Crisismanagement en incidentmanagement in het digitale tijdperk

0
145

Andy Thurai

Door Andy Thurai voor onderzoek naar sterrenbeelden | 27 september 2021 | Onderwerp: Tech Industrie

Een “incident” wordt gedefinieerd als ongeplande downtime, of onderbreking, die een service gedeeltelijk of volledig verstoort door een lagere servicekwaliteit aan de gebruikers te bieden. Als het incident groot is, is het een “crisis”.

Als het de kwaliteit van de aan de klanten geleverde service begint te beïnvloeden, wordt het een probleem, aangezien de meeste serviceproviders serviceniveau-overeenkomsten hebben met de consumenten die vaak boetes hebben ingebouwd.

Terwijl ik mijn onderzoek op deze gebieden voortzet, en na met meerdere klanten te hebben gesproken, ben ik tot het besef gekomen dat de meeste ondernemingen niet zijn ingesteld om IT-gerelateerde incidenten of crises in realtime af te handelen. De klassieke legacy-ondernemingen zijn opgezet om op ouderwetse manieren met crises om te gaan, zonder rekening te houden met het cloud- of het SaaS-model, en het ventileren van sociale media brengt nog een eigenaardigheid met zich mee. Nieuwere digital native bedrijven leggen niet veel nadruk op crisisbeheer, voor zover ik heb gezien.

Vooral met de behoefte en de vraag naar “always-on” wachten incidenten niet op een geschikt moment. Problemen kunnen, en doen zich vaak voor in het weekend, op feestdagen of doordeweeks wanneer niemand oplet. Wanneer zich een incident voordoet, moet een goed voorbereide onderneming zich in een situatie bevinden om het te identificeren, te beoordelen, te beheren, op te lossen en effectief te communiceren aan de klanten.

Een ander belangrijk punt dat hier moet worden opgemerkt, is het verschil tussen beveiligings- en service-incidenten. Een beveiligingsincident is wanneer er een datalek of een datalek plaatsvindt. De mitigatie en crisisbeheersing daar omvat een andere reeks procedures, van het uitschakelen van de accounts tot het informeren van belanghebbenden en accounteigenaren en het escaleren van het probleem naar beveiligings- en identiteitsteams. Een service-incident is wanneer een serviceonderbreking plaatsvindt, geheel of gedeeltelijk. Het moet worden geëscaleerd naar DevOps, ontwikkelaars en Ops-teams. Aangezien ze vergelijkbaar zijn, kunnen sommige procedures voor crisisbeheer elkaar overlappen. Maar als uw ondersteuningsteams niet op de hoogte zijn van het juiste escalatieproces, kunnen ze kritieke waarschuwingen naar het verkeerde kanaal sturen wanneer minuten er toe doen in een kritieke situatie. In het belang van dit artikel ga ik alleen serviceonderbrekingen bespreken, hoewel er ook veel parallellen kunnen worden getrokken met een beveiligingsincident.

Voorkom incidenten waar mogelijk

Vermijden is beter dan problemen oplossen in welke situatie dan ook. Er zijn veel dingen die een onderneming kan doen om situaties te vermijden, zoals kwetsbaarheidsaudits, monitoring van vroegtijdige waarschuwingen, audits van codeprofielen, commissies voor het beoordelen van releases, anomaliedetectie, enz. Men moet ook investeren in goede observatie-, monitoring-, logging- en traceringsoplossingen. Ik heb ook veel artikelen over die gebieden geschreven; ze zijn te ingewikkeld om hier in detail te behandelen.

Bereid je voor op het onverwachte

Bij de meeste ondernemingen is er geen voorbereiding of actieplan wanneer zich een incident voordoet. In de digitale wereld wachten incidenten niet dagenlang om opgelost of beheerd te worden. Als je sociale media het over laat nemen, zal dat ook gebeuren. Soms kan het zelfs een eigen willetje hebben. Wanneer u het verhaal niet vertelt, zullen de experts van de sociale media uw verhaal voor u vertellen.

