Har du slutit DevOps oändliga loop efter driftsättning?

Kan vi sluta DevOps oändliga loop med IT service management?

”Förvirringens mur” har två sidor. Den ena vetter mot utveckling och den andra mot drift. När muren illustreras ser vi vanligtvis ett flöde från utveckling till drift, och sällan i motsatt riktning.

DevOps illustreras däremot på ett helt annat sätt – som en oändlig loop som beskriver vilka områden vi behöver täcka och vilka förmågor vi behöver ha som produkt- eller tjänsteorganisation. Som vi alla vet handlar DevOps om att riva ”förvirringens mur” och förändra hur Dev och Ops arbetar tillsammans. Vi strävar efter att bygga en kultur där Dev och Ops samarbetar för att ofta leverera värdeskapande kod av hög kvalitet, med ett sammanhängande flöde från discovery till kontinuerlig feedback.

Men svara ärligt på det här. Fokuserar vi verkligen tillräckligt på vad som händer efter Deploy? Missar vi inte många aspekter av samspelet mellan Ops och Dev?

Den här bloggen handlar om att koppla samman DevOps-loopen och rikta fokus mot Ops-sidan och hur den kan bidra till product discovery. Jag vill också gå igenom hur vi kan arbeta med IT service management (ITSM) för att få insikter om hur vi kan leverera hög tjänstekvalitet och värde till kunderna.

Vad menar vi med drift i DevOps?

Om du ställde den här frågan till tio personer skulle du förmodligen få tio olika svar. Personligen skulle jag sammanfatta det som arbetssättet och förmågan att säkerställa att det som driftsätts hanteras, är tillgängligt och har rätt kapacitet och säkerhetsnivå.

Vem gör vad i operate?

När kod har driftsatts i produktion och bekräftats fungera ansvarar driftteamen för att säkerställa att allt är online. Hur detta görs varierar beroende på arkitekturen för de tjänster som levereras. Är allt on-premise, eller finns det en mix av infrastructure-as-a-service (IaaS) och platform-as-a-service (PaaS) för olika delar av tjänsten? Är driftteamet internt, outsourcat, co-sourcat eller multi-sourcat?

Det spelar egentligen ingen roll, men vi behöver fokusera på samarbete och förväntningshantering mellan de olika intressenterna.

Det som spelar roll är att vi behöver säkerställa att vi får information från alla parter för att kunna fatta beslut och prioritera vilket arbete som behöver göras. Vi vill till exempel kunna fatta beslut som förhindrar att teknisk skuld byggs upp och säkerställa att förändringar i miljön inte stör de tjänster som levereras.

Här är samarbetet mellan Dev och Ops avgörande för att fatta rätt beslut och ge insikter till Product Discovery. Det finns många olika verktyg på marknaden för operate-delen av DevOps. Varje verktyg tillhandahåller olika data och information på olika sätt – och alla har olika syften.

I ITIL4, som är ett ramverk för ITSM, finns några principer som är relevanta för ämnet:

• Samarbeta och främja synlighet

• Håll det enkelt och praktiskt

Vi behöver säkerställa att data och information från driftverktygen är tillgängliga och enkla att använda för intressenterna, oavsett om det gäller en produktchef, produktdesigner eller ledande produktutvecklare. Det förbättrar deras förmåga att hantera och utveckla tjänsterna på ett bra sätt.

Som organisation vill du också säkerställa att beslut fattas på rätt nivå. Operativa beslut bör fattas så nära driftteamet som möjligt, helst inom teamet. Det ger teamet bättre förutsättningar att arbeta mer självständigt och Agile. Om du vill ha IT Service Management med högt tempo behöver du i möjligaste mån eliminera slöseri, som överlämningar och väntetider. Lita på dina team, oavsett om de arbetar med Dev, Ops eller DevOps.

Hur observerar vi?

