Frukostmöte 7/5 – Problem med Problem

Hur kan vi använda Problem Management för att minimera sannolikheten för och påverkan av incidenter?

Vi ser några nyckelfaktorer till ett framgångsrikt arbete med Problem Management.

Vill du ha fler tips och idéer kring Problem Management titta på presentationen på vår YOuTube-kanal.

Frågor & svar

Under frukostmötet fick vi in flera frågor, vi hann inte med att besvara alla. Men du hittar våra tankar kring dessa frågor här.

Först vill vi bara påpeka att det är svårt att ge generella svar eftersom hur vi implementerar och använder ITIL varierar från organisation till organisation.
ITIL pratar om ”adopt and adapt” vilket betyder att vi skall anpassa ramverket efter oss men också anpassa oss efter ramverket. Detta är det givetvis viktigt att ta hänsyn till när ni läser svaren.

Vill du diskutera hur det ser ut hos er eller mer i detalj kring en fråga är du givetvis välkommen att kontakta oss.

Vill du veta mer?

Kontakta oss gärna för mer information eller bara för att diskutera mer kring ämnet.

Du hittar denna och tidigare frukostmöten på vår Youtube-kanal! Klicka här!

Hör gärna av dig!

Telefon: 031-337 57 50
Mail: info@larssonco.com

Klicka på bilden!

Klicka på bilden för att komma till presentationen!

Nästa frukostmöte

11 juni är det dags för
”Agile med ITIL – del 2”.

Läs mer och anmäl dig här:

ITIL® Frukost

Frukostmöte 26/3 – Agile med ITIL

Går det att få nytta av ITIL
när vi arbetar Agilt?

Absolut! Vi ser många fördelar med det!

Vår omvärld förändras därför behöver vi säkra att vi fortsätter hjälpa verksamheten skapa värde.
När vi utvecklar, levererar och förvaltar produkter och tjänster finns det stor nytta att kombinera ITIL med Agila metoder. ITIL 4 är uppdaterat för att hjälpa oss med just det.

ITIL 4 innehåller bra tips på hur vi kan lyckas.

I ITIL 4 beskrivs de tre begreppen nedan och hur vi kan skapa just Fast Flow, Feedback & Improvements:

Vill du veta mer?

Kontakta oss gärna för mer information eller bara för att diskutera mer kring ämnet.

Du hittar denna och tidigare frukostmöten på vår Youtube-kanal! Klicka här!

Hör gärna av dig!

Telefon: 031-337 57 50
Mail: info@larssonco.com

Klicka på bilden!

Klicka på bilden för att komma till presentationen!

Nästa frukostmöte

7 maj är det dags för
”Problem med Problem management”.

Läs mer och anmäl dig här:

ITIL® Frukost

Vad är DevOps egentligen?

Det är en rörelse som tycker att det är dags för förändring i IT-branschen – dags att sluta slösa pengar, tid att börja leverera bra programvara, och bygga system som är skalbara och livskraftiga. Denna rörelse som kallas DevOps. Men vad är DevOps? Var kom den ifrån? Och vad kan man uppnå?

Vilka problem försöker vi lösa?

Inom IT-branschen finns det ett tyst antagande att projekten kommer att bli sena, och när det har levererats (om det någonsin levereras) så kommer det att underprestera och inte motsvara den investering man gjort.

Låt oss ta en titt på några av de vanligaste problemen finns idag.

Rädsla för förändring

När en applikation levereras, tenderar företag att vara oerhört rädda för förändring. Att både programvara och plattform är som en glasbutik i vilken man måste gå väldigt, väldigt varsamt fram. Onödigt byråkratiska system för förändringshantering införs, och det tar plågsamt lång tid att införa nya funktioner, eller åtgärda problem med programmet.

Riskfyllda installationer

Detta är den situation där ingen är helt och fullt övertygad om att programmet kommer att fungera felfritt när det gått ”live”. Kommer allt beter sig som förväntat? Kommer det klara av belastningen? Ofta saknar vi svaren på dessa frågor – så vi trycker ut det när det är lite lugnt och kollar om det håller.

Det fungerar för migToppen!

Inte helt sällan dyker situationen upp när man gått live, att problem uppstår. Dessa problem dyker då oftast upp hos systemadministratörer, Helpdesk, kundservice som rapporterar vidare till utveckling, förhoppningsvis efter lite undersökning. Dessa problem är oftast plockas upp av systemadministratörer, eller helpdesk / kundservice människor. Utvecklarna tar en snabb titt och svarar: ”Det fungerar för mig”, vilket ofta blir lite felaktigt då miljöerna oftast ser rätt olika ut för utvecklare och användare.

Silofiering – flipperspelande

