Vad “Summer of Outages” visade oss och vad vi kan göra åt det

0 Shares

Sommaren 2019 var grov för internet, med systemavbrott inträffade ofta och i snabb följd.

Några av dessa avbrott orsakades av interna fel, andra externa, men två tvingande orsaker uppstod: större nätverkskomplexitet och frekvens och takt för kodändring. Sammantaget fungerar dessa avbrott som en smärtsam påminnelse om hur ömtåligt internet är, särskilt när nätverk och tjänster blir alltmer sammankopplade och medberoende.

De viktigaste avbrotten var:

Den 2 juni upplevde Google avbrott som företaget skyllde på “höga nivåer av trängsel i nätet i östra USA”. Flera av de mest populära tjänsterna, inklusive Sök, Nest, YouTube och Gmail, stoppades. Inte långt efter gick Google Kalender ner och skämtade och gav många slutanvändare en ursäkt för att förklara en ledig dag. Cloudflare gick ned den 24 juni på grund av en mindre nätverksläcka, vilket påverkade domäner som förlitar sig på detta ledande innehållsleveransnätverk (CDN). Slutanvändare låstes utanför populära tjänster inklusive Discord, Google, Amazon och mer. Den 3 juli drabbades både Google och Cloudflare av ytterligare avbrott. Även den 3 juli hade Facebook problem med att ladda bilder, videor och annan data över viktiga appar och tjänster, inklusive Instagram, WhatsApp och Messenger. Facebook skyllde detta på “ett fel utlöst under en rutinmässig underhållsoperation.” Apple gick med i klubben en dag senare, med ett omfattande tre timmars molnavbrott som påverkade App Store, Apple Music och Apple TV. Slutligen, den 11 juli, upplevde Twitter ett timmes långt avbrott i webb- och mobilappar, vilket berodde på vad företaget kallade “en intern systemändring”.

Du kan inte förhindra att sådana avbrott händer, men du kan bättre isolera din organisation från sådan vild oförutsägbarhet genom att fokusera på dessa fem kategorier:

Håll utkik efter avbrott i så många geografiska områden och från så många nätverksperspektiv som möjligt: Huruvida dina olika slutanvändarsegment kan komma åt en webbplats eller tjänst beror på att en lång kedja av prestandapåverkande element står mellan dem och ditt datacenter. Detta inkluderar CDN: er, molnet, regionala och lokala internetleverantörer, mobilnätverk och mer.

Eftersom det första steget i att vara förberedd för / svara på ett avbrott är att proaktivt upptäcka det kommer det att vara nästan omöjligt om du bara testar tillgänglighet nationellt eller i begränsade geografiska områden. Detsamma gäller om du bara spårar från ett litet antal nätverksutsikter, som molnet eller en handfull ISP eller mobiloperatörer. Ett sådant smalt tillvägagångssätt kommer att ge dig betydande blinda fläckar. En bredare räckvidd ger dig förvarning om fler avbrott och ger en bättre möjlighet att sätta in reservplaner, om de är tillgängliga, eller att kommunicera proaktivt med påverkade slutanvändare och låta dem veta att du arbetar med problemet.

Minska medeltiden att upptäcka och medeltiden att reparera: Medan tidig upptäckt och avisering av ett avbrott är användbart, kommer slutanvändarens goodwill bara att vara så länge. Det räcker inte att helt enkelt veta att en händelse händer; du måste också ta reda på vad som orsakar det och snabbt. I vissa fall kommer problemet att vara något inom din egen brandvägg som du kan åtgärda. I andra fall kommer det felaktiga att vara något utanför din direkta kontroll, som en molntjänst, CDN eller operatörsnätverk.

Även om problemet är något du inte direkt kan ta itu med, är denna kunskap makt – för det betyder att du inte skickar dina IT Ops-team och webbplatsens pålitlighetstekniker (SRE) till bortkastade timmar av krigsrum, vilket leder till trötthet i varningen , utbrändhet och förlorad tid där de proaktivt kunde fokuseras på att förbättra tillgängligheten på lång sikt.

Aktivera BGP-ruttspårning – Internet är i grunden en krets som vidarebefordrar datasignaler och paket över olika nätverksvägar. Flera protokoll hanterar detta dataflöde, varav ett är Border Gateway Protocol eller BGP. BGP styr hur data överförs mellan olika autonoma nätverksenheter. Internet förlitar sig på att det ska fungera, men missförstånd kan uppstå på grund av kapningar, felaktiga konfigurationer, ruttflikar och peeringproblem. Detta kan leda till att paket oavsiktligt skickas till fel destination eller helt upphör att gälla.

