🥇Infrastructure as Code: cum să depășești problemele cu ajutorul XP

Salut, Habr! Cândva mă plângeam de viața în paradigma Infrastructure as Code și nu ofeream nicio soluție pentru situația existentă. Astăzi m-am întors să împărtășesc ce abordări și practici ne pot ajuta să ieșim din abisul disperării și să îndreptăm lucrurile în direcția corectă.

În articolul anterior «Infrastructure as Code: prima întâlnire» Îmi împărtășeam impresiile despre acest domeniu, încercând să reflectez asupra situației actuale și chiar am presupus că practicile standard, cunoscute de toți dezvoltatorii, ar putea ajuta. Ar fi putut părea că am exprimat multe plângeri despre viață, dar nu au fost propuneri pentru a ieși din această situație.

Cine suntem, unde suntem și ce probleme avem

Acum ne aflăm în echipa SRE Onboarding, care constă din șase programatori și trei ingineri de infrastructură. Toți încercăm să scriem Infrastructure as Code (IaC). Facem asta pentru că, în principiu, știm să scriem cod și în trecut am fost dezvoltatori de nivel «peste medie».

Avem un set de avantaje: un anumit background, cunoștințe de practici, abilitatea de a scrie cod, dorința de a învăța lucruri noi.
Și există o parte căzută, adică un dezavantaj: lipsa de cunoștințe în domeniul infrastructurii.

Tehnologiile pe care le folosim în IaC-ul nostru.

Terraform pentru crearea resurselor.
Packer pentru construirea imaginii. Acestea sunt imagini Windows, CentOS 7.
Jsonnet, pentru a face un build puternic în drone.io, precum și pentru generarea packer json și modulele noastre Terraform.
Azure.
Ansible pentru pregătirea imaginilor.
Python pentru servicii auxiliare, precum și scripturi de provisioning.
Și toate acestea în VSCode cu pluginuri, partajate între membrii echipei.

Concluzia mea articolului precedent a fost că încercam să insufl (în primul rând în mine) optimism, voiam să spun că vom încerca abordările și practicile pe care le cunoaștem pentru a lupta împotriva dificultăților și complexităților din acest domeniu.

Acum ne confruntăm cu următoarele probleme IaC:

Imperfecțiunea instrumentelor, mijloacelor de dezvoltare a codului.
Dezvoltarea lentă. Infrastructura este o parte a realității, iar aceasta poate fi lentă.
Lipsa abordărilor și practicilor.
Suntem noi în acest domeniu și știm foarte puțin.

Programarea extremă (XP) se grăbește în ajutor

Toți dezvoltatorii sunt familiarizați cu programarea extremă (XP) și practicile care o susțin. Mulți dintre noi au lucrat după această abordare, iar aceasta a avut succes. Atunci de ce să nu ne folosim de principiile și practicile stabilite acolo pentru a depăși dificultățile infrastructurii? Am decis să aplicăm această abordare și să vedem ce va ieși.

Verificarea aplicabilității abordării XP în domeniul vostruPrezint o descriere a mediului pentru care XP este adecvat și cum se corelează acesta cu noi:

1. Cerințe software care se schimbă dinamic. Ne era clar care este scopul final. Dar în detalii putem varia. Noi decidem în ce direcție dorim să ne îndreptăm, așa că cerințele se schimbă periodic (în principal de către noi înșine). Dacă luăm echipa SRE, care realizează automatizarea și își limitează singură cerințele și sfera de lucru, atunci acest punct se potrivește bine.

2. Riscuri cauzate de proiectele cu timp fix care folosesc tehnologii noi. Putem avea riscuri atunci când folosim lucruri necunoscute nouă. Și acesta este 100% cazul nostru. Întregul nostru proiect constă în utilizarea tehnologiilor cu care nu am fost pe deplin familiarizați. Aceasta este, de fapt, o problemă constantă, deoarece în domeniul infrastructurii apar mereu multe tehnologii noi.

3,4. Echipa de dezvoltare extinsă, mică și co-locată. Tehnologia pe care o folosiți permite teste unitare și funcționale automate. Aceste două puncte nu se potrivesc prea bine cu noi. În primul rând, nu suntem o echipă co-locată, iar în al doilea rând, suntem nouă persoane, ceea ce poate fi considerat o echipă mare. Totuși, conform unor definiții ale „echipelor mari”, multe înseamnă 14+ persoane.

Să examinăm unele practici din XP și cum influențează acestea viteza și calitatea feedback-ului.

Principiul ciclului de feedback în XP

