DXC-brøler tog strømmen til Sundhed.dk, mens tusinder ventede på corona-svar

DXC-brøler tog strømmen til Sundhed.dk, mens tusinder ventede på corona-svar
Illustration: Screenshot.
I begyndelsen af denne måned var Sundhed.dk nede i mere end et døgn, og de tusindvis af danskere, der ventede svar på corona-test, kunne ikke tilgå dem på siden. Nu viser en aktindsigt, at driftsleverandøren selv kom til at tage strømmen ved en fejl.
Reportage21. september 2020 kl. 03:45
errorÆldre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Den 4. september klokken 07.52 forsvandt Sundhed.dk fra internettet, og de næste cirka 18 timer kunne de tusindvis af danskere, der utålmodigt ventede svar på en corona-test, ikke tjekke dem på siden.

»Det er ret kritisk,« lød det dengang fra Sundhed.dk, og nu viser det sig, at det var Sundhed.dks egen driftsleverandør, DXC Technology, der bogstaveligt talt trak stikket på den vigtige hjemmeside ved en fejl.

Strømmen skulle fjernes fra et SMB-rack, som ikke var i brug længere - og her gik det altså galt.

»Ved en fejl var strømmen i dette rack forbundet/videreført til to andre racks med udstyr i. Det var årsagen til, at det andet rack mistede strømmen, og den fælles storage blev utilgængelig,« skriver DXC i en rapport til Sundhed.dk, som Version2 har fået aktindsigt i.

»Ingen var vidende om, at der var afhængigheder af strømtilslutninger på tværs af rack-skabe, da nedtagningsbestillingen blev sendt.«

Til tælling i 18 timer

Klokken 01.41 dagen efter blev det muligt at logge på Sundhed.dk igen for de mere end 100.000 daglige brugere, der besøgte siden i den periode.

I de mellemliggende 18 timer udspillede sig et kaotisk forløb, som Version2 kan kortlægge.

Årsagen til fejlen blev fundet mellem klokken 8 og 10.

Fra klokken 10-14 forsøger DXC-teknikerne at få liv i storage diskene.

»Efter flere forsøg blev det besluttet at kalde en IBM-tekniker ind,« står der i rapporten fra DXC.

Log ind og få adgang
Du kan læse indholdet ved at logge ind eller oprette dig som ny bruger.
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
28
24. september 2020 kl. 10:03

Det udløste ikke verdens undergang, men det er da rimeligt at forvente af en stor og professionel leverandør at de leverer en service af professionel kvalitet.

Ja. Men ... kig tilbage i historien ... de store professionelle leverandører laver også fejl. Man kan ikke tage en enkelt fejlsituation og så blæse den op til verdens undergang. Med mindre folk opfatter sundhed.dk som værende et website der er kritisk for nationen på samme niveau som el-forsyningen, respiratorer på hospitaler, etc. Det gør jeg ikke. Derfor kan man heller ikke forvente at der ikke sker en fejl fra tid til anden. Det er dyrt at have et setup hvor man kan forvente 100% oppetid.

Hvis nu sundhed.dk eller DXC havde en historik af fejl, så var kritikken berettiget. Men at lave folkestorm på basis af en enkelt fejl er useriøst.

Forhåbentligt har de CI på det ellers, er det også en stor utilsvarende tilgang til at lave en så stor løsning. Jeg vil væde med at 90% af deres interface kan der skrives tests til, som helt automatisk kan køres igennem inden et release til produktion.

Jeg gætter på at sundhed.dk har integration til så mange forskellige offentlige og private sundhedssystemer at muligheden for 90% er utopi. Min erfaring er at det nemme i IT projekter er alt det der ligger indenfor egen løsning. Det svære er alle de integrationer man har til alle mulige andre systemer der hver har deres egen protocoller, dataformater og issues.

27
23. september 2020 kl. 22:53

Men selvom man havde gjort alt ovenstående vil der opstå fejl. Den hyppigste fejl i store custom IT systemer er kode-fejl. Der er sikkert et lille IT team omkring sundhed.dk som kæmper for at rulle nye releases ud og rette fejl. Og et antal testere som aldrig får testet det hele hver gang der releases ...

Forhåbentligt har de CI på det ellers, er det også en stor utilsvarende tilgang til at lave en så stor løsning. Jeg vil væde med at 90% af deres interface kan der skrives tests til, som helt automatisk kan køres igennem inden et release til produktion.

Der kan altid smutte kodefejl igennem, men så skriver man en ny test der tester for det scenario og så er man en fejl mindre ved næste release. Det er umiddelbart heller ikke mit indtryk at sundhed.dk er så ramt af den type fejl?

26
23. september 2020 kl. 11:45

