Incidentspårning

7 minuter

Incidenter har en livscykel. För att svara mest effektivt måste du kunna spåra utvecklingen av själva incidenten och utvecklingen av ditt svar på den från början av den livscykeln.

Utvärdera vad du vet

Ett bra sätt att utvärdera din incidentspårningsprocedur med hjälp av en specifik incident är att ställa dig själv en rad frågor:

När visste du först om problemet? Om ditt mål är att minska den tid det tar att återställa från incidenter måste du börja samla in information från det ögonblick du blir medveten om problemen.
Hur fick du reda på problemet? Har övervakningssystemet varnat dig om incidenten? Hörde du först om det från dina kunder som klagade, antingen direkt eller på sociala medier?
Om du bara får reda på problemet, är du den första att veta? I så fall, vem behöver du meddela? Om inte, vem mer är medveten om problemet?
Om andra är medvetna, vad (om något) görs åt det? Antar alla att någon annan undersöker det, eller har någon börjat vidta åtgärder för att ta itu med det?
Hur illa är det? Vi kanske inte har någon uppfattning om allvarlighetsgrad eller påverkan, och det finns ingen plats för oss att ta reda på hur illa problemet verkligen är och vem som påverkas.

Det kan vara svåra frågor att besvara om ingenting spåras.

Standardisera var incidentinformation ska spåras

Det finns många möjliga platser där du kan behålla och dela din lista över incidenter (aktiva eller på annat sätt) och all aktuell information om dessa incidenter. Dessa kan vara lika enkla som ett delat filområde med Word-dokument och så komplext som högspecialiserad programvara och tjänster för incidentspårning. Mellan dessa två ytterligheter finns system för biljett- och arbetsspårning som du kan använda för den här uppgiften. Vilket system du väljer är faktiskt mindre viktigt än hur du använder det. Oavsett vilket system du använder måste alla som kan ha någon koppling alls till incidenter (tekniker, kundsupport, hantering, PR, juridik och så vidare) veta vart de ska gå för att hitta systemet, hur man skapar en incident och hur man kommer åt data när det är lämpligt. Ett säkert sätt att misslyckas med incidentspårning är att de personer som stöds inte vet hur de ska komma till systemet ("vad var URL:en för vårt system igen?") när de behöver det.

I den här modulen använder vi funktionerna för arbetsobjekt i Azure DevOps för vårt exempelspårningssystem.

Skapa en konversationsbrygga

Om du vill besvara några av frågorna i föregående Utvärdera vad du vet och påbörja incidenthanteringsprocessen måste du ha ett sätt att kommunicera med andra om incidenten. Helst kommer detta att vara någon form av "teamsamarbete" elektroniskt medium för konversation, även om telefonbroar också fungerar. Konferenssamtal/telefonbryggor är mindre önskvärda eftersom det är svårare att granska incidentkommunikationen retroaktivt (därav rollen "Scribe" som nämndes tidigare).

Oavsett vilket medium du väljer bör du se till att skapa en unik kanal som är strikt begränsad till diskussion om den här incidenten och inget annat. Det är viktigt att hålla irrelevant diskussion borta från den här kanalen, eftersom du måste kunna ta data och analysera dem senare i din granskning efter incidenten.

I den här modulen använder vi Microsoft Teams som vår metod för incidentkommunikation.

Automatisera incidentspårningsstarten

Så låt oss granska de bitar vi har satt ihop hittills. Vi har en:

Lista över jourpersonalen och den rotation som har definierats för dem.
Roll som vi kan tilldela till personer som arbetar med en incident.
Specifik plats där vi ska deklarera incidenten och spåra den.
Unik kanal för personer som arbetar med incidenten för att kommunicera om den.

Du kan och bör automatisera skapandet och hanteringen av alla dessa saker i största möjliga utsträckning. När ett brådskande problem uppstår behöver du inte behöva komma ihåg alla steg som krävs för att skapa en incident, ta in rätt personer och spåra den. Allt du verkligen vill göra är att kunna trycka på "go"-knappen så att arbetet omedelbart kan börja ta itu med problemet.

