Dette indlæg er alene udtryk for skribentens egen holdning.

Single point of failure

9 kommentarer.  Hop til debatten
Blogindlæg11. april 2008 kl. 20:04
errorÆldre end 30 dage

Nedbruddet i onsdags i IBM's primære driftscenter viser med al ønskelig tydelighed, hvilke risici dette samfund i stadig stigende grad bygges på.

En pæn håndfuld af Danmarks største virksomheder - fra A.P.Møller, Danske Bank og Carlsberg til ATP og transportfirmaet DSV - blev lagt døde på samme tid af den samme fejl i IBM's driftscenter. Det er virksomheder, der har en bevidst strategi om at outsource driften til en stor og stærk leverandør, der på sin side konsoliderer så mange kunder som muligt på det samme udstyr for at optimere fortjenesten på sine driftsaftaler.

Flere virksomheder vil i de kommende år gå præcis samme vej, og selv staten opererer med planer om eet stort it-driftcenter for de fleste af sine enheder.

Spørg en militærstrateg, om han ville samle alle sine styrker eet enkelt sted? Man har vel lært lektien fra Pearl Harbour .....

Artiklen fortsætter efter annoncen

Javel, der var etableret backup-centre med fail-over teknologi, men det virkede bare ikke, selvom et af verdens ypperste it-firmaer havde brugt et 3-cifret millionbeløb på konstruktionen. Det siger lidt om, hvilke udfordringer vi er oppe imod.

Den herskende management-filosofi sværger til centralisering og konsolidering i den økonomiske rationalitets navn, men hvor rationelt er det egentlig, hvis samfundet kan lammes fuldkommen af en teknisk fejl i et driftscenter .....

9 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
9
Indsendt af Anonym (ikke efterprøvet) den man, 04/14/2008 - 13:04

Jeg kan ikke undlade at bemærke at man fokuserer ensidigt på availability her. Det er vigtigt og vi kender kuren - redundans på alle kritiske niveauer. I sidste ende med en varm synkroniseret backup. Det kan være dyrt, svært, krævende og alligevel går det galt.

Men der mangler et fokus på recoverability, dvs. hvor galt kan det gå worst case og hvor hurtigt kan vi komme op igen. Det drejer sig i stigende grad om isolering, virtualisering og specielt revokability på alle niveauer.

Bedre forståelse for recoverability ville gøre availability-problemet væsentligt mindre problematisk, bl.a. fordi det på den ene side også ville dække bevidst fejl og angreb som et hastigt voksende problem og på den anden side reducere sårbarheden væsentligt ved distribution blandt flere produktionslokationer.

8
13. april 2008 kl. 23:35

Ole stiller et ubehageligt men meget relevant spørgsmål ved at konsolideringen af datacentrene på et meget lille antal enheder medfører en øget risiko for single point of failure. Det er jeg helt enig i og jeg mener at spørgsmålet godt kan udvides. Mange virksomheder (og formodenligt flere og flere) har indbyggede single points of failures i deres systemarkitektur pga afhængigheder til interne eller eksterne services.

Jeg mener desværre ikke at der findes et teknologisk fix på det her problem.

@Dennis Denne type virksomheder hoster ikke billedalbums :-). Når DSV og APM's bliver varerne ikke leveret og smoggen fra de ventende lastbiler kan ses på satelitbillederne. Det lyder som den eneste fysiske manifestation på nedbruddet i DK var svigtende vareleverancer og det må betragtes som billigt sluppet.

Flere providers med forskellige kvalitetsniveau giver ikke nogen stor forbedring i situationen hvis dine systemer er tætkoplede. Tværtimod vil din tilgængelighed blive defineret af den værste leverandør.

@Michael Helt enig i din analyse og faktisk er der flere af de nævnte kunder som har opbygget sådanne kompetancecentre, men efter min mening bliver de meget tandløse da deres interface til leverandørens organisation filtreres af en Service Delivery Manager.

Respekt for kunden har jeg ikke set meget i praksis. Den instinktive reaktion hos leverandøren i tilfælde af problemer er: flugt, bortforklaring og send problemet i udvalg (det er ikke kun IBM som har den taktik).

@Jens Personligt tvivler jeg ikke på at IBM er blevet for stor, men man må også anerkende at antallet af problemer i et eller andet omfang er proportional med antal og kompleksiteten af kunderne. Et webhostingsfirma med 50.000 hjemmesider har mange kunder men begrænset kompleksitet. Et andet problem er at IBM lover at drifte hvad som helst. Det giver nogle interessante udfordringer - man kan f.eks. ikke undervurdere kvaliteten i en applikation skrevet af kinesere udfra en specifikation forfattet af indere på baggrund af et oplæg fra den yngste medarbejder i et internationalt konsulentfirmas danske afdeling.

