Avviksrapport Major Incident 6.12-10.12.

Torsdag natt, den 6.12.2018 kl. 00:50 inntrådte en feilsituasjon i Teknograds nettverk. Vakten vår ble vekket av en kunde kl. 06:20 da det ble meldt inn problemer.

Det ble umiddelbart iverksatt feilsøking av problemet og det ble raskt identifisert at mange av Teknograds kunder var berørt. Dette medførte at incident’en ble oppskalert til en Major Incident, saksnummer INC302539.

Første melding til våre kunder ble sendt pr. SMS kl. 09:43.
Første oppdatering kommer så kl. 11:05 samt driftsmelding blir lagt ut på våre hjemmesider.
Påfølgende oppdateringer kommer så kl. 12:11, 13:08, 14:08, 15:14. Websidene våre ble oppdatert jevnlig utover kvelden og natten.

Feilsøkingen pågår for fullt og alle våre nettverksfolk m.fl. er involvert, etter hvert som kunder rapporterer inn feil blir incidentene relatert til Major Incident saken.

Underveis i feilsøkingen begynner vi å finne symptomer på hva som er galt, men hvorfor dette skjer er ikke umiddelbart klart. Før vi har en mulig logisk forklaring på hva feilen består i ønsker vi ikke å gjøre for mange endringer, for å ikke risikere og forverre situasjonen. Vi sender folk i datasenteret for å følge et spor som kan virke som en mulig feilkilde.

I vårt nettverk har vi noen maskiner som sørger for at datatrafikken går riktige veier, dette er et system som er satt opp fullt redundant, dette betyr at det står to slike maskiner i systemet, hvor en er primær og den andre sekundær, hver kunde har et slikt par med maskiner. Disse kjører som virtuelle maskiner på et dedikert virtualiseringsmiljø.

For at disse maskinen skal fungere så må de kommunisere med hverandre, hovedmaskinen sender beskjeder til sekundærmaskinen med jevne mellomrom, dersom sekundærmaskinen ikke får disse beskjedene er jobben dens å anta at primærsystemet er dødt slik at denne sekundærmaskinen skal ta over primærrollen. Vi finner etter hvert at sekundærmaskinene ikke mottar disse beskjedene og prøver å ta over selv om primærmaskinen er i live og sender disse beskjedene.

Alle disse maskinene snakker på en måte med hverandre i nettverket for å vite hvilken maskin som til enhver tid er primærmaskin. Alt dette styres av noen hovedsystemer via en annen protokoll, det som antakelig skjer er at hovedprotokollen blir ustabil når den nå får så mange motstridende beskjeder fra de kundededikerte primære og sekundære systemene. Dermed spres problemene og gjør vondt verre, dette fører til mange små avbrudd i datatrafikken.

Vi har på dette tidspunktet fortsatt ikke identifisert den underliggende årsaken til at disse pakkene forsvinner og ser etter en midlertidig løsning som kan sørge for at nettverkene holder seg så stabile som mulig. På tross av at virtualiseringsmiljøet virker ok og har nok ressurser kan vi ikke utelukke at dette miljøet er en medvirkende årsak, vi mistenker at vårt eksisterende overvåkingssystem ikke har dyp nok innsikt i dette miljøet og raskt installerer vi produsentens eget overvåkingssystem og starter innhenting av data.

Problemene kommer og går for ulike kunder. Rundt 22-tiden på kvelden innser vi at vi er nødt til å omstarte primærprotokollene på hovedsystemene, dette er noe vi har forsøkt i det lengste å unngå, da det vil medføre midlertidig stopp i all trafikk. Vi innser at vi ikke har noe valg dersom vi skal få stoppet alle de gale beskjedene. Dette blir gjennomført og vi ser at kommunikasjon blir mer stabilt. Systemene oppleves mer stabile, men etter ca. 1 time ser vi en tiltagende ustabilitet, vi gjør ytterligere tiltak, bl.a. stopper vi sekundærsystemene for å forhindre at de sender pakker til hovedsystemene og ting begynner igjen å se lovende ut og det holder seg stabilt. Vi tror vi har klart å midlertidig stabilisere nettverket.

7.12:
Med tanke på foregående dags problemer sjekkes systemene 05:30 og vi har personell på plass fra 06:48. Systemene har holdt seg stabile i løpet av natten, loggene ser fine ut og vi er lettere optimistiske, ny melding blir sendt ut og lagt ut på vår webside kl. 07:34.

