Infrastructure as Code: hur man övervinner problem med hjälp av XP

Hej, Habr! Tidigare klagade jag på livet i paradigmet Infrastructure as code och föreslog inget för att lösa situationen. Idag är jag tillbaka för att berätta om de metoder och praxis som kan hjälpa oss att bryta oss ur avgrunden av förtvivlan och leda situationen i rätt riktning.

I den föregående artikeln «Infrastructure as code: en första bekantskap» delade jag mina intryck av detta område, försökte reflektera över den aktuella situationen och till och med föreslog att standardpraxis som alla utvecklare känner till kan hjälpa. Det kan ha verkat som att det fanns mycket klagande på livet, men inga förslag för att ta sig ur den situationen.

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

Just nu befinner vi oss i SRE Onboarding Team, som består av sex programmerare och tre infrastrukturingenjörer. Vi försöker alla skriva Infrastructure as code (IaC). Vi gör det eftersom vi generellt kan skriva kod och alla har erfarenhet som utvecklare på "över medelnivå".

• Vi har en uppsättning fördelar: en viss bakgrund, kunskaper om praxis, förmåga att skriva kod och en vilja att lära oss nya saker.
• Och det finns en svag punkt, det vill säga en nackdel: bristande kunskaper om den tekniska grunden för infrastrukturen.

Teknologiska stackar som vi använder i vår IaC.

• Terraform för att skapa resurser.
• Packer för att bygga bilder. Detta inkluderar Windows och CentOS 7-bilder.
• Jsonnet, för att göra kraftfulla byggen i drone.io, samt för att generera packer json och våra Terraform-moduler.
• Azure.
• Ansible vid skapande av bilder.
• Python för hjälptjänster samt provisioning-skript.
• Och allt detta i VSCode med tillägg som delas mellan teammedlemmarna.

Slutsatsen av min tidigare artikel var sådan: jag försökte inge (främst mig själv) optimisme, ville säga att vi kommer att prova de metoder och praxis som vi känner till för att kämpa mot svårigheterna och utmaningarna i detta område.

Just nu kämpar vi med följande problem i IaC:

• Imperfektion i verktyg, utvecklingsmedel.
• Långsam distribueringsprocess. Infrastruktur är en del av den verkliga världen, vilket kan ta tid.
• Brist på metoder och praxis.
• Vi är nya och vet inte mycket.

Extremprogrammering (XP) kommer till undsättning

Alla utvecklare känner väl till extrem programmering (XP) och de metoder som ligger bakom. Många av oss har arbetat enligt denna metodik och den har varit framgångsrik. Så varför inte använda principerna och metoderna som finns där för att övervinna infrastruktursutmaningar? Vi har beslutat att tillämpa detta tillvägagångssätt och se vad som händer.

Bedömning av tillämpbarheten av XP-metoden i er branschHär är en beskrivning av den miljö där XP passar bra, och hur det relaterar till oss:

1. Dynamiskt föränderliga mjukvarukrav. Vi visste vad det slutgiltiga målet var. Men detaljerna kan variera. Vi bestämmer själva hur vi ska navigera, så kraven förändras periodiskt (främst av oss själva). När det gäller SRE-teamet som själva gör automatiseringen och också begränsar krav och arbetsomfattning, så passa det här punkt bra.

2. Risker orsakade av fasta tidsprojekt som använder ny teknologi. Vi kan möta risker när vi använder saker vi inte är bekanta med. Och det här är 100 % vårt fall. Hela vårt projekt handlar om att använda teknologier som vi inte var helt bekanta med. Det är generellt ett konstant problem, eftersom många nya teknologier ständigt dyker upp inom infrastruktur.

3,4. Litet, samlokaliserat utvecklingsteam. Den teknik ni använder möjliggör automatiserade enhets- och funktionstest. Dessa två punkter passar oss inte riktigt. För det första är vi inte ett samlokaliserat team, för det andra är vi nio personer, vilket kan betraktas som ett stort team. Men enligt vissa definitioner av 'stort' team så är många 14+ personer.

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

Principen om feedbackcykeln i XP

