Close

CALMS-framework

Beoordeel je vaardigheden en meet de voortgang van je DevOps-traject.

Ian Buchanan

Principal Solutions Engineer


CALMS is een framework dat het vermogen beoordeelt van een bedrijf om DevOps-processen te implementeren, evenals een manier om resultaten tijdens een DevOps-transformatie te meten. Het acroniem is bedacht door Jez Humble, co-auteur van 'The DevOps Handbook', en staat voor Cultuur, Automatisering, Lean, Meten en Samenwerken.

Cultuur


DevOps is niet zomaar een proces, of een andere ontwikkelingsaanpak, maar een daadwerkelijke cultuurverandering. En een belangrijk onderdeel van een DevOps-cultuur is samenwerking.

Iedere tool en iedere vorm van automatisering is alleen nuttig als de IT/Ops-teams samenwerken. DevOps lost namelijk geen technische problemen op. Het lost menselijke problemen op.

Beschouw DevOps als een evolutie van agile teams — het verschil is dat nu operaties standaard zijn opgenomen. Een goede eerste stap is om teams te vormen op basis van producten, in plaats van op basis van functie. Betrek ontwikkeling, QA, productmanagement, design, operations, projectmanagement en andere vaardigheden die voor het product nodig zijn. In plaats van één team alles te laten doen of 'DevOps-professionals' in te huren, is het belangrijker om productgebaseerde teams te hebben die naadloos kunnen samenwerken.

Er zijn maar weinig dingen zo goed voor de samenwerking als een gedeeld doel en een plan om dat samen te bereiken. Bij sommige bedrijven is de overstap naar teams op basis van producten echter te groot, in te korte tijd. Zet dan kleinere stappen. Ontwikkelingsteams kunnen bijvoorbeeld geschikte leden van het operationsteam uitnodigen om deel te nemen aan sprintplanningen, dagelijkse stand-ups en sprintdemo's. Operationsteams kunnen belangrijke ontwikkelaars uitnodigen voor hun vergaderingen. Dit is een agile en natuurlijke manier om op de hoogte te blijven van de projecten, ideeën en problemen van het andere team.

gerelateerde content

Meer informatie over de voordelen van DevOps

gerelateerde content

Een DevOps-cultuur creëren

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.

Automatisering


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.

Lean


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.

Meten


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.

Delen


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.

De conclusie ...


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.

Ian Buchanan
Ian Buchanan

Ian Buchanan is een Principal Solutions Engineer voor DevOps bij Atlassian waar hij zich richt op de opkomende DevOps-community en de toepassing van Jira, Bitbucket en Bamboo voor betere continue integratie en continue levering. Hoewel Ian Buchanan een brede en uitgebreide kennis heeft van zowel Java als .NET, staat hij vooral bekend als expert op het gebied van lean en agile methoden bij grote ondernemingen.

Tijdens zijn carrière heeft hij met succes enterprise softwareontwikkelingstools beheerd in alle fases van hun levenscyclus, van begin tot eind. Ook was hij de motor achter organisatiebrede procesverbeteringen resulterend in een hogere productiviteit, kwaliteit en klanttevredenheid. Hij heeft agile teams met meerdere nationaliteiten onder zijn leiding opgericht. Voor deze teams was zelfsturing en zelforganisatie erg belangrijk. Wanneer hij geen presentaties geeft of codeert, is hij waarschijnlijk bezig met een van zijn passies als parsers, metaprogramming en domeinspecifieke talen.


Deel dit artikel
Volgend onderwerp

Aanbevolen artikelen

Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.

Toelichting DevOps

DevOps-community

Toelichting DevOps

DevOps-leertraject

Afbeelding van kaart

Gratis aan de slag

Meld je aan voor onze DevOps-nieuwsbrief

Thank you for signing up