Bygg et førsteklasses DevOps-team: Samarbeid, kultur og viktige metoder

DevOps har vokst frem som en viktig filosofi som bygger bro mellom programvareutvikling og IT-drift. Det handler om mer enn bare å bruke DevOps-verktøy. Et vellykket DevOps-team fremskynder ikke bare leveringsprosessen, men sikrer også kvalitet og pålitelighet. Å skape et slikt team krever imidlertid en harmonisk sammensmelting av verktøy, kultur, prosesser, samarbeid og mer. Hva er de avgjørende komponentene i et førsteklasses DevOps-team, og hvordan kan organisasjoner integrere dem for å oppnå best mulige resultater? Som en del av denne serien hadde vi gleden av å intervjue Dylan Etkin, medgründer og administrerende direktør i Sleuth.

Hei, Dylan – Kan du fortelle litt om bakgrunnen din? 

Jeg startet karrieren min som programvareingeniør. Jeg var så heldig å begynne i den lille oppstartsbedriften Atlassian som deres 20. ansatte. Jeg tilbrakte 10 år i Atlassian, lærte utrolig mye og så organisasjonen vokse fra 20 til 1200 ansatte. Jeg jobbet som en av de tre første ingeniørene på Jira, den første Jira-arkitekten og som teknisk leder for Bitbucket, hvor jeg bidro til å øke produktet fra 40 000 til 2 millioner brukere. 

Jeg forlot Atlassian og begynte i en liten oppstartsbedrift, Statuspage. Ett år senere ble Statuspage kjøpt opp av Atlassian, og jeg oppdaget at jeg var tilbake i moderskipet igjen. Etter å ha ledet dette teamet i Atlassian i tre år bestemte jeg meg for å starte på egen hånd og grunnla Sleuth for å kommersialisere det som alltid har vært lidenskapen min: å bygge effektive utviklingsteam.

Jeg har alltid vært fascinert av utviklerverktøy og av å hjelpe team med å arbeide effektivt og lære kontinuerlig.

Hvem takker du for å ha hjulpet deg med å oppnå suksess?

Mange mennesker har hjulpet meg på veien. Jo eldre jeg har blitt, desto mer har jeg innsett hvilket spesielt nettverk jeg har bygget opp, og hvor åpne alle er for å hjelpe når man spør.

Et eksempel som skiller seg ut, er John Kodumal, medgrunnlegger og teknologidirektør i LaunchDarkly. John og jeg var kolleger i Atlassian. Da han forlot selskapet for å grunnlegge LaunchDarkly, var han alltid åpen om erfaringene sine fra oppstartsbedriften.

Da jeg begynte å motivere meg selv til å starte Sleuth, støttet han meg på alle nivåer. Fra idéutveksling og åpne samtaler om hvordan jeg burde gå frem, til å bli vår første kunde – John har hjulpet meg gjennom hvert eneste steg på reisen. 

Kan du dele tre styrker, ferdigheter eller egenskaper som har hjulpet deg med å nå dette punktet i karrieren? Hvordan kan andre aktivt utvikle disse områdene hos seg selv? 

1. Utholdenhet. Ferdigheter og intelligens bringer deg bare et stykke på vei. Det er langt kraftigere å vende tilbake til et problem om og om igjen. Utholdenhet, selv når man møter flere nederlag, har vært avgjørende for min suksess.
2. Sans for detaljer. Dette er en egenskap som alltid har falt naturlig for meg. Som ingeniør er det en viktig ferdighet som gjør at du kan utføre oppgavene foran deg på en fremragende måte. I et oppstartsmiljø er denne ferdigheten enda viktigere. Når du skal føre et produkt fra visjon til virkelighet, er det sansen for detaljer som utgjør forskjellen mellom et middelmådig produkt og noe brukerne elsker.
3. Delegering. Selv om du må ta fullt eierskap til virksomheten din, blir en oppstartsbedrift svært raskt en øvelse i å ansette mennesker som er smartere enn deg på mange områder, og i å akseptere at du gir fra deg byggeklossene dine slik at andre kan lykkes og føre virksomheten fremover. 

Hvilke ferdigheter prøver du fortsatt å utvikle?

Jeg arbeider alltid med mange ting, så det mangler aldri ferdigheter å utvikle. Det jeg først og fremst fokuserer på akkurat nå, er kunsten å få frem det beste i menneskene dine. Alle er forskjellige, og det er en utfordring å vite hvordan man skaper et miljø der hver enkelt kan gjøre sitt beste arbeid.

La oss snakke om å ha et vellykket DevOps-team. Hvilke hovedmål kan et DevOps-team identifisere for en digital transformasjonsreise?

DevOps-team får myndighet til å ta arbeid effektivt fra idé til vellykket lansering i produksjon. Derfor er det viktigste målet for et DevOps-team å bygge verktøyene, prosessene og kulturen som gjør det mulig for individuelle utviklere å ta arbeid raskt fra idé til vellykket lansering. 

