Google is de bedenker van SRE (Site Reliability Engineering) practices. Een site is hierbij een website. Dit klinkt allemaal simpel, even websiteje in de lucht houden. Maar dat is het natuurlijk niet als je een enorme website hebt met honderden miljoenen gebruikers.
De best practices van Google kunnen gebruikt worden in beheer van software en ook daarbuiten.
De belangrijkste principes:
- Betrouwbaarheid is het belangrijkste
- Meet automatisch hoe een website er voor staat:
- Beschikbaarheid
- Performance
- Doen alle functies het
- Meet wat gebruikers ervaren! Dit is wat telt.
- Meet automatisch hoe een website er voor staat:
- Bepaal het fout budget. Als de website er te veel uitligt, traag is, het niet doet, dan kost dit te veel geld. Dan wordt er gestopt met maken van nieuwe functies en wordt eerst de energie gericht op het weer betrouwbaar maken van de site. Dit is niet makkelijk in de praktijk; in veel organisaties is een splitsing tussen beheer en ontwikkeling. Die splitsing helpt niet, want beheer wil stabiliteit, maar de ontwikkelaars worden vaak afgerekend op nieuwe functies (en niet op stabiliteit). Door dit principe zo te formuleren balanceert de SRE methode van Google tussen beheer betrouwbaarheid en nieuwe functies.
- Automatiseer handmatig beheer werk: achtergrond is dat de site schaalbaar moet zijn. Dus als de site een success is en volgend jaar er 10 keer meer gebruik is, dan wil je niet dat het handwerk voor beheer ook 10 keer zo veel is. Dus om op te kunnen schalen moet handwerk geautomatiseerd worden.
- Monitoring en observeerbaarheid. Dit wordt vaak verward, maar zijn 2 losse zaken:
- Monitoring: is er NU wat kapot is en niet werkt?
- Observeerbaarheid: heb ik alle data om te achterhalen wat er is gebeurd? Dit betekent het op orde hebben van logging, traces, enz.
- Foutanalyses op basis van feiten en zonder schuldigen aan te wijzen. Als iets mis gaat is de neiging vaak om te achterhalen wie een fout heeft gemaakt. Dit leidt dan vaak tot het verkeerde gedrag: niet doorvragen naar de echte oorzaak, mensen worden bang om fouten te maken en/of toe te geven. Foutanalyses moeten gaan over feiten en wat heeft bijgedragen aan die fout (fishbone analysis). Van hier uit preventieve acties definieren en de foutbronnen aanpakken. “Improve systems, not blame people.”
- Denk na over het actief maken van wijzigingen: kunnen die gradueel? Kun je eerst met een kleine test groep? Kun je makkelijk terugdraaien als er problemen zijn?
De volledige practices kunnen bekeken worden bij de SRE site van Google zelf.