CALMS-framework

Uitdagingen en zelfs noodgevallen zijn effectieve tests voor de DevOps-cultuur. Werpen ontwikkelaars, operations en klantvertegenwoordigers zich op een probleem en lossen ze het op als team? Richten postmortems van het incident zich op het verbeteren van resultaten voor het volgende incident in plaats van het aanwijzen van schuldigen? Als het antwoord 'ja' is, betekent dit dat jouw organisatie een DevOps-cultuur omarmt.

De meest succesvolle bedrijven hebben een DevOps-cultuur verwerkt in iedere afdeling en op elk niveau van de organisatiestructuur. Op zo'n grote schaal dekt de term 'DevOps' de lading vaak niet en is de term niet meer nodig. Zulke bedrijven hebben open communicatiekanalen en overleggen regelmatig. Ze gaan er vanuit dat het tevreden houden van de klant net zo zeer de verantwoordelijkheid van productmanagement is als van het ontwikkelingsteam. Ze begrijpen dat DevOps niet de taak van één team is. Het is de taak van iedereen.

Door te automatiseren maak je een einde aan repetitief handwerk, wat herhaalbare processen en betrouwbare systemen oplevert.

Teams die nog geen automatisering hebben, beginnen meestal met bouwen, testen, implementeren en leveren ervan. En wat is nou een betere reden voor ontwikkelaars, testers en commando's om samen te werken dan om systemen te bouwen waar iedereen baat bij heeft?

Teams voor wie automatisering nieuw is, beginnen vaak met continue levering. Hierbij wordt iedere code door een serie geautomatiseerde tests gevoerd, vaak ondersteund door cloudinfrastructuur, en worden builds verpakt en doorgevoerd naar omgevingen met geautomatiseerde implementaties.

Hoezo? Computers voeren tests grondiger en betrouwbaarder uit dan mensen. Met deze tests worden bugs en beveiligingsproblemen sneller ontdekt. Bovendien waarschuwen geautomatiseerde IT/Ops implementaties als er verschillen ('drift') zijn tussen omgevingen, waardoor de kans kleiner is dat je voor verrassingen komt te staan bij je release.

Een andere belangrijke bijdrage van DevOps is 'configuratie als code.' Ontwikkelaars streven ernaar om modulaire applicaties te maken die in elkaar gezet kunnen worden omdat die betrouwbaarder en gemakkelijker te onderhouden zijn. Diezelfde denkwijze kan toegepast worden op de ondersteunende infrastructuur, of deze nu in de cloud zit of op het eigen netwerk van het bedrijf.

'Configuratie als code' en 'continue levering' zijn niet de enige soorten automatisering in de wereld van DevOps, maar ze verdienen wel een speciale vermelding omdat ze helpen de muur tussen ontwikkeling en operations af te breken. Wanneer DevOps geautomatiseerde implementaties gebruikt om een goed geteste code door te sturen naar identiek geregistreerde omgevingen wordt 'doet het op mijn apparaat!' irrelevant.

Als we 'lean' horen in softwarecontext denken we vaak aan het afrekenen met activiteiten die weinig waarde opleveren en snel werken; vindingrijk en agile zijn. Nog relevanter voor DevOps zijn de concepten van continue verbetering en het accepteren van fouten, die de basis leggen voor een experimentele mindset.

Iemand met een DevOps-mindset ziet overal kansen om continu te verbeteren. Soms zijn die overduidelijk, zoals het organiseren van regelmatige retrospectieven zodat je team zijn processen kan verbeteren. Andere zijn subtieler, zoals het A/B-testen van verschillende inwerkmethoden voor nieuwe gebruikers van je product.

Dat continue verbetering een gangbaar idee werd hebben we te danken aan agile ontwikkeling. Early adopters van de agile-methode hebben bewezen dat een eenvoudig product dat gebruikers vandaag kunnen gebruiken waardevoller is dan een perfect product dat klanten pas over zes maanden kunnen gebruiken. Als het product blijft verbeteren, blijven de klanten het gebruiken.

En raad eens: falen is onvermijdelijk. Het is dus beter om je team voor te bereiden om dat te accepteren, te herstellen en er van te leren ('anti-fragiel zijn' volgens sommigen). Bij Atlassian geloven we dat als je niet af en toe faalt, je niet hard genoeg je best doet.

Falen verdient geen straf in de context van DevOps. Teams gaan ervan uit dat er soms iets verkeerd kan gaan, dus ze zijn berekend op snelle detectie en snel herstel. Postmortems zijn gericht op hoe processen verkeerd gelopen zijn en hoe ze sterker kunnen worden, niet op welk teamlid de code heeft verknoeid. Waarom? Omdat falen en continue verbetering bij elkaar horen.

Zonder gegevens is het moeilijk aan te tonen dat jouw continue verbetering ook echt voor verbetering zorgt. Gelukkig zijn er allerlei tools en technologieën om je prestaties te meten, bijvoorbeeld hoeveel tijd gebruikers besteden aan je product, of die blogpost verkopen heeft opgeleverd, of hoe vaak er kritieke waarschuwingen verschijnen in je logboeken.

Je kunt van alles meten, maar dat betekent niet dat je álles moet (of zou moeten) meten. Kijk naar hoe agile ontwikkeling werkt en begin bij het begin:

Hoe lang duurde het om van ontwikkeling naar implementatie te gaan?

Hoe vaak komen terugkerende bugs of storingen voor?

Hoe lang duurt het om te herstellen van systeemfouten?

Hoeveel mensen gebruiken jouw product op dit moment?

Hoeveel gebruikers heb je deze week erbij gekregen/verloren?

Als je een stevige basis hebt, is het gemakkelijker om geavanceerde meetgegevens te verzamelen over functiegebruik, klantervaringen en SLA's (service level agreements). De informatie die je krijgt is handig voor het maken van roadmaps en het voorbereiden van je volgende grote stap.

Al die interessante gegevens helpen je team belangrijke keuzes te maken, maar ze zijn nóg handiger om te delen met andere teams; zeker teams in andere afdelingen. Je marketingteam wil bijvoorbeeld weten welke mooie nieuwe functies ze kunnen verkopen. Maar in de tussentijd zie je een hoog klantenverloop omdat het product vol technische schulden zit. Gebruikersgegevens leveren ondersteunt je roadmap, zelfs als deze weinig nieuwe functies en veel oplossingen bevat, waardoor het gemakkelijker is om het met elkaar eens te worden en belanghebbenden te overtuigen.

Hoe graag we ook zouden willen dat we direct alle teams kunnen omvormen tot goed presterende DevOps-teams, komt er bij DevOps-transformaties een combinatie van werkwijzen, culturele filosofieën en tools kijken. Maar zoals je hebt gelezen, zijn de voordelen van het afbreken van de scheiding tussen ontwikkeling en operations de moeite waard: meer vertrouwen, snellere softwarereleases, betrouwbaardere implementaties en een betere feedbacklus tussen teams en klanten.

DevOps omarmen is niet eenvoudig. Met de juiste mindset, inspanning en tools kan een organisatie echter een DevOps-transformatie ondergaan die aanzienlijke voordelen oplevert.

De welbekende wrijving tussen de ontwikkelings- en operationsteams wordt vooral veroorzaakt door een gebrek aan overeenkomsten. Wij geloven dat het delen van verantwoordelijkheden en successen helpt om de geschillen te overbruggen. Ontwikkelaars kunnen direct goodwill opbouwen door een van de zwaarste lasten van operations te dragen: de pager (tegenwoordig een figuratieve constructie). DevOps is gebouwd op het idee dat de mensen die een applicatie ontwikkelen betrokken moeten zijn bij het leveren en uitvoeren ervan.

Uit dit idee komt de zin 'jij bouwt het en jij voert het uit' voort, wat een praktische aanpak in teams bevordert. Dit betekent niet dat je ontwikkelaars inhuurt en van ze verwacht dat zij ook uitstekende operators zijn. Het betekent dat ontwikkelaars en operators samenwerken gedurende de levenscyclus van de applicatie. Bovendien is uit rapporten gebleken dat peerreview van code en producten de enige beoordelingen zijn die zorgen voor betere levering en prestaties; sterker nog, externe beoordelaars waren even effectief als helemaal geen beoordeling.

Teams die met DevOps aan de slag gaan hebben vaak een wisselende rol, waarbij ontwikkelaars aan de slag gaan met problemen die eindgebruikers ontdekken en tegelijkertijd productieproblemen oplossen. Deze persoon reageert op dringende issues die aangekaart zijn door klanten, maakt patches wanneer nodig en verwerkt de backlog van problemen van klanten. De 'ontwikkelaar bij support' leert veel over hoe de applicatie in het echt gebruikt wordt. Omdat het ontwikkelingsteam goed beschikbaar is voor het operationsteam ontstaat er vertrouwen en wederzijds respect.

Atlassian heeft Open DevOps gemaakt voor teams die de toolchain willen bouwen die bij hen past, met de tools waarmee ze graag werken, dankzij integraties met toonaangevende leveranciers en marketplace-apps. Probeer het nu uit.