X

DevOps – Allt du behöver veta om DevOps

DevOps by Larsson & Co

En artikel om DevOps och vad vi på Larsson & Co menar att man behöver veta, tänka på och fundera över.

Är du nyfiken på DevOps så har du kommit rätt. Larsson & Co kommer att ge dig information, inspiration och tips om hur du kan förhålla dig till DevOps i din verksamhet. Vi börjar från början och det är inte så länge sedan som DevOps filosofin växte fram. Patrick Debois har fått stå som grundare av DevOps idéerna redan 2009 då han framförde sina DevOps tankar till en bredare publik. Det är dock viktigt att påpeka att DevOps är en ung företeelse med många olika förespråkare och varianter på ämnet.  Små- och mellanstor företag borde vara de som snabbast kan anamma DevOps men det är faktiskt ofta stora företag med komplexa miljöer som snabbast drar nytta av DevOps lättrörliga och snabba processer för att komma från utveckling till drift på ett snabbt och kvalitetssäkrat sätt.

Vad är DevOps, allt du behöver veta om DevOps

Klicka för stor bild

Effekter av en väl etablerad DevOps-organisation

  • Positiv kultur och attityd
  • Kontroll och förståelse för
    • vad vi gör och varför
    • vad vi har & relationerna dem i mellan
    • vad det kostar och vem som är ansvarig
    • våra risker och möjligheter
    • hela tjänstens livscykel
  • Tydligt ägarskap och ansvar
  • Bekväm med förändring
  • Överenskomna och säkrade kundlöften
  • Ökad förmåga att hantera risker
  • Ökad kundnöjdhet
  • Repeterbar och förutsägbar IT-leverans
  • Mätbar kapacitet, prestanda och leverans
  • Säkrade löften, kvalité och prestanda
  • Framgångsrika ändringar & utrullningar
  • Kortare ledtider
  • Färre incidenter och snabbare åtgärdstider
  • Ständigt förbättringsarbete
  • Leverantörer som en naturlig del av leveransen
  • Förutsägbarhet i vår tjänsteleverans
  • Möjlighet att planera & hushålla med tiden
  • Göra rätt saker
  • Styra konsumtion av våra tjänster

DevOps grundprinciper

DevOps bygger vidare på Agila arbetssätt för utvecklare med målsättningen att förbättra och modernisera hela processen av programutveckling. Bland annat genom 4 grundläggande principer:

  • Kommunikation
  • Samarbete
  • Integration
  • Modeller

 

Kommunikation

Kommunikation är ofta en källa till missförstånd. Begrepp och uttryck kan skilja sig mellan mottagare och avsändare i olika kommunikationskanaler.

Det snabba informationsutbytet gör att kommunikationen behöver säkerställas.

 

Samarbete

Av tradition har utveckling och driftavdelningar varit mycket måna om sina ”revir” och det har också speglas i bristande samarbete. De har nu fått tänka om då dagens snabba, flexibla och kvalitetsmedvetna programutveckling kräver agila arbetsmetoder som också ger fler, mindre och kvalitetssäkrade deployments.  Genom ett nära samarbete skapar man bäste möjliga förutsättningar för programutveckling.

 

Integration

Med multikompetenta team baserat på medarbetare med olika kompetenser skapas förutsättningar att gemensamt hantera frågor och problem tidigt i utvecklingsprocessen. Teamet ger möjligheter att kontinuerligt testa och validera programutvecklingen vilket ger färre och mindre justeringar istället för att som tidigare vänta tills det nästan är klart och sedan testa med en förhoppning om att man inte ska behöva börja om från början.

 

Modeller

Vattenfall har länge varit den förhärskande utvecklingsmodellen där man steg för steg utvecklar systemet och avslutningsvis testar man och om allt går bra. Det har varit en bra metod under många år men i dagens snabba utvecklingstakt behövs något som kan hantera den snabba teknik- och integrationsutveckling som sker i utvecklings- och driftsmiljöerna där IT verkar.

 

