Reageren op een incident

Detecteren

Mensen binnen het bedrijf kunnen op veel manieren incidenten ontdekken. Incidenten kunnen gemeld worden via monitoring, via klantmeldingen, of door ze zelf te constateren. Hoe een incident ook plaatsvindt, het eerste dat een team doet is een incidentticket opslaan (in ons geval een Jira-issue).

Een nieuw incident aanmaken

Als de incident-issue is aangemaakt maar nog niet is toegewezen aan een incidentmanager (IM), bevindt het incident zich in een nieuwe status. Dit is de oorspronkelijke status in ons Jira-incidentproces.

We hebben een service die Jira-webhooks gebruikt om een paginamelding te activeren als er een nieuw groot incident is aangemaakt. De dienstdoende IM wordt ingelicht op basis van de geselecteerde service. Bij een incident met Bitbucket wordt bijvoorbeeld een Bitbucket-incidentmanager ingelicht. We hebben ook een algemeen rooster met grote incidentmanagers die we ‘dienstdoende incidentmanager’ of IMOC noemen.

De paginamelding bevat de issuesleutel van het incident, het niveau en een overzicht, waarin de manager verteld wordt waar hij of zij naartoe moet om het incident (de Jira-issue) te managen, wat er over het algemeen fout is en hoe ernstig het is.

Opmerkingen openen

Het eerste dat de IM doet als deze online komt, is de issue van het incident aan zichzelf toewijzen en de issue instellen op de status wordt opgelost. Het Jira-issueveld Uitvoerder geeft ook aan wie de huidige IM is. Tijdens noodrespons is het erg belangrijk om duidelijk te geven wie de leiding heeft, dus letten we er altijd op dat dit veld juist is ingevuld.

Vervolgens stelt de IM de communicatiekanalen van het team voor het incident op. Het doel op dit moment is om alle communicatie van het team voor het incident op bekende plaatsen in te stellen en te focussen. Normaal gesproken gebruiken we drie communicatiemethodes voor teams, die alle drie vertegenwoordigd worden door een veld in de Jira-issue, voor ieder incident:

• Een chatruimte in Slack of in een andere berichtenservice. Op deze manier kan het team communiceren, observaties, links en schermafbeeldingen delen met tijdstempels en de optie om zaken op te slaan. Als je het chatkanaal dezelfde naam geeft als de issuesleutel (bijvoorbeeld HOT-1234) is het eenvoudiger voor betrokkenen om aan het gesprek deel te nemen.
• Videochat in een conferentie-app zoals Skype, Blue Jeans of iets vergelijkbaars; of als je allemaal op dezelfde locatie bent, roep je het team bij elkaar in een fysieke ruimte. Onze ervaring is dat persoonlijke communicatie ervoor zorgt dat teams zaken sneller doornemen zonder al te veel kastjes en muren.
• Een Confluence-pagina met de naam ‘incidentstatusdocument’. Als mensen tegelijkertijd dezelfde pagina bewerken, kunnen ze in realtime bekijken welke informatie er wordt verzameld. Dit is een geweldige manier om wijzigingen in de gaten te houden (bijvoorbeeld een tabel met wie wat heeft gewijzigd, wanneer, hoe, waarom, hoe terug te draaien, etc.), meerdere werkstromen, of een verlengde tijdlijn. Een incidentstatusdocument is zeer handig als waarheidsbron tijdens complexe of verlengde incidenten.

We hebben ontdekt dat zowel videochat als een chatruimte gebruiken het beste werkt tijdens een incident, aangezien beide geoptimaliseerd zijn voor verschillende zaken. Videochat blinkt uit in het snel creëren van een gedeelde mentale voorstelling van het incident via groepsdiscussies, terwijl tekstchat geweldig is om een record met tijden, gedeelde links naar dashboards, schermafbeeldingen en andere URL's bij te houden voor het incident.