I min förståelse är feedback svaret på frågan, gör jag rätt, är vi på väg åt rätt håll? I XP finns en fantastisk schema: tidscykeln för feedback. Det intressanta är att ju längre ner vi är i cykeln, desto snabbare får vi tillbaka en respons för att kunna svara på nödvändiga frågor.

Detta är ett ganska intressant ämne för diskussion, att vi inom IT-branschen snabbt kan få feedback. Tänk dig hur svårt det skulle vara att genomföra ett projekt i ett halvår och först då få reda på att det i början fanns ett fel. Sådant sker både inom design och i alla konstruktioner av komplexa system.

I det här fallet hjälper IaC oss med feedback. Jag gör en liten justering i schemat ovan: vår releaseplan har inte en månads cykel, utan sker flera gånger per dag. Till denna cykel är vissa praktiker kopplade som vi kommer att titta närmare på.

Viktigt: feedback kan bli lösningen på alla ovan nämnda problem. Tillsammans med XP-praktiker kan den dra oss ur avgrunden av förtvivlan.

Hur man drar sig ur avgrunden av förtvivlan: tre praktiker

Tester

Tester nämns två gånger i XP:s feedbackcykel. Det är inte utan anledning. De är extremt viktiga för hela tekniken kring extrem programmering.

Det förutsätts att du har enhetstester och acceptanstester. Vissa ger dig feedback på några minuter, andra tar dagar att skriva och körs mindre ofta.

Det finns en klassisk testpyramid som visar att vissa tester bör vara fler.

Hur är denna skema tillämplig på vårt IaC-projekt? Egentligen… inte alls.

• Enhetstester, trots att det bör vara många av dem, kan inte vara för många. Antingen testar de något mycket indirekt. Faktiskt kan man säga att vi knappt skriver dem alls. Men här är några tillämpningar för sådana tester som vi faktiskt lyckats genomföra:
  1. Testning av koden på jsonnet. Detta är till exempel vår byggpipeline i drone, som är ganska komplex. Koden på jsonnet är väl täckt av tester.
     Vi använder detta Unit testing framework for Jsonnet.
  2. Tester på skript som körs när resursen startas. Skript i Python, och därmed kan tester skrivas för dem.
• Det är potentiellt möjligt att kontrollera konfigurationen i tester, men vi gör inte så. Det finns också möjlighet att ställa in kontroller av konfigureringsregler för resurser via tflint. Men för terraform är kontrollerna för grundläggande, och många testscenarier har skrivits för AWS. Vi har Azure, så det här passar inte heller.
• Komponentintegreringstester: här beror det på hur du klassificerar dem och var du placerar dem. Men de fungerar i grunden.

  Så här ser integreringstester ut.

  
  
  Detta är ett exempel på att bygga bilder i Drone CI. För att nå dem måste man vänta 30 minuter på att Packer-bilden ska byggas, och sedan ytterligare 15 minuter på att de ska genomföras. Men de finns!

  Algoritm för att kontrollera bilder

  1. Först måste Packer förbereda bilden helt.
  2. Bredvid testet finns det en Terraform med lokal status som vi använder för att distribuera bilden.
  3. Vid distributionen används en liten modulfiler som ligger bredvid för att underlätta arbetet med bilden.
  4. När en VM har distribuerats från bilden kan kontroller påbörjas. Kontrollerna utförs huvudsakligen på maskinen. Det kontrolleras hur skripten har fungerat vid start, hur daemons fungerar. För detta loggar vi in på den nyss startade maskinen via ssh eller winrm och kontrollerar konfigurationsstatus eller om tjänsterna har startat.

• En liknande situation gäller för integrationstester och moduler för Terraform. Här är en kort tabell som förklarar egenskaperna hos sådana tester.

  
  
  Återkopplingen i pipelinen är ungefär 40 minuter. Allt tar väldigt lång tid. Det kan användas för regressionstester, men för ny utveckling är det verkligen omöjligt. Om man förbereder sig mycket, preparerar körande inställningar och skript kan tiden kortas ner till 10 minuter. Men det är fortfarande inte enhetstester, som kan göras 100 stycken på 5 sekunder.

Frånvaron av enhetstester vid byggande av bilder eller moduler för Terraform gör att vi tvingas överlämna arbetet till separata tjänster, som enkelt kan anropas via REST, eller till Python-skript.

