Infrastruktur som kode: hvordan overvinne problemer med XP

Hei, Habr! Tidligere klaget jeg på livet i Infrastrukturen som kodeparadigme og tilbød ikke noe for å løse dagens situasjon. I dag er jeg tilbake for å fortelle deg hvilke tilnærminger og praksiser som vil hjelpe deg å flykte fra fortvilelsens avgrunn og styre situasjonen i riktig retning.

I forrige artikkel "Infrastruktur som kode: første bekjentskap" Jeg delte mine inntrykk av dette området, prøvde å reflektere over den nåværende situasjonen på dette området, og til og med foreslo at standardpraksis kjent for alle utviklere kunne hjelpe. Det kan virke som det var mange klager på livet, men det var ingen forslag til en vei ut av dagens situasjon.

Hvem vi er, hvor er vi og hvilke problemer vi har

Vi er for tiden i Sre Onboarding Team, som består av seks programmerere og tre infrastrukturingeniører. Vi prøver alle å skrive infrastruktur som kode (IaC). Vi gjør dette fordi vi i utgangspunktet vet hvordan vi skal skrive kode og har en historie med å være "over gjennomsnittet" utviklere.

• Vi har et sett med fordeler: en viss bakgrunn, kunnskap om praksis, evnen til å skrive kode, et ønske om å lære nye ting.
• Og det er en hengende del, som også er et minus: mangel på kunnskap om infrastrukturmaskinvare.

Teknologistabelen vi bruker i vår IaC.

• Terraform for å skape ressurser.
• Pakker for å sette sammen bilder. Dette er Windows, CentOS 7-bilder.
• Jsonnet for å lage et kraftig bygg i drone.io, samt å generere packer json og våre terraform-moduler.
• Azure.
• Ansible når du forbereder bilder.
• Python for hjelpetjenester og klargjøringsskript.
• Og alt dette i VSCode med plugins som deles mellom teammedlemmer.

Konklusjon fra min siste artikkel var slik: Jeg prøvde å innpode (først av alt i meg selv) optimisme, jeg ville si at vi vil prøve tilnærmingene og praksisene som er kjent for oss for å håndtere vanskelighetene og kompleksitetene som finnes på dette området.

Vi sliter for tiden med følgende IaC-problemer:

• Ufullkommenhet av verktøy og midler for kodeutvikling.
• Sakte utplassering. Infrastruktur er en del av den virkelige verden, og den kan være treg.
• Mangel på tilnærminger og praksis.
• Vi er nye og vet ikke så mye.

Ekstrem programmering (XP) til unnsetning

Alle utviklere er kjent med Extreme Programming (XP) og praksisen som ligger bak. Mange av oss har jobbet med denne tilnærmingen, og den har vært vellykket. Så hvorfor ikke bruke prinsippene og praksisene som er nedfelt der for å overvinne infrastrukturutfordringer? Vi bestemte oss for å ta denne tilnærmingen og se hva som skjer.

Sjekke anvendeligheten av XP-tilnærmingen til din bransjeHer er en beskrivelse av miljøet som XP er godt egnet for, og hvordan det forholder seg til oss:

1. Dynamisk endring av programvarekrav. Det var klart for oss hva sluttmålet var. Men detaljene kan variere. Vi bestemmer selv hvor vi skal taxi, så kravene endres med jevne mellomrom (hovedsakelig av oss selv). Tar vi SRE-teamet, som gjør automatiseringen selv, og selv begrenser kravene og arbeidsomfanget, så passer dette punktet godt.

2. Risikoer forårsaket av fasttidsprosjekter ved bruk av ny teknologi. Vi kan støte på risiko ved bruk av ting som er ukjente for oss. Og dette er 100% vårt tilfelle. Hele prosjektet vårt var bruk av teknologier som vi ikke var helt kjent med. Generelt er dette et konstant problem, fordi... Det er mange nye teknologier som dukker opp i infrastruktursektoren hele tiden.

3,4. Lite, samlokalisert utvidet utviklingsteam. Den automatiserte teknologien du bruker gir mulighet for enhets- og funksjonstester. Disse to punktene passer ikke helt for oss. For det første er vi ikke et koordinert lag, og for det andre er vi ni, som kan betraktes som et stort team. Selv om, ifølge noen definisjoner av et "stort" team, er mye 14+ personer.

La oss se på noen XP-praksis og hvordan de påvirker hastigheten og kvaliteten på tilbakemeldinger.

XP Feedback Loop Prinsipp