Deze methodes kunnen ook worden gebruikt om belangrijke observaties, wijzigingen en besluiten op te slaan die in niet-opgeslagen gesprekken voorbijkomen. De IM of iemand van het incidentteam doet dit door observaties, wijzigingen en besluiten gewoon in de daarvoor bestemde chatroom op te merken als ze zich in realtime voordoen. Het is geen probleem als het erop lijkt dat mensen tegen zichzelf praten! Deze aantekeningen zijn ontzettend waardevol tijdens de postmortem als teams de tijdlijn van het incident moeten reconstrueren en achterhalen wat de oorzaak is.

De meeste chatsystemen hebben een een functie voor onderwerp in de chatruimte. De IM werkt het onderwerp in de ruimte bij met informatie over het incident en handige links, zoals:

• Een samenvatting en het niveau van het incident.
• Wie vervult welke rol, te beginnen bij de IM.
• Links naar de incident-issue, de video-chatruimte en het incidentstatusdocument.

Op deze manier kan iedereen met een issuesleutel deelnemen aan de chat en op de hoogte worden gebracht over het incident (vergeet niet dat we het chatkanaal een naam hebben gegeven op basis van de issuesleutel van het incident, bijvoorbeeld HOT-1234).

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.

Beoordelen

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?

Het is nu het juiste moment om de tijdlijn van het incident in te vullen. Sla de observaties van het team op, zodat mensen die erbij komen snel op de hoogte zijn. Dit is later in het postmortem-proces ook van belang. Noteer of de starttijd van het incident overeenkomt met een wijziging (bijvoorbeeld een Bamboo-implementatie) zodat die wijziging teruggerold kan worden om het incident mogelijk op te lossen.

Op basis van de impact van het incident en de hoeveelheid werk die volgens onze teams vereist is om het op te lossen, wijzen we issues toe met een van de volgende niveaus:

Eerste communicatie versturen

Als je er redelijk zeker van bent dat het een echt incident betreft, wil je dit natuurlijk zo snel mogelijk intern en extern communiceren. Het doel van initiële interne communicatie is de incidentrespons op één plek te concentreren en verwarring te voorkomen. Het doel van externe communicatie is klanten vertellen dat je weet dat er iets niet werkt en dat je dit zo snel mogelijk probeert op te lossen. Snelle en accurate communicatie rondom incidenten helpt vertrouwen opbouwen onder medewerkers en klanten.

We gebruiken Statuspage voor interne en externe communicatie over incidenten. We hebben verschillende statuspagina's voor interne bedrijfsmedewerkers en externe klanten. Later vertellen we meer over het gebruik ervan, maar nu is het doel om zo snel mogelijk communicatie op te zetten. Om dat te doen, volgen we deze sjablonen:

Escaleren

Je hebt het incident onder je hoede genomen, teamcommunicatie opgesteld, de situatie beoordeeld en medewerkers en klanten verteld dat er sprake is van een incident. En nu?

De eerste reacties kunnen van de mensen zijn die je nodig hebt om het incident op te lossen, maar meestal moet je andere teams bij het incident betrekken door ze op de hoogte te stellen. Dit noemen we escalatie.

Het belangrijkste systeem tijdens deze stap is een rooster en meldtool zoals OpsGenie. Met OpsGenie en vergelijkbare systemen kun je dienstroosters opstellen, zodat iedere team een roulatiesysteem van medewerkers heeft die beschikbaar moeten zijn om op een noodgeval te reageren. Dit is beter dan iedere keer dezelfde persoon nodig te hebben (‘’roep Bob er maar weer bij’), omdat individuen niet altijd beschikbaar zijn (ze gaan af en toe op vakantie, verlaten het bedrijf of lopen tegen een burn-out aan als je ze te vaak belt). Het is ook beter dan ‘best efforts’ dienst, omdat het duidelijk is wie er moet reageren.

Voeg altijd de Jira-issuesleutel van een incident toe aan een paginamelding over het incident. Dit is de sleutel die degene die de melding ontvangt gebruikt om de chatruimte van het incident te openen.

Delegeren

