Sommaren 2019 är en svår tid för internet, där systemiska avbrott ofta uppstår och successivt snabbt.
Vissa av dessa avbrott orsakas av interna fel, andra är externa, men två huvudsakliga orsaker uppstår: större nätverkskomplexitet och frekvens och frekvens av kodändringar. 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 växer alltmer samman och är beroende av varandra.
Huvudstopp är:
- Den 2 juni upplevde Google en blackout som företaget anklagade för “den höga nivån på nätverksdensitet i östra USA”. Några av de mest populära tjänsterna, inklusive Sök, Nest, YouTube och Gmail, stannade. Inte så länge efter gick Google Kalender ner, vilket skämtigt gav många slutanvändare en anledning att förklara en ledig dag.
- Cloudflare föll den 24 juni på grund av en liten nätläcka, vilket påverkade domäner som är beroende av detta ledande nätverk för leverans av innehåll (CDN). Slutanvändare är inlåsta från populära tjänster inklusive Discord, Google, Amazon och andra.
- Den 3 juli drabbades båda av Google och Cloudflare av ytterligare blackouts.
- Även den 3 juli hade Facebook problem med att ladda bilder, videor och annan data över alla större applikationer och tjänster, inklusive Instagram, WhatsApp och Messenger. Facebook skyller detta på “fel som utlöses under rutinmässigt underhåll.”
- Apple gick med i klubben en dag senare med ett tre timmars molnstopp som drabbade App Store, Apple Music och Apple TELEVISION.
- Slutligen, den 11 juli, upplevde Twitter en timmes blackout av webb- och mobilapplikationer, vilket resulterade från vad företaget kallade “interna systemändringar”.
Du kan inte förhindra sådana avbrott, men du kan bättre skydda din organisation från oväntade osäkerheter genom att fokusera på dessa fem kategorier:
Var uppmärksam på störningar i så många geografiska områden som möjligt och ur så många nätverk som möjligt: Huruvida dina olika slutanvändarsegment kan komma åt din webbplats eller tjänst beror på den långa kedjan med element som påverkar prestanda som står mellan dem och ditt datacenter. Detta inkluderar CDN, moln, regionala och lokala internetleverantörer, mobilnät och mer.
Eftersom det första steget som är förberett för / svar på ett strömavbrott är att upptäcka det proaktivt, är detta nästan omöjligt om du bara testar tillgänglighet nationellt eller i begränsad geografi. Detsamma gäller om du bara spårar från ett litet antal nätverksplatser, till exempel molnet eller en handfull ISP: er eller mobiloperatörer. En sådan snäv inställning kommer att ge dig betydande blinda fläckar. Ett bredare sortiment ger dig förhandsmeddelande om fler avbrott och ger en bättre möjlighet att införa en säkerhetskopieringsplan, om sådan finns, eller att proaktivt kommunicera med drabbade slutanvändare och låta dem veta att du tar upp problemet.
Minskar den genomsnittliga tiden att upptäcka och betyder tiden att förbättra: Även om meddelanden om tidig upptäckt och blackout är användbara, kommer slutanvändarens goodwill endast att hålla så länge. Det räcker inte bara för att veta att en incident inträffar; Du måste också ta reda på vad som orsakade det och snabbt. I vissa fall är problemet något i din brandvägg som du kan fixa. I andra fall kommer felet att vara något utanför din direkta kontroll, till exempel molntjänster, CDN eller nätoperatörer.
Även om problemet är något som du inte direkt kan övervinna är denna kunskap makt – eftersom det betyder att du inte skickar ditt IT Ops-team och SRE-tillförlitlighetsteknik (SRE) till bortkastade timmar av krig, vilket orsakar alert trötthet. , trötthet och tidsförlust där de proaktivt kan fokusera på att öka tillgängligheten på lång sikt.
Aktivera BGP-ruttspårning – Internet är i princip en krets som skickar signaler och datapaket över olika nätverkslinjer. Flera protokoll hanterar detta dataflöde, varav ett är Border Gateway-protokollet, eller BGP. BGP reglerar hur data överförs mellan olika autonoma nätverksenheter. Internet förlitar sig på att det fungerar, men växande fel kan uppstå på grund av piratkopiering, felkonfigurationspolicy, ruttflikar och problem med peering. Det kan leda till att paket skickas av misstag till fel destination eller upphör helt.
Ett konkret exempel på en BGP-läcka involverade Google i november förra året. När det gäller “stöldinternet”, riktas Googles servicetrafik från olika länder och webbplatser till IP-adresser som tillhör utländska internetleverantörer inklusive TransTelekom Ryssland och China Telecom, snarare än till Googles servrar. Detta resulterar i att paket skickas till olika oönskade destinationer innan de avslutas eller döljs.
De första rapporterna från händelsen tyder på att detta kan vara en farlig BGP-hacking, med tanke på att de berörda länderna har en historia av internetcensur. Emellertid upptäcktes det senare att fel omdirigeringar faktiskt var resultatet av mänskliga misstag; i det här fallet, se på felkonfigurationen mellan Google och MainOne, den nigerianska ISP, som Google har inrättat för att bättre stödja Nigerias växande närvaro.
I takt med att nätverksbyggandet fortsätter snabbt kan sådana BGP-olyckor bli vanligare. Även om du kanske inte kan göra mycket åt en incident när det påverkar externa leverantörer, kan du närmare spåra BGP-läckor i din egen leveranskedja för applikationer, för att möjliggöra snabbare identifiering, utesluta vissa orsaker och fortsätta att reparera.
Automatiska tester är tidiga och ofta: Det är aldrig en bra idé att köra ny kod direkt på ett produktionssystem. Men i bråttom att släppa koden händer det ofta, vilket leder till problem. Google gör tiotusentals nya koddistributioner varje 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 och kodning och vem som bär ansvaret för att bibehålla systemtillgänglighet inför nästan konstant programvaruförändringar – rapporterade nyligen att händelsehantering är en stor del av deras arbete. Under undersökningen konstaterade nästan hälften av de tillfrågade att de hade arbetat med servicehändelser under den senaste veckan.
Med en programstartfrekvens som inte förväntas avta inom en nära framtid måste organisationer bli mer skickliga när det gäller att balansera hastighet och kvalitet. Förbättrad automatisering av funktionell mjukvarutestning, som genomförs i den tidigaste fasen av utvecklingscykeln, är mycket viktig för detta, liksom omfattande regressionstestning och rollbackfunktioner.
Mät tredje parter och håll dem ansvariga: Tredje parter, allt från mjukvarukomponenter integrerade i din webbplats till extern infrastruktur som moln och CDN, kan ha stor inverkan på tillgängligheten till din webbplats. Varje organisation som förlitar sig på externa tredje parter måste alltid övervaka dem för att säkerställa sin egen tillgänglighet.
När det gäller molnet specifikt måste företag undvika att lägga alla sina ägg (data och applikationer) i en korg (en enda leverantör av molntjänster). Implementering av en multicloud-strategi som en form av säkerhetskopiering och skydd kan innebära betydande tid och ansträngning, inklusive att testa en failover-strategi i förväg och säkerställa snabb och pålitlig moln-till-moln-interaktion (stöder replikering). Detta är faktiskt ett bra användningsfall där övervakning från en enda synvinkel från olika moln är lämplig; men som nämnts ovan bör övervakning av molnet dock inte användas för att mäta verklig slutanvändarupplevelse fullständigt.
Slutsats: På senare tid har blackouts förstärkt det faktum att internet liknar ett korthus, och det är nästan omöjligt att undvika en stor blackout och dess effekter. När nätet växer mer samman, kommer möjligheten att oplanerad driftstopp påverkar ditt företag bara att växa. Lyckligtvis finns det åtgärder som företag kan vidta 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 ett måste. Om det kan hända att det gillar Google, Facebook och Apple kan det – och kommer definitivt – hända dig.
Bildkredit: pathdoc / Shutterstock
Mehdi Daoudi är grundaren och VD för Catchpoint, ett ledande företag för digital erfarenhetsinformation. Hans team har expertis i att designa, bygga, driva, skala och övervaka mycket transaktionella internettjänster som används av tusentals företag som påverkar upplevelsen hos miljoner användare. Innan Catchpoint tillbringade Mehdi 10+ år på DoubleClick och Google, där han var ansvarig för servicekvalitet, köpa, bygga, distribuera och använda övervakningslösningar för att övervaka infrastrukturen som skickar miljarder transaktioner varje dag.
