DevOps & Automatisering
Wat Gebeurt Er Als Software Engineers Operations Doen?
Binnen IT-organisaties is er altijd een inherente spanning geweest tussen twee kampen: Development (Dev) en Operations (Ops). Developers worden afgerekend op snelheid en het afleveren van nieuwe features, terwijl Operations-teams (Systeembeheerders) worden afgerekend op stabiliteit en uptime. Elke nieuwe release introduceert risico, waardoor Ops van nature terughoudend is. In 2003 besloot Google dit probleem fundamenteel anders aan te pakken. Ze stelden de vraag: “Wat gebeurt er als we de taak van een systeembeheerder geven aan software engineers?” Het antwoord was de geboorte van Site Reliability Engineering (SRE).
SRE is de concrete, technische implementatie van de DevOps-filosofie. In plaats van problemen handmatig op te lossen met scripts en reboots, schrijven SRE’s software die de infrastructuur automatiseert, beheert en zelfherstellend maakt. De kern van SRE ligt echter niet in de tools, maar in een radicale verandering van de bedrijfscultuur rondom uptime.
De Illusie van 100% Uptime en Error Budgets
De belangrijkste les uit het Google SRE-boek is dat 100% uptime het verkeerde doel is. Streven naar 100% beschikbaarheid is astronomisch duur, vertraagt innovatie tot stilstand en is fysiek onmogelijk (uw internetprovider of datacenter valt immers ook wel eens uit). In plaats daarvan introduceert SRE de concepten SLI (Service Level Indicator) en SLO (Service Level Objective).
Een SLI is een meetwaarde (bijv. de responstijd van de API is onder de 200ms). De SLO is het doel dat we met de business afspreken (bijv. 99,9% van de API-calls moet slagen in de komende maand). De speling tussen 100% en de SLO (dus 0,1%) is het magische concept van het ‘Error Budget’. Dit budget betekent dat we accepteren dat we deze maand 43 minuten downtime mogen hebben. Zolang er nog Error Budget over is, mogen ontwikkelaars vol gas nieuwe, risicovolle code naar productie pushen. Is het budget opgebruikt? Dan worden alle feature-releases bevroren (code freeze) en moet het hele team 100% focussen op het verbeteren van de stabiliteit totdat de nieuwe maand begint. Dit lijnt de doelen van Dev, Ops en de Business perfect uit.
Het Einde van de Heldencultuur (Toil Reduction)
In traditionele IT is de beheerder die midden in de nacht uit bed wordt gebeld, de server herstart en de dag redt, de held. In SRE is dit geen heldendaad, maar een symptoom van falend systeemontwerp. SRE streeft naar de eliminatie van ‘Toil’. Toil is handmatig, repetitief, tactisch werk dat lineair meegroeit met de grootte van de service (bijvoorbeeld het handmatig schalen van servers of het vrijmaken van schijfruimte).
SRE-teams hanteren een harde regel: maximaal 50% van hun tijd mag besteed worden aan operationeel werk (zoals storingsdiensten). De overige 50% moet besteed worden aan engineering en automatisering om ervoor te zorgen dat hetzelfde probleem nooit een tweede keer voorkomt. Gebeurt iets twee keer? Dan moet het geautomatiseerd worden (auto-remediation via scripts of Kubernetes).
Blameless Post-Mortems: Cultuur Boven Techniek
De grootste cultuurverandering in SRE is de ‘Blameless Post-Mortem’ na een incident. Wanneer de website crasht, wordt er niet gezocht naar wie de schuldige was (de developer die de verkeerde code pushte), maar naar wat in het systeem faalde waardoor die fout naar productie kon lekken. Dit psychologische veilige klimaat zorgt ervoor dat problemen niet onder het tapijt worden geveegd, maar transparant worden opgelost. Begrijp meer over de impact van SRE en automatisering op management-processen via deze evaluatie op Computable.
Volgende: FinOps in de Cloud: Kostenefficiëntie in AWS en Azure Beheersen