Det ville være rart hvis A-nummeret kun stod i klar text, hvis ens udbyder viste det var legitimt og kunne stå inde for det. Så kunne udbyderne opbygge en chain-of-trust, hvor de kun sagde ok, hvis de selv havde checket oprindelsen af forbindelsen eller den kom fra nogen de troede på, og de derfor havde gjort det samme. Hvis trusten manglede kunne man fx sætte 666 foran nummeret eller helt lade være med at levere A-nummeret til kunden.

Det ville være rart, hvis legitime firmaer, som benytter spoofing for at gøre deres service transparent, skulle bede ejeren af A-nummeret om at meddele udbyderen at servicefirmaet må impersonere deres nummer. Udbyderen skulle så checke alle a-numre fra servicefirmaet mod denne positiv liste og sætte firmaets eget a-nummer ind, hvis firmaet ikke havde tilladelse til at spoofe det.

25
23. september 2020 kl. 09:08

Det udløste ikke verdens undergang, men det er da rimeligt at forvente af en stor og professionel leverandør at de leverer en service af professionel kvalitet. Hvis dette udfald har besværliggjort arbejdet for tusindvis af sundhedspersoner og borgere/patienter og skyldes sjusk, synes jeg da vi som it-folk burde lære af det og forbedre kvalitet - og ikke bare trække på skuldrene. Ellers ender man jo i et serverrum der ligner en klump spaghetti hvor ingen kan overskue hvad der afhænger af hvad, og hvor det kun er er spørgsmål om tid før det går galt.

24
22. september 2020 kl. 21:18

Fejl sker. Det sker også i de mest professionelle organisationer. Problemet med et setup som det her er at det forventer at alt er sat op som planlagt. Men hvad hvis nogen havde trykket på hovedafbryderen fra datacentret? Eller hvis der opstod brand.

I stedet skal man lave et setup som også fungerer med fejl. Og ikke bare end fejl, men flere. Hvis man nu havde spredt sundhed.dk ud over flere datacentre og rutinemæssigt lukkede dele ned for upgrade o.lign. så ville denne form for problemer være fundet for længe siden.

Men selvom man havde gjort alt ovenstående vil der opstå fejl. Den hyppigste fejl i store custom IT systemer er kode-fejl. Der er sikkert et lille IT team omkring sundhed.dk som kæmper for at rulle nye releases ud og rette fejl. Og et antal testere som aldrig får testet det hele hver gang der releases ...

Så måske skal vi have flere sundhed.dk. Lavet af uafhængige teams. Men der kan findes security fejl i OS og software stakken, så de skal bruge forskellig software stack ... det kan blive rigtigt godt ... og meget meget dyrt.

Så måske er sundhed.dk godt nok som det er. Samfundet kører videre. Fejlen sker ikke hver dag og systemet har håndteret at der er kommet mange flere brugere på siden COVID-19 ramte os ... det er godt nok selvom der altid er plads til forbedringer.

23
22. september 2020 kl. 11:14

Hvorfor det ikke selv kan komme i luften ved jeg ikke.

Måske der allerede var warnings om syge diske i systemet eller en restore var i gang da strømmen blev taget fra systemet = meget høj sansynlighed for at det går galt.

Når man har strøm der går fra rack til rack som eneste strømkilde, så er min tiltro til at DXC har styr på forebyggende vedligeholdelse meget lille.

22
22. september 2020 kl. 09:53

Anvendes der ikke journaliserede file-systemer (Linux- ext4 eller lignende), spejlede disks (raid-1 eller 10)? Det koster ikke en formue.

Der er ikke nogen seriøse os'er der ikke kører med journaliserede filsystemer i dag. Ud fra teksten virker det som om dxc har købt et færdigt SAN (eller lign) fra IBM, men at det er blevet sygt pga uventet crash/strømsvigt: "IBM fejlsøgte på storage-systemet".

Hvorfor det ikke selv kan komme i luften ved jeg ikke.

21
21. september 2020 kl. 23:00

Jeg har serviceaftale på min bil og der forventer jeg, at den bliver holdt kørende og i forsvarlig sikkerhedsmæssig stand af leaser. Jeg forventer ikke at mekanikeren forbinder blinklys og traction-control til samme sikring eller bruger en brændstofpumpe der ikke virker efter tom tank ... Jeg forventer at mekanikeren ved ved han gør, at der følges afprøvede, reproducerbare procedurer, at der er kvalitetskontrol og at værkstedet har en brugbar forsikring, skulle man dumme sig. Jeg forventer, at jeg får at vide, hvis der er problemer, eller reparationer, som jeg skal forholde mig til.

Hvis det var min bil havde jeg uden tvivl haft en meget interessant snak med værkføren.

