Belangrijke SRE-principes en -procedures: de menselijke kant van SRE
Een geslaagd bewerkingsproces is een proces dat de gewenste betrouwbaarheid bereikt en het ondersteunt. Een dergelijk proces is net zo afhankelijk van hoe het de mensen behandelt die verantwoordelijk zijn voor die omgeving, omdat het afhankelijk is van hoe het machines behandelt. Site reliability engineering erkent deze waarheid op veel manieren die cruciaal zijn voor zijn praktijk.
Toil
De eerste is gericht op het begrip 'toil'. In een SRE-context verwijst toil naar werk dat wordt gedaan door een persoon dat bepaalde kenmerken heeft. Toil heeft geen meerwaarde op de lange termijn. Het helpt de service niet op een betekenisvolle manier vooruit. Het is vaak herhalend en grotendeels handmatig (ook al kan het worden geautomatiseerd). Naarmate de service of het systeem groter wordt na verloop van tijd, neemt het aantal aanvragen voor dat systeem waarschijnlijk ook evenredig toe en is er zelfs nog meer handmatig werk vereist.
Een service kan bijvoorbeeld vereisen dat het SRE-team operationele belastingen als deze laadt die als toil worden beschouwd:
- Elke week iets opnieuw instellen.
- Nieuwe accounts en schijfruimte handmatig inrichten.
- Herhaaldelijk opnieuw opstarten van een proces met de hand.
Door deze acties te voltooien, wordt de service op lange termijn niet beter. Het is ook waarschijnlijk dat deze acties telkens opnieuw moeten worden herhaald.
Notitie
Zelfs als u aanvragen van deze aard in een soort ticketsysteem houdt, zoals veel wordt gedaan, is het uitvoeren van de actie en het oplossen van een ticket nog steeds toil. Het is alleen maar goed bijgehouden toil.
SRE's hebben een hekel aan toil. Ze proberen om het zoveel en indien mogelijk te voorkomen. Dit doel is een van de plaatsen waar automatisering in SRE in het spel komt. Als deze aanvragen automatisch kunnen worden verwerkt, heeft het team meer tijd om te werken aan dingen die stimulerend zijn en meer impact hebben dan het leegmaken van de aanvraagwachtrij.
Het gebruik van het woord 'passend' ten opzichte van toil is vergelijkbaar met het gebruik ervan rond betrouwbaarheid. Er zijn situaties waarin het terugbrengen van toil opheffing minder prioriteit heeft dan andere werkzaamheden, maar over het algemeen is het elimineren van toil uit een service een belangrijke focus voor een SRE.
Projectwerk versus reactief 'ops'-werk
Om het werk te doen dat nodig is om toil te verwijderen of de betrouwbaarheid van een systeem te verbeteren, moet de tijd van een SRE op de juiste manier worden toegewezen. Ze willen ervoor zorgen dat ze niet al hun tijd besteden aan brandbestrijding, het beantwoorden van pagina's of het verwerken van een ticketwachtrij. Ze moeten de tijd hebben om code te schrijven om toil te verwijderen, selfservice automatisering te maken zodat tickets niet nodig zijn, projecten te bouwen die de service en de mensen efficiënter maken. Het cijfer dat meestal wordt genoemd (dat afkomstig is uit het oorspronkelijke Google-model) is een van niet meer dan 50% operationele belasting van een team.
Notitie
50% is een enigszins willekeurig getal, maar in de praktijk lijkt het als een redelijke doelstelling voor veel mensen te werken.
Er zijn momenten in het leven van een SRE wanneer al hun tijd wordt besteed aan het blussen van brandjes, maar dat kan geen stabiele status zijn. Als het reactieve 'ops'-werk van een team (waarvan veel toil is) meer dan 50% van de tijd gedurende een langere periode in beslag neemt, is dit een recept voor burn-out en verminderde betrouwbaarheid. In deze situatie kunnen de correcte cycli die we eerder hebben besproken, niet werken of worden gebouwd. SRE besteedt op dezelfde manier aandacht aan slecht verdeelde on-call belasting, omdat dat ook het potentieel heeft voor een sterke negatieve impact op het team.
Nu we enkele van de kernprocedures en beginselen van SRE hebben gezien, gaan we het hebben over hoe u aan de slag kunt gaan.