Till exempel behövde vi se till att den virtuella maskinen registrerade sig själv i tjänsten ScaleFT, och vid borttagning av VM:en raderade sig själv.

Eftersom ScaleFT är en tjänst måste vi arbeta med den via API. En wrapper har skrivits som vi kan anropa och säga: "Gå in och ta bort det här och det där". Den lagrar alla nödvändiga inställningar och åtkomster.

Till detta kan vi nu skriva normala tester, eftersom det inte skiljer sig från vanlig mjukvara: någon API mockas, du anropar, och vi ser vad som händer.

Sammanfattning av testerna: Enhetstestning, som borde ta en minut enligt OS, ger ingen sådan feedback. Högre typer av tester ger effekt, men löser bara en del av problemen.

Parprogrammering

Tester är självklart bra. Man kan skriva många av dem, och de kan vara av olika slag. De kommer att fungera på sina nivåer och ge oss feedback. Men problemet med dåliga enhetstester som ger det snabbaste operativsystemet kvarstår. Samtidigt vill man ha ett snabbt operativsystem, som är enkelt och trevligt att arbeta med. För att inte tala om kvaliteten på den lösning som erhålls. Lyckligtvis finns det tekniker som möjliggör snabbare feedback än enhetstester. Det handlar om parprogrammering.

När man skriver kod vill man ha feedback om dess kvalitet så snabbt som möjligt. Ja, man kan skriva allt i en feature-branch (för att inte störa någon), göra en pull request på GitHub, utse någon vars åsikt har vikt, och vänta på svar.

Men att vänta kan ta lång tid. Folk är upptagna, och svaret, även om det kommer, kanske inte är av hög kvalitet. Anta att svaret kom omedelbart, att granskaren snabbt förstod hela idén, men svaret kommer fortfarande med en försenad tidpunkt, i efterhand. Man vill ha det tidigare. Här syftar parprogrammering till att möjliggöra just detta – att få feedback direkt, i skrivögonblicket.

Nedan presenterar jag stilarna för parprogrammering och deras tillämplighet i arbetet med IaC:

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

Låt oss granska kompatibiliteten mellan våra problem och stilen:

• Problem: ofullkomlighet hos verktyg, medel för att utveckla kod.
  Negativ påverkan: längre utvecklingstid, vi blir långsammare, arbetsrytm / tempo störs.
  Hur vi hanterar det: vi använder andra verktyg, gemensam IDE och lär oss kortkommandon.
• Problem: långsam distribution.
  Negativ påverkan: ökar tiden för att skapa en fungerande kodbit. Vi blir uttråkade under väntan, händerna sträcker sig efter att sysselsätta sig med något annat medan vi väntar.
  Hur vi hanterar det: vi har inte löst det.
• Problem: brist på metoder och praxis.
  Negativ påverkan: vi har ingen kunskap om vad som är bra och vad som är dåligt. Det förlänger tiden för att få feedback.
  Hur vi hanterar det: utbyte av åsikter och metoder i pararbete löser nästan problemet.

Huvudproblemet med att använda denna stil i IaC är det ojämna arbetstempot. I traditionell mjukvaruutveckling har du en mycket jämn progression. Du kan spendera fem minuter och skriva N. Spendera tio minuter och skriva 2N, femton minuter – 3N. Här kan du spendera fem minuter och skriva N, för att sedan spendera ytterligare trettio minuter och skriva en tiondel av N. Här vet du ingenting, du har en blockering, en stillastående situation. Att reda ut det tar tid och distraherar från själva programmeringen.

Slutsats: i sin rena form passar det inte för oss.

2. Ping-pong. Denna metod innebär att en deltagare skriver testet, medan den andra implementerar det. Med tanke på att det är komplicerat med enhetstester, och att man måste skriva ett tidskrävande integrationstest, försvinner hela lättheten med ping-pong.

Jag kan säga att vi har försökt med att dela upp ansvar för att designa testscenarier och implementera koden för dem. En deltagare kom på scenariot och var ansvarig för detta, han hade det sista ordet. Den andra var ansvarig för implementeringen. Det fungerade bra. Kvaliteten på scenariot ökade med denna metod.