Mål som støtter oppnåelsen av det viktigste målet, er:

• Muligheten til å definere arbeid i små porsjoner
• En helautomatisert CI/CD-pipeline
• Observasjon og miljøer før produksjon  som fungerer som sikkerhetsnett, slik at utviklere trygt kan sende endringer til produksjon
• En tydelig prosess for hva man skal gjøre når endringer går galt. Alle vet hvordan feil skal oppdages og systemet bringes tilbake til en fungerende tilstand
• Støtte fra resten av organisasjonen, PM-er, markedsføring, kundestøtte, salg og ledelsen. Team vil ikke kunne gjennomføre en DevOps-transformasjon uten støtte fra hele organisasjonen

Finnes det noen utfordringer eller vanlige fallgruver som DevOps-team bør ta hensyn til?

Det finnes for mange til å nevne alle. Én som skiller seg ut, er å forstå at DevOps-praksis innebærer at du legger mer ansvar på utvikleren. Dette kommer ikke gratis, og hvis du ikke investerer i prosesser og verktøy, risikerer du å bygge et system som ikke gir utviklerne tid til faktisk å få arbeidet gjort.

Du risikerer også å bygge et miljø der utviklere raskt blir utbrent. Du må huske at mennesker bare har en viss kapasitet, så du må være bevisst på hva du legger til rette for å støtte utviklere som praktiserer DevOps.

Hvordan kan effektivt samarbeid og god kommunikasjon mellom teammedlemmer forbedre produktiviteten og suksessen til et DevOps-team, og hvilke praksiser kan legge til rette for dette?

Kommunikasjon og samarbeid er nødvendig for å praktisere DevOps. Noen viktige praksiser inkluderer:

• Bruk av et system for oppfølging av saker for alt arbeid, og inkludering av denne konteksten og informasjonen i commits og kodegjennomganger
• Kodegjennomgang med pull requests
• Å tilby en løsning for sanntidschat, som Slack, til teamet
• Teambaserte varsler om distribusjoner i Slack eller teamets ChatOps-verktøy
• Slack-baserte godkjenninger for å flytte endringer fra miljøer før produksjon til produksjon
• Individuelle utviklervarsler når endringene deres settes i produksjon, og når de har brutt betingelser for feil
• Synlighet for teamet rundt hendelser og perioder der distribusjoner bør vente
• Teamdemonstrasjoner med PM-er og andre interessenter
• Daglige statusmøter

Hvilken rolle spiller CI/CD i DevOps, og hva er de beste praksisene for implementering av CI/CD-pipelines for å sikre en sømløs og pålitelig prosess for programvareutgivelser?

CI/CD er uten tvil den viktigste verktøykomponenten som støtter et team som praktiserer DevOps. Ideelt sett bør team ha en helautomatisert distribusjonspipeline som kjører på rimelig kort tid, slik at utviklere ikke må vente lenge og kan følge endringene sine helt ut i produksjon. Det er viktig å inkludere CI og testkjøring som en del av denne ideelle pipelinen. Å kjøre en robust testpakke mot endringene dine som en kontroll før distribusjon er det viktigste sikkerhetsnettet for å sikre at gode endringer settes i produksjon. 

Hvis team bare ønsker å distribuere én gang i uken, er det mulig å ha en distribusjonspipeline som ikke er helautomatisert. Hvis teamet ditt derimot ønsker å distribuere minst én gang om dagen, må dere være helautomatiserte, og distribusjon må være en ikke-hendelse.

Hvordan bidrar det å fremme en DevOps-kultur og -tankegang til den overordnede suksessen til et DevOps-team, og hvilke strategier kan organisasjoner bruke for å fremme denne kulturen blant utviklings- og driftsteamene?

For utviklere:

• Ukentlig eller annenhver uke kan sprintplanlegging bidra til å fastsette størrelsen på oppgavene og etablere en teambasert enighet om hvordan oppgavene skal få plass i dette tidsrommet
• Automatisert CI mot utgivelsesgrenen og synlighet for hele teamet i resultatene, slik at teamet kan holde utgivelsen byggbar
• Å opprettholde en avbrytende rolle på et team, der det er tydelig hvem som har ansvar for å holde utgivelsesgrenen byggbar
• En av de beste mekanismene for å kunne sette uferdig arbeid i produksjon er å ta i bruk en form for funksjonsflagg.
• Det kan også være svært effektivt å distribuere hver pull request én om gangen. Når dere tar i bruk dette mønsteret, kan dere inkludere en vurdering av endringens størrelsesgruppe sammen med kodegjennomgangen av pull requesten. Hvis en gruppe er for stor, kan andre teammedlemmer be en utvikler om å dele endringen opp i flere pull requests.
• Ha nok måledata og en forståelse av normalverdiene deres til å kunne verifisere en distribusjon
• Forstå hvordan dere eskalerer og ruller tilbake ved behov
• Ha myndighet til å distribuere egne endringer til alle miljøene dere vedlikeholder, og kunne gjøre det raskt og uten feil