Identificeer het incident voordat anderen het doen

Over dit onderwerp heb ik een aantal artikelen geschreven. In mijn nieuwste artikel, 'In de digitale economie moet je snel falen, maar je moet ook snel herstellen', bespreek ik de noodzaak van snelheid om problemen sneller te vinden dan je klanten of partners kunnen. Softwareontwikkeling heeft de DevOps- en agile-principes volledig overgenomen, maar de Ops-teams hebben de DevOps-methodologieën niet volledig omarmd. De oudere monitoringsystemen, of het nu gaat om Application Performance Monitoring (APM), infrastructuurmonitoring of Digital Experience Monitoring (DEM)-systemen, kunnen ook vrij snel vaststellen of er een serviceonderbreking is. Het identificeren van de microservice die het probleem veroorzaakt, of de wijzigingen die dit probleem hebben veroorzaakt, is echter complex in het huidige landschap. Ik heb geschreven over de noodzaak van waarneembaarheid en om de problemen steeds sneller te vinden met de snelheid van falen.

Snel en resoluut handelen

Wanneer er zich grote incidenten voordoen, moet het een situatie van alle hens aan dek zijn. Zodra een kritiek incident (Sev. 1) wordt geïdentificeerd, moet een incidentcommandant worden toegewezen aan het incident, moet er onmiddellijk een collaboratieve oorlogskamer (virtueel of fysiek) worden geopend en moeten de juiste service-eigenaren worden uitgenodigd. Indien mogelijk moet het probleem onmiddellijk worden geëscaleerd naar de juiste eigenaar die het probleem kan oplossen, in plaats van het workflowproces van L1 tot en met L3, enz. te doorlopen. In de gezamenlijke oorlogskamer is het heel gewoon om met de vinger te wijzen en iemand anders de schuld te geven, maar dat zal het proces verder vertragen. Als er te veel mensen worden uitgenodigd voor deze gezamenlijke oorlogsruimten, moet er bovendien een mechanisme zijn om de gemiddelde tijd tot onschuld (MTTI) te identificeren, zodat iedereen die wordt uitgenodigd, zijn productieve werk kan voortzetten door te vertrekken als ze niet direct gerelateerd en kan niet helpen bij het oplossen van het probleem.

Bezit je verhaal op je digitale kanalen.

Wanneer een Sev. 1 of een grote serviceonderbreking plaatsvindt, moeten uw gebruikers weten, moeten uw service-eigenaren het weten en moeten uw leidinggevenden het weten. Met andere woorden, iedereen die een skin in het spel heeft, zou het moeten weten. Onderdeel daarvan zou externe communicatie zijn. Er moet op zijn minst een statuspagina zijn die de status en kwaliteit van de service weergeeft, zodat iedereen altijd op de hoogte is van de servicestatus. Daarnaast moet een eerste uitleg over wat er mis is gegaan, wat u doet om het op te lossen en een mogelijke ETA worden geplaatst, hetzij als een statusupdate of op reguliere berichten op LinkedIn, Twitter, Facebook en andere sociale mediaplatforms waar uw onderneming merk aanwezig is. Donker worden op sociale media zal alleen maar olie op het vuur gooien. Uw gebruikers weten dat uw services niet beschikbaar zijn. Als ze geen updates van u krijgen, zullen speculanten of zelfs concurrenten geruchten verspreiden om uw merk te ruïneren.

Dit is waar de meeste digitale bedrijven zwak zijn omdat ze niet voorbereid zijn, wat een MKB-onderneming kan maken of breken. Realtime crisis- en reputatiebeheer zijn cruciaal op die kritieke momenten terwijl technici en ondersteuningsteams het probleem proberen op te lossen. Het is ook een goed idee om sentimentanalyse- en reputatietools te gebruiken om erachter te komen wie extreem negatieve dingen zegt en om te proberen ze offline te halen om ze direct af te handelen of in natura te reageren om verdere escalatie te voorkomen.

