1. BusinessOperations ManagementHvordan dannes DevOps-teams i din organisation

Af Emily Freeman

DevOps har ingen ideel organisationsstruktur. Ligesom alt inden for tech, afhænger det "rigtige" svar vedrørende din virksomheds struktur af din unikke situation: dit nuværende team, dine planer for vækst, dit teams størrelse, dit teams tilgængelige færdigheder, dit produkt og til og med.

Tilpasning af dit DevOps-teams vision skal være din første mission. Først efter at du har fjernet den lavthængende frugt af åbenlyst friktion mellem mennesker, skal du begynde at omarrangere hold. Tillad dig endda en vis fleksibilitet.

Hvis du nærmer dig en omorganisering med åbenhed og fleksibilitet, sender du beskeden, at du er villig til at lytte og give dit team autonomi - et grundlæggende princip for DevOps.

Du har muligvis allerede en Python- eller Go-udvikler, der er lidenskabelig og nysgerrig omkring infrastruktur og konfigurationsstyring. Måske kan denne person skifte til en mere ops-fokuseret rolle i din nye organisation. Sæt dig selv i den persons sko. Ville du ikke være loyal over for en organisation, der tog en risiko for dig? Ville du ikke være begejstret for at arbejde hårdt? Og den spænding er smitsom.

Her lærer du, hvordan du justerer de hold, du allerede har, på plads, dedikerer et team til DevOps-praksis og skaber tværfunktionelle teams - alle tilgange, hvorfra du kan vælge at orientere dine hold mod DevOps.

Du kan vælge en tilgang og lade den udvikle sig derfra. Må ikke føle, at denne beslutning er permanent og ubevægelig. DevOps fokuserer på hurtig iteration og kontinuerlig forbedring, og det er den største fordel ved denne metode. Denne filosofi gælder også for hold.

Tilpasning af funktionelle teams til DevOps

I denne tilgang skaber du et stærkt samarbejde mellem dine traditionelle udviklings- og operationsteams. Holdene forbliver funktionelle i naturen - et fokuseret på ops, et fokuseret på kode. Men deres incitamenter er på linje. De vil vokse til at stole på hinanden og arbejde, som to teams skrædder sammen.

For mindre ingeniørorganisationer er tilpasning af funktionelle teams et solidt valg. Selv som et første skridt kan denne justering styrke de positive ændringer, du har foretaget indtil videre. Du starter typisk justeringen ved at tage dig tid til at opbygge rapport. Sørg for, at hver person på begge hold ikke kun intellektuelt forstår det andet holds rolle og begrænsninger, men også empati med smertepunkterne.

Til denne tilgang er det en god ide at promovere en politik om "Du bygger den, du støtter den." Denne politik betyder, at alle - både udvikler og driftsperson - deltager i din rotation på telefon.

Denne deltagelse giver udviklere mulighed for at begynde at forstå frustrationerne ved at blive kaldt midt på natten og kæmpe, mens de er tågeede og koffeinberøvet til at løse en fejl, der påvirker kunderne. Operationsfolk begynder også at stole på dine udviklere 'engagement i deres arbejde. Selv denne lille ændring bygger en ekstraordinær mængde tillid.

Et forsigtighedsord: Hvis udviklere kæmper hårdt mod at være på vagt, er der et større problem i din organisation. Pushback er ikke ualmindeligt, fordi at være på vagt er meget forskelligt fra deres normale daglige ansvar. Pushback kommer ofte fra et sted med ubehag og frygt. Du kan hjælpe med at afbøde denne reaktion ved at tage fat på det faktum, at dine udviklere muligvis ikke ved, hvad de skal gøre de første par gange, de er på telefon.

De er muligvis ikke bekendt med infrastrukturen, og det er okay. Opmuntr dem til at eskalere hændelsen og søge nogen med mere erfaring. Til sidst oprette en runbook med almindelige alarmer og hvilke handlinger der skal tages. Tilvejebringelse af denne ressource vil hjælpe med at dæmpe nogle frygt, indtil de begynder at få fat på tingene.

En anden taktik til at hjælpe med at anspore til samarbejde om at danne et mere sammenhængende DevOps-team er at introducere en dag med skygge, hvor hvert team ”handler” med en kollega. Den handlede person skygger blot en anden på holdet, sidder ved deres skrivebord (eller i deres område) og hjælper med deres daglige ansvar. De kan hjælpe med arbejde, diskutere problemer som et team (parprogrammering) og lære mere om systemet fra et andet synspunkt. Denne undervisningstilstand er ikke ordinerende.

I stedet egner det sig til nysgerrighed og opbygning af tillid. Kolleger bør være velkomne til at stille spørgsmål - også den "dumme" sort - og lære frit. Der er ingen forventninger til præstationer. Tiden skal bruges ved blot at lære hinanden at kende og værdsætte hinandens arbejde. Enhver produktiv produktion er en bonus!

I denne tilpasningstilgang skal begge teams absolut være involveret i planlægning, arkitektur og udviklingsprocesser. De skal dele ansvar og ansvarlighed gennem hele udviklingslivscyklussen.

Dedikere et DevOps-team

Et dedikeret DevOps-team er mere en udvikling af Sys Admin end et ægte DevOps-team. Det er et operationsteam med en blanding af færdighedsæt. Måske er nogle ingeniører kendte med konfigurationsstyring, andre IaC (infrastruktur som kode) og måske andre er eksperter i containere eller cloud native infrastruktur eller CI / CD (kontinuerlig integration og kontinuerlig levering / udvikling).