Agile metoder har växt ur behovet av en snabb, flexibel systemutveckling där man kan jobba i flera parallella processer och hela tiden kvalitetssäkrar utvecklingen och samtidigt kan man hantera snabba omvärldsförändringar. Genom den Agile utvecklingsmetodiken skapades ett ännu större avstånd mellan utveckling och drift eftersom drift länge höll fast vid den traditionella vattenfallsmetoden när de hanterade sina driftsprojekt. Det var detta avstånd mellan utveckling och drift som födde tankarna om DEVOPS ett tätt och integrerat samarbete mellan utveckling och drift som också säkerställer kommunikationen.

 

Buzz Word: CIDD (Continuous Integration, Delivery, Deployment)

Utvecklarna lägger kontinuerligt in sin kod flera gånger om dagen I ett utvecklingssystem och varje del testas omgående för att förhindra och förebygga programfel. Som en förlängning av integrationen och som ett nästa steg I programleveransen säkerställs att det alltid finns uppdaterad och tested kod I systemet så release kan göras när som helst. Med hjälp av de 2 föregående stegen säkerställs att ny  kod kan kontinuerligt deployas till produktion när testerna uppfyller release kriterier.

 

DevOps nytta för olika roller

Utvecklare:

Som utvecklare kan DevOps innebär en paradox. Man får en komplexare miljö med versionshantering av kod och kontinuerliga uppdateringar och tester i en flora av system som ska samverka för att hålla ihop utvecklingsmiljön. Samtidigt kan man koncentrera sig på det utvecklingsspåret som man jobbar i. DevOps speglar de nya krav på snabb utveckling, test och kvalitet som verksamheternas produktion ställer på dagens utvecklare. Dagens utvecklare har också ett större intresse och en större förståelse för verksamhetens behov än vad den äldre generationen utvecklare hade. Det kan bero på att i takt med ITs utveckling så har också ramverk som ITIL fått en större utbredning.

 

Testare:

Testare har länge haft en utsatt roll. Att täcka alla scenarier i tester har varit en grannlaga uppgift. Nu för tiden sker ett tidigt samarbete mellan utvecklare och testare för att utveckla inom ramar som tillåter automatisk testning. Men ett utvecklingsramverk som innefattar och anpassas för test så har testare fått en betydligt kortare led tid för att säkerställa tester som kvalitetssäkrar systemutvecklingen. DEVOPS har lyft fram testares behov som är ett krav för en snabb utvecklings cykel med hög kvalitet. Test sker idag i samma snabba tempo som utveckling med snabba releaser som är kvalitetssäkrade.

 

Drifttekniker:

Historiskt sätt så är detta en trög enhet. Det är fullt förståeligt då de ska försöka leverera en stabil drift i en miljö som ofta präglas av auto-uppdateringar som man måste hitta och stänga av för att inte äventyra driftsmiljön. Här vill man göra så få förändringar som möjligt så sällan som möjligt. Det håller inte längre. Idag krävs en högre flexibilitet och rörlighet vilket driftsorganisationer nu utvecklar. DevOps har varit en stor förändring för driften men tack vare den kvalitetshöjande testningen och ett tätare samarbete med utvecklare så uppnår man också driftens krav på stabilitet. De mindre och kontinuerliga deployerna gör också att eventuella fel endast ger en mindre driftstörning som ofta kan lösas omedelbart med en rollback. Det gör att även driften kan se positivt på det nya tankesättet.

 

Beställare/Förvaltare:

Som beställare har tiden till produktion blivit betydligt kortare. Med flera utvecklare som arbetar agilt med flera parallella utvecklingsspår. Ja, visst finns det fortfarande utveckling som är beroende av föregående utvecklingssteg men idag arbetar högpresterande utvecklingsteam i parallella spår där det är möjligt. Med en kortare utvecklingstid och test finns en ekonomisk aspekt som ofta definieras som ”Time to market” tiden det tar innan man kan lägga ut en ny tjänst till kunder och användare. Med DevOps kan en kortare tid till beställarens slutliga UAT (User acceptance test) skapas.

 

Användare:

