Lavere risiko, høyere kvalitet

I en nyoppstartet bedrift, for eksempel for en ny og innovativ nettjeneste, er de fleste av de som jobber i virksomheten involvert i det meste av det som skjer, og kanskje særlig i forbindelse med utviklingen og leveransen av selskapets hovedprodukt.

Det er kort vei mellom alle som deltar i dette, og kommandolinjene er enkle. Innovasjon foregår uten stans, og brukerne av tjenesten nyter godt av stadige oppdateringer og forbedringer av produktet.

Én måte å beskrive denne måten å jobbe på, er ved hjelp av den relativt nye termen «devops» - en sammensmelting av begrepene «development» og «operations», altså utvikling og drift.

- Et lite nyoppstartet selskap er ofte i sin natur devops-orientert. Der må alle gjøre alt, der må de utvikle, drifte og selge, fordi de er få personer med lite ressurser. Det har nok definitivt alltid vært sånn, mener Stein Inge Morisbak, grunnlegger av Devops Norway og leder for devops og nettsky i Bekk Consulting.

Industrimetodikk

Denne arbeidsmåten står i sterk kontrast til mer tradisjonelle tilnærminger til systemutvikling, som foregår i langt større organisasjoner. Der har utvikling og drift forlengst skilt lag, og utvikling foregår etter metoder som opprinnelig har kommet fra helt andre engineeringsdisipliner enn programvareutvikling. Det kommer av at da programvareindustrien var ung, fantes det ingen formelle utviklingsmetodikker for programvare, så eksisterende industrimetoder ble tatt i bruk, også for programvareprosjekter.

Den tradisjonelt mest brukte metoden i større it-prosjekter omtales ofte som «vannfallsmetoden». Det er en stringent og lineær prosess, med sekvensielle faser som etterfølger hverandre, akkurat som strykene i et vannfall. Som regel består disse hovedfasene av kravspesifikasjon, design, implementering, verifikasjon og vedlikehold. Et grunnpremiss i vannfallsmetoden er at man ikke går til neste fase før den foregående er ferdig, verifisert og godkjent.

Det er heller ingen systematisk feedbackmekanisme mellom de påfølgende leddene, noe som ikke åpner for at tilpasninger som følge av praktiske erfaringer har noen plass i vannfallsprosjekter.

Vannfall er resultatet av tenking som har sin opprinnelse i produksjons- og konstruksjonsindustriene, virksomheter som er preget av høy grad av struktur, og der sene endringer er forhindrende kostbare eller umulige å gjennomføre i praksis.

Problemet er at denne tilnærmingen ikke passer spesielt bra for programvare, en teknologi som har adskillig mer grunnleggende fleksibilitet i seg enn det produksjon og konstruksjon har.

Passer programvare

Det har allerede pågått arbeid med å finne fram til mer egnete utviklingsmetoder for programvare i etpar årtier. Siden det er mulig, innenfor de grunnleggende rammene for programvare , å lage hva som helst på hvilken som helst måte, bør metodene i større grad gjenspeile den grunnleggende fleksible naturen som programvare har.

Det er mulig og ønskelig at mange eller alle av sluttbrukerne skal involveres i programvareutvikling på et langt tidligere tidspunkt enn det som er praktisk i de tradisjonelle engineeringsdisiplinene. Det er også mulig å endre koden med tilhørende funksjonalitet på en helt annen måte enn ved konstruksjon og industriell produksjon.

[Devops] er en kryssdisiplinær måte å bygge, videreutvikle og drifte it-systemer i stor skala.

De siste 15-20 årene har det derfor dukket opp mange forskjellige nye tilnærminger til programvareutvikling, som bedre gjenspeiler programvarens egenart.

Devops kan sies å være en samlende konklusjon på mange av disse nye metodene, som tar opp i seg både veldefinerte metodikker, i tillegg til å se på hvordan virksomhetene kan organisere seg på best mulig måte for å understøtte utvikling og drift av programvare.

