1. BusinessOperations ManagementHvordan danne DevOps-team i organisasjonen din

Av Emily Freeman

DevOps har ingen ideell organisasjonsstruktur. Som alt innen teknologi, avhenger det "riktige" svaret til bedriftens struktur av din unike situasjon: ditt nåværende team, planene dine for vekst, teamets størrelse, teamets tilgjengelige ferdighetssett, ditt produkt og videre og videre.

Å justere visjonen til DevOps-teamet bør være ditt første oppdrag. Først etter at du har fjernet den lavthengende frukten av åpenbar friksjon mellom mennesker, bør du begynne å omorganisere team. Selv da, tillate litt fleksibilitet.

Hvis du nærmer deg en omorganisering med åpenhet og fleksibilitet, sender du meldingen om at du er villig til å lytte og gi teamet ditt autonomi - et grunnleggende grunnlag av DevOps.

Du har kanskje allerede en Python- eller Go-utvikler som er lidenskapelig og nysgjerrig på administrasjon av infrastruktur og konfigurasjon. Kanskje den personen kan bytte til en mer ops-fokusert rolle i din nye organisasjon. Legg deg selv i personens sko. Ville du ikke være lojal mot en organisasjon som tok en risiko for deg? Ville du ikke være spent på å jobbe hardt? Og den spenningen er smittsom.

Her lærer du hvordan du justerer lagene du allerede har på plass, dedikerer et team til DevOps-praksis og lager tverrfunksjonelle team - alt fra hvilken måte du kan velge å orientere teamene dine mot DevOps.

Du kan velge en tilnærming og la den utvikle seg derfra. Føler ikke at denne avgjørelsen er permanent og umulig. DevOps fokuserer på rask iterasjon og kontinuerlig forbedring, og det er den viktigste fordelen med denne metodikken. Den filosofien gjelder også lag.

Justere funksjonelle team for DevOps

I denne tilnærmingen skaper du et sterkt samarbeid mellom dine tradisjonelle utviklings- og operasjonsteam. Lagene forblir funksjonelle i sin natur - en fokusert på ops, en fokusert på kode. Men incentivene deres er på linje. De vil vokse til å stole på hverandre og jobbe som to team åket sammen.

For mindre ingeniørorganisasjoner er det å velge funksjonelle team et solid valg. Selv som et første skritt, kan denne justeringen forsterke de positive endringene du har gjort så langt. Du starter vanligvis justeringen ved å ta deg tid til å bygge rapport. Forsikre deg om at hver person på begge lag ikke bare intellektuelt forstår det andre teamets rolle og begrensninger, men også innlevelse i smertepunktene.

For denne tilnærmingen er det en god idé å markedsføre en policy om "Du bygger den, du støtter den." Denne policyen betyr at alle - både utvikler og driftsperson - deltar i rotasjonen på samtalen.

Denne deltakelsen gjør det mulig for utviklere å begynne å forstå frustrasjonene over å bli tilkalt midt på natten og slite mens de er tåkelagte og koffeinfrie for å fikse en feil som påvirker kundene. Driftsfolk begynner også å stole på utviklerne sine engasjement for arbeidet sitt. Selv denne lille endringen bygger en ekstra stor grad av tillit.

Et ord med forsiktighet: Hvis utviklere kjemper hardt mot å være på vakt, er det et større problem i organisasjonen din. Tilbakeførsel er ikke uvanlig fordi det å være på vakt er veldig forskjellig fra deres vanlige ansvarsområder. Pushback kommer ofte fra et sted med ubehag og frykt. Du kan bidra til å dempe denne reaksjonen ved å ta opp det faktum at utviklerne dine kanskje ikke vet hva de skal gjøre de første gangene de er på telefon.

De er kanskje ikke kjent med infrastrukturen, og det er greit. Oppfordre dem til å eskalere hendelsen og side noen med mer erfaring. Til slutt lager du en runbook med vanlige varsler og hvilke tiltak du må ta. Tilveiebringelse av denne ressursen vil hjelpe til med å knytte litt frykt til de begynner å få tak i tingene.

En annen taktikk som hjelper til å stimulere til samarbeid for å danne et mer sammenhengende DevOps-team, er å introdusere en dag med skygge, med hvert team som “handler” en kollega. Den handlede personen skygger ganske enkelt noen andre på teamet, sitter ved skrivebordet sitt (eller i deres område) og hjelper til med sitt daglige ansvar. De kan hjelpe med arbeid, diskutere problemer som et team (parprogrammering) og lære mer om systemet fra et annet synspunkt. Denne undervisningsstilen er ikke reseptbelagt.

I stedet egner det seg til nysgjerrighet og å bygge tillit. Kolleger bør gjerne stille spørsmål - også den "dumme" sorten - og lære fritt. Ingen resultatforventninger finnes. Tiden bør brukes bare ved å bli kjent med hverandre og sette pris på hverandres arbeid. Enhver produktiv produksjon er en bonus!

I denne justeringsmetoden må begge team absolutt være involvert i planleggings-, arkitektur- og utviklingsprosessene. De må dele ansvar og ansvarlighet gjennom hele utviklingslivssyklusen.

Vie et DevOps-team

Et dedikert DevOps-team er mer en utvikling av Sys Admin enn et ekte DevOps-team. Det er et operasjonsteam med en blanding av ferdighetssett. Kanskje er noen ingeniører kjent med konfigurasjonshåndtering, andre IaC (infrastruktur som kode) og kanskje andre er eksperter på containere eller cloud native infrastruktur eller CI / CD (kontinuerlig integrasjon og kontinuerlig levering / utvikling).