Använda Logic Apps för kodlös automatisering

Ett sätt att automatisera ditt första svar är att använda Logic Apps, vilket kan förenkla jobbet med schemaläggning, automatisering och orkestrering av uppgifter, affärsprocesser och arbetsflöden.

Logic Apps är en Azure-molntjänst för att skapa integreringslösningar. Den använder anslutningar för att skapa automatiserade arbetsflöden. Utlösare starta logikappen när en specifik händelse inträffar eller när data uppfyller angivna villkor. Åtgärder är de åtgärder som sedan utförs i Logic App-arbetsflödet.

I vårt exempel använder vi följande Logic App-anslutningsappar för incidentspårning:

Azure Boards (en del av Azure DevOps), som du kan använda för att skapa och spåra problem/incidenter.
Azure Storage, där du kan lagra och hämta information om vem som är jour så att du kan tilldela rätt personer för att svara på incidenten. I vårt exempel använder vi Azure Table Storage eftersom det erbjuder en mycket enkel "nyckel/värde"-butik som gör det enkelt att lagra en lista över tekniker och deras jourstatus.
Microsoft Teams, som du kan använda för att skapa en ny, unik incidentkanal för att spåra dina teknikteams konversationer i realtid när de kommunicerar om specifika incidenter. På så sätt kan du bevara interaktionerna i förhållande till tidslinjen för händelser senare när du utför en granskning efter incidenten.

Nu ska vi koppla ihop allt detta med en logikapp. Ta först en titt på den fullständiga appen som visas i Logic Apps Designer, sedan går vi igenom den steg för steg.

Skärmbild av en utzoomad vy av en logikapp som visas i Logic Apps Designer.

Det första steget är att hantera en utlösare, den HTTP-begäran som vi nämnde. En HTTP POST-begäran görs till vår logikapp som innehåller en JSON-nyttolast med information om incidenten som vi vill deklarera. Vi parsar nyttolasten och skickar tillbaka en bekräftelse på att vi har mottagit den.

Skärmbild av HTTP- och svarsblocket i Logic App Designer-vyn för logikappen.

Med den här informationen skapar vi ett nytt arbetsobjekt i vår Azure DevOps-organisation som representerar den här incidenten.

Skärmbild av blocket Skapa ett arbetsobjekt i Logic App Designer-vyn för logikappen.

Den skapar sedan en ny Teams-kanal för incidenten:

Skärmbild av vyn Skapa en kanal i Logic App Designer-vyn för logikappen.

När kanalen har skapats uppdateras arbetsobjektet som vi skapade för en stund sedan med en länk till den nya kanalen. Detta behåller all information på samma plats (arbetsobjektet) och gör att personer som tittar på den senare kan veta vart de ska gå om de vill ansluta till den kanalen.

Skärmbild av blocket Uppdatera arbetsobjekt i Logic App Designer-vyn för logikappen.

Nu är det dags att ta med jourpersonen in i sammanhanget. Vi genomför en sökning i Azure Table Storage efter e-postadressen till ingenjören som är listad som jour. Detta returnerar ett JSON-svar som vi sedan parsar.

Skärmbild av blocket Hämta entiteter i Logic App Designer-vyn för logikappen.

Eftersom vår fråga returnerar en lista måste vi iterera över varje objekt i listan som nästa steg. Vi tilldelar arbetsobjektet till varje person (de är nu "ägare" av incidenten).

Skärmbild av Foreach-blocket i Logic App Designer-vyn för logikappen.

Som ett sista steg skickar vi sedan ett meddelande till Teams-kanalen med en pekare tillbaka till arbetsobjektet för personer som ansluter till kanalen och vill veta var den auktoritativa informationen för incidenten lagras.

Skärmbild av meddelandeinlägg som Flow bot-kanalblock i Logic App Designer-vy för Logic App.

Det är bara ett exempel på hur vi kan automatisera konfigurationen av mekanismerna för incidentspårning och kommunikation. I nästa lektion tittar vi lite närmare på aspekter av kommunikationen kring en incident.