Vilken nytta har man då som slutanvändare av att DevOps används i systemutveckling. Det första som kommer upp är snabbheten. I samband med att man hittar buggar så kan man oftast åtgärda de snabbt och JA, det kommer fortfarande förekomma buggar i programvaror och system. Det är i princip omöjligt att ha ett helt buggfritt system över tiden. Med det flexibla och lättrörliga arbetssättet kommer eventuella buggar att kunna rättas snabbt i de kontinuerliga små utrullningar som sker av deployer. Samtidigt kan användare förslag och andra förbättringar genomföras på kortare tid vilket gynnar användare. I system med frekventa uppdateringar genomförs dessa kontinuerligt vilket ger ett bättre system för användare.

 

Verksamheten:

Vad har verksamheten för nytta av DevOps. Har kommer de större frågorna in och bland annat kostnader. Om man ska arbeta effektivt med DevOps krävs ett batteri av samverkande programvaror som håller de olika systemen synkade. Det är versionshantering, testning, testdrift, deploy och produktionssystem som var och ett kan kosta en del pengar men när man jämför det med KPIn ”Time to market” så ser de flesta verksamheter nyttan med att snabbt få ut nya tjänster och förbättringar till användarna på marknaden som kostnadseffektivt både i det kort och långa perspektivet. Om man samtidigt räknar in den kunskapsöverföring som sker när medarbetare med olika kompetenser samarbetar så finns ett  stort dolt värde för verksamheten och för personalen. Det skapas en bredare förståelse i verksamheten.

 

DevOps i kristallkulan

De tidiga DEVOPS pionjärerna som Google, Amazon, Netflix m.fl. har hela tiden utvecklat olika DEVOPS modeller i sina verksamheter med lyckade resultat. Med de positiva ekonomiska effekterna tillsammans med bättre samarbetskultur, snabbare utveckling och kvalitetssäkrade leveranser så anser många att det är dags att hoppa på DEVOPS tåget. 55% av 700 IT ledare har redan implementerat DEVOPS och tittar nu på ytterligare förbättringar. DEVOPS trenden ger effekter även utanför de teknologiska delarna genom processer och samarbeten över yrkesgränser och även stabilitet och kvalitet.

 

DEVOPS har kommit för att stanna. Under de närmaste fem åren kommer det antagligen utvecklas ytterligare och sälla sig till de andra ramverken som används inom IT. Om man tittar på den accelererande utvecklingen inom IT å är det egentligen inte konstigt att DEVOPS föddes. Med verksamhetens krav om att snabbare kunna leverera tjänster till marknaden sattes fokus på utveckling som tidigt anpassade sig med agila arbetsmetoder. Det som blev flaskhalsen var istället driften som av naturliga skäl vill hålla en stabil miljö och det gör man bäst genom att störa så lite som möjligt. Genom att skapa förutsättningar för alla berörda har DEVOPS en given plats i IT världen. Den är ett naturligt steg för att följa den snabba och fortfarande accelererande IT utvecklingen.

 

Var tar det vägen nu då? På Larsson & Co ser vi en naturlig samverkan med ITIL som i sina Service transition processer har försökt strukturera samarbetet mellan utvecklare och Operations. ITIL har dock inte lyckats full ut och det har gett plats för ett snabbare och mer flexibelt synsätt som kallas DevOps och förhoppningsvis knyter vi ihop det i den stora ITSM säcken.

 

Risker med DevOps!

Jo visst finns det risker. De många utvecklingsverktygen måste vara stabila och ständigt synkade. Samarbetet måste fungera på en professionell nivå mellan de olika medarbetarna där man är överens om hur DevOps ska fungera i organisationen. Kommunikation är, som vanligt, grundläggande för att lyckas. Man måste vara överens om hur DevOps ska fungera och stödet måste finnas upp till högsta nivå inom verksamheten. Det finns säkert fler risker men inga som är så stora så att de tagit död på DevOps. Värdera riskerna och fokusera på hur man kan förbättra så kommer du långt och åt rätt håll.


Vill du träffa oss för en kostnadsfri och förutsättningslös workshop om ITSM, ITIL, DevOps och andra intressanta vägar och verktyg för din IT organisation så kontakta oss HÄR !

 

Tags:

Leave a reply

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *