En “hendelse” er definert som uplanlagt nedetid eller avbrudd, som enten delvis eller helt forstyrrer en tjeneste ved å tilby brukerne en lavere kvalitet på tjenesten. Hvis hendelsen er stor, er det en “krise.”
Når den begynner å påvirke kvaliteten på tjenesten som leveres til kundene, blir det et problem, ettersom de fleste tjenesteleverandører har servicenivåavtaler med forbrukere som ofte har innebygde straffer.
Når jeg fortsetter min forskning på disse områdene, og etter å ha snakket med flere klienter, har jeg innsett at de fleste virksomheter ikke er satt opp for å håndtere IT-relaterte hendelser eller kriser i sanntid. De klassiske eldre foretakene er satt opp for å håndtere kriser på gammeldagse måter, uten å ta i betraktning Cloud eller SaaS-modellen, og venting på sosiale medier gir enda en finurlighet. Nyere digitale innfødte selskaper legger ikke mye vekt på krisehåndtering, etter det jeg har sett.
Spesielt med behovet og etterspørselen etter “alltid på”, venter ikke hendelser på et passende tidspunkt. Problemer kan, og ofte skjer, skje i helger, helligdager eller hverdager når ingen tar hensyn. Når en hendelse skjer, må et godt forberedt foretak være i en situasjon for å identifisere, vurdere, administrere, løse og effektivt kommunisere det til kundene.
Et annet sentralt problem å merke seg her er forskjellen mellom sikkerhet og servicehendelser. En sikkerhetshendelse er når enten datalekkasje eller databrudd skjer. Avbøtningen og krisehåndteringen der innebærer et annet sett med prosedyrer, fra å deaktivere kontoene til å varsle interessenter og kontoeiere og eskalere problemet til sikkerhets- og identitetsteam. En servicehendelse er når en tjenesteavbrudd skjer, delvis eller helt. Det må eskaleres til DevOps, utviklere og Ops -team. Siden de er like, kan noen av krisehåndteringsprosedyrene overlappe hverandre. Men hvis supportteamene dine ikke er klar over den riktige opptrappingsprosessen, kan de sende kritiske varsler opp på feil kanal når minutter betyr noe i en kritisk situasjon. Av hensyn til denne artikkelen skal jeg bare diskutere tjenesteavbrudd, selv om det også kan trekkes mange paralleller til en sikkerhetshendelse.
Unngå hendelser når det er mulig
Unngåelse er bedre enn å fikse problemer i enhver situasjon. Det er mange ting et foretak kan gjøre for å unngå situasjoner, for eksempel sårbarhetsrevisjoner, tidlig varslingsovervåking, kodeprofilrevisjoner, utgivelsesvurderingsutvalg, anomalideteksjon, etc. Man bør også investere i riktig observerbarhet, overvåking, logging og sporing av løsninger. Jeg har også skrevet mange artikler om disse områdene; de er for komplekse til å dekke detaljert her.
Forbered deg på det uventede
Med de fleste virksomheter er det ingen forberedelse eller handlingsplan når en hendelse skjer. I den digitale verden venter ikke hendelser i flere dager på å bli løst eller administrert. Hvis du lar sosiale medier ta over, vil det gjøre det. Noen ganger kan det til og med ha et eget sinn. Når du ikke forteller historien, vil ekspertene i sosiale medier fortelle historien din for deg.
Identifiser hendelsen før andre gjør
Jeg skrev noen artikler om dette emnet. I min siste artikkel, “I den digitale økonomien bør du mislykkes raskt, men du må også komme deg raskt,” diskuterer jeg behovet for hastighet for å finne problemer raskere enn kundene eller partnerne dine kan. Programvareutvikling har fullt ut tatt i bruk DevOps og smidige prinsipper, men Ops -teamene har ikke fullt ut omfavnet DevOps -metodikkene. For eksempel kan de eldre overvåkingssystemene, enten de er applikasjonsytelseovervåking (APM), infrastrukturovervåking eller digital opplevelsesovervåking (DEM), også finne om det er en tjenesteavbrudd ganske raskt. Imidlertid er det komplekst å identifisere mikro -tjenesten som forårsaker problemet, eller endringene som trådte i kraft som forårsaket dette problemet. Jeg har skrevet om behovet for observerbarhet og for å finne problemene raskere med feilens hastighet gjentatte ganger.
Handle raskt og avgjørende
Når store hendelser skjer, bør det være en all-hands on deck-situasjon. Så snart en kritisk hendelse (Sev. 1) er identifisert, bør en hendelseskommandant tilordnes hendelsen, et krigsrom (virtuelt eller fysisk) må åpnes umiddelbart, og riktige tjenesteeiere må inviteres. Hvis det er mulig, må problemet umiddelbart eskaleres til den rette eieren som kan løse problemet i stedet for å gå gjennom arbeidsflytprosessen til L1 til og med L3, etc. I krigsrommet for samarbeid er det ofte vanlig å peke fingre og skylde på noen andre, men det vil forsinke prosessen ytterligere. I tillegg, hvis for mange mennesker blir invitert til disse krigsromene, må det være en mekanisme for å identifisere mellomtid til uskyld (MTTI), slik at alle som blir invitert kan fortsette sitt produktive arbeid ved å gå hvis de ikke er direkte relatert og kan ikke hjelpe deg med å løse problemet.
Eier historien din på dine digitale kanaler.
Når en Sev. 1 eller et større tjenesteavbrudd skjer, brukerne dine trenger å vite, dine tjenesteeiere må vite det, og dine ledere må vite det. Med andre ord burde alle som har hud i spillet vite det. En del av det ville være ekstern kommunikasjon. I det minste må det være en statusside som viser status og kvalitet på tjenesten, slik at alle er klar over tjenestestatusen hele tiden. I tillegg en innledende forklaring på hva som gikk galt, hva du gjør for å fikse det, og en mulig ETA bør legges ut enten som en statusoppdatering eller på vanlige innlegg på LinkedIn, Twitter, Facebook og andre sosiale medieplattformer der virksomheten din er merke er tilstede. Å gå mørkt på sosiale medier vil bare legge drivstoff til bålet. Brukerne dine vet at tjenestene dine er nede. Hvis de ikke får oppdateringer fra deg, vil spekulanter eller til og med konkurrenter spre rykter for å ødelegge merkevaren din.
Det er her de fleste digitale selskaper er svake da de ikke er forberedt, noe som kan opprette eller ødelegge et SMB -foretak. Sanntids krise- og omdømmestyring er avgjørende i de kritiske øyeblikkene mens ingeniører og supportteam prøver å løse problemet. Det er også en god idé å bruke sentimentanalyse og omdømmeverktøy for å finne ut hvem som sier ekstremt negative ting og prøve å enten ta dem frakoblet for å håndtere dem direkte eller svare in natura for å unngå ytterligere eskalering.
Gjør en feilfri obduksjon
Et vanlig mønster jeg ser på tvers av organisasjoner er etter at krisen er løst og hendelsen er fikset, det ser ut til at alle går videre til neste problem raskt. Det kan være fordi det er for mange problemer som support-, DevOps- og Ops -teamene er overveldet, eller at de ikke tror det er nødvendig å analysere hva eller hvorfor dette skjedde. En spesielt viktig del av krise-/hendelseshåndtering er å finne ut hva som gikk galt, hvorfor det gikk galt, og enda viktigere, hvordan kan du fikse dette en gang for alle, så dette vil aldri skje igjen. Etter å ha funnet ut en løsning, dokumenter den ordentlig. Du må også ha et depot for å lagre disse løsningene, så i den uheldige hendelsen at det skjer igjen, vet du hvordan du løser dette raskt og avgjørende.
Oppfølging
I tillegg kan du diskutere situasjonen med dine beste kunder som ble berørt av den. forklar hva du gjorde for å løse problemet og hvordan du løste det, slik at det ikke gjentar seg. Enda viktigere, diskuter hvordan du var forberedt på hendelsen før den skjedde. Dette skaper stor tillit til merkevaren din. Ikke bare vil du ikke miste kunder, men du vil få mer på grunn av hvordan du håndterte det.
I tillegg vil det generelle rådet fra krisehåndteringsfirmaer være å avlyse eventuelle ekstravagante hendelser som er planlagt i nærmeste fremtid. Hvis de kritiske tjenestene dine var nede i flere dager, men lederne dine hadde en stor konferanse i Vegas, ville verden på sosiale medier vært der i flere dager. Overvåk sosiale medieplattformer (LinkedIn, Twitter, Facebook som minimum eller andre sosiale medieplattformer bedriften din har tilstedeværelse på, inkludert negative kommentarer på dine egne bloggsider) for tone; du kan til og med bruke AI-baserte sentimentanalyseverktøy for å identifisere fortsatt utilfredse kunder for å diskutere bekymringene deres og hvordan du kan løse dem. Inntil disse bekymringene er adressert, er ikke hendelsen din helt løst.
En annen god praksis er å unngå hype -innhold eller markedsføringssummer en stund etter at en stor hendelse har skjedd. Jeg har sett selskaper fortsette med planen og få tilbakeslag fra kundene om at de alle snakker og ingenting fungerer.
Konklusjon
La oss innse det: hver bedrift kommer til å møte dette før enn senere. Ingen er uovervinnelig. Spørsmålet er, er du klar til å håndtere det når det skjer med deg? De som håndterer det riktig, kan vinne kundenes tillit og vise at de er forberedt på å håndtere fremtidige hendelser hvis de skulle skje igjen.
Tjener du kundenes tillit ved å gjøre dette riktig måte, eller mister du det ved å knuse og dekke over dette? Det vil definere deg fremover.
På Constellation -forskning gir vi selskaper råd om valg av verktøy, beste praksis, trender og riktig IT -hendelse/krisehåndteringsoppsett for skytiden, slik at du kan være klar når det skjer med deg. Vi rådgiver også kundene i RFP-, POC- og leverandørkontraktforhandlingsprosessen etter behov.
Relaterte emner:
Enterprise Software CXO Government Security 