En “incident” definieras som oplanerad driftstopp eller avbrott, som antingen helt eller delvis stör en tjänst genom att erbjuda användare en lägre kvalitet. Om incidenten är stor är det en “kris.” konsumenter som ofta har sanktioner inbyggda.
När jag fortsätter min forskning inom dessa områden och efter att ha pratat med flera kunder har jag insett att de flesta företag inte är inrättade för att hantera IT-relaterade incidenter eller kriser i realtid. De klassiska äldre företagen är inrättade för att hantera kriser på gammaldags sätt, utan att tänka på molnet eller SaaS-modellen, och sociala medier skapar en annan egendom. Nyare digitala inhemska företag lägger inte mycket vikt vid krishantering, vad jag har sett.
Speciellt med behovet och efterfrågan på “alltid på”, väntar incidenter inte på en bekväm tid. Problem kan, och händer ofta, på helger, helgdagar eller veckokvällar när ingen är uppmärksam. När en incident inträffar måste ett väl förberett företag befinna sig i en situation för att identifiera, bedöma, hantera, lösa och effektivt kommunicera det till kunderna.
En annan viktig fråga att notera här är skillnaden mellan säkerhets- och serviceincidenter. En säkerhetsincident är när antingen dataläckage eller dataintrång inträffar. Minskningen och krishanteringen där innebär en annan uppsättning rutiner, från att inaktivera kontona till att meddela intressenter och kontoägare och eskalera frågan till säkerhets- och identitetsteam. En serviceincident är när en tjänstavbrott inträffar, antingen delvis eller helt. Det måste eskaleras till DevOps, utvecklare och Ops -team. Eftersom de är liknande kan vissa av krishanteringsförfarandena överlappa varandra. Men om dina supportteam inte är medvetna om rätt eskaleringsprocess, kan de skicka kritiska varningar upp på fel kanal när minuter spelar roll i en kritisk situation. För den här artikelns skull kommer jag bara att diskutera avbrott i tjänsten, även om många paralleller kan dras till en säkerhetsincident också.
Undvik incidenter när det är möjligt
Undvikande är bättre än att lösa problem i alla situationer. Det finns många saker som ett företag kan göra för att undvika situationer, till exempel sårbarhetsgranskningar, tidig varningsövervakning, kodprofilgranskningar, kommittéer för frigivningsgranskning, upptäckt av avvikelser etc. Man bör också investera i korrekt observerbarhet, övervakning, loggning och spårningslösningar. Jag har också skrivit många artiklar om dessa områden; de är för komplexa för att beskrivas i detalj här.
Förbered dig på det oväntade
För de flesta företag finns det ingen förberedelse eller handlingsplan när en incident inträffar. I den digitala världen väntar incidenter inte på att dagar ska lösas eller hanteras. Om du låter sociala medier ta över så gör det det. Ibland kan det till och med ha ett eget sinne. När du inte berättar berättar socialpeditikerna din historia för dig.
Identifiera händelsen innan andra gör
Jag skrev några artiklar om detta ämne. I min senaste artikel, “I den digitala ekonomin bör du misslyckas snabbt, men du måste också återhämta dig snabbt”, diskuterar jag behovet av snabbhet för att hitta problem snabbare än dina kunder eller partners kan. Programutveckling har fullt ut antagit DevOps och agila principer, men Ops -teamen har inte fullt ut anammat DevOps -metoderna. Till exempel kan de äldre övervakningssystemen, oavsett om de är applikationsprestationsövervakning (APM), infrastrukturövervakning eller digital erfarenhetsövervakning (DEM), också hitta om det sker ett tjänstavbrott ganska snabbt. Att identifiera mikrotjänsten som orsakar problemet eller de ändringar som trädde i kraft som orsakade problemet är dock komplexa i det nuvarande landskapet. Jag har skrivit om behovet av observerbarhet och om att hitta frågorna snabbare vid hastigheten att misslyckas upprepade gånger.
Agera snabbt och beslutsamt
När stora incidenter inträffar bör det vara en situation på alla nivåer. Så snart en kritisk incident (Sev. 1) har identifierats, ska en incidentchef ha tilldelats händelsen, ett samarbetsstridsrum (virtuellt eller fysiskt) måste öppnas omedelbart och rätta tjänstelejare måste bjudas in. Om möjligt måste frågan eskaleras omedelbart till rätt ägare som kan lösa problemet snarare än att gå igenom arbetsflödesprocessen för L1 till och med L3, etc. I det samarbetsvilliga krigsrummet är det ofta vanligt att fingerpeka och skylla på någon annan, men det kommer att försena processen ytterligare. Dessutom, om för många människor bjuds in till dessa krigsrum, måste det finnas en mekanism för att identifiera medeltid-till-oskuld (MTTI) så att alla som är inbjudna kan fortsätta sitt produktiva arbete genom att lämna om de inte är direkt relaterade och kan inte hjälpa till att lösa problemet.
Äg din berättelse på dina digitala kanaler.
När en Sev. 1 eller ett större tjänstavbrott inträffar, dina användare behöver veta, dina tjänstägare måste veta och dina chefer måste veta. Med andra ord borde alla som har hud i spelet veta. En del av det skulle vara extern kommunikation. Åtminstone måste det finnas en statussida som visar status och kvalitet på tjänsten, så att alla är medvetna om tjänstens status hela tiden. Dessutom en inledande förklaring av vad som gick fel, vad gör du för att åtgärda det och en eventuell ETA bör läggas upp antingen som en statusuppdatering eller på vanliga inlägg på LinkedIn, Twitter, Facebook och andra sociala medieplattformar där ditt företag märket är närvarande. Att gå mörkt på sociala medier kommer bara att lägga bränsle till elden. Dina användare vet att dina tjänster är nere. Om de inte får några uppdateringar från dig kommer spekulanter eller till och med konkurrenter att sprida rykten om att förstöra ditt varumärke.
Det är här de flesta digitala företag är svaga eftersom de inte är förberedda, vilket kan skapa eller bryta ett SMB -företag. Kris- och rykthantering i realtid är avgörande under de kritiska stunderna medan ingenjörer och supportteam försöker lösa problemet. Det är också en bra idé att använda sentimentanalyser och rykteverktyg för att ta reda på vem som säger extremt negativa saker och att försöka antingen ta dem offline för att hantera dem direkt eller svara in natura för att undvika ytterligare eskalering.
Gör ett felfritt obduktion
Ett vanligt mönster som jag ser mellan organisationer är efter att krisen är löst och händelsen har åtgärdats, alla verkar snabbt gå vidare till nästa nummer. Det kan bero på att det är för många frågor som support-, DevOps- och Ops -team är överväldigade eller att de inte tycker att det är nödvändigt att analysera vad eller varför detta hände. En särskilt viktig del av krishantering/incidenthantering är att ta reda på vad som gick snett, varför det gick fel och ännu viktigare, hur kan du åtgärda detta en gång för alla, så att detta aldrig kommer att hända igen. Efter att ha kommit fram till en lösning, dokumentera den ordentligt. Du måste också ha ett förvar för att lagra dessa lösningar så i den olyckliga incidenten att det händer igen vet du hur du löser detta snabbt och beslutsamt.
Uppföljning
Diskutera dessutom situationen med dina bästa kunder som påverkades av den. förklara vad du gjorde för att lösa problemet och hur du fixade det så att det inte ska upprepas. Ännu viktigare, diskutera hur du var beredd på händelsen innan den hände. Detta väcker stort förtroende för ditt varumärke. Du kommer inte bara att förlora kunder, utan du kommer att vinna mer på grund av hur du hanterade det.
Dessutom skulle de allmänna råden från krishanteringsföretag vara att avboka eventuella extravaganta händelser som planeras inom en snar framtid. Om dina kritiska tjänster var nere i flera dagar, men dina chefer hade en stor konferens i Vegas, skulle sociala medier världen vara på det i flera dagar. Övervaka sociala medieplattformar (LinkedIn, Twitter, Facebook minst eller vad andra sociala medieplattformar ditt företag har närvaro på, inklusive negativa kommentarer på dina egna bloggsidor) för ton; du kan till och med använda AI-baserade sentimentanalysverktyg för att identifiera fortfarande missnöjda kunder för att diskutera deras bekymmer och hur du kan hantera dem. Innan dessa problem har åtgärdats är din incident inte helt löst.
En annan bästa praxis är att undvika hypeinnehåll eller marknadsföring ett tag efter att en stor incident inträffat. Jag har sett företag fortsätta med planen och få en motreaktion från kunder om att de alla pratar och att ingenting verkligen fungerar.
Slutsats
Låt oss inse det: varje företag kommer att möta detta förr än senare. Ingen är oövervinnerlig. Frågan är, är du redo att hantera det när det händer dig? De som hanterar det ordentligt kan vinna kundernas förtroende och visa att de är beredda att hantera framtida incidenter om de skulle hända igen.
Tjänar du dina kunders förtroende genom att göra detta rätt eller förlorar du det genom att tappa och dölja det här? Det kommer att definiera dig framöver.
På Constellation -forskningen rekommenderar vi företag om verktygsval, bästa praxis, trender och korrekt IT -incident/krishantering för molnetiden så att du kan redo när det händer dig. Vi rekommenderar också kunderna i RFP-, POC- och leverantörskontraktförhandlingsprocessen efter behov.
Relaterade ämnen:
Enterprise Software CXO Government Security 