Close

De weg naar beter incidentmanagement begint hier

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.

No matter how the incident is detected, your first step should be to record that a new incident is open in a tool for tracking incidents. In an incident management solution such as Jira Service Management, alerting and communication is integrated with your tracking tool.

Stel communicatiekanalen voor teams op

One of the first things the incident manager (IM) does when they come online is set up the incident team's communication channels. The goal at this point is to establish and focus all incident team communications in well-known places, such as:

  • 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?

The next step typically is to assign a severity level.

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

Sometimes the initial responders are the ones who resolve the incident. More often than not, those responders need to bring other teams into the incident by paging them using an alerting tool. With Jira Service Management, responders can take their pick as to what alerting method they use, or even use them all in one central location.

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

After a new incident responder is paged and comes online, the incident manager delegates a role to them. As It’s important they understand what's required of their role, and how to contribute to the incident team quickly and effectively.

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.

Conclusion

There are many moving parts to the incident response process. Keeping track of each step with seamless communication is easy with an incident management tool like Jira Service Management. Centralize alerts and unify teams with flexibility to resolve incidents quickly.