20
21. september 2020 kl. 20:47

Kan du supplere med en kilde til at der er høj sandsynlighed for falske negativer (og at denne risiko er forhøjet når folk ikke har symptomer)?

Denne her siger 5-10% falske negativer ved stærke symptomer, og det er jo ret højt i sig selv: https://www.sst.dk/-/media/Udgivelser/2020/Corona/IRF-Almen-praksis/Kommunikation-til-almen-praksis_test-af-COVID.ashx?la=da&hash=A28AC860410928AAD8864F689B6A05C9E56F3A87

Jeg kan ikke længere finde der hvor jeg læste at der var højere risiko for falske negativer uden symptomer, dog finder jeg flere steder der nævner at koncentrationen af virus hvor man poder ændrer sig igennem forløbet, bla. https://sundhedspolitisktidsskrift.dk/nyheder/3543-coronabloggen-hvad-betyder-din-covid-test.html . Og det kan jo forklare hvorfor man vil teste på 4. dag og 6. dag ved kontaktopsporingen.

18
21. september 2020 kl. 18:16

Beklager, det havde jeg ikke lige fattet. Jeg ved intet om hvordan man f.eks. sikrer en respirator på et hospital. OG der har tydeligvis ikke været relevant sikring mod den menneskelig dumhed hos leverandøren her.

jeg ved at mht respiratorpatienter er der i mange tilfælde personer tilstede hvis funktion er at kunne træde til og bruge manuel ventilator hvis strøm/maskine går (i hvert fald tidligere er der brugt lægestuderende etc som nattevagter til den slags jobs hvor de så kunne bruge tiden til at studere mens de bare var der for det tilfælde at maskinen gigki stykker)

17
21. september 2020 kl. 15:38

Kan du supplere med en kilde til at der er høj sandsynlighed for falske negativer (og at denne risiko er forhøjet når folk ikke har symptomer)?

Jeg har ikke nogen kilde, men i følge MEDCRAM er der nogle billige og hurtige test, der giver falske negative, når antallet af virus i prøven er lavt. F.eks. i begyndelsen af en infektion. Når infektionen udvikler sig, stiger virusmængden, og de giver så et udslag. Men da man angiveligt er lidt lidet smittefarlig i begyndelsen, va det - måske - ikke så slemt. Men det var nogle stick-tests med en svartid på 15 minutter, ikke de timer, som der synes at være tale om her.

16
21. september 2020 kl. 15:00

Kan du supplere med en kilde til at der er høj sandsynlighed for falske negativer (og at denne risiko er forhøjet når folk ikke har symptomer)?

14
21. september 2020 kl. 13:48

Alle seriøse steder jeg har været forbi, har man 2 stikdåser i HVERT skab - der er ført for HVERT skab - tilbage til hver sin gruppe og bag en UPS.

Og vigtige hosts har selvf. dobbelt strømforsyning - så de får strøm fra begge grupper.

Så har man IKKE nogen grund til at føre på tværs af skabe (er der ingen der inspicerer skabe/laver review - bare engang imellem - og sæter arbejde igang, hvis man ser ledninger på tværs af skabe?)

13
21. september 2020 kl. 13:38

Et er at der slukkes for strømmen ved et uheld. Men hvorfor skal det tage så lang tid og involvere en IBM-tekniker at få systemet i luften igen? Anvendes der ikke journaliserede file-systemer (Linux- ext4 eller lignende), spejlede disks (raid-1 eller 10)? Det koster ikke en formue. Men hvis det ikke virker den dag der er brug for det er det jo lige meget.

10
21. september 2020 kl. 11:26

Det er yderst vigtigt for alle kræft patienter.

Hvad angår Corona må jeg sige det er mindre vigtigt af de første 2 mio test er en trediedle ikke rapporteret / fundet brugbart. De fleste for gentaget den samme test igen og igen til hvad nytte ? Samfundet har brændt over en 1 mia kr. af i test alene, hvoraf mange er unyttige, fordi folk ikke passer alt for godt på. Tes burde forbeholdes hospitaler og sundhedspersonale og plejepersonale for de gamle.

9
21. september 2020 kl. 11:11

@Mogens Lysemose Det er jeg som gammel it-konsulent og stærkstrømsingeniør fuldstændig klar over. (Derfor står der, ikke som gætværk, men konstatering: "Jeg kan forestille mig ..." = Jeg ved at .....).

Spørgsmålet gik på et fail-safe system med dobbelt-sikkerhed mod menneskelige fejl - som kan være så banal som brug af forkert afbryder i en tavle. DET ville jo ikke være godt e.g. på en intensiv afdeling. Så hvordan er disse systemer sikret helt frem til "lungemaskinen" ?

