Devops – jeg fatter det ikke!

Hos os satte vi dev og operations i samme rum. Det kom der rigtig gode ting ud af - fx at der bliver kort vej fra en opstået fejl, til udvikleren er i gang med at rette den. Og vi får også bedre løsninger i første produktionssættelse.

Jeg kan stærkt anbefale "The Phoenix Project" af Gene Kim. Det er en meget atypisk IT-bog, idet den faktisk er spændende og underholdende. Der er gode forklaringer på hvorfor DevOps er så interessant (fra et forretningsperspektiv).

...Kommentaren "med devops så er udviklere tvunget til at tænke over hvordan man får noget i drift" overser dette punkt. Jeg har en nyhed: Man kan ikke tvinge medarbejdere til noget som helst!

Jeg gætter på at vores udviklere du hentyder til når du skrive at de står for udvikling, QA og drift A-Z. Hvis det er, har jeg ikke været præcis nok i det jeg skriver. De står ikke for driften.

Nå vi for eksempel skal bruge en kø. Det kunne være RabbitMQ. Så køber vi en fully managed og hosted kø hos en SaaS leverandør. Vi taler om et firma der lever af at drifte RabbitMQ. De har folk der brænder for det, de har en ekspertise du aldrig vil kunne få in-house, de har prøvet at skalere RabbitMQ til volumner du aldrig vil nå. De har pakket det hele ind i lækker GUI hvor du selv kan gøre det du har brug for. Og de har en support hvor du kan få hjælp.

Så det er slet ikke fordi vi ikke har kæmpe respekt for driftsfolk og den ekspertise god ops kræver. Vi ansætter dem bare ikke.

Det gør også, at når vi fx har brug for Redis, så er der, bogstaveligt talt få sekunder fra vi har taget beslutningen om at bruge Redis, en korrekt konfigureret og 100% produktionsklar Redis klar til os. Konfigureret af folk der lever og ånder kun for Redis og de giver os support og rådgivning hvis vi har brug for det.

Hvis vi senere vil skifte til noget andet kan vi lukke ned for Redis og køre noget andet lige så hurtigt.

Det kan du så sammenligne med hvor lang tid det tager at snakke om at du vil køre Redis. Prøve at se om du kan finde to mennesker (ingen nøglepersoner) i driftsafdelingen der tilfældigvis brænder for Redis, oplære dem, få det provisioneret og driftet. Og så kan du gentage øvelsen når du vil skifte til noget andet.

Vores udviklere står for at drifte systemerne oven på dette lag af eksperter, Dvs. Når der lyder en alarm fordi en kø er ved at blive lang, så er det udviklerne der reagerer.

Køen kører undeliggende som den skal. Men en af vores services der skal tage af køen har måske et problem. Der er en ret klar skillelinje mellem hvad der er en udviklers opgave og hvad der ikke er. For alt det der ikke er udviklerens opgave kan de alligevel ikke gøre noget ved.

Hvis der er driftsproblemer som udvikleren ikke kan gøre noget ved, bliver deres opgave at opdatere vores status-side så kunder har information om problemet. Og at informere vores egen support, så de kan opdatere facebook osv.

Jeg håber det er mere klart, at det netop er på grund af respekt for ops, at vi ikke gør det selv.

Tak for de mange - og synes jeg - bestemt relevante kommentarer. Mange af dem viser, at mit udgangspunkt om, at det handler om mennesker og at få dem til at samarbejde mere end at det handler om at omorganisere, ikke er helt ved siden af.

Men jeg læser også eksempler på, at man kan få en gruppe af personer til at tage ansvar for software-udvikling/-drift fra A-Z. Det er godt gået, men måske ikke det typiske, da det kræver nogle specielle profiler.

I bund og grund er det en evig-gyldig diskussion om specialister versus generalister - for man kan vel ikke være dybt inde i alle dele af udvikling/drift-processerne? Måske reddes meget af - og styrker udviklingen af Devops - at mange af processerne omkring udvikling, test, QA osv. i stigende grad kan automatiseres - og dermed større behov for generalister og mindre behov for specialister.

