Att köra vilken skalbar distribuerad plattform som helst kräver ett engagemang för tillförlitlighet, för att säkerställa att kunderna har vad de behöver när de behöver det. Beroendena kan vara ganska komplicerade, speciellt med en plattform så stor som Roblox. Att bygga tillförlitliga tjänster innebär att, oavsett komplexiteten och statusen för beroenden, någon given tjänst inte kommer att avbrytas (dvs. tillgänglig), kommer att fungera felfritt (dvs hög kvalitet) och utan fel (dvs feltolerans).
Varför tillförlitlighet är viktigt
Vårt kontoidentitetsteam strävar efter att uppnå högre tillförlitlighet, eftersom efterlevnadstjänsterna vi byggt är kärnkomponenterna i plattformen. Brutna efterlevnad kan få allvarliga konsekvenser. Kostnaden för att blockera Roblox naturliga drift är mycket hög, med ytterligare resurser som krävs för att återhämta sig efter ett fel och en försvagad användarupplevelse.
Det typiska förhållningssättet till tillförlitlighet fokuserar främst på tillgänglighet, men i vissa fall blandas termer och missbrukas. De flesta mätningar för tillgänglighet bedömer bara om tjänsterna är igång, medan aspekter som partitionstolerans och konsistens ibland glöms bort eller missförstås.
I enlighet med CAP-teoremet kan alla distribuerade system bara garantera två av dessa tre aspekter, så våra efterlevnadstjänster offrar viss konsekvens för att vara högst tillgängliga och partitionstoleranta. Ändå offrade våra tjänster lite och hittade mekanismer för att uppnå god överensstämmelse med rimliga arkitektoniska förändringar som förklaras nedan.
Processen för att nå högre tillförlitlighet är iterativ, med täta mätningar som matchar kontinuerligt arbete för att förhindra, hitta, upptäcka och åtgärda defekter innan incidenter inträffar. Vårt team identifierade ett starkt värde i följande metoder:
- Rätt mått – Bygg full observerbarhet kring hur kvalitet levereras till kunder och hur beroenden levererar kvalitet till oss.
- Proaktiv förväntan – Utföra aktiviteter som arkitektoniska granskningar och beroenderiskbedömningar.
- Prioritera korrigering – Uppmärksamma incidentrapportlösningen för tjänsten och beroenden som är kopplade till vår tjänst.
Att bygga högre tillförlitlighet kräver en kvalitetskultur. Vårt team investerade redan i prestationsdriven utveckling och vet att en processs framgång beror på hur den antas. Teamet antog denna process till fullo och tillämpade praxis som standard. Följande diagram belyser komponenterna i processen:
Kraften i rätt mätning
Innan du dyker djupare in i måtten, finns det ett snabbt förtydligande att göra gällande mätningar av servicenivå.
- SLO (Service Level Objective) är det tillförlitlighetsmål som vårt team siktar på (dvs. 99.999%).
- SLI (Service Level Indicator) är den uppnådda tillförlitligheten givet en tidsram (dvs. 99.975 % förra februari).
- SLA (Service Level Agreement) är den tillförlitlighet som överenskommits om att leverera och förväntas av våra konsumenter vid en given tidsram (dvs. 99.99 % i veckan).
SLI bör återspegla tillgängligheten (inga obehandlade eller saknade svar), feltoleransen (inga servicefel) och uppnådd kvalitet (inga oväntade fel). Därför definierade vi vår SLI som "framgångskvoten" för framgångsrika svar jämfört med det totala antalet förfrågningar som skickats till en tjänst. Framgångsrika svar är de förfrågningar som skickades i tid och form, vilket betyder nej anslutning, service eller oväntade fel inträffade.
Denna SLI eller Success Ratio samlas in från konsumenternas synvinkel (dvs. kunder). Avsikten är att mäta den faktiska end-to-end-upplevelse som levereras till våra konsumenter så att vi känner oss säkra på att SLAs uppfylls. Att inte göra det skulle skapa en falsk känsla av tillförlitlighet som ignorerar alla infrastrukturproblem för att få kontakt med våra kunder. I likhet med konsument-SLI samlar vi in beroende-SLI för att spåra eventuella risker. I praktiken bör alla beroende SLA:er vara i linje med service SLA och det finns ett direkt beroende med dem. Ett misslyckande innebär att alla misslyckas. Vi spårar och rapporterar även mätvärden från själva tjänsten (dvs. servern) men detta är inte den praktiska källan till hög tillförlitlighet.
Förutom SLI:erna samlar varje byggnad in kvalitetsmått som rapporteras av vårt CI-arbetsflöde. Denna praxis hjälper till att kraftfullt upprätthålla kvalitetsgrindar (dvs. kodtäckning) och rapportera andra meningsfulla mätvärden, såsom kodningsstandard och statisk kodanalys. Detta ämne har tidigare behandlats i en annan artikel, Bygga mikrotjänster som drivs av prestanda. Ett noggrant iakttagande av kvalitet läggs till när man pratar om tillförlitlighet, för ju mer vi investerar i att nå utmärkta poäng, desto mer säkra är vi på att systemet inte kommer att misslyckas under ogynnsamma förhållanden.
Vårt team har två instrumentpaneler. Man levererar all synlighet i både Consumers SLI och Dependencies SLI. Den andra visar alla kvalitetsmått. Vi arbetar på att slå samman allt till en enda instrumentpanel, så att alla aspekter vi bryr oss om är konsoliderade och redo att rapporteras inom en given tidsram.
Förutse misslyckande
göra Arkitektoniska recensioner är en grundläggande del av att vara pålitlig. Först avgör vi om redundans finns och om tjänsten har möjlighet att överleva när beroenden minskar. Utöver de typiska replikeringsidéerna, tillämpade de flesta av våra tjänster förbättrade tekniker för hydratisering av dubbla cache, dubbla återställningsstrategier (såsom lokala failover-köer) eller strategier för dataförlust (såsom transaktionsstöd). Dessa ämnen är tillräckligt omfattande för att motivera ett nytt blogginlägg, men i slutändan är den bästa rekommendationen att implementera idéer som tar hänsyn till katastrofscenarier och minimerar eventuella prestationsstraff.
En annan viktig aspekt att förutse är allt som kan förbättra anslutningen. Det innebär att vara aggressiv med låg latens för klienter och förbereda dem för mycket hög trafik med hjälp av cache-kontrolltekniker, sidovagnar och prestandapolicyer för timeouts, kretsbrytare och återförsök. Dessa metoder gäller för alla klienter inklusive cachar, butiker, köer och ömsesidigt beroende klienter i HTTP och gRPC. Det innebär också att förbättra sunda signaler från tjänsterna och förstå att hälsokontroller spelar en viktig roll i all containerorkestrering. De flesta av våra tjänster ger bättre signaler för försämring som en del av hälsokontrollfeedbacken och verifierar att alla kritiska komponenter fungerar innan de skickar sunda signaler.
Att dela upp tjänster i kritiska och icke-kritiska delar har visat sig användbart för att fokusera på den funktionalitet som betyder mest. Vi brukade ha administratörsslutpunkter i samma tjänst, och även om de inte användes ofta påverkade de den övergripande latensmätningen. Att flytta dem till sin egen tjänst påverkade varje mätvärde i en positiv riktning.
Beroenderiskbedömning är ett viktigt verktyg för att identifiera potentiella problem med beroenden. Detta innebär att vi identifierar beroenden med låg SLI och ber om SLA-anpassning. Dessa beroenden behöver särskild uppmärksamhet under integrationsstegen så vi avsätter extra tid för att jämföra och testa om de nya beroenden är mogna nog för våra planer. Ett bra exempel är den tidiga användningen av Roblox Storage-as-a-Service. Integrationen med den här tjänsten krävde arkivering av buggbiljetter och periodiska synkroniseringsmöten för att kommunicera fynd och feedback. Allt detta arbete använder taggen "tillförlitlighet" så att vi snabbt kan identifiera dess källa och prioriteringar. Karakterisering skedde ofta tills vi hade förtroendet om att det nya beroendet var redo för oss. Detta extra arbete bidrog till att dra beroendet till den nivå av tillförlitlighet som vi förväntar oss att leverera tillsammans för ett gemensamt mål.
Ta struktur till kaos
Det är aldrig önskvärt att ha incidenter. Men när de inträffar finns det meningsfull information att samla in och lära av för att vara mer tillförlitlig. Vårt team har en teamincidentrapport som skapas utöver den typiska företagsomfattande rapporten, så vi fokuserar på alla incidenter oavsett omfattningen av deras påverkan. Vi pekar ut grundorsaken och prioriterar allt arbete för att mildra den i framtiden. Som en del av denna rapport kallar vi in andra team för att åtgärda beroendeincidenter med hög prioritet, följa upp med rätt upplösning, retrospektiv och leta efter mönster som kan gälla oss.
Teamet producerar en Månatlig tillförlitlighetsrapport per tjänst som inkluderar alla SLI:er som förklaras här, alla biljetter vi har öppnat på grund av tillförlitlighet och eventuella incidenter i samband med tjänsten. Vi är så vana vid att generera dessa rapporter att nästa naturliga steg är att automatisera utvinningen av dem. Att göra denna periodiska aktivitet är viktigt, och det är en påminnelse om att tillförlitlighet ständigt spåras och beaktas i vår utveckling.
Vår instrumentering inkluderar anpassade mätvärden och förbättrade varningar så att vi söks så snart som möjligt när kända och förväntade problem uppstår. Alla varningar, inklusive falska positiva, granskas varje vecka. Vid det här laget är det viktigt att polera all dokumentation så att våra konsumenter vet vad de kan förvänta sig när varningar utlöses och när fel uppstår, och sedan vet alla vad de ska göra (t.ex. handböcker och integrationsriktlinjer anpassas och uppdateras ofta).
I sista hand, antagandet av kvalitet i vår kultur är den mest kritiska och avgörande faktorn för att nå högre tillförlitlighet. Vi kan se hur dessa metoder som tillämpas på vårt dagliga arbete redan ger resultat. Vårt team är besatt av pålitlighet och det är vår viktigaste prestation. Vi har ökat vår medvetenhet om vilken inverkan potentiella defekter kan ha och när de kan införas. Tjänster som implementerat dessa metoder har konsekvent nått sina SLO:er och SLA:er. Tillförlitlighetsrapporterna som hjälper oss att spåra allt arbete vi har gjort är ett bevis på det arbete vårt team har utfört, och är ovärderliga lärdomar för att informera och påverka andra team. Det är så pålitlighetskulturen berör alla komponenter i vår plattform.
Vägen till högre tillförlitlighet är inte lätt, men den är nödvändig om du vill bygga en pålitlig plattform som ombildar hur människor möts.
Alberto är en huvudprogramvaruingenjör i Account Identity-teamet på Roblox. Han har varit i spelbranschen länge, med krediter på många AAA-speltitlar och sociala medieplattformar med ett starkt fokus på mycket skalbara arkitekturer. Nu hjälper han Roblox att nå tillväxt och mognad genom att tillämpa bästa utvecklingsmetoder.
Posten Levererar tillförlitlighet i storskalig plattform visades först på Roblox blogg.
- "
- a
- Om Oss
- Konto
- Uppnå
- uppnås
- aktiviteter
- aktivitet
- Dessutom
- Annat
- Antagande
- ogynnsam
- Avtal
- Alla
- redan
- analys
- Annan
- förutse
- tillämpas
- Ansök
- Tillämpa
- tillvägagångssätt
- arkitektoniska
- runt
- Artikeln
- associerad
- uppmärksamhet
- automatisera
- tillgänglighet
- tillgänglig
- medvetenhet
- därför att
- innan
- Där vi får lov att vara utan att konstant prestera,
- nedan
- riktmärke
- BÄST
- Bortom
- Blogg
- föra
- Bug
- SLUTRESULTAT
- Ring
- vilken
- fall
- Orsak
- Kontroller
- klienter
- koda
- Kodning
- samla
- komma
- förbinda
- engagemang
- engagerad
- Gemensam
- kommunicera
- jämfört
- Efterlevnad
- komponenter
- villkor
- förtroende
- säker
- Kontakta
- Anslutningar
- Tänk
- ständigt
- Konsumenten
- konsumenter
- Behållare
- Kärna
- kunde
- skapa
- skapas
- krediter
- kritisk
- kultur
- beställnings
- Kunder
- instrumentbräda
- datum
- djupare
- levereras
- leverera
- levererar
- krav
- beror
- Bestämma
- Utveckling
- rikta
- katastrof
- distribueras
- ner
- driven
- under
- Tidig
- början till slut
- ingenjör
- speciellt
- alla
- allt
- exempel
- utmärkt
- förvänta
- förväntat
- erfarenhet
- omfattande
- Misslyckande
- återkoppling
- Förnamn
- Fast
- Fokus
- fokuserar
- fokusering
- följer
- efter
- formen
- hittade
- från
- full
- funktionella
- funktionalitet
- grundläggande
- framtida
- lek
- grindar
- generera
- Målet
- god
- Tillväxt
- garanti
- riktlinjer
- hända
- hänt
- Hälsa
- hjälpa
- hjälpa
- hjälper
- här.
- Hög
- högre
- höjdpunkter
- höggradigt
- Hur ser din drömresa ut
- HTTPS
- idéer
- identifiera
- Identitet
- Inverkan
- genomföra
- genomföras
- med Esport
- förbättra
- förbättras
- förbättra
- I andra
- innefattar
- Inklusive
- ökat
- industrin
- påverka
- informationen
- Infrastruktur
- integrering
- Avsikt
- investera
- IT
- sig
- Vet
- känd
- LÄRA SIG
- Nivå
- liten
- lokal
- Lång
- se
- göra
- matchande
- Betyder Något
- mogen
- förfall
- betyder
- meningsfull
- betyder
- mäta
- Media
- möten
- Metrics
- blandad
- mer
- mest
- rörliga
- Natural
- nödvändigt för
- Icke desto mindre
- driva
- drift
- orkestrering
- beställa
- Övriga
- övergripande
- egen
- del
- Personer
- prestanda
- bitar
- planer
- plattform
- Plattformar
- Spela
- Punkt
- Synvinkel
- Strategier
- positiv
- möjlig
- potentiell
- kraft
- praktiken
- presentera
- Principal
- prioritet
- problem
- process
- kvalitet
- Snabbt
- snabbt
- nå
- rimlig
- Recover
- återvinning
- reflektera
- om
- pålitlig
- rapport
- Rapport
- förfrågningar
- Obligatorisk
- Resurser
- Omdömen
- Risk
- väg
- Roblox
- Roll
- rot
- rinnande
- Samma
- skalbar
- Skala
- känsla
- service
- Tjänster
- liknande
- eftersom
- enda
- So
- Social hållbarhet
- sociala medier
- sociala medierna
- Mjukvara
- Programvara ingenjör
- några
- speciell
- stå
- standard
- status
- lagrar
- strategier
- stark
- framgång
- framgångsrik
- stödja
- system
- tala
- grupp
- tekniker
- villkor
- testa
- Smakämnen
- därför
- tre
- biljetter
- tid
- tidsram
- tillsammans
- tolerans
- verktyg
- ämne
- ämnen
- spår
- trafik
- förståelse
- us
- värde
- verifiera
- utsikt
- synlighet
- vecka
- Vad
- om
- medan
- utan
- Arbete
- arbetssätt
- skulle