Låt oss börja med en fråga: Varför observerar vi? Om svaret bara är ”Vi vill övervaka våra applikationers prestanda” hjälper det inte ur ett ITSM- eller DevOps-perspektiv. Vi måste vara tydliga med vad vi avser att göra med informationen från våra observationer, och vem som kan och kommer att använda den.

Vi behöver också kunna svara på om resultatet vi fick var bra, dåligt eller förväntat. Den främsta anledningen till observation och övervakning är att förbättra det som observeras, inklusive att åtgärda sådant som inte fungerar.

Kontinuerlig förbättring är en central förmåga inom Lean, DevOps och ITSM. Därför behöver vi säkerställa att verktygen vi använder för observationer ger relevant information som hjälper oss att hitta förbättringsområden. Informationen är avgörande för produktchefer, produktdesigners och ledande produktutvecklare som ansvarar för att vi kontinuerligt förbättrar våra tjänster.

Vi vill ge dem rätt förutsättningar att agera på avvikelser som identifieras genom observation, så att vi inte missar tekniska förbättringar, nödvändiga förändringar i arbetssätt, verktyg eller samarbeten med partner.

Så vad observerar vi i en DevOps-miljö? Om vi tittar på mätvärdena i en DORA-rapport omfattar de:

• Driftsättningsfrekvens (hur ofta ett mjukvaruteam skickar förändringar till produktion)

• Ledtid för förändringar (tiden det tar innan committad kod körs i produktion)

• Andel misslyckade förändringar (andelen incidenter, återställningar och fel av alla driftsättningar)

• Tid till återställd tjänst (tiden det tar att återställa tjänsten i produktion efter en incident)

De två sista punkterna är nära kopplade till ITSM. Den första handlar om ITIL-praktikerna förändringskontroll och incidenthantering, medan den sista handlar om incidenthantering. Det innebär att vi behöver övervaka incidenter och förändringar i produktmiljön samt kunna koppla dem till varandra för att få fram ITIL:s kvalitets-KPI för incidenter orsakade av förändringar. En del av detta kan automatiseras genom att integrera CI/CD-pipelinen med förändringskontroll i exempelvis Jira Service Management.

Vad mer behöver vi observera för att förbättra de tjänster vi erbjuder våra kunder? Listan kan bli väldigt lång, men vad sägs om interaktioner med användarsupporten, användningen av tillgängliga tjänstefunktioner och produktens användarupplevelse?

För produktorganisationer är det avgörande att mäta användningen av olika funktioner och hur ofta människor använder standardtjänsten för att hitta nya möjligheter till fortsatt utveckling. Produktchefer, produktdesigners och ledande produktutvecklare behöver kunna identifiera vad som skapar värde för slutanvändarna, så att de kan ta bort alla aktiviteter i backloggen som inte skapar kundvärde.

Vissa studier visar att det inte är ovanligt att en tredjedel av backloggen inte skapar något värde för slutanvändaren. Det är bara slöseri som tar plats från det som faktiskt gör det.

Ett vanligt misstag vid arbete med övervakning och observation är att inte täcka in olika dimensioner av grundorsaken till avvikelser. Inom ITIL finns en praktik som kallas problemhantering och som är nära kopplad till kontinuerlig förbättring. Syftet med den är att hantera återkommande kvalitetsproblem, som incidenter. När man arbetar med problem för att hitta deras grundorsak är det viktigt att analysera dem i fyra dimensioner:

• Organisationer och människor

• Information och teknik

• Partner och leverantörer

• Värdeströmmar och processer

I teknik- och produktorganisationer är det inte ovanligt att endast information och teknik täcks in vid en grundorsaksanalys. Det begränsar kraftigt möjligheten att hitta den verkliga grundorsaken, eliminera den och förbättra tjänstekvaliteten. Om du inte analyserar alla dimensioner är det sannolikt att samma typ av tekniska avvikelse dyker upp gång på gång.

Hur kan vi arbeta med kontinuerlig återkoppling?

