Under förmiddagen den 12 februari 2020 uppstod en större driftstörning till följd av ett nätverksfel. Felet påverkade alla våra tjänster och servrar inklusive vår telefonväxel.
Först och främst vill vi ta tillfället att beklaga problemen och hur de påverkar dig som kund. Vi vet att du litar på oss för att hålla din webbplats och dina tjänster online.
Igår levde vi inte upp till dina förväntningar på oss. Det ber vi om ursäkt för.
Är den här rapporten för teknisk? Vi har även samlat övergripande information och vanliga frågor för dig som inte är tekniskt intresserad.
Innehållsförteckning
- Översikt
- Om nätverksproblemet som drabbade alla kunder
- Om följdproblemet som drabbade Managed Server-kunder
- Åtgärder och lärdomar
1. Översikt
Vid ca 10:30 den 12 februari 2020 uppstod ett större nätverksfel som påverkade samtliga av våra tjänster och servrar, inklusive vår egen webbplats, support och telefonväxel.
Vid ca 14:00 fick vi igång nätverket och majoriteten av våra tjänster och servrar kunde återgå till normal drift.
Allt efter tjänsterna började komma tillbaka online upptäckte vi ett följdfel med lagringsklustren för Managed Server. En del fick korrupta databaser vilket krävde manuell handpåläggning för varje server. Vid 17:45 var databasproblemen lösta och hela driftstörningen avhjälpt.
Här nedan kan du läsa mer om de olika problemen samt vad vi gör för att förhindra detta och bli ännu bättre framöver.
2. Om nätverksproblemet som drabbade alla kunder
Problemet med nätverket berodde på bugg i mjukvaran till en av våra switchar i vårt nätverk.
I vårt nätverk använder vi något som kallas för STP (Spanning-tree Protocol). Det används bland annat för att förhindra loopar i nätverk, och för att kunna bygga redundans i form av flera upplänkar mellan till exempel switchar.
Buggen gjorde så att en switch plötsligt utsåg sig själv till STP-root, trots att den inte var det. Med två stycken root i samma nätverk uppstår en loop då resten av switcharna går som tänkt mot den “riktiga” root-switchen.
Loopen medför i sin tur att all trafik går runt mellan switcharna internt. Trafiken når inte fram till servern och inte heller ut på internet. På grund av den intensiva trafiken mellan switcharna som uppstår vid loopen blir de snabbt överbelastade och nätet går ner.
Mer tekniskt beskrivet gjorde det att våra core-routers upplänk mot resten av datacentret ansåg att vi hade fått en nätverksloop någonstans och började blockera VLAN-trafik mot resten av miljön. Samtidigt blockerades och avblockerades VLAN konstant på upplänken vilket skapade en extrem packet loss.
Det här gjorde att vi först misstänkte att problemet låg i våra core-routrar eftersom de konstant skiftade mellan aktiv och passiv. I detta läge försökte vi slå av spanning-tree för core-routrarna. Det här avhjälpte inte problemet, men gjorde att vi kunde utesluta core-routrarna som en del av problemet.
Det här tog relativt lång tid eftersom vi på grund av nätverksfelet inte kunde komma åt vår syslog och konstatera exakt var felet låg (se åtgärd nedan).
Teknikerna på plats i hallen kunde här identifiera loopen och började gå igenom resten av switcharna. Här började vi med de switchar som vi nyligen haft mindre problem med, eller gjort arbete på.
Då kunde vi hitta den felande switchen och starta om den (se vidare åtgärd nedan). Efter omstarten var nätverket uppe i normalt tillstånd, cirka 12:30 och de första av våra tjänster började komma online igen.
Efter att kommunikationen utåt kommit igång igen efter att näverksproblemet var löst såg vi i vår övervakning hur våra webbhotellsservrar och kunders webbplatser på dessa blev åtkomliga igen enligt förväntan.
Samtidigt blev det allt mer uppenbart att inte allt självläkte som det skulle med alla tjänster.
3. Om följdproblemet som drabbade Managed Server-kunder
Våra lagringkluster för Managed Server, webbhotell och Gör det Själv-servrar är separerade för att kunna tillhandahålla optimal lagringsmängd, hastighet och feltolerans.
Problem 1: Tappad anslutning mot lagring
Under nätverksproblemen tappade vissa av virtualiseringnoderna (engelska: Hypervisor) för Managed Server periodvis anslutning mot bakomliggande lagring. Noderna är ansvariga för att utföra slagningar i databasen och visa kunders webbplatser så snabbt som möjligt. Detta innebar att filer inte kunde sparas ordentligt.
När vissa av våra Managed Serverar försökte skriva data fick de då problem med operativsystemet och i vissa fall med databasskrivningar.
Till skillnad från våra webbhotellsservrar som inte fick dessa problem krävdes därför manuell handpåläggning av väldigt många servrar på samma gång.
Många av servrarna där operativsystemet hängde sig på grund av lagringsproblemet kunde vi snabbt få upp igen med hjälp av en omstart. De servrarna som fick problem med databasskrivningar krävde däremot ytterligare handpåläggning.
Problem 2: Ett fåtal korrupta databaser
Databaserna, som i e-handelssammanhang ofta innehåller orderinformation, kunduppgifter och önskelistor, sparas på diskar på samma sätt som vanliga filer.
När servern försöker skriva en ändring till disken men inte lyckas, kan databasen i vissa fall bli korrupt.
Du kan jämföra med att spara någonting till ett USB-minne som du kopplar ur innan allt hunnit sparas. Eller till och med om du rycker ur pappret ur skrivaren innan den skrivit klart. Ungefär på samma sätt blir det med databasen.
Vi hade tur i oturen att mängden servrar som fick problem med korrupta databaser enbart var ett fåtal av våra managed servrar.
Databasproblemen vi såg var möjliga att lösa på två olika sätt:
- Antingen så hade vi kunnat återläsa senaste backupen. På Managed Server sparas en återställningspunkt varje dygn (oftast nattetid). Det hade inneburit att ändringar och därmed bland annat dagens orderinformation för e-handlare hade gått förlorad.
- Alternativt kunde vi få ut så mycket data som möjligt ur de korrupta databaserna och återläsa dessa till en ny databasinstans och därefter reparera eventuella trasiga tabeller. Det här är en manuell process som beroende på databasernas storlek och vad som går att återläsa tar allt mellan 15 och 45 minuter per server.
Vi tog snabbt ett beslut om att alternativ 1 inte var rimligt. Hellre ett lite längre driftstopp än förlust av affärskritisk data. Därför påbörjade vi direkt att fixa de korrupta databaserna så snabbt vi kunde. Här prioriterade vi våra kunder med SLA Pro.
4. Åtgärder och lärdomar
Helst hade vi såklart sett att vi kunde undvika driftstörningar helt. Vi har höga ambitioner för upptid på alla våra tjänster. Under 2019 låg vår upptid på 99,998%. Det betyder ca 2,5 minuters nedtid på en månad. Vårt mål är såklart att du som kund aldrig ska behöva uppleva stora störningar i din tjänst (vår senaste större var 2018-12-04).
Därför arbetar vi systematiskt för att förbättra och uppgradera våra tjänster. Vi investerar mycket i vårt nätverk, lagring och virtualiseringsnoder för att leverera så bra tjänster som möjligt.
En sådan här stor driftstörning är ytterligare ett tillfälle att se över rutiner och analysera vad vi kan göra bättre framöver. Vi tackar också för den feedback med synpunkter och förslag som vi under dagen fick från er kunder, bland annat via Facebook.
Avveckling av den felaktiga switchen
Redan nu har vi plockat bort den felaktiga switchen för att förhindra att samma bugg uppstår igen.
Tätare kommunikation
På vår statussida (mer om den nedan) som ligger på ett externt nätverk kan du alltid få information om aktuella driftstörningar. Så även den här gången.
Under dagen publicerade vi ungefär en uppdatering varje halvtimme samt fanns tillgängliga med personliga svar via sociala medier som på vår Facebook-sida.
Det är en utmaning att både vilja vänta på mer information och resultat av felsökning, och rapportera positiva nyheter, samt att uppdatera oftare. Framöver vill vi försöka att rapportera ännu tätare, även om vi inte har några uppdateringar.
Vid 14:10 publicerade vi en alldeles för positiv prognos över Managed Server eftersom det fortfarande var ett fåtal servrar drabbade av databasproblemet. Uppdateringen om databasproblemet dröjde sedan för länge (15:30). Här borde vi kommunicerat tätare och bättre.
Fallback-webbplats
Det är väldigt ovanligt att alla våra servrar och tjänster går ner samtidigt. När det händer går även vår egen webbplats ner. Vi förstår att det skapar extra oro och väcker frågor, särskilt om du inte känner till vår statussida.
För att förhindra att vår webbplats inte går att nå håller vi på att titta på en extern “fallback”-lösning som vi kan aktivera om något liknande händer igen. På så vis kommer du alltid att kunna nå vår webbplats och få aktuell information.
Extern syslog
Vi kommer under de kommande dagarna att sätta upp en syslog som inte påverkas av nätverksproblem i någon av våra två datahallar. Det hade i det här fallet hjälpt oss att hitta problemet snabbare när vi inte kunde nå nätverket.
Bättre övervakning av nätverket
Med en bättre och tydligare visuell övervakning av nätverket hade vi snabbare kunnat identifiera exakt var problemet låg och även agera snabbare. Det här är ett arbete som vi redan var påbörjat och fortgår.
Bättre statussida
Under driftstoppet visade vår statussida fortfarande “Operational” och grönt på alla tjänster. Detta trots att vi hade ett meddelande om driftstörning. Dessutom visades en text som felaktigt berättade att endast “vissa” tjänster hade problem, trots att alla hade det.
Det är såklart inte acceptabelt att statussidan inte visar fullständigt korrekt information. Vi kommer därför inom den kommande månaden titta på en ny och förbättrad lösning för statusinformation.