Belangrijke SRE-principes en -procedures: correcte cycli
Als het echt waar is dat "u bent wat u doet", dan zijn we tot het hart van deze module gekomen. In deze les gaan we kijken naar twee van de procedures die vaak als kern worden beschouwd voor de praktijk van SRE. Beide komen voort uit het principe dat het belangrijk is om 'goede cycli' te creëren. Goede cycli in deze context zijn procedures die feedbacklussen bouwen in een organisatie die ervoor zorgen dat de organisatie continu beter wordt. We hebben volledige follow-on modules op precies deze twee werkwijzen, dus we gaan het oppervlak alleen overslaan met een overzicht van elk hier.
Opwaartse spiraal 1: SLI's en SLO's
Eerder in deze module hebben we ons punt benadrukt over het werken aan het 'juiste niveau van betrouwbaarheid'. Dit gedeelte is precies de plaats waar dat concept tot stand wordt gebracht.
Stel dat u een nieuwe service hebt die u naar productie wilt brengen (een service die is gemaakt of een service die nog in het planningsproces is). Als onderdeel van dat proces is het belangrijk om enkele beslissingen te nemen over de gewenste betrouwbaarheid. Als u niet alle code zelf schrijft, worden deze beslissingen genomen (en dit punt is cruciaal) in samenwerking met de ontwikkelaars die het doen.
De eerste beslissing om te nemen is, wat moeten we gebruiken als indicatoren van de status van de service (een Service Level Indicator of SLI)? Een andere manier om deze vraag te stellen is 'Hoe weet je wanneer het goed werkt?'. Er zijn veel manieren om SLI bij te houden en we verkennen later enkele details. Maar deze indicatoren zijn meestal:
- Succes versus foutmetingen. Voltooit de service een bewerking in een bepaald percentage van de tijd?
- Metingen van timing. Hebben we binnen een bepaalde tijdsdrempel een antwoord geretourneerd?
- Metingen van doorvoer. Hebben we een bepaalde hoeveelheid gegevens verwerkt?
Of een combinatie van al deze metingen.
We kunnen als eenvoudig voorbeeld een SLI voor onze service nemen die via een HTTP 200-code (versus een 500 of andere code) aangeeft hoe vaak een bewerking is geslaagd.
Nu we een duidelijke indicator hebben die aangeeft hoe de service werkt. We willen bepalen welk betrouwbaarheidsniveau we ervan verwachten of verlangen. Verwachten we bijvoorbeeld gedurende een periode van een dag dat er een foutpercentage van 20% van de service wordt weergegeven? We gebruiken hier ronde en grote getallen omdat deze in het begin gemakkelijker te bespreken zijn. In latere modules verhogen we de complexiteit en precisie van instructies zoals deze (welke gebruikers zien dat foutpercentage? Sommigen van hen? de meeste van hen?" enzovoort). Die verwachting die in overleg met de ontwikkelaar van de service wordt bepaald, is een serviceniveaudoelstelling (SLO of Service Level Objective).
De serviceniveaudoelstelling moet nauwkeurig kunnen worden gemeten en in uw controlesysteem worden weergegeven. Het is bedoeld om een objectief, goed begrepen doel te zijn voor de betrouwbaarheid van de service, wat is het getal dat goed genoeg is? Er is hier geen ruimte voor vage veronderstellingen als "De service heeft het de afgelopen week wel aardig gedaan, maar ik kan er verder moeilijk uitspraken over doen". De service voldoet aan de SLO of niet. De gegevens moeten voor zich spreken. Als de service niet voldoet aan de SLO (vooral wanneer dit gedurende een bepaalde tijd herhaaldelijk gebeurt), is er iets mis en moet er iets aan worden gedaan.
Foutbudgetten
We kunnen begrijpen dat een organisatie in actie kan komen als een service niet voldoet aan de SLO. SRE neemt dit hele concept echter nog een stap vooruit voor de gevallen waarin aan de SLO wordt voldaan of overschreden. Sommige organisaties gebruiken SLO's om zogeheten 'foutbudgetten' samen te stellen.
Laten we ter illustratie van dit idee de voorbeeldservice gebruiken die we hebben besproken en de bijbehorende SLO met een slagingspercentage van 80% (dat staat voor: 'de service moet 80% van de tijd actief zijn'). Met de SLO van 80% uptime hebben we opgegeven dat onze service 80% van de tijd actief moet zijn. Maar hoe zit het met de overige 20%? Als onze service de overige 20% buiten werking is, maakt dat ons niet echt uit omdat we hebben besloten dat het voor ons als servicedoelstelling niet belangrijk is dat de service die overige 20% actief is.
Dus als het ons niet uitmaakt wat er in die tijd gebeurt, wat kunnen we dan doen met de service? We kunnen in ieder geval wijzigingen aanbrengen in de actieve service door deze te upgraden, bijvoorbeeld met een nieuwe versie waarbij een aantal functies wordt toegevoegd. Als de service bij deze nieuwe versie actief blijft en geen extra uitvaltijd kent, is dat prima. Als deze nieuwe release ervoor zorgt dat de service minder stabiel is en fouten nog eens 10% van de tijd retourneert wanneer er fouten worden opgespoord, is het nog steeds prima. We blijven namelijk nog steeds binnen ons budget van toegestane onbetrouwbaarheid.
Een foutenbudget is het verschil tussen de mogelijke perfecte betrouwbaarheid van de service en de gewenste betrouwbaarheid van de service (100% - 80% = 20%). In dit geval geeft het foutbudget ons een fonds van 20% onbetrouwbaarheid 20% tijd waarin we "het niet schelen of het op is of niet omdat het nog steeds in spec" is. We kunnen die 20% tijd trekken en besteden op elke manier die we willen (misschien met meer releases) totdat het uitgeput is, net als elk ander budget.
Foutbudgetten worden in sommige organisaties ook gebruikt voor minder positieve gevallen, bijvoorbeeld wanneer u niet aan de SLO voldoet. In dat geval kunt u ervoor kiezen om iets strenger te doen dan alleen 'een actie ondernemen'. Stel dat er wat problemen zijn met onze service en dat deze slechts 60% van de tijd actief was, zoals wordt aangegeven door de SLI die we eerder hebben gekozen. We hebben niet voldaan aan onze doelstelling (de SLO). Onze service heeft het foutenbudget verbruikt. De organisatie kan besluiten om af te zien van een geplande release omdat nog meer ingrepen in het systeem op dit moment kunnen leiden tot een verdere verslechtering van de betrouwbaarheid. Meestal worden foutbudgetten berekend voor een bepaalde periode; een maand, kwartaal, enzovoort. Op doorlopende basis dus uiteindelijk als de betrouwbaarheid van de service verbetert, retourneert dat budget.
Tijdens deze tijd van gated releases kan de organisatie ervoor kiezen om enkele technische resources weg te draaien van functieontwikkeling naar betrouwbaarheidswerk. Met als doel om de bron van de problemen te ontdekken en te verbeteren die ervoor zorgde dat de service de SLO opblazen.
We hebben het over 'sommige organisaties' als het gaat over foutbudgetten omdat voor de implementatie, met name in het geval van releases die continu worden gecontroleerd, een zekere institutionele samenwerking vereist is. Wanneer er een releasebeslissing is genomen, moet de organisatie bereid zijn om de release terug te houden als de betrouwbaarheid van de service tot nu toe niet vol is geweest. Die beslissing is niet een beslissing die alle organisaties bereid zijn te maken. Deze beslissing is ook niet de enige mogelijke reactie op een verarmd foutbudget, maar het is de meest besproken.
In een afzonderlijke module bespreken we aanzienlijk meer informatie over SLO's, SLO's en foutbudgetten. Maar het is hier de moeite waard om het positieve cyclusaspect van deze praktijken te benadrukken. In theorie biedt het een manier voor een organisatie om de betrouwbaarheid van een service te beschrijven, te communiceren en erop te reageren. Terwijl u dit op een manier doet waardoor iedereen aan een betere betrouwbaarheid kan werken. Deze terugkoppelingscyclus kan erg belangrijk zijn.
Opwaartse spiraal 2: analyses achteraf zonder schuldvraag
Het idee van een postmortem, de retrospectiefanalyse van een significante, meestal ongewenste gebeurtenis, is niet eens op afstand specifiek voor sitebetrouwbaarheidstechniek. Het is zelfs niet ongebruikelijk in de operationele wereld. Wat wel enigszins specifiek is voor de SRE is dat bij de analyses achteraf geen sprake is van een schuldvraag. De aandacht wordt gericht op het falen van de procedure of de technologie die het incident veroorzaakt, niet op de handelingen van specifieke personen. "Wat was er verkeerd aan de procedure die we hebben geïmplementeerd waardoor X de handeling kon verrichten die leidde tot de fout? Aan welke informatie ontbrak het die persoon, waardoor deze de verkeerde conclusie trok? Welke kaders moesten aanwezig zijn, zodat het niet mogelijk was om zo'n catastrofale fout te hebben?" Deze vragen zijn de sortering die wordt gesteld in een onschuldige postmortem.
De strekking en de richting van deze vragen is van cruciaal belang. We zijn op zoek naar manieren om de systemen of processen te verbeteren, niet naar manieren om de personen te straffen waarvan het gebruik van deze systemen of processen in goed vertrouwen heeft bijgedragen aan de storing. Onthoud hierbij het volgende: "U zorgt niet voor betrouwbaarheid door mensen te ontslaan". In onze ervaring leert een organisatie die een persoon elke keer als er een productieincident (met enkele uitzonderingen) wordt geactiveerd, niet van deze incidenten. In plaats daarvan worden ze achtergelaten met één individu, die in de hoek schudt, bang om eventuele wijzigingen aan te brengen in alles.
Met een goed functionerende analyse achteraf in een organisatie wordt er echter een positieve spiraal gecreëerd. Hiermee kan de organisatie leren van de storingen en continu de systemen verbeteren (een juiste analyse en opvolging wordt uitgevoerd).
Deze relatie met fouten en fouten die door de organisatie worden omarmd als kansen voor leren en verbeteren is een kernprincipe van sitebetrouwbaarheidstechniek. Het creëren van deze positieve spiraal om gebruik te maken van deze mogelijkheden en de organisatie naar een grotere betrouwbaarheid te leiden is een ander belangrijk principe.
Laten we enkele andere principes en procedures verkennen, gericht op de menselijke kant van SRE, in onze volgende les.