Basisbeginselen van incidentrespons

Organisaties profiteren tegenwoordig van de toegankelijkheid, efficiëntie en het gemak van de cloud, maar ze hebben veel uitdagingen als ze een digitale transformatie ondergaan waarbij onderdelen van hun bedrijf naar cloudservices worden verplaatst.

Enkele veelvoorkomende uitdagingen waarmee u in uw organisatie te maken hebt, zijn onder andere:

• Verhoogd aantal serviceonderbrekingen
• Geen effectieve methode voor het bijhouden en reageren op incidenten (alles is ad-hoc en reactionair)
• Onacceptabele tijd tot oplossing
• De oplossingstijd wordt niet verbeterd of wordt erger
• Informatie en status zijn moeilijk te vinden
• Terugkeerpatroon van dezelfde problemen en fouten

Voor deze uitdagingen hebt u een goed gedefinieerd plan voor incidentrespons nodig dat is gebouwd op een solide basis.

Fundamenten en pijlers

Het doel van een stichting is om de structuur erboven te houden en bijeen te houden. In een afzonderlijke intromodule voor dit leertraject hebben we het idee besproken dat betrouwbaarheidswerk is gebaseerd op het basisniveau van bewaking en dat incidentrespons zich net boven dat in de hiërarchie bevindt.

Incidentrespons heeft ook zelf een basis. Er zijn drie pijlers die ondersteuning bieden voor een goed plan voor incidentrespons:

• Roosters
• Rollen
• Rotaties

In deze les leert u wat elk van deze pijlers is en welke onderdelen ze spelen bij het ontwerpen van een strategie voor incidentrespons die u verder op weg brengt naar uw betrouwbaarheidsdoelen.

Roosters

Het is essentieel om een goed plan te hebben, maar een plan is nutteloos zonder mensen om het uit te voeren. De beste plaats om te beginnen is door te bepalen wie naar verwachting moet reageren op problemen en hoe ze weten wanneer hun reactie vereist is.

De beste manier om deze uitdaging aan te pakken, is door een rooster te ontwerpen. Een rooster is een lijst met personen die zijn toegewezen aan het on-call team. Dit team moet bestaan uit meerdere technici. Deze teamleden moeten beschikken over de kennis en vaardigheden om het type problemen op te lossen dat zich in uw omgeving kan voordoen, evenals training bij het reageren op incidenten.

Een lijst met namen is echter niet voldoende. U moet een framework bouwen om te bepalen wie op een bepaald moment in gesprek is en wat elke persoon moet doen. Daar komen rollen binnen.

Rollen

Rollen brengen orde in wat een chaos zou zijn, of in het beste geval een ad-hocreactie. Dit doet u door de specifieke functies te definiëren die door elke persoon in een bepaalde situatie moeten worden aangenomen, en de plaats van elk in de 'keten van opdracht'. Rollen kunnen per organisatie of zelfs per incidenttype verschillen, maar de volgende rollen moeten over het algemeen deel uitmaken van een georganiseerd incidentresponsteam:

