Hoe begint u met SRE?

Crowd of passengers having fun in a bustling city on a vibrant floor

Published on June 2022 by Arjan Franzen

A rising stair of platforms with only the first one built, illustrating the first step into SRE.

Misschien heeft u inmiddels enkele DevOps-principes en -processen ingevoerd. De volgende stap is opschalen met SRE. Dit zijn beproefde methoden om teams snel op weg te helpen met SRE-principes:

Introduceer Service Level Objectives (SLO's) en Error Budget

SRE-teams stellen samen met stakeholders Service Level Objectives (SLO's) vast. SLO's definiëren het serviceniveau dat klanten mogen verwachten. Dat serviceniveau wordt gemeten met Service Level Indicators (SLI's). SLI's evalueren de kritieke aspecten van de service.

SLO's bepalen ook hoeveel tijd een applicatie onbeschikbaar mag zijn; die speelruimte kunt u inzetten voor innovatie en het verbeteren van betrouwbaarheid. Deze toelaatbare downtime heet het “Error Budget”: de toegestane marge voor defecten en storingen, die het developmentteam kan “opmaken” om features te bouwen of te repareren totdat het budget verbruikt is. ZEN Software’s Agile Analytics biedt een uitstekende suite om Error Budgets — de hoeveelheid onbetrouwbaarheid die een team mag opmaken voordat betrouwbaarheidswerk voorgaat — te beheren en te volgen voor uw organisatie.

Zo borgt u zowel beschikbaarheid als de flexibiliteit om het bestaande systeem te verbeteren of te updaten. Traditionele uptime-metingen zijn voor complexe systemen onvoldoende, omdat ze veronderstellen dat alle services gelijk zijn. SRE meet beschikbaarheid daarom met een formule die berekent hoeveel klantinteracties succesvol zijn:

                        aantal succesvolle requests
     Beschikbaarheid = -------------------------------------
                               totale requests

SLO's meten de performance van de service met de SLI. De Service Level Indicator (SLI) is een numerieke waarde (bijv. 99,981%). Trek de onbetrouwbaarheid van de vorige periode af van het SLO en wat overblijft is het Error Budget. Dat rekent u om naar een aantal minuten toelaatbare downtime per maand, die u mag inzetten voor innovatie en experimenten. (Figuur 2) In deze figuur ziet u het Error Budget voor beschikbaarheid geleidelijk afnemen door kleine maar constante problemen.

ZEN Software’s Agile Analytics laat u de performance van uw services (in real time) volgen en observeren, en corrigerend ingrijpen wanneer Error Budgets opraken.

An error budget declining steadily across a month until it is exhausted.

Inzien dat het verbeteren van betrouwbaarheid en performance een organisatievraagstuk is

Beschikbaarheid verbeteren vraagt om ontwikkelaars en operations-teams op één lijn te brengen. SRE vraagt om een goed begrip van hoe die twee op elkaar inwerken. Meestal komt er een site reliability engineer bij het ontwikkelteam die het werk afstemt en bepaalt welke tools voor beide teams geschikt zijn. SRE-teams moeten met de businessklant onderhandelen over behoeften en capaciteit.

Borgen dat teams de organisatorische capaciteit hebben om SRE te leveren

SRE is een aanzienlijke investering; organisaties moeten de implementatie organiseren op basis van de missie en een passend budget. Elke sprint moet de juiste organisatorische randvoorwaarden bevatten zodat klanten het product betrouwbaar kunnen gebruiken. Dat vereist zowel de beschikbaarheid van de juiste tools, zoals geautomatiseerde scripts, als organisatorische afspraken, zoals developmentteams die stand-by zijn wanneer producten in preproductie nog niet compleet zijn. Om dit te bereiken, wordt SRE-werk gericht op het beheersen van toil (repeterend handmatig beheerwerk) en technische schuld begrensd tot de helft van alle activiteiten, zodat er voldoende capaciteit is om dit te beheren.

Focus op het probleem, niet op de schuldvraag

SRE vraagt om een blameless analyse waarin teams leren van een probleem in plaats van schuld toe te wijzen. Het gaat erom te begrijpen waardoor het probleem is ontstaan, niet wat het had kunnen voorkomen, en desnoods meerdere lagen van oorzakelijkheid te doorgronden in plaats van één enkel root cause. Blameless Postmortems moeten na elk groot incident worden uitgevoerd, met nadruk op het benutten van alle beschikbare databronnen.