8
21. september 2020 kl. 11:03

Jeg kan forestille mig et system med power backup og fall back, som er designet til at træde i funktion ved (ekstern) strømsvigt.

Det er standard hos de mere professionelle server-hosting-leverandører: Garanteret strøm via UPS (batteri-baseret). Når strømmen går sendes start-besked fra UPS til (typisk) diesel-generatorer som leverer strøm inden UPS-batteriet er opbrugt.

Men det hjælper jo ikke hvis teknikerne slukker/trækker stik ud af UPS'en, og et af dem er en simpel stikdåse som man har brugt som forlænger/fordeler til et par naboskabe...

Lige som hvis du slukker på kontakten derhjemme og først opdager der at "hov nu stoppede både internet, fjernsyn og computer" - og ikke bare den lampe du troede du slukkede for. Forskellen er bare at her er det ikke bare ungerne og fruen der bliver kortvarrigt irriteret

7
21. september 2020 kl. 10:49

Jeg kan forestille mig et system med power backup og fall back, som er designet til at træde i funktion ved (ekstern) strømsvigt.

Gad vist om sådanne systemer er beskyttet mod in-house betjeningsfejl?

Måske er det ikke en del af design-filosofien? (- hvilket vel så er en fejl)

P.S.: Nogle tekniske anlæg har en "millionær knap" som er en override for (automatiske) beskyttelsessystemer. Et eksempel kan være oliealarm i skibsmotorer. De vil brænde mere eller mindre sammen uden smøreolie. Men der er jo situationer, f.eks. ved havnemanøvre eller undvigemanøvre, hvor et motorhavari er det mindst onde.

Mon der findes en "du må ikke slukke"-alarm / -blokering på e.g. vigtige it-systemer, eller livsvigtigt hospitalsudstyr ?

Hvem har konkret viden og kan forklare ?

6
21. september 2020 kl. 10:13

Hvis vi tænker tilbage på pre-covid-19 tiden, så var sundhed.dk (hjemmesiden) nok ikke så vigtig som i dag

Måske ikke, jeg tror at private læger bruger sundhed.dk ifm. konsultation for egne patienter: se laboratoriesvar, se røntgenbilleder, se medicinlister/recepter, journal fra sygehus osv.

Jeg har også set hospitalslæger slå op i sundhed.dk

Det tyder jo på det er et vigtigt værktøj for sundhedspersonalet, også før CoViD.

5
21. september 2020 kl. 09:43

a det var også det første jeg tænkte, store og vigtige systemer bør have et failover-system placeret et andet sted, hvortil al Storage synkroniseres.

Grundlæggende enig.

Hvis vi tænker tilbage på pre-covid-19 tiden, så var sundhed.dk (hjemmesiden) nok ikke så vigtig som i dag, hvilket kan forklare at Sundhed.dk (virksomheden) er blevet ledt hen til at man ikke havde behov for meget høj tilgængelighed/kapacitet.

Failover systemer er typisk mere komplekse og kræver mere af de folk der skal drifte dem. Hvilket kan føre til mindre tilgængelighed, hvis man ikke er agtpågivende.

4
21. september 2020 kl. 08:41

Single point of failure - efter det oplyste. Burde den slags systemer ikke være "fail safe" (i form af et [eller flere] mirror sites)

Ja det var også det første jeg tænkte, store og vigtige systemer bør have et failover-system placeret et andet sted, hvortil al Storage synkroniseres.

Det virker i hvert fald uprofessionelt at man trækker strømmen uden at opdage at ledninger løber over til naboskabet. Det er jo ikke lamper hjemme i stuen man tager strømmen til.

3
21. september 2020 kl. 08:27

Så hvem er egentlig overrasket? Jeg kan komme i tanke om 2 tidligere incidents som ligner meget. Det er en del af virksomhedens dna at køre på den måde...

2
21. september 2020 kl. 07:39

Burde den slags systemer ikke være "fail safe" (i form af et [eller flere] mirror sites) bygning

Kun hvis kunden betaler for det... Det kunne være interessant at vide om det er tilfældet.

i gang med at sikre sig, at man har de rigtige aftaler med de rigtige leverandører.

kunne godt tyde på at det ikke var tilfældet?

1
21. september 2020 kl. 06:13

»Ingen var vidende om, at der var afhængigheder af strømtilslutninger på tværs af rack-skabe, da nedtagningsbestillingen blev sendt.«

Ingen??? Single point of failure - efter det oplyste. Burde den slags systemer ikke være "fail safe" (i form af et [eller flere] mirror sites) bygning kunne jo for eksempel brænde?

Jamen, jeg spør' bare.