1. BusinessOperations ManagementTips til forbedring af tekniske ydelser med DevOps

Af Emily Freeman

Forbedring af teknisk ydeevne som en del af DevOps-processen kan have store konsekvenser for hele virksomheden. Effektivisering af udviklingslivscyklussen og fjernelse af flaskehalse vil tjene til at fremskynde virksomhedens samlede præstation - i sidste ende øge bundlinjen. Og hvis du som DevOps-ingeniør mener, at du ikke behøver at være interesseret i forretningspræstationen, har du fejl.

I henhold til DevOps Research and Assessment (DORA) overgår højtydende DevOps-hold konsekvent deres konkurrenter på fire nøgleområder:

  • Distributionsfrekvens: Dette udtryk henviser til, hvor ofte dine ingeniører kan indsætte kode. Forbedring af ydeevnen justeres med anvendelse af flere gange om dagen efter ønske. Ledetid: Ledetid er, hvor lang tid du tager at gå fra at indgive en ny kode til at køre den kode i et produktionsmiljø. Ifølge DORA har de højeste kunstnere en ledetid på under en time, mens gennemsnitlige kunstnere har brug for op til en måned. MTTR (gennemsnitlig tid til gendannelse): MTTR refererer til, hvor lang tid du tager for at gendanne en service efter en hændelse eller strømafbrydelse. Ideelt set ønsker du at sigte mod under en time. Et strømafbrydelse koster alvorlige penge, især når det påvirker profitcentre i applikationen. Lange afbrydelser ødelægger tillid, mindsker moral og indebærer yderligere organisatoriske udfordringer. Ændringsfejl: Dette udtryk henviser til den hastighed, hvormed ændringer til dit system påvirker ydeevnen negativt. Selvom du aldrig vil nå en ændringsfejlrate på nul procent, kan du absolut nærme dig nul ved at øge dine automatiske test og stole på en installationsinstallation med kontinuerlig integrationskontrol og porte - som alle sikrer kvalitet.

Fjernelse af perfektion som et mål for DevOps succes

DevOps er afhængig af mantraet ”Udført er bedre end perfekt.” Det ser ud til at være et af disse citater, der er umulige at attributter, men ordene taler ikke desto mindre sandhed. Forsøg på at opnå perfektion er en fjende af effektivitet og produktivitet.

De fleste ingeniører, inklusive dem af DevOps-sorten, lider af en eller anden version af analyse-lammelse - en mental lidelse, der begrænser din produktivitet i et forsøg på at overanalisere dit arbejde og undgå enhver mulig uheld.

Træning ufuldkommenhed i dit arbejde kræver, at du omfavner muligheden for fiasko og uundgåeligheden af ​​refactoring. Oprettelse af feedback-løkker rundt om kunden og looping tilbage til forskellige faser i rørledningen er primære lejere af DevOps. I DevOps forbinder du enderne for at bøje linjen i en cirkel.

Når du tænker iterativt og cirkulært, er det meget mindre skræmmende at skubbe kode, der ikke er perfekt ud, fordi koden ikke er udskåret i sten. I stedet er det i en midlertidig tilstand, at DevOps-ingeniører ofte forbedrer sig, når du samler flere data og feedback.

Designe små teams til DevOps

Du har sandsynligvis hørt om Amazons “to-pizza” -hold. Konceptet taler bredt om betydningen af ​​små teams. Nu, det nøjagtige antal mennesker, der består af et to-pizzateam, varierer afhængigt af dine appetit.

Det er en god ide at holde hold under 12 personer. Når en gruppe nærmer sig 9, 10 eller 11 personer, kan du prøve at opdele den i to. Det søde sted for gruppestørrelse er omkring 4-6 personer. Dit nøjagtige antal kan variere afhængigt af de involverede mennesker, men pointen er dette: Når grupper bliver for store, bliver kommunikation udfordrende, kliske dannes, og teamarbejdet lider.

Her er et andet bonusmål, når du danner DevOps-hold: lige antal. Det er en god ide at give folk en "kompis" på arbejdspladsen - nogen, de kan stole på over alle andre. I grupper med lige numre har alle en ven, og ingen er ude. Du kan parre jævnt fra hinanden, og det har en tendens til at fungere godt. Dannelse af lige numre grupper er ikke altid opnåelig på grund af personaltal, men det er noget at huske på.

