Close

Krijg 30% korting als je je aanmeldt voor Jira Service Management

Incidentmanagement voor razendsnelle teams

De 7 fasen van effectieve incidentrespons

Incidentrespons is het proces van een organisatie om te reageren op IT-bedreigingen zoals cyberaanvallen, inbreuk op de beveiliging en serverdowntime.

Andere IT Ops- en DevOps-teams kunnen naar de praktijk verwijzen als beheer van grote incidenten of gewoon incidentmanagement.

De volgende gedeelten beschrijven een incidentresponsproces, wat je moet doen tussen het besef dat een service niet werkt en deze weer operationeel maken, op basis van het materiaal in ons eigen Incidentengids.

In dit artikel behandelen we de zeven belangrijkste fasen van incidentrespons:

  1. Detecteer het incident
  2. Stel communicatiekanalen voor teams op
  3. Beoordeel de impact en pas een ernstniveau toe
  4. Communiceer met klanten
  5. Escaleer naar de juiste responders
  6. Delegeer rollen voor incidentrespons
  7. Los het incident op
Workflow voor incidentrespons

Detecteer het incident

Idealiter zullen monitoring- en waarschuwingstools incidenten detecteren en jet team informeren over een incident voordat je klanten het merken. Maar soms vertellen klanten of teamleden je als eerst over een incident via Twitter of een klantenserviceticket.

Het maakt niet uit hoe het incident wordt gedetecteerd, je eerste stap zou moeten zijn om vast te leggen dat een nieuw incident is geopend in een tool voor incidenttracking. Bij een incidentmanagementoplossing zoals Jira Service Management zijn waarschuwingen en communicatie geïntegreerd in je trackingtool.

Stel communicatiekanalen voor teams op

Een van de eerste dingen die de incidentmanager (IM) doet wanneer deze online komt, is het opzetten van de communicatiekanalen voor het incidentteam. Het doel is op dit punt om alle communicatie van het incidentteam op bekende plaatsen op te zetten en te concentreren, zoals: via

  • Een chatruimte in Slack of in een andere berichtenservice.
  • Videochat in een vergaderapp zoals Zoom (of als jullie allemaal op dezelfde plek zijn, verzamel het team in een fysieke ruimte).

We gebruiken bij incidenten het liefst zowel videochat als een tekstchattool, omdat beide uitblinken in verschillende dingen. Videochat is geweldig om snel een gedeeld mentaal beeld van het incident te creëren door middel van groepsdiscussies. En Slack helpt bij het genereren van een tijdstempel van het incident, samen met verzamelde links naar screenshots, URL's en dashboards.

Met Slack en de meeste andere chattools kunnen gebruikers een ruimte-onderwerp instellen. De incidentmanager moet dit veld gebruiken voor informatie over het incident en nuttige links.

Ten slotte stelt de IM de eigen persoonlijke chatstatus in op de issuecode van het incident dat ze beheren. Zo weten collega's dat ze bezig zijn met het beheren van een incident.

Beoordeel de impact en pas een ernstniveau toe

Als de communicatiekanalen voor het team voor het incident zijn ingesteld, is het tijd om het incident te beoordelen zodat het team kan besluiten wat ze mensen erover gaan vertellen en wie het moet herstellen.

De volgende vragen worden door IM's aan hun teams gesteld:

  • Wat is de impact voor klanten (intern of extern)?
  • Wat zien klanten?
  • Op hoeveel klanten heeft het impact (enkele, allemaal)?
  • Wanneer is het begonnen?
  • Hoeveel support cases hebben klanten geopend?
  • Is er sprake van overige factoren zoals Twitter, beveiliging, of gegevensverlies?

De volgende stap is meestal een ernstniveau toewijzen.

Ernstniveaus van incidentrespons

Ernst 1
Beschrijving: een kritiek incident met een zeer grote impact
Voorbeelden:

  • Een klantgerichte service is niet beschikbaar voor alle gebruikers
  • Vertrouwelijkheid of privacy is geschonden
  • Gegevensverlies klant.

Ernst 2
Een groot incident met aanzienlijke gevolgen
Voorbeelden:

  • Een klantgerichte service is niet beschikbaar voor een aantal klanten
  • De kernfunctionaliteit wordt aanzienlijk beïnvloed.

Ernst 3
Een klein incident met weinig impact
Voorbeelden:

  • Een klein ongemak voor klanten, kan worden omzeild.
  • Werkbare lagere prestaties.

Het gebruik van een nummeringssysteem voor ernstniveaus helpt het incident snel te definiëren en erover te communiceren. Het enige wat iemand hoeft te zeggen is 'we hebben misschien te maken met een ernst 1' en de juiste mensen kunnen onmiddellijk de ernst van de zaak begrijpen, zelfs voordat ze aanvullende informatie krijgen.

Ernstniveaus kunnen ook helpen bij het opzetten van richtlijnen voor responsverwachtingen.

Bij sommige bedrijven kunnen incidenten met ernst 3 bijvoorbeeld tijdens kantooruren worden aangepakt, terwijl voor ernst 1 en 2 teamleden moeten worden opgeroepen voor een onmiddellijke oplossing (buiten kantoortijd).

