IBM-nedbrud: Hvad ved vi?
Onsdag den 9. april kl. 12.01 startede en switch i en større IBM-installation at sende data i stride strømme gennem IBM's net. Få minutter efter er det klart, at fejlen omkring den famøse switch får en lang række andre switches til at stå af.
12.25 tilkalder den danske direktør for IBM, Lars Mikkelgaard-Jensen hjælp fra IBM's internationale hold af eksperter. Nogenlunde sådan beskriver IBM overfor Børsen i går for første gang siden nedbruddet onsdag i sidste uge det konkrete forløb omkring nedbruddet.
Men desværre er Lars Mikkelgaard-Jensen ikke særlig præcis omkring detaljerne ved nedbruddet. IBM har over for Version2.dk afslået at give en mere teknisk og indsigtsfuld forklaring på nedbruddet ? en forklaring som netop kan være til glæde fra andre it-professionelle, så de ikke havner i en lignende situation.
Men hvad ved vi allerede på nuværende ? uden bidrag fra IBM-direktøren.
Omganget?
I første omgang er det omfanget af nedbruddet, der løbende er blevet afsløret som værende betydeligt mere omfattede, end de første meldinger tydede på.
Indtil videre har det været fremme, at nedbruddet ramte større danske erhvervsvirksomheder som Arla, A. P. Møller-Mærsk, Danske Bank, Carlsberg og DSV.
Men heller ikke det offentlige gik ramt forbi. Her blev to vigtige hjemmesider berørt direkte af nedbruddet nemlig apoteket.dk og sundhed.dk.
Også Københavns Kommune, ATP og hospitaler i Region Hovedstaden blev taget med i faldet.
Hvad ved du? Men er dette den endelige liste. Hvad ved du. Deltag i debatten nedenfor, hvis du har kendskab til flere IBM-kunder, der blev ramt af onsdagens nedbrud. IBM er blandt andet leverandør af EPJ-systemer til en række hospitaler ? blev de også berørt af nedbruddet?
Deltag i debatten neden for eller send en mail til redaktion@version2.dk.
Hvad skete der?
Som beskrevet gik en switch amok i et hjørne af IBM's driftsinstallation. Men IBM har ikke oplyst, hvilken type switch, der var tale om, eller hvad der var årsagen til, at det kunne ske. Ifølge Børsen var det angiveligt en switch fra Cisco, der er verdens største producent af netværksudstyr, der skabte problemerne, men det er ikke bekræftet af IBM.
Lars Mikkelgaard-Jensen oplyser til Børsen, at uheldet skete under almindelig drift, og fortsætter: » vi foretog intet ekstraordinært, da det indtraf. Vi har været helt ude i et hjørne, hvor vi næsten aldrig kommer.«
Til it-mediet Comon siger Politikens it-direktør, at IBM overfor Politiken har forklaret, at det var tale om en menneskelig fejl. Ifølge Comons kilder var der tale om en fejlkonfigurering af et VLAN.
Hvad ved du? Var det en Cisco-switch, der sendte den samme datastrøm ud i nettet, der til sidst skabte så meget overbelastning, at det ene it-system efter det andet gik i sort? Har du kendskab til situationer omkring switches, der har haft samme uheldige forløb, som IBM oplevede den 9. april. Deltag i debatten neden for eller send en mail til redaktion@version2.dk.
Hvor skete uheldet?
På Dorte Tofts blog spekuleres der i, om uheldet indtraf i det driftscenter, der kom ind i IBM, da IBM købte Mærsk Data. Den gang hed selskabet DMdata og stod blandt andet for driften af it-systemer hos Danske Bank og A. P. Møller ? Mærsk.
Hvad ved du? Var det en switch i det forhenværende DMdata, der løb løbsk og sendte datastrømme ud i nettet og fik kundernes it-systemer til at gå sort.
Deltag i debatten neden for eller send en mail til redaktion@version2.dk.
Kommentarer (10)
Det må da være utilfredsstillende for IBM's kunder at IBM ikke har folk her i Danmark til at kunne ordne den slags.
Det er åbenbart lykkedes IBM at overbevise kunderne om, at når de tilkalder internationale eksperter, er dette en god ting. I virkeligheden er det jo en ret dårlig service, at de ikke har folk her i landet til at fixe tingene.
-
0 -
0
Beskrivelsen passer langt hen ad vejen rigtig godt med et bridging loop.
Til at undgå den slags har man spanning tree protocol (STP), der i Cisco-miljøer normalt anvendes i en variant, hvor STP køres separat for hvert VLAN.
Hvis man har mange VLANs, har man således også brug for mange STP-processer, hvilket ikke er et problem på typiske backboneswitche som eksempelvis Catalyst 6500-serien.
Imidlertid er det ikke usædvanligt, at mindre switche kun understøtter et mindre antal STP-processer, eksempelvis 128. Det gælder blandt andet Catalyst 3560, der ofte er populær til placering i serverrum og datacentre, fordi man får 24 eller 48 porte på 1 RU.
Hvis man ukritisk opretter VLANs uden specifikke begrænsninger af tilladte VLANs på sine 802.1Q trunks, og hvis man tilmed anvender VTP-protokollen til automatisk distribution af VLANs mellem switche, går det meget nemt galt.
En Catalyst 3560, som har to uplinks uden begrænsning af VLANs, vil være nødt til at oprette og aktivere alle disse VLANs inklusiv STP-processer, også selv om der ikke er udstyr tilsluttet i disse VLANs. Men når den kommer over 128, må den give op, og dermed vil der være VLANs, som ikke kører STP, hvorved der kan opstå et loop, der ikke bliver taget hånd om.
Der er andre mulige scenarier, som kan føre til bridging loops, lige som det kan være noget helt andet, der er sket. Uden viden om, hvordan tingene rent faktisk er opbygget kan det derfor ikke blive andet end getværk.
Men hvis der er tale om et bridging loop, er der reelt kun to mulige forklaringer på, hvordan det kan opstås: Konfigurationsfejl eller fejl på udstyr. Og i mindst ni ud af ti tilfælde, er det førstnævnte, der gør sig gældende …
-
0
-
0
Det er ikke så unormalt at datacentre drives af dygtige folk, men de virkelige eksperter er helt andre steder. Hvis det så virkeligt brænder på, er de klar til at yde distance hjælp eller endda tage første fly/helikopter og komme til undsætning.
Havde i ikke et eksempel på det for et års tid eller mere siden, hvor et stort firma fik tilfløjet eksperter fra et andet land.. Kan ikke huske hve det var, men noget ala. IBM eller Oracle..
Tror faktisk det var dengang Danske Bank havde et nedbrud der varede i en lille uge.. Dengang var det også IBM der styrede det: http://www.computerworld.dk/art/18390
-
0
-
0
Jeg havde store problemer med at koble op til de servere, som bruges i forbindelse med ITstyrelsens elektroniske fakturaer til det offentlige. http://www.itst.dk/arkitektur-og-standarder/infrastruktur-og-felles-losn...
-
0
-
0
Dansk Landbrug blev også ramt. Alle deres VPN-forbindelser og regnskabssystemet Ø-90 kører igennem IBM.
Alle landbrugscentre og mange landmænd benytter Ø-90 systemet til kontering. Ø-90 kørte først igen op af formiddagen dagen efter nedbruddet.
Det sker i øvrigt forbavsende jævnligt at der er problemer med Ø-90, og det er altid hos IBM problemet er. Jeg vil påstå det sker 3-4 gange årligt, og der varer typisk et par timer før det kører igen. I den forbindelse har jeg også oplevet dårlig service fra IBM's side. Det er ikke altid man bliver informeret om et nedbrud, og hvis man gør får man aldrig at vide årsagen til nedbruddet.
-
0
-
0
... Hey, det var en central hardware-ting, at hele Prøvensvej var nede. Så alle kunder, der driftes derfra var nede.
Der er ingen grund til at tilkalde udenlandske eksperter.
Man ved, hvad der skete, gutterne derude handlede meget meget fornuftigt og klogt, og der er fuld gang i at få leveret patches til lignende ekstreme situationer (hidtil usete i verden).
Det er jo kun for at kunne sige "Vi gør ALT, hvad man kan...", at Mikkelgaard tilkalder folk, der taler noget andet end dansk.
Gutterne derude var og er fuldt ud i stand til at håndtere det her.
At en fjollet IT-ordfører fra SF "vil have Sander i samråd" er én ting. Han er jo bare fjollet og ved intet.
Men jeg tror det er vigtigt at vi alle forstår, at vi her i lille Dannevang har akkurat ligeså gode folk som de andre lande. Og på nogle punkter (det med at kunne snakke sammen og få ting til at fungere uden at skulle skrive kontrakter og holde møder med chefer) betydeligt mere effektive, når de da ellers får lov at arbejde.
Jeg må sige, at jeg (med det rimeligt detaljerede kendskab jeg har til nedbruddet og dets håndtering) gerne vil udbringe en skål for gutterne derude på Prøvelsens Vej. Respekt, som man siger.
mvh.
Mogens
-
0
-
0
Tilkald af udenlandske eksperter er et centralt ritual i IBM kulten.
- Det beviser ledelsens handlekraft (laes vi goer noeget)
- Det daekker ledelsens roev (vi bruger de bedst mulige resourcer)
- Det viser overfor kunderne at "IBM har globale styrker"
De reele effekter er desvaerre
- Forsinkelse i problemloesningen da der skal bruges tid paa at jage en "ekspert" i en anden tidszone og saette ham ind i sagen.
- Demotivering af de lokalt ansaette da deres analyse bliver baade forsinket og nedvurderet.
Et hyppigt paradox er at den samme person vurderes langt hoejere som ekstern ekspert end hvis han blev som fastansat i organisationen. Hyppigt bliver geografisk distance det brugt som et kvalitetsmaal for "eksperten".
Mvh
Claus
-
0
-
0
Hvis IBM drifter alt i Danmark, så er det da klart at det virker omfattende når de endelig går ned.
-
0
-
0
Mogens Nørgaard skriver: At en fjollet IT-ordfører fra SF "vil have Sander i samråd" er én ting. Han er jo bare fjollet og ved intet.
Vi er jo ret mange der intet ved, for IBM er jo ikke ligefrem dem der er åbne omkring hvad der skete. Man får kun brugbare oplysninger af bagvejene, og det virker som dårlig service i mine øjne.
-
0
-
0
Det var da det vildeste postulat længe hørt...
1/ De "lokale" vil da næppe sidde på deres flade og vente på eksperten. De vil da arbejde videre med at løse problemerne.
2/ Den tid man bruger på at sætte eksperten ind i tingene er sikkert godt givet ud - han har jo netop en viden som kan biddrage til fejlsøgningen.
3/ Mon ikke IBM har eksperter i tidszoner, som ligger tæt på vores.....
/Kim
-
0
-
0
Tilføj kommentar