Jeg har været i flere organisationer, hvor det var nødvendigt at skelne mellem salg på den ene side og leverance på den anden. Ganske enkelt fordi mennesker drives af forskellige ting og som personer er forskellige. Kommentaren "med devops så er udviklere tvunget til at tænke over hvordan man får noget i drift" overser dette punkt. Jeg har en nyhed: Man kan ikke tvinge medarbejdere til noget som helst!

Vi er 100% enige om, at der skabes større værdi ved, at alle i processerne har en god forståelse af de andre dele. Men at forestille sig en organisation, hvor alle er lige gode til alle dele fra udvikling, test, QA, deploy, drift osv - og i øvrigt interesserer sig brændende for alle områderne - er utopi. Så i de fleste tilfælde er der tale om specialisering og et behov for at man arbejder samme på tværs af denne specialisering. Det kræver selvfølgelig, at man ikke sidder i hvert sit tårn - så det er jeg helt enig i.

Til at starte med skal det siges at jeg har selv tidligere være værktøjs konsulent, der besøgte virksomheder og hjælp dem med at få automatiseret build & deploy, så mange på denne tråd vil nok allerede betrakte mig som partisk. Om hvorvidt det er gammelt kendt viden ved jeg vil jeg ikke udtale mig om, men jeg må da sige at tanke om at splitte sine projekter helt op så hvert team, er fuldt ansvarlig for hele life cycle manegement, ligger forbavsende langt væk i de fleste af de virksom heder jeg ha været i. Der forstiller man sig stadig at man har forskellige specialist team hvor man så flytter opgaven igennem de forskellige team, i stedet for at det enkelte team har fuld det fulde ansvar for at feature/fixet kommer i produktion. Hvis det er Buzz words der skal til for at vores leder fanger disse smarte ledelses tricks så er det vel det vi må bruge.

P.S. jeg arbejder nu ikke så konsulent med sider i en fast stilling hvor vi tools & automation

Jeg er meget enig med Allan Ebdrup her. For små firmaer ser jeg de samme fordele ved devops. Her er det uden tvivl en smartere måde at gøre tingene på. I tidligere projekter har jeg tit set at udviklere ikke bekymrede sig om drift. Hvis det virker på udviklerens maskine så er hans opgave løst. At der så skal så skal skrives kæmpe change management dokument hvor der skal ændres i en masse XML dokumenter for at tage noget i drift var heller ikke udviklerens problem.

Men med devops så er udviklere tvunget til at tænke over hvordan man får noget i drift. Og dermed tvunget til at skrive koden på en måde så den rent faktisk kan tages i drift uden besvær, og skrive tests der checker at det rent faktisk vil virke i drift.

Men jeg kan sagtens se at det er svært at udbrede i kæmpe firmaer med store dev og ops afdelinger.

Det nye ved Devops, set fra min stol er, at cloud og SaaS løsninger lader dig tage udviklerens nye fokus på driftssystemer, i stedet for eget lokal udviklingsmiljø, til ekstremer der ikke er set før.

Når servere, kø'er, databaser og alverdens andet infrastruktur kan provisioneres på få sekunder med et try på en knap, så har du slet ikke brug for folk med dyb operations ekspertise. De SaaS løsninger du bruger har en support siddende til at hjælpe dig med spørgsmål du måtte have. Du er selv uddannet på de centrale komponenter i systemet.

Således har vi i vores 10-mand store udviklingsteam fuldstændig afskaffet operations, og QA. En ændring der I stor stil har været drevet frem af udviklerne selv. Resultaterne er at vi leverer ca 140% af hvad vi gjorde før. Og meget vigtigt, så er det ikke gjort ved at arbejder mere, kun ved at arbejder mere intelligent. Der er 44% færre defects. Hvem ville have troet at det at afskaffe QA gav bedre kvalitet? Oppetiden har måltes i 3-4 niere over de sidste år. Men vigtigst af alt, det er meget sjovere at arbejde hos os. Ikke underligt, folk kan godt lide at tage beslutninger selv, og rent faktisk få noget fra hånden (Kun 3% af en udviklers tid går med møder).

Hvis der er driftsproblemer må den udvikler der lige er ved en computer træde til. Som Adrian Cockcroft fortæller om, så giver reglen "You build it you run it" meget stabile systemer, hvor root cause til et nedbrud altid findes og rettes.