În înțelegerea mea, feedback-ul este răspunsul la întrebarea: fac bine? Mergem în direcția corectă? În XP, există o schemă divină pe acest subiect: ciclul de feedback în timp. Interesant este că, cu cât suntem mai jos, cu atât mai repede putem obține feedback-ul necesar pentru a răspunde la întrebările esențiale.

Aceasta este o temă destul de interesantă pentru discuție, deoarece în industria IT este posibil să obținem rapid feedback. Imaginați-vă cât de dureros este să lucrați la un proiect timp de șase luni și abia apoi să aflați că la început a fost sădită o greșeală. Aceasta se întâmplă atât în proiectare, cât și în construirea oricăror sisteme complexe.

În cazul nostru, IaC ne ajută cu feedbackul. Fac imediat o mică corectare în schema de mai sus: planul de lansare nu are un ciclu lunar, ci se desfășoară de mai multe ori pe zi. La acest ciclu sunt legate anumite practici, pe care le vom explora mai în detaliu.

Important: feedbackul poate deveni soluția pentru toate problemele menționate mai sus. În combinație cu practicile XP, poate scoate din abisul disperării.

Cum să te scoți din abisul disperării: trei practici

Teste

Testele sunt menționate de două ori în ciclul de feedback XP. Nu este întâmplător. Ele sunt extrem de importante pentru întreaga tehnică de programare extremă.

Se presupune că ai teste Unit și Acceptance. Unele îți oferă feedback în câteva minute, iar altele în câteva zile, deoarece acestea sunt scrise mai lent și rulată mai rar.

Există o piramidă clasică a testării, care arată că trebuie să existe mai multe teste de acest tip.

Cum se aplică această schemă în proiectul nostru IaC? De fapt... deloc.

Testele Unit, deși ar trebui să fie foarte multe, nu pot fi niciodată prea multe. Fiecare dintre ele testează ceva foarte indirect. Practic, se poate spune că nu le scriem deloc. Dar iată câteva aplicații pentru astfel de teste pe care totuși am reușit să le implementăm:
1. Testarea codului în jsonnet. Acesta este, de exemplu, pipeline-ul nostru de construire în drone, care este destul de complicat. Codul în jsonnet este bine acoperit de teste.
  Folosim acest cadru de testare Unit pentru Jsonnet.
2. Teste pentru scripturile care sunt executate la pornirea resursei. Scripturile sunt în Python, ceea ce înseamnă că și testele pentru acestea pot fi scrise.
Este potențial posibil să verifici configurația în teste, dar noi nu facem asta. Există, de asemenea, opțiunea de a seta verificarea regulilor de configurare a resurselor prin tflint. Totuși, pentru terraform sunt prea multe verificări de bază, dar multe scenarii de verificare sunt scrise pentru AWS. Noi suntem pe Azure, așa că din nou nu se potrivește.
Teste de integrare a componentelor: aici depinde de cum le clasifici și unde le plasezi. Dar, în principiu, acestea funcționează.
Așa arată testele de integrare.

Acesta este un exemplu în timpul construirii imaginilor în Drone CI. Pentru a ajunge la ele, trebuie să aștepți 30 de minute pentru a construi imaginea Packer, apoi încă 15 minute pentru a le rula. Dar există!
Algoritmul de verificare a imaginilor
1. Mai întâi, Packer trebuie să pregătească imaginea complet.
2. Aproape de test există un terraform cu starea locală, cu care desfășurăm această imagine.
3. Pentru desfășurare se folosește un mic modul aflat în apropiere, pentru a lucra mai ușor cu imaginea.
4. Când o VM este desfășurată din imagine, se pot începe verificările. În principal, verificările se efectuează pe mașină. Se verifică cum au funcționat scripturile la pornire, cum funcționează demonii. Pentru aceasta, prin ssh sau winrm, accesăm mașina proaspăt ridicată și verificăm starea configurației sau dacă serviciile s-au pornit.
Situația este similară cu testele de integrare și în modulele pentru terraform. Iată un tabel scurt care explică particularitățile acestor teste.

Feedback-ul pe pipeline este de aproximativ 40 de minute. Totul durează foarte mult. Poate fi folosit pentru regres, dar pentru dezvoltarea nouă este complet nerealizabil. Dacă ne pregătim foarte, foarte bine, pregătind running și scripturi, putem reduce timpul la 10 minute. Dar aceasta nu este totuși o testare Unit care durează 5 secunde pentru 100 de teste.

Lipsa testelor Unit la construirea imaginilor sau modulelor terraform ne determină să externalizăm munca către servicii separate, pe care le putem accesa prin REST, sau către scripturi Python.

De exemplu, a trebuit să facem astfel încât, la pornirea mașinii virtuale, aceasta să se înregistreze în serviciul ScaleFT, iar la distrugerea VM-ului să se elimine singură.

Având în vedere că ScaleFT este un serviciu, suntem nevoiți să lucrăm cu el prin API. A fost scris un wrapper, pe care îl putem apela și să spunem: „Accesează și elimină acesta, acesta”. Acesta păstrează toate setările și accesurile necesare.

Pe aceasta putem scrie teste normale, deoarece nu se deosebește de orice alt software: se simulează un API, îl apeliți și vedem ce se întâmplă.

Rezultatele testelor: testarea Unit, care ar trebui să ofere OS-ului un rezultat într-un minut, nu o face. Iar tipurile de testare mai înalte din piramidă oferă un efect, dar acoperă doar o parte din probleme.

Programare în pereche

Testele sunt, desigur, utile. Se pot scrie multe și pot fi de diferite tipuri. Vor funcționa la nivelurile lor și ne vor oferi feedback. Dar problema testelor Unit slabe, care oferă cele mai rapide OS-uri, rămâne. Pe de altă parte, dorința de a avea un OS rapid persistă; este ușor și plăcut de utilizat. Nemaivorbind de calitatea soluției obținute. Din fericire, există tehnici care oferă un feedback chiar mai rapid decât testele modulare. Aceasta este programarea în pereche.

Când scriem cod, dorim să obținem feedback despre calitatea acestuia cât mai repede posibil. Da, putem scrie totul în ramura de funcționalitate (pentru a nu strica nimic nimănui), să facem un pull request pe GitHub, să nominalizăm pe cineva a cărui opinie contează și să așteptăm răspunsul.

Însă așteptarea poate dura mult. Oamenii sunt ocupați și răspunsul, chiar dacă vine, poate să nu fie de cea mai bună calitate. Să presupunem că răspunsul a venit imediat, revizorul a înțeles instantaneu tot conceptul, dar totul vine cu întârziere, după fact. Și vrem să avem răspunsul mai devreme. Aici intervine programarea în pereche – pentru a obține feedback imediat, în momentul scrierii.

Aici sunt prezentate stilurile programării în pereche și aplicabilitatea lor în munca cu IaC:

1. Clasic, Experiențiat + Experiențiat, schimbare la un interval de timp stabilit. Două roluri – driver și navigator. Două persoane. Lucrează la același cod și își schimbă rolurile la un anumit interval de timp stabilit anterior.

Să examinăm compatibilitatea problemelor noastre cu stilul:

Problemă: imperfecțiunea instrumentelor, a mijloacelor de dezvoltare a codului.
Influență negativă: dezvoltare mai lungă, ne încetinim, ritmul/ne ființa este afectat.
Cum combatem: folosim un alt instrument, un IDE comun și învățăm scurtături.
Problemă: desfășurare lentă.
Influență negativă: crește timpul necesar creării unei părți funcționale de cod. Ne plictisim în timpul așteptării și mâinile ni se îndreaptă spre altceva, în timp ce așteptăm.
Cum combatem: nu am rezolvat.
Problemă: lipsa abordărilor și practicilor.
Influență negativă: nu știm cum să facem bine și cum să facem rău. Îndelungește obținerea feedback-ului.
Cum combatem: schimbul de opinii și practici în muncă în pereche aproape rezolvă problema.

Problema principală a aplicării acestui stil în IaC este ritmul de muncă neregulat. În dezvoltarea tradițională de software, ai o mișcare foarte uniformă. Poți să cheltuiești cinci minute și să scrii N. Să cheltuiești zece minute și să scrii 2N, cincisprezece minute – 3N. Aici poți să cheltuiești cinci minute și să scrii N, iar apoi să cheltuiești încă treizeci de minute și să scrii o zecime din N. Aici nu știi nimic, ai o blocare, o stagnare. Investigarea durează timp și te distrage de la programarea propriu-zisă.

Concluzie: în forma sa pură, nu se potrivește.

2. Ping-pong. Această abordare presupune că un participant scrie un test, iar altul face implementarea acestuia. Ținând cont de faptul că cu testele unității este complicat, și trebuie să scrii un test de integrare care durează mult timp, toată ușurința ping-pong-ului se pierde.

Pot spune că am încercat să separăm responsabilitățile între proiectarea scenariului de test și implementarea codului pentru acesta. Un participant concepea scenariul, iar în această parte a muncii el era responsabil, el avea cuvântul final. Iar celălalt era responsabil pentru implementare. S-a dovedit a fi eficient. Calitatea scenariului este îmbunătățită prin această abordare.

Concluzie: din păcate, ritmul de muncă nu permite utilizarea ping-pong-ului ca practică de programare în pereche în IaC.

3. Strong Style. O practică complicată.Ideea este că un participant devine navigator directiv, iar celălalt preia rolul de driver executiv. În acest context, dreptul de decizie aparține exclusiv navigatorului. Driverul doar tastează și poate influența desfășurarea evenimentelor prin cuvânt. Rolurile nu se schimbă pentru o perioadă lungă de timp.

Se potrivește bine pentru învățare, dar necesită abilități soft puternice. Aici ne-am împotmolit. Tehnica era dificil de aplicat. Și problema nu ține nici măcar de infrastructură.

Concluzie: poate fi aplicată potențial, nu renunțăm la încercări.

4. Mobbing, swarming și toate stilurile cunoscute, dar neenumerate aici. nu le considerăm, deoarece nu le-am încercat și nu putem spune nimic despre ele în contextul muncii noastre.

Concluziile generale privind utilizarea programării în pereche:

Avem un ritm de muncă inegal, care perturbează.

Ne-am lovit de abilități soft insuficient de bune. Și domeniul de aplicare nu contribuie la depășirea acestor deficiențe.

Testele lungi, problemele cu instrumentele fac ca dezvoltarea în pereche să fie dificilă.

5. Cu toate acestea, au existat și succese. Am creat propria noastră metodă de „Convergență - Divergență”. Îți voi descrie pe scurt cum funcționează.

Avem parteneri permanenți pentru câteva zile (mai puțin de o săptămână). Facem o sarcină împreună. O perioadă stăm împreună: unul scrie, celălalt stă și observă, ca un suport de echipă. Apoi ne dispersăm pentru un timp, fiecare își face lucruri independente, apoi ne reunim din nou, ne sincronizăm foarte repede, facem ceva împreună și din nou ne dispersăm.

Planificare și comunicare

Ultimul bloc de practici prin care se rezolvă problemele sistemului de operare este organizarea muncii cu sarcinile în sine. Aici intră și schimbul de experiență care se află în afara muncii în echipă. Să examinăm trei practici:

1. Sarcini printr-un arbore de obiective. Gestionarea generală a proiectului a fost organizată printr-un arbore care se întinde infinit în viitor. Tehnic, gestionarea se face în Miro. Există o sarcină - aceasta este un obiectiv intermediar. De la aceasta derivă fie obiective mai mici, fie grupuri de sarcini. De la acestea derivă sarcinile propriu-zise. Toate sarcinile sunt create și gestionate pe acest board.

Această schemă oferă, de asemenea, feedback, care are loc o dată pe zi, când ne sincronizăm în timpul întâlnirilor. Existența unui plan comun pentru toți, structurat și complet deschis, permite fiecăruia să fie la curent cu ceea ce se întâmplă și cu cât de departe am avansat în progres.

Avantajele unei viziuni vizuale a sarcinilor:

Causalitate. Fiecare sarcină duce la un anumit obiectiv global. Sarcinile sunt grupate în funcție de obiectivele mai mici. Domeniul infrastructurii este în sine destul de tehnic. Nu este întotdeauna imediat evident ce influență specifică asupra afacerii are, de exemplu, redactarea unui ghid de migrare pe un alt nginx. Existența unei cărți de obiective lângă aceasta face ca lucrurile să fie mai clare.

Causalitatea este o proprietate importantă a sarcinilor. Aceasta răspunde direct la întrebarea: „Fac bine?”
Paralelism. Suntem nouă persoane, și a ne concentra cu toții pe o singură sarcină este pur și simplu imposibil din punct de vedere fizic. Sarcinile dintr-un singur domeniu nu sunt întotdeauna suficiente. Suntem nevoiți să paralelizăm munca între mici grupuri de lucru. În acest timp, grupurile stau pe sarcina lor, iar cineva le poate întări. Din această grupă de lucru uneori pleacă oameni. Unii merg în concediu, alții pregătesc o prezentare pentru conferința DevOps conf, iar alții scriu un articol pe Habr. A ș i ști care obiective și sarcini pot fi realizate în paralel devine foarte important.

2. Schimbarea facilitatorilor întâlnirilor de dimineață. La standup-uri a apărut o problemă – mulți oameni lucrează la sarcini în paralel. Uneori sarcinile sunt slab legate și nu există o înțelegere clară despre cine ce face. Părerea unui alt membru al echipei este foarte importantă. Este o informație suplimentară care poate schimba direcția rezolvării sarcinii. Desigur, de obicei ai pe cineva lângă tine, dar consultarea și sugestiile nu sunt niciodată în plus.

