DEVOPS

KOM-I-GÅNG  ⋅  UTBILDNINGAR  ⋅  BLOGGPOSTER  ⋅  LADDA HEM

DevOps är en framväxande community-driven praxis baserad på Lean och agile. På många sätt är det den naturliga följden av hur IT-organisationer utvecklats. Från att ha strävat mot effektivitet i leverans genom att tydliggöra specifika kompetens- och ansvarsområden. Mot ett integrerat flöde från idé till produktion. Ingen stans blir detta tydligare än i den historiska separationen mellan Development och Operations. I DevOps-ramverket kan detta nu äntligen överbryggas.

Bagkrund och historia

Konceptet DevOps sägs ha sin tillkomst runt 2008 i samband med en konferens som hölls på ämnet agil utveckling och Lean, som verksamhetsstrategi för IT-organisationer.  Då visade få intresse för diskussionen. Men sedan dess har “the DevOps community” och erfarenheterna kring DevOps som metod och ramverk vuxit. Eftersom ramverket växer fram organiskt snarare än ur en given organisation så saknas en “enda sanning om DevOps”. Bland de mer etablerade källorna hittar vi dock böckerna “The Phoenix Project” respektive “The Unicorn Project”.  Båda har rönt stor uppmärksamhet och samma författare erbjuder också många konkreta råd i “The DevOps Handbook”.

Konceptuellt har dock både metoder, principer, verktyg, utbildningar och andra kunskapskällor vuxit fram under det senaste decenniet. Metoderna är nu mogna och applicerbara på alla organisationer. Även de som inte redan driver agil systemutveckling i sin verksamhet.

Precis som med agila metoder och Lean IT så tar DevOps sitt avstamp i flödeseffektiv leverans genom hela leveranskedjan. Från idé till produktion till grav till kund och användare. Men till skillnad från agila metoder som fokuserar på utveckling. Så beskriver DevOps också hur man bör hantera även löpande driftsfrågor.

Varför DevOps?

Uppdelningen av IT-organisationer i Development respektive Operations (utveckling och drift) har möjligjort specialisering.  Detta har underbyggt förmågan att hantera mer komplexa lösningar än vad vi tidigare sett inom IT. Men baksidan av specialiseringen är den oundvikliga konflikten mellan de två funktionerna. Där Development/utveckling har fokus på snabba och ständiga förändringar, för att möta nya affärs- och verksamhetskrav. Så har Operations/drift fokus på stabilitet och trygga tillgängliga IT-tjänster. På inget sätt är detta en unik problemställning för endast IT-organisationer. Utan det är istället vanligt förekommande problem inom många områden. Inom tillverkningsindustrin har man länge talat om “the core chronic conflict”. Dvs konflikten mellan introduktionen av nya krav och produkter. Samtidigt som fabriken/produktionen ska kunna vara fortsatt effektiv.

DevOps i en IT-driftskontext

För många driftsorganisationer är också DevOps inte bara en fråga om adderat värde men också till stor del en överlevnadsfråga. Kraven på snabbare leveranser med säkrare och stabilera tjänster, helst till lägre priser, pressar driftsorganisationer. Samtidigt som molnleverantörerna växer sig starkare och mer framgångsrika. Driftsorganisationer som hanterat sin traditionella affär statiskt, utan att ställa om till dagens krav, riskerar att få svårt att hävda sig.

De organisationer som väljer att flytta delar av eller hela sin miljö till molnbaserade lösningar riskerar också att missa sitt fokus. Om drivaren i första hand är kostnadsbesparingar missas viktigare aspekter. Flödeseffektiv helhetsleverans. Med det tempo som omvärld och organisationer omvandlas idag krävs kortare ledtider. Flödeseffektivitet och hög affärsmässig flexibilitet är inte bara “nice to have”, utan kritiska överlevnadskriterier. “Driften” får inte hamna i vägen för utvecklingen.

Förväntade effekter

Organisationer som ändå har utvecklat sina “DevOps-förmågor” har sett många positiva resultat. Inte bara för IT-delen av organisationen. Utan även för de verksamheter som IT-organisationerna är satta att leverera tjänster och produkter till. I “the State of DevOps report” från Puppet labs, påvisas tydliga relationer mellan DevOps och konkurrensförmåga respektive lönsamhet. Flexibilitet och förmåga att ställa om till nya krav och affärer har en direkt relation till användandet av DevOpspraxis som är kända idag.

I korta drag så har man sett stabilare IT-tjänster, kortare ledtider i leveranser samt en högre grad av framgångsrika förändringar av IT-miljön än jämförbara enheter. Detta har i sin tur inneburit mindre strul och störningar av affärsverksamheten från kritiska IT-tjänster. Snabbare förmåga att ta fram och leverera nya tjänster och funktioner till kunder. Samt en högre pricksäkerhet på att ta fram just det IT-stöd som behövs, även i komplexa systemutvecklingsfrågor.

