🥇Infrastructure as Code: hvordan takle problemer ved hjelp av XP

Hei, Habr! Tidligere har jeg klaget over livet i paradigmet Infrastructure as Code uten å foreslå løsninger på situasjonen. I dag er jeg tilbake for å fortelle hvilke tilnærminger og praksiser som kan hjelpe oss å komme ut av avgrunnen av fortvilelse og styre situasjonen i riktig retning.

I den forrige artikkelen «Infrastructure as Code: første bekjentskap» Jeg delte mine inntrykk av dette feltet, prøvde å reflektere over den nåværende situasjonen og til og med antydet at standardpraksiser kjent for utviklere kan være til hjelp. Det kan ha sett ut som jeg klaget mye over livet, men det var ingen forslag til hvordan man kunne komme ut av situasjonen.

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

Nå er vi i SRE Onboarding Team, som består av seks programmerere og tre infrastrukturingeniører. Alle prøver å skrive Infrastructure as Code (IaC). Vi gjør det fordi vi i utgangspunktet kan skrive kode og har en bakgrunn som «over middels» utviklere.

Vi har en rekke fordeler: en viss bakgrunn, kunnskap om praksiser, evnen til å skrive kode, og ønsket om å lære noe nytt.
Og det er en sårbar del, som også er en ulempe: mangel på kunnskap om infrastrukturens materie.

Teknologibunken vi bruker i vår IaC.

Terraform for å opprette ressurser.
Packer for å bygge bilder. Dette er Windows, CentOS 7 bilder.
Jsonnet for å lage kraftige bygg i drone.io, samt for å generere packer json og våre Terraform-moduler.
Azure.
Ansible for å forberede bildene.
Python for hjelpeservere, samt provisjoneringsskripter.
Og alt dette i VSCode med plugins delt mellom teammedlemmene.

Min konklusjon var slik: jeg prøvde å påføre (først og fremst meg selv) optimisme, ønsket å si at vi vil prøve kjente tilnærminger og praksiser for å takle utfordringer og vanskeligheter i dette feltet. den forrige artikkelen Akkurat nå kjemper vi med slike problemer i IaC:

Ufullkommenhet av verktøy og utviklingsmidler.

Langsom deployering. Infrastruktur er en del av den virkelige verden, som kan være treg.
Mangel på tilnærminger og praksiser.
Vi er nybegynnere og vet lite.
Ekstrem programmering (XP) skyndter seg til unnsetning.

Ekstrem programmering (XP) skyndter seg til unnsetning.

Alle utviklere er godt kjent med ekstrem programmering (XP) og de praksisene som følger med. Mange av oss har jobbet med denne tilnærmingen, og den har vært vellykket. Så hvorfor ikke benytte prinsippene og praksisene som er lagt der for å overvinne infrastrukturen? Vi har bestemt oss for å anvende denne tilnærmingen og se hva som kommer ut av det.

Vurdering av anvendbarheten av XP-tilnærmingen til ditt områdeHer er en beskrivelse av miljøet der XP passer godt, og hvordan det relaterer til oss:

1. Dynamisk skiftende programvarekrav. Vi hadde klart for oss hva det endelige målet var. Men detaljene kan varieres. Vi bestemmer selv retningen vi skal ta, så kravene endres fra tid til annen (for det meste av oss selv). Når det gjelder SRE-teamet som både gjør automatisering og setter begrensningene for kravene og omfanget av arbeidet, passer dette punktet godt.

2. Risikoer forårsaket av faste tidsprosjekter som bruker ny teknologi. Vi kan stå overfor risikoer når vi bruker noe vi ikke kjenner til. Og det er 100% vårt tilfelle. Hele prosjektet vårt er basert på teknologier vi ikke var helt kjent med. Dette er generelt et konstant problem, ettersom det stadig dukker opp mange nye teknologier innen infrastruktur.

3,4. Liten, co-lokalisert utvidet utviklingsteam. Teknologien du bruker, muliggjør automatiserte enhets- og funksjonstester. Disse to punktene passer ikke helt for oss. For det første er vi ikke et co-lokalisert team, og for det andre er vi ni personer, som kan betraktes som et stort team. Selv om mange definisjoner av «stor» team sier at en stor gruppe er 14+ personer.

La oss se på noen praksiser fra XP og hvordan de påvirker hastigheten og kvaliteten på tilbakemeldingene.

Prinsippet om tilbakemeldingssyklusen i XP

Etter min forståelse er tilbakemelding et svar på spørsmålet, gjør jeg dette riktig, er vi på rett vei? I XP finnes det et guddommelig diagram om dette: tidsbasert tilbakemeldingssyklus. Det interessante er at jo lavere vi befinner oss, jo raskere får vi muligheten til å få tilbakemelding for å svare på nødvendige spørsmål.

Dette er et ganske interessant tema for diskusjon, for i IT-industrien er det mulig å få tilbakemelding raskt. Tenk deg hvor vanskelig det ville være å jobbe med et prosjekt i et halvt år og så først finne ut at det i begynnelsen ble lagt en feil. Dette skjer både i design og i bygging av komplekse systemer.

I vårt tilfelle hjelper IaC oss med tilbakemelding. Jeg gjør straks en liten justering i skjemaet ovenfor: utgivelsesplanen har ikke en månedlig syklus, men skjer flere ganger om dagen. Til denne syklusen er det knyttet noen praksiser som vi vil se nærmere på.

Viktig: tilbakemelding kan bli løsningen på alle de nevnte problemene. Sammen med XP-praksiser kan den trekke oss ut av avgrunnen av fortvilelse.

Hvordan trekke seg selv ut av avgrunnen av fortvilelse: tre praksiser

Tester

Tester nevnes to ganger i XP-tilbakemeldingssyklusen. Dette er ikke tilfeldig. De er ekstremt viktige for hele teknikken med ekstrem programmering.

Det antas at du har enhetstester og akseptansetester. Den første gir deg tilbakemelding etter noen minutter, den andre etter noen dager, derfor tar det lengre tid å skrive dem, og de kjøres sjeldnere.

Det finnes en klassisk testpyramide som viser at det bør være flere av visse tester.

Hvordan er dette skjemaet anvendelig for oss i IaC-prosjektet? Faktisk… ikke i det hele tatt.

Selv om det bør være mange enhetstester, kan det ikke være for mange. Enten tester de noe veldig indirekte. Faktisk kan vi si at vi ikke skriver dem i det hele tatt. Men her er noen anvendelser for slike tester som vi likevel har fått gjort:
1. Testing av kode i jsonnet. Dette er for eksempel vår byggpipeline i drone, som er ganske komplisert. Kode i jsonnet dekkes godt av tester.
  Vi bruker denne Unit testing framework for Jsonnet.
2. Tester på skripter som kjøres ved oppstart av ressursen. Skriptene er skrevet i Python, og dermed kan testene på dem også skrives.
Potensielt er det mulig å sjekke konfigurasjonen i testene, men det gjør vi ikke. Det er også mulig å sette opp validering av konfigurasjonsregler for ressurser gjennom tflint. Men for Terraform er det bare for grunnleggende sjekker, men mange sjekkscenarier er skrevet for AWS. Og vi bruker Azure, så dette passer igjen ikke.
Komponentintegrasjonstester: her avhenger det av hvordan du klassifiserer dem og hvor du plasserer dem. Men de fungerer egentlig.
Slik ser integrasjonstestene ut.

Dette er et eksempel ved bygging av bilder i Drone CI. For å komme til dem må man vente i 30 minutter mens Packer-bildet bygges, deretter ytterligere 15 minutter mens de fullføres. Men de finnes!
Algoritmen for å sjekke bilder
1. Først må Packer forberede bildet helt.
2. Ved siden av testen er det Terraform med lokal tilstand, som vi bruker til å rulle ut dette bildet.
3. Under utrullingen brukes en liten modul som ligger ved siden av for enklere arbeid med bildet.
4. Når VM-en er rullet ut fra bildet, kan vi begynne med sjekkene. Hovedsakelig utføres sjekkene på maskinen. Vi tester hvordan skriptene fungerte ved oppstart, og hvordan tjenestene fungerer. For dette logger vi inn på den nylig opprettede maskinen via ssh eller winrm for å sjekke konfigurasjonsstatusen eller om tjenestene har startet.
Situasjonen er lik med integrasjonstester og i modulene for Terraform. Her er en kort tabell som forklarer egenskapene til slike tester.

Tilbakemelding på pipelinen tar omtrent 40 minutter. Alt går veldig sakte. Det kan brukes til regresjonstesting, men for ny utvikling er det helt urealistisk. Hvis man forbereder seg skikkelig, setter opp kjøringer og skripter, kan man kanskje redusere det til 10 minutter. Men det er fortsatt ikke enhetstester, som kan kjøre 100 tester på 5 sekunder.

Mangelen på enhetstester ved bygging av bilder eller Terraform-moduler gjør at arbeidet må overlates til separate tjenester, som kan kontaktes via REST, eller til Python-skripter.

For eksempel måtte vi gjøre det slik at når den virtuelle maskinen startet, registrerte den seg i tjenesten ScaleFT, og da virtuelle maskinen ble ødelagt, fjernet den seg selv.

Siden ScaleFT er en tjeneste, må vi jobbe med den gjennom API-et. Det ble skrevet en innpakning som vi kan bruke til å si: «Gå inn og fjern dette, dette». Den lagrer alle nødvendige innstillinger og tilgang.

Vi kan nå skrive ordentlige tester for dette, siden det ikke skiller seg fra vanlig programvare: vi lager en mock av et API, du kontakter det, og ser hva som skjer.

Resultater fra testene: Enhetstesting, som burde gi OS feedback på ett minutt, gir ikke dette. Høyere nivåer av testing gir resultater, men dekker bare en del av problemene.

Parprogrammering

Tester er selvfølgelig bra. Du kan skrive mange av dem, de kan være av forskjellige typer. De vil fungere på sine nivåer og gi oss tilbakemelding. Men problemet med dårlige enhetstester, som gir det raskeste OS, vedvarer. Samtidig ønsker man et raskt OS, det er lett og behagelig å jobbe med. Ikke å snakke om kvaliteten på løsningen som oppnås. Heldigvis finnes det teknikker som gir enda raskere tilbakemelding enn modulære tester. Det er pareprogrammering.

Når du skriver kode, vil du ha tilbakemelding om kvaliteten så raskt som mulig. Ja, du kan skrive alt i en funktionsgren (for ikke å ødelegge noe for noen), lage en pull request på GitHub, tildele den til noen med relevant mening, og vente på svar.

Men ventetiden kan bli lang. Folk er travle, og svaret, selv om det kommer, kan ha lav kvalitet. La oss anta at svaret kom umiddelbart, og gjennomgangen umiddelbart forsto hele hensikten, men svaret kommer fortsatt med forsinkelse, i ettertid. Og man ønsker det tidligere. Det er nettopp derfor pareprogrammering er rettet mot – for å få tilbakemelding umiddelbart, i løpet av skriveprosessen.

Her presenterer jeg stilene for pareprogrammering og deres anvendelighet i arbeidet med IaC:

1. Klassisk, Erfaren + erfaren, bytte etter et tidsintervall. To roller – driver og navigator. To personer. De jobber med samme kode og bytter roller etter en bestemt tid som er forhåndsbestemt.

La oss se på kompatibiliteten mellom våre problemer og stilen:

Problem: ufullkommenhet i verktøyene for kodeutvikling.
Negativ innvirkning: lengre utvikling, vi bremser, arbeidsrytmen går i stykker.
Hvordan vi takler det: vi bruker andre verktøy, felles IDE og lærer hurtigtaster.
Problem: langsom distribusjon.
Negativ innvirkning: øker tiden det tar å lage en fungerende del av koden. Vi kjeder oss mens vi venter, hendene fristes til å gjøre noe annet mens vi venter.
Hvordan vi takler det: vi har ikke løst det.
Problem: mangel på tilnærminger og praksiser.
Negativ innvirkning: ingen kunnskap om hva som er bra eller dårlig. Forlenger tilbakemeldingstiden.
Hvordan vi takler det: utveksling av meninger og praksiser i paret nesten løser problemet.

Hovudproblemet med å bruke denne stilen i IaC er den ujevne arbeidsflyten. I tradisjonell programvareutvikling har en veldig jevn flyt. Du kan bruke fem minutter på å skrive N. Bruke ti minutter på å skrive 2N, og 15 minutter på å skrive 3N. Her kan du bruke fem minutter på å skrive N, og deretter bruke enda 30 minutter og skrive en tidel av N. Her vet du ingenting, du står fast, det stopper opp. Å finne løsninger tar tid og avleder fra selve programmeringen.

Konklusjon: I sin rene form passer det ikke for oss.

2. Ping-pong. Denne tilnærmingen innebærer at én deltaker skriver testen, mens en annen lager implementeringen for den. Med tanke på at alt med enhetstester er komplisert, og man må bruke mye tid på å skrive integrasjonstester, forsvinner all enkelhet i ping-pong.

Jeg kan si at vi har prøvd å dele ansvaret for å utforme testscenarier og implementere koden for dem. Én deltaker fant på scenariet, og i denne delen av arbeidet var han ansvarlig, og han hadde det siste ordet. Den andre var ansvarlig for implementeringen. Dette fungerte bra. Kvaliteten på scenariene økte med denne tilnærmingen.

Konklusjon: dessverre tillater arbeidsflyten ikke å bruke ping-pong som en praksis for parprogrammering i IaC.

3. Strong Style. En komplisert praksis. Ideen er at én deltaker blir en styrende navigator, mens den andre tar rollen som utførende driver. Beslutningsretten tilhører utelukkende navigatoren. Driveren skriver bare og kan med ord påvirke hva som skjer. Rollene forblir uendret over lengre tid.Godt egnet for læring, men krever sterke soft skills. Her stoppet vi også. Teknikken var vanskelig å følge. Og det handler ikke engang om infrastrukturen.

Konklusjon: potensielt kan det brukes, vi gir ikke opp forsøket.

4. Mobbing, swarming og alle kjente, men ikke nevnte stiler

vurderes ikke, siden vi ikke har prøvd dem og ikke kan si noe om dem i konteksten av vårt arbeid. Generelle oppsummeringer om bruk av parprogrammering:

Vi har en ujevn arbeidsflyt som skaper forstyrrelser.

Vi har støtt på utilstrekkelige soft skills. Og fagfeltet bidrar ikke til å overvinne disse manglene.

Langvarige tester og problemer med verktøyene gjør parprogrammering vanskelig.

Dårlig støtte i omgivelser og verktøy gjør utviklingsprosessen treig.

5. Til tross for dette var det også suksesser. Vi utviklet vår egen metode kalt «Sammenkomst – adskillelse». Jeg skal kort beskrive hvordan den fungerer.

Vi har faste partnere i flere dager (mindre enn en uke). Vi løser en oppgave sammen. En stund sitter vi sammen: en skriver, den andre sitter og observerer, som et supportteam. Deretter separerer vi oss en stund, hver gjør sine egne ting, så møtes vi igjen, synkroniserer oss raskt, jobber sammen og så skilles vi igjen.

Planlegging og kommunikasjon

Den siste blokken med praksiser hvor vi løser OS-problemer er organisering av arbeidet med oppgavene selv. Her inngår også erfaringsutveksling som skjer uten pararbeid. La oss se på tre praksiser:

1. Oppgaver gjennom måltreet. Den generelle prosjektledelsen har vi organisert gjennom et tre som strekker seg uendelig inn i fremtiden. Teknisk sett føres dette i Miro. Det er én oppgave – den er et mellomliggende mål. Fra den går det enten mindre mål eller grupper av oppgaver. Fra dem går det egen oppgaver. Alle oppgaver opprettes og føres på denne tavlen.

Denne ordningen gir også tilbakemelding, som skjer en gang om dagen når vi synkroniserer oss i møter. Å ha en felles plan, som er strukturert og helt åpen, gjør at alle er oppdatert på hva som skjer og hvor langt vi har kommet i fremdriften.

Fordeler med visuell oversikt av oppgaver:

Årsakssammenheng. Hver oppgave fører til et overordnet mål. Oppgavene grupperes etter mindre mål. Domenen for infrastruktur er i seg selv ganske teknisk. Det er ikke alltid helt klart hvilket konkret innvirkning, for eksempel, å skrive en håndbok for migrering til en annen nginx, har på bedriften. Å ha et målkort ved siden av gjør dette mer forståelig.

Årsakssammenheng er en viktig egenskap ved oppgaver. Den svarer direkte på spørsmålet: «Gjør jeg det riktige?»
Parallellitet. Vi er ni personer, og det er fysisk umulig å kaste seg over én oppgave samtidig. Det er ikke alltid nok oppgaver fra ett område. Vi må nødvendigvis parallellisere arbeidet mellom små arbeidsgrupper. På denne måten jobber gruppene en stund med sin oppgave, og de kan bli styrket av noen andre. Personer kan noen ganger forlate denne arbeidsgruppen. Noen tar ferie, noen holder en presentasjon på DevOps-konferansen, noen skriver en artikkel på Habr. Det blir veldig viktig å vite hvilke mål og oppgaver som kan gjøres parallelt.

2. Rotasjon av ledere for morgenmøtene. Det oppstod et problem i standup-møtene - mange oppgaver blir gjort parallelt. Noen ganger er oppgavene svakt knyttet til hverandre og det er ikke klart hvem som gjør hva. Men meningen til enda et teammedlem er veldig viktig. Dette er tilleggsinformasjon som kan endre utfallet av oppgaveløsningen. Selv om det vanligvis er noen i par med deg, er konsultasjoner og tips aldri overflødige.

For å forbedre denne situasjonen har vi tatt i bruk teknikken "Skifte av leder for standup". Nå roterer de etter en bestemt liste, og dette har en effekt. Når det blir din tur, blir du tvunget til å dykke inn og forstå hva som skjer for å kunne lede scrum-møtet godt.

3. Internt demo. Hjelp til oppgaveløsning fra parprogrammering, visualisering på oppgavetreet og hjelp på scrum-møtene om morgenen – det er bra, men ikke perfekt. I par er man begrenset av ens egne kunnskaper. Oppgavetreet hjelper til med å forstå globalt hvem som gjør hva. Lederen og kolleger på morgenmøtet vil ikke dykke dypt inn i problemene dine. De kan definitivt gå glipp av noe.

Løsningen ble funnet i å demonstrere gjort arbeid for hverandre og deretter diskutere det. Vi samles en gang i uken i en time og viser detaljer om løsningene på oppgavene vi har gjort den siste uken.

Under demonstrasjonen må man avdekke detaljene i oppgaven og sørge for å vise hvordan den fungerer.

Foredraget kan ledes etter en sjekkliste.1. Sett i kontekst. Hvor kom oppgaven fra, hvorfor var dette nødvendig?

2. Hvordan ble oppgaven løst før? For eksempel var det nødvendig med masse musklikk, eller var det umulig å gjøre noe som helst.

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

4. Vis hva det er som skjer. Det er ønskelig å demonstrere et brukerscenario direkte. Jeg vil ha X, gjør Y, ser Z (eller Y). For eksempel, jeg deployer NGINX, checker URL-en, får 200 OK. Hvis handlingen tar lang tid, forbered på forhånd, så vi kan vise det senere. Det er best om det ikke er noe som bryter sammen en time før demoen.

5. Forklar hvor godt problemet er løst, hvilke vanskeligheter som gjenstår, hva som ikke er fullført, og hvilke forbedringer som kan bli gjort videre. For eksempel, nå er det CLI, senere vil det være full automatisering i CI.

Hver taler bør forsøke å holde seg innen 5-10 minutter. Hvis ditt innlegg helt åpenbart er viktig og vil ta lengre tid, avtal dette på forhånd i sre-takeover-kanalen.

Etter den fysiske delen er det viktig å ha en diskusjon i tråden. Her dukker vår nødvendige tilbakemelding på oppgavene opp.

Til slutt vil det bli gjennomført en undersøkelse for å vurdere nytteverdien av det som har skjedd. Dette er tilbakemelding på selve presentasjonen og viktigheten av oppgaven.

Lange konklusjoner og hva så.

Det kan virke som tonen i artikkelen er litt pessimistisk. Det er ikke tilfellet. To grunnleggende nivåer av tilbakemelding, nemlig tester og parprogrammering, fungerer. Ikke like perfekt som i tradisjonell utvikling, men den positive effekten er der.

Tester, i sin nåværende form, gir bare delvis dekning av koden. Mange konfigurasjonsfunksjoner viser seg å være upåvirket. Deres innvirkning på det direkte arbeidet ved skriving av kode er lav. Men effekten av integrasjonstester er der, og det er disse som tillater oss å gjennomføre refaktoreringer uten frykt. Dette er en stor prestasjon. Også med skiftet fokus mot utvikling i høyere programmeringsspråk (vi bruker Python, Go) forsvinner problemet. Man trenger ikke mange sjekker på 'limet', det holder med generell integrasjon.

Pararbeid er mer avhengig av de spesifikke menneskene. Det er faktoren av oppgaven og våre myke ferdigheter. Med noen fungerer det veldig bra, med andre mindre bra. Det er definitivt en fordel. Det er klart at selv ved utilstrekkelig overholdelse av reglene for pararbeid, påvirker det positive resultatet kvaliteten. Personlig synes jeg det er enklere og hyggeligere å jobbe i par.

Mer høy-nivå måter å påvirke OS – planlegging og arbeid med oppgaver gir absolutt resultater: kvalitetsutveksling av kunnskap og forbedring av utviklingskvalitet.