Nadat je het incident aan iemand hebt geëscaleerd en deze persoon online komt, wijst de IM hem of haar een rol toe. Zolang hij of zij weet wat er binnen de rol wordt verwacht, kan hij of zij snel en effectief te werk gaan als onderdeel van het incidentteam.

De rollen die we bij Atlassian gebruiken zijn:

• Incidentmanager, beschreven op de Overzichtspagina.
• Technisch manager, een senior technisch responder. Verantwoordelijk voor het ontwikkelen van theorieën wat er kapot is en waarom, neemt beslissingen over wijzigingen en geeft leiding aan het technische team. Werkt nauw samen met de IM.
• Communicatiemanager, iemand die verstand heeft van openbare communicatie, mogelijk van het klantondersteuningsteam of public relations. Verantwoordelijk voor het opstellen en versturen van interne en externe communicatie over het incident.

We gebruiken het onderwerp van de chatruimte om aan te geven wie er momenteel welke rol bekleedt, en dit wordt aangepast als rollen veranderen tijdens een incident.

De IM kan ook rollen toekennen en delegeren als het incident dit vereist, bijvoorbeeld meerdere technisch managers als er meer dan één werkstroom onderweg is, verschillende interne en externe communicatiemanagers.

Bij gecompliceerde of grote incidenten is het raadzaam om nog een gekwalificeerde incidentmanager aan te stellen als back-up voor de IM. Ze kunnen hun aandacht richten op verschillende taken en zo de IM tijd besparen, bijvoorbeeld door de tijdlijn bij te houden.

Vervolgcommunicatie versturen

Je hebt al eerste communicaties verzonden, maar zodra het incidentteam aan de slag is, moet je medewerkers en klanten op de hoogte brengen van het incident.

Het is belangrijk om intern personeel op de hoogte te brengen omdat er dan een consistent gedeelde waarheid ontstaat over het incident. Als iemand een fout maakt, is hier weinig informatie over beschikbaar, met name in een vroegtijdig stadium. En als er geen betrouwbare waarheidsbron is over wat er is gebeurd en hoe er op wordt gereageerd, neigen mensen ernaar hun eigen conclusies te trekken.

Voor interne communicatie volgen we het volgende patroon:

• We communiceren via onze interne Statuspage en via e-mail, zoals beschreven in ‘Eerste communicatie’ hierboven.
• Gebruik de naamconventie voor incidentnaam en e-mailonderwerp indeling ( - - )
• Begin met een samenvatting van 1 of 2 zinnen van de huidige status en impact.
• Een ‘Huidige status’ sectie met 2-4 punten.
• Een ‘Volgende stappen’ sectie met 2-4 punten.
• Vertel wanneer en waar de volgende ronde communicatie wordt verstuurd.

We gebruiken de volgende checklist om de communicatie te controleren op volledigheid:

• Wat is de werkelijke impact voor klanten?
• Hoeveel interne en externe klanten zijn er getroffen?
• Als de hoofdoorzaak bekend is, wat is dan de hoofdoorzaak?
• Als er een deadline voor herstel is, wat is dan de deadline?
• Wanneer en waar is de volgende update?

We stimuleren onze incidentmanagers om specifiek te zijn over onbekende factoren in hun interne communicatie. Dit zorgt voor minder onzekerheid. Als je bijvoorbeeld nog niet weet wat de hoofdoorzaak is, is het veel beter om “op dit moment weten we niet wat de hoofdoorzaak is” te zeggen dan het eenvoudigweg te verzwijgen.

Externe klanten op de hoogte brengen is belangrijk omdat dit vertrouwen helpt op te bouwen. Ondanks dat het impact op ze kan hebben, kunnen doorgaan met andere zaken zolang ze weten dat je ze op de hoogte houdt.

Voor externe communicatie werken we gewoon het incident bij dat we eerder op de Statuspage hebben geopend en veranderen de status indien nodig. We proberen updates kort en krachtig te houden, omdat externe klanten niet geïnteresseerd zijn in de technische details van het incident. Ze willen gewoon weten of het al is opgelost of wanneer het is wordt opgelost. Over het algemeen zijn 1 tot 2 zinnen voldoende.

