Routing-fejl sendte Nem-login til tælling i 17 timer: Borgere kunne ikke få corona-svar

Hvis du har rettet noget for ganske nylig, og tingene holder op med at fungere, så undersøg om din rettelse kan være årsagen

Med et fint ord kan man kalde det regressionstest: virker funktionaliteten før ændring, så skal det også virke efter ændring.

Nu ved jeg ikke meget om routing, men det undrer mig at man ikke har testet om produktionssystemet virker som forventet efter ændring.

De fleste fejl tager 10 minutter at rette. Men det kan godt tage 17 timer at finde fejlen, vurdere hvad der går i stykker, når man ruller tilbage, og finde en eller anden leder der får løn for at skrive under på, at det er en okay beslutning.

Især når det er to forskellige organisationer. Hvis organisation 1 bestiller en ændring, organisation 2 udfører ændringen ukritisk (for det har organisation 1 nok styr på, og de har i øvrigt været ret insisterende på at ændringen hastede fordi de er kommet bagud med bestillingerne), og en hel anden del af organisation 1 så bliver ramt af fejl - så er det nok ikke så nemt længere.

Fidusen ved en officiel IT-Havarikommission er at alle i branche er forpligtet til at tage stilling til rapporten og vurdere hvilke tiltag de skal tage i deres organisationer for at undgå gentagelser.</p>
<p>

Yep , og det ville være nemt bare at sende den interne ud og så komme videre

Kunne man ikke have rullet ændringen tilbage hurtigere og derved undgået 17 timers nedetid? 17 timer er lang tid. Hvis man har en klar proces for at rulle ændringen tilbage, burde et så kritisk system vel ikke være nede så længe?

Hvis netværket er blevet uoverskueligt, er det så ikke en designfejl. Der er måske råd til en lille internetforbindelse og IP til testformål med de budgetter der arbejdes med. Det kunne give mere awarness, om hvad der arbejdes med

Når der er en person der rykker stikket ud til det rackskab hvor sundhed.dk køre, eller router produktions IP'er ud i det blå, mangler der så produktviden, omhu og samvittighedsfuldhed. Altså lige præcist det der ikke kan købes i Indien.

De har formodentelig allerede en intern AAR som de bare ikke viser til andre end dem som betalere regningen direkte

Fidusen ved en officiel IT-Havarikommission er at alle i branche er forpligtet til at tage stilling til rapporten og vurdere hvilke tiltag de skal tage i deres organisationer for at undgå gentagelser.

Idag sidder resten af branchen bare og ryster på hovedet af Nets uden selv at blive klogere.

Jeg tror ikke der mangler flere process/projekt/change managere, blot nogle basale kompetencer. At kende formålet er en forudsætning for at løse opgaven, alt andet er held. Når man kender målet, er det så ikke naturligt at teste om det er nået?

Når der er en person der rykker stikket ud til det rackskab hvor sundhed.dk køre, eller router produktions IP'er ud i det blå, mangler der så produktviden, omhu og samvittighedsfuldhed. Altså lige præcist det der ikke kan købes i Indien.

De har formodentelig allerede en intern AAR som de bare ikke viser til andre end dem som betalere regningen direkte

Her lyder det som den banale grundregel: Hvis du har rettet noget for ganske nylig, og tingene holder op med at fungere, så undersøg om din rettelse kan være årsagen (og begynd at svede).

Af og til er det ikke ens nyeste rettelse, men så har man da afkræftet dét.

Her havde det været rigtig godt med en IT-havarikommision som udgav en rapport hvis anbefalinger for alle praktiske formål ville blive obligatoriske fremover.

Tja. Får man først introduceret assymetrisk routning i et større netværk kan det godt være svært at finde ud af hvor fejlen ligger, og hvis man så har problemer i kommunikationen mellem leverandører så ingen reelt ved hvad den anden part laver og forventer. så går tiden.

Og uden at vide det i dette tilfælde, men hvis man så også benytter en outsourcing leverandør i asien, så går tiden bare, og så er 17 timer ikke engang lang tid.

Og er der noget en Firewall som regel ikke kan lide, så er det netop assymetrisk routning.

Trist at alle nedbrudene blot er unødvendige begynderfejl, manglende styr på configuration og change. Man kan også undre sig at det tager 17 timer at opdage en fejl som man lige har lavet, ved personen ikke hvad det er der rodes ved? Men det er måske gået tabt i oversættelsen.