For PM-er og designere:

• Inkluder en PM i planleggingsprosessen, slik at vedkommende får mulighet til å uttrykke kundens behov i trinnvise distribusjoner.
• Implementer funksjonsflagg, slik at kode kan rulles ut uten å bli eksponert for kundene ennå. Dette hjelper PM-er med å beholde fleksibiliteten de trenger, samtidig som utviklerne kan gå videre.
• Ha en omforent mekanisme for tilbakemeldinger og omarbeiding, for eksempel en sak som tildeles direkte til en utvikler. En strategi for å løse problemet med uferdig arbeid er at teamet tar i bruk seksukerssykluser.

For tekniske ledere:

• Implementer prosesser som legger til rette for kommunikasjon, for eksempel gjentakende planleggingsmøter, kodegjennomganger og ukentlige demonstrasjoner.
• Forplikt dere til å sette av tid fra utviklingsteamet til å sørge for at byggene av utgivelsesgrenen består. Å holde koden i flyt betyr også å investere i dette nye systemet. Når teamet identifiserer en flaskehals, bør lederen kunne la teamet fjerne den (for eksempel ved å rette CI-tester som har en ustabilitetsgrad på over 20 %).
• Implementer verktøy som hjelper dere med å måle DORA-måledata kontinuerlig

For toppledelsen:

• Synliggjør Accelerate-måltallene for prosjektene dine og gjør dem tilgjengelige, med kontekst, for ledelsen.
• Synliggjør oppetiden eller tilsvarende for applikasjonene dine.
• Gi ledergruppen den samme overordnede informasjonen om store deler av funksjonaliteten som blir lansert.
• Hvis du er leder, må du forstå at endring tar tid. Vær tydelig på at teamene skal holdes ansvarlige for overordnede mål, men fleksibel når det gjelder hvordan de oppnår dem. Stol på dem, men verifiser.
• Ta deg tid til å forklare organisasjonen hvordan dere skaper verdi for kundene. Forklar hvordan trinnvis levering fungerer, hva som vil bli lansert samlet, og hvordan denne arbeidsmåten kan gjøre det mulig å levere verdi til kundene raskere.

Hva er de viktigste bestanddelene i et vellykket DevOps-team?

1 . Teamet samarbeider i en kultur uten skyldfordeling. 

Programvareutvikling er en lagidrett. Hendelser og feil er muligheter for teamene til å lære, ikke muligheter til å plassere skyld. En kultur uten skyldfordeling kan strekke seg lenger enn til selve hendelsene. Når teamet setter mål for forbedring, kan det fokusere på å forbedre resultatene i stedet for å klandre enkeltpersoner eller prosesser for at ting ikke er slik de burde være.

2 . Distribusjoner er udramatiske hendelser.

For å kunne levere i små trinn og reagere raskt på hendelser og tilbakemeldinger fra kunder, må distribusjonen være enkel og ikke fremkalle frykt eller uro. Hvis et team ikke stoler på distribusjonene sine, eller hvis de tar for lang tid eller innebærer manuelle trinn, vil dette føre til frykt og nøling, noe som hindrer teamene i å ta i bruk DevOps.

3 . Utviklere får individuelt ansvar og myndighet til å ta endringer fra idé til en pålitelig lansering i produksjon. DevOps fungerer når du legger ansvaret for hele prosessen fra idé til lansering i utviklernes hender. Dette gjør det mulig for teamet å dele opp arbeidet i små leveranser og raskt levere verdi til kunden i små trinn.

4 . Teamet har sikkerhetsnett, som observerbarhet og målinger av feil, slik at de har tillit til å bevege seg raskt (dette er én av mange fordeler med verktøy for dataobserverbarhet). Tiden da man beveget seg raskt og ødela ting, er over. Nå må du bevege deg raskt og samtidig pålitelig. For å gjøre dette må du ha automatiserte sikkerhetsnett på plass.

5 . Hele organisasjonen har sluttet opp om å arbeide i en DevOps-flyt.

Hvilke nye trender ser du for deg i DevOps-landskapet som kan få betydelig innvirkning på strategier for digital transformasjon i fremtiden?

Dette kan virke som et åpenbart svar akkurat nå, men AI-verktøy endrer allerede måten utviklere arbeider på, og vil helt sikkert få stor innvirkning på hvordan DevOps praktiseres fremover. AI vil i det minste bli brukt til å oppdage og identifisere feil på måter som ikke er mulige i dag.

Hvis det innfrir alle løftene sine, vil det fullstendig erstatte de kompliserte distribusjons- og testprosessene vi har i dag.

Abonner på nyhetsbrevet til The CTO Club for flere innsikter, sammendrag, spørsmål og svar og mer!