Hvis en organisation på størrelse med Netflix kan implementere "You build it you run it", så kan KMD, CSC og alle de andre store også gøre det. Det gør de nok ikke, som du skriver er kultur meget svær at ændre. Der sker nok nærmere det, at der kommer nye firmaer der har bedre styr på den slags og overtager. Vi får se hvordan det står til om ti-tyve år, er KMD fortid?

Per, jeg synes du indrammer begrebet ret godt når du skriver "Devops er – blandt andet – at få integreret software udvikling, QA og operations, så det bliver muligt at højne kvaliteten af løsningerne, få hurtigere udrulning af nye eller opdaterede løsninger og større stabilitet.". For mig handler det om den kvalitetsbevidste udvikler, som kan følge sin software til dørs.

Det opnår man naturligvis ved at have nogle udviklere der forstår en meget stor del af den teknologi-stak man arbejder med. Man kan naturligvis ikke nøjes med et snævert indblik i et eller andet programmeringssprog med tilhørende standard-biblioteker, men er også nødt til at have indblik i hvordan man fx interagerer med databaser, filsystemer, netværksklienter osv.

Jeg har altid været med til at drifte de applikationer jeg har været udvikler på. Det sikrer at de rigtige mennesker er med når der skal fejlsøges på bugs eller ressource-flaskehalse. Jeg har svært ved at forestille mig hvordan jeg skulle kunne passe mit arbejde optimalt, hvis jeg ikke havde ret meget indflydelse på driftsmiljøet.

Jeg har engang set et eksempel på at drift og udvikling var så adskildt at udviklerne havde svært ved blot at få adgang til logfiler med henblik på fejlsøgning. Så er det altså op ad bakke.

Var jeres dev's med til at udvikle efi?

Og ledelses-opmærksomhed skal der til, for DevOps er noget der ændrer på organisationen - i al fald hvis man er oppe i den størrelse hvor Development og Operations er organisatorisk klart adskilt.

Så jeg er enig i at det handler om forandringsledelse - men der er mere i det.

Jeg sidder selv i Operations hos KMD, og var tidligere i Operations i CSC. Begge har Development afdelinger, og tro mig - der kan være meget langt mellem de to grupper! (Hos KMD sidder vi i forskellige bygninger, og sågar forskellige lokationer). Det er simpelt hen forskellige måder at se verden på, som Per også beskriver. Og når de to grupper så sidder i hver sin søjle i organisations-diagrammet, så bliver det alt for let bare at starte et "blame-game" når noget går galt eller en software release falder mellem de to stole. "DevOps" er derfor nyttigt som begreb for at bryde gennem muren og få gjort det klart for ledelsen at der skal gøres noget.

Men der er også mere end organisation i det. DevOps er også en anden måde at håndtere software release management, så man kan køre releases igennem meget hyppigere. Måske en mikro-release om dagen, i stedet for en stor release hvert halve år. Og det kræver dels en ændret tankegang (især hos Operations), og dels en langt større brug af automatiserings-værktøjer end man traditionelt har set hos drifts-folk. Der bliver mere programmering og mindre "gammeldags"/hands-on systemadministration. Dermed begynder det også at få nogle afledte effekter i form af at have en infrastruktur som understøtter automatisering, f.eks. bliver software-defined networking i stedet for gængse dedikerede netværks-enheder måske mere attraktivt.