Man delar ofta upp projektet inom projektgruppen med för lite kommunikation emellan grupperna. Det är utvecklar, testare, release managers, systemadministratörer som alla sitter i varsina hörn och försöker jobba på sina respektive saker utan helhetsbild. Det resulterar ofta i att så snart något ändras i projektet så får respektive hörn helt nya förutsättningar. Lite lobba det över muren-mentalitet. Problem studsar runt som en flipperkula utan att bli lösta. Det skapar dessutom gärna en ”vi och dem”-mentalitet i den negativa bemärkelsen. Samma silofiering kan även uppstå inom team, dvs silos i silos.

I större bolag kan dessa silos finnas på olika platser, städer, länder. Det skapar gärna lite rädsla och misstänksamhet mellan silosarna.

DevOps tar sikte på att lösa de här problemen.

 

Hur kan då DevOps hjälpa?

I korthet kan man säga att DevOps utgår från att man genom att kombinera lämplig teknik med rätt attityd kan lösa dessa knutar.

Det handlar då om att förstå nyckeln att vi alla är på samma sida. Utvecklare, testare, chefer, administratörer, tekniker etc. alla vill samma sak. Leverera kvalitet, pålitliga system som skapar värde för dem som beställt det.

Genom att ha en bred kunskap inom teamet så har man lättare för att se helheten och sammanhanget. Ingen kunskap är mer värd än den andra. För att ta ett exempel med en lyxkrog, kocken är såklart viktig, men om ingen städar lokalen så kommer folk att stanna hemma. Till och med ett bryskt bemötande vid bordsbokningen eller i garderoben ger kanske ett försämrat intryck.

teamSå för att lösa problem eller beställningar behövs alla färdigheter. Så genom att bygga team med interdisciplinära kunskaper når man framgång, snabbt och säkert.

Utöver detta tvärfunktionella tillvägagångssätt försöker DevOps främja utvecklingen av kommunikationsförmåga, en förståelse för omgivningen, och framför allt, en känsla och passion för verksamheten, och för att säkerställa allas framgång (hela bolaget).

På samma sätt som att två personer kan se sina arbeten på olika sätt, stenläggarna som på frågan vad de gör svarar den ena: ”jag lägger de här stenarna i våg”, den andre: ”jag bygger en väg till Rom”.

KommunikationDet kan tyckas självklart, men kommunikationen är verkligen en av de största nycklarna. DevOps är en brobyggare. Att bygga system och program med hög kvalitet är svårt – det är mycket som kan gå fel, det är riskabelt, det är oförutsägbart. Under de senaste tio åren eller så, har program- och systemutvecklare börjat inse detta och därmed har det dykt upp en hel del metoder, agila arbetssätt och modeller som försöker underlätta, även tekniska framsteg som rör testning har såklart hjälpt till otroligt mycket.

Men det finns fortfarande ett gapande hål, från ”Development Complete!” till  ”live, stabil, inkomstbringande” är det fortfarande ofta en bra bit kvar.

Ett vanligt problem är att det ofta finns en schism, brist på tillit och förtroende mellan Dev och Ops. De kanske endast har sporadisk kontakt med varandra. Systemägarna/systemadministratörerna har ingen aning om vem de ska prata med, de sitter kanske inte ens i samma stad. Man måste förstå att samarbete är mycket mer än ett ord på ett papper.

Så DevOps kännetecknas av personer med bred kompetens – människor som är bekväma med infrastruktur och konfiguration, gillar att kavla upp ärmarna, köra tester, felsöka funktioner och leverera. Dessa är människor som skapar nya kontakter, bygger broar mellan silos. Eftersom de har fötterna i flera läger så kan de vara ambassadörer, fredsmäklare, handledare och kommunikatörer. Poängen med DevOps är att identifiera dessa, för närvarande sällsynta, människor och uppmuntra dem, jämföra idéer och börja identifiera, utbilda, rekrytera och dessutom skapa en kultur som främjar det arbetssättet för att kunna skapa fler.

Detta har en enorm inverkan på verksamheten. Plötsligt börjar alla dra åt samma håll. ”Alle man på däck”-mentalitet blir något varaktigt. Tekniker som suttit i sitt hörn med sina uppgifter känner både ansvar och att de har befogenheter att agera på alla områden.

Traditionella problemområden som driftsättning och underhåller blir mer lätthanterligt. Det här ger såklart en positiv effekt på sista raden. Bättre tillgänglighet och tillförlitlighet, nöjdare kunder, kortare tid till marknaden, mer tid att fokusera på kärnverksamheten än brandsläckning och administration.

Sist med inte minst, det blir mycket roligare att gå till jobbet!

 

-Antonio Tomar


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 !

 

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

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

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 !