At køre enhver skalerbar distribueret platform kræver en forpligtelse til pålidelighed for at sikre, at kunderne har det, de har brug for, når de har brug for det. Afhængighederne kan være ret indviklede, især med en platform så stor som Roblox. Opbygning af pålidelige tjenester betyder, at uanset kompleksiteten og status af afhængigheder, vil enhver given tjeneste ikke blive afbrudt (dvs. til rådighed), vil fungere fejlfrit (dvs. høj kvalitet) og uden fejl (dvs fejltolerance).
Hvorfor pålidelighed er vigtig
Vores Account Identity-team er forpligtet til at opnå højere pålidelighed, da de compliance-tjenester, vi har bygget, er kernekomponenter til platformen. Brudt overholdelse kan have alvorlige konsekvenser. Omkostningerne ved at blokere Roblox' naturlige drift er meget høje, med yderligere ressourcer nødvendige for at komme sig efter en fejl og en svækket brugeroplevelse.
Den typiske tilgang til pålidelighed fokuserer primært på tilgængelighed, men i nogle tilfælde er termer blandet og misbrugt. De fleste målinger for tilgængelighed vurderer blot, om tjenester er oppe og kører, mens aspekter som partitionstolerance og konsistens nogle gange bliver glemt eller misforstået.
I overensstemmelse med CAP-sætningen kan ethvert distribueret system kun garantere to ud af disse tre aspekter, så vores compliance-tjenester ofrer en vis konsistens for at være yderst tilgængeligt og partitionstolerant. Ikke desto mindre ofrede vores tjenester lidt og fandt mekanismer til at opnå god overensstemmelse med rimelige arkitektoniske ændringer, som forklares nedenfor.
Processen for at opnå højere pålidelighed er iterativ, med tæt måling, der matcher kontinuerligt arbejde for at forhindre, finde, opdage og rette fejl, før hændelser opstår. Vores team identificerede stærk værdi i følgende praksis:
- Rigtig måling – Byg fuld observerbarhed omkring, hvordan kvalitet leveres til kunder, og hvordan afhængigheder leverer kvalitet til os.
- Proaktiv forventning – Udføre aktiviteter såsom arkitektoniske gennemgange og afhængighedsrisikovurderinger.
- Prioriter rettelse – Bring større opmærksomhed på løsning af hændelsesrapporter for den service og afhængigheder, der er knyttet til vores service.
Opbygning af højere pålidelighed kræver en kvalitetskultur. Vores team investerede allerede i præstationsdrevet udvikling og ved, at en process succes afhænger af dens vedtagelse. Holdet overtog denne proces fuldt ud og anvendte praksis som standard. Følgende diagram fremhæver komponenterne i processen:
Styrken ved rigtig måling
Før du dykker dybere ned i metrikker, er der en hurtig afklaring at lave vedrørende serviceniveaumålinger.
- SLO (Service Level Objective) er det pålidelighedsmål, som vores team sigter efter (dvs. 99.999%).
- SLI (Service Level Indicator) er den opnåede pålidelighed givet en tidsramme (dvs. 99.975 % sidste februar).
- SLA (Service Level Agreement) er den pålidelighed, der er aftalt at levere og forventes af vores forbrugere på en given tidsramme (dvs. 99.99 % om ugen).
SLI'en skal afspejle tilgængeligheden (ingen ubehandlede eller manglende svar), fejltolerancen (ingen servicefejl) og opnået kvalitet (ingen uventede fejl). Derfor definerede vi vores SLI som "Success Ratio" af vellykkede svar sammenlignet med det samlede antal anmodninger sendt til en tjeneste. Vellykkede svar er de anmodninger, der blev afsendt i tid og form, hvilket betyder nej forbindelse, service eller uventede fejl skete.
Denne SLI eller Succes Ratio er indsamlet fra forbrugernes synspunkt (dvs. klienter). Hensigten er at måle den faktiske end-to-end oplevelse leveret til vores forbrugere, så vi føler os sikre på at SLA'er bliver opfyldt. Hvis du ikke gør det, vil det skabe en falsk følelse af pålidelighed, der ignorerer alle infrastrukturproblemer for at få forbindelse til vores kunder. I lighed med forbruger-SLI'en indsamler vi afhængigheds-SLI'en for at spore enhver potentiel risiko. I praksis bør alle afhængigheds-SLA'er stemme overens med service-SLA'en, og der er en direkte afhængighed med dem. Fejlen af én indebærer fiasko for alle. Vi sporer og rapporterer også metrics fra selve tjenesten (dvs. serveren), men dette er ikke den praktiske kilde til høj pålidelighed.
Ud over SLI'erne indsamler hver build kvalitetsmålinger, der rapporteres af vores CI-workflow. Denne praksis hjælper kraftigt med at håndhæve kvalitetsgates (dvs. kodedækning) og rapportere andre meningsfulde målinger, såsom kodningsstandardoverholdelse og statisk kodeanalyse. Dette emne blev tidligere dækket i en anden artikel, Opbygning af mikrotjenester drevet af ydeevne. Omhyggelig overholdelse af kvalitet lægger op til, når vi taler om pålidelighed, for jo mere vi investerer i at opnå fremragende scores, jo mere sikre er vi på, at systemet ikke vil fejle under ugunstige forhold.
Vores team har to dashboards. Man leverer al synlighed i både Consumers SLI og Dependencies SLI. Den anden viser alle kvalitetsmålinger. Vi arbejder på at samle alt til et enkelt dashboard, så alle de aspekter, vi holder af, er konsoliderede og klar til at blive rapporteret inden for en given tidsramme.
Forvent fiasko
Doing Arkitektoniske anmeldelser er en grundlæggende del af at være pålidelig. Først afgør vi, om redundans er til stede, og om tjenesten har midlerne til at overleve, når afhængighed falder. Ud over de typiske replikeringsideer, anvendte de fleste af vores tjenester forbedrede dual cache-hydreringsteknikker, dual recovery-strategier (såsom failover lokale køer) eller datatabsstrategier (såsom transaktionssupport). Disse emner er omfattende nok til at berettige endnu et blogindlæg, men i sidste ende er den bedste anbefaling at implementere ideer, der tager højde for katastrofescenarier og minimerer enhver præstationsstraf.
Et andet vigtigt aspekt at forudse er alt, der kunne forbedre forbindelsen. Det betyder at være aggressiv med hensyn til lav latenstid for klienter og forberede dem til meget høj trafik ved hjælp af cache-kontrolteknikker, sidevogne og performante politikker for timeouts, kredsløbsafbrydere og genforsøg. Denne praksis gælder for enhver klient inklusive caches, butikker, køer og indbyrdes afhængige klienter i HTTP og gRPC. Det betyder også at forbedre sunde signaler fra tjenesterne og forstå, at sundhedstjek spiller en vigtig rolle i al containerorkestrering. De fleste af vores tjenester giver bedre signaler for forringelse som en del af sundhedstjekkets feedback og verificerer, at alle kritiske komponenter er funktionelle, før de sender sunde signaler.
At opdele tjenester i kritiske og ikke-kritiske stykker har vist sig nyttig til at fokusere på den funktionalitet, der betyder mest. Vi plejede at have admin-only endpoints i den samme tjeneste, og selvom de ikke blev brugt ofte, påvirkede de de overordnede latency-metrics. At flytte dem til deres egen tjeneste påvirkede alle målinger i en positiv retning.
Risikovurdering af afhængighed er et vigtigt værktøj til at identificere potentielle problemer med afhængigheder. Det betyder, at vi identificerer afhængigheder med lav SLI og beder om SLA-justering. Disse afhængigheder kræver særlig opmærksomhed under integrationstrin, så vi afsætter ekstra tid til at benchmarke og teste, om de nye afhængigheder er modne nok til vores planer. Et godt eksempel er den tidlige adoption af Roblox Storage-as-a-Service. Integrationen med denne tjeneste krævede indlevering af fejlbilletter og periodiske synkroniseringsmøder for at kommunikere resultater og feedback. Alt dette arbejde bruger "pålideligheds"-tagget, så vi hurtigt kan identificere dets kilde og prioriteter. Karakterisering skete ofte, indtil vi havde tillid til, at den nye afhængighed var klar til os. Dette ekstra arbejde var med til at trække afhængigheden til det nødvendige niveau af pålidelighed, som vi forventer at levere i fællesskab for et fælles mål.
Bring struktur til kaos
Det er aldrig ønskeligt at have hændelser. Men når de sker, er der meningsfuld information at indsamle og lære af for at være mere pålidelig. Vores team har en teamhændelsesrapport, der er oprettet ud over den typiske virksomhedsdækkende rapport, så vi fokuserer på alle hændelser uanset omfanget af deres påvirkning. Vi fremhæver årsagen og prioriterer alt arbejde for at afbøde det i fremtiden. Som en del af denne rapport indkalder vi andre teams til at rette afhængighedshændelser med høj prioritet, følge op med ordentlig løsning, tilbageblik og se efter mønstre, der kan gælde for os.
Holdet producerer en Månedlig pålidelighedsrapport pr. service som inkluderer alle de SLI'er, der er forklaret her, alle billetter, vi har åbnet på grund af pålidelighed og eventuelle hændelser forbundet med tjenesten. Vi er så vant til at generere disse rapporter, at det næste naturlige skridt er at automatisere deres udvinding. Det er vigtigt at udføre denne periodiske aktivitet, og det er en påmindelse om, at pålidelighed konstant spores og overvejes i vores udvikling.
Vores instrumentering inkluderer brugerdefinerede målinger og forbedrede advarsler, så vi bliver søgt hurtigst muligt, når kendte og forventede problemer opstår. Alle advarsler, inklusive falske positiver, gennemgås hver uge. På dette tidspunkt er det vigtigt at polere al dokumentation, så vores forbrugere ved, hvad de kan forvente, når advarsler udløses, og når der opstår fejl, og så ved alle, hvad de skal gøre (f.eks. bliver playbooks og integrationsvejledninger justeret og opdateret ofte).
I sidste ende, overtagelsen af kvalitet i vores kultur er den mest kritiske og afgørende faktor for at opnå højere pålidelighed. Vi kan se, hvordan denne praksis, der anvendes i vores daglige arbejde, allerede giver pote. Vores team er besat af pålidelighed, og det er vores vigtigste præstation. Vi har øget vores bevidsthed om, hvilken effekt potentielle defekter kan have, og hvornår de kan blive introduceret. Tjenester, der implementerede denne praksis, har konsekvent nået deres SLO'er og SLA'er. Pålidelighedsrapporterne, der hjælper os med at spore alt det arbejde, vi har udført, er et vidnesbyrd om det arbejde, vores team har udført, og står som uvurderlige erfaringer til at informere og påvirke andre teams. Sådan berører pålidelighedskulturen alle komponenter i vores platform.
Vejen til højere pålidelighed er ikke let, men den er nødvendig, hvis du vil bygge en pålidelig platform, der genskaber, hvordan mennesker mødes.
Alberto er hovedsoftwareingeniør i Account Identity-teamet hos Roblox. Han har været i spilindustrien i lang tid, med kreditter på mange AAA-spiltitler og sociale medieplatforme med et stærkt fokus på meget skalerbare arkitekturer. Nu hjælper han Roblox med at nå vækst og modenhed ved at anvende bedste udviklingspraksis.
Stillingen Levering af platformspålidelighed i stor skala dukkede først på Roblox blog.
- "
- a
- Om
- Konto
- opnå
- opnået
- aktiviteter
- aktivitet
- Desuden
- Yderligere
- Vedtagelse
- negativ
- Aftale
- Alle
- allerede
- analyse
- En anden
- foregribe
- anvendt
- Indløs
- Anvendelse
- tilgang
- arkitektonisk
- omkring
- artikel
- forbundet
- opmærksomhed
- automatisere
- tilgængelighed
- til rådighed
- bevidsthed
- fordi
- før
- være
- jf. nedenstående
- benchmark
- BEDSTE
- Beyond
- Blog
- bringe
- Bug
- bygge
- ringe
- hvilken
- tilfælde
- Årsag
- Kontrol
- kunder
- kode
- Kodning
- indsamler
- Kom
- begå
- engagement
- engageret
- Fælles
- kommunikere
- sammenlignet
- Compliance
- komponenter
- betingelser
- tillid
- sikker
- Tilslut
- Connectivity
- Overvej
- konstant
- forbruger
- Forbrugere
- Container
- Core
- kunne
- skabe
- oprettet
- Medvirkende
- kritisk
- Medarbejder kultur
- skik
- Kunder
- instrumentbræt
- data
- dybere
- leveret
- leverer
- leverer
- krav
- afhænger
- Bestem
- Udvikling
- direkte
- katastrofe
- distribueret
- ned
- drevet
- i løbet af
- Tidligt
- ende til ende
- ingeniør
- især
- alle
- at alt
- eksempel
- fremragende
- forvente
- forventet
- erfaring
- omfattende
- Manglende
- tilbagemeldinger
- Fornavn
- Fix
- Fokus
- fokuserer
- fokusering
- følger
- efter
- formular
- fundet
- fra
- fuld
- funktionel
- funktionalitet
- fundamental
- fremtiden
- spil
- Gates
- generere
- mål
- godt
- Vækst
- garanti
- retningslinjer
- ske
- skete
- Helse
- hjælpe
- hjælpe
- hjælper
- link.
- Høj
- højere
- højdepunkter
- stærkt
- Hvordan
- HTTPS
- ideer
- identificere
- Identity
- KIMOs Succeshistorier
- gennemføre
- implementeret
- vigtigt
- Forbedre
- forbedret
- forbedring
- I andre
- omfatter
- Herunder
- øget
- industrien
- indflydelse
- oplysninger
- Infrastruktur
- integration
- Intention
- investere
- IT
- selv
- Kend
- kendt
- LÆR
- Niveau
- lidt
- lokale
- Lang
- Se
- lave
- matchende
- Matters
- modne
- modenhed
- betyder
- meningsfuld
- midler
- måle
- Medier
- møder
- Metrics
- blandet
- mere
- mest
- flytning
- Natural
- nødvendig
- Ikke desto mindre
- betjene
- drift
- orkestrering
- ordrer
- Andet
- samlet
- egen
- del
- Mennesker
- ydeevne
- stykker
- planer
- perron
- Platforme
- Leg
- Punkt
- Synspunkt
- politikker
- positiv
- mulig
- potentiale
- magt
- praksis
- præsentere
- Main
- prioritet
- problemer
- behandle
- kvalitet
- Hurtig
- hurtigt
- nå
- rimelige
- Recover
- opsving
- afspejler
- om
- pålidelig
- indberette
- Rapporter
- anmodninger
- påkrævet
- Ressourcer
- Anmeldelser
- Risiko
- vej
- Roblox
- roller
- rod
- kører
- samme
- skalerbar
- Scale
- forstand
- tjeneste
- Tjenester
- lignende
- siden
- enkelt
- So
- Social
- sociale medier
- sociale medieplatforme
- Software
- Software Engineer
- nogle
- særligt
- stå
- standard
- Status
- forhandler
- strategier
- stærk
- succes
- vellykket
- support
- systemet
- taler
- hold
- teknikker
- vilkår
- prøve
- derfor
- tre
- billetter
- tid
- tidsramme
- sammen
- tolerance
- værktøj
- emne
- Emner
- spor
- Trafik
- forståelse
- us
- værdi
- verificere
- Specifikation
- synlighed
- uge
- Hvad
- hvorvidt
- mens
- uden
- Arbejde
- arbejder
- ville