Slutsats: tyvärr tillåter arbetstempot oss inte att använda ping-pong som en praktik för parprogrammering i IaC.

3. Strong Style. En komplex praktik.. Idén är att en deltagare blir den styrande navigatören, medan den andra tar rollen som utförande drivare. Beslutsrätten ligger enbart hos navigatören. Drivaren skriver bara och kan med ord påverka det som sker. Roller förändras inte under en längre tid.

Passar bra för utbildning, men kräver starka mjuka färdigheter. Här stötte vi på problem. Tekniken gick trögt. Och det handlar inte ens om infrastrukturen.

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

4. Mobbing, svärmande och alla kända, men inte nämnda stilar. behandlas inte, då vi inte har provat dem och kan inte uttala oss om dem i kontexten av vårt arbete.

Sammanfattande slutsatser angående parprogrammering:

• Vi upplever ett ojämnt arbetstempo som skapar problem.
• Vi har kört fast på våra otillräckliga mjuka färdigheter. Och ämnesområdet bidrar inte till att övervinna dessa brister.
• Långa tester och verktygsproblem gör parprogrammering segt.

5. Trots detta hade vi också framgångar. Vi kom på vår egen metod "Konvergens – divergens". Jag ska kort beskriva hur den fungerar.

Vi har ständiga partners under flera dagar (mindre än en vecka). Vi arbetar tillsammans med en uppgift. En tid sitter vi tillsammans: en skriver, den andra observerar som supportteam. Sedan separerar vi ett tag, var och en gör sina egna saker, och sen kommer vi återigen tillsammans, synkroniserar oss mycket snabbt, gör något tillsammans och separerar igen.

Planering och kommunikation

Det sista blocket av metoder för att lösa OS-problem är organiseringen av arbetet med själva uppgifterna. Här ingår också erfarenhetsutbyte som ligger utanför pararbete. Låt oss överväga tre metoder:

1. Uppgifter genom målträdet. Den övergripande ledningen av projektet organiserar vi genom ett träd som oändligt sträcker sig in i framtiden. Tekniskt sett hanteras detta i Miro. Det finns en uppgift – den är ett delmål. Från den leder antingen mindre mål eller grupper av uppgifter. Från dem går själva uppgifterna. Alla uppgifter skapas och hanteras på denna tavla.

Detta schema ger också återkoppling som sker en gång om dagen, när vi synkroniserar oss på möten. Att ha en gemensam plan för alla, strukturerad och helt öppen, gör det möjligt för alla att vara medvetna om vad som pågår och hur långt vi har kommit i vår framsteg.

Fördelarna med visuell översikt över uppgifter:

• Orsakssamband. Varje uppgift leder till något globalt mål. Uppgifterna grupperas efter mindre mål. Domäninfrastrukturen är i sig ganska teknisk. Det är inte alltid uppenbart vilken specifik påverkan på affären som exempelvis skrivning av en handbok för migrering till en annan nginx har. Att ha ett mål bredvid en uppgift gör det mer begripligt.
  
  Orsakssamband är en viktig egenskap hos uppgifter. Det besvarar direkt frågan: "Gör jag rätt saker?"
• Parallellitet. Vi är nio personer, och det är fysiskt omöjligt för alla att kasta sig över en och samma uppgift. Ibland räcker inte uppgifterna inom ett område. Vi tvingas parallellisera arbetet mellan små arbetsgrupper. Under tiden arbetar grupperna en stund med sina uppgifter, och de kan förstärkas av någon annan. Ibland lämnar personer från denna arbetsgrupp. Någon går på semester, någon gör en presentation för konferensen DevOps conf, någon skriver en artikel på Habr. Att veta vilka mål och uppgifter som kan göras parallellt blir mycket viktigt.

2. Rotationen av ledare för morgonmöten. På standup-mötena har vi stött på ett problem – många uppgifter görs parallellt av folk. Ibland hänger uppgifterna dåligt ihop och det finns ingen förståelse för vem som gör vad. Åsikten från en annan teammedlem är mycket viktig. Det är extra information som kan förändra hur uppgiften löses. Visst finns det vanligtvis någon med dig, men konsultation och tips är alltid välkomna.