Etter min forståelse er tilbakemelding svaret på spørsmålet, gjør jeg det rette, skal vi dit? XP har et guddommelig opplegg for dette: en tidstilbakemeldingssløyfe. Det interessante er at jo lavere vi er, jo raskere er vi i stand til å få OS til å svare på de nødvendige spørsmålene.

Dette er et ganske interessant tema for diskusjon, at i vår IT-bransje er det mulig å raskt få et OS. Se for deg hvor vondt det er å gjøre et prosjekt i seks måneder og først da finne ut at det var en feil helt i begynnelsen. Dette skjer i design og i enhver konstruksjon av komplekse systemer.

I vårt tilfelle av IaC hjelper tilbakemelding oss. Jeg vil umiddelbart gjøre en liten justering av diagrammet ovenfor: utgivelsesplanen har ikke en månedlig syklus, men forekommer flere ganger om dagen. Det er noen praksis knyttet til denne OS-syklusen som vi vil se nærmere på.

Viktig: tilbakemelding kan være en løsning på alle problemene nevnt ovenfor. Kombinert med XP-praksis kan det trekke deg ut av fortvilelsens avgrunn.

Hvordan trekke deg ut av fortvilelsens avgrunn: tre øvelser

Tester

Tester er nevnt to ganger i XP-tilbakemeldingssløyfen. Det er ikke bare sånn. De er ekstremt viktige for hele ekstremprogrammeringsteknikken.

Det forutsettes at du har Enhets- og Akseptprøver. Noen gir deg tilbakemelding på noen få minutter, andre i løpet av få dager, så de tar lengre tid å skrive og blir anmeldt sjeldnere.

Det er en klassisk testpyramide, som viser at det burde vært flere tester.

Hvordan gjelder dette rammeverket for oss i et IaC-prosjekt? Faktisk... ikke i det hele tatt.

• Enhetstester, til tross for at det burde være mange av dem, kan ikke bli for mange. Eller de tester noe veldig indirekte. Faktisk kan vi si at vi ikke skriver dem i det hele tatt. Men her er noen søknader for slike tester som vi var i stand til å gjøre:
  1. Tester jsonnet-koden. Dette er for eksempel dronemonteringsrørledningen vår, som er ganske komplisert. Jsonnet-koden er godt dekket av tester.
     Vi bruker dette Enhetstestramme for Jsonnet.
  2. Tester for skript som kjøres når ressursen starter. Skript er skrevet i Python, og derfor kan tester skrives på dem.
• Det er potensielt mulig å sjekke konfigurasjonen i tester, men det gjør vi ikke. Det er også mulig å konfigurere kontrollressurskonfigurasjonsregler via tflint. Imidlertid er sjekkene der rett og slett for grunnleggende for terraform, men mange testskript er skrevet for AWS. Og vi er på Azure, så dette gjelder ikke igjen.
• Komponentintegrasjonstester: det avhenger av hvordan du klassifiserer dem og hvor du plasserer dem. Men de fungerer i grunnen.

  Slik ser integrasjonstester ut.

  
  
  Dette er et eksempel når du bygger bilder i Drone CI. For å nå dem må du vente 30 minutter på at Packer-bildet dannes, og deretter vente 15 minutter til før de passerer. Men de finnes!

  Algoritme for bildeverifisering

  1. Packer må først forberede bildet fullstendig.
  2. Ved siden av testen er det en terraform med en lokal stat, som vi bruker til å distribuere dette bildet.
  3. Ved utfolding brukes en liten modul som ligger i nærheten for å gjøre det lettere å jobbe med bildet.
  4. Når VM-en er distribuert fra bildet, kan kontrollene begynne. I utgangspunktet utføres kontroller med bil. Den sjekker hvordan skriptene fungerte ved oppstart og hvordan demonene fungerer. For å gjøre dette, via ssh eller winrm logger vi inn på den nylig hevet maskinen og sjekker konfigurasjonsstatusen eller om tjenestene er oppe.

• Situasjonen er lik med integrasjonstester i moduler for terraform. Her er en kort tabell som forklarer funksjonene til slike tester.

  
  
  Tilbakemelding på rørledningen er rundt 40 minutter. Alt skjer i veldig lang tid. Det kan brukes til regresjon, men for nyutvikling er det generelt urealistisk. Hvis du er veldig, veldig forberedt på dette, klargjør kjørende skript, så kan du redusere det til 10 minutter. Men dette er fortsatt ikke enhetstester, som gjør 5 stykker på 100 sekunder.

Fraværet av enhetstester ved sammenstilling av bilder eller terraform-moduler oppmuntrer til å flytte arbeidet til separate tjenester som ganske enkelt kan kjøres via REST, eller til Python-skript.

