Incidentmanagement voor razendsnelle teams
Inzicht in ernstniveaus van incidenten
Incidenten identificeren en prioriteren voor een snellere oplossing
Voor incidentmanagement zijn er drie universele waarheden.
De eerste is dat incidenten onvermijdelijk zijn, vooral voor bedrijven die voortdurend groeien en innoveren.
De tweede is een sterk incidentmanagementproces is essentieel voor een gezond bedrijf (en een zwak proces kost bedrijven veel tijd, tevredenheid en inkomsten).
De derde is dat niet alle incidenten gelijk geschapen zijn. Als je gegevens uit de ene database verliest, is dat niet hetzelfde als gegevens uit al je databases verliezen. Omgaan met een uitval die 20% van je gebruikers treft, is een heel ander verhaal dan omgaan met een uitval die 90 of 100% treft. Een systeemstoring die tijdens piekuren gebeurt, is veel stressvoller dan het afhandelen van een systeemstoring wanneer je meeste klanten slapen. Zelfs twee incidenten die er op papier identiek uitzien, zijn uniek als je verder kijkt.
Incidentmanagement voor razendsnelle teams
Versnel met Jira Service Management de informatiestroom tussen operationele en ontwikkelingsteams om op incidenten te reageren wanneer ze zich voordoen en om systemen te herstellen.
Daarom hebben bedrijven met robuuste incidentmanagementprogramma's duidelijk omschreven ernstniveaus en duidelijke best practices voor prioriteit toewijzen aan incidenten zodra ze zich voordoen.
Wat zijn ernstniveaus?
De ernstniveaus van incidenten zijn een maatstaf voor de impact van een incident op het bedrijf. Doorgaans geldt dat hoe lager het cijfer van het ernstniveau, hoe groter de impact van het incident.
We definiëren bij Atlassian bijvoorbeeld een incident met Ernst 1 als 'een kritiek incident met een zeer grote impact'. Dit kan verlies van klantgegevens zijn, een inbreuk op de beveiliging, of wanneer een klantgerichte service voor geen enkele klant beschikbaar is.
Een Ernst 2-incident is een 'groot incident met aanzienlijke gevolgen', ook wanneer een klantgerichte service niet beschikbaar is voor een deel van de klanten of een kritieke functie binnen een systeem niet werkt.
En een Ernst 3-incident is 'een klein incident met weinig impact', zoals een systeemstoring die klanten lichte overlast bezorgt.
Bij Atlassian kunnen Ernst 3-incidenten overdag of tijdens werkuren worden afgehandeld, terwijl incidenten met Ernst 1- en Ernst 2-incidenten zorgen voor een waarschuwing aan opafroepmedewerkers voor een onmiddellijke oplossing, ongeacht hoe laat het is.
| Niveau | Beschrijving | Voorbeelden |
|---|---|---|
| 1 | Een kritiek incident met erg veel impact |
|
| 2 | Een groot incident met significante impact |
|
| 3 | Een klein incident met weinig impact |
|
Prioriteitsniveaus zijn nuttig om snel inzicht te krijgen in de impact en om prioriteiten te stellen voor de IT- en DevOps-teams.
Hoe duidelijker je ernstniveaus zijn gedefinieerd, hoe waarschijnlijker het is dat je team op één lijn zit en in staat is om snel en adequaat te reageren op incidenten. Zonder duidelijk omschreven ernstniveaus wordt er zo essentiële tijd verspild aan het bepalen en uitleggen van de urgentie van een incident in plaats van het op te lossen.
Wanneer en waar komen ernstniveaus van pas?
De kernwaarde van ernstniveaus is dat ze teams tijd besparen. Een team met ernstniveaus en een duidelijk roadmap om elk niveau aan te pakken, is een team dat meteen een oplossing kan vinden. Een team zonder ernstniveaus besteedt waarschijnlijk de eerste cruciale minuten van een groot incident aan het uitzoeken hoe belangrijk het is, wie er wat aan moet doen en hoe ze ermee om moeten gaan.
Hoe kritieker het incident, hoe belangrijker het is om zoveel mogelijk tijd te besparen door vooruit te plannen. Niet alleen met betrekking tot de oplossing van incidenten en communicatieplannen, maar ook toot duidelijke ernstniveaus en prioriteiten.
Het verschil tussen ernst en prioriteit
Op het eerste gezicht lijkt de ernst van het incident hetzelfde te zijn als incidentprioriteit. Een ernstig incident met ernstige gevolgen moet immers worden aangepakt vóór een minder ernstig incident, toch?
Maar de waarheid is dat het voor de meeste bedrijven ingewikkelder ligt dan dat.
Ernst is een maatstaf voor de impact. Hoeveel impact heeft een incident op gebruikers? Haalt het het hele systeem uit de lucht? Zorgt het ervoor dat ze hun hoofdtaken niet kunnen voltooien? Of is het alleen maar irritant en maakt het taken lastiger?
Prioriteit is daarentegen een meting van urgentie. Hoe snel moeten we deze issue oplossen? Welke issue moet als eerst worden opgelost?
Soms zijn de twee metingen perfect op elkaar afgestemd. Een incident met een hoge ernst waarbij het hele bedrijf wordt uitgeschakeld, heeft voor DevOps- en IT-teams waarschijnlijk ook de hoogste prioriteit.
Maar soms komen de prioriteit en de ernst niet overeen. Bijvoorbeeld: stel dat er een typefout staat in de kop op de startpagina van je website. Dit is een issue met een lage ernst omdat het niet echt van invloed is op de functie van de website. Gebruikers kunnen nog steeds doen wat ze moeten doen. Medewerkers kunnen nog steeds doen wat ze moeten doen.
Maar het bedrijf ziet de oplossing misschien als hoge prioriteit om de merkstandaarden hoog te houden, omdat het verwarring veroorzaakt of gewoon omdat ze er niet mooi uitzien. En dus kan dit incident van lage ernst en hoge prioriteit zijn.
Laten we ook zeggen dat er een incident is waardoor je app crasht. Dat is zeer ernstig omdat gebruikers niet kunnen doen wat ze moeten doen. Maar laten we ook zeggen dat het incident slechts 0,05% van je gebruikers treft. Als er andere incidenten zijn met een grotere impact, heeft een issue als dit misschien niet de hoogste prioriteit, ook al zouden de woorden 'systeem crasht' over het algemeen alle hens aan dek betekenen.
Beide metingen zijn belangrijk bij incidentmanagement, maar het is belangrijk om te herkennen wanneer ze op één lijn liggen en wanneer niet. Hoge ernst push iets niet automatisch naar de top van de prioriteitenlijst en hoge prioriteit betekent niet altijd dat een systeem uitvalt.
Omdat prioriteit uitvoerbaarder is dan ernst, is deze de primaire meting die we gebruiken. En omdat ernst vaak een sleutelfactor is die prioriteit bepaalt, hebben we duidelijke definities vastgelegd in onze Incidentgids voor onze eigen incidentmanagementwerkwijzen.
Ernstniveaus voor je organisatie definiëren
Niet alle incidenten zijn gelijk geschapen en niet alle organisaties behandelen ze op dezelfde manier. Bij het bepalen van de ernstniveaus en de bijbehorende processen en verwachtingen moet je, naast de impact van een incident, rekening houden met:
- De grootte van je technische team
- On-call schedules
- De pieken en dalen in het verkeer van je service op verschillende tijden
- De frequentie van incidenten
Waarom? Omdat al deze dingen van invloed kunnen zijn op hoe je ernstniveaus definieert.
Een app die lokale markten in één tijdzone bedient, kan bijvoorbeeld tussen 02.00 en 7.00 uur een groot dal in gebruik hebben. Dus als je hele systeem om 3 uur 's ochtends uitvalt, krijgt dat dan hetzelfde ernstniveau als een systeemstoring tijdens piekuren?
Of wat dacht je van een start-up met een klein team en veel van wat we zouden kunnen beschouwen als Ernst 3-incidenten? Moeten ze het bij een Ernst 3-niveau houden en het team laten uitzoeken welke incidenten prioriteit hebben als er drie tegelijk gebeuren? Of moeten ze ze verder opsplitsen in Ernst 3, 4 of zelfs 5 om onderscheid te maken tussen een gedeeltelijk verlies van functionaliteit in een klantgericht systeem, prestatieproblemen, en iets nog minder belangrijks, zoals een bug die geen invloed heeft op de bruikbaarheid van het systeem, maar die uiteindelijk moet worden opgelost?
Het belangrijkste hierbij is dat je je bedrijf en je team begrijpt en welke definities van ernstniveaus en prioriteit voor jou werken.
| Atlassian, 3-laags | 4-laags | 5-laags | |
|---|---|---|---|
| Ernst 1 | Een kritiek incident met erg veel impact. | ||
| Ernst 2 | Een groot incident met significante impact. | ||
| Ernst 3 | Een klein incident met weinig impact. Bijvoorbeeld: een systeemfout veroorzaakt een klein ongemak voor klanten. | Een incident dat mogelijk een ernstig incident kan worden als het niet snel wordt opgelost. | |
| Ernst 4 | Een supportaanvraag over iets dat een klant irriteert, maar dat geen invloed heeft op de algemene werking van het systeem. | Een klein incident dat gevolgen heeft voor de bruikbaarheid van het product, maar dat het niet tot stilstand brengt. | |
| Ernst 5 | Bugs of supportproblemen die geen invloed hebben op de bruikbaarheid van het product. | ||
Het is essentieel om een oplossing voor incidentmanagement te hebben om incidenten te kunnen escaleren, zodat de juiste teams zich onmiddellijk op een oplossing kunnen storten.
Ontdek hoe teams met alle functies voor incidentbeheer van Jira Service Management, waaronder waarschuwingen en op-afroepplanning, samenwerkingscommunicatie en robuuste rapportage- en analysefuncties, kunnen reageren op incidenten, ze kunnen oplossen en er van kunnen leren.
Ontdek incidentcommunicatie met Statuspage
In deze tutorial laten we je zien hoe je incidentsjablonen kunt gebruiken om effectief te communiceren tijdens storingen. Aanpasbaar voor de vele soorten serviceonderbrekingen.
Lees deze tutorialSjablonen en voorbeelden voor incidentcommunicatie
Bij het reageren op een incident zijn communicatiesjablonen van onschatbare waarde. Download de sjablonen die onze teams gebruiken, plus meer voorbeelden voor veelvoorkomende incidenten.
Lees dit artikel