Kom igång med DevOps

Att slaviskt införa ramverk (eller strukturer såsom “Bimodal IT”) för att de är på modet eller baserat på en nyck ger sällan framgång. Varje organisation som ger sig på en tillämpning av DevOps-principer i sin verksamhet bör ha en god uppfattning om  “vilket problem vi vill lösa”. Har man ett eller flera team (in- eller outhouse) som bedriver agil systemutveckling. Som också ofta hamnar i beroendesituationer till driftsorganisationen? Har man en driftsorganisation som är helt dränkt med arbete. Som också är överhopad av besparings- och tillgänglighetskrav.  Utan att kunna bedriva sitt arbete i korta snabba iterationer? Samtidigt som de ska möta utmaningarna med nya/snabbt föränderliga applikationer och behov? Sitter IT-arkitekterna i organisationen och river sig i håret. Funderar på hur de på något sätt ska kunna få rätsida på en enorm teknisk skuld. För att inte tala om snåriga integrationer och fragila IT-lösningar som bara tycks bli värre över tid?

Sannolikt går det att ganska tydligt idenfiera åtminstone någon eller några exempel på de problem som DevOps kan lösa. Kanske också var man ska börja sina insatser? Från DevOps community finns också hjälp att få. Såsom några centrala komponenter Puppet Labs identifierat som hjälper organisationer att utvecklas i rätt riktning.

Resan har redan startat

I vår erfarenhet handlar det ofta om att fortsätta den resa som redan är påbörjad i organisationen. De flesta organisationer har redan idag någon form av agil utveckling som pågår. Antingen internt eller via externa partners. Molntjänster blir mer och mer etablerade och nyttjas flitigt av många IT-organisationer. Stöd från Lean IT  med fokus på flödeseffektiv leverans. Elinimering av waste med enkla nyckelord som “downtime” har hjälpt IT-organisationer att kapa ledtider. Samtidigt som de förädlat värdeleveransen. Automatisering och självprovisionering, avancerad monitorering och förenklad “deployment” genom moderna verktyg avlastar. Men ökar också kvaliteten på arbetet och leveranserna.

Vi tror ändå att resan förenklar genom att att förstå och dra nytta av de verktyg och principer som finns tillgängliga. “The three ways of DevOps” ger oss riktningen för arbetet. Att inte tillåta lokal optimering som skapar global degradering pekar till på vikten att att arbeta i ett gemensamt värdeflöde. Snarare än silobaserade strukturer med ständiga överlämningar och långa ledtider.

Utveckla nya förmågor i korta iterationer

Att använda sig av korta iterationer för arbetet fungerar inte bara för utvecklingsavdelningar men även för driftsfunktionen. Genom beprövade verktyg som Kanban och Visual management (från Toyota och Sensei Taichi Ohno) kan vi lära oss att skapa flöde. Begränsa WIP, synliggöra vårt arbete, förenkla prioritering och säkra löpande avbetalning av teknisk skuld. Genom korta iterationer kan vi också förstärka feedback-loopar och bygga in ständig förbättring i vårt arbete. Där vi ser på vårt end-to-end-flöde och bryter ner våra silos internt.

Slutligen måste vi sträva mot att utveckla den önskade kulturen i organisationen där ständiga kaizen-aktiviteter är standard och vi som organisation lär oss varje dag. Av både misstag och framgångar. Och i detta erkänna att DevOps inte är en organisationsform, en roll eller ett verktyg för automatisering. Det är ett helhetsperspektiv på IT-leveransen och värdet av IT för verksamheten.

Med nya förmågor krävs nya kompetenser

Med ramverket DevOps så kommer också många nya kompetensfrågor som behöver mötas. Därför finns det också flera olika utbildningar av både teoretisk och praktisk karaktär.

Vi på Onbird har sedan många tillhandahållit en rad olika tjänster till Organisationer som påbörjat eller vill utveckla sina DevOpsförmågor. Bland annat så erbjuder vi:

• Certifierande utbildningar såsom DevOps fundamentals och DevOps Product Owner.
• Praktiskt orienterade workshops och affärssimuleringar såsom  “The Phoenix Project” baserat på boken med samma titel.
• Konsulttjänster såsom DevOps Coach, DevOps-strateg samt traditionell uppdragsorienterad konsulting.

Framför allt så tror vi på Onbird att varje organisation måste hitta sin egen DevOps-röst. Följ inte dogmatiskt ett regelverk utan att anpassa det till de specifika förutsättningar för er organisation. Då får ni tyvärr oftast dåliga lösningar, motstånd till förändring och framför allt missade affärsmöjligheter.

Under alla omständigheter finns det stora vinster tillika misstag man kan göra som organisation om man inte behandlar frågan om DevOps med någon form av tanke och struktur. Slutmålet måste kunna översättas till affärsresultat för att investeringen ska kunna motiveras.

BLOGGPOSTER OM DEVOPS

LADDA HEM