Best practices en tips voor incidentrespons

1. Pak altijd een noodtas

Een 'noodtas' voor incidentresponders bevat alle kritieke informatie die teams nodig hebben met zo min mogelijk vertraging. Hoewel het waarschijnlijker is dat het een digitaal document is, profiteren incidentresponders er van om één gecentraliseerde startpunt te hebben.

Dit kan verschillende dingen omvatten:

• Incidentresponsplannen
• Lijsten met contactpersonen
• Op afroeprooster(s)
• Escalation policies
• Links naar vergadertools
• Toegangscodes
• Beleidsdocumenten
• Technische documentatie en runbooks

2. Keer runbooks niet de rug toe

Runbooks bieden richtlijnen over welke stappen moeten worden genomen in bepaalde scenario's. Ze zijn vooral belangrijk voor teams die op afroep werken wanneer een systeemexpert niet onmiddellijk beschikbaar is. Een goed onderhouden set runbooks stelt teams in staat om sneller te reageren en een gedeelde kennisdatabase van incidentresponswerkwijzen op te bouwen.

3. Omarm chaos, bevorder stabiliteit

Chaos Engineering is het experimenteren met systemen door opzettelijk storingen te injecteren om te begrijpen hoe systemen robuuster gebouwd kunnen worden. Een voorbeeld hiervan is Chaos Monkey. Chaos Monkey, oorspronkelijk ontwikkeld bij Netflix, is een tool die de veerkracht van het netwerk test door productiesystemen opzettelijk offline te halen.

4. Denk buiten het NOC

Historisch gezien fungeerden Network Operations Centers (NOCs) als de bewakings- en waarschuwingshub voor grootschalige IT-systemen. Met moderne hulpmiddelen voor incidentmanagement kan dit proces aanzienlijk worden gestroomlijnd. Door workflows voor het afleveren van waarschuwingen te automatiseren op basis van gedefinieerde alarmtypen, teamroosters en een escalatiebeleid, kan de kans op menselijke fouten en/of vertragingen worden verkleind.

5. Verenigen, niet verergeren

Niets is erger dan een voortdurend spervuur van waarschuwingen ontvangen afkomstig van meerdere bewakingstools. Door de stroom van waarschuwingen te centraliseren via één tool, kunnen teams de ruis beter filter, zodat ze zich snel kunnen concentreren op zaken die aandacht nodig hebben.

6. Onthoud: kennis is macht

Een basiswaarschuwing geeft aan dat er iets mis is, maar het geeft niet altijd weer wat. Dit veroorzaakt onnodige vertragingen omdat teams moeten uitvinden wat de oorzaak is. Door waarschuwingen te koppelen aan de technische details over waarom deze werden geactiveerd, kan het herstelproces sneller van start.

7. Waarschuwingen voor je waarschuwingen

De Latijnse uitdrukking 'quis custodiet ipsos custodes' (Wie bewaakt de bewakers?) geeft een universeel probleem weer. De bewakingstools die IT- en ontwikkelteams gebruiken, zijn even kwetsbaar voor incidenten en downtime als de systemen die ze moeten beschermen. Holistische waarschuwingsprocessen zorgen ervoor dat zowel de systemen als de tools die ze bewaken, voortdurend worden gecontroleerd op gezondheid.

8. Stelp het bloeden

Triagisten weten dat ze meer schade riskeren als ze vastlopen in een poging om alle situaties op te lossen zodra ze aankomen. Hun focus ligt op kortetermijnacties die een patiënt voldoende stabiliseren om diegene naar meer acute zorg te brengen. Op technische gebieden richten insluitingsacties zich op tijdelijke oplossingen (het isoleren van een netwerk, het terugdraaien van een build, het opnieuw opstarten van servers enz.) die op zijn minst de scope van het incident beperken of, idealiter, systemen weer online brengen.

9. Doe het niet alleen

Heldencultuur in IT- en DevOps-teams is een uitstervende filosofie. Het is niet meer in de mode om de eenzame engineer te zijn die eindeloze avond- en weekenduren werkt, omdat deze de enige is die systemen weer online kan brengen. In plaats daarvan werken teams zoals het hoort, als teams. Het proces is slechts zo sterk als de zwakste schakel. Probeer het hele team te koesteren en niet slechts één eenzame rockster.

10. Wees transparant

Als gebruikers worden geconfronteerd met een serviceonderbreking, is het gebruikelijk dat het incident op korte termijn openbaar wordt gemaakt. Om dit voor te blijven, moeten teams een communicatieplan voor incidenten klaar hebben liggen. Het doel is om vertrouwen op te bouwen bij klanten door publiekelijk te erkennen dat er een verstoring plaatsvindt en ervoor te zorgen dat er stappen worden ondernomen om deze op te lossen. Tools zoals Statuspage zijn geweldig voor dergelijke informatie verspreiden.

11. Leer van fouten

IT- en DevOps-teams zullen eensgezind zeggen dat ze alleen de tijd nemen om 'grote storingen' te beoordelen. Hoewel dit een goed begin is, worden daardoor vaak kleinere incidenten over het hoofd gezien die een aanhoudende impact kunnen hebben. Een uitgebreid rapport is misschien niet nodig voor alle incidenten, maar een postmortemanalyse is altijd nuttig.

12. Zoek de hoofdoorzaak (er is geen hoofdoorzaak!)

Of toch? Bij het analyseren van een incident komt het zelden voor dat er een maar één ding aangewezen kan worden als hoofdoorzaak. Vaak zijn systemen veel te complex en onderling afhankelijk om een enkele hoofdoorzaak van een incident te definiëren. Zelfs als de hoofdoorzaak duidelijk lijkt (bijvoorbeeld een toetsaanslagfout waardoor een toepassing crasht), zijn er vaak nog externe factoren die meespelen waardoor de toepassing crasht (of waardoor dit niet is voorkomen). Voor een beter begrip van je incidenten, zoek je naar verschillende hoofdoorzaken.

13. Geen verwijten

Het doel van elk incidentpostmortem moet zijn om te begrijpen wat er mis is gegaan en wat er kan worden gedaan om soortgelijke incidenten in de toekomst te voorkomen. Belangrijk is dat dit proces niet moet worden gebruikt om een schuldige aan te wijzen. Dat komt omdat teams die zich richten op het 'wie' en niet op het 'wat' emoties de overhand laten nemen wat afneemt van echt begrijpen wat er is gebeurd.

Nog iets anders

In moderne incidentmanagement-omgevingen is verandering de enige constante. Dit betekent dat systemen voortdurend op nieuwe en verschillende manieren zullen worden getest. Teams die dit begrijpen, begrijpen ook dat het niet gaat om of, maar om wanneer systemen falen. Het nemen van voorbereidende stappen op deze onderbrekingen moet worden erkend worden als een cruciaal element van aanhoudend succes, en geïntegreerd worden in het DNA van technische teams.

Een oplossing voor incidentmanagement zoals Jira Service Management helpt je bij elk van deze 13 punten, van het organiseren van je op afroeprooster en -waarschuwingen tot het verenigen van teams voor betere samenwerking en het uitvoeren van incidentpostmortems.