For eksempel måtte vi sørge for at når den virtuelle maskinen starter, registrerer den seg selv i tjenesten ScaleFT, og når den virtuelle maskinen ble ødelagt, slettet den seg selv.

Siden vi har ScaleFT som en tjeneste, er vi tvunget til å jobbe med den gjennom API. Det var et omslag skrevet der som du kunne trekke og si: «Gå inn og slett det og det.» Den lagrer alle nødvendige innstillinger og tilganger.

Vi kan allerede skrive normale tester for dette, siden det ikke er forskjellig fra vanlig programvare: en slags apiha blir hånet, du trekker den og ser hva som skjer.

Resultater av testene: Enhetstesting, som skal gi OS på et minutt, gir det ikke. Og typer testing høyere i pyramiden er effektive, men dekker bare deler av problemene.

Parprogrammering

Tester er selvfølgelig bra. Du kan skrive mange av dem, de kan være av forskjellige typer. De vil jobbe på sine nivåer og gi oss tilbakemeldinger. Men problemet med dårlige enhetstester, som gir det raskeste operativsystemet, gjenstår. Samtidig vil jeg fortsatt ha et raskt OS som er enkelt og behagelig å jobbe med. For ikke å snakke om kvaliteten på den resulterende løsningen. Heldigvis finnes det teknikker som kan gi enda raskere tilbakemelding enn enhetstester. Dette er parprogrammering.

Når du skriver kode, ønsker du å få tilbakemelding på kvaliteten så raskt som mulig. Ja, du kan skrive alt i en funksjonsgren (for ikke å ødelegge noe for noen), lage en pull-forespørsel i Github, tilordne den til noen hvis mening har vekt, og vente på svar.

Men du kan vente lenge. Folk er alle opptatt, og svaret, selv om det er en, er kanskje ikke av høyeste kvalitet. Anta at svaret kom umiddelbart, anmelderen forsto umiddelbart hele ideen, men svaret kommer fortsatt sent, etterpå. Jeg skulle ønske det var tidligere. Det er dette parprogrammering er rettet mot – med en gang, i skrivende stund.

Nedenfor er parprogrammeringsstilene og deres anvendelighet i arbeid med IaC:

1. Klassisk, Erfaren+Erfaren, skift for timer. To roller - sjåfør og navigatør. To mennesker. De jobber med den samme koden og bytter roller etter en viss forhåndsbestemt tidsperiode.

La oss vurdere kompatibiliteten til problemene våre med stil:

• Problem: ufullkommenhet av verktøy og verktøy for kodeutvikling.
  Negativ påvirkning: det tar lengre tid å utvikle seg, vi bremser ned, tempoet/rytmen i arbeidet går tapt.
  Hvordan vi kjemper: vi bruker et annet verktøy, en felles IDE og lærer også snarveier.
• Problem: Treg distribusjon.
  Negativ innvirkning: øker tiden det tar å lage et fungerende kodestykke. Vi kjeder oss mens vi venter, hendene strekker seg ut for å gjøre noe annet mens vi venter.
  Hvordan vi kjemper: vi har ikke overvunnet det.
• Problem: mangel på tilnærminger og praksis.
  Negativ innvirkning: det er ingen kunnskap om hvordan man gjør det bra og hvordan man gjør det dårlig. Forlenger mottak av tilbakemelding.
  Hvordan vi kjemper: gjensidig utveksling av meninger og praksis i pararbeid løser nesten problemet.

Hovedproblemet med å bruke denne stilen i IaC er det ujevne arbeidstempoet. I tradisjonell programvareutvikling har du en veldig enhetlig bevegelse. Du kan bruke fem minutter og skrive N. Bruk 10 minutter og skriv 2N, 15 minutter - 3N. Her kan du bruke fem minutter og skrive N, og så bruke 30 minutter til og skrive en tidel av N. Her vet du ingenting, du sitter fast, dum. Etterforskningen tar tid og distraherer fra selve programmeringen.

Konklusjon: i sin rene form er det ikke egnet for oss.

2. Ping-pong. Denne tilnærmingen innebærer at en person skriver testen og en annen gjør implementeringen for den. Tar man i betraktning at alt er komplisert med Unit-tester, og man må skrive en integrasjonstest som tar lang tid å programmere, forsvinner all lettheten med ping-pong.

Jeg kan si at vi prøvde å skille ansvar for å designe et testskript og implementere kode for det. En deltaker kom med manus, i denne delen av arbeidet han hadde ansvaret, hadde han siste ordet. Og den andre var ansvarlig for gjennomføringen. Det fungerte bra. Kvaliteten på manuset med denne tilnærmingen øker.

