🥇Infrastruktur som kod: Hur man löser problem med XP

Hej, Habr! Tidigare klagade jag på livet i Infrastrukturen som kodparadigm och erbjöd inget för att lösa den nuvarande situationen. Idag är jag tillbaka för att berätta vilka tillvägagångssätt och metoder som hjälper dig att fly från förtvivlans avgrund och styra situationen i rätt riktning.

I en tidigare artikel "Infrastruktur som kod: första bekantskapen" Jag delade med mig av mina intryck av detta område, försökte reflektera över den aktuella situationen inom detta område och föreslog till och med att standardpraxis som alla utvecklare känner till kunde hjälpa. Det kan tyckas att det fanns många klagomål på livet, men det fanns inga förslag på en väg ut ur den nuvarande situationen.

Vilka vi är, var vi är och vilka problem vi har

Vi är för närvarande i Sre Onboarding Team, som består av sex programmerare och tre infrastrukturingenjörer. Vi försöker alla skriva infrastruktur som kod (IaC). Vi gör detta eftersom vi i grunden vet hur man skriver kod och har en historia av att vara utvecklare "över genomsnittet".

Vi har en uppsättning fördelar: en viss bakgrund, kunskap om praxis, förmågan att skriva kod, en vilja att lära sig nya saker.
Och det finns en hängande del, som också är ett minus: bristande kunskap om infrastrukturhårdvara.

Teknikstapeln vi använder i vår IaC.

Terraform för att skapa resurser.
Packare för sammansättning av bilder. Dessa är Windows, CentOS 7-bilder.
Jsonnet för att göra en kraftfull build i drone.io, samt för att generera packer json och våra terraform-moduler.
Azure.
Ansible när du förbereder bilder.
Python för extratjänster och provisioneringsskript.
Och allt detta i VSCode med plugins som delas mellan teammedlemmar.

Slutsats från min sista artikeln var så här: Jag försökte ingjuta (först av allt i mig själv) optimism, jag ville säga att vi kommer att prova de metoder och metoder som vi känner till för att hantera de svårigheter och komplexiteter som finns inom detta område.

Vi kämpar för närvarande med följande IaC-problem:

Ofullkomlighet av verktyg och medel för kodutveckling.
Långsam utbyggnad. Infrastruktur är en del av den verkliga världen, och den kan vara långsam.
Brist på tillvägagångssätt och praxis.
Vi är nya och vet inte så mycket.

Extreme programmering (XP) till undsättning

Alla utvecklare är bekanta med Extreme Programming (XP) och de metoder som ligger bakom det. Många av oss har arbetat med detta tillvägagångssätt, och det har varit framgångsrikt. Så varför inte använda de principer och praxis som anges där för att övervinna infrastrukturutmaningar? Vi bestämde oss för att ta detta tillvägagångssätt och se vad som händer.

Kontrollera tillämpligheten av XP-metoden för din branschHär är en beskrivning av miljön som XP är väl lämpad för, och hur den relaterar till oss:

1. Dynamiskt förändrade mjukvarukrav. Det stod klart för oss vad slutmålet var. Men detaljerna kan variera. Vi bestämmer själva vart vi behöver taxi, så kraven ändras med jämna mellanrum (främst av oss själva). Om vi tar SRE-teamet, som gör automatiseringen själv, och själva begränsar kraven och omfattningen av arbetet, så passar denna punkt bra.

2. Risker orsakade av tidsbundna projekt med ny teknik. Vi kan stöta på risker när vi använder vissa saker som är okända för oss. Och detta är 100% vårt fall. Hela vårt projekt var användningen av teknologier som vi inte var helt bekanta med. I allmänhet är detta ett konstant problem, eftersom... Det finns många nya tekniker som dyker upp inom infrastruktursektorn hela tiden.

3,4. Litet, samlokaliserat utökat utvecklingsteam. Den automatiserade tekniken du använder tillåter enhets- och funktionstester. Dessa två punkter passar oss inte riktigt. För det första är vi inte ett samordnat team, och för det andra är vi nio stycken, som kan betraktas som ett stort team. Även om, enligt vissa definitioner av ett "stort" team, är mycket 14+ personer.

Låt oss titta på några XP-metoder och hur de påverkar hastigheten och kvaliteten på feedback.