- Det finnes en definisjon på devops som jeg liker: Det er en kryssdisiplinær måte å bygge, videreutvikle og drifte it-systemer i stor skala. I sin reneste form er devops egentlig at utviklere og driftere jobber sammen om å utvikle it-systemer, som inkluderer både utvikling av programvaren og drift av plattformen, forklarer Morisbak.

- Men så oppstår det masse i tillegg, at man lager litt utvidete definisjoner, og putter mer inn i begrepene, legger han til.

Rive siloer

I større og modnere virksomheter lever programvareutvikling og tjenestedrift i to forskjellige organisasjoner med forskjellige målsetninger og suksesskriterier. Det er et grunnleggende hinder for best mulig programvareutvikling, mener Morisbak.

Fienden til stabilitet er jo endring, ikke sant?

- Det klassiske skillet som har skapt problemer, er at drift måles på stabilitet, og utvikling måles på endring. Fienden til stabilitet er jo endring, ikke sant? Så man har blitt målt på to vidt forskjellige ting, og dermed oppstår det konflikter mellom de to siloene, forklarer han.

Morisbak mener også at det er viktig å ta inn over seg at det er den som har skoen på, som kjenner hvor den trykker. Det slår begge veier i tilfellet med utvikling og drift, slik at begge partene vil tjene det overordnete målet bedre, om de har mer innsikt i hva som foregår i den andre situasjonen.

- Det har veldig mye med disse to siloene å gjøre, som gjør at samarbeidet og veldig mye annet blir vanskeligere. Det er ofte flere feil, og mer risiko fordi de ikke kjenner til hverandre. De som drifter vet ikke hvordan programvaren er lagd, og hva som skal til for at den skal kjøre. Og de som lager programvaren har ikke tilgang til produksjonssystemet for å lese logger eller for å vite hvordan ting henger sammen. Disse overleveringene har hatt veldig mye å si, sier han.

- I den opprinnelige betydningen av devops, handlet det om å rive ned siloene til utvikling og drift. Det har imidlertid medført mye mer, for eksempel det med kontinuerlige leveranser, oppsummerer han.

Smidig utvikling

Morisbak argumenterer med at når man ser på drift av plattform og utvikling av programvaren samtidig, når du har et team som gjør dette sammen, så oppstår det en del nye muligheter og effekter som gjør at vi endrer måten vi gjør mange av de tingene på. Av den grunn er det viktig å forholde seg til flere begreper enn bare «devops» for å forstå moderne systemutvikling.

- Devops muliggjør det å være smidig i større deler av organisasjonen enn kun i programvareutvikling. Smidig kommer jo fra programvareutvikling. Smidigmanifestet som smidig kommer fra, det var det utviklere som skrev, og de tenkte på utvikling. Der står det ingen ting om plattform og slikt, men med devops har man i tillegg også omfavnet den delen inn i smidig tenkning, forklarer han.

- Glem Scrum

Mange tenker på metodikken Scrum når noen snakker om smidig programvareutvikling. Begrepet har eksistert i denne sammenhengen i flere årtier allerede, og Morisbak mener at det er på tide å gå videre derfra nå.

Jeg mener det er på tide å glemme Scrum.

- Scrum er vel den mest utbredte smidig-metodikken, mens Kanban er mer og mer på vei inn. Scrum prøver å tilpasse sin metodikk til å passe mer til hvordan folk jobber nå, men jeg mener det er på tide å glemme Scrum og heller tenke på mer flytbaserte metodikker. Der man ikke jobber med tidsbokser på ting man gjør, sier han.

- Ofte er Scrum implementert på en sånn måte at det er et stort vannfallsprosjekt, som bare er stykket opp i mindre biter. Hvis du definerer det slik at slutten av en sprint skal havne i produksjon, får du ekte feedback, men det syndes det veldig mye mot. Ofte gjør man noe ferdig, og sier at det er ferdig, men det er ikke satt i produksjon. Produksjonssetting kommer gjerne et halvt år ned i løypa, og da sier det kræsj. Produksjon er noe helt annet enn et testmiljø, slår han fast.

Kontinuerlig for kvalitet