Hvis du tror at å sette en gruppe mennesker i et offisielt team er nok til å bryte ned siloer, tar du feil. Mennesker er mer sammensatte enn regneark. Hierarki betyr ikke noe hvis siloene dine har gått inn i en fase der de er usunne og stammelige. I giftige kulturer kan det oppstå en sterk lederstil som nesten alltid følges av folk som tar sider. Hvis du ser dette på ditt eget team, har du arbeid å gjøre.

Selv om enhver tilnærming kan fungere for teamet ditt, er denne dedikerte teamtilnærmingen den du bør tenke gjennom mest. Den største ulempen med et dedikert DevOps-team er at det lett blir en fortsettelse av tradisjonelle ingeniørteam uten å erkjenne behovet for å samkjøre team, redusere siloer og fjerne friksjon. Risikoen for fortsatt friksjon (eller å skape mer) er høy i denne tilnærmingen. Gå nøye gjennom for å sikre at du velger denne teamorganisasjonen av en bestemt grunn.

Fordelene med denne DevOps-tilnærmingen er å ha et dedikert team for å håndtere større infrastrukturendringer eller tilpasninger. Hvis du sliter med driftssentrerte problemer som bremser distribusjonene dine eller forårsaker bekymringer for nettstedets pålitelighet, kan dette være en god tilnærming - også midlertidig.

Et dedikert team hvis du planlegger å flytte en gammel applikasjon til skyen. Men heller enn å kalle dette teamet for et DevOps-team, kan du prøve å merke det som et automatiseringsteam.

Denne dedikerte gruppen av ingeniører kan fokusere fullstendig på å sikre at du har satt opp riktig infrastruktur og automatiseringsverktøy. Du kan deretter fortsette med tillit til at søknaden din vil lande i skyen uten større forstyrrelser. Fortsatt er denne tilnærmingen midlertidig. Hvis du holder teamet isolert for lenge, risikerer du å gå ned en glatt skråning fra rask vekst til innebygd silo.

Opprette tverrfunksjonelle produktteam for DevOps

Et tverrfunksjonelt team er et team som dannes rundt et enkelt produktfokus. I stedet for å ha separate team for utvikling, brukergrensesnitt og brukeropplevelse (UI / UX), kvalitetssikring (QA) og drift, kombinerer du mennesker fra hvert av disse teamene.

Et tverrfunksjonelt team fungerer best i mellomstore til store organisasjoner. Du trenger nok utviklere og driftspersoner til å fylle ut stillingene til hvert produktteam. Hvert tverrfunksjonelt team ser litt annerledes ut.

Det er lurt å ha minst en operasjonsperson per team. Ikke be en operasjonsperson om å dele sitt ansvar mellom to lag. Dette scenariet er urettferdig for dem og vil raskt skape friksjon mellom de to produktgruppene. Gi ingeniørene dine privilegiet å kunne fokusere og grave dypt inn i arbeidet deres.

Hvis organisasjonen din fortsatt er liten eller i oppstartfasen, kan du tenke på hele ingeniørorganisasjonen din som et tverrfunksjonelt team. Hold den liten og fokusert. Når du begynner å henvende deg til å ha 10–12 personer, kan du begynne å tenke på hvordan du kan omorganisere ingeniører.

Bildet nedenfor viser hvordan de tverrfunksjonelle teamene dine kan se ut. Men husk at deres sammensetning varierer fra team til team og fra organisasjon til organisasjon. Noen produkter har et sterkt designfokus, noe som betyr at du kan ha flere designere i hvert team. Andre produkter er tekniske produkter designet for ingeniører som ikke bryr seg mye for estetikk. Lag for den typen produkter kan ha en designer - eller ingen i det hele tatt.

DevOps produktteam

Hvis organisasjonen din er stor nok, kan du absolutt opprette flere team ved å bruke forskjellige DevOps-ideer og tilnærminger. Husk at organisasjonen din er unik. Føl deg bemyndiget til å ta avgjørelser basert på nåværende forhold og tilpasse deg derfra. Her er noen mulige kombinasjoner av forskjellige typer produktgrupper.

  • Legacy Product Team: Prosjektleder (PM), Front-end Developer, Back-end Developer, Back-end Developer, Site Reliability Engineer (SRE), Automation Engineer, QA Tester Cloud Transformation Team: SRE, SRE, Operations Engineer, Automation Engineer, Back-end Developer MVP Team: PM, Designer, UX Engineer, Front-end Developer, Backend Developer, Operations Engineer

Ulempen med et tverrfunksjonelt produktteam er at ingeniører mister kameraderiet til ingeniører med samme ferdigheter og lidenskaper. Å ha en gruppe likesinnede som du kan sosialisere deg med, og som du kan lære deg, er et viktig aspekt av arbeidsglede. Sjekk ut en løsning på dette problemet nedenfor.

Som vist nedenfor, kan du gi ingeniørene dine dedikert arbeidstid å tilbringe med stammene sine. Du kan gjøre noe så raus som å betale for lunsj en gang hver uke, slik at de kan komme sammen og snakke. Eller du kan gi 10–20 prosent av arbeidstiden til at de kan jobbe med prosjekter som stamme. Uansett, trenger du ingeniørene dine for å holde seg skarpe.

Stammene deler bransjekunnskap, gir god tilbakemelding og støtter vekst i karrieren. Gi tid for ingeniørene dine å lære av mennesker de deler utdanning, erfaring og mål med. Denne gangen gir et trygt sted hvor de kan slappe av og føle seg hjemme.

DevOps stammer

Ingen mengder perfekt finagling vil overvinne manglene ved en dårlig organisasjonskultur. Men hvis du har lagt merke til så langt og gjort passende skritt, er neste trinn å danne team som forsterker de kulturelle idealene du allerede har satt på plass.