Een grootschalig incidentmanagementproces runnen

Incidenten met grote impact beheren en oplossen

Grootschalig incidentmanagement (bij Atlassian vaak simpelweg incidentmanagement genoemd) is het proces dat DevOps- en IT Operations-teams gebruiken om te reageren op een ongeplande gebeurtenis of serviceonderbreking en de service weer te herstellen naar de operationele status.

Wat is een ernstig incident?

Dus wat is een ernstig incident? Een ernstig incident is een storing of uitval van de service van zodanige schaal dat het een noodsituatie vormt.

De definitie van het niveau van noodgevallen verschilt per organisatie. Bij Atlassian hebben we drie ernstniveaus en de top twee (Ernst 1 en Ernst 2) worden beide beschouwd als ernstige incidenten.

Als een klantgerichte service uitvalt voor alle Atlassian-klanten, is dat een Ernst 1-incident. Als dezelfde service niet beschikbaar is voor een deel van de klanten, dan is dat een Ernst 2. Beide vallen onder de noemer grootschalig incidentmanagement en vereisen een onmiddellijke reactie van onze incidentmanagementteams.

Elke issue dat essentiële taken niet verstoort, wordt beschouwd als een Ernst 3 en is geen ernstig incident.

Je grootschalige incidentmanagementproces definiëren

De levenscyclus van incident (ook wel bekend als het incidentmanagementproces) is de pad dat we volgen om incidenten te identificeren, op te lossen, te begrijpen en in de toekomst te voorkomen.

De incidentmanagementprocessen verschillen van bedrijf tot bedrijf, maar de sleutel tot succes voor elk team is het duidelijk definiëren en van te voren communiceren over de ernstniveaus, prioriteiten, rollen en processen, voordat zich een ernstig incident voordoet.

Om een gedeeld inzicht te krijgen in prioriteiten, rollen en processen, moet elk team dat een managementproces voor ernstige opzet of opnieuw evalueert, beginnen met duidelijke antwoorden te vinden op vragen zoals deze:

• Wat houdt een ernstig incident voor ons bedrijf/product in?
• Hoe definiëren we ernst- en het prioriteitsniveaus van incidenten? Als er meer dan één ernstig incident tegelijk gebeurt, hoe weten we dan wat we als eerste moeten aanpakken?
• Wie is verantwoordelijk voor de aanpak van ernstige incidenten? Welke rollen krijgen teamleden? Hoe worden die rollen gedefinieerd en gecommuniceerd?
• Welk proces moeten teams volgen in geval van een ernstig incident? Is er meer dan één proces, afhankelijk van het soort incident?
• Hoe vaak moeten we communiceren met belanghebbenden, zowel intern als extern? Hoe ziet ons communicatieplan eruit?
• Hoe ziet ons opafroeprooster eruit voor ernstige incidenten? Wie is er om 2 uur 's nachts verantwoordelijk voor een incident? En in het weekend? Tijdens de feestdagen?
• Wanneer en hoe moeten we onze oproepbare incidentmanager waarschuwen door prioriteit te geven aan een snelle oplossing voor ernstige incidenten en tegelijkertijd waarschuwingsmoeheid te vermijden?

Het grootschalige incidentmanagementproces van Atlassian

Bij Atlassian omvat ons incidentmanagementproces detectie, melding van een nieuw incident, communicatie opzetten, beoordelen, eerste communicatie versturen, escaleren, delegeren, vervolgcommunicatie versturen, beoordelen en oplossen.

Detectie:

Ten eerste wordt een incident ontdekt via onze technologie, meldingen van klanten of ons personeel. Degene die het incident detecteert (of dat nou een technicus is die het probleem tegenkwam of een klantenservicemedewerker die wordt gebeld door een gefrustreerde klant) is verantwoordelijk de registratie van het incident in ons systeem en de ernst ervan vaststellen.

Tegen de tijd dat een incident onze teams bereikt, is er al een ernstniveau 1, 2 of 3 aan gekoppeld. We beschouwen ernstniveaus 1 en 2 als ernstige incidenten, terwijl een Ernst 3 een incident met een lagere impact aanduidt.