En del av tenkingen bak smidig-begrepet handler om tidlige leveranser av kjørbar kode som brukerne kan forholde seg til under utviklingens gang, og åpner også for tilbakemeldinger som påvirker det endelige produktet. En del av dette er å realisere funksjonalitet kjapt, noe som jo er ønskelig, og som står i kontrast til tradisjonelle industrier.

- Det er et mål å få funksjoner ut fortere, men det har ikke noe med devops å gjøre. Det har mer med kontinuerlige leveranser å gjøre, men devops muliggjør kontinuerlige leveranser, oppklarer Morisbak.

En viktig forskjell mellom programvareutvikling og tradisjonell industri, er at veien mellom ide og funksjon i produksjon, ikke trenger å være spesielt lang. Med programvare er det mulig å gjøre små endringer fortløpende, og det er også mulig å ombestemme seg, og rulle tilbake om funksjonen ikke er formålstjenlig.

- Hvis du leverer kontinuerlig, kanskje mange ganger om dagen i sin ytterste konsekvens, så er det veldig små endringer som går i produksjon. Da har du veldig god kontroll på endringene, så hvis noe går galt, så vet du akkurat hva som har gått galt. Så på den måten kan du si at du reduserer risikoen. Jo hyppigere du leverer, desto mindre risiko blir det. Da blir det også mindre behov for testing, fordi du slipper å teste masse funksjonalitet som du kanskje ikke har fullstendig oversikt over, forteller Morisbak engasjert.

Han er krystallklar når vi for å oppklare direkte spør om han virkelig mener at kontinuerlige leveranser er kvalitetshevende:

- Ja, definitivt! Hovedårsakene til at man gjør dette, er at det reduserer risiko og øker kvaliteten. I tillegg er det jo slik at man korter ned feedbackrundene noe veldig. Ved å gjøre eksperimenter i produksjonen, ved å slippe noe smått og se hvordan brukerne reagerer på det, kan man enten endre på det eller trekke det tilbake og gjøre noe annet, utdyper han.

Automatisering er viktig

En grunnforutsetning for å kontinuerlig levere og produksjonssette programvare er automasjon. Det krever systemer som tar fatt i kildekoden som utvikleren slipper fra seg, og automatisk kompilerer, tester og igangkjører den.

En viktig bit av kontinuerlig utrulling er automatisering.

- En viktig bit av kontinuerlig utrulling er automatisering. At man automatiserer absolutt alt som kan automatiseres, slik som sikkerhetsrevisjoner, ytelsestesting, alt som har med etterfølgelse av regler, utrulling og så videre, sier Morisbak.

- Du bygger opp en pipeline fra innsjekket kode ut til produksjonen, der du må gjennom en masse automatiserte steg, og passerer du ikke alle disse stegene, går det rett tilbake for å fikses, legger han til.

Overvåking må til

Morisbak peker ut en annen viktig teknisk detalj i denne sammenhengen, monitorering. Produksjonssystemene må overvåkes for at utvikleren skal kunne forvisse seg om at programvaren fungerer som tenkt i den virkelige verden.

- Det er et veldig viktig sikkerhetsnett, som på mange måter tar over for testing. Det blir jo mye mer testing i produksjonen, understreker han.

- Dette handler om både klassisk monitorering, men også at du implementerer det som en del av applikasjonskoden. Du vet at i denne biten av koden har du noe du ønsker å monitorere, på samme måte som at du ser at det er noe du trenger å teste, så lager du applikasjonskode som integrerer seg med et monitoreringssystem som gjør at du kan følge med, utdyper Morisbak.

Dette er til en viss grad sammenlignbart med tradisjonell overvåking av it-systemer, der man både kan regelmessig spørre de overvåkete systemene om status og andre data, eller at systemene alarmerer overvåkingssystemet på eget initiativ når unntakssituasjoner måtte dukke opp.

- Dette kan gjøres på mange måter, monitorering er et veldig stort emne i seg selv, fastslår Morisbak.

Devops er reorg