XP Feedback Loop Princip

Enligt min uppfattning är feedback svaret på frågan, gör jag rätt, ska vi dit? XP har ett gudomligt schema för detta: en tidsåterkopplingsslinga. Det intressanta är att ju lägre vi är, desto snabbare kan vi få OS att svara på nödvändiga frågor.

Detta är ett ganska intressant ämne för diskussion, att det i vår IT-bransch går att snabbt få ett OS. Föreställ dig hur smärtsamt det är att göra ett projekt i ett halvår och först då få reda på att det var ett misstag i början. Detta händer i design och i alla konstruktioner av komplexa system.

I vårt fall med IaC hjälper feedback oss. Jag kommer omedelbart att göra en liten justering av diagrammet ovan: releaseplanen har inte en månatlig cykel, utan sker flera gånger om dagen. Det finns några metoder kopplade till denna OS-cykel som vi kommer att titta på mer i detalj.

Viktigt: feedback kan vara en lösning på alla ovanstående problem. I kombination med XP-övningar kan det dra dig upp ur förtvivlans avgrund.

Hur man tar sig upp ur förtvivlans avgrund: tre övningar

Tester

Tester nämns två gånger i XP-feedbackslingan. Det är inte bara så. De är extremt viktiga för hela extremprogrammeringstekniken.

Det förutsätts att du har enhets- och acceptanstest. Vissa ger dig feedback på några minuter, andra på några dagar, så de tar längre tid att skriva och recenseras mer sällan.

Det finns en klassisk testpyramid, som visar att det borde finnas fler tester.

Hur gäller detta ramverk för oss i ett IaC-projekt? Egentligen... inte alls.

Enhetstester kan, trots att det borde finnas många, inte bli för många. Eller så testar de något väldigt indirekt. Vi kan faktiskt säga att vi inte skriver dem alls. Men här är några applikationer för sådana tester som vi kunde göra:
1. Testar jsonnet-koden. Det här är till exempel vår drönarrörledning, som är ganska komplicerad. Jsonnet-koden täcks väl av tester.
  Vi använder detta Enhetstestramverk för Jsonnet.
2. Testar för skript som körs när resursen startar. Skript skrivs i Python, och därför kan test skrivas på dem.
Det är potentiellt möjligt att kontrollera konfigurationen i tester, men det gör vi inte. Det är också möjligt att konfigurera regler för kontrollresurskonfiguration via tflint. Dock är kontrollerna där helt enkelt för grundläggande för terraform, men många testskript är skrivna för AWS. Och vi är på Azure, så det här gäller inte igen.
Komponentintegreringstester: det beror på hur du klassificerar dem och var du placerar dem. Men de fungerar i princip.
Så här ser integrationstester ut.

Detta är ett exempel när man bygger bilder i Drone CI. För att nå dem måste du vänta 30 minuter tills Packer-bilden bildas och sedan vänta ytterligare 15 minuter för att de ska passera. Men de finns!
Bildverifieringsalgoritm
1. Packer måste först förbereda bilden helt.
2. Bredvid testet finns en terraform med en lokal stat, som vi använder för att distribuera den här bilden.
3. Vid utfällning används en liten modul som ligger i närheten för att göra det lättare att arbeta med bilden.
4. När den virtuella datorn har distribuerats från bilden kan kontroller påbörjas. I princip utförs kontroller med bil. Den kontrollerar hur skripten fungerade vid start och hur demonerna fungerar. För att göra detta loggar vi via ssh eller winrm in på den nyligen upphöjda maskinen och kontrollerar konfigurationsstatus eller om tjänsterna är uppe.
Situationen är liknande med integrationstester i moduler för terraform. Här är en kort tabell som förklarar funktionerna i sådana tester.

Feedback på pipeline är cirka 40 minuter. Allt händer under väldigt lång tid. Det kan användas för regression, men för nyutveckling är det i allmänhet orealistiskt. Om du är väldigt, väldigt förberedd på detta, förbered körande skript, då kan du minska det till 10 minuter. Men dessa är fortfarande inte enhetstester, som gör 5 stycken på 100 sekunder.