Hvis du synes, at det er nok at sætte en gruppe mennesker i et officielt hold til at nedbryde siloer, tager du fejl. Mennesker er mere komplekse end regneark. Hierarki betyder ikke noget, hvis dine siloer er gået ind i en fase, hvor de er usunde og stammelige. I giftige kulturer kan en stærk lederstil dukke op, som næsten altid følges af folk, der tager sider. Hvis du ser dette på dit eget team, har du arbejde at gøre.

Selvom enhver tilgang kan fungere for dit team, er denne dedikerede teamtilgang den, du skal tænke mest igennem. Den største ulempe ved et dedikeret DevOps-team er, at det let bliver en fortsættelse af traditionelle ingeniørteam uden at erkende behovet for at justere hold, reducere siloer og fjerne friktion. Risikoen for fortsat friktion (eller skabe mere) er høj i denne tilgang. Træd omhyggeligt for at sikre, at du vælger denne teamorganisation af en bestemt grund.

Fordelene ved denne DevOps-tilgang er at have et dedikeret team til at tackle store infrastrukturændringer eller justeringer. Hvis du kæmper med driftsorienterede problemer, der bremser dine implementeringer eller forårsager bekymringer for webstedspålidelighed, kan dette være en god tilgang - selv midlertidigt.

Et dedikeret team, hvis du planlægger at flytte en ældre applikation til skyen. Men snarere end at kalde dette team et DevOps-team, kan du prøve at mærke det som et automatiseringsteam.

Denne dedikerede gruppe af ingeniører kan fokusere fuldstændigt på at sikre, at du har konfigureret de korrekte infrastruktur- og automatiseringsværktøjer. Du kan derefter fortsætte med tillid til, at din ansøgning lander i skyen uden større forstyrrelser. Denne tilgang er stadig midlertidig. Hvis du holder teamet isoleret for længe, ​​risikerer du at gå ned ad en glat hældning fra hurtig vækst til indlejret silo.

Oprettelse af tværfunktionelle produktteam til DevOps

Et tværfunktionelt team er et team dannet omkring et enkelt produktfokus. I stedet for at have separate teams til udvikling, brugergrænseflade og brugeroplevelse (UI / UX), kvalitetssikring (QA) og operationer, kombinerer du mennesker fra hvert af disse teams.

Et tværfunktionelt team fungerer bedst i mellemstore til store organisationer. Du har brug for nok udviklere og driftsfolk til at udfylde positionerne for hvert produkthold. Hvert tværfunktionelt team ser lidt anderledes ud.

Det er en god ide at have mindst en driftsperson pr. Team. Bed ikke en driftsperson om at opdele sit ansvar mellem to hold. Dette scenarie er urimeligt over for dem og skaber hurtigt friktion mellem de to produktteams. Giv dine ingeniører privilegiet at være i stand til at fokusere og grave dybt ned i deres arbejde.

Hvis din organisation stadig er lille eller i opstartfasen, kan du tænke på hele din ingeniørorganisation som et tværfunktionelt team. Hold det lille og fokuseret. Når du begynder at henvende dig til at have 10-12 personer, skal du begynde at tænke på, hvordan du kan omorganisere ingeniører.

Billedet herunder viser, hvordan dine tværfunktionelle teams kunne se ud. Men husk, at deres sammensætning varierer fra team til team og fra organisation til organisation. Nogle produkter har et stærkt designfokus, hvilket betyder, at du muligvis har flere designere i hvert team. Andre produkter er tekniske produkter designet til ingeniører, der ikke er meget interesseret i æstetik. Hold til den slags produkt har muligvis en designer - eller slet ingen.

DevOps produktteam

Hvis din organisation er stor nok, kan du helt sikkert oprette flere teams ved hjælp af forskellige DevOps-ideer og tilgange. Husk, at din organisation er unik. Føl dig bemyndiget til at tage beslutninger baseret på dine nuværende omstændigheder og justere derfra. Her er nogle mulige kombinationer af forskellige typer produkthold.

  • Legacy Product Team: Project Manager (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 tværfunktionelt produktteam er, at ingeniører mister kameraderiet for ingeniører med deres samme kvalifikationssæt og lidenskaber. Det er et vigtigt aspekt af jobtilfredshed at have en gruppe ligesindede personer, som du kan socialisere dig med, og som du kan lære af. Tjek en løsning på dette problem nedenfor.

Som vist nedenfor kan du give dine ingeniører dedikeret arbejdstid til at tilbringe med deres stammer. Du kan gøre noget så generøst som at betale for frokost en gang hver uge, så de kan mødes og tale. Eller du giver måske 10-20 procent af arbejdstiden til dem at arbejde på projekter som en stamme. Uanset hvad, har du brug for dine ingeniører for at forblive skarpe.

Stammer deler branchekendskab, giver god feedback og understøtter vækst i karrieren. Giv tid til dine ingeniører at lære af mennesker, som de deler uddannelse, erfaring og mål med. Denne tid giver et sikkert sted, hvor de kan slappe af og føle sig hjemme.

DevOps stammer

Intet beløb af perfekt finagling vil overvinde underskuddene ved en dårlig organisationskultur. Men hvis du hidtil har været opmærksom og gjort de rette skridt, er det næste skridt at danne teams, der styrker de kulturelle idealer, du allerede har sat på plads.