Stort er helt klart = dårligt hvis vi snakker komplicerede systemer (men også billig). Den eneste forklaring jeg kan se er at en eller anden DJØFfer har udtrykt guldkornet "IT-drift er en standardydelse" og det var givet genklang hos hans ligesindede, der elsker når verden kan sammenfattes på 3 bulletpoints i Powerpoint. Det er mit indtryk at IT-drift hyppigt betragtes som en ren omkostning som skal minimeres for enhver pris.

@Lau Det er da meget interessant at der findes højkvalitetshardware - man kan da også bare bruge IBM AS/400 eller mainframe. Kunderne har en kompleks heterogen infrastruktur som dikteres af kundens indkøbspolitik og applikationskravene. Hardware koster jo penge så applikationerne kan godt afvikles på en gammel desktop PC.

@Peter Ingen tvivl om at kunderne ikke investerer tilstrækkeligt i disastertests. De betragtes mest som en udgift der skal sikre en pletfri revisionspåtegning og ikke som en naturlig funktion i et stort driftmiljø. Et eksempel fra virkeligheden i en meget stor dansk koncern (2 år gammelt): der gennemføres to årlige disastertests hvor det testes om hele applikationsporteføljen kan flyttes fra det primære til det sekundære driftcenter - det ser jo meget smukt ud på revisionsrapporten. I praksis var denne øvelse planlagt over 3 måneder og blev gennemført af et dedikeret team. Testen var successful hvis alle services startede op - der var ingen kontrol af datakvalitet. I denne test var det ikke muligt kun at lave failover på en del af applikationerne - det var alt eller intet. Jeg gætter på at eksemplet stadigt er "best practise" hos mange danske virksomheder.

Uprofessionelt? Det er jo altid en nem anklage i bagklogskabens klarhed :-) Hvis vi holder fast i de ubekræftede rygter om en switchfejl og et ikke-dubleret backbone er der nok kød på den påstand, men en værre situation kunne være opstået i forbindelse med en brand eller vandskade på prøvensvej. Der er nogle begrænsninger i tid og rum man som både kunde og leverandør har svært ved at overskride og slet ikke at diskutere. Det er et faktum at IBM ikke vil være istand til at lave recovery af flere store kunder parallelt indenfor overskuelig tid. Denne typer opgaver indebærer mange manuelle processer med stor risiko for fejl og er ekstremt koordineringstunge. Det reele arbejde skal udføres af et meget begrænset antal tekniske resourcer som formodenligt vil være brændt ud indenfor de første 48 timer. Jeg formoder at det bliver vurderet som en "known but insignificient risk" men jeg tvivler på at kunderne helt har gennemskuet hvor sårbare deres drift er overfor single points of failures og at påvirkning fra leverandørens andre kunder medfører at deres dyrt udviklede disasterplan er værdiløs.

Mvh Claus

7
13. april 2008 kl. 12:03

Jeg syntes ikke, at Ole Bechs blog - indlæg handler om teknik, men snarere om systematik og procedurer. Uanset om IBM havde alle mulige sikkerhedssystemer på plads, så fejlede de alligevel. For mig tyder det på, at de ikke har kontrolleret om det virker.

Det virker noget uprofessionelt.

@Stephan: Selvfølgelig skal man sikre maksimal sikkerhed, og den "bedste" måde at gøre det på er ved at gøre det brugermæssigt så svært at brugerne vælger fra at benytte sig af systemerne. Hvis ingen bruger systemerne, så er det ikke så interessant for dem der ønsker at ødelægge.

Jeg syntes ikke at man kan kalde virk.dk m.m. for single point of failure(Selvom de er det!), uden samtidig at sige at det er en kalkuleret risiko man må tage for at få brugerne (Os) til at benytte sig af virk.dk m.m.

Vi kan håbe på at virk.dk m.m. har optimeret sin sikkerhed så godt som det kan lade sig gøre, og samtidig fået pudset fail-over procedurerne af, så i givet fald det går galt, så er man hurtigt oppe igen.

Peter Hansen

6
13. april 2008 kl. 11:30

Hvis oppetid og tilgængelighed er vigtig findes der servere der kan levere varen. Det er muligt at undgå single point of failure, failover og systemnedbrud også selvom der er knurhår og defekte netværkskort. Amerikanske Stratus Technologies har i mere end 20 år leveret ftServere hvor ft direkte står for fejl tolerant. FtServere er bygget til at fejle uden at gå ned. Så det er simplethen bare et spørgsmål om at vælge de rigtige server teknologier. Siemens Wind Power der har anvendt både clustre og ftServere siden 2003 siger i en artikel om serverteknologierne »Udgifterne til softwarelicenser på redundante clustre er dobbelt så store, og vi får blandt andet problemer med koblingen fra serverne til elværkernes øvrige datasystemer, fordi det er svært at styre, hvilken fysisk forbindelse der skal overtage ved udfald. Det problem undgår vi helt med en Stratus Server.« /Lau Ludvigsen PC Instruments

5
13. april 2008 kl. 09:38

