I sidste uge blev vi beklageligvis ramt af lange svartider i e-conomic. Intet er vigtigere for os end oppetid og datasikkerhed. Vi blev altså ramt på vores kernegrundlag. Derfor iværksatte vi vores beredskabsplan for situationer som denne. Den indebærer at:

  • Alle interne ressourcer flyttes fra andre opgaver og over til afhjælpning.
  • Sagen eskaleres til og med vores hosting-partner, som ligeledes har en beredskabsplan, der iværksættes.
  • Hardware- og softwareleverandører aktiveres i forbindelse med fejlsøgning.
  • Eksterne eksperter/konsulenter hentes ind.

Al fokus blev således øjeblikkeligt vendt mod at normalisere driften og at få e-conomic til at køre med normal hastighed igen.

Det ovenstående beskriver den tekniske beredskabsplan. Men ligeså vigtig er at informere vores kunder – dig – om det passerede, og hvornår normal drift kan forventes. Det var sparsomt, hvor meget vi kunne fortælle under forløbet. Derfor lovede vi at vende tilbage med en nærmere redegørelse, og det gør vi her.

 

Har vi fået for mange kunder?

Nej. Mange stillede spørgsmålet om den nedsatte hastighed skyldtes, at vi har fået for mange kunder, eller at der er for mange, der arbejder i e-conomic samtidig. Vi vil gerne slå fast, at det ikke er antallet af kunder, der har gjort, at vi er løbet ind i den nedsatte hastighed.

Vi har en ambition om, at vi skal nå at få 100.000 virksomheder som brugere ved udgangen af 2013. Og det er vores systemer bygget til at kunne håndtere.

Desværre blev den nedsatte hastighed først mærkbar, da der kom flere brugere på systemet. Med andre ord, hastigheden bliver først ramt ved mange samtidige brugere. Så det fremstod som om, det var antallet af brugere, der var årsagen.

Det vidste vi dog selv med det samme, ikke var tilfældet. En uheldig bivirkning ved dette er, at vi først med sikkerhed kunne afgøre om hastigheden var normaliseret, når der kom mange brugere på.

 

Har jeres regnskabsdata været i fare?

Nej, jeres regnskabsdata har på intet tidspunkt været i fare. Der tages backup af alle data hver 15. minut, og vi opbevarer data i to spejlede datacentre på forskellige geografiske adresser.

 

Hvad skete der egentlig?

Der var faktisk tre årsager til den ustabile drift.

1)

Der er to hovedindgange fra internettet til og fra vores hosting-leverandør. Lige op til momsrapporteringsfristen forsvandt den ene hovedindgang i ca. 5 minutter. Det ramte primært ikke-TDC-kunder. Derfor oplevede nogle, at de ikke kunne få forbindelse til e-conomic.

 

2)

I samme momsperiode konstaterede vi nedsat hastighed i e-conomic. Det kom som en overraskelse, eftersom der var færre kunder online og flere servere sat ind i driften, end under sidste momsperiode.

Efter at have fejlsøgt i en længere periode og smidt flere servere online til at håndtere presset, opdagede vi, at belastningen på vores databaseserver lå langt over, hvad der burde kunne lade sig gøre med vores nuværende mængde kunder.

Vi kastede os med det samme over at finde årsagen til den voldsomme belastning.

Da dette ikke er eksakt videnskab, er der et element af at forsøge sig frem. Der opstilles en række mulige årsager, og der undersøges i prioriteret rækkefølge. Den første, vi forsøgte, var optimering af database og relevant kode i den forbindelse. Det hjalp ikke.

Det næste skridt var at rulle seneste markedspakke tilbage. Det gjorde ingen forskel, da der kom mange brugere på. Herefter forsøgte vi at rulle endnu en markedspakke af systemet. Igen uden at det gjorde en forskel.

Så forsøgte vi at lukke ned for enkeltfunktioner i e-conomic. Vi satte en håndfuld apps på pause for at se, om det gjorde en forskel. Det havde heller ingen effekt.

Vi lavede efterfølgende en kontrolleret database-failover. Dvs. vi smed alle kunder over på vores reserve-databaseserver. Og det virkede. Hastigheden normaliserede sig øjeblikkeligt.

Det ærgrede os, at det var det sidste, vi forsøgte os med, der endte med at løse hastighedsnedsættelsen. Men sådan er det jo altid i den slags situationer. Det er altid sidste sted, man leder, at man finder sine nøgler. Og ofte er det ikke det første sted, man leder.