För att förbättra denna situation har vi implementerat tekniken "Rotation av standup-ledaren". Nu roterar de enligt en viss lista, och det har en effekt. När det är din tur är du tvungen att fördjupa dig och förstå vad som pågår för att bra kunna leda scrum-mötet.

3. Intern demo. Hjälp med att lösa uppgifter genom parprogrammering, visualisering i uppgifts-trädet och hjälp på scrum-mötena på morgonen är bra, men inte perfekt. I paret är du begränsad av dina egna kunskaper. Uppgifts-trädet hjälper till att få en global förståelse för vem som gör vad. Och ledaren och kollegorna på morgonmötet kommer inte att fördjupa sig i dina problem. De kan definitivt missa något.

Lösningen hittades i att demonstrera det arbete som utförts för varandra och sedan diskutera det. Vi träffas en gång i veckan i en timme och visar detaljer om lösningar på uppgifter vi har arbetat med under den senaste veckan.

Under demonstrationen bör man avslöja detaljerna i uppgiften och definitivt demonstrera dess funktion.

Presentationen kan hållas enligt en checklista.1. Sätt in i kontext. Var kom uppgiften ifrån, varför behövdes det överhuvudtaget?

2. Hur har uppgiften lösts tidigare? Till exempel, behövdes massiva mus-klick eller var det överhuvudtaget omöjligt att göra något.

3. Hur förbättrar vi detta. Till exempel: "Titta, nu finns det ett litet skript, här är README."

4. Visa hur det fungerar. Det är önskvärt att direkt genomföra ett användarscenario. Jag vill ha X, gör Y, ser Z (eller Z). Till exempel, jag distribuerar NGINX, kollar url, får 200 OK. Om åtgärden tar lång tid, förbered i förväg så att du kan visa det senare. Det är bäst att inte bryta ner något en timme före demonstrationen, om det är känsligt.

5. Förklara hur väl problemet har lösts, vilka svårigheter som återstår, vad som inte är klart och vilka förbättringar som kan göras framöver. Till exempel, nu finns det en cli, senare blir det full automation i CI.

Det är önskvärt att varje talare håller sig inom 5-10 minuter. Om din presentation är uppenbart viktig och kommer att ta längre tid, kom överens om det i kanalen sre-takeover i förväg.

Efter den fysiska delen följer alltid en diskussion i tråden. Här dyker den nödvändiga feedbacken upp angående våra uppgifter.

Som resultat genomförs en enkät för att ta reda på nyttan med det som pågår. Detta ger redan feedback angående själva presentationen och betydelsen av uppgiften.

Långa slutsatser och nästa steg

Det kan verka som att tonen i artikeln är något pessimistisk. Så är det inte. De två grundläggande nivåerna av att få feedback, nämligen tester och parprogrammering, fungerar. Inte helt som i traditionell utveckling, men det finns en positiv effekt av detta.

Tester, i deras nuvarande form, ger endast delvis täckning av koden. Många konfigurationsfunktioner förblir otestade. Deras påverkan på det faktiska arbetet vid kodskrivning är låg. Men det finns en effekt från integrationstester, och det är just de som gör det möjligt att genomföra refaktoriseringar utan rädsla. Detta är en stor prestation. Dessutom försvinner problemet med att flytta fokus till utveckling i högnivåspråk (vi använder python, go). För "limmet" krävs många kontroller, vilket inte är nödvändigt, allmän integration räcker.

Arbete i par beror mer på de specifika personerna. Det finns faktorer som uppgiften och våra mjuka färdigheter. Med vissa fungerar det väldigt bra, med andra sämre. Det finns definitivt nytta av detta. Det är klart att även vid otillräckligt efterlevande av reglerna för pararbete, påverkar själva faktumet av gemensamt utförande av uppgifter positivt resultatets kvalitet. Personligen tycker jag att det är enklare och trevligare att arbeta i par.

Högre nivåer av påverkan på OS – planering och arbete med uppgifter ger definitivt effekter: kvalitativ kunskapsutbyte och förbättrad kvalitet på utvecklingen.

Korta slutsatser i en rad.

• XP-praktiker fungerar inom IaC, men med lägre effektivitet.
• Stärk det som fungerar.
• Tänk ut egna kompenserande mekanismer och praktiker.

Källa: habr.com