Al snel ondervond een van de vele kritieke componenten van internet een storing op 8 juni waardoor enkele van de meest prominente websites online waren – nou ja, offline. Toen, bijna twee weken later, struikelde Akamai, een van de grootste wereldwijde netwerken voor het leveren van inhoud, ook door online systemen uit te schakelen voor luchtvaartmaatschappijen, banken en beurzen over de hele wereld.
Lessen om te leren van de Fastly- en Akamai-storingen
In het licht van deze recente stroomonderbrekingen is het belangrijk om te onthouden dat mislukkingen zullen gebeuren , maar het essentiële kenmerk van mislukking is de mogelijkheid om te leren. Dus wat kun je leren van deze voorbeelden? Hier zijn vijf lessen die zijn geleerd uit de recente storingen en acties die u kunt ondernemen om ervoor te zorgen dat u een snelle website heeft die een betrouwbare digitale ervaring biedt, zelfs wanneer infrastructuurpartners falen.
Les 1: Alles mislukt uiteindelijk. Zorg voor een back-upplan.
Als jonge ingenieur kreeg ik te horen: "Als je software ontwerpt met de verwachting dat elke afhankelijkheid op een gegeven moment zal mislukken, zul je nooit teleurgesteld zijn, ongeacht de uitkomst."
De recente mislukkingen brengen deze les zeker naar huis, maar we vergeten dat dingen de hele tijd mislukken. Hoewel het toepassingsgebied en de omvang van de Fastly en Akamai uitval trok koppen, de realiteit is dat het internet ervaringen mislukkingen de hele tijd . Zo waren er in de week van 14 – 20 juni 2021: 427 netwerkstoringen, 352 internetproviderstoringen en 23 storingen in de public cloud.
Het is belangrijker dan ooit om het onontkoombare feit van internet te erkennen: alles faalt uiteindelijk. Om deze impact te bestrijden, proberen betrouwbaarheidsingenieurs redundantie te implementeren waar dit financieel en operationeel mogelijk is.
Een online infrastructuur
Wanneer gebruikers toegang krijgen tot een online winkel, vindt er een delicate overdracht plaats tussen meerdere providers van kerninfrastructuur. Laten we dus eerst eens kijken naar de significante infrastructuurniveaus voor toegang tot een online winkel en de mogelijkheden en kosten identificeren om bepaalde niveaus van bescherming tegen overmacht te implementeren. De eerste stap is de Domain Naming Service (DNS).
De Domain Naming Service (DNS)
DNS is verantwoordelijk voor het vertalen van de naam van een website (bijvoorbeeld uw website hier) naar het onderliggende IP-adres (Internet Protocol) (denk bijvoorbeeld aan het IP-nummer als een wereldwijd internettelefoonboek).
DNS wordt gedistribueerd, met 13 kernrootservers die de backbone-database vormen en duizenden exemplaren die wereldwijd worden gerepliceerd voor meerdere geografische locaties. Bovendien heeft elke website een DNS-provider die verantwoordelijk is voor het toewijzen van de naam van een site aan de bestaande IP-waarde.
Aangezien deze waarden in de loop van de tijd kunnen veranderen, implementeren DNS-providers een Time to Live (TTL) voor elke recordupdate om ervoor te zorgen dat de laatste informatie continu wordt bijgewerkt. Als er geen DNS-record voor een website bestaat, wordt de eindgebruiker geconfronteerd met een foutpagina met de melding "Server niet gevonden/webpagina niet beschikbaar". (Er zijn ook veel andere redenen om een foutpagina te "krijgen".)
Voor veel bedrijven wordt DNS-functionaliteit geleverd door één bedrijf, waardoor bedrijven worden blootgesteld aan DNS-zoekfouten als die provider een materiële storing heeft. Het implementeren van redundantie voor DNS kost niet veel, aangezien DNS-services hooguit een paar honderd dollar per jaar kosten, maar er zijn hoge operationele kosten, omdat meerdere providers tegelijkertijd moeten worden bijgewerkt over eventuele backend-wijzigingen.
Zoals gebruikelijk is in de moderne tijd, biedt een groot aantal bedrijven aanbiedingen om dit proces te automatiseren, en het is vaak goed besteed geld.
Het Edge-netwerk / Netwerk voor inhoudsdistributie
Het volgende niveau is het 'edge'-netwerk, vaak een Content Distribution Network (CDN).
Het CDN bevindt zich op deze laag waar onze spraakmakende mislukkingen (Fastly en Akamai) plaatsvonden. CDN's helpen websites sneller te laden door de fysieke afstand tussen uw webserver en de gebruiker te verkleinen. Met CDN's kunnen gebruikers over de hele wereld dezelfde hoogwaardige inhoud bekijken zonder langzame laadtijden, terwijl tegelijkertijd een wereldwijde vloot van servers wordt gebruikt om uw online aanwezigheid te versterken. In tegenstelling tot DNS-redundantie, waar de financiële kosten minimaal zijn, is het implementeren van meerdere redundante CDN's duur.
Om deze reden wordt CDN-redundantie vaak alleen gebruikt door zakelijke klanten en grote eCommerce-merken. In de meeste gevallen wordt de CDN-redundantie geïmplementeerd op de DNS-laag zelf. Voor kleinere bedrijven kan het echter zorgen dat u up-to-date IP-adressen heeft voor uw oorspronkelijke server (uw webhost zelf) als u DNS hebt gescheiden van uw CDN-provider.
Beperking van CDN-storingen
Wanneer CDN's falen, kunnen technici DNS-records bijwerken zodat gebruikers het CDN helemaal kunnen omzeilen. Dit geeft klanten een functionele (maar langzamere) ervaring. Tijdens de Fastly-storing hebben veel bedrijven de impact omzeild door gebruikers eenvoudig om te leiden naar hun webserver of back-up CDN-provider.
De Origin-webserver
Dit is ofwel een gehost contentmanagementsysteem (Magento, WordPress, etc.) of een platform (Shopify, Kinsta, etc.). Dit is de traditionele plaats waar IT redundantiebronnen inzet, waarbij back-ups en load balancing vaak al aanwezig zijn.
Een belangrijke les uit de Fastly uitval: ervoor zorgen dat uw web servers kan een capaciteit om alle klanten te bedienen, indien nodig bedienen. Als u het CDN moet omzeilen, zijn uw webservers verantwoordelijk voor het bedienen van al het verkeer. CDN's cachen vaak tussen 60-95% van alle webverzoeken, dus als u deze provider moet omzeilen vanwege een storing, kan uw webserver dan 10x het siteverkeer bijhouden?
Les 2: Begrijp uw afhankelijkheden van derden.
Wanneer kritieke infrastructuur uitvalt en een site offline haalt, heb je een fatale storing. Als u bijvoorbeeld in eerste instantie afhankelijk bent van een provider en die provider faalt, wordt uw ondersteuningsteam getroffen door een spervuur van boze klanten (ervan uitgaande dat ze u kunnen bereiken).
Maar hoe zit het met afhankelijkheden van derden, die essentiële services die in elke online winkel zijn verweven? De explosieradius van de Fastly-storing was groter dan sites die offline gingen, omdat honderden SaaS-bedrijven werden uitgeschakeld. Over de hele wereld hadden marketing- en ontwikkelingsteams black-outs in analytische gegevens, mislukkingen in de e-mailopvolgcampagnes en meer esoterische gevolgen, zoals het niet berekenen van verzendkosten voor sommige regio's.
Afhankelijkheden van derden komen ook naar voren in de gebruikerservaring, zoals externe JavaScript (JQuery, D3.js) die de pagina niet correct laadt en weergeeft. Deze niet-fatale storingen veroorzaken vaak de grootste hoofdpijn, omdat gebruikers denken dat de site operationeel is, maar sommige componenten (bijv. klikken op knoppen) werken niet.
Uw infrastructuurafhankelijkheden analyseren
Deze gratis online tool biedt een manier om de infrastructuurbehoeften van elke website te analyseren. Als we Tesla.com als voorbeeld gebruiken, kunnen we zien dat er afhankelijkheden zijn van Akamai, Google en Microsoft. Elk van deze providers speelt een cruciale rol in de Tesla-ervaring.
Voor grotere sites, met name sites die regionale inhoud leveren, kan het web van afhankelijkheden uitgebreid zijn (en variëren afhankelijk van de locatie van de gebruiker!). Als we bijvoorbeeld naar BBC.com kijken, zien we afhankelijkheden van drie CDN-providers, drie cloudproviders en een direct gehost advertentienetwerk. Dat is een aanzienlijke hoeveelheid infrastructuur om te overzien.
Fatale storingen versus niet-fatale storingen
De oplossing die betrouwbaarheidsingenieurs hier gebruiken, is om zoveel mogelijk storingen fataal te maken. In eerste instantie lijkt dit misschien contra-intuïtief, maar een gedeeltelijk werkende site kan inderdaad schadelijker zijn dan een die moeilijk bereikbaar is. Bovendien zijn fatale fouten het gemakkelijkst te debuggen omdat de fout expliciet is: het systeem zelf stopt.
Aan de andere kant zijn niet-fatale storingen vaak "Heisenbugs", dwz notoir lastige problemen die van voorbijgaande aard kunnen zijn en nooit echt de oorzaak kunnen zijn, omdat het systeem over het algemeen blijft werken.
In het licht hiervan streven betrouwbaarheidsingenieurs ernaar om fouten expliciet te maken en de explosieradius van afhankelijkheden te minimaliseren door zoveel mogelijk services zelf te hosten.
Wanneer bijvoorbeeld een essentieel stuk JavaScript nodig is om bepaalde functionaliteit te laden, is het hosten van deze "on origin" (uw webserver) sneller en transparanter. Bovendien, in de steeds toenemende drang naar privacy, minimaliseert het hosten van activa (lettertypen, JavaScript, afbeeldingen, enz.) "on origin" het delen van gegevens met externe providers.
De belangrijkste conclusie: stroomlijn en host waar mogelijk uw afhankelijkheden van uw infrastructuur – en mogelijk al uw storingen fataal.
Les 3: Als je niet meet, weet je het ook niet.
Voor expliciete fatale fouten is de monitoringuitdaging simplistisch: is de website in de lucht? Maar wat als slechts enkele delen van de website kapot zijn, of erger nog, zo traag dat ze kapot lijken te zijn? Zou je het ook weten? Moderne websites zijn verrassend complex. De gemiddelde website heeft 73 netwerkverzoeken nodig om te laden. Dat zijn 73 verschillende netwerkoproepen naar tientallen afzonderlijke netwerken. Als er storingen optreden, hebben ze mogelijk alleen invloed op een van die verzoeken, maar misschien is het van cruciaal belang (denk aan creditcardvalidatie?).
Om het nog erger te maken, is de sitesnelheid niet bepalend. Sites die gepersonaliseerde inhoud of advertenties laden, kunnen bijvoorbeeld sterk verschillende prestatiekenmerken ervaren van gebruiker tot gebruiker, van regio tot regio of van apparaat tot apparaat. Complexe systemen vereisen robuuste monitoring en het is nooit een beter moment geweest om het te implementeren dan nu.
Als het geen Real User Monitoring is, is het per definitie Fake User Monitoring.
De enige manier om te weten hoe uw site presteert voor uw gebruikers, is door de prestaties te meten tijdens het laden van en interactie met de site. Dit type meting wordt gewoonlijk Real User Monitoring genoemd en in de wereld van eCommerce is dit de enige monitoring die het bekijken waard is.
Wanneer er expliciete fouten optreden, zoals het niet laden van een component van een derde partij, bieden Real User Monitoring-systemen gedetailleerde weergaven van welke inhoud is mislukt, op welk apparaat en van welke netwerk- of infrastructuurpartner deze afkomstig is.
Voor impliciete storingen, waarbij een derde partij zich in een gedegradeerde staat bevindt en dus inhoud langzamer aanbiedt, is Real User Monitoring de kanarie in de kolenmijn die nauwkeurige en bruikbare gegevens levert aan betrouwbaarheidsingenieurs over wat er aan de hand is.
.
In een eCommerce-wereld, waar sitesnelheid cruciaal is voor zakelijk succes , biedt Real User Monitoring de vluchtgegevensrecorder die ingenieurs en bedrijfsleiders nodig hebben om de winkel te optimaliseren. Dit is tegenwoordig nog belangrijker, waar zelfs een tiende van een seconde vertraging van de laadtijd van de pagina kan resulteren ineen 8,4% daling van de conversieratio en een 9,2% daling van de gemiddelde bestelwaarde .
Les 4: Foutmeldingen zijn belangrijk.
Wanneer sites een fatale fout hebben, steekt de pagina 'site niet beschikbaar' de kop op. Als de fout echter meer uitgesproken is of verder in de leveringsketen staat (zoals het geval was met Fastly), is de foutpagina mogelijk nog minder gebruiksvriendelijk.
Foutpagina's worden vaak over het hoofd gezien als een potentiële bron van klantenbereik. Toch kan een goed gemaakte foutpagina van een gefrustreerde, verloren klant een toekomstige potentiële verkoopkans maken.
Geweldige foutpagina's maken
Foutpagina's bieden de mogelijkheid om belangrijke informatie aan uw klant over te brengen. Grote foutpagina's hebben drie belangrijke kenmerken:
- Erken : dit is uw fout, niet de klanten. Het is van cruciaal belang om dit te erkennen en links naar ondersteuningsservices, sociale updates en statuspagina's aan te bieden. De sleutel is om ervoor te zorgen dat de klant weet dat dit een tijdelijke storing is en dat u snel weer online bent.
- Excuses : voor het verspillen van de tijd van de klant. Niemand komt gratis op uw website; je hebt ofwel betaald met reclamedollars of met marketing. Nu we ze op de site hebben, hebben we onze aangeboden waarde niet kunnen leveren. Neem even de tijd om duidelijk te maken dat hun bezoek belangrijk voor je is.
- Award: alleen omdat uw site offline is, betekent niet dat de relatie hier moet eindigen. Bied de klant korting als ze je een e-mail sturen. Foutpagina's kunnen ook doorverwijzen naar websites van derden die (hopelijk) niet offline zijn. Gebruik dit moment om het vertrouwen van de klant terug te winnen en het verkoopproces vooruit te helpen.
Als het goed wordt gedaan, kunnen foutpagina's superhelden zijn en je ondersteuningsteams (die al met andere problemen te maken hebben) wat dekking geven. Wanneer e-commercesites niet beschikbaar zijn, zijn we waarschijnlijk ook onze tracking- en metrische mogelijkheden kwijt, dus het vastleggen van de e-mail van de gebruiker en het opvolgen van aanvullende aanbiedingen kan de dag redden.
Les 5: Client-side technologie biedt geavanceerde bescherming.
Als het gaat om storingspreventie, kijken we vaak naar dingen die we kunnen implementeren op infrastructuur- of serverniveau. Maar wat als de storing het netwerk van de gebruiker is (kabel uit)? Wat als uw site zo groot is dat u niet elke infrastructuurpartner kunt volgen? Wat als uw IT-team maanden achterloopt bij het implementeren van uw laatste infrastructuurverzoek? Is het tijd om op te geven? Nee, het is tijd om naar client-side oplossingen te kijken.
Prestatieoplossingen aan de clientzijde worden uitgevoerd in de browser van de gebruiker zelf. Dit zijn stukjes code die u met uw website verzendt, maar die rechtstreeks in de browser zelf worden uitgevoerd – als een beschermengel die waakt over het laden van de pagina. En in de afgelopen tien jaar heeft het web een aantal krachtige, maar vaak over het hoofd geziene client-side oplossingen ontwikkeld. Maar niemand machtiger dan Service Workers.
Tot uw dienst (werknemers)
De Service Worker API is oorspronkelijk ontworpen om offline browsen op een website te vergemakkelijken, met name Gmail. Toen Gmail voor het eerst uitkwam, gebruikten mensen het op vroege smartphones. Toen ze de metro in gingen (waar de netwerkverbinding nul is), konden ze de site niet gebruiken. Het is duidelijk dat een e-mailclient die niet offline kon werken een buzzkill was.
Om dit op te lossen, heeft het Google-team een functie in de browser ontwikkeld waarmee de browser zelf enige controle over een website kan hebben, zelfs als het netwerk niet beschikbaar is.
Ze noemden de nieuwe functie Service Workers, omdat het een vorm van code is die in de browser kan worden uitgevoerd (werkt wel) maar niet afhankelijk is van externe netwerkservices. In plaats daarvan, service werknemers fungeren als een proxy tussen de website, de browser en het netwerk – en geeft ontwikkelaars de mogelijkheid om gegevens op te slaan op het apparaat en reageren op verzoeken vanuit de browser. In veel opzichten zijn het ideeën op infrastructuurniveau, maar ze draaien rechtstreeks op het apparaat van de gebruiker zelf.
Servicemedewerkers kunnen netwerkverzoeken die de browser verzendt onderscheppen, actie ondernemen op basis van of het netwerk beschikbaar is, endpoints snel reageren of een lokaal in de cache opgeslagen kopie van de site terugsturen in het geval van een serverfout. In geavanceerde gevallen kunnen ze cache aan de clientzijde inschakelen, waardoor de site zowel betrouwbaarder als sneller wordt.
Hoe servicemedewerkers kunnen helpen in tijden van gevaar: Caching client-side :
Het belangrijkste voordeel is de mogelijkheid om gegevens, inclusief die vervelende bronnen van derden, op het apparaat zelf op te slaan. Een speciale cache aan de clientzijde zal een werkende website aanzienlijk versnellen en enige mate van bescherming bieden wanneer individuele activa falen. Als de cache voldoende geavanceerd is, kunt u de afhankelijkheid van uw terugkerende klant van uw netwerkinfrastructuur met 70% of meer verminderen.