Det at skifte databaseserver er en relativt drastisk procedure at foretage alene på baggrund af en formodning om, at det kan hjælpe. Skulle det vise sig, at det ikke var databaseserveren, den var gal med, kunne det have gjort situationen værre. Så også af den grund var det ikke det første, vi forsøgte.

 

3)

Da vi så havde fået den nye databaseserver kørt i stilling åndede vi lettet op. Der var grønne lamper over hele linjen, e-conomic kørte som normalt, og telefonerne stoppede med at ringe.

Men som bekendt kommer en ulykke sjældent alene, og der gik ikke længere end halvanden time, før noget gik galt hos vores hosting-udbyder. Når den slags sker, skifter systemet automatisk til et andet datacenter, der ligger et andet sted i landet. Det betød, at e-conomic var utilgængeligt i 3 gange 3 minutter over en 20 minutters periode, indtil skiftet var foretaget og alt var tilbage i drift.

Det fulde tekniske forløb og yderligere information findes på Tech-talk bloggen (på engelsk).

 

Det har vi lært

Man kan roligt sige, at vi har fået afprøvet vores beredskabsplan. Som en del af beredskabsplanen har vi foretaget grundig evaluering af hændelsen. Visse ting er allerede ændret.

Vi har arbejdet og fortsætter med at implementere både tekniske, organisatoriske og kommunikationsmæssige forbedringer.

 

Teknik

Bedre overvågning:

Den overvågning vi har af e-conomics driftsstatus bliver forbedret, så vi hurtigere kan identificere, hvad der kan udvikle sig til at skabe problemer.

Hele den hele den tekniske opbygning af e-conomic er blevet, og bliver stadigvæk, gået efter i sømmene for at vi kan mindske risikoen for at noget lignende vil ske i fremtiden.

 

Ikke trykke ”OK” flere gange:

Vi opdagede under perioden med nedsat hastighed, at det var muligt at klikke flere gange på en knap i e-conomic. Hvis man f.eks. klikker på en ”OK” knap, så kan man godt være fristet til at klikke igen, hvis ikke der sker noget inden for et par sekunder.

Men hver gang der klikkes, sendes der en ny forespørgsel af sted, der skal behandles af e-conomic. Det betød, at der under forløbet, hvor e-conomic kørte langsomt, blev sendt to eller tre gange så mange forespørgsler af sted fra folk, der klikkede flere gange. Det gjorde e-conomic endnu langsommere, og det er en uhensigtsmæssighed, som vi får løst nu og allerede delvist har implementeret.

 

Vedrørende den tredje hændelse, altså skift af datacenter, så er det dog positivt, at systemet opførte sig som tiltænkt. Når et datacenter falder ud, skiftes der automatisk til et andet datacenter for at retablere driften. At det skulle ske uvarslet midt på dagen og efter ustabil drift, er vi sikre på, at både I og vi gerne havde været foruden.

 

Kommunikation

Vi bilder os ind at vi er åbne, transparente og ærlige overfor vores kunder – dig. Selvom nedsat hastighed i det omfang, vi for nyligt har oplevet, er et budskab, som vi helst vil undgå at kommunikere, skal vi sørge for, at budskabet kommer ud.

Vi opdaterede om driften på loginsiden, på bloggen, pop-up i e-conomic, Facebook og Twitter. Vi forsøgte at opdatere jer, så snart vi fik ny viden om situationen.

I perioden åbnede vi vores telefoner og chat tidligere og lukkede dem senere end normalt, og den uddannelsesdag, vi havde planlagt for vores telefonsupportere den 23. august, blev aflyst, så vi i stedet kunne holde telefonerne åbne.

Al anden planlagt kommunikation blev sat på standby, indtil vi havde dette blogindlæg klar.

 

Igen – undskyld og tak for jeres forståelse

Der er ingen tvivl om, at vi allerhelst ville have undgået at udsætte jer for nedsat hastighed og driftsforstyrrelser. Det er en virkelig dårlig forretningsstrategi at gøre sine kunder sure og frustrerede.

Men på trods af de forståelige frustrationer ved at e-conomic kørte langsomt, fik vi også en masse positive tilkendegivelser og opmuntrende kommentarer.

Til alle jer der kom med opmuntrende kommentarer: I ved ikke hvor meget det varmer, og hvor meget det løfter moralen på et tidspunkt, hvor der var allermest brug for det. Tusind tak for det.