Een nieuw incident aanmaken

Zodra er een incidentticket is aangemaakt, wordt er een melding gestuurd naar de opafroepmedewerker die verantwoordelijk is voor die service.

De paginamelding die we naar Atlassian sturen, bevat informatie over de ernst en prioriteit van het incident, evenals een samenvatting, zodat het in één oogopslag duidelijk is of het incident de hoogste prioriteit heeft of dat het nog even kan wachten tot een dringender incident is opgelost.

Communicatie opzetten

Zodra de incidentmanager een waarschuwing krijgt, is zijn eerste taak om mee te delen dat de oplossing van het incident in behandeling is. Diegene verandert de status van het incident naar 'wordt opgelost' en stelt de communicatiekanalen van het team in.

Het is noodzakelijk om flexibele communicatiekanalen te bieden tijdens incidentresponsprocessen waardoor teams contact kunnen blijven houden op de manier van hun voorkeur. In Jira Service Management zijn meerdere communicatiekanalen geïntegreerd om downtime te minimaliseren, zoals insluitbare statuswidgets, een speciale statuspagina, e-mail, chattools, social media en sms.

Beoordeling

De incidentmanager is op de hoogte gebracht en de communicatiekanalen zijn geopend. Volgende stap: het incident beoordelen.

Dit proces begint voor onze teams met een aantal vragen die ze moeten beantwoorden:

• Wat is de impact op onze klanten en werknemers?
• Wat zien klanten?
• Hoeveel klanten zijn getroffen? (Een aantal? Allemaal?)
• Wanneer begon het incident?
• Hoeveel supportcases hebben klanten geopend?
• Zijn er andere factoren die de ernst of prioriteit van het incident veranderen of die de manier waarop we het incident aan moeten pakken veranderen? (Bijvoorbeeld: zorgen over veiligheid, PR-crises op sociale media, enz.)

Zodra we deze vragen hebben beantwoord, kunnen we vol vertrouwen verder gaan met diagnostiek en oplossingen vinden of het ernstniveau en het prioriteitsniveau van het incident indien nodig aanpassen.

Eerste communicatie versturen

Zodra we zeker weten dat het incident echt is, is de communicatie met onze klanten en medewerkers de hoogste prioriteit. Zoals beschreven in ons handboek:

"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 je je er bewust van bent dat er iets niet werkt en dat je hard aan werkt om het te verhelpen."

Snelle, nauwkeurige communicatie helpt het vertrouwen van klanten op te bouwen en te behouden.

We gebruiken een strategisch incidentcommunicatieplan en bieden regelmatige statusupdates met een eenvoudige indeling. We sturen ook een e-mail naar een vaste lijst van belanghebbenden, waaronder ons technisch management, managers van ernstige incidenten en andere belangrijk intern personeel. Zoals eerder genoemd, zijn al deze communicatiemethoden aanpasbaar binnen Jira Service Management en kunnen ze worden aangepast aan het incidentresponsplan van elke organisatie.

Escalatie

Soms wordt een incident snel afgesloten door het opafroepteam. Maar in gevallen waarin dat niet gebeurt, is de volgende stap om de issue door te verwijzen naar een andere expert of een team van deskundigen dat beter in staat is om dit specifieke incident op te lossen.

In Jira Service Management kunnen responders gerelateerde tickets groeperen en partners aan de issue toevoegen om waarschuwingen te coördineren. Responders kunnen ook automatisch alle acties registreren met een uitgebreide tijdlijn voor incidenten en toegang krijgen tot automatisering en kennisdatabase-artikelen om incidenten snel te onderzoeken en op te lossen.

Delegatie

Zodra de issue naar iemand anders is geëscaleerd, wijst de incidentmanager een rol aan diegene toe. Bij Atlassian zijn deze rollen vooraf vastgesteld, zodat teamleden weten wat er van hen wordt verwacht.

Soms vereisen ernstige incidenten één incidentmanager en een klein team. Andere keren kan een situatie meerdere technische leads of zelfs meerdere incidentmanagers nodig hebben. De oorspronkelijke incidentmanager heeft de taak om uit te zoeken wanneer dat het geval is en om de juiste mensen erbij te betrekken.