Frånvaron av enhetstester vid sammansättning av bilder eller terraform-moduler uppmuntrar till att flytta arbetet till separata tjänster som helt enkelt kan köras via REST, eller till Python-skript.

Vi behövde till exempel se till att när den virtuella maskinen startar registrerar den sig själv i tjänsten ScaleFT, och när den virtuella maskinen förstördes tog den bort sig själv.

Eftersom vi har ScaleFT som tjänst är vi tvungna att arbeta med den via API:et. Det stod ett omslag skrivet där som man kunde dra och säga: "Gå in och radera det och det." Den lagrar alla nödvändiga inställningar och åtkomster.

Vi kan redan skriva normala tester för detta, eftersom det inte skiljer sig från vanlig programvara: någon form av apiha hånas, du drar den och ser vad som händer.

Resultat av testerna: Enhetstestning, som borde ge OS på en minut, ger det inte. Och typer av tester högre upp i pyramiden är effektiva, men täcker bara en del av problemen.

Parprogrammering

Tester är förstås bra. Du kan skriva många av dem, de kan vara av olika slag. De kommer att arbeta på sina nivåer och ge oss feedback. Men problemet med dåliga enhetstester, som ger det snabbaste operativsystemet, kvarstår. Samtidigt vill jag fortfarande ha ett snabbt OS som är lätt och trevligt att arbeta med. För att inte tala om kvaliteten på den resulterande lösningen. Lyckligtvis finns det tekniker som kan ge ännu snabbare återkoppling än enhetstester. Detta är parprogrammering.

När du skriver kod vill du få feedback på dess kvalitet så snabbt som möjligt. Ja, du kan skriva allt i en funktionsgren (för att inte bryta något för någon), göra en pull-förfrågan i Github, tilldela den till någon vars åsikt har vikt och vänta på svar.

Men du kan vänta länge. Människor är alla upptagna, och svaret, även om det finns ett, kanske inte är av högsta kvalitet. Anta att svaret kom direkt, recensenten förstod omedelbart hela idén, men svaret kommer fortfarande sent, i efterhand. Jag önskar att det var tidigare. Det är detta som parprogrammering syftar till – direkt, i skrivande stund.

Nedan är parprogrammeringsstilarna och deras tillämpbarhet vid arbete med IaC:

1. Klassisk, Erfaren+Erfaren, skift för timer. Två roller – förare och navigatör. Två personer. De arbetar på samma kod och byter roller efter en viss förutbestämd tidsperiod.

Låt oss överväga kompatibiliteten för våra problem med stil:

Problem: ofullkomlighet i verktyg och verktyg för kodutveckling.
Negativ påverkan: det tar längre tid att utvecklas, vi saktar ner, takten/rytmen i arbetet tappas.
Hur vi kämpar: vi använder ett annat verktyg, en gemensam IDE och lär oss också genvägar.
Problem: Långsam distribution.
Negativ effekt: ökar tiden det tar att skapa en fungerande kod. Vi blir uttråkade medan vi väntar, händerna sträcker sig ut för att göra något annat medan vi väntar.
Hur vi slåss: vi övervann det inte.
Problem: brist på tillvägagångssätt och praxis.
Negativ påverkan: det finns ingen kunskap om hur man gör det bra och hur man gör det dåligt. Förlänger mottagandet av feedback.
Hur vi kämpar: ömsesidigt utbyte av åsikter och metoder i pararbete löser nästan problemet.

Det största problemet med att använda denna stil i IaC är den ojämna arbetstakten. I traditionell mjukvaruutveckling har man en väldigt enhetlig rörelse. Du kan spendera fem minuter och skriva N. Spendera 10 minuter och skriv 2N, 15 minuter - 3N. Här kan du spendera fem minuter och skriva N, och sedan spendera ytterligare 30 minuter och skriva en tiondel av N. Här vet du ingenting, du har fastnat, dum. Utredningen tar tid och distraherar från själva programmeringen.

Slutsats: i sin rena form är den inte lämplig för oss.

2. Ping-pong. Detta tillvägagångssätt innebär att en person skriver testet och en annan gör implementeringen för det. Med tanke på att allt är komplicerat med Unit-tester, och du måste skriva ett integrationstest som tar lång tid att programmera, försvinner all lätthet med pingis.

