Ik loop al jaren rond in beheeromgevingen. Daar heerst vooral de mindset van 'zero mistakes'. Fouten maken is not done. Sla’s en contracten zijn vooral gericht op het minimaliseren van het aantal fouten of incidenten. Maar is dit niet vreselijk old-skool en achterhaald? Steeds meer organisaties adopteren de DevOps-filosofie. DevOps is gericht op het multidisciplinair samenwerken tussen ontwikkeling (dev) en beheer (ops).
Sterker nog, voor een effectieve ketensamenwerking worden ook aangrenzende domeinen nauw betrokken, zoals de klant, architectuur, security, testen en leveranciers. In de praktijk leidt dit tot zelforganiserende teams, waar feedback, snelheid en voortdurend experimenteren van cruciaal belang zijn. Waarde en risico’s krijgen een totaal andere invulling dan voorheen.
Traditionele organisaties kennen nog vaak een zogenaamde “blaming culture”. Als mensen gestraft worden zodra fouten worden ontdekt, dan worden fouten in het vervolg bedekt. Maar wat gebeurt er als fouten gezien worden als waardevolle leerpunten, als cadeautjes? Juist, dan wordt de organisatie er beter van, sterker, sneller, effectiever.
Nassim Nicholas Taleb, één van de grote denkers van deze tijd, omschreef dit soort organisaties als ‘antifragile’-systemen. Antifragile systemen, tegenovergesteld aan fragile systemen, leren en groeien door stressoren of tegenslagen. Dit geldt voor alle denkbare systemen, zoals organisaties, community’s, maar bijvoorbeeld ook spiermassa. Pas als je de gewichten voldoende verhoogt, zal spiermassa werkelijk toenemen. It-systemen werken net zo.
Bij Netflix hebben ze dit wel heel innovatief opgepakt. Met een uitermate bedrijfskritische productieomgeving, is betrouwbaarheid nogal een issue. Netflix ontwikkelde de (inmiddels open source) tool Chaos Monkey om deze betrouwbaarheid te optimaliseren. Deze destructieve agent haalt mogelijke gaten in het systeem naar boven, door willekeurig services in productie (!!!) onderuit te trekken. Het team staat klaar om problemen direct op te lossen. Het team leert hierdoor op zeer effectieve wijze van fouten of imperfecties en kan deze direct herstellen.
Ook zie ik steeds meer blameless postmortems ontstaan. Deze meetings vormen een veilige omgeving waarbinnen alle stakeholders de feiten boven tafel halen van het betreffende productieincident. Er wordt niet alleen gezocht naar een mogelijke root cause, maar vooral ook naar de condities waarbinnen de root cause zich heeft kunnen ontwikkelen. Dit accelereert het zelflerend vermogen van de gehele organisatie.
Zo willen we in it-servicemanagement onze it-diensten leveren. Met oog voor continue verbetering van de diensten, processen en mensen die de dienstverlening mogelijk maken. En met managers die ruimte scheppen en genomen risico’s belonen. Want fouten maken is menselijk. En dat is maar goed ook.
Dit artikel is eerder verschenen in Computable magazine jaargang 48, nummer 2 van februari 2015.
Interessant artikel, een soort DevOps-benadering van architectuur, maar het zondigt tegen een van de ICT hoofdwetten: “if it ain’t broken, don’t fix it”.
The Sisian army bestaat uit een verzameling monkeys die elk een andere functie hebben: http://tinyurl.com/3ouh537
Je zou deze monkeys kunnen beschouwen als een resilience laag (een soort verlengstuk van het OS) over verschillende cloudservers heen.
In de conventionele praktijk is vaak juist in de ontwerpfase al een afweging gemaakt tussen de kosten van het verlagen van het risico (met behulp van redundantie bijvoorbeeld) en het risico zelf. In latere fasen is daar dan geen geld meer beschikbaar voor.
In je artikel leg je een link met de organisatie, die ik niet terugvind in de Netflix blog. Zo te zien is deze resilience layer volledig geautomatiseerd.
Zelf heb ik ook gewerkt in organisaties waar een soort verlammende angst heerste voor changes op “belangrijke” systemen. Zelfs security patches werden tegengehouden door klanten of beheerorganisaties en het gevolg is een achterstand in software maintenance en derhalve kwetsbare systemen.
Ik voorspel dan ook, dat zodra er een “Patch Monkey” bijkomt die in staat is om volledig zelfstandig de applicatie te patchen, het einde van Service Management in zicht komt. Immers het beheer is dan volledig geautomatiseerd en aansturing ervan is niet meer nodig. Onmenselijk…
Alleen al de naam ‘Chaos Monkey’ is al geweldig.
Wellicht dat de banken en de NS hier ook mee aan het ‘experimenteren’ zijn getuige de vele storingen de laatste jaren.
Je zal maar op de helpdesk werken : “Ja, kan goed zijn dat u geen beeld heeft. We hebben net onze destructieve agent geactiveerd en we het is hier blameless gezellig. Ow, wilt u de antifragile baas spreken ? Kan niet, die staat iedereen schouderklopjes te geven en aan te moedigen.”
Om u nog beter van dienst te kunnen zijn … nou ja, laat ook maar 🙂
@Felix Je bent weer scherp. Ja, niets leerzamer dan doffe ellende die opgelost moet worden onder hoge productie druk. Ik geloof echt niet dat je live zaken at random onderuit laat schoppen en kapot laat maken om de beheerders te laten leren hier mee om te gaan. En de klant het beeld op het zwart. Kan het me niet voorstellen.
Tsja, en dat DevOps. Dat beheer en ontwikkeling onlosmakelijk met elkaar zijn verbonden is zeker iedere techneut duidelijk, wat ook duidelijk is dat binnen bedrijven de organisatorische afstand tussen technische gerelateerde afdelingen groot is. Daar komt dit vandaan, deze hele nieuwe cultus van de devops, het slechte van die barrieres. Maar de rollen en verantwoordelijkheden blijven ook als hebben de rollen weer nieuwe namen. Automatische deployment? Dat is niet van vandaag of gisteren. Maar die hele cultus van het zelfsturende team dat ons nu weer overspoelt, samen, samen, samen, er voor elkaar zijn, fouten maken mag en gooi het maar uit want het is niet erg. Dit is motivatie management daar geloof ik ook helemaal niet. Uiteraard is al er iets misgaat om het maar gewoon te zeggen dat je iets stom maar het is nog dezelfde apenrots en ratrace, iedereen voor zich en wijzen en blamen waar het kan. Anders hadden Opstelten en Teeven er ook nog wel gezeten.