Pentru a îmbunătăți această situație, am aplicat tehnica „Schimbarea facilitatorului standup-ului”. Acum aceștia se rotesc după o listă stabilită, iar acest lucru are efectul său. Când îți vine rândul, ești obligat să te implici și să înțelegi ce se întâmplă, pentru a conduce bine întâlnirea scrum.

3. Demo intern. Ajutorul în rezolvarea sarcinilor prin programare pereche, vizualizarea pe un arbore de sarcini și asistența în întâlnirile scrum de dimineață sunt bune, dar nu perfecte. În pereche ești limitat doar de cunoștințele tale. Arborele de sarcini ajută să înțelegi global cine și ce face. Iar facilitatorul și colegii din întâlnirea de dimineață nu se vor adânci în problemele tale. Cu siguranță pot rata ceva.

Soluția a fost găsită în prezentarea muncii realizate unii altora și în discuția ulterioară a acestora. Ne întâlnim o dată pe săptămână timp de o oră și arătăm detaliile soluțiilor pentru sarcinile realizate în ultima săptămână.

În timpul prezentării trebuie să detaliem sarcina și să demonstrăm neapărat cum funcționează aceasta.

Prezentarea poate fi realizată pe baza unui checklist.1. Introduceți în context. De unde a apărut sarcina, de ce a fost necesară aceasta?

2. Cum se rezolva sarcina anterior? De exemplu, era necesar un clic masiv cu mouse-ul, sau era imposibil să se facă ceva.

3. Cum îmbunătățim aceasta. De exemplu: „Uitați, acum avem un mic script, iată readme-ul".

4. Arătați cum funcționează. Ar fi bine să implementați un scenariu al utilizatorului. Vreau X, fac Y, văd Z (sau Z). De exemplu, implementez NGINX, accesez url-ul, primesc 200 OK. Dacă acțiunea durează, pregătiți-o din timp pentru a o putea arăta. Ideal ar fi să evitați să se strice ceva cu o oră înainte de demo, dacă este fragil.

5. Explicați cât de bine a fost rezolvată problema, ce dificultăți au rămas, ce nu a fost finalizat și ce îmbunătățiri sunt posibile în viitor. De exemplu, acum avem CLI, iar mai târziu va fi automatizare completă în CI.

Fiecare vorbitor ar trebui să se încadreze în 5-10 minute. Dacă prezentarea dumneavoastră este crucială și va dura mai mult timp, asigurați-vă că ați convenit acest lucru în canalul sre-takeover.

După partea față în față, va urma cu siguranță o discuție în thread. Aici apare feedback-ul necesar cu privire la sarcinile noastre.

La final, se va realiza un sondaj pentru a evalua utilitatea a ceea ce s-a întâmplat. Acesta este feedback-ul referitor la prezentare și la importanța sarcinii.

Concluzii lungi și ce urmează

Poate părea că tonul articolului este oarecum pesimist. Nu este așa. Cele două niveluri inferioare de obținere a feedback-ului, și anume testele și programarea în pereche, funcționează. Nu perfect, ca în dezvoltarea tradițională, dar există un efect pozitiv.

Testele, în forma lor actuală, oferă doar o acoperire parțială a codului. Multe funcții de configurare rămân netestate. Influența lor asupra activității directe în scrierea codului este scăzută. Totuși, efectul testelor de integrare este vizibil și ele permit să efectuăm fără frică refactorizări. Aceasta este o realizare mare. De asemenea, odată cu mutarea accentului pe dezvoltarea în limbaje de nivel înalt (la noi python, go), problema dispare. O mulțime de verificări pentru „lipici” nu sunt necesare, este suficientă integratia generală.

Munca în pereche depinde mult de persoanele implicate. Există o factor al sarcinii și abilitățile noastre soft. Cu unii rezultatează foarte bine, cu alții mai puțin bine. Beneficiul este cert. Este clar că, chiar și în cazul nerespectării insuficiente a regulilor de muncă în pereche, simplul fapt de a lucra împreună asupra sarcinilor influențează pozitiv calitatea rezultatului. Personal, îmi este mai ușor și mai plăcut să lucrez în pereche.

Metodele mai avansate de influențare asupra OS – planificarea și gestionarea sarcinilor aduc cu siguranță efecte: un schimb calitativ de cunoștințe și îmbunătățirea calității dezvoltării.