• Primaire beantwoorder: dit is de 'puntpersoon' die meestal de eerste persoon op de scène is; Dat wil gezegd, de eerste on-call engineer die wordt aangeroepen wanneer er een incident optreedt.
• Secundaire beantwoorder: dit is iemand die als back-up fungeert en kan instappen als de primaire responder niet beschikbaar is of als er een tweede paar ogen nodig is.
• Vakexperts (KMO's): dit zijn mensen die diepgaande kennis hebben over een bepaald facet van uw activiteiten. Ze zijn er als de primaire en secundaire responders het probleem moeten escaleren naar iemand met meer expertise. Ze zijn niet altijd in gesprek, maar zijn beschikbaar wanneer hun gespecialiseerde vaardigheden nodig zijn. U moet een lijst met KMO's in verschillende onderwerpen onderhouden (bijvoorbeeld database, front-end, netwerkinfrastructuur, web-apps, cyberbeveiliging, enzovoort).
• Incidentcommandant: Dit is een belangrijke rol in een grootschalige incident of storing die van invloed is op veel verschillende onderdelen en/of coördinatie vereist voor veel verschillende teams en systemen. Een incidentcommandant is de persoon die veel van het gesprek coördineert en de inspanning met betrekking tot de reactie- en herstelactiviteiten. De commandant houdt het overzicht in de gaten; ze houden bij wat er aan de hand is en wie wat doet. Een incidentcommandant is geweldig om ervoor te zorgen dat technici gefocust blijven en dat ze aan hun eigen herstelwerkzaamheden werken zonder elkaars werk te doen of ongedaan te maken.
• Scribeer: De rol van de scriber is om het gesprek rond het incident zo gedetailleerd mogelijk te documenteren. Teams gebruiken vaak telefoonbruggen, telefonische vergaderingen of videochats om iedereen bij elkaar te krijgen en te begrijpen wat er aan de hand is, wat zeker kan helpen om ruimte te creëren voor het gesprek. Het is echter moeilijk voor ons om door te gaan en in detail te begrijpen wat de technici zeiden en doen, tenzij het wordt getranscribeerd. Als gevolg hiervan is een schrijver de persoon die ons kan helpen zoveel mogelijk vast te leggen om later te kunnen bekijken. De scribeert alle gegevens die mogelijk zijn; Niet alleen wat teamleden doen, maar ook wat ze zeggen en zelfs wat ze voelen of ervaren.
• Communicatiecoördinator: Beschouw deze persoon als de 'public relations manager' voor het incident. De communicatiecoördinator werkt samen met de incidentcommandant om informatie te delen over het incident met degenen die niet actief betrokken zijn bij het aanpakken en herstellen van het incident. Dit kunnen klanten, verkoop- en marketingteams, klantondersteuning en andere belanghebbenden binnen of buiten de organisatie zijn die op de hoogte moeten worden gesteld van wat er plaatsvindt en de status van de voortgang van de reactie en het herstel.

Rotaties

Nu hebt u uw rooster met antwoordteammedewerkers en hebt u de juiste rollen toegewezen. De volgende en laatste stap is het samenstellen van een rooster, dat is een schema waarmee de diensten worden toegewezen waarvoor elke persoon dienst heeft.

Er zijn veel verschillende manieren om diensten op te delen. Dienstroosterplanning kan een complex strategisch proces zijn. Diensten mogen niet willekeurig worden toegewezen; U moet nadenken over de planning om het zo effectief en zo aangenaam mogelijk te maken voor teamleden.

Enkele methoden voor het plannen van diensten zijn:

• 24 x 7: Dit is een rotatie waarbij teamleden enkele dagen achter elkaar worden aangeroepen. Dit is een eenvoudige manier om dienstdekking toe te wijzen, maar u moet voorzichtig zijn met het beperken van de duur. Verschuivingsrotaties die langer dan drie tot vier dagen duren, kunnen nadelig zijn voor de algehele gezondheid van het technische personeel en vermindert zo de betrouwbaarheid van het hele systeem.
• Volg de zondiensten: Dit is een dienstmodel waarin de technici hun on-call diensten alleen plannen tijdens hun normale werkuren en vervolgens hun on-call verantwoordelijkheid aan het einde van hun werkdag afleveren aan een andere collega die zich in een andere tijdzone bevindt.

Dit zijn slechts enkele voorbeelden van manieren waarop diensten kunnen worden toegewezen. Het belangrijkste punt is om diensten op te delen op een manier die het beste werkt voor de personen in uw antwoordteam. Er zijn veel manieren om diensten aan te passen, met name voor weekenden, wanneer technici meer flexibiliteit nodig hebben. Technici moeten de rol eenvoudig aan iemand kunnen overdragen wanneer er niet-werkgerelateerde conflicten optreden.