Hou je van DevOps? Dan heb je nog niet kennisgemaakt met SRE

Wat is SRE nou weer?

Google's brein achter SRE, Ben Treynor, heeft nog steeds geen definitie van één zin gepubliceerd. Hij beschrijft de betrouwbaarheid van de site echter als 'wat er gebeurt als een software-engineer is belast met wat vroeger operationele activiteiten werd genoemd'.

Het onderliggende probleem is als volgt: ontwikkelteams willen geweldige nieuwe functies vrijgeven en die op grote schaal van start zien gaan. Ops-teams willen ervoor zorgen dat die functies de zaken niet kapot maken. Historisch gezien veroorzaakte dat een grote machtsstrijd, waarbij Ops zoveel mogelijk releases probeerde af te remmen, en Dev op zoek was naar slimme nieuwe manieren om om de processen heen te sluipen die hen tegenhouden. (Wedden dat dat bekend klinkt?)

SRE neemt het vermoeden en de discussie weg over wat er kan worden gelanceerd en wanneer. De methode introduceert een wiskundige formule voor lanceringen om te bepalen of deze door kan gaan of niet, en maakt een team van werknemers met Ops-vaardigheden (toepasselijk Service Reliability Engineers of SRE's genoemd) helemaal vrij om continu toezicht te houden op de betrouwbaarheid van het product. Zoals Google's eigen SRE Andrew Widdowson het beschrijft: "Ons werk is alsof we deel uitmaken van 's werelds meest intense pitcrew. We verwisselen de banden van een raceauto die 160 km/u rijdt."

Klinkt dat nog niet revolutionair? Veel van de magie zit hem in hoe ze werken. Hier zijn een aantal van hun kernprincipes, die toevallig ook een paar van de grootste afwijkingen zijn van traditionele IT-activiteiten.

Ten eerste krijgen nieuwe lanceringen groen licht op basis van de huidige productprestaties.

De meeste toepassingen bereiken geen uptime van 100%. Daarom stelt het SRE-team voor elke service een Service Level Agreement (SLA) op, waarin wordt vastgelegd hoe betrouwbaar het systeem moet zijn voor eindgebruikers. Als het team het eens is over een SLA van 99,9%, levert dat hen een foutenbudget op van 0,1%. Een foutenbudget is precies wat de naam doet vermoeden: het is de maximaal toegestane drempel voor fouten en uitval.

Protip: met dit coole spiekbriefje voor uptime kun je SLA's eenvoudig omzetten in 'minuten downtime' .

Hier is de crux: het ontwikkelteam kan dit foutenbudget op elke gewenste manier 'uitgeven'. Als het product momenteel foutloos werkt, kan het team starten wat het maar wil en wanneer het maar wil. Maar als ze het foutenbudget op is of is overschreden en er op of onder de gedefinieerde SLA wordt gewerkt, worden alle lanceringen bevroren totdat het aantal fouten is teruggebracht tot een niveau waarop de lancering kan doorgaan.

Wat daar zo vernuftig aan is? Zowel de SRE's als de ontwikkelaars hebben een sterke stimulans om samen te werken om het aantal fouten te minimaliseren.

SRE's kunnen ook programmeren

In het oude model zet je mensen in op een betrouwbaarheidsprobleem en blijf je pushen (soms een jaar of langer) totdat het probleem verdwijnt of verergert.

Zo niet bij SRE. Zowel het ontwikkel- als het SRE-team delen dezelfde medewerkers, dus voor elke SRE die wordt ingehuurd is er één ontwikkelaar minder beschikbaar (en vice versa). Dit maakt een einde aan de eindeloze strijd tussen Dev en Ops, en creëert een autonoom systeem waarbij ontwikkelaars worden beloond met meer teamgenoten voor het schrijven van beter presterende code (d.w.z. code die minder support nodig heeft van minder SRE's).

Ontwikkelaars zijn niet bang om hun handen uit de mouwen te steken

Bij Google moest Ben Treynor vechten voor deze clausule, en hij is blij dat hij dat deed. In zijn geweldige keynote over SRE op SREcon14 benadrukte hij zelfs dat het verplicht moet zijn om deze toezegging van je leidinggevenden te krijgen voordat je SRE lanceert.

In principe behandelt het ontwikkelingsteam 5% van alle operationele werklast (het afhandelen van tickets, het bieden van support op afroep enz.). Hierdoor kunnen ze nauw verbonden blijven met hun product, zien hoe het presteert en betere beslissingen nemen over het programmeren en releasen.

Bovendien wordt de overloop altijd toegewezen aan de ontwikkelaars zodra de operationele belasting de capaciteit van het SRE-team overschrijdt. Wanneer het systeem goed werkt, beginnen de ontwikkelaars hier ook zichzelf te reguleren, sterke code te schrijven en zorgvuldig te lanceren om toekomstige problemen te voorkomen.

SRE's zijn vrije agents (en kunnen indien nodig worden ingetrokken)

Om ervoor te zorgen dat teams gezond en gelukkig blijven, raadt Treynor aan om SRE's naar andere projecten te laten verhuizen zoals ze willen, of zelfs naar een andere organisatie te verhuizen. SRE moedigt zeer gemotiveerd, toegewijd en effectief teamwerk aan, dus geen enkel teamlid mag worden tegengehouden om zijn of haar eigen persoonlijke doelstellingen na te streven.

Als een heel team van SRE's en ontwikkelaars gewoon niet met elkaar overweg kan en meer problemen veroorzaakt dan betrouwbare code oplevert, is er een laatste drastische maatregel die je kunt nemen: haal het hele SRE-team van het project af en wijs alle operationele werklast rechtstreeks toe aan het ontwikkelingsteam. Treynor heeft dit in zijn hele carrière maar een paar keer gedaan, en de dreiging is meestal voldoende om beide teams tot een positievere werkrelatie te brengen.

SRE heeft nogal wat meer te bieden dan ik in één artikel kan behandelen, zoals hoe SRE productie-incidenten voorkomt, hoe ondersteuningsteams op afroep worden bemand en de regels die bij elke dienst worden gevolgd.

Onze visie

Laten we het beestje bij de naam noemen: IT zit vol modewoorden en trends. Het ene moment is het de 'cloud', het volgende moment is het DevOps of 'klantervaring' of 'gamification'. SRE bevindt zich in een sterke positie om veel meer te worden dan dat, vooral omdat het veel meer om de mensen en het proces gaat dan om de technologie die eraan ten grondslag ligt. Hoewel technologie zich zeker kan (en waarschijnlijk zal) aanpassen aan het concept naarmate het volwassen wordt en meer teams het toepassen, heb je geen nieuwe tools nodig om je ontwikkelingsorganisatie en operationele organisaties af te stemmen op de principes van Site Reliability Engineering.

In toekomstige artikelen zullen we dat nauwkeuriger bekijken en gaan we in op praktische stappen in de richting van SRE en de rol die technologie kan spelen.