Definities van de ernst van incidenten moeten gedocumenteerd en consistent zijn in de hele organisatie.

Communiceer met klanten

Zodra een team vaststelt dat het incident echt is, is het het beste om zo snel mogelijk intern en extern erover te communiceren met belanghebbenden.

Het doel van interne communicatie is om de incidentrespons op één plek te concentreren en verwarring te verminderen.

Het doel van externe communicatie is om klanten te vertellen dat het team zich ervan bewust is dat er iets niet werkt en dat je ermee bezig bent. Snel en nauwkeurig communiceren helpt bij het opbouwen van vertrouwen bij klanten en de rest van de organisatie.

Veel teams gebruiken Statuspage voor incidentcommunicatie, zowel intern als extern. Hier zijn twee eenvoudige sjablonen voor het updaten van een interne of externe statuspagina:

Interne Statuspage
- -

We onderzoeken een incident met betrekking tot, en . We zullen binnenkort updates verstrekken via e-mail en Statuspage.

Externe Statuspage
We onderzoeken problemen met

We onderzoeken problemen met en zullen hier binnenkort updates geven.

Escaleer naar de juiste responders

Soms zijn de eerste responders degenen die het incident oplossen. Vaak moeten die responders dan wel andere teams bij het incident betrekken door ze op te roepen met behulp van een waarschuwingstool. Met Jira Service Management kunnen responders zelf kiezen welke waarschuwingsmethode ze gebruiken, of ze zelfs allemaal op één centrale locatie gebruiken.

Met waarschuwingstools kunnen teams op afroeproosters definiëren om een roulatie te creëren van personeel dat naar verwachting bereikbaar is tijdens een incident. Dit is beter dan elke keer dat er een incident is op een specifiek persoon vertrouwen. Diezelfde persoon zal niet altijd beschikbaar zijn (ze nemen vakantie, veranderen van baan of krijgen een burn-out als je ze te vaak belt).

Delegeer rollen voor incidentrespons

Nadat een nieuwe incidentresponder is opgeroepen en online is gekomen, wordt door de incidentmanager een rol aan diegene gedelegeerd. Het is belangrijk dat deze begrijpt wat er van hen verwacht wordt en hoe diegene snel en effectief kan bijdragen aan het incidentteam.

Een ander voordeel van het definiëren van rollen is dat het meer aanpassingsvermogen en flexibiliteit mogelijk maakt. Zolang iemand weet hoe een bepaalde rol moet worden ingevuld, kan diegene die rol voor elk incident op zich nemen.

Drie belangrijke rollen voor incidentrespons

Incidentmanager

Ieder incident wordt gemanaged door de incidentmanager, die verantwoordelijk is en de leiding heeft over het aanpakken van het incident.

De incidentmanager is gemachtigd om alle nodige maatregelen te nemen om het incident op te lossen, waaronder iedereen binnen de organisatie op de hoogte brengen en de aandacht van mensen die betrokken zijn bij een incident gericht houden op het zo snel mogelijk herstellen van de service.

Technisch onderzoeksleider

Een senior technische responder. De techlead is verantwoordelijk voor het ontwikkelen van theorieën over wat er defect is en waarom, het nemen van beslissen over wijzigingen en het leiden van het technische team. Deze persoon werkt nauw samen met de incidentmanager.

Communicatiemanager

Dit is de persoon die bekend is met openbare communicatie, mogelijk komt deze van het klantenserviceteam of public relations. Deze persoon is verantwoordelijk voor zowel het schrijven als verzenden van interne en externe communicatie over het incident.

Los het incident op

Er is geen one-size-fits-all proces dat elk incident kan oplossen. Als dat zo was, zouden we dat gewoon automatiseren en er klaar mee zijn. Laat je in plaats daarvan inspireren door de wetenschappelijke methode. Herhaal het volgende proces om je snel aan te passen aan verschillende scenario's voor incidentrespons:

  • Kijk wat er aan de hand is. Deel en bevestig observaties.
  • Ontwikkel theorieën waarom het gebeurt.
  • Ontwikkelen experimenten en voer ze uit om je theorieën te bewijzen of te weerleggen.
  • Herhaal dit totdat het incident is opgelost.

Een incident is opgelost als de huidige of dreigende impact op het bedrijf is geëindigd. Op dat moment eindigt de noodrespons en gaat het team verder met secundaire taken en de postmortem.

We sturen de laatste interne en externe communicatie wanneer het incident is opgelost. De interne communicatie bevat een samenvatting van de impact en duur van het incident, zoals het aantal supportcases dat is ingediend en andere belangrijke incidentdimensies. Er moet ook duidelijk worden vermeld dat het incident is opgelost en dat er geen verdere communicatie over zal zijn. De externe communicatie is meestal kort en vertelt klanten dat de service is hersteld en dat het team zal opvolgen met een postmortem.

Conclusie

Er zijn veel bewegende onderdelen in het incidentresponsproces. Elke stap bijhouden met naadloze communicatie is eenvoudig met een tool voor incidentmanagement zoals Jira Service Management. Centraliseer waarschuwingen en breng teams samen met de flexibiliteit om snel op incidenten te kunnen reageren en deze op te oplossen.