Brukt på feil måte blir det kun et nytt buzzord som du slenger rundt deg uten å egentlig forstå det. De beste folkene skyr slike virksomheter som pesten. Du får for lang time-to-market, og klarer ikke levere produktene som gir bedriften din de konkurransefortrinnene den trenger.
Alt dette viser at det er viktig å kjenne dette begrepet godt. Vi har derfor samlet en rekke tips til hvordan du kan kjenne igjen at du ikke gjør DevOps riktig.
1. Du lyser ut stillingen som DevOpser
Et raskt søk på finn.no viser 203 stillingsutlysninger med DevOps enten i stillingstittelen eller i teksten. Noen av disse bruker ord som DevOps-konsulent, Lead DevOps og DevOps-utvikler. Noen sier det er fint om du har jobbet med Scrum og/eller DevOps fra før.
Buzzordene er selvfølgelig mange, som det ofte er i stillingsutlysninger, men det forandrer ikke det faktum at én person alene ikke utgjør DevOpsen i et team. Det er mange forskjellige beskrivelser av hva ordet betyr, men et gjennomgående tema er at det ikke handler om enkeltpersoner, men om hvordan teamet er bygget opp og hvordan det samarbeider.
Utviklere skal fortsatt være best på programmering og drifterne skal fortsatt være best på infrastruktur, men det er ofte slik at kunnskapen overlapper. La oss spille hverandre gode, og være klare på: Du lyser ikke ut DevOpsere, du bygger DevOps kompetanse i teamet ditt!
2. Master-branchen er ikke klar for produksjon
DevOps handler om å kunne få ut endringer raskt og smertefritt. Hvis du for eksempel har 4 hovedreleaser i et år, og det kun er i forbindelse med disse at ny funksjonalitet blir gjort tilgjengelig for publikum, blir det umulig å respondere raskt på trender og tilbakemeldinger fra sluttbrukere.
Endringer skal ut i produksjon så snart de er ferdig utviklet og testet. Oppgaven er altså ikke ferdig før funksjonaliteten er tilgjengelig for brukerne. For å få til dette er kontinuerlig integrasjon (CI) og kontinuerlige leveranser (CD) essensielle byggesteiner i grunnmuren til organisasjonen. Dette forutsetter at man har verktøy som en CI-server (feks. Jenkins) og en plattform som egner seg for automatisert deploy. Her kommer man fort inn på forskjellige nettskyløsninger, både interne og eksterne, Docker-containere og Serverless.
Selvfølgelig skal man teste funksjonaliteten som legges ut, en god teststrategi er fortsatt viktig, men testingen gjøres i forbindelse med hver brukerhistorie. Man må gjerne også ta i bruk Canary Releases. Hvis det mot formodning introduseres en bug, fokusér på å få ut en fiks i en ny versjon, ikke automatisk rull tilbake, med mindre feilen er veldig alvorlig og vil ta lang tid å løse. Et av de viktiste punktene ved å få ut endringer fortløpende, er at endringene da blir små, så det blir lett å finne ut av en eventuell feilårsak.
Ved at koden som ligger på master-branchen alltid er deployerbar, unngår man også at man har flere releaser å fikse feil i samtidig: den som skal deployes om tre måneder, den som er i testfasen og skal deployes om 2 uker, og den som kjører i produksjon for øyeblikket.
3. Flaskehalsene fjernes ikke
I iveren etter å ramse opp buzzord som smidig og DevOps, er det fort gjort å brenne seg ved å ikke forstå hvilke flaskehalser som finnes i prosjektene dine.
Produkteieren må styre backlogen av oppgaver på en riktig måte. Det er viktig å prioritere de oppgavene som gir størst verdi og samtidig er raskest å implementere. Det er også viktig å si nei til de oppgavene som ikke gir verdi. Ved å legge grunnlaget med en god MVP tidlig i prosjektet, har du en solid base å bygge resten av prosjektet på, slik at det til slutt kun er nice to haves, som man så kanskje kan kutte helt ut. En bra introduksjon til hvordan man styrer backloggen kan ses i denne videoen:
Neste flaskehals er en velkjent en: teamet må ikke sjonglere for mange oppgaver samtidig. Det må være en grense på Work In Progress (WIP), samtidige oppgaver som teamet tar ut fra backlog. For mange samtidige oppgaver fører til mye kontekstsvitsjing, unødvendig kommunikasjon og gjør rett og slett at man leverer oppgavene tregere enn om man gjennomfører oppgavene én og én.
Hvis det er flere team, er det også viktig å begrense avhengighetene mellom teamene, så teamene er mest mulig autonome, og kan bestemme utviklingstakten selv.
Når oppgaver er ferdig utviklet, er det viktig at det ikke er unødvendige flaskehalser som hindrer fra å få dem ut i produksjon. Automatisering, kontinuerlig integrasjon og kontinuerlig leveranser er her igjen livsviktige. Man må unngå at prodsettinger forsinkes fordi de bare kan utføres av én bestemt person fordi han tilfeldigvis er ansatt som drifter. Helst burde master-branchen ha god nok kvalitet til å automatisk rulles ut i produksjon. Hvis man ikke tør dette, men vil jobbe for å komme seg dit kan man starte med å definere lavrisiko-applikasjoner hvor dette skjer. Etterhvert kan man da skape tillit og definere flere applikasjoner som lavrisiko.
At teamet hele tiden jobber med å se på hva som kan gjøres bedre, er en viktig bestanddel i DevOps. Hvis det finnes gode fora, som for eksempel en retrospektiv, hvor man ser på hvilke forbedringer man kan gjøre, er man på god vei til å minimere flaskehalsene og bli et mer effektivt team.
4. Utviklerne ansvarliggjøres ikke
“You build it, you run it!” er et mantra fra DevOps-verdenen som aldri dør, og det er en god grunn til det. Utviklerne av applikasjonen er de som kjenner den best, inn og ut, og er også de som blir tilkalt hvis det skjer noe feil. Derfor er det uhyre viktig at disse utviklerne får et mandat som lar dem ta vare på applikasjonene sine.
Ofte er det sånn at utviklerne ikke kan deploye til produksjon, de kan ikke se logger, de får ikke tilgang til databasen, og de får ikke bestemme over produksjonsoppfølgingsverktøy, de har kanskje ikke heller tilgang til produksjonsoppfølgingsverktøyene, og da er det også vanskelig å få et ordentlig eierskap til applikasjonene.
Det er ganske sikkert at dette punktet gjelder deg hvis det er driftere eller produksjonsoppfølgingsteam som har ansvaret for å oppdage feil og utfordringer i applikasjonene, mens utvikleren bare er den som blir ringt etter og klandret når det faktisk har oppstått.
Dette punktet tar oss over i neste:
5. Brukerne oppdager feil før teamet
La oss si at for 5% av brukerne deres oppstår det en teknisk feil når de prøver å gå inn på en spesiell side, søker etter noe, eller lignende. Har dere rutinen og verktøyene til å oppdage det før en av kundene tilfeldigvis sier ifra?
Mer enn én gang har jeg vært vitne til at brukere ringer inn om en feil hverken utviklere eller drift har sett noe til, og vi leter nytteløst etter bevis på at det er kundens feil, før vi skjønner at det er en feil i vår løsning, og den oppstår for mange tusen andre.
Som utviklere og driftere har man alle forutsetninger for å lage mekanismer for å oppdage slike problemer. Logging, metrikker og tracing er ofte kalt grunnpilarene i observerbarhet og monitorering. I verktøy som Splunk for logging, Grafana for visualisering av metrikker og Lightstep for tracing, kan man sette opp varsler for enkle feilsituasjoner som at det er mange svar av en viss HTTP-kode, eller at svartidene går over et visst nivå.
Hver gang det kommer inn en feil fra en kunde som ikke ble oppdaget i overvåkningssystemet må man spørre seg hvordan man kunne oppdaget dette automatisk.
6. Den skyldige utpekes
Når det oppstår alvorlige feil, spør teamet seg: «Hvem er skyldig?» eller prøver dere heller å jobbe sammen med å finne ut hvordan dere kan forbedre systemet slik at det ikke blir mulig å gjøre samme feil igjen?
Begrepet «Blameless Culture» har de siste årene dukket opp, godt hjulpet av John Allspaw’s post om Blameless Post-Mortems i 2012. Ved å fokusere på systemet og hvordan feilen kunne oppstå, og ikke personen som trykket på feil knapp, skaper man en selvforsterkende atmosfære i teamet. Medlemmene føler seg trygge nok til å være ærlige i feilsøkingen, som gjør det lettere å unngå liknende feil ved et senere tidspunkt.
Foraer som daglig standup, retrospektiv, for ikke å snakke om mekanismer som åpent landskap kontra cellekontor, kan være med på å øke åpenheten og samholdet i teamet.
I miljøer med sterke skiller mellom forskjellige team, eller forskjellige fag, som «dev» og «ops», vil det fort være skyldpeking mellom konstellasjonene. Derfor er slik skyldpeking et klart tegn på at man ikke har klart å implementere DevOps-tankegangen riktig i organisasjonen.
Flere tegn?
Dette er et utvalg av tegn på at organisasjonen ikke jobber etter DevOps-prinsipper. Gjør gjerne en helsesjekk av din organisasjon, og se hvordan dere kommer ut.