Het runnen van een schaalbaar gedistribueerd platform vereist een toewijding aan betrouwbaarheid, om ervoor te zorgen dat klanten hebben wat ze nodig hebben wanneer ze het nodig hebben. De afhankelijkheden kunnen nogal ingewikkeld zijn, vooral met een platform zo groot als Roblox. Het bouwen van betrouwbare services betekent dat, ongeacht de complexiteit en status van afhankelijkheden, een bepaalde service niet zal worden onderbroken (dwz in hoge mate) Beschikbaar), werkt zonder bugs (dwz hoog kwaliteit) en zonder fouten (dwz fouttolerantie).
Waarom betrouwbaarheid belangrijk is
Ons Account Identity-team streeft naar een hogere betrouwbaarheid, aangezien de nalevingsservices die we hebben gebouwd kerncomponenten van het platform zijn. Een gebrekkige naleving kan ernstige gevolgen hebben. De kosten van het blokkeren van de natuurlijke werking van Roblox zijn erg hoog, met extra middelen die nodig zijn om te herstellen na een storing en een verzwakte gebruikerservaring.
De typische benadering van betrouwbaarheid is voornamelijk gericht op beschikbaarheid, maar in sommige gevallen zijn termen gemengd en misbruikt. De meeste metingen voor beschikbaarheid beoordelen alleen of services actief zijn, terwijl aspecten als partitietolerantie en consistentie soms worden vergeten of verkeerd worden begrepen.
In overeenstemming met de CAP-stelling kan elk gedistribueerd systeem slechts twee van deze drie aspecten garanderen, dus onze compliance-services offeren enige consistentie op om zeer beschikbaar en partitietolerant te zijn. Desalniettemin hebben onze diensten weinig opgeofferd en mechanismen gevonden om een goede consistentie te bereiken met redelijke architecturale veranderingen die hieronder worden uitgelegd.
Het proces om een hogere betrouwbaarheid te bereiken is iteratief, met strakke metingen die passen bij continu werk om defecten te voorkomen, op te sporen, te detecteren en op te lossen voordat zich incidenten voordoen. Ons team identificeerde sterke waarde in de volgende praktijken:
- Juiste meting – Bouw volledige waarneembaarheid op over hoe kwaliteit wordt geleverd aan klanten en hoe afhankelijkheden kwaliteit aan ons leveren.
- Proactief anticiperen – Uitvoeren van activiteiten zoals architectuurbeoordelingen en afhankelijkheidsrisicobeoordelingen.
- Prioriteit geven aan correctie – Breng meer aandacht voor het oplossen van incidentrapporten voor de service en afhankelijkheden die aan onze service zijn gekoppeld.
Het bouwen van een hogere betrouwbaarheid vereist een cultuur van kwaliteit. Ons team investeerde al in prestatiegedreven ontwikkeling en weet dat het succes van een proces afhangt van de acceptatie ervan. Het team nam dit proces volledig over en paste de praktijken als standaard toe. In het volgende diagram worden de componenten van het proces weergegeven:
De kracht van juiste meting
Voordat we dieper op statistieken induiken, is er een snelle verduidelijking die moet worden gegeven met betrekking tot serviceniveau-metingen.
- SLO (Service Level Objective) is de betrouwbaarheidsdoelstelling die ons team nastreeft (nl. 99.999%).
- SLI (Service Level Indicator) is de bereikte betrouwbaarheid gegeven een tijdsbestek (ie 99.975% afgelopen februari).
- SLA (Service Level Agreement) is de betrouwbaarheid die is overeengekomen om te leveren en te worden verwacht door onze consumenten binnen een bepaald tijdsbestek (dwz 99.99% per week).
De SLI moet de beschikbaarheid (geen onverwerkte of ontbrekende reacties), de fouttolerantie (geen servicefouten) en de bereikte kwaliteit (geen onverwachte fouten) weerspiegelen. Daarom hebben we onze SLI gedefinieerd als de "succesverhouding" van succesvolle reacties in vergelijking met het totale aantal verzoeken dat naar een service is verzonden. Succesvolle reacties zijn die verzoeken die op tijd en in vorm zijn verzonden, wat betekent nee verbinding, service of onverwachte fouten zijn opgetreden.
Deze SLI of Succesratio wordt verzameld vanuit het oogpunt van de consument (dwz klanten). Het is de bedoeling om de daadwerkelijke end-to-end-ervaring te meten die aan onze consumenten wordt geleverd, zodat we er zeker van zijn dat aan de SLA's wordt voldaan. Als u dit niet doet, ontstaat er een vals gevoel van betrouwbaarheid dat alle zorgen over de infrastructuur negeert om verbinding te maken met onze klanten. Net als bij de consumenten-SLI, verzamelen we de afhankelijkheids-SLI om eventuele risico's te volgen. In de praktijk moeten alle afhankelijkheids-SLA's aansluiten bij de service-SLA en is er een directe afhankelijkheid mee. Het falen van één impliceert het falen van allen. We volgen en rapporteren ook statistieken van de service zelf (dwz de server), maar dit is niet de praktische bron voor hoge betrouwbaarheid.
Naast de SLI's verzamelt elke build kwaliteitsstatistieken die worden gerapporteerd door onze CI-workflow. Deze praktijk helpt om kwaliteitspoorten (dwz codedekking) sterk af te dwingen en andere zinvolle statistieken te rapporteren, zoals naleving van codeerstandaarden en statische code-analyse. Dit onderwerp is eerder behandeld in een ander artikel, Microservices bouwen op basis van prestaties. Nauwkeurige naleving van de kwaliteit telt op als we het over betrouwbaarheid hebben, want hoe meer we investeren in het behalen van uitstekende scores, des te zekerder zijn we dat het systeem niet zal falen tijdens ongunstige omstandigheden.
Ons team heeft twee dashboards. One levert alle zichtbaarheid in zowel de Consumers SLI als de Dependencies SLI. De tweede toont alle kwaliteitsstatistieken. We werken eraan om alles samen te voegen tot één dashboard, zodat alle aspecten waar we om geven geconsolideerd zijn en klaar zijn om op elk willekeurig moment te worden gerapporteerd.
Anticipeer op mislukking
Doen Architecturale beoordelingen is een fundamenteel onderdeel van betrouwbaar zijn. Eerst bepalen we of er redundantie is en of de service de middelen heeft om te overleven wanneer de afhankelijkheden wegvallen. Naast de typische replicatie-ideeën, pasten de meeste van onze services verbeterde dual-cache-hydratatietechnieken, dubbele herstelstrategieën (zoals lokale failover-wachtrijen) of strategieën voor gegevensverlies (zoals transactionele ondersteuning) toe. Deze onderwerpen zijn uitgebreid genoeg om nog een blogbericht te rechtvaardigen, maar uiteindelijk is de beste aanbeveling om ideeën te implementeren die rekening houden met rampscenario's en eventuele prestatieverlies te minimaliseren.
Een ander belangrijk aspect om op te anticiperen, is alles wat de connectiviteit zou kunnen verbeteren. Dat betekent agressief zijn met betrekking tot lage latentie voor klanten en ze voorbereiden op zeer veel verkeer met behulp van cache-control-technieken, sidecars en performant beleid voor time-outs, stroomonderbrekers en nieuwe pogingen. Deze praktijken zijn van toepassing op elke client, inclusief caches, winkels, wachtrijen en onderling afhankelijke clients in HTTP en gRPC. Het betekent ook het verbeteren van gezonde signalen van de services en het begrijpen dat gezondheidscontroles een belangrijke rol spelen in alle containerorkestratie. De meeste van onze services geven betere signalen voor degradatie als onderdeel van de feedback over de gezondheidscontrole en verifiëren of alle kritieke componenten functioneel zijn voordat ze gezonde signalen verzenden.
Het opsplitsen van services in kritieke en niet-kritieke stukken is nuttig gebleken om te focussen op de functionaliteit die er het meest toe doet. Vroeger hadden we eindpunten voor beheerders in dezelfde service, en hoewel ze niet vaak werden gebruikt, hadden ze invloed op de algemene latentiestatistieken. De verhuizing naar hun eigen service had een positieve invloed op elke statistiek.
Afhankelijkheidsrisicobeoordeling is een belangrijk hulpmiddel om mogelijke problemen met afhankelijkheden te identificeren. Dit betekent dat we afhankelijkheden met een lage SLI identificeren en vragen om SLA-afstemming. Die afhankelijkheden hebben speciale aandacht nodig tijdens integratiestappen, dus we besteden extra tijd aan benchmarking en testen of de nieuwe afhankelijkheden volwassen genoeg zijn voor onze plannen. Een goed voorbeeld is de vroege adoptie die we hadden voor de Roblox Storage-as-a-Service. De integratie met deze service vereiste het indienen van bugtickets en periodieke synchronisatievergaderingen om bevindingen en feedback te communiceren. Al dit werk maakt gebruik van de tag "betrouwbaarheid", zodat we snel de bron en prioriteiten kunnen identificeren. Karakterisering gebeurde vaak totdat we het vertrouwen hadden dat de nieuwe afhankelijkheid voor ons klaar was. Dit extra werk heeft geholpen om de afhankelijkheid naar het vereiste betrouwbaarheidsniveau te brengen dat we verwachten te leveren door samen te werken voor een gemeenschappelijk doel.
Breng structuur in chaos
Het is nooit wenselijk om incidenten te hebben. Maar als ze zich voordoen, is er zinvolle informatie om te verzamelen en van te leren om betrouwbaarder te zijn. Ons team heeft een teamincidentrapport dat verder gaat dan het typische bedrijfsbrede rapport, dus we richten ons op alle incidenten, ongeacht de omvang van hun impact. We noemen de oorzaak en geven prioriteit aan al het werk om het in de toekomst te verminderen. Als onderdeel van dit rapport roepen we andere teams op om afhankelijkheidsincidenten met hoge prioriteit op te lossen, de juiste oplossing op te volgen, terug te kijken en patronen te zoeken die op ons van toepassing kunnen zijn.
Het team produceert een Maandelijks betrouwbaarheidsrapport per service dat omvat alle SLI's die hier worden uitgelegd, alle tickets die we hebben geopend vanwege de betrouwbaarheid en eventuele incidenten die verband houden met de service. We zijn zo gewend aan het genereren van deze rapporten dat de volgende natuurlijke stap is om de extractie ervan te automatiseren. Het is belangrijk om deze periodieke activiteit uit te voeren en het herinnert ons eraan dat betrouwbaarheid constant wordt gevolgd en overwogen in onze ontwikkeling.
Onze instrumentatie omvat aangepaste statistieken en verbeterde waarschuwingen, zodat we zo snel mogelijk worden opgeroepen wanneer bekende en verwachte problemen optreden. Alle waarschuwingen, inclusief valse positieven, worden wekelijks beoordeeld. Op dit moment is het oppoetsen van alle documentatie belangrijk, zodat onze consumenten weten wat ze kunnen verwachten wanneer waarschuwingen worden geactiveerd en wanneer er fouten optreden, en dan weet iedereen wat te doen (bijv. draaiboeken en integratierichtlijnen worden op elkaar afgestemd en vaak bijgewerkt).
uiteindelijk de acceptatie van kwaliteit in onze cultuur is de meest kritische en beslissende factor bij het bereiken van een hogere betrouwbaarheid. We kunnen zien hoe deze praktijken, toegepast op ons dagelijks werk, nu al vruchten afwerpen. Ons team is geobsedeerd door betrouwbaarheid en het is onze belangrijkste prestatie. We hebben ons bewust gemaakt van de impact die mogelijke defecten kunnen hebben en wanneer ze kunnen worden geïntroduceerd. Services die deze praktijken hebben geïmplementeerd, hebben consequent hun SLO's en SLA's bereikt. De betrouwbaarheidsrapporten die ons helpen bij het volgen van al het werk dat we hebben gedaan, zijn een bewijs van het werk dat ons team heeft gedaan en zijn onschatbare lessen om andere teams te informeren en te beïnvloeden. Zo raakt de betrouwbaarheidscultuur alle onderdelen van ons platform.
De weg naar een hogere betrouwbaarheid is niet gemakkelijk, maar het is noodzakelijk als je een vertrouwd platform wilt bouwen dat de manier waarop mensen samenkomen opnieuw uitvindt.
Alberto is een Principal Software Engineer in het Account Identity-team van Roblox. Hij zit al heel lang in de game-industrie, met credits op veel AAA-gametitels en sociale-mediaplatforms met een sterke focus op zeer schaalbare architecturen. Nu helpt hij Roblox om groei en volwassenheid te bereiken door de beste ontwikkelingspraktijken toe te passen.
De post Grootschalige platformbetrouwbaarheid leveren verscheen eerst op Roblox-blog.
- "
- a
- Over
- Account
- Bereiken
- bereikt
- activiteiten
- activiteit
- toevoeging
- Extra
- Adoptie
- nadelige
- Overeenkomst
- Alles
- al
- analyse
- Nog een
- anticiperen
- toegepast
- Solliciteer
- Het toepassen van
- nadering
- bouwkundig
- rond
- dit artikel
- geassocieerd
- aandacht
- automatiseren
- beschikbaarheid
- Beschikbaar
- bewustzijn
- omdat
- vaardigheden
- wezen
- onder
- criterium
- BEST
- Verder
- Blog
- brengen
- Bug
- bouw
- Bellen
- verzorging
- gevallen
- Veroorzaken
- Controles
- klanten
- code
- codering
- verzamelen
- hoe
- plegen
- verplichting
- toegewijd
- Gemeen
- communiceren
- vergeleken
- nakoming
- componenten
- voorwaarden
- vertrouwen
- zeker
- Verbinden
- Connectiviteit
- Overwegen
- permanent
- consument
- Consumenten
- Containers
- Kern
- kon
- en je merk te creëren
- aangemaakt
- credits
- kritisch
- Culture
- gewoonte
- Klanten
- dashboards
- gegevens
- diepere
- geleverd
- het leveren van
- levert
- eisen
- afhankelijk
- Bepalen
- Ontwikkeling
- directe
- ramp
- verdeeld
- beneden
- gedreven
- gedurende
- Vroeg
- eind tot eind
- ingenieur
- vooral
- iedereen
- alles
- voorbeeld
- uitstekend
- verwachten
- verwacht
- ervaring
- uitgebreid
- Storing
- feedback
- Voornaam*
- Bepalen
- Focus
- richt
- gericht
- volgen
- volgend
- formulier
- gevonden
- oppompen van
- vol
- functioneel
- functionaliteit
- fundamenteel
- toekomst
- spel
- Gates
- het genereren van
- doel
- goed
- garantie
- richtlijnen
- gebeuren
- gebeurd
- Gezondheid
- hulp
- het helpen van
- helpt
- hier
- Hoge
- hoger
- highlights
- zeer
- Hoe
- HTTPS
- ideeën
- identificeren
- Identiteit
- Impact
- uitvoeren
- geïmplementeerd
- belangrijk
- verbeteren
- verbeterd
- het verbeteren van
- Anders
- omvat
- Inclusief
- meer
- -industrie
- beïnvloeden
- informatie
- Infrastructuur
- integratie
- Bedoeling
- investeren
- IT
- zelf
- blijven
- bekend
- LEARN
- Niveau
- Elke kleine stap levert grote resultaten op!
- lokaal
- lang
- Kijk
- maken
- matching
- Zaken
- volwassen
- зрелость
- betekenis
- zinvolle
- middel
- maatregel
- Media
- vergaderingen
- Metriek
- gemengd
- meer
- meest
- bewegend
- Naturel
- noodzakelijk
- niettemin
- besturen
- operatie
- orkestratie
- bestellen
- Overige
- totaal
- het te bezitten.
- deel
- Mensen
- prestatie
- stukken
- plannen
- platform
- platforms
- Spelen
- punt
- Oogpunt
- beleidsmaatregelen door te lezen.
- positief
- mogelijk
- potentieel
- energie
- praktijk
- presenteren
- Principal
- prioriteit
- problemen
- kwaliteit
- Quick
- snel
- bereiken
- redelijk
- Herstellen
- na een training
- reflecteren
- met betrekking tot
- betrouwbaar
- verslag
- Rapporten
- verzoeken
- nodig
- Resources
- Recensies
- Risico
- weg
- roblox
- Rol
- wortel
- lopend
- dezelfde
- schaalbare
- Scale
- zin
- service
- Diensten
- gelijk
- sinds
- single
- So
- Social
- social media
- social media platforms
- Software
- Software Engineer
- sommige
- special
- staan
- standaard
- Status
- winkels
- strategieën
- sterke
- succes
- geslaagd
- ondersteuning
- system
- praat
- team
- technieken
- termen
- proef
- De
- daarom
- drie
- tickets
- niet de tijd of
- tijdsbestek
- samen
- tolerantie
- tools
- onderwerp
- onderwerpen
- spoor
- verkeer
- begrip
- us
- waarde
- controleren
- Bekijk
- zichtbaarheid
- week
- Wat
- of
- en
- zonder
- Mijn werk
- werkzaam
- zou