Jag kan säga att vi försökte separera ansvar för att designa ett testskript och implementera kod för det. En deltagare kom på manuset, i den här delen av arbetet var han ansvarig, han hade sista ordet. Och den andra ansvarade för genomförandet. Det gick bra. Kvaliteten på manuset med detta tillvägagångssätt ökar.

Slutsats: tyvärr tillåter inte arbetstakten användningen av pingis som parprogrammering i IaC.

3. Stark stil. Svår övning. Tanken är att en deltagare blir direktivnavigator och den andra tar rollen som avrättningsförare. I detta fall åvilar rätten att fatta beslut uteslutande navigatören. Föraren skriver bara ut och kan påverka vad som händer med ett ord. Rollerna förändras inte på länge.

Bra för att lära, men kräver starka mjuka färdigheter. Det var här vi vacklade. Tekniken var svår. Och det handlar inte ens om infrastruktur.

Slutsats: det kan potentiellt användas, vi ger inte upp att försöka.

4. Mobbing, svärmande och alla kända men inte listade stilar Vi anser det inte, eftersom Vi har inte provat det och det är omöjligt att prata om det i samband med vårt arbete.

Allmänna resultat om användning av parprogrammering:

Vi har en ojämn arbetstakt, vilket är förvirrande.

Vi stötte på otillräckligt bra mjuka färdigheter. Och ämnesområdet hjälper inte till att övervinna dessa brister hos oss.

Långa tester och problem med verktyg gör parad utveckling svår.

5. Trots detta blev det framgångar. Vi kom på vår egen metod "Convergence - Divergence". Jag ska kort beskriva hur det fungerar.

Vi har fasta partners under några dagar (mindre än en vecka). Vi gör en uppgift tillsammans. Vi sitter tillsammans en stund: en skriver, den andre sitter och tittar på supportteamet. Sedan skingras vi under en tid, var och en gör några oberoende saker, sedan kommer vi samman igen, synkroniserar väldigt snabbt, gör något tillsammans och skingras igen.

Planering och kommunikation

Det sista blocket av praxis genom vilket OS-problem löses är organisationen av arbetet med själva uppgifterna. Detta inkluderar även erfarenhetsutbyte som ligger utanför pararbete. Låt oss titta på tre metoder:

1. Mål genom målträdet. Vi organiserade den övergripande ledningen av projektet genom ett träd som går oändligt in i framtiden. Tekniskt sett görs spårningen i Miro. Det finns en uppgift - det är ett delmål. Från det går antingen mindre mål eller grupper av uppgifter. Själva uppgifterna kommer från dem. Alla uppgifter skapas och underhålls på denna tavla.

Det här schemat ger också feedback, vilket sker en gång om dagen när vi synkroniserar på rallyn. Att ha en gemensam plan inför alla, men strukturerad och helt öppen, gör att alla kan vara medvetna om vad som händer och hur långt vi kommit.

Fördelar med visuell syn på uppgifter:

Kausalitet. Varje uppgift leder till något globalt mål. Uppgifterna grupperas i mindre mål. Infrastrukturdomänen i sig är ganska teknisk. Det är inte alltid omedelbart klart vilken specifik påverkan, till exempel att skriva en runbook vid migrering till en annan nginx, har på verksamheten. Att ha målkortet i närheten gör det tydligare.

Kausalitet är en viktig egenskap hos problem. Det svarar direkt på frågan: "Gör jag rätt?"
Parallellism. Vi är nio, och det är helt enkelt fysiskt omöjligt att kasta alla på en uppgift. Uppgifter från ett område kanske inte heller alltid räcker. Vi tvingas parallellisera arbetet mellan små arbetsgrupper. Samtidigt sitter grupperna på sin uppgift en tid, de kan förstärkas av någon annan. Ibland faller människor bort från denna arbetsgrupp. Någon åker på semester, någon gör en rapport för DevOps-konferensen, någon skriver en artikel om Habr. Att veta vilka mål och uppgifter som kan göras parallellt blir väldigt viktigt.

2. Ersättande föredragshållare av morgonmöten. På stand-ups har vi det här problemet – människor gör många uppgifter parallellt. Ibland är uppgifter löst sammankopplade och det finns ingen förståelse för vem som gör vad. Och åsikten från en annan lagmedlem är mycket viktig. Detta är ytterligare information som kan förändra hur problemet ska lösas. Självklart brukar det vara någon med dig, men råd och tips är alltid användbara.