(Den obligatoriske disclaimer: Ovenstående er ikke nødvendigvis udtryk for KMD's holdning, selv om jeg gør mit bedste for at overbevise dem :-))

Ud over kultur handler det også meget om mennesker. - Jeg har i hvert fald oplevet, at der meget nemt kommer en os og dem kultur i firmaet med distancerede development og operations afdelinger. Jeg sidder i en DevOps rolle nu. Jeg ser ligeså meget det med at bygge bro imellem mennesker der opfatter systemer og prioritering forskelligt som, at automatisere infrastruktur, sikkerhed, test, dokumentation (som nok er den gængse opfattelse af hvordan DevOps ser dem selv), Det med der kommer nogen mennesker der ikke helt passer ind i development og deres til tider fastlåste toolstack eller ind i operations i deres til tider fastlåste procedure (som der ikke er særligt egnede til, at ting forandre sig). Men som der elsker, at være lidt over det hele. Danne sig et overblik over kode struktur, toolstack, deployment, test, sikkerhed, dokumentation og kommunikere det ud i hele forretningen og på den måde hjælpe med, at drive produkterne i en retning der gør det hurtigere for udviklere, at udvikler og giver operations en ro om, at hvis ting fejler så er der tænkt løsninger ind over der kan håndtere det. Man kan kalde det kultur, disciplin alt muligt. - Nu er der nogen der har valgt, at kalde det DevOps (og dermed give det sit eget ord) - Det tror jeg der er flere, af os der til tider har følt os udstødte fra udvikling eller operations afdelinger der er glade for.

Spørgsmålet er, om det overhovedet er muligt at ændre en kultur, eller om der reelt sker en destruktion af eksisterende kultur og opbygning af en ny? Hvad er forskellen? set fra mit vindue er den store forskel, at man i en "ændring/udvikling" baserer det nye på det gamle - herunder at langt de fleste ressourcer (medarbejdere) er del af både det bestående, og det kommende. Op imod det står en udvikling, hvor ressourcer/medarbejdere forlader organisationen i en lind strøm i takt med kulturforandringen - måske i et så hurtigt tempo, at selve virksomhedens sammenhængskraft er udfordret. I min optik er der således ikke tale om forandring som betegnelse for udvikling, men som betegnelse for destruktion og opbygning. Man skal jo huske på, at "kultur" ikke kan begrænses til organisationen; kunder og andre interessenter er en del af den kultur. De køber hos dig, fordi de kan lide din måde at gøre tingene på... så når du ændrer på det, ændrer du dit samlede setup.

Resultatet kan (sagtens) være en stærk(ere) og fremtidsduelig virksomhed, men med mange nye medarbejdere -og måske nye kundesegmenter, kan man ikke tale om en kulturforandring, men om nedbrydning og opbygning af en ny (kultur).

Ja overskriften er vel lige så triviel gammeldags som det at gamle discipliner 'genopdages' og pakkes ind i et glitrende papir og en sjov hat - hvad skal konsulent husene ellers leve af?

Jeg morer mig også kosteligt over den kommende Disruption konference hvor en masse ledere kan finde ud af at det eksisterer og hvad de skal gøre.

Øeh... gode ledere ved det da i forvejen, eller tager jeg fejl af kvaliteten hos de danske ledere?

I en hvilken som helst organisation skal man sammensætte og koordinere teams, medlemmer og opgaver med skyldig hensyntagen til 'alle' parametre, der bla. tæller at kunne levere funktionalitet hurtigt, at skidtet virker og er sikkert. Sådan har det i hvert fald været for mig siden jeg i 1987 trådte ind i IT branchen.

Metodikkerne og værktøjerne har ændret sig, lige som at kompleksiteten er steget, men det har gode ledere og medarbejdere tilpasset sig løbende således at ketchup effekten udebliver.

Det er først farligt, også som medarbejder, hvis der ensidigt satses på en enkelt disciplin, altså at der frigives nye funktionaliteter hyppigt men at disse ikke testes og dokumenteres ordentligt.

Jeg kan naturligvis kun tale for mig selv, men Devops er, i hvert fald her, Mission impossible. Når en Dev'er udtaler at "Change management er ikke noget man bruger tid på" og når Ops'en ikke får nogen dokuemntation senere, så han lever af Change management.. så er der pænt langt til en Devops..

Nu vil sikkerhedsafdelingen heller ikke springes over, så i nogle kredse hedder det DevSecOps. Når QA er med, er det måske DevSecTestOps. Hvis vi arbejder lidt med det, og kan få rengøringen og kantinen med ind i begrebet også, får vi en virkelig rapid-agile-development på hyperspeed, med alle afdelingerne samlet i én stor boble. Det kan ikke gå galt, vel?

PS: Nej nej, jeg er ikke fortaler for siloer eller manglende samarbejde på tværs. MEN er hele det her hypede begreb ikke bare en "I skal arbejde lidt bedre sammen her"-tur?