Ett synligt exempel på en BGP-läcka involverade Google i november förra året. I fallet med “grand theft internet” riktades Googles trafik från olika länder och webbplatser till IP-adresser som tillhör utländska Internetleverantörer inklusive TransTelekom Ryssland och China Telecom, istället för till Googles servrar. Detta resulterade i att paketen skickades till olika oavsiktliga destinationer innan de avslutades eller svarta hål.

De första rapporterna om händelsen tyder på att detta kan ha varit ett skadligt BGP-hack, med tanke på att de inblandade länderna har historier om internetcensur. Senare upptäcktes dock att felaktiga omdirigeringar faktiskt var resultatet av mänskliga fel; i detta fall peering felkonfigurationer mellan Google och MainOne, en nigeriansk ISP, som Google hade etablerat för att bättre stödja sin växande nigerianska närvaro.

När nätverksutbyggnader fortsätter i snabb takt kan sådana BGP-olyckor bli vanligare. Även om du kanske inte kan göra mycket åt en incident när den påverkar en extern leverantör, kan du närmare spåra BGP-läckor i din egen applikationskedja, för att möjliggöra snabbare identifiering, utesluta vissa orsaker och gå vidare till sanering.

Automatisera testning tidigt och ofta: Det är aldrig en bra idé att köra ny kod direkt i ett produktionssystem. Men i brådskan att släppa kod händer detta ofta, vilket leder till problem. Google bedriver tiotusentals nya koddistributioner per dag till tusentals tjänster, varav sju har mer än en miljard användare över hela världen.

Inte överraskande – SRE, som har expertis inom IT-ops och kodning och som bär ansvaret för att upprätthålla systemtillgängligheten inför nästan konstant programvaruändring – rapporterade nyligen att incidenthantering är en stor del av deras jobb. Vid tidpunkten för undersökningen noterade nästan hälften av de tillfrågade att de hade arbetat med en serviceincident under den senaste veckan.

Eftersom hastigheten på utbyggnaden av programvara inte förväntas sakta ner snart, måste organisationer bli mer skickliga på att balansera hastighet och kvalitet. Ökad automatisering av funktionell programvarutestning, utförd i tidigast möjliga faser av utvecklingscykeln, är avgörande för detta, liksom omfattande regressionstestning och återställningskapacitet.

Mät tredje part och håll dem ansvariga: Tredje part, allt från mjukvarukomponenter integrerade på din webbplats till extern infrastruktur som moln och CDN, kan ha en enorm inverkan på din webbplats tillgänglighet. Varje organisation som förlitar sig på externa tredje parter måste hålla ett öga på dem för att säkerställa deras egen tillgänglighet.

När det gäller molnet specifikt bör företag undvika att lägga alla sina ägg (data och appar) i en korg (en enda molntjänstleverantör). Implementering av en multicloud-strategi som en form av säkerhetskopiering och skydd kan innebära en hel del tid och ansträngning, inklusive att testa failover-strategier i förväg och se till att moln-till-moln-interaktioner (stöd för replikering) är snabba och tillförlitliga. Detta är faktiskt ett bra användningsfall där övervakning från de enskilda utsiktspunkterna för olika moln är lämplig; som nämnts ovan bör dock övervakning av molnet aldrig användas för att heltäckande mäta verkliga slutanvändarupplevelser.

Slutsats: Den senaste tidens strömavbrott har förstärkt det faktum att internet är mycket som ett korthus, och det är praktiskt taget omöjligt att undvika större avbrott och deras kaskadeffekt. När webben blir mer sammankopplad kommer sannolikheten för oplanerad stillestånd som påverkar ditt företag bara att öka. Lyckligtvis finns det åtgärder som företag kan ta för att bättre förutse och svara på dessa händelser. Det kan vara svårt att höra, men planering för misslyckande är en nödvändighet. Om det kan hända med sådana som Google, Facebook och Apple kan det – och det kommer oundvikligen att – hända dig.

Bildkredit: pathdoc / Shutterstock

Mehdi Daoudi är medgrundare och VD för Catchpoint, ett ledande företag för digital erfarenhetsinformation. Hans team har expertis inom design, byggande, drift, skalning och övervakning av mycket transaktionella internettjänster som används av tusentals företag som påverkar miljontals användares upplevelse. Innan Catchpoint tillbringade Mehdi 10+ år på DoubleClick och Google, där han var ansvarig för kvaliteten på tjänsterna, köpte, byggde, distribuerade och använde övervakningslösningar för att hålla ett öga på en infrastruktur som levererade miljarder transaktioner dagligen.

0 Shares