Blijf verantwoordelijk na de deployment

Definieer de service waarop gebruikers vertrouwen

Een deployment maakt software beschikbaar. Beheer houdt die software bruikbaar terwijl gebruikers, dependencies, verkeer en eisen veranderen. Een codegenerator neemt dit doorlopende werk niet weg.

Bij een fictieve klantenexport hebben gebruikers meer nodig dan een bereikbare pagina. Ze hebben de toegestane records nodig, in het vereiste formaat en binnen een aanvaardbare tijd. De service moet ook voorkomen dat ze gegevens van een andere organisatie kunnen inzien.

Benoem de verantwoordelijke vóór de release. Leg vast wie buiten normale werktijden reageert als dat deel uitmaakt van de servicetoezegging. Een leverancier kan werk uitvoeren, maar de organisatie heeft nog steeds een duidelijke route nodig voor beslissingen en communicatie.

Kies signalen die tot actie leiden

Een service-level indicator, of SLI, meet een gedefinieerde eigenschap van het servicegedrag. Een service-level objective, of SLO, stelt voor die indicator een doel over een bepaalde periode. Kies het doel op basis van gebruikersbehoeften en de mogelijkheden van het beheer.

De SRE-richtlijnen van Google leggen deze aanpak uit en beschrijven het gebruik van een error budget bij betrouwbaarheidsbeslissingen. Neem het doel van een andere service niet over zonder de betekenis te controleren. Richtlijnen voor SLO’s, voorbeeldbeleid voor een error budget.

Definieer voor de export wat telt als een geslaagde aanvraag die aan de voorwaarden voldoet. Scheid verwachte weigeringen van systeemfouten. Documenteer uitzonderingen, zodat een meetwaarde niet beter kan worden door lastige aanvragen te verbergen.

Log geen volledige exports om meer inzicht te krijgen. Verzamel alleen de informatie die nodig is om het probleem te onderzoeken en bescherm de toegang ertoe.

Bereid de incidentrespons voor

Bepaal wie coördineert, wie onderzoekt en wie communiceert. In een klein team kunnen deze rollen worden gecombineerd, maar de verantwoordelijkheden moeten duidelijk blijven. Houd waarnemingen en acties bij.

De incidentresponsrichtlijnen van Google benadrukken coördinatie en communicatie naast technische maatregelen. Ook bij een technisch juiste oplossing kunnen gebruikers zonder informatie blijven of kunnen meerdere betrokkenen tegenstrijdige wijzigingen maken. Incidentrespons.

Een agent kan logs samenvatten of hypotheses vergelijken binnen goedgekeurde gegevensgrenzen. De urgentie van een incident mag geen onbeperkte productiebevoegdheid opleveren. Gebruik een vastgelegde escalatieroute voor uitzonderlijke toegang.

Oefen herstel en reserveer middelen voor onderhoud

Test de herstelprocedure met representatieve fictieve gegevens. Bepaal wat een rollback van code niet kan terugdraaien, zoals verwijderde records of al verzonden berichten. Leg vast hoeveel tijd en welke informatie nodig zijn om de service te herstellen.

Wijs doorlopend werk toe: dependency-updates, toegangsreviews, certificaatvernieuwing waar nodig, capaciteitswijzigingen en correcties in documentatie. Een service zonder onderhoudscapaciteit blijft verplichtingen opbouwen nadat het budget voor de lancering op is.

Kies na een incident verbeteringen die de waargenomen oorzaken aanpakken. Verbind ze met implementatie en verificatie. Zo sluit u de levenscyclus: bewijs uit het beheer verandert wat het team vervolgens specificeert en bouwt.