Infrastruktur som kode: hvordan man overvinder problemer ved hjælp af XP

Hej, Habr! Tidligere klagede jeg over livet i Infrastrukturen som kodeparadigme og tilbød ikke noget til at løse den aktuelle situation. I dag er jeg tilbage for at fortælle dig, hvilke tilgange og praksis der vil hjælpe dig med at flygte fra fortvivlelsens afgrund og styre situationen i den rigtige retning.

I en tidligere artikel "Infrastruktur som kode: første bekendtskab" Jeg delte mine indtryk af dette område, forsøgte at reflektere over den aktuelle situation på dette område og foreslog endda, at standardpraksis kendt af alle udviklere kunne hjælpe. Det kunne se ud til, at der var mange klager over livet, men der var ingen forslag til en vej ud af den nuværende situation.

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

Vi er i øjeblikket i Sre Onboarding Team, som består af seks programmører og tre infrastrukturingeniører. Vi forsøger alle at skrive Infrastruktur som kode (IaC). Vi gør dette, fordi vi grundlæggende ved, hvordan man skriver kode og har en historie med at være "over gennemsnittet" udviklere.

• Vi har en række fordele: en vis baggrund, viden om praksis, evnen til at skrive kode, et ønske om at lære nyt.
• Og der er en hængende del, som også er et minus: mangel på viden om infrastruktur hardware.

Teknologistakken bruger vi i vores IaC.

• Terraform til at skabe ressourcer.
• Pakker til samling af billeder. Disse er Windows, CentOS 7 billeder.
• Jsonnet til at lave en kraftfuld build i drone.io, samt til at generere packer json og vores terraform-moduler.
• Azure.
• Ansible ved forberedelse af billeder.
• Python til hjælpetjenester og leveringsscripts.
• Og alt dette i VSCode med plugins, der deles mellem teammedlemmer.

Konklusion fra min sidste artikel var sådan her: Jeg forsøgte at indgyde (først og fremmest i mig selv) optimisme, jeg ville sige, at vi vil prøve de tilgange og praksis, vi kender, for at håndtere de vanskeligheder og kompleksiteter, der findes på dette område.

Vi kæmper i øjeblikket med følgende IaC-problemer:

• Ufuldkommenhed af værktøjer og midler til kodeudvikling.
• Langsom implementering. Infrastruktur er en del af den virkelige verden, og den kan være langsom.
• Mangel på tilgange og praksis.
• Vi er nye og ved ikke meget.

Ekstrem programmering (XP) til undsætning

Alle udviklere er bekendt med Extreme Programming (XP) og den praksis, der ligger bag det. Mange af os har arbejdet med denne tilgang, og den har været en succes. Så hvorfor ikke bruge de principper og praksis, der er fastlagt der, til at overvinde infrastrukturudfordringer? Vi besluttede at tage denne tilgang og se, hvad der sker.

Kontrol af anvendeligheden af ​​XP-tilgangen til din brancheHer er en beskrivelse af det miljø, som XP er velegnet til, og hvordan det forholder sig til os:

1. Dynamisk skiftende softwarekrav. Det stod klart for os, hvad slutmålet var. Men detaljerne kan variere. Vi bestemmer selv, hvor vi skal taxa, så kravene ændrer sig med jævne mellemrum (hovedsageligt af os selv). Hvis vi tager SRE-teamet, som selv laver automatiseringen, og selv begrænser kravene og arbejdets omfang, så passer dette punkt godt.

2. Risici forårsaget af fasttidsprojekter ved brug af ny teknologi. Vi kan støde på risici, når vi bruger nogle ting, vi ikke kender. Og dette er 100% vores tilfælde. Hele vores projekt var brugen af ​​teknologier, som vi ikke var helt fortrolige med. Generelt er dette et konstant problem, fordi... Der dukker mange nye teknologier op i infrastruktursektoren hele tiden.

3,4. Lille, samlokaliseret udvidet udviklingsteam. Den automatiserede teknologi, du bruger, giver mulighed for enheds- og funktionstest. Disse to punkter passer ikke helt os. For det første er vi ikke et koordineret team, og for det andet er vi ni, som kan betragtes som et stort team. Selvom, ifølge nogle definitioner af et "stort" hold, er meget 14+ personer.

Lad os se på nogle XP-praksis, og hvordan de påvirker hastigheden og kvaliteten af ​​feedback.

XP Feedback Loop Princip

Efter min forståelse er feedback svaret på spørgsmålet, gør jeg det rigtige, skal vi derhen? XP har et guddommeligt skema til dette: en tidsfeedback loop. Det interessante er, at jo lavere vi er, jo hurtigere er vi i stand til at få OS til at besvare de nødvendige spørgsmål.

Dette er et ret interessant emne til diskussion, at i vores IT-branche er det muligt hurtigt at få et OS. Forestil dig, hvor smertefuldt det er at lave et projekt i seks måneder og først derefter finde ud af, at der var en fejl i begyndelsen. Dette sker i design og i enhver konstruktion af komplekse systemer.

I vores tilfælde af IaC hjælper feedback os. Jeg vil straks foretage en lille justering af diagrammet ovenfor: frigivelsesplanen har ikke en månedlig cyklus, men forekommer flere gange om dagen. Der er nogle praksisser knyttet til denne OS-cyklus, som vi vil se mere detaljeret på.

Vigtigt: feedback kan være en løsning på alle de ovenfor nævnte problemer. Kombineret med XP-øvelser kan det trække dig ud af fortvivlelsens afgrund.

Sådan trækker du dig selv ud af fortvivlelsens afgrund: tre øvelser

Tests

Tests nævnes to gange i XP feedback loop. Det er ikke bare sådan. De er ekstremt vigtige for hele den ekstreme programmeringsteknik.

Det forudsættes, at du har enheds- og accepttest. Nogle giver dig feedback på få minutter, andre på få dage, så de tager længere tid at skrive og bliver anmeldt sjældnere.

Der er en klassisk testpyramide, som viser, at der burde være flere tests.

Hvordan gælder denne ramme for os i et IaC-projekt? Faktisk... slet ikke.

• Enhedstests, på trods af at der burde være mange af dem, kan ikke være for mange. Eller de tester noget meget indirekte. Faktisk kan vi sige, at vi slet ikke skriver dem. Men her er et par applikationer til sådanne tests, som vi var i stand til at lave:
  1. Test af jsonnet-kode. Dette er for eksempel vores drone montage pipeline, som er ret kompliceret. Jsonnet-koden er godt dækket af tests.
     Vi bruger dette Enhedstestramme for Jsonnet.
  2. Tester for scripts, der udføres, når ressourcen starter. Scripts er skrevet i Python, og derfor kan der skrives test på dem.
• Det er potentielt muligt at tjekke konfigurationen i test, men det gør vi ikke. Det er også muligt at konfigurere kontrolressourcekonfigurationsregler via tflint. Men kontrollerne der er simpelthen for grundlæggende til terraform, men mange testscripts er skrevet til AWS. Og vi er på Azure, så dette gælder igen ikke.
• Komponentintegrationstest: det afhænger af, hvordan du klassificerer dem, og hvor du placerer dem. Men de virker i bund og grund.

  Sådan ser integrationstest ud.

  
  
  Dette er et eksempel ved opbygning af billeder i Drone CI. For at nå dem skal du vente 30 minutter på, at Packer-billedet dannes, og derefter vente yderligere 15 minutter, før de passerer. Men de findes!

  Billedbekræftelsesalgoritme

  1. Packer skal først forberede billedet fuldstændigt.
  2. Ved siden af ​​testen er der en terraform med en lokal stat, som vi bruger til at implementere dette billede.
  3. Ved udfoldning bruges et lille modul, der ligger i nærheden, for at gøre det nemmere at arbejde med billedet.
  4. Når VM'en er implementeret fra billedet, kan tjek begynde. Som udgangspunkt udføres kontrol i bil. Det tjekker, hvordan scripts fungerede ved opstart, og hvordan dæmonerne fungerer. For at gøre dette logger vi via ssh eller winrm ind på den nyligt hævede maskine og tjekker konfigurationsstatus eller om tjenesterne er oppe.

• Situationen er den samme med integrationstest i moduler til terraform. Her er en kort tabel, der forklarer funktionerne i sådanne tests.

  
  
  Feedback på pipeline er omkring 40 minutter. Alt sker i meget lang tid. Det kan bruges til regression, men til nyudvikling er det generelt urealistisk. Hvis du er meget, meget forberedt på dette, skal du forberede kørende scripts, så kan du reducere det til 10 minutter. Men det er stadig ikke enhedstest, som laver 5 stykker på 100 sekunder.

Fraværet af enhedstests ved samling af billeder eller terraform-moduler tilskynder til at flytte arbejdet til separate tjenester, der blot kan køres via REST eller til Python-scripts.

