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

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.

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?

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.

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.

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.

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.

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.

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.

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 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.

Beklager, det havde jeg ikke lige fattet. Jeg ved intet om hvordan man f.eks. sikrer en respirator på et hospital

Hvis en respirator eller lignende står af, vil der jo være læger/sygeplejersker eller andet personale i nærheden, som vil kunne se om apparaterne er gået i stykker.

Tilsyneladende bruger man på et datacenter som DXCs ikke at vandre ned i maskinstuen og inspicere de berørte racks.

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)

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)?

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)?

Altså man kan jo være blevet udsat for smitte siden den første test.

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?)

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.

De fleste for gentaget den samme test igen og igen til hvad nytte ?

Det er jeg som gammel it-konsulent og stærkstrømsingeniør fuldstændig klar over

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.

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.

@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" ?

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

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 ?

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.

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.

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.

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...

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.

»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.