En formel til måling af kommunikationskanaler er n (n - 1) / 2, hvor n repræsenterer antallet af mennesker. Du kan estimere, hvor kompliceret dit teams kommunikation vil være ved at foretage en simpel beregning. For eksempel ville formlen for et to-pizzateam på 10 være 10 (10 - 1) / 2 = 45 kommunikationskanaler. Du kan forestille dig, hvordan komplekse større teams kan blive.

Sporing af dit DevOps-arbejde

Hvis du kan komme over det lille overhead med at fortælle, hvad du gør hver dag, giver resultaterne dig enestående værdi. At have ægte data om, hvordan du bruger din tid, hjælper dig med at spore dig og dit teams effektivitet. Som Peter Drucker berømt sagde: "Hvis du ikke kan måle det, kan du ikke forbedre det."

Hvor mange dage forlader du arbejde, og følelsen af ​​at du ikke gjorde noget? Du har lige haft møde efter møde eller tilfældige afbrydelser hele dagen. Du er ikke alene. Mange arbejdstagere har det samme problem. Det kan være vanskeligt at spore dine fremskridt og derfor din produktivitet. Forskellen mellem vores følelser af effektivitet og virkeligheden af ​​vores effektivitet er farligt område for ethvert DevOps-team.

Prøv at bruge pen og papir i stedet for et automatiseret værktøj til dette. Ja, du kan bruge software til at spore, hvordan du bruger din tid på din computer. Det kan fortælle dig, når du læser e-mail, hvornår du slapper, og når du koder, men det mangler nuance og ofte går glip af eller forkert kategoriserer store tidstykker.

Når du har en idé om, hvad du laver, og hvornår du kan begynde at identificere, hvilke aktiviteter der falder ind under hvilke kvadranter i Eisenhower Decision Matrix. Hvilket travlt arbejde laver du rutinemæssigt og giver ingen værdi for dig eller organisationen?

Reduktion af friktion i DevOps-projekter

En af de bedste ting, en manager kan gøre for et DevOps-teknikerteam, er at lade dem være i fred. Ansæt nysgerrige ingeniører, der er i stand til at løse problemer uafhængigt og derefter lade dem gøre deres job. Jo mere du kan reducere den friktion, der bremser deres tekniske arbejde, desto mere effektivt bliver dit team.

Reduktion af friktion inkluderer den friktion, der findes mellem holdene - især operationer og udvikling. Glem ikke specialister som sikkerhed.

Tilpasning af mål og incitamenter øger hastigheden. Hvis alle er fokuseret på at nå de samme ting, kan de gå sammen som et team og bevæge sig metodisk mod disse mål.

Humanisering af alarmering for DevOps succes

Hvert ingeniørteam har advarsler om handlinger eller begivenheder, der ikke betyder noget. Når du har alle disse alarmer, føles ingeniørerne følsomme over for de virkelig vigtige alarmer. Mange ingeniører er blevet betinget af at ignorere e-mail-advarsler på grund af en overflod af meddelelser.

Alert træthed skader mange ingeniørorganisationer og koster høje omkostninger. Hvis du bliver oversvømmet hver dag, er det umuligt at vælge det vigtige fra et hav af det uvæsentlige. Du kan endda sige, at disse meddelelser er presserende, men ikke vigtige. . . .

E-mail er ikke et ideelt køretøj til alarmering, fordi det ikke er tidssensitivt (mange mennesker tjekker e-mail kun et par gange om dagen), og det er let at blive begravet i andre detaljer.

Anvend det, du har lært om hurtig iteration, og evaluer regelmæssigt dine alarmeringstærskler for at sikre en passende dækningsgrad uden for mange falske positiver. Det tager tid og arbejde at identificere hvilke advarsler, der ikke er nødvendige. Og det vil sandsynligvis være lidt skræmmende, ikke? Sletning af en advarsel eller forøgelse af en tærskel medfører altid en smule risiko.

Hvad hvis advarslen faktisk er vigtig? Hvis det er tilfældet, finder du ud af det. Husk, at du ikke kan frygte fiasko i en DevOps-organisation. Du skal omfavne det, så du kan skubbe fremad og konstant forbedre. Hvis du lader frygt styre dine beslutninger, stagnerer du - som ingeniør og som organisation.