Vervolgcommunicatie versturen

Naarmate het incident vordert, zal een nieuwe ronde van communicatie buiten het technische team helpen om klanten en medewerkers kalm, gerust en op de hoogte te houden. Dit is eenvoudig als teamgenoten waarschuwingen kunnen beheren op verschillende communicatieplatforms om op de hoogte te blijven van de incidentrespons.

Beoordeling

Helaas is er geen universele oplossing voor incidenten. Daarom nemen we in deze fase van het proces de tijd voor het volgende:

• Observeren wat er aan de hand is, observaties delen met het team en ze deze laten bevestigen
• Theorieën ontwikkelen over waarom dit gebeurt (en hoe we dat kunnen oplossen)
• Experimenten ontwikkelen en uitvoeren om je theorieën te bewijzen of te weerleggen
• Herhalen

Tijdens dit proces houdt de incidentmanager nauwlettend in de gaten hoe het gaat. Zijn bepaalde teamleden overbelast? Heeft iemand pauze nodig? Hebben we een frisse blik nodig? Als dat nodig is, wordt er meer gedelegeerd.

Oplossing

In onze incidentengids wordt oplossing gedefinieerd als "wanneer de huidige of dreigende impact op het bedrijf is geëindigd.”

Op dat moment eindigt de noodsituatie en gaat het team verder met secundaire taken en postmortems.

Postmortems

Onze incidentlevenscyclus eindigt wanneer het incident is opgelost, maar dat is niet het einde van het proces bij Atlassian. We willen er ook alles doen wat we kunnen om ervoor te zorgen dat een incident zich niet nog een keer voordoet. Daarom is de volgende stap een postmortem zonder schuldvraag. Deze is ontworpen om de oorzaak van een incident vast te stellen en ons te helpen het risico te beperken dat we in de toekomst zouden kunnen lopen.

Maak gebruik van postmortemsjablonen met Jira Service Management om eenvoudig postmortemrapporten te maken en te exporteren naar Confluence , inclusief de betreffende tijdlijnen van incidenten, zodat responders kunnen blijven samenwerken met teams die verschillende functies vervullen om vervolgacties te volgen en soortgelijke incidenten in de toekomst te voorkomen.

Rollen en verantwoordelijkheden

Rollen en verantwoordelijkheden zullen verschillen, afhankelijk van de cultuur binnen je organisatie, de grootte van je team, de opafroeproosters en meer. Enkele veelvoorkomende rollen bij ernstige incident zijn onder meer:

Incidentmanager: de persoon die verantwoordelijk voor het proces rondom incidentoplossing.

Tech lead: een technicus op hoog niveau die moet uitzoeken wat er kapot is en waarom, de beste manier van handelen moet bepalen en leiding moet geven aan het technische team.

Communicatiemanager: een communicatieprofessional (vaak van de afdeling PR of klantenservice) die verantwoordelijk is voor de communicatie met interne en externe klanten die getroffen zijn door het incident.

Klantensupport lead: de persoon die ervoor zorgt dat inkomende tickets, telefoontjes en tweets over het incident een tijdige, passende reactie krijgen.

Sociale media lead: een socialemediaprofessional die verantwoordelijk is voor de communicatie over het incident op sociale kanalen.

Andere veelvoorkomende rollen zijn:

Hoofdoorzaakanalist of probleemmanager: de persoon die verantwoordelijk is voor het verder gaan dan de oplossing van het incident om de hoofdoorzaak te identificeren en eventuele veranderingen die moeten worden aangebracht om de issue in de toekomst te voorkomen.

Onderzoeksraad voor ernstige incidenten: een groep die verantwoordelijk is voor onderzoek en verandermanagement.

Een oplossing voor incidentmanagement zoals Jira Service Management helpt je bij elke stap van het responsproces, van het organiseren van je opafroeprooster en waarschuwingen tot het verenigen van teams voor betere samenwerking en het uitvoeren van incidentpostmortems.