Sluiten
Atlassian incidenthandboek

Reageren op een incident

Caution alert exclamation point

Reageren op een incident

In het volgende gedeelte wordt het proces voor het reageren op incidenten van Atlassian beschreven. De incidentmanager (IM) volgt deze stappen om het incident van detectie naar oplossing te brengen.

Workflow of Atlassian incident response from new to fixing to resolved
Book illustration with a light bulb over it

Overzicht

Incidenten en incidentwaarde definiëren. Weet welke tools er gebruikt moeten worden en ken de rollen binnen het team.

Illustration of different kinds of charts

Incident-postmortems

Een postmortem uitvoeren zonder schuldigen aan te wijzen, hoofdoorzaken identificeren en het doorvoeren van oplossingen plannen.

Detect

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). 

We gebruiken een eenvoudig te onthouden korte URL die Atlassians doorstuurt naar een intern Jira Service Desk-portaal. Atlassians kunnen controleren of er al een incident is aangemaakt door een Jira-dashboard of een Jira-macro in Confluence te bekijken. Teams zoals onze klantondersteuningsteams hebben dashboards ingesteld op alle bekende locaties om lopende incidenten te monitoren.

We vullen de volgende velden in voor ieder incident:

Jira-veld

Type

Helptekst

Summary

Tekst

Wat is er aan de hand?

Description

Tekst

Welke impact heeft het op klanten? Vul je contactgegevens in zodat respondenten je kunnen bereiken.

Niveau

Eén selecteren

(Hyperlink naar een Confluence-pagina met onze schaalverdeling) Als je voor niveau 2 of 1 kiest, betekent dit dat het probleem meteen moet worden opgelost - er worden mensen op de hoogte gebracht.

Foutieve service

Eén selecteren

De service met de fout die het incident veroorzaakt. Doe een gok als je het niet zeker weet. Selecteer 'Onbekend' als je geen idee hebt.

Betrokken producten

Vakjes

Welke producten hebben last van dit incident? Selecteer alle producten die van toepassing zijn.

Als het incident is aangemaakt, wordt de issue-sleutel ervan gebruikt in alle interne communicatie over het incident.

Klanten openen vaak support cases over een incident waar ze mee te maken hebben. Als onze klantondersteuningsteams bepalen dat deze cases allemaal bij een incident horen, labelen ze die cases met de issue-sleutel van het incident om de impact op de klanten te volgen en eenvoudiger contact op te kunnen nemen met betrokken klanten als het incident is opgelost.

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 hij of zij online komt is het issue-incident aan zichzelf toewijzen, en de issue instellen op de status wordt opgelost. Het veld Uitvoerder in het Jira-issue geeft ook aan wie de huidige IM is. Tijdens een noodrespons is het belangrijk om duidelijk aan te geven wie er de leiding heeft, dus moet dit veld altijd correct worden 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:

  • Chatruimte in Slack of een andere chatservice. 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 betrokken mensen 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).

Tot slot stelt de IM zijn of haar eigen persoonlijke chatstatus in op de issuesleutel van het incident dat hij of zij managet. Op deze manier weten zijn of haar collega's dat hij of zij bezig is met het managen 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

Niveau

Description

Examples

1

Een kritiek incident met erg veel impact

  • Een klantgerichte service, zoals Jira Cloud, ligt plat voor alle klanten

  • Vertrouwelijkheid of privacy is geschonden.

  • Gegevensverlies klant.


2

Een groot incident met significante impact

  • Een klantgerichte service is niet beschikbaar voor een aantal klanten

  • Kernfunctionaliteit (zoals git push, issue maken) wordt significant beïnvloed.

3

Een klein incident met weinig impact

  • Een klein ongemak voor klanten, kan worden omzeild.

  • Werkbare lagere prestaties.

Als je de impact van het incident eenmaal hebt achterhaald, wijzig of bevestig je de ernst van de incident-issue en communiceer je de ernst naar het team. We hebben ontdekt dat een cijfer voor het niveau erg handig is om de ernst duidelijk te communiceren.

Bij Atlassian worden incidenten van niveau 3 doorgegeven aan de leveringsteams om tijdens werktijd op te lossen, terwijl voor incidenten van niveau 1 en 2 teamleden opgepiept moeten worden voor een onmiddellijke oplossing. Het verschil in respons tussen niveau 1 en 2 is genuanceerder en afhankelijk van desbetreffende service.

De matrix met niveaus moet gedocumenteerd worden en alle teams moeten er overeenstemming over bereiken voor een consistente respons gebaseerd op impact op de klant.

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:

 

Interne statuspagina

Externe statuspagina

Naam incident

<Issuesleutel incident> - <Niveau> - <Incidentoverzicht>

Issues onderzoeken met <product>

Bericht

We zijn een incident aan het onderzoeken met betrekking tot <product x>, <product y> en <product z>. We sturen zo snel mogelijk een update via e-mail en Statuspage.

We zijn problemen aan het onderzoeken met <product> en hier volgt zo snel mogelijk een update.

Naast het aanmaken van een Statuspage-incident, sturen we een e-mail naar een distributielijst met incidentcommunicaties met onze engineering manager, grote incidentmanagers en overige betrokken medewerkers. Deze e-mail heeft dezelfde inhoud als als het interne Statuspage-incident. Medewerkers kunnen via e-mail reageren en vragen stellen, terwijl Statuspage meer eenzijdige communicatie is.

We voegen altijd de Jira-issuesleutel toe aan alle interne communicatie over het incident, zodat medewerkers weten welke chatruimte ze moeten bezoeken als ze nog vragen hebben.

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 interne medewerkers 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 (<Issuesleutel incident> - <Niveau> - <Incidentoverzicht>)

  • 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 kan oplossen. Als dat zo was, zouden we dit 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 doorvoeren?  

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

Book illustration with a light bulb over it

Overzicht

Incidenten en incidentwaarde definiëren. Weet welke tools er gebruikt moeten worden en ken de rollen binnen het team.

Illustration of different kinds of charts

Incident-postmortems

Een postmortem uitvoeren zonder schuldigen aan te wijzen, hoofdoorzaken identificeren en het doorvoeren van oplossingen plannen.

Op zoek naar een tool om een proces voor incidentmanagement uit te voeren?