Mycket av den information och data vi samlar in inom Ops kan presenteras i rapporter och dashboards för att göra oss datadrivna, eller analyseras av AI. Men vi behöver också forum för samarbete och dialog där vi kan lära av varandra. Ett bra sätt att uppnå detta är att låta kundsupportteam regelbundet träffa Dev- och Ops-team för att dela tankar och bygga goda tvärfunktionella relationer. Det skapar i sin tur en kultur av samarbete och transparens, som är grundläggande principer inom ITSM, Agile, Lean och DevOps.

Det vi hittar under drift och observation behöver bedömas, utvärderas, prioriteras och dokumenteras för att vara användbart i de återkopplingsloopar som går vidare till product discovery. Vi behöver strukturera data till information och lägga till kontext för att skapa kunskap som blir underlag för beslutsfattande. Möjligheter behöver presenteras, värde identifieras, risker hanteras och allt behöver vara väl förberett för att product discovery ska kunna utvärdera, prioritera och fatta beslut.

Att sluta loopen

I det här sista steget anser jag att vi har gjort stora framsteg med att sluta DevOps oändliga loop från driftsättning till product discovery. Det finns förstås inga universallösningar eller magiska lösningar som passar alla organisationer. Men varje organisation kan identifiera och ta steg mot ett komplett DevOps-arbetssätt som är tätt integrerat med ITSM-praktiker och det arbete som Ops utför.

Det första steget är att utvärdera och identifiera era styrkor och svagheter inom arbetssätt, verktyg och kultur.

Sammanfattning av åtgärder att överväga

Samarbete och dialog

Samla olika team – kundsupport, utveckling och drift – för att dela insikter och bygga tvärfunktionella relationer. Skapa en kultur av samarbete och transparens med grundläggande principer från ITSM, Agile, Lean och DevOps.

Strukturerad datatransformation

Omvandla rå driftdata till strukturerad och meningsfull information. Sätt informationen i ett sammanhang för att skapa kunskap som kan användas som underlag för beslutsfattande.

Prioritering och utvärdering

Bedöm, utvärdera och prioritera observationer från driften så att endast den mest avgörande återkopplingen når product discovery-fasen.

Integrera feedback i produktutforskningen

Skapa sätt att använda informationen från Observe och Continuous feedback under produktutforskningsfasen för att utvärdera, prioritera och fatta beslut. Då kan ni använda det ni lär er i driftfaserna när ni utvärderar nya funktioner eller förbättringar.

Kontinuerlig observation och övervakning

Använd observationsverktyg som ger relevant information till alla i DevOps oändliga loop, särskilt drifttekniker, produktchefer, produktdesigners och tekniskt ansvariga produktledare. Ge teamen rätt förutsättningar att agera på avvikelser och förbättringar som identifieras genom observation.

Rotorsaksanalys

Säkerställ att ni genomför en fullständig rotorsaksanalys genom att beakta alla fyra dimensioner som anges i ITIL4:

• Organisationer och människor

• Information och teknik

• Partner och leverantörer

• Värdeflöden och processer

Begränsa inte detta till enbart den tekniska dimensionen. När teamen tar hänsyn till alla dimensioner kan de få en helhetsbild av och hantera alla bakomliggande problem.

Gör kontinuerlig förbättring till en del av ert DNA

Det främsta syftet med observation och övervakning är att kontinuerligt förbättra det som observeras. Se till att detta tankesätt finns i organisationens DNA och uppmuntra teamen att vara proaktiva med feedback för att främja och möjliggöra kontinuerlig produktförbättring.

Integrera och bygg upp analysförmåga

Säkerställ att era verktyg är integrerade för att möjliggöra automatisering av åtgärder och mätetal. Ett exempel är att integrera er CI/CD-pipeline med ert ITSM-verktyg för att använda ITIL-praxisen change control.

Slut feedback-loopen

Kommunicera, kommunicera, kommunicera. Se till att information från driften inte fastnar i silos, utan flödar från Operate till Product Discovery för att sluta DevOps oändliga loop.