men det virkede bare ikke, selvom et af verdens ypperste it-firmaer havde brugt et 3-cifret millionbeløb på konstruktionen

Der er en udbredt tendens til at mene, at hvis man bare vælger en stor, international leverandør, kan det ikke gå galt. Som om de automatisk bliver gode af at være store.

I min optik har IBM dog været i en del modvind her på det seneste. Denne sag tyder jo på, at man ikke har gjort sit arbejde godt nok (men det kommer selvfølgelig an på, præcis hvad der er sket).

For nyligt åbnede en ny terminal i Heathrow. Her stod IBM bag it-delen af bagagesystemet, der endte i total kaos. Og på det seneste har vi hørt forskellige kunder skille sig af med IBM, fordi de ikke var tilfredse.

Er IBM simpelt hen blevet for store og ude i stand til at styre sin egen organisation? Eller har de bare været usandsynligt uheldige lidt for mange gange i træk?

Uanset forklaringen ligger der en ikke helt nem pr-opgave forude …

4
Indsendt af Anonym (ikke efterprøvet) den lør, 04/12/2008 - 13:20

Det er nemt at skyde på IBM, men prøv lige at se hvad der foregår i OIO-regi pt. Staten selv er jo den største synder på dette område.

Dependability dækker over både accidents og attacks, og både problemer med availability (manglende redundancy) og manglende recoverability og revokability med fokus på skalerende falblacks.

IBM-nedbruddet havde nok tab som konsekvens, men der er ingen varige skader.

Single point of (trust) failures dækker f.eks. også over indgange der kan bruges til skalerende attacks.

Forestil dig når (ikke om, men når) pas-databasen med certificerede biometriske data bliver hacket og teknokraterne har tvunget accept af biometrisk identifikation som adgangskontrol.

Det er som at forære denne verdens Rasmus Trads'er beviser på ikke bare Andre Lublin, men hvem som helst. Det kræver kun at man spoofer biometrien selv og så er løbet kørt.

Ser man med sikkerhedsbriller på OIO må man rystes over den mangelnde respekt ofr helt basale forhold.

Borger.dk er et single point of failure. Sundhed.dk er et single point of failure Dokumentboksen er et single point of failiure

Med SSO er IdP er et single point of failure eftersom det kan authentikere på vegne af alle - designet som et rent kommercercielt man-in-the-middle attack så det maksimerer gatekeeper-rollens magt og profitabilitet.

Borgerservicecentrene er single point of failures. Rolle-baseret adgangskontrol er single point of failure.

Et samtykkeregister (Gud forbyde) ville skabe et single point of failure til alle andre systemer.

Etc. etc.

Det er først og frememst banale designspørgsmål som arkitekterne forsynder sig imod. Men de stammer igen fra basale fejl på strateginiveauet.

3
12. april 2008 kl. 12:51

@ Michael, jeg er helt enig med dig i, at vi alle bør lære af vore fejl. Men du husker vel det tilsvarende store nedbrud hos IBM i 2003, hvor Danske Bank røg helt ned i græsset. Det nuværende setup, som svigtede i onsdags, var netop lavet direkte ud fra læren i 2003!!

Det siger mig, at teknologien ikke går i retning af det mere og mere simple og standardiserede, men tværtimod bliver mere og mere kompleks, og dermed vanskeligere og vanskeligere at håndtere .....

2
12. april 2008 kl. 10:06

... om man ønsker at lege "Den som flaskehalsen peger på. Hvis man har mod og mandshjerte kan man gå ud og shoppe rundt og gå efter de bedste tilbud og så sammensætte en samlet leverance til sin organisation. Når det så går galt - for det gør det altså også i det scenarie, så skal man til at spille den gamle børneleg for hvis ikke man sætter sig voldsomt i respekt over for sine leverandører, så vil de sidde og pege på hinanden og så vil DU som IT chef være den der skal tage tævene fra din organisation. For at imødekomme dette vil du være nødt til at opbygge en stab af meget dygtige (og dyre) eksperter, som kan støtte dig i at genneskue leverandørernes bortforklaringer (der kan jo være tale om bods bestemmelser for den som fejlede) så du kan skille skidt fra snot. Her kan du meget vel sætte din besparelse over styr og dit liv bliver fandeme ikke nemmere. Jeg forstår godt at der er nogen der vælger one-stop shopping modellen. Og skal vi så ikke lige afvente og se hvad det lige var der skete i onsdags? Det er vi da vist en del der er spændte på at høre for det kan hænde at der er noget alle kan lære lidt af - også i Roskilde kommune.

1
11. april 2008 kl. 20:44

Hvis det ikke ødelægger fra eller til (for den enkelte) om 1 eller 10 virksomheder ryger ned, er det vel egentlig ligemeget.

Til gengæld ville det være godt hvis de enkelte firmaer delte deres ting ud til flere providers, eller forskellige firmaer der kunne overtage vitale opgaver for hinanden, sørgede for at bruge forskellige providers.