Doe een onberispelijke autopsie

Een veelvoorkomend patroon dat ik in organisaties zie, is dat nadat de crisis is opgelost en het incident is verholpen, iedereen snel naar het volgende probleem lijkt te gaan. Het kan zijn dat er te veel problemen zijn dat de ondersteunings-, DevOps- en Ops-teams overweldigd zijn, of dat ze het niet nodig vinden om te analyseren wat of waarom dit is gebeurd. Een bijzonder belangrijk onderdeel van crisis-/incidentbeheer is om erachter te komen wat er fout is gegaan, waarom het fout is gegaan en, nog belangrijker, hoe je dit voor eens en altijd kunt oplossen, zodat dit nooit meer zal gebeuren. Nadat u een oplossing hebt gevonden, documenteert u deze goed. Je moet ook een repository hebben om deze oplossingen op te slaan, zodat je bij het ongelukkige incident dat het opnieuw gebeurt, weet hoe je dit snel en resoluut kunt oplossen.

Opvolging

Bespreek daarnaast de situatie met uw topklanten die erdoor geraakt zijn; leg uit wat je hebt gedaan om het probleem op te lossen en hoe je het hebt opgelost, zodat het zich niet herhaalt. Wat nog belangrijker is, bespreek hoe u voorbereid was op het incident voordat het gebeurde. Dit wekt enorm vertrouwen in uw merk. U zult niet alleen geen klanten verliezen, maar u zult er ook meer bij krijgen door de manier waarop u ermee omgaat.

Bovendien zou het algemene advies van crisisbeheersingsfirma's zijn om alle extravagante evenementen die in de nabije toekomst zijn gepland, te annuleren. Als uw kritieke diensten dagenlang niet beschikbaar waren, maar uw leidinggevenden een enorme conferentie in Vegas hadden, zou de wereld van de sociale media dagenlang bezig zijn. Controleer sociale mediaplatforms (minimaal LinkedIn, Twitter, Facebook of welke andere socialemediaplatforms dan ook waarop uw bedrijf aanwezig is, inclusief negatieve opmerkingen op uw eigen blogsites) voor toon; je kunt zelfs op AI gebaseerde tools voor sentimentanalyse gebruiken om nog steeds ontevreden klanten te identificeren om hun zorgen te bespreken en hoe je ze kunt aanpakken. Totdat deze zorgen zijn weggenomen, is uw incident niet volledig opgelost.

Een andere best practice zou zijn om hype-inhoud of marketingbuzz een tijdje te vermijden nadat een groot incident heeft plaatsgevonden. Ik heb bedrijven gezien die doorgaan met het plan en een reactie van klanten krijgen dat ze allemaal praten en niets echt werkt.

Conclusie

Laten we eerlijk zijn: elke onderneming krijgt hier vroeg of laat mee te maken. Niemand is onoverwinnelijk. De vraag is: ben je er klaar voor om ermee om te gaan als het je overkomt? Degenen die het op de juiste manier afhandelen, kunnen het vertrouwen van de klant winnen en laten zien dat ze voorbereid zijn om toekomstige incidenten aan te pakken als ze zich opnieuw zouden voordoen.

Win je het vertrouwen van je klanten door dit op de juiste manier te doen manier, of verlies je het door dit te verknoeien en te verdoezelen? Dat zal uw toekomst bepalen.

Bij Constellation Research adviseren we bedrijven over toolselectie, best practices, trends en de juiste setup voor IT-incident-/crisisbeheer voor het cloudtijdperk, zodat u klaar als het je overkomt. We adviseren de klanten waar nodig ook in het RFP-, POC- en leverancierscontractonderhandelingsproces.

Verwante onderwerpen:

Enterprise Software CXO Overheidsbeveiliging Andy Thurai

Door Andy Thurai voor Constellation Research | 27 september 2021 | Onderwerp: Tech Industrie