Basisprincipes van incidentrespons
Tegenwoordig profiteren organisaties van de toegankelijkheid, de efficiëntie en het gemak van de cloud, maar ze staan voor talloze uitdagingen wanneer ze een digitale transformatie ondergaan, waarbij delen van hun bedrijf naar cloudservices worden verplaatst.
Enkele veelvoorkomende uitdagingen waarmee u in uw organisatie te maken hebt, zijn onder andere:
- Groter aantal serviceonderbrekingen
- Geen doeltreffende methode voor het volgen van en reageren op incidenten (alles is ad hoc en reactief)
- Onaanvaardbare oplossingstijd
- De oplossingstijd wordt niet beter of wordt erger
- Informatie en status zijn moeilijk te vinden
- Dezelfde problemen en fouten treden opnieuw op
Voor deze uitdagingen hebt u een goed gedefinieerd plan voor incidentrespons nodig dat is gebouwd op een solide basis.
Grondslagen en pijlers
Het doel van een fundament is om ervoor te zorgen dat de structuur erbovenop overeind blijft en bijeenblijft. In een afzonderlijke inleidende module voor dit leertraject hebben we het idee besproken dat het bij betrouwbaar werken draait om een fundamenteel niveau van controle en dat incidentrespons daar in de hiërarchie net boven staat.
Incidentrespons heeft zelf ook weer een fundament. Er zijn drie pijlers die ondersteuning bieden voor een goed plan voor incidentrespons:
- Roosters
- Rollen
- Rouleringen
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 dit te doen, is door een rooster te ontwerpen. Een rooster is een lijst met personen die zijn toegewezen aan het stand-byteam. Dit team moet uit meerdere technici bestaan. 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 de volgorde aan wat een chaos zou zijn, of in het beste een ad-hoc-antwoord. 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 responder: dit is de 'point person' die meestal de eerste persoon op de scène is. Dat wil gezegd, de eerste on-call engineer die wordt aangeroepen wanneer 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 incidentcommandant houdt het "grote plaatje" in de gaten; ze houden de tabs 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 maken vaak gebruik van communicatiebruggen, telefonische vergaderingen of videochat om iedereen bijeen te brengen en inzicht te krijgen in wat er gebeurt, wat zeker kan helpen om de communicatie op gang te brengen. 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 scribeer de persoon die ons kan helpen om ons zo veel mogelijk te documenteren om later te controleren. 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.
Rouleringen
Nu hebt u een rooster met de personen in uw responsteam en hebt u de relevante rollen toegewezen. De volgende en laatste stap is het maken van een roulering. Dat is een schema waarin wordt aangegeven voor welke ploegen iedereen stand-by moet staan.
Er zijn veel verschillende manieren om ploegen te verdelen. Het inplannen van ploegen 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.
Dit zijn enkele methoden voor het inplannen van ploegen:
- 24 x 7: Dit is een rotatie waarbij teamleden enkele dagen achter elkaar worden aangeroepen. Dit is een eenvoudige manier om ploegen toe te wijzen, maar u moet er wel op letten dat iemand niet te lang achter elkaar dezelfde dienst draait. 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 een paar voorbeelden van manieren waarop ploegen kunnen worden toegewezen. Het belangrijkste is dat de ploegen worden toegewezen op een manier die goed werkt voor de leden van uw responsteam. Er zijn veel manieren om diensten aan te passen, met name voor weekenden, wanneer technici meer flexibiliteit nodig hebben. Technici moeten hun rol eenvoudig aan iemand anders kunnen overdragen wanneer ze te maken hebben met niet-werkgerelateerde problemen.