För att förbättra denna situation använde vi tekniken "Changing the Leading Stand-Up". Nu roteras de enligt en viss lista, och det har sin effekt. När det är din tur tvingas du dyka in och förstå vad som händer för att kunna köra ett bra Scrum-möte.

3. Intern demo. Hjälp med att lösa ett problem från parprogrammering, visualisering på problemträdet och hjälp vid scrummöten på morgonen är bra, men inte idealiskt. Som ett par begränsas ni bara av er kunskap. Uppgiftsträdet hjälper till att globalt förstå vem som gör vad. Och presentatören och kollegorna på morgonmötet kommer inte att dyka djupt in i dina problem. De kanske missar något.

Lösningen fann man genom att demonstrera det utförda arbetet för varandra och sedan diskutera det. Vi träffas en gång i veckan under en timme och visar detaljer om lösningar på uppgifter vi gjort den senaste veckan.

Under demonstrationen är det nödvändigt att avslöja detaljerna i uppgiften och se till att demonstrera dess funktion.

Rapporten kan göras med hjälp av en checklista.1. Gå in i sammanhanget. Var kom uppdraget ifrån, varför var det ens nödvändigt?

2. Hur löstes problemet innan? Till exempel krävdes massiva musklick, eller så var det omöjligt att göra någonting alls.

3. Hur vi förbättrar det. Till exempel: "Titta, nu finns det scriptosik, här är readme."

4. Visa hur det fungerar. Det är tillrådligt att direkt implementera något användarscenario. Jag vill ha X, jag gör Y, jag ser Y (eller Z). Till exempel distribuerar jag NGINX, röker webbadressen och får 200 OK. Om åtgärden är lång, förbered den i förväg så att du kan visa den senare. Det är tillrådligt att inte bryta det för mycket en timme före demot, om det är ömtåligt.

5. Förklara hur framgångsrikt problemet löstes, vilka svårigheter kvarstår, vad som inte är slutfört, vilka förbättringar som är möjliga i framtiden. Till exempel nu CLI, då blir det full automatisering i CI.

Det är lämpligt för varje högtalare att hålla det till 5-10 minuter. Om ditt tal uppenbarligen är viktigt och kommer att ta längre tid, samordna detta i förväg i sre-takeover-kanalen.

Efter öga mot öga-delen är det alltid en diskussion i tråden. Det är här den feedback vi behöver på våra uppgifter visas.

Som ett resultat görs en undersökning för att fastställa nyttan av det som händer. Detta är feedback på talets kärna och uppgiftens betydelse.

Långa slutsatser och vad som händer härnäst

Det kan tyckas att tonen i artikeln är något pessimistisk. Detta är fel. Två lägre nivåer av feedback, nämligen tester och parprogrammering, fungerar. Inte lika perfekt som i traditionell utveckling, men det finns en positiv effekt av det.

Tester, i sin nuvarande form, ger endast delvis kodtäckning. Många konfigurationsfunktioner hamnar oprövade. Deras inflytande på själva arbetet när man skriver kod är lågt. Det finns dock en effekt från integrationstester, och de låter dig oförskräckt utföra omfaktoreringar. Detta är en stor prestation. Dessutom, med förskjutningen av fokus till utveckling på högnivåspråk (vi har python, go), försvinner problemet. Och du behöver inte många kontroller för "limmet"; en allmän integrationskontroll räcker.

Att arbeta i par beror mer på specifika personer. Där finns uppgiftsfaktorn och våra mjuka färdigheter. Med vissa människor fungerar det mycket bra, med andra fungerar det sämre. Det finns definitivt fördelar med detta. Det är tydligt att även om reglerna för pararbete inte följs tillräckligt, har själva det faktum att man utför uppgifter tillsammans en positiv effekt på kvaliteten på resultatet. Personligen tycker jag att det är lättare och roligare att arbeta i par.

Sätt på högre nivå att påverka OS - planering och arbete med uppgifter ger precis effekter: högkvalitativt kunskapsutbyte och förbättrad utvecklingskvalitet.