Close

Incidentmanagement voor razendsnelle teams

Plannen voor disaster recovery voor IT-ops en DevOps-professionals

Naarmate IT-services zich verplaatsen van een back-of-the-house kostenplaats naar het stimuleren van de kernwaarde van het bedrijf, worden effectieve werkwijzen voor IT-disaster recovery nog belangrijker.

Of het nou gaat om downtime van toepassingen, gegevensverlies of zelfs een brand op locatie, reageren tijdens een ramp is zelden eenvoudig.

Voor kleine bedrijven kan een ramp vernietigend zijn. Volgens FEMA opent ongeveer 40-60 procent van de kleine bedrijven na een ramp nooit meer de deuren.

Wat is een disasterrecovery-plan?

Een disasterrecovery-plan is een gedocumenteerde reeks werkwijzen en procedures die zijn opgezet om een organisatie en haar IT-middelen te beschermen in geval van een ramp. Het plan omvat doorgaans scenario's, runbooks, back-ups en instructies om de bedrijfs- en IT-services operationeel te maken. Dit is met name relevant bij bijvoorbeeld systeemstoringen, downtime, inbreuk op de beveiliging en gegevensverlies.

Volgens IBM:

"Voor 1970 hoefden de meeste organisaties zich alleen maar bezig te houden met het maken van kopieën van hun papieren dossiers. De planning voor disaster recovery werd in de jaren 70 steeds belangrijker toen bedrijven steeds meer afhankelijk werden van computegebaseerde activiteiten. Destijds waren de meeste systemen batchgeoriënteerde mainframes. In afwachting van het herstel van de primaire site zou een andere externe mainframe kunnen worden geladen vanaf back-uptapes."

Disasterrecovery-planning vs. bedrijfscontinuïteitsplanning

Disasterrecovery-planning is een onderdeel van bedrijfscontinuïteitsplanning. Waar de planning voor disaster recovery erop is gericht om de betrokken services zo snel mogelijk weer operationeel te maken, is de bedrijfscontinuïteitsplanning erop gericht ervoor te zorgen dat het bedrijf ononderbroken kan functioneren in geval van een ramp.

IT speelt een centrale rol bij beide werkwijzen, of het nou gaat om disaster recovery of bedrijfscontinuïteit.

Het is eenvoudig om disaster recovery en bedrijfscontinuïteit door de war te halen of om ze als onderling uitwisselbaar te zien. De planning voor disaster recovery is gericht op het herstellen van de service na een incident. Disaster recovery is een kleiner onderdeel van het algemene bedrijfscontinuïteitsplan. Een bedrijfscontinuïteitsplan is ontworpen om ervoor te zorgen dat de organisatie blijft functioneren voor, tijdens en na een incident. Als disaster recovery is 'hoe beëindigen we dit incident?', dan is bedrijfscontinuïteit 'hoe blijven we als bedrijf opereren, zelfs tijdens een incident?'

Disasterrecovery-planning vs. incidentmanagement

Voor DevOps- en IT Operations-teams is incidentmanagement het proces dat wordt gebruikt om te reageren op een ongeplande gebeurtenis of onderbreking van de service en om de service weer operationeel te maken.

Incidentmanagement en disaster recovery worden vaak door elkaar gebruikt, afhankelijk van het team en de organisatie. Incidentbeheer is er ook op gericht incidenten in realtime te behandelen en ervoor te zorgen dat de services tijdens het incident weer operationeel zijn.

Bij Atlassian definiëren we een incident als een gebeurtenis die een service verstoort of de kwaliteit vermindert van een service, waar direct op gereageerd moet worden.

Of volgens het boek van Google over Site Reliability Engineering:

"Effectief incidentmanagement is essentieel om de overlast als gevolg van een incident te beperken en om de normale bedrijfsactiviteiten zo snel mogelijk te herstellen. Als je je reactie op mogelijke incidenten niet van tevoren hebt bepaald, kunnen de principieel incidentmanagementplannen in echte situaties opeens nergens te vinden zijn.

Google raadt ook aan om incidentmanagement op te nemen als onderdeel van het testproces voor disaster recovery van een organisatie. Via het incidentresponsproces worden de acties en communicatie van respondenten idealiter geregistreerd om een uitgebreide tijdlijn voor incidenten op te stellen die kan dienen als hulpmiddel voor toekomstige gerelateerde incidenten of storingen. Dit is nuttig voor organisaties die noodhersteltests uitvoeren, aangezien teams de volledige operationele context hebben.

Wat is Recovery Time Objective (RTO, doelhersteltijd)?

Recovery Time Objective (RTO, of doelhersteltijd) is de aanvaardbare tijd waarin een bedrijfsfunctie eruit kan liggen voor herstel na een uitval. Dit lijkt erg op de gemiddelde tijd tot herstel, zoals besproken in de DevOps-statistieken.

Disasterrecovery-planning in een DevOps-wereld

Hoe blijven disasterrecovery-plannen relevant in de wereld van continue levering, geautomatiseerd testen en een groot aantal implementaties per dag?

Met andere woorden, welke rol spelen disasterrecovery-plannen in organisaties die DevOps toepassen?

Gelukkig gaan de twee werkwijzen goed samen en wordt daarbij veel voordeel behaald. Dezelfde hulpmiddelen en processen die je gebruikt om code te pushen van ontwikkeling naar testen en verder tot productie, kunnen ook een rol spelen bij disaster recovery. Back-ups van productieomgevingen die worden gebruikt om implementaties te testen, kunnen bijvoorbeeld ook worden gebruikt om noodsimulaties uit te voeren. En de getraceerde code-commits vanuit je CI/CD-pijplijn kunnen een nuttig hulpmiddel zijn om recente veranderingen in een disasterrecovery-scenario aan het licht te brengen.

Het is geen geheim dat DevOps steeds vaker het tempo bepaalt voor alle IT-beslissingen in het bedrijf. Maar dit hoeft niet te betekenen dat het harde werk dat in het herstelplan en de middelen is gestoken, verspild is, of dat je plan voor disaster recovery op de plank ligt om stof te verzamelen.

Lees meer over de incidentmanagementoplossing van Atlassian, Jira Service Management, en ontdek hoe deze Dev- en Ops-teams van de flexibiliteit geeft om samen te werken, of ze nou incidenten oplossen of werken aan disaster recovery.