Belang van reactie op incidenten

Voortbouwend op de principes en procedures voor bewaking die in een andere module van dit leertraject worden besproken, leert u nu wat u moet doen wanneer uw bewaking een probleem aan het licht brengt. Als u een waarschuwing ontvangt waarvoor actie kan worden ondernomen, wordt u gewaarschuwd dat uw systemen niet werken zoals verwacht, is dat de trigger voor een reactie om het probleem op te lossen.

Wat is een incident?

Incidentrespons gaat over de acties die u uitvoert wanneer een incident plaatsvindt, maar wat is precies een incident? Het antwoord kan subjectief zijn; zelfs alle technici zijn het niet eens over wat een incident is. Als u de vraag stelt in verschillende branches en organisaties, krijgt u veel verschillende antwoorden.

Sommigen labelen alle onderbrekingen als incidenten, ongeacht of klanten worden beïnvloed. In de context van deze module kunnen we ermee akkoord gaan dat een incident wordt gedefinieerd als een serviceonderbreking: een gebeurtenis of voorwaarde die van invloed is op de mogelijkheid van de gebruiker om de services te gebruiken waarop ze afhankelijk zijn. Voorbeelden hiervan zijn wanneer systemen uitvallen of defect zijn op een manier die van invloed is op klanten.

Wat is reactie op incidenten?

Het voorkomen van alle problemen is een prijzenswaardig, maar onmogelijk doel. Dingen kunnen fout gaan, dus we hebben een plan nodig om de impact op onze eindgebruikers te beperken en de operaties zo snel mogelijk te herstellen.

Het is belangrijk dat reageren met urgentie in plaats van te reageren. Een reactie is meestal impulsief en gebaseerd op het huidige moment, zonder rekening te houden met langetermijneffecten. Een antwoord is goed doordacht, georganiseerd en gebaseerd op informatie.

Uw aanpak voor incidentrespons bepaalt uw effectiviteit op:

• Begrijpen wat er aan de hand is (diagnose van het probleem).
• Triatiseren (de urgentie bepalen) en prioriteit geven aan het probleem.
• De juiste resources inschakelen om het probleem(en) te verhelpen.
• Communiceren met belanghebbenden over het probleem.

Nadat u het probleem hebt opgelost, kunt u vervolgens leren van het incident via een incidentbeoordelingsproces. Dat is een belangrijk onderwerp, dat een hele afzonderlijke module ter discussie heeft.

Prestaties van incidentrespons meten

Misschien bent u bekend met de acroniem TTR, die op verschillende manieren is gedefinieerd als 'tijd om te herstellen', 'tijd om te herstellen' of 'tijd om te herstellen'. Al deze varianten verwijzen naar hetzelfde idee: hoe lang het duurt om een service terug te brengen naar een status waarin het weer voldoet aan de verwachtingen van klanten.

Verschillende frameworks gebruiken verschillende namen voor dit concept. De huidige richtlijnen van DORA verwijzen naar de hersteltijd van de mislukte implementatie, een van de vijf metrische gegevens over de prestaties van softwarelevering. Het meet hoe snel een team kan herstellen van een mislukte implementatie die een productieprobleem veroorzaakt, waardoor het een van de sterkste indicatoren van de mogelijkheid voor incidentrespons is.

Deze metrische waarde is een manier om te meten hoe goed teams presteren wanneer ze reageren op incidenten. Hoe sneller u de service herstelt, hoe minder invloed de storing of verminderde service heeft op uw gebruikers.

Het is belangrijk om te weten hoe goed uw organisatie incidentrespons afhandelt. Het onderzoek van DORA blijft een sterke relatie vertonen tussen herstelprestaties en algehele prestaties van softwarelevering. In plaats van benchmarkbanden als vaste doelen te behandelen, gebruikt u de hersteltijd om services in de loop van de tijd te vergelijken, knelpunten in uw reactieproces te identificeren en te meten of uw verbeteringen werken.

Teams met sterke procedures voor incidentrespons herstelt sneller dan slecht presterende peers en koppelen die snelheid doorgaans aan sterkere leveringsprestaties. Goede bewaking, duidelijk eigendom, geoefende responsplannen en automatisering helpen allemaal om de hersteltijd te verminderen.

Waarom herstellen teams met sterke procedures voor incidentrespons zo veel sneller dan de rest? Het is ten minste gedeeltelijk omdat ze begrijpen hoe belangrijk het is om een goed basisantwoordplan te hebben dat al is ingesteld wanneer er onvermijdelijk iets misgaat.

Tijdens het doorlopen van deze module leert u over de kenmerken en levenscyclus van een incident en hoe u die kennis kunt gebruiken om uw eigen basisplan te maken.