Du har förmodligen inte missat det, men den fjärde oktober hade Facebook, och dess övriga tjänster såsom WhatsApp och Instagram, ett massivt driftavbrott över hela världen som pågick i nästan sex timmar. Det är relativt ovanligt att avbrott pågår under så lång tid, i alla fall med totalt avbrott. Degraderad prestanda lider de flesta tjänster av någon gång men att vara helt bortkopplad från internet under nästan sex timmar är ovanligt. Vad var det då så hände under Facebook-haveriet? Finns det tips för att förebygga driftavbrott av detta slag?
Felkonfiguration av Border Gateway Protocol (BGP)
Baserat på den information som Facebook själva lämnat ut hittills, har det blivit en felkonfiguration i Border Gateway Protocol (BGP). BGP är det protokoll som används för att annonsera prefix man använder för sina tjänster till operatörer, partners och alla som har en router som pratar BGP. Utan BGP, inget internet. Din trafik passerar troligen ett antal operatörer innan den kommer fram till Facebooks datahallar. Exempelvis för mig hemifrån går trafiken genom Telenor till Telia och sedan till Facebooks datahall i Köpenhamn.
Facebook skulle igår uppdatera sin BGP konfiguration men sedan verkar något ha gått väldigt fel. På något sätt lyckades man med att sluta annonsera prefixen 185.89.218.0/23 och 129.134.30.0/23. Att sluta annonsera två stycken /23 prefix låter kanske inte så allvarligt men problemet var att Facebooks auktoritativa DNS-servrar står i just dessa prefix… Med andra ord, när dessa prefix försvann, gick det inte längre att kommunicera med Facebooks DNS-servrar, därav Facebook-haveriet.
Facebook-haveriet kan ha berott på DNS
För att kortfattat förklara hur DNS fungerar så brukar klienter ställa sina DNS-förfrågningar till en rekursiv resolver. Det är oftast operatörens DNS-server om man inte konfigurerat en annan DNS-server såsom Googles 8.8.8.8. En rekursiv resolver kan svara tillbaka på din fråga om svaret finns cacheat, annars måste den fråga Root DNS-servrarna, för att sedan fråga .com servrar och slutligen Facebooks DNS servrar. Facebook.com är så klart ett namn som efterfrågas väldigt ofta och finns cacheat i en rekursiv resolver.
Problemet är bara att svar som är cacheade får bara ligga kvar i en viss tid baserat på något som kallas för Time To Live (TTL). Det innebär att efter en relativt kort tid, exempelvis fem minuter, måste rekursiv resolver fråga Facebooks DNS server för att se om svaret fortfarande är aktuellt. Då Facebooks DNS-servrar inte kan svara, kan då inte heller rekursiv resolver svara klienten och den vet då inte vilken IP den ska kommunicera med. Hur stor effekt detta hade är svårt att säga i och med att man slutade annonsera flera prefix men troligen fick det följdfel att man inte kunde kommunicera med sina DNS-servrar. Exempelvis hade Facebooks anställda svårt att utföra arbete då de själva är beroende av dessa servrar.
Tips för att förebygga driftavbrott
Facebook har givetvis mycket kompetenta anställda och många som jobbar med IT, ändå uppstod Facebook-haveriet. Vad kan vi lära oss av detta avbrott av sällan skådad magnitud? Här är några tips på saker du bör tänka på för att förebygga driftavbrott enligt ovan scenario:
- Begränsa din automationsplattform – Facebook har säkerligen mycket avancerade automationssystem. Automation är väldigt kraftfullt och kan spara mycket tid men den påverkar också så kallad ”blast radius”, det vill säga hur många system du kan påverka samtidigt. En människa kan inte logga in i 100-tals routrar samtidigt men det kan en automationsplattform. När du gör förändringar, prova först förändringen på ett mindre antal enheter och utvärdera innan förändringen görs globalt.
- ”Break the glass” rutin – När något går väldigt fel kan du förmodligen inte komma åt dina vanliga system. Hur kommunicerar du med kollegor om er kommunikationsplattform såsom Slack ligger nere? Hur ska du kunna rulla tillbaka förändringen om ditt automationssystem inte längre är nåbart? Hur kommer du ens åt utrustningen när de normala kommunikationsvägarna ligger nere? Det är svårt för att inte säga omöjligt att lösa alla dessa problem men det måste finnas någon form av plan för hur man ska hantera en krissituation. Enligt rapporter tog det under Facebook-haveriet extra lång tid att rulla tillbaka då de hade svårt att komma åt sin utrustning.
- Out of band infrastruktur – Som jag nämnde hade teknikerna svårt att nå sin infrastruktur och därmed också att kunna rulla tillbaka förändringen under Facebook-haveriet. Det är mycket vanligare än du kanske tror. För att komma runt detta behöver man kommunikationsvägar som inte har några beroenden alls till den normala kommunikationsvägen. Exempelvis genom att ha en console server som sitter på en annan operatör och med andra prefix än den vanliga. Förmodligen kommer du inte heller åt dina normala autentiseringssystem så då behöver du också lokalt login eller liknande.
- Din DNS är kritisk – Tiden då vi kommunicerade baserat på IP och inte namn är förhoppningsvis förbi. DNS är kritisk infrastruktur och kräver mycket eftertanke för att skapa hög tillgänglighet. Vad det verkar hade Facebook bara egna DNS-servrar och inte DNS från någon tredje-part. Nu kanske felet med BGP hade gjort att ingen trafik kunde komma fram ändå men man kan också ha fel där DNS-servrar är nere men nätet i övrigt fungerar. För att förebygga driftavbrott bör man ha DNS-servrar någon annanstans än i egen regi så att klienter kan få svar på sina DNS-förfrågningar.
- Utvärdera beroenden – Vilka system är egentligen beroende av nätkommunikation? Jag vågar lova att det är fler än vad du tror. Facebook hade enligt rapporter problem med att komma in i datahallar och byggnader då passerkortssystem var beroende av att kommunicera med tjänster som inte fanns tillgängliga. Hur löser man detta? Det gäller att ha rutiner för hur man kommer runt detta i ett katastrofläge.
- Testa din plan – Det är inte många företag som testar sin beredskapsplan. Självklart kan det vara svårt att motivera att man ska ta ner hela sitt nät för att testa sin beredskapsplan men man vet inte heller om planen fungerar förrän man har prövat den. Använd exempelvis Facebooks incident för att motivera internt för varför ni ska öva oftare och testa er plan. Kanske kan ni inte ta ner alla system men se om ni i alla fall kan testa utvalda delar av planen där man testar av någon komponent åt gången.
Att tillhandahålla globala tjänster är komplext och oavsett hur duktig man är kommer det att bli avbrott. Det enda man kan göra för att förebygga driftavbrott är att lära sig från sina egna misstag, och andras, och försöka att bli lite bättre till nästa gång. Förhoppningsvis fick du med dig några saker att tänka på som du kan förbättra i din egen infrastruktur. Jag kan också tipsa om att använda Thousand Eyes från Cisco för att få bättre insyn i driftavbrott som dessa och att kunna mäta prestanda mot tjänster som ni använder.
Hör av er om ni är intresserade!
