Incidentmanagement voor razendsnelle teams
Maakt 'je bouwt het, je voert het uit' de hype waar?
Dertien jaar geleden werd 'je bouwt het, je voert het uit' geïntroduceerd. Is het principe zijn beloften nagekomen?
Dertien jaar geleden vond een nieuwe strijdkreet voor het implementeren en bedienen van software zijn weg in een interview. Die strijdkreet zette IT-processen over de hele wereld op zijn kop. Tegenwoordig omarmen meer bedrijven dan ooit de collaboratieve aanpak van DevOps en de 'je bouwt het, je voert het uit'-mentaliteit die er doorgaans bij hoort. Maar is het concept nog steeds relevant nu we meer dan een decennium aan veranderingen achter de rug hebben? Heeft de kreet zijn beloften waargemaakt?
De geschiedenis van de verschuiving
Het begon allemaal in 2006 met een interview met Amazon-CTO Werner Vogels:
"Door ontwikkelaars operationele verantwoordelijkheden te geven, is de kwaliteit van de diensten aanzienlijk verbeterd, zowel vanuit het oogpunt van de klant als vanuit technologisch oogpunt. In het traditionele model gooi je je software over de muur die ontwikkeling en operaties scheidt, en dan vergeet je het. Zo niet bij Amazon. Je bouwt én beheert de software. Zo zijn ontwikkelaars betrokken op de dagelijkse werking van hun software en hebben ze dagelijks contact met de klant. Deze feedbacklus van klanten is essentieel voor het verbeteren van de kwaliteit van de service."
Zo begon 'je bouwt het, je voert het uit', een nieuwe manier van werken die prachtig samenviel met de daaropvolgende opkomst van de collaboratieve DevOps-beweging, waarbij het van het grootste belang was om de muur te slechten tussen degenen die bouwen en degenen die ondersteuning bieden.
Het idee kreeg vleugels, en terecht. Het is heel verstandig om de kloof tussen ontwikkeling en operationele activiteiten te overbruggen. Waarom zou het team dat de code heeft geschreven, het team dat goed bekend is met het product, niet ook de superheldencape aantrekken als er een incident ontstaat? In de praktijk leidt dat niet alleen sneller tot een oplossing. Ontwikkelaars komen daardoor ook dichter bij feedback van klanten en realtime problemen, waardoor always-on services mogelijk worden.
Duidelijke voordelen … en duidelijke uitdagingen
Zoals bij alle procesverschuivingen, waren er naast de voordelen ook flink wat uitdagingen en veel weerstand van meer traditioneel gestructureerde bedrijven.
Voordelen waren onder meer minder druk op IT-teams, een productieklaar ontwerp, snellere responstijden en grondiger geteste code (als je immers om 1 uur 's nachts wordt opgepiept om een bug op te lossen, zul je bij de volgende implementatie ongetwijfeld een extra controle uitvoeren). Het principe zorgde ook voor betere en meer toegeruste ontwikkelaars, die nieuwe vaardigheden aanleerden en op nieuwe manieren gingen nadenken over het bedrijf.
Doordat de verantwoordelijkheid voor de code bij hetzelfde team blijft liggen, heeft deze aanpak ook een positieve impact op incidentpreventie. Uit een rapport bleek dat bedrijven met een externe codebeoordeling voorafgaand aan de implementatie evenveel resultaat hadden als bedrijven zonder codebeoordeling. Onderlinge evaluatie door ontwikkelaars die het product al kennen, had daarentegen een positieve invloed op de preventie van incidenten.
Wat de uitdagingen betreft: ons team besprak een paar van de uitdagingen van deze veranderende benadering van incidentmanagement hier: "De uitdaging van [decentralisatie van incidentmanagement] is dat organisaties nog steeds enige centralisatie nodig hebben. Het management heeft toegang nodig tot rapporten en documentatie. Zakelijke belanghebbenden willen updates. Ze willen incidentstatistieken zien, zoals de gemiddelde tijd voor het vinden van oplossingen en de gemiddelde tijd voor bevestiging. Ze verwachten duidelijke updates over incidenten, postmortemrapporten van incidenten en herstelwerkzaamheden.
Voor veel bedrijven die op weg zijn naar decentralisatie [en een 'je bouwt het, je voert het uit'-benadering] en goed presteren, kan deze uitdaging worden aangegaan met technologie die decentralisatie en teamautonomie mogelijk maakt. Daardoor blijft incidentoplossing wendbaar en kunnen ze toch informatie centraliseren, zodat iedereen in het bedrijf op de hoogte blijft.
De andere kernuitdaging van 'je bouwt het, je voert het uit' voor bedrijven die het principe omarmen, is dat ze teamstructuren en interne cultuur moeten veranderen. Het principe vereist dat men openstaat voor samenwerking, en nieuwe manieren van denken over producten en nieuwe teamstructuren die communicatiebarrières doorbreken. Veranderingen zoals deze zijn uitdagend en hebben een heel specifieke aanpak nodig om te slagen.
Maakt 'je bouwt het, je voert het uit' zijn belofte waar?
Ondanks de uitdagingen is het antwoord in onze ervaring positief. 'Je bouwt het, je voert het uit' verandert nog steeds de sector, waarbij zelfs traditionele IT-teams langzaam overstag gaan.
Er zijn geen onderzoeken beschikbaar over de acceptatie van 'je bouwt het, je voert het uit', maar in onze ervaring gaat die vaak gepaard met de acceptatie van DevOps-principes in het algemeen. En we hebben cijfers om dit te onderbouwen. In 2017 gaf 63% van de organisaties volgens een rapport van Forrester aan DevOps te hebben geïmplementeerd. Nog eens 27% van de organisaties had plannen om er binnen het jaar mee aan de slag te gaan. Slechts 1% toonde geen interesse in verandering.
Overtuigender is dat bedrijven een gemiddelde toename van 45% van klanttevredenheid en een toename van 43% in de productiviteit van werknemers bij het toepassen van DevOps-principes meldde.
Aan de slag met 'je bouwt het, je voert het uit'
Een 'je bouwt het, je voert het uit'-aanpak kan onmogelijk worden omarmd zonder een flexibel en op samenwerking gericht platform. Het hele uitgangspunt is dat Dev en Ops naadloos kunnen samenwerken, en dit soort samenwerking kan alleen worden ontgrendeld met de juiste tools.
Jira Service Management verenigt teams met geïntegreerde, op samenwerking gerichte communicatie, waarbij teams verbinding kunnen maken via hun favoriete communicatiemethode, van chatkanalen (Slack, Microsoft Teams) tot videovergaderingen (via een systeemeigen videobridge of Zoom). Bijna elk aspect van Jira Service Management kan worden aangepast aan de behoeften van elk team, van waarschuwingen tot routeringsregels en meer, om de benodigde responders in te lichten en context te bieden aan alle partijen, van de eerste responsfasen tot postmortemrapportage en probleembeheer.
Lees meer over hoe Jira Service Management het samenwerkingspotentieel van je team kan benutten.
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 tutorialDe voor- en nadelen van verschillende benaderingen van op afroep-beheer
Op afroep-teams evolueren snel. Ontdek de voor- en nadelen van verschillende benaderingen van op afroep-beheer.
Lees dit artikel