Snälla, kan inte någon berätta vad #¤%#¤% DevOps är …

Och kanske ännu viktigare, vad ska DevOps vara bra för?

DevOps är en term och en framväxande praxis som vi sett mer och mer av de senaste åren. Konceptet 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. Termen är förståeligt nog en sammanslagning av Development och Operations. Eller på svenska Utveckling och Drift.

Den underliggande konflikten/separationen

Framkomsten av konceptet var en strävan efter att komma ännu närmare en mer total leverans av IT än vad som ofta är fallet i organisationer där Utveckling och Drift är separata funktioner (som helst har så lite som möjligt med varandra att göra). De problem som denna uppdelning ofta ger upphov till är:

• Konflikter mellan funktionerna utveckling och drift.
• Ovilja eller oförmåga att tala gemensamt språk.
• Användande av icke gemensamma verktyg.
• Funktionerna jobbar inte i en gemensam total leverans till kunden där inte bara ny fiffig funktionalitet snabbt produktionssätts utan även den löpande driften fungerar smärtfritt.
• Hantering av test sker i silos utan kontroll på hela leveransinnehållet.
• Incidenthantering fastnar mellan funktioner som gärna skyller felen på varandra snarare än arbetar tillsammans för att lösa både incident och problem.

När resultatet blir kontraproduktivt

De flesta organisationer strävar efter olika former av effektivitet och kanske framför allt kostnadseffektivitet genom att dela upp ovan nämnda funktioner. Argumentet är ganska enkelt – genom att specialisera sig på ett område och skapa standarder för det området blir det kostnadseffektivt, säkert och lätthanterligt.

Men dessvärre kan detta ofta innebära att det istället skapar bekymmer för den andra funktionen. T.ex., på drift väljer vi att standardisera på en viss typ av operativ och plattform vilket vi sedan önskar att utvecklare ska förhålla sig till. Men det skapar inlåsning för utvecklarna, och ofta som ett resultat också situationer där det är oklart vem som ansvarar för vad till exempel i samband med incidenter.

Eller utvecklare sätter igång att utveckla på nya plattformar eller i egna verktyg där de dokumenterar sina behov och strukturer på ett sådant sätt att det inte är tillgängligt för drift (eller än mindre Servicedesken).

Igen i samband med incidenter så har vi till exempel inte en gemensam plats för att lagra och dokumentera kända fel i en produkt. Har vi också inom drift lyckats rulla ut någon form av CMDB så uppstår problem med att hålla denna uppdaterad då utvecklarna hela tiden ändrar i sina “system och applikationer” utan att det för den delen uppdateras i CMDB.

Och ett annat vanligt problem kan vara att tempot med vilket utveckling regnar ner sina releaser på drift gör att det bildas långa köer med releaser som ska produktionssättas som drift inte kan eller är förberedda att hantera.

Alltihop ovan får den olyckliga effekten att leverans till kund blir lidande både vad gäller time-to-market såväl som tillförlitlighet i termer av kapacitet, tillgänglighet och säkerhet. Låt oss inte heller ens nämna vad som är fallet om vi måste göra en större återställning i samband med någon katastrof eller liknande.

Men vad är då DevOps och hur löser det problemet ovan?

Eftersom DevOps dels är nytt men också dels faktiskt inte ger så många handfasta eller konkreta råd så låt oss belysa vad det inte är:

• Det är inte en organisationsform. DevOps kan visserligen betyda att vi väljer att omorganisera oss, men det är inte att slänga in 5 utvecklare och 2 driftare i en grupp och kalla dem DevOps.
• Det är inte ett ramverk eller en Best Practice som till exempel Scrum, ITIL eller Cobit. Däremot är det ett paraplykoncept som refererar till allt som vi gör för att skapa smidigare interaktion mellan utveckling och drift och därmed snabbare totalleveranser till kund med bibehållen eller förbättrad tillförlitlighet i drift.
• Det är inte att göra sig av med drift genom att lägga all drift i molnet. Visserligen kan vi säkert uppnå många önskade effekter men det är inte målet eller medlet. Intressant nog så var upphovsmännen till DevOps inte utvecklare utan traditionella “Sysmans” (system managers, eller driftspersonal).
• Det är inte en utvecklingsmetodik. DevOps beskriver inga specifika regler, råd, processer eller metoder för enkom systemutveckling utan har ett bredare perspektiv än så. Det bygger dock vidare på agil utveckling och i någon mån tar detta till nästa nivå.
• Det är inte en metod för automatisering. Visserligen kommer ett DevOps-initiativ säkert rendera i att ett antal processer, steg och aktiviteter kan komma att automatiseras, men då enkom i syfte att uppnå ett snabbare flöde från idé till produktion och i både drifts- och utvecklingsgruppens goda minne och deltagande i automatiseringen.
• DevOps är inte till för Utveckling eller drift enkom. Nej, tvärtom så står DevOps med varsitt ben väl förankrat i både utveckling och drift. Det säger egentligen att man inte får låta den ena sidan skapa bekymmer för den andra. Dvs utveckling och stabil drift måste vara det gemensamma målet för hela organisationen.

Principerna är beskrivna i termer av “three ways”

Med detta tar man vad som ibland kallas för ett systemperspektiv eller helhetsflöd. Dvs. istället för att titta på detta flöde silo för silo, så strävar man efter att skapa ett end-to-end flöde där de som arbetar i flödet bär med sig sin produkt hela vägen till slutmålet, inte till något delmål på vägen. Vidare så innebär detta att man aldrig får arbeta på ett sådant sätt att det skapar problem för nästa instans på vägen till slutmålet.

Med detta så menar man att flödet måste vara uppbyggt med fungerande feedback-mekanismer som gör att man för alla intressenter tar vara på deras intressen och åsikter om flödet och kvaliteten på leveranserna så att dessa ständigt identifierar och tillvaratar var förbättringar behövs.

Med detta så menas att vi måste fostra en kultur där ständiga experiment i förbättrade metoder och verktyg hela tiden görs i syfte att öka flödet med bibehållen och förbättrad kvalitet på slutprodukten. För att nå dit måste vi våga pröva nya saker, ifrågasätta gamla sanningar, utveckla Kaizenbaserade problemlösningsförmågor och acceptera misslyckanden för vad de egentligen är. En möjlighet att lära sig och förbättras. Den andra satsen fokuserar i sin tur faktiskt på att genom ständig övning, träning och repetition utveckla perfekta metoder för vårt arbete.

Sammanfattningsvis

För att undvika konflikter mellan drift och utveckling, förebygga konflikter och förbättra samarbetet i totala leveranser till kund ger oss DevOps värdefulla råd i sina synsätt. Tillämpningen måste följa de specifika förutsättningarna för varje organisation och är ett arbete som pågår över tid. Samarbete, kommunikation och gemensamma mål kommer vara centrala komponenter under alla omständigheter.