For eksempel skulle vi sikre os, at når den virtuelle maskine starter, registrerer den sig selv i tjenesten ScaleFT, og da den virtuelle maskine blev ødelagt, slettede den sig selv.

Da vi har ScaleFT som en service, er vi tvunget til at arbejde med det gennem API'et. Der var skrevet en indpakning, som man kunne trække og sige: "Gå ind og slet det og det." Den gemmer alle de nødvendige indstillinger og adgange.

Vi kan allerede skrive normale tests for dette, da det ikke adskiller sig fra almindelig software: en form for apiha bliver hånet, du trækker den og ser, hvad der sker.

Resultater af testene: Enhedstest, som skulle give OS på et minut, giver det ikke. Og typer af test højere i pyramiden er effektive, men dækker kun en del af problemerne.

Par programmering

Tests er selvfølgelig gode. Du kan skrive mange af dem, de kan være af forskellige typer. De vil arbejde på deres niveauer og give os feedback. Men problemet med dårlige Unit-tests, som giver det hurtigste OS, består. Samtidig vil jeg stadig gerne have et hurtigt OS, der er nemt og behageligt at arbejde med. For ikke at nævne kvaliteten af ​​den resulterende løsning. Heldigvis er der teknikker, der kan give endnu hurtigere feedback end enhedstests. Dette er parprogrammering.

Når du skriver kode, vil du gerne have feedback på dens kvalitet så hurtigt som muligt. Ja, du kan skrive alt i en feature-gren (for ikke at ødelægge noget for nogen), lave en pull-anmodning i Github, tildele den til en person, hvis mening har vægt, og vente på et svar.

Men du kan vente længe. Folk har alle travlt, og svaret, selvom der er et, er måske ikke af højeste kvalitet. Antag, at svaret kom med det samme, anmelderen forstod øjeblikkeligt hele ideen, men svaret kommer stadig sent, bagefter. Jeg ville ønske, det var tidligere. Det er, hvad parprogrammering er rettet mod – med det samme, i skrivende stund.

Nedenfor er parprogrammeringsstilene og deres anvendelighed i arbejdet med IaC:

1. Klassisk, Erfaren+Erfaren, skift efter timer. To roller - chauffør og navigatør. To personer. De arbejder på den samme kode og skifter roller efter en bestemt forudbestemt tidsperiode.

Lad os overveje kompatibiliteten af ​​vores problemer med stil:

• Problem: ufuldkommenhed af værktøjer og værktøjer til kodeudvikling.
  Negativ påvirkning: det tager længere tid at udvikle sig, vi bremser, tempoet/rytmen i arbejdet går tabt.
  Sådan kæmper vi: Vi bruger et andet værktøj, en fælles IDE og lærer også genveje.
• Problem: Langsom implementering.
  Negativ indvirkning: øger den tid, det tager at skabe et fungerende stykke kode. Vi keder os, mens vi venter, vores hænder rækker ud for at gøre noget andet, mens vi venter.
  Hvordan vi kæmper: vi overvandt det ikke.
• Problem: mangel på tilgange og praksis.
  Negativ indvirkning: der er ingen viden om, hvordan man gør det godt, og hvordan man gør det dårligt. Forlænger modtagelsen af ​​feedback.
  Sådan kæmper vi: gensidig udveksling af meninger og praksis i pararbejde løser næsten problemet.

Hovedproblemet ved at bruge denne stil i IaC er det ujævne arbejdstempo. I traditionel softwareudvikling har man en meget ensartet bevægelse. Du kan bruge fem minutter og skrive N. Brug 10 minutter og skriv 2N, 15 minutter - 3N. Her kan du bruge fem minutter og skrive N, og så bruge yderligere 30 minutter og skrive en tiendedel af N. Her ved du ikke noget, du sidder fast, dum. Undersøgelsen tager tid og distraherer fra selve programmeringen.

Konklusion: i sin rene form er den ikke egnet til os.

2. Ping-pong. Denne tilgang involverer en person, der skriver testen, og en anden udfører implementeringen for den. Tager man i betragtning, at alt er kompliceret med Unit-tests, og man skal skrive en integrationstest, der tager lang tid at programmere, forsvinder al letheden ved ping-pong.

Jeg kan sige, at vi prøvede at adskille ansvar for at designe et testscript og implementere kode til det. En deltager kom med manuskriptet, i denne del af arbejdet var han ansvarlig, han havde det sidste ord. Og den anden stod for implementeringen. Det lykkedes godt. Kvaliteten af ​​scriptet med denne tilgang øges.