Konklusjon: dessverre, arbeidstempoet tillater ikke bruk av ping-pong som en parprogrammeringspraksis i IaC.

3. Sterk stil. Vanskelig praksis. Tanken er at den ene deltakeren blir direktivnavigator, og den andre tar rollen som henrettelsessjåføren. I dette tilfellet ligger retten til å ta avgjørelser utelukkende hos navigatøren. Sjåføren skriver kun ut og kan påvirke hva som skjer med et ord. Rollene endres ikke på lenge.

Bra for læring, men krever sterke myke ferdigheter. Det var her vi vaklet. Teknikken var vanskelig. Og det handler ikke engang om infrastruktur.

Konklusjon: den kan potensielt brukes, vi gir ikke opp å prøve.

4. Mobbing, sverming og alle kjente, men ikke oppførte stiler Vi vurderer det ikke, pga Vi har ikke prøvd det, og det er umulig å snakke om det i sammenheng med arbeidet vårt.

Generelle resultater for bruk av parprogrammering:

• Vi har et ujevnt arbeidstempo, noe som er forvirrende.
• Vi møtte utilstrekkelig gode myke ferdigheter. Og fagområdet hjelper ikke med å overvinne disse manglene våre.
• Lange tester og problemer med verktøy gjør paret utvikling vanskelig.

5. Til tross for dette var det suksesser. Vi kom opp med vår egen metode "Konvergens - Divergens". Jeg vil kort beskrive hvordan det fungerer.

Vi har faste samarbeidspartnere i noen dager (mindre enn en uke). Vi gjør én oppgave sammen. Vi sitter sammen en stund: den ene skriver, den andre sitter og ser på støtteteamet. Så sprer vi oss en stund, hver gjør noen uavhengige ting, så kommer vi sammen igjen, synkroniserer veldig raskt, gjør noe sammen og sprer oss igjen.

Planlegging og kommunikasjon

Den siste blokken med praksis som OS-problemer løses gjennom, er organiseringen av arbeidet med selve oppgavene. Dette inkluderer også erfaringsutveksling som er utenfor pararbeid. La oss se på tre praksiser:

1. Mål gjennom måltreet. Vi organiserte den overordnede ledelsen av prosjektet gjennom et tre som går uendelig inn i fremtiden. Teknisk sett gjøres sporingen i Miro. Det er én oppgave – det er et delmål. Fra det går enten mindre mål eller grupper av oppgaver. Selve oppgavene kommer fra dem. Alle oppgaver opprettes og vedlikeholdes på dette styret.

Denne ordningen gir også tilbakemelding, som skjer en gang om dagen når vi synkroniserer på stevner. Å ha en felles plan foran alle, men strukturert og helt åpen, gjør at alle kan være klar over hva som skjer og hvor langt vi har kommet.

Fordeler med visuell visjon av oppgaver:

• Kausalitet. Hver oppgave fører til et eller annet globalt mål. Oppgaver er gruppert i mindre mål. Selve infrastrukturdomenet er ganske teknisk. Det er ikke alltid umiddelbart klart hvilken spesifikk innvirkning, for eksempel å skrive en runbook på migrering til en annen nginx, har på virksomheten. Å ha målkortet i nærheten gjør det klarere.
  
  Kausalitet er en viktig egenskap ved problemer. Det svarer direkte på spørsmålet: "Gjør jeg det rette?"
• Parallellisme. Vi er ni, og det er rett og slett fysisk umulig å kaste alle på én oppgave. Oppgaver fra ett område er kanskje ikke alltid nok heller. Vi er tvunget til å parallellisere arbeid mellom små arbeidsgrupper. Samtidig sitter gruppene med oppgaven sin en stund, de kan bli forsterket av noen andre. Noen ganger faller folk bort fra denne arbeidsgruppen. Noen drar på ferie, noen lager en rapport for DevOps-konferansen, noen skriver en artikkel om Habr. Å vite hvilke mål og oppgaver som kan gjøres parallelt blir veldig viktig.

2. Erstatning foredragsholdere av morgenmøter. Hos stand-ups har vi dette problemet – folk gjør mange oppgaver parallelt. Noen ganger henger oppgaver løst sammen og det er ingen forståelse for hvem som gjør hva. Og meningen til et annet teammedlem er veldig viktig. Dette er tilleggsinformasjon som kan endre forløpet for å løse problemet. Selvfølgelig er det vanligvis noen med deg, men råd og tips er alltid nyttige.

For å forbedre denne situasjonen brukte vi "Changing the Leading Stand-Up"-teknikken. Nå roteres de etter en bestemt liste, og dette har sin effekt. Når det er din tur, blir du tvunget til å dykke inn og forstå hva som skjer for å kunne gjennomføre et godt Scrum-møte.

3. Intern demo. Hjelp til å løse et problem fra parprogrammering, visualisering på problemtreet og hjelp på scrummøter om morgenen er bra, men ikke ideelt. Som et par begrenses dere kun av kunnskapen deres. Oppgavetreet bidrar til globalt å forstå hvem som gjør hva. Og programlederen og kollegene på morgenmøtet vil ikke dykke dypt inn i problemene dine. De kan sikkert gå glipp av noe.

Løsningen ble funnet ved å demonstrere arbeidet som ble utført for hverandre og deretter diskutere det. Vi møtes en gang i uken i en time og viser detaljer om løsninger på oppgaver vi har gjort den siste uken.

Under demonstrasjonen er det nødvendig å avsløre detaljene i oppgaven og sørg for å demonstrere driften.

Rapporten kan gjennomføres ved hjelp av en sjekkliste.1. Gå inn i kontekst. Hvor kom oppgaven fra, hvorfor var den i det hele tatt nødvendig?

2. Hvordan ble problemet løst før? For eksempel var det nødvendig med massiv museklikk, eller det var umulig å gjøre noe i det hele tatt.

3. Hvordan vi forbedrer det. For eksempel: "Se, nå er det scriptosik, her er readme."

4. Vis hvordan det fungerer. Det anbefales å implementere et brukerscenario direkte. Jeg vil ha X, jeg gjør Y, jeg ser Y (eller Z). For eksempel distribuerer jeg NGINX, røyker url-en og får 200 OK. Hvis handlingen er lang, forberede den på forhånd slik at du kan vise den senere. Det er tilrådelig å ikke bryte den for mye en time før demoen, hvis den er skjør.

5. Forklar hvor vellykket problemet ble løst, hvilke vanskeligheter som gjenstår, hva som ikke er fullført, hvilke forbedringer som er mulige i fremtiden. For eksempel nå CLI, da blir det full automatisering i CI.

Det er tilrådelig for hver høyttaler å holde det til 5-10 minutter. Hvis talen din åpenbart er viktig og vil ta lengre tid, koordiner dette på forhånd i sre-overtakelseskanalen.

Etter ansikt-til-ansikt-delen er det alltid en diskusjon i tråden. Her kommer tilbakemeldingene vi trenger på oppgavene våre.

Som et resultat gjennomføres det en undersøkelse for å fastslå nytten av det som skjer. Dette er tilbakemelding på essensen i talen og viktigheten av oppgaven.

Lange konklusjoner og hva som skjer videre

Det kan virke som om tonen i artikkelen er noe pessimistisk. Dette er feil. To lavere nivåer av tilbakemelding, nemlig tester og parprogrammering, fungerer. Ikke like perfekt som i tradisjonell utvikling, men det er en positiv effekt av det.

Tester, i sin nåværende form, gir kun delvis kodedekning. Mange konfigurasjonsfunksjoner ender opp uprøvd. Deres innflytelse på det faktiske arbeidet når de skriver kode er lav. Det er imidlertid en effekt fra integrasjonstester, og de lar deg fryktløst utføre refaktoreringer. Dette er en stor prestasjon. Med skiftet av fokus til utvikling i språk på høyt nivå (vi har python, gå), forsvinner problemet. Og du trenger ikke mange sjekker for "limet"; en generell integrasjonssjekk er nok.

Å jobbe i par avhenger mer av spesifikke personer. Det er oppgavefaktoren og våre myke ferdigheter. Hos noen går det veldig bra, med andre går det dårligere. Det er definitivt fordeler med dette. Det er klart at selv om reglene for pararbeid ikke overholdes tilstrekkelig, har selve det å utføre oppgaver sammen en positiv effekt på kvaliteten på resultatet. Personlig synes jeg det er lettere og morsommere å jobbe i par.

Måter på høyere nivå å påvirke OS - planlegging og arbeid med oppgaver gir nøyaktige effekter: høykvalitets kunnskapsutveksling og forbedret utviklingskvalitet.

Korte konklusjoner på én linje

• HR-utøvere jobber i IaC, men med mindre effektivitet.
• Styrk det som fungerer.
• Kom opp med dine egne kompenserende mekanismer og praksis.

Kilde: www.habr.com