Incidenten communiceren is een kunst en hoe meer ervaring je hebt, des te beter je wordt. Tijdens onze training voor incidentmanagers spelen we een rollenspel met een hypothetisch incident, stellen we er communicaties voor op en lezen ze aan de rest van de groep voor. Dit is een goede manier om deze vaardigheid op te doen voordat het nodig is in de praktijk. Het is ook altijd een goed idee om iemand anders een bericht te laten lezen als ‘second opinion’ voordat het wordt verstuurd.

Beoordeling

Er is niet een bepaald voorgeschreven proces dat alle incidenten op kan lossen. Als dat zo was, zouden we dat gewoon automatiseren en koffie gaan drinken. In plaats daarvan herhalen we het volgende proces om het snel aan te passen aan verschillende responsscenario's:

• Observeer wat er aan de hand is. Deel en bevestig observaties.
• Ontwikkel theorieën over waarom het gebeurt.
• Ontwikkel experimenten die de theorieën bewijzen of weerleggen. Voer ze uit.
• Herhaal ze.

Je kunt bijvoorbeeld een hoge foutfrequentie waarnemen in een service die overeenkomt met een fout die de provider van de regionale infrastructuur heeft gepost op hun Statuspage. Je bedenkt dan dat de fout waarschijnlijk beperkt is tot deze regio, besluiten om een failover uit te voeren naar een andere regio en de resultaten te bekijken.

De grootste uitdagingen voor de IM op dit moment hebben te maken met teamdiscipline:

• Communiceert het team effectief?
• Wat zijn de huidige observaties, theorieën en werkstromen?
• Nemen we effectief beslissingen?
• Worden wijzigingen opzettelijk en zorgvuldig doorgevoerd? Weten we welke wijzigingen we aanbrengen?
• Zijn de rollen duidelijk? Doen mensen hun werk? Moeten we naar meer teams escaleren?

Raak in ieder geval niet in paniek. Blijf rustig en de rest van team volgt vanzelf je voorbeeld.

De IM moet in de gaten houden of teamleden niet te moe worden en moet overnames van andere teams plannen. Een speciaal team loopt het risico op te branden als ze complexe incidenten oplossen. IM's moeten in de gaten houden hoelang teamleden al wakker zijn, hoelang ze al aan het incident werken en beslissen wie hun rol vervolgens gaat invullen.

Oplossen

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.

Secundaire taken kunnen eenvoudig gekoppeld en gevolgd worden als issue-koppelingen van de Jira-issue van het incident.

Bij Atlassian gebruiken we aangepaste Jira-velden om het begin van de impact, de detectietijd en het einde van de impact van ieder incident te volgen. We gebruiken deze velden voor de berekening van de hersteltijd (time-to-recovery/TTR), wat het interval is tussen begin en einde, en tijd te detecteren (time-to-detect/TTD), wat het interval is tussen start en detectie. De distributie van de TTD en TTR van het incident is vaak een belangrijke bedrijfsstatistiek.

We versturen definitieve interne en externe communicatie als het incident is opgelost. De interne communicaties bevatten een samenvatting van de impact en duur van het incident, inclusief hoeveel support cases er aangemaakt zijn en overige belangrijke incidentgegevens, en beschrijven duidelijk dat het incident is opgelost en dat er verder geen communicatie meer over verstuurd wordt. De externe communicaties zijn over het algemeen kort en vertellen klanten dat de service is hersteld en dat we nog opvolgen met een postmortem.

Klik op de onderstaande knop voor meer informatie over hoe Jira Service Management teams helpt bij het uitvoeren van elke stap van het responsproces, van het centraliseren van waarschuwingen en het organiseren van communicatie over incidenten tot het verenigen van teams voor betere samenwerking en het uitvoeren van incidentpostmortems voor een analyse van de hoofdoorzaak.