Som vi har sett, handler devops om mye mer enn bare en enkelt metodikk. De opprinnelige forkjemperne for devops omtaler det like mye som en «bevegelse» enn en spesifikt sett av regler som skal følges.

Under årets Devopsdays Norway-konferanse i Oslo i høst, sa den belgiske devops-forkjemperen Kris Buytaert under sitt foredrag at devops betyr reorganisering når vi ser på de aller fleste eksisterende og modne organisasjoner. Det er også viktig å organisere seg riktig, igjen fordi devops ikke er en ren metodikk, det er en bredt anlagt måte å jobbe med utvikling og drift av it-systemer.

-  Ikke kall det for et «devopsteam». Da har du bare lagd flere siloer i organisasjonen, ikke færre. Devops er ikke en jobbtittel eller en rolle, det er en tenkemåte vi alle må ta opp, formante Buytaert.

- Det første rådet jeg pleier å gi, er å plassere teamet sammen. Grunnen til det, er at de trenger å bli kjent med hverandre, de trenger å drikke seg fulle sammen, de må kjenne samme skoen trykke og de trenger å være på vakt sammen. Du trenger å bygge et team. Et team er ikke en gruppe mennesker som sitter sammen, det er mennesker som forstår hverandre og stoler på hverandre, fortsatte han.

Slutt med it-prosjekter

Morisbak svarer noe tilsvarende når vi spør om hvordan en tradisjonell organisasjon skal kunne komme seg i gang med devops.

- Det er jo ikke småtterier dette, det krever mye. I stedet for å fokusere på teknologi og verktøy og sånne ting, så krever det organisasjonsendringer og endringer i måten man bygger forretningen sin på. Så det første steget man kan gjøre, er å slutte med it-prosjekter, og heller utvikle programvaren sin i [forretnings]linja. Det er ikke noen grunn til å bemanne opp store it-prosjekter for å løse noe man tror man vil ha behov for et eller annet sted langt fram i tid. Det er bedre å gjøre alle disse små inkrementelle endringene i takt med hvordan man utvikler forretningen sin, svarer han.

Det er også et poeng å levere det brukerne ønsker og har behov for, i stedet for å kun forholde seg til en kravspesifikasjon som kanskje kan være over et år gammel på det tidspunktet en gitt funksjon implementeres.

- Når du kontinuerlig måler effekten hva du gjør, så kan du på et tidlig tidspunkt vite om dette er noe brukerne er interessert i det hele tatt. Om det bare er én prosent av brukerne som synes at dette er bra, så kan du droppe det. Da kan du heller fokusere på ting som det viser seg at 95 prosent av brukerne er interessert i. Det er mye enklere å styre aktiviteten dit det gir mest verdi, sier Morisbak.

Passer for alle

Devops gjør det altså mye enklere å realisere forretningskravene i en flyktig og omskiftelig verden. I et videre perspektiv er heller ikke devops lenger begrenset til utvikling og drift. Alle fagspesialister som påvirker produktet må være sammen om oppgaven.

Alle som påvirker produktet på en eller annen måte, de må jobbe sammen.

- Vi snakker jo også om dev, ops, biz og sec, altså at alle disipliner, at forretning, driftere, utviklere og sikkerhetsfolk jobber sammen, det er en del av devops-filosofien. Alle som påvirker produktet på en eller annen måte, de må jobbe sammen. Opprinnelig var det drift og utvikling man fokuserte på, fordi der var det såpass stor avstand. Men det handler vel så mye om sikkerhet, brukeropplevelse og ikke minst forretning. Det er litt etter modellen av oppstartsselskap, der alle er nødt til å gjøre ting sammen, og alle er nødt til å gjøre litt forskjellige ting også, sier Morisbak.

Han er klar på at devops ikke er noe for spesielt interesserte. Han mener at dette er den riktige måten å utvikle og levere programvareprodukter til sine brukere på, så han nøler ikke når Computerworld spør om det finnes noen virksomheter eller produkter der devops ikke passer:

- Nei. Ikke en gang månelandinger. At all kompetansen er samlet ett sted i ett team, det er aldri negativt, slår Morisbak fast.