Kl. 12:50 endrer dessverre situasjonen seg og noen av de problemer vi opplevde i løpet av torsdagen starter opp igjen, denne gangen forstår vi umiddelbart hva som må gjøres og det tiltaket som ser ut til å fungere best er å omstarte primærmaskinene, sekundærmaskinene er fortsatt avslått. For å holde ustabiliteten så liten som mulig omstarter vi disse så fort vi ser de har problemer. Dette medfører da dessverre korte avbrudd for de kundene vi må omstarte maskinene for.

Det vi så legger merke til er at det er de av våre kunder med den største nettverkstrafikken som først får problemer, feilsøkingen fortsetter for fullt mens vi gjør vårt beste for å holde nettverkene oppe og så stabile som mulig.

Vi begynner å utforske funnet med at det er de største nettverkskundene som blir berørt og i løpet av et statusmøte vi har kl. 15.00 blir det klart at det kan se ut som maskinene som kjører i virtualiseringsmiljøet kan sloss om CPU kapasitet i korte perioder. Vi innser at dette kan være en mulig forklaring på at sekundærmaskinene ikke mottar meldingene, eller ikke rekker å håndtere dem og vi begynner å se på hva vi kan gjøre for å øke kapasiteten i miljøet.

Vi legger også en plan på hvordan vi skal fordele personell slik at vi klarer å ha en kontinuerlig progresjon uten å slite ut medarbeiderne, da vi innser at vi blir nødt til å jobbe gjennom hele helgen for å få gjort det som trengs.

Kortsiktig plan er å flytte servere fra vårt ene datasenter til det andre, slik at vi får opp kapasiteten og forhindrer at CPU’ene sloss om kapasitet.
Ett annet tiltak vi beslutter er å oppgradere de kundededikerte maskinene til siste versjon av programvaren da denne skal være mer effektiv.

Etter regulær arbeidstid den 7.12 begynner ting å oppføre seg mer stabilt, dette understøtter den mistanke vi har fått i at vi har nådd en terskel på hva vårt eksisterende nettverkssystem takler av trafikk og samsvarer med trafikkmønsteret vi observerer.

8.12:
Vi starter lørdagen med å legge en plan for hvordan vi kan eliminere disse problemene, det er to ting som står klart frem, vi trenger å øke kapasiteten i ett datasenter slik at alle primærmaskinene skal ha nok ressurser til enhver tid. Et annet grep er å konfigurere bort sekundærmaskinene, da de nå (mot sin opprinnelige hensikt) er en feilkilde. Testingen på de oppgraderte maskinene viser også at de fungerer på lik måte som tidligere tester og de er mer effektive til å håndtere trafikk. Vi setter i gang to spor, det ene er å fysisk flytte maskiner fra et datasenter til det andre. Vi samler så alle virtuelle maskiner i det som får mest kapasitet. Det andre sporet er å fjerne logikken som styrer primær og sekundærmaskin.

9.12:
I løpet av søndagen blir alle kundededikerte maskiner oppdatert samt at man fortsetter jobben med å forenkle oppsettet, samt at de flyttede serverne blir satt i drift og lasten blir balansert over alle serverne. Dessverre blir det noen kort i brudd i trafikken, da enkelte av disse operasjonene ikke er mulig å gjennomføre uten brudd. Testing blir gjennomført og store datamengder blir kjørt igjennom nettverket uten noen form for avbrudd.

10.12:
Ingen ustabilitet eller nedetid blir observert, det gjenstår noen få maskiner som trenger en konfigurasjonsendring og oppdateringer, dette blir gjennomført kl. 23.05. Vi mener nå at stabil drift er gjenopprettet.

Utestående oppgaver:
Opprette ny type redundans på de kundededikerte systemene i nettverket.

Tiltak for å forhindre tilsvarende i framtiden:
De tiltakene som er gjennomført gir bedre kapasitet og endringen fra primær/sekundær-oppsett vil gjøre at vi unngår en slik spiral med problemer.
Det midlertidige overvåkningssystemet av virtualiseringsmiljøet vil bli vurdert faset inn på permanent basis.

Andre forbedringsområder:
Vår kommunikasjon ut mot våre kunder fungerte greit i begynnelsen, men etter hvert som dagene gikk begynte vi å svikte på dette området. Overlevering av arbeidsoppgaver fra ett team til neste var ikke optimal. Etablerte prosesser ble kun delvis fulgt.

Det er planlagt en gjennomgang av tiltak og forbedringsområder for å oppdatere våre planer, slik at vi kan bli bedre og mer effektive i håndtering av avvikssituasjoner i framtiden.

Vi beklager på det sterkeste de ulemper og problemer dette har forårsaket, dette var en stor og krevende oppgave og vi kan med hånden på hjertet si at vi gjorde alt i vår makt for å rette problemene så raskt som mulig. Men naturen i dette problemet gjorde at det dessverre tok lang tid.