Konklusion: desværre tillader arbejdstempoet ikke brugen af ​​ping-pong som parprogrammeringspraksis i IaC.

3. Stærk stil. Svær praksis. Tanken er, at den ene deltager bliver direktivnavigator, og den anden tager rollen som henrettelsesføreren. I dette tilfælde påhviler retten til at træffe beslutninger udelukkende navigatøren. Chaufføren udskriver kun og kan påvirke, hvad der sker med et ord. Rollerne ændres ikke i lang tid.

God til at lære, men kræver stærke bløde færdigheder. Det var her, vi vaklede. Teknikken var svær. Og det handler ikke engang om infrastruktur.

Konklusion: det kan potentielt bruges, vi giver ikke op med at prøve.

4. Mobbing, sværmeri og alle kendte, men ikke listede stilarter Vi overvejer det ikke, pga Vi har ikke prøvet det, og det er umuligt at tale om det i forbindelse med vores arbejde.

Generelle resultater om brug af parprogrammering:

• Vi har et ujævnt arbejdstempo, hvilket er forvirrende.
• Vi løb ind i utilstrækkeligt gode bløde færdigheder. Og fagområdet hjælper ikke med at overvinde disse mangler hos os.
• Lange test og problemer med værktøjer gør parret udvikling vanskelig.

5. På trods af dette var der succeser. Vi fandt på vores egen metode "Konvergens - Divergens". Jeg vil kort beskrive, hvordan det fungerer.

Vi har faste partnere i et par dage (mindre end en uge). Vi laver én opgave sammen. Vi sidder sammen et stykke tid: den ene skriver, den anden sidder og ser på supportteamet. Så spredes vi i nogen tid, hver gør nogle selvstændige ting, så kommer vi sammen igen, synkroniserer meget hurtigt, gør noget sammen og spreder os igen.

Planlægning og kommunikation

Den sidste blok af praksis, hvorigennem OS-problemer løses, er tilrettelæggelsen af ​​arbejdet med selve opgaverne. Dette omfatter også erfaringsudveksling, der ligger uden for pararbejde. Lad os se på tre praksisser:

1. Mål gennem måltræet. Vi organiserede den overordnede ledelse af projektet gennem et træ, der går uendeligt ind i fremtiden. Teknisk set foregår sporingen i Miro. Der er én opgave – det er et delmål. Derfra går enten mindre mål eller grupper af opgaver. Selve opgaverne kommer fra dem. Alle opgaver oprettes og vedligeholdes på denne tavle.

Denne ordning giver også feedback, som sker en gang om dagen, når vi synkroniserer ved stævner. At have en fælles plan foran alle, men struktureret og fuldstændig åben, giver alle mulighed for at være opmærksomme på, hvad der sker, og hvor langt vi er nået.

Fordele ved visuel vision af opgaver:

• Kausalitet. Hver opgave fører til et eller andet globalt mål. Opgaverne er grupperet i mindre mål. Selve infrastrukturdomænet er ret teknisk. Det er ikke altid umiddelbart klart, hvilken specifik indflydelse, for eksempel at skrive en runbook om migrering til en anden nginx, har på virksomheden. At have målkortet i nærheden gør det tydeligere.
  
  Kausalitet er en vigtig egenskab ved problemer. Det svarer direkte på spørgsmålet: "Gør jeg det rigtige?"
• Parallelisme. Vi er ni, og det er simpelthen fysisk umuligt at kaste alle på én opgave. Opgaver fra ét område er måske heller ikke altid nok. Vi er tvunget til at parallelisere arbejdet mellem små arbejdsgrupper. Samtidig sidder grupperne på deres opgave i nogen tid, de kan blive forstærket af en anden. Nogle gange falder folk væk fra denne arbejdsgruppe. Nogen tager på ferie, nogen laver en rapport til DevOps-konferencen, nogen skriver en artikel om Habr. At vide, hvilke mål og opgaver der kan udføres parallelt, bliver meget vigtigt.

2. Afløser oplægsholdere af morgenmøder. Hos stand-ups har vi dette problem - folk laver mange opgaver sideløbende. Nogle gange hænger opgaver løst sammen, og der er ingen forståelse for, hvem der gør hvad. Og et andet teammedlems mening er meget vigtig. Dette er yderligere information, der kan ændre processen med at løse problemet. Selvfølgelig er der normalt nogen med dig, men råd og tips er altid nyttige.

For at forbedre denne situation brugte vi "Changing the Leading Stand-Up"-teknikken. Nu roteres de efter en bestemt liste, og det har sin effekt. Når det er din tur, er du tvunget til at dykke ned og forstå, hvad der foregår, for at afholde et godt Scrum-møde.

3. Intern demo. Hjælp til at løse et problem fra parprogrammering, visualisering på problemtræet og hjælp til scrummøder om morgenen er godt, men ikke ideelt. Som et par er I kun begrænset af jeres viden. Opgavetræet hjælper til globalt at forstå, hvem der gør hvad. Og oplægsholderen og kollegerne på morgenmødet vil ikke dykke dybt ned i dine problemer. De kan helt sikkert gå glip af noget.

Løsningen blev fundet ved at demonstrere det udførte arbejde for hinanden og derefter diskutere det. Vi mødes en gang om ugen i en time og viser detaljer om løsninger på opgaver, vi har udført den seneste uge.

Under demonstrationen er det nødvendigt at afsløre detaljerne i opgaven og være sikker på at demonstrere dens drift.

Rapporten kan udføres ved hjælp af en tjekliste.1. Gå ind i kontekst. Hvor kom opgaven fra, hvorfor var den overhovedet nødvendig?

2. Hvordan blev problemet løst før? For eksempel krævedes massive museklik, eller det var umuligt at gøre noget overhovedet.

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

4. Vis hvordan det virker. Det er tilrådeligt at implementere nogle brugerscenarier direkte. Jeg vil have X, jeg vil Y, jeg ser Y (eller Z). For eksempel installerer jeg NGINX, ryger url'en og får 200 OK. Hvis handlingen er lang, skal du forberede den på forhånd, så du kan vise den senere. Det er tilrådeligt ikke at bryde det for meget en time før demoen, hvis det er skrøbeligt.

5. Forklar, hvor vellykket problemet blev løst, hvilke vanskeligheder der er tilbage, hvad der ikke er afsluttet, hvilke forbedringer der er mulige i fremtiden. For eksempel nu CLI, så vil der være fuld automatisering i CI.

Det er tilrådeligt for hver højttaler at holde det til 5-10 minutter. Hvis din tale åbenlyst er vigtig og vil tage længere tid, så koordiner dette på forhånd i sre-takeover-kanalen.

Efter face-to-face-delen er der altid en diskussion i tråden. Det er her den feedback, vi har brug for på vores opgaver, dukker op.

Som et resultat bliver der gennemført en undersøgelse for at fastslå nytten af ​​det, der sker. Dette er feedback på essensen af ​​talen og vigtigheden af ​​opgaven.

Lange konklusioner og hvad er det næste

Det kan virke som om tonen i artiklen er noget pessimistisk. Det er forkert. To lavere niveauer af feedback, nemlig tests og parprogrammering, fungerer. Ikke så perfekt som i traditionel udvikling, men der er en positiv effekt af det.

Tests i deres nuværende form giver kun delvis kodedækning. Mange konfigurationsfunktioner ender utestede. Deres indflydelse på det faktiske arbejde, når de skriver kode, er lav. Der er dog en effekt af integrationstest, og de giver dig mulighed for frygtløst at udføre refactorings. Dette er en stor præstation. Også med skiftet af fokus til udvikling i sprog på højt niveau (vi har python, go), forsvinder problemet. Og du behøver ikke mange tjek for "limen"; et generelt integrationstjek er nok.

At arbejde i par afhænger mere af specifikke personer. Der er opgavefaktoren og vores bløde færdigheder. Hos nogle mennesker fungerer det meget godt, med andre fungerer det værre. Det er der helt sikkert fordele ved. Det er klart, at selvom reglerne for pararbejde ikke overholdes tilstrækkeligt, har selve det at udføre opgaver sammen en positiv effekt på kvaliteten af ​​resultatet. Personligt synes jeg det er nemmere og sjovere at arbejde i par.

Måder på højere niveau at påvirke OS - planlægning og arbejde med opgaver giver præcist effekter: højkvalitetsvidenudveksling og forbedret udviklingskvalitet.

Korte konklusioner på én linje

• HR-praktikere arbejder i IaC, men med mindre effektivitet.
• Styrk det, der virker.
• Kom med dine egne kompenserende mekanismer og praksis.

Kilde: www.habr.com