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

av | jun 29, 2017 | DEVOPS

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.

Vad består då DevOps av och vad betyder detta för en organisation?

DevOps är ett bekräftande att utveckling och drift måste samarbeta under gemensamma principer som alla syftar till att säkerställa att leveransen från krav till fungerande produktion ska ske på snabbast möjligast sätt till bästa tänkbara kvalitet end-to-end. DevOps eliminerar myten att vi måste välja mellan stabil drift eller snabb anpassning.

Principerna är beskrivna i termer av “three ways

The First Way Of DevOps

The outcomes of putting the First Way into practice include never passing a known defect to downstream work centers, never allowing local optimization to create global degradation, always seeking to increase flow.

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.

The Second Way Of DevOps

The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it.

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.

The Third Way Of DevOps

The third way is about creating a culture that fosters two things: continual experimentation, which requires taking risks and learning from success and failure; and understanding that repetition and practice is the prerequisite to mastery.

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.

Vill du förstå de 3 principerna?

En globalt erkänd DevOps-kurs där vi inte bara rör vid de tekniska koncepten, såsom pipelines och autmatisering, utan även kring teamuppbyggnad och kultur!

CIO-utmaningar 2024

CIO-utmaningar 2024

Snälla, kan inte någon berätta vad #¤%#¤% DevOps är … av Torbjörn Dahlström | jun 29, 2017 | DEVOPS I takt med att den digitala transformationen accelererar, blir IT alltmer kritiskt för företagens framgång. Trots detta finner sig CIO:er och IT-avdelningar ofta på efterkälken…

Författare
Torbjörn Dahlström

Jag har en idé om att vi kan bättre. Vi kan få ut mer värde av våra IT-initiativ. Vi kan korta ledtider i leveranser. Vi kan knyta verksamhet och IT närmare. Och vi kan samtidigt få nöjdare och mer motiverade medarbetare på köpet. Läs mer om Torbjörn

Kostnadsfri rådgivning

Vill du prata med oss för en kostnadsfri rådgivningssession kring era behov/utmaningar? Kontakta oss genom formuläret nedan!

Share This