Hoe begin ik met SRE?

Misschien heb je inmiddels een aantal DevOps-principes en -processen ingevoerd. De volgende stap is het op schaal laten werken door SRE in te voeren. Dit zijn methoden die zich bewezen hebben om teams met SRE-principes van de grond te krijgen:

SRE-teams onderhandelen met belanghebbenden over service level objectives (SLO's). Die SLO's leggen vast welk serviceniveau klanten mogen verwachten. Het serviceniveau wordt gemeten met service level indicators (SLI's), die de kritieke aspecten van de dienst beoordelen.

SLO's leggen ook vast hoe lang een applicatie onbeschikbaar mag zijn; die ruimte kun je vervolgens inzetten om te vernieuwen en de betrouwbaarheid te verbeteren. Die toegestane downtime heet het “error budget”: de toegestane marge voor fouten en storingen die het ontwikkelteam mag “uitgeven” om features te bouwen of te repareren, totdat het budget op is. Met Agile Analytics van ZEN Software heb je een uitgebreide set gereedschap om error budgets te beheren en te volgen voor je organisatie.

Zo waarborg je zowel beschikbaarheid als de ruimte om het bestaande systeem te verbeteren of bij te werken. Klassieke uptime-cijfers zijn geen toereikende maatstaf voor complexe systemen, omdat ze ervan uitgaan dat alle diensten gelijk zijn. SRE meet beschikbaarheid in plaats daarvan met een formule die kijkt hoeveel klantinteracties slagen:

                    aantal geslaagde verzoeken
Beschikbaarheid = -------------------------------
                      totaal aantal verzoeken

SLO's meten de prestatie van de dienst via de SLI. Die service level indicator is een getal (bijvoorbeeld 99,981%). Trek je de onbetrouwbaarheid uit de vorige periode af van de SLO, dan houd je het error budget over: een getal dat je kunt omrekenen naar het aantal minuten toegestane downtime per maand, in te zetten voor vernieuwing en experiment. (Figuur 2) In die figuur zie je het beschikbaarheids-error budget geleidelijk teruglopen door kleine maar aanhoudende problemen.

Met Agile Analytics van ZEN Software volg je in realtime hoe je diensten presteren en grijp je in wanneer error budgets opraken.

Begrijpen hoe je beschikbaarheid verbetert, vraagt dat ontwikkel- en beheerteams op hetzelfde podium staan. SRE vraagt om een vollediger beeld van de wisselwerking tussen die twee — meestal door een site reliability engineer als orkestrator bij het ontwikkelteam te betrekken, en te beoordelen welke tools voor beide teams passend zijn. SRE-teams moeten met de interne opdrachtgever in gesprek over wat er werkelijk nodig is en welke capaciteit daarbij hoort.

SRE is een flinke investering, en organisaties moeten de invoering inrichten op basis van de opdracht en een toereikend budget. Elke sprint moet aan de organisatorische randvoorwaarden voldoen om klanten het product betrouwbaar te laten gebruiken. Dat vraagt zowel de juiste tools, zoals geautomatiseerde scripts, als organisatorische zaken — bijvoorbeeld ontwikkelteams die dienst hebben als producten in preproductie nog niet af zijn. Om dat haalbaar te houden wordt het SRE-werk aan handwerk en technische schuld begrensd op de helft van alle activiteiten.

SRE vraagt om een blameless analyse: begrijpen hoe teams van een probleem kunnen leren, in plaats van iemand de schuld geven. Dat betekent achterhalen wat het probleem heeft veroorzaakt, niet wat het had kunnen voorkomen, en zo nodig elk niveau van oorzakelijkheid bekijken in plaats van één enkele hoofdoorzaak. Na elk groot incident hoort een blameless postmortem, waarbij je zo veel mogelijk beschikbare databronnen benut.