Incidentmanagement voor razendsnelle teams
Incidentmanagement in de tijd van DevOps
Principes voor open, communicatie zonder schuldvraag gebruiken bij incidentmanagementteams
Je kunt niet opnieuw nadenken over hoe je software bouwt, implementeert en gebruikt zonder na te denken over hoe je op incidenten reageert.
In hun baanbrekende lezing '10+ Deploys Per Day: Dev and Ops Cooperation op Flickr', uit 2009, schetsten John Allspaw en Paul Hammond een visie op een wereld waarin ontwikkelaars en IT Ops-teams samenwerken en vaak nieuwe releases uitrollen. In het volgende decennium kreeg die visie vorm als de DevOps-beweging.
De aard van DevOps berust op nieuwe manieren om op incidenten te reageren. Het is niet verwonderlijk dat incidentmanagement zoveel aandacht kreeg in de toespraak van Allspaw en Hammond.
"Het belangrijkste om te beseffen is dat er fouten zullen plaatsvinden", zei Hammond. "Het is niet de vraag of, maar wanneer dat gebeurt."
In tegenstelling tot frameworks zoals ITIL is er geen 'officieel' document met beproefde methoden voor een DevOps-team. Maar we zijn het er over het algemeen over eens dat DevOps in de kern draait om het leveren van bedrijfswaarde aan een organisatie door organisatorische silo's af te breken, de transparantie te vergroten en open communicatie tussen ontwikkelaars en IT-operatieteams te bevorderen.
Diezelfde cultuur van transparantie, zichtbaarheid en snel leren strekt zich uit tot incidentmanagement.
Waarom? Omdat de eerste en meest cruciale stappen bij incidentmanagement draaien om het verkrijgen van inzicht in wat er mis is gegaan, het inschakelen van de juiste mensen en het bevorderen van een cultuur waarin de schuldvraag niet centraal staat.
DevOps-incidentmanagement vraagt om een cultuur van open communicatie zonder vingerwijzen tussen ontwikkelaars en IT-teams. En om lichtgewicht processen die de betrouwbaarheid van IT-services verbeteren, de klanttevredenheid verhogen en de bedrijfswaarde verhogen. Een DevOps-engineer kan helpen om de DevOps-cultuur en -methoden te implementeren.
ITIL is bijvoorbeeld een vaststaande set van 26 processen, procedures, taken en checklists die zijn ontworpen om specifieke methoden in IT-servicemanagement te verbeteren. ITIL richt zich op servicekwaliteit en consistentie, en op het verbeteren van de veerkracht van systemen.
Een van de voordelen van ITIL is dat organisaties die ITSM willen verbeteren, kunnen beginnen met beproefde methoden. Ze hoeven dus niet helemaal opnieuw te beginnen. En hoewel sommigen geloven dat ITIL het meest geschikt is voor grote ondernemingen, is het framework flexibel genoeg zodat kleinere bedrijven de processen kunnen kiezen die zinvol zijn voor hun bedrijf en daar hun winst mee kunnen doen.
Een nadeel van ITIL, als je snel wijzigingen in je incidentresponsproces aan wilt brengen, is dat het formeel verandermanagement en een deskundige consultant kan omvatten, waardoor verbeteringen kunnen worden vertraagd.
Teams die meteen aan de slag willen, hebben baat bij de DevOps-incidentmanagement aanpak: die helpt hen op weg om onmiddellijk voordelen te realiseren.
Een op afroep-rooster opstellen met Opsgenie
In deze tutorial leer je hoe je een op afroep-rooster instelt, overschrijfregels toepast, op afroep-meldingen configureert en meer, allemaal binnen Opsgenie.
Lees deze tutorialBest practices voor incidentcommunicatie
Incidentcommunicatie is het proces dat gebruikers waarschuwt als een service een storing heeft of verslechterde prestaties levert.
Lees dit artikel