En “hændelse” defineres som uplanlagt nedetid eller afbrydelse, der enten delvist eller fuldstændigt forstyrrer en service ved at tilbyde en mindre servicekvalitet til brugerne. Hvis hændelsen er større, så er det en “krise.”
Når den begynder at påvirke kvaliteten af den service, der leveres til kunderne, bliver det et problem, da de fleste serviceleverandører har serviceniveauaftaler med forbrugere, der ofte har sanktioner indbygget.
Da jeg fortsætter min forskning på disse områder, og efter at have talt med flere kunder, er jeg kommet til den erkendelse, at de fleste virksomheder ikke er oprettet til at håndtere it-relaterede hændelser eller kriser i realtid. De klassiske ældre virksomheder er sat op til at håndtere kriser på gammeldags måder uden at tage Cloud eller SaaS-modellen i betragtning, og udluftning af sociale medier bringer endnu en finurlighed. Nyere digitale indfødte virksomheder lægger ikke meget vægt på krisestyring, ud fra hvad jeg har set.
Især med behovet og efterspørgslen efter “altid tændt” venter hændelser ikke på et passende tidspunkt. Problemer kan, og ofte sker, ske i weekender, helligdage eller hverdage, når ingen er opmærksomme. Når en hændelse sker, skal en korrekt forberedt virksomhed være i en situation for at identificere, vurdere, styre, løse og effektivt kommunikere den til kunderne.
Et andet vigtigt spørgsmål at bemærke her er forskellen mellem sikkerhed og servicehændelser. En sikkerhedshændelse er, når enten datalækage eller databrud sker. Afbødning og krisestyring der indebærer et andet sæt procedurer, fra at deaktivere konti til at underrette interessenter og kontoindehavere og eskalere problemet til sikkerheds- og identitetsteam. En servicehændelse er, når en serviceafbrydelse sker, delvis eller fuldstændigt. Det skal eskaleres til DevOps, udviklere og Ops -teams. Da de ligner hinanden, kan nogle af krisestyringsprocedurerne overlappe hinanden. Men hvis dine supportteams ikke er klar over den rigtige eskaleringsproces, sender de muligvis kritiske advarsler op ad den forkerte kanal, når minutter betyder noget i en kritisk situation. Af hensyn til denne artikel vil jeg kun diskutere serviceafbrydelser, selvom der også kan trækkes mange paralleller til en sikkerhedshændelse.
Undgå hændelser, når det er muligt
Undgåelse er bedre end at løse problemer i enhver situation. Der er mange ting, en virksomhed kan gøre for at undgå situationer, såsom sårbarhedsrevisioner, overvågning af tidlige advarsler, kodeprofilrevisioner, frigivelseskomitéer, anomaliedetektering osv. Man bør også investere i korrekt observerbarhed, overvågning, logning og sporing af løsninger. Jeg har også skrevet mange artikler om disse områder; de er for komplekse til at dække detaljeret her.
Forbered dig på det uventede
Med de fleste virksomheder er der ingen forberedelse eller handlingsplan, når der sker en hændelse. I den digitale verden venter hændelser ikke i dagevis for at blive løst eller administreret. Hvis du lader de sociale medier tage over, gør det det. Nogle gange kan det endda have et eget sind. Når du ikke fortæller historien, fortæller de sociale medieeksperter din historie for dig.
Identificer hændelsen, før andre gør
Jeg skrev et par artikler om dette emne. I min seneste artikel, “I den digitale økonomi skulle du fejle hurtigt, men du skal også komme dig hurtigt,” diskuterer jeg behovet for hastighed for at finde spørgsmål hurtigere, end dine kunder eller partnere kan. Softwareudvikling har fuldt ud vedtaget DevOps og agile principper, men Ops -teams har ikke fuldt ud taget DevOps -metoderne til sig. For eksempel kan de ældre overvågningssystemer, uanset om det er applikationsovervågningsovervågning (APM), infrastrukturovervågning eller digital oplevelsesovervågning (DEM), også finde ud af, om der er en serviceafbrydelse ret hurtigt. Det er imidlertid komplekst at identificere den mikrotjeneste, der forårsager problemet, eller de ændringer, der trådte i kraft, der forårsagede dette problem, i det nuværende landskab. Jeg har skrevet om behovet for observerbarhed og for at finde problemerne hurtigere med fejlens hastighed gentagne gange.
Handle hurtigt og beslutsomt
Når der sker større hændelser, bør det være en all-hands on deck-situation. Så snart en kritisk hændelse (Sev. 1) er identificeret, skal en hændelseschef være tilknyttet hændelsen, et kollaborativ krigsrum (virtuelt eller fysisk) skal straks åbnes, og ordentlige serviceejere skal inviteres. Hvis det er muligt, skal spørgsmålet øjeblikkeligt eskaleres til den rigtige ejer, der kan løse problemet i stedet for at gå igennem arbejdsgangsprocessen for L1 til og med L3 osv. I det kollaborative krigsrum er det ofte almindeligt at pege fingre og bebrejde en anden, men det vil forsinke processen yderligere. Hvis der også inviteres for mange mennesker til disse kollaborative krigsrum, skal der være en mekanisme til at identificere middel-tid-til-uskyld (MTTI), så alle, der inviteres, kan fortsætte deres produktive arbejde ved at forlade, hvis de ikke er direkte relateret og kan ikke hjælpe med at løse problemet.
Ej din historie på dine digitale kanaler.
Når en Sev. 1 eller der sker en større serviceafbrydelse, dine brugere skal vide det, dine serviceejere skal vide det, og dine ledere skal vide det. Med andre ord burde alle, der har hud i spillet, vide det. En del af det ville være ekstern kommunikation. I det mindste skal der være en statusside, der viser status og kvalitet af tjenesten, så alle er opmærksomme på servicestatus hele tiden. Derudover en indledende forklaring på, hvad der gik galt, hvad du gør for at rette op på det, og en mulig ETA bør postes enten som en statusopdatering eller på regelmæssige opslag på LinkedIn, Twitter, Facebook og andre sociale medieplatforme, hvor din virksomhed mærke er til stede. At gå mørkt på sociale medier vil kun tilføre brændstof til ilden. Dine brugere ved, at dine tjenester er nede. Hvis de ikke får nogen opdateringer fra dig, vil spekulanter eller endda konkurrenter sprede rygter om at ødelægge dit brand.
Det er her, de fleste digitale virksomheder er svage, da de ikke er forberedte, hvilket kan skabe eller bryde en SMB -virksomhed. Real-time krise- og omdømmestyring er afgørende i de kritiske øjeblikke, mens ingeniører og supportteams forsøger at løse problemet. Det er også en god idé at bruge følelsesanalyse og omdømmeværktøjer til at finde ud af, hvem der siger ekstremt negative ting og forsøge enten at tage dem offline for at håndtere dem direkte eller svare in natura for at undgå yderligere eskalering.
Lav en fejlfri obduktion
Et fælles mønster, jeg ser på tværs af organisationer, er efter at krisen er løst, og hændelsen er rettet, alle ser ud til hurtigt at gå videre til det næste nummer. Det kan skyldes, at der er for mange spørgsmål, at support-, DevOps- og Ops -holdene er overvældede, eller at de ikke synes, det er nødvendigt at analysere, hvad eller hvorfor dette skete. En særlig vigtig del af krise-/hændelseshåndtering er at finde ud af, hvad der gik galt, hvorfor det gik galt, og endnu vigtigere, hvordan kan du løse dette en gang for alle, så dette ikke vil ske igen. Efter at have fundet frem til en løsning, skal du dokumentere den ordentligt. Du skal også have et lager til at gemme disse løsninger, så i den uheldige hændelse, at det sker igen, ved du, hvordan du løser dette hurtigt og afgørende.
Opfølgning
Desuden skal du diskutere situationen med dine topkunder, der var berørt af den; forklar hvad du gjorde for at løse problemet, og hvordan du fikset det, så det ikke gentages. Endnu vigtigere, diskuter hvordan du var forberedt på hændelsen, før den skete. Dette vækker stor tillid til dit brand. Ikke alene vil du ikke miste kunder, men du vil få mere på grund af din håndtering.
Derudover vil det generelle råd fra krisestyringsfirmaer være at aflyse eventuelle ekstravagante begivenheder, der er planlagt i den nærmeste fremtid. Hvis dine kritiske tjenester var nede i flere dage, men dine ledere havde en kæmpe konference i Vegas, ville den sociale medieverden være der i flere dage. Overvåg sociale medieplatforme (LinkedIn, Twitter, Facebook som minimum eller andre sociale medieplatforme, som din virksomhed har tilstedeværelse på, herunder negative kommentarer på dine egne blogsider) for at se tone; du kan endda bruge AI-baserede følelsesanalyseværktøjer til at identificere stadig utilfredse kunder til at diskutere deres bekymringer, og hvordan du kan håndtere dem. Indtil disse bekymringer er løst, er din hændelse ikke fuldstændig løst.
En anden bedste praksis ville være at undgå hype -indhold eller marketing -buzz et stykke tid efter, at der sker en større hændelse. Jeg har set virksomheder gå videre med planen og få et tilbageslag fra kunderne om, at de alle taler, og intet virkelig virker.
Konklusion
Lad os se det i øjnene: enhver virksomhed vil stå over for dette før end senere. Ingen er uovervindelige. Spørgsmålet er, er du klar til at håndtere det, når det sker for dig? Dem, der håndterer det ordentligt, kan vinde kundernes tillid og vise, at de er parate til at håndtere fremtidige hændelser, hvis de skulle ske igen.
Tjener du dine kunders tillid ved at gøre dette rigtigt måde, eller mister du det ved at droppe og dække over dette? Det vil definere dig fremover.
I Constellation -forskning rådgiver vi virksomheder om værktøjsvalg, bedste praksis, tendenser og korrekt it -hændelses-/krisestyringsopsætning til cloud -æraen, så du kan være klar, når det sker for dig. Vi rådgiver også kunderne i RFP-, POC- og leverandørkontraktforhandlingsprocessen efter behov.
Relaterede emner:
Enterprise Software CXO Government Security 