Infrastructura ca cod: cum să depășești problemele folosind XP

Bună, Habr! Anterior, m-am plâns de viața în Infrastructură ca paradigmă de cod și nu am oferit nimic pentru a rezolva situația actuală. Astăzi m-am întors să vă spun ce abordări și practici vă vor ajuta să scăpați din abisul disperării și să îndreptați situația în direcția corectă.

Într-un articol precedent „Infrastructura ca cod: prima cunoștință” Mi-am împărtășit impresiile despre această zonă, am încercat să reflectez asupra situației actuale în acest domeniu și chiar am sugerat că practicile standard cunoscute de toți dezvoltatorii ar putea ajuta. S-ar putea părea că au fost multe plângeri cu privire la viață, dar nu au existat propuneri pentru o ieșire din situația actuală.

Cine suntem, unde suntem și ce probleme avem

În prezent, suntem în echipa Sre Onboarding, care este formată din șase programatori și trei ingineri de infrastructură. Cu toții încercăm să scriem Infrastructură ca cod (IaC). Facem acest lucru pentru că știm practic să scriem cod și avem o istorie de a fi dezvoltatori „peste medie”.

• Avem un set de avantaje: un anumit background, cunoștințe de practici, capacitatea de a scrie cod, dorința de a învăța lucruri noi.
• Și există o parte slabă, care este și un minus: lipsa de cunoștințe despre hardware-ul infrastructurii.

Tehnologia pe care o folosim în IaC.

• Terraform pentru crearea de resurse.
• Ambalator pentru asamblarea imaginilor. Acestea sunt imagini Windows, CentOS 7.
• Jsonnet pentru a realiza o construcție puternică în drone.io, precum și pentru a genera packer json și modulele noastre terraform.
• Azur.
• Ansible la pregătirea imaginilor.
• Python pentru servicii auxiliare și scripturi de furnizare.
• Și toate acestea în VSCode cu pluginuri partajate între membrii echipei.

Concluzie din partea mea ultimul articol a fost asa: am incercat sa insuflet (in primul rand in mine) optimism, am vrut sa spun ca vom incerca abordarile si practicile cunoscute de noi pentru a face fata dificultatilor si complexitatilor care exista in acest domeniu.

În prezent, ne confruntăm cu următoarele probleme IaC:

• Imperfecțiunea instrumentelor și mijloacelor pentru dezvoltarea codului.
• Desfăşurare lentă. Infrastructura face parte din lumea reală și poate fi lentă.
• Lipsa abordărilor și practicilor.
• Suntem noi și nu știm prea multe.

Extreme Programming (XP) la salvare

Toți dezvoltatorii sunt familiarizați cu Extreme Programming (XP) și cu practicile care stau în spatele acesteia. Mulți dintre noi au lucrat cu această abordare și a avut succes. Deci, de ce să nu folosiți principiile și practicile stabilite acolo pentru a depăși provocările legate de infrastructură? Am decis să luăm această abordare și să vedem ce se întâmplă.

Verificarea aplicabilității abordării XP în industria dvsIată o descriere a mediului pentru care este potrivit XP și a modului în care acesta se raportează la noi:

1. Cerințe software în schimbare dinamică. Ne-a fost clar care este scopul final. Dar detaliile pot varia. Noi înșine decidem unde trebuie să taxi, așa că cerințele se schimbă periodic (în principal singuri). Dacă luăm echipa SRE, care realizează automatizarea în sine și limitează ea însăși cerințele și domeniul de activitate, atunci acest punct se potrivește bine.

2. Riscuri cauzate de proiecte cu oră fixă ​​care utilizează noi tehnologii. Este posibil să întâmpinăm riscuri atunci când folosim unele lucruri necunoscute nouă. Și acesta este 100% cazul nostru. Întregul nostru proiect a fost utilizarea unor tehnologii cu care nu eram pe deplin familiarizați. În general, aceasta este o problemă constantă, deoarece... Există multe tehnologii noi care apar tot timpul în sectorul infrastructurii.

3,4. Echipă extinsă de dezvoltare mică, amplasată în comun. Tehnologia automatizată pe care o utilizați permite efectuarea de teste unitare și funcționale. Aceste două puncte nu ni se potrivesc deloc. În primul rând, nu suntem o echipă coordonată, iar în al doilea rând, suntem nouă, care putem fi considerați o echipă mare. Deși, conform unor definiții ale unei echipe „mare”, o mulțime este de 14+ persoane.

Să ne uităm la câteva practici XP și la modul în care acestea afectează viteza și calitatea feedback-ului.

Principiul buclei de feedback XP

După înțelegerea mea, feedback-ul este răspunsul la întrebarea, fac ceea ce trebuie, mergem acolo? XP are o schemă divină pentru asta: o buclă de feedback în timp. Lucrul interesant este că, cu cât suntem mai jos, cu atât mai repede putem face ca sistemul de operare să răspundă la întrebările necesare.

Acesta este un subiect destul de interesant de discuție, că în industria noastră IT este posibil să obțineți rapid un sistem de operare. Imaginează-ți cât de dureros este să faci un proiect timp de șase luni și abia apoi să afli că a fost o greșeală chiar de la început. Acest lucru se întâmplă în proiectare și în orice construcție de sisteme complexe.

În cazul nostru, IaC, feedback-ul ne ajută. Voi face imediat o mică ajustare diagramei de mai sus: planul de lansare nu are un ciclu lunar, ci are loc de mai multe ori pe zi. Există câteva practici legate de acest ciclu de sistem de operare pe care le vom analiza mai detaliat.

Important: feedback-ul poate fi o soluție la toate problemele menționate mai sus. Combinat cu practicile XP, te 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 bucla de feedback XP. Nu este doar așa. Sunt extrem de importante pentru întreaga tehnică de programare extremă.

Se presupune că aveți teste de unitate și de acceptare. Unele vă oferă feedback în câteva minute, altele în câteva zile, așa că durează mai mult să scrieți și sunt revizuite mai rar.

Există o piramidă clasică de testare, care arată că ar trebui să existe mai multe teste.

Cum ni se aplică acest cadru într-un proiect IaC? De fapt... deloc.

• Testele unitare, în ciuda faptului că ar trebui să fie multe, nu pot fi prea multe. Sau testează ceva foarte indirect. De fapt, putem spune că nu le scriem deloc. Dar iată câteva aplicații pentru astfel de teste pe care le-am putut face:
  1. Testarea codului jsonnet. Aceasta, de exemplu, este conducta noastră de asamblare a dronei, care este destul de complicată. Codul jsonnet este bine acoperit de teste.
     Noi folosim asta Cadrul de testare unitară pentru Jsonnet.
  2. Testează pentru scripturile care sunt executate când pornește resursa. Scripturile sunt scrise în Python și, prin urmare, testele pot fi scrise pe ele.
• Este posibil să se verifice configurația în teste, dar nu facem asta. De asemenea, este posibil să configurați regulile de configurare a resurselor de verificare prin tflint. Cu toate acestea, verificările de acolo sunt pur și simplu prea de bază pentru terraform, dar multe scripturi de testare sunt scrise pentru AWS. Și suntem pe Azure, așa că acest lucru din nou nu se aplică.
• Teste de integrare a componentelor: depinde de cum le clasificați și de unde le puneți. Dar practic funcționează.

  Așa arată testele de integrare.

  
  
  Acesta este un exemplu când construiți imagini în Drone CI. Pentru a ajunge la ele, trebuie să așteptați 30 de minute pentru ca imaginea Packer să se formeze, apoi să așteptați încă 15 minute să treacă. Dar ele există!

  Algoritm de verificare a imaginii

  1. Ambalatorul trebuie mai întâi să pregătească imaginea complet.
  2. Lângă test există o terraformă cu o stare locală, pe care o folosim pentru a implementa această imagine.
  3. La desfășurare, un mic modul aflat în apropiere este folosit pentru a facilita lucrul cu imaginea.
  4. Odată ce VM-ul este implementat din imagine, pot începe verificările. Practic, verificările se fac cu mașina. Verifică modul în care au funcționat scripturile la pornire și cum funcționează demonii. Pentru a face acest lucru, prin ssh sau winrm ne conectăm la mașina nou lansată și verificăm starea configurației sau dacă serviciile sunt activate.

• Situația este similară cu testele de integrare în module pentru terraform. Iată un scurt tabel care explică caracteristicile unor astfel de teste.

  
  
  Feedback-ul asupra conductei este de aproximativ 40 de minute. Totul se întâmplă de foarte mult timp. Poate fi folosit pentru regresie, dar pentru dezvoltare nouă este în general nerealist. Dacă sunteți foarte, foarte pregătit pentru asta, pregătiți scripturi care rulează, atunci îl puteți reduce la 10 minute. Dar acestea încă nu sunt teste unitare, care fac 5 de bucăți în 100 secunde.

Absența testelor unitare la asamblarea imaginilor sau a modulelor terraform încurajează mutarea lucrării către servicii separate care pot fi pur și simplu rulate prin REST sau către scripturi Python.

De exemplu, trebuia să ne asigurăm că atunci când pornește mașina virtuală, se înregistrează singură în serviciu ScaleFT, iar când mașina virtuală a fost distrusă, s-a șters singură.

Deoarece avem ScaleFT ca serviciu, suntem forțați să lucrăm cu el prin intermediul API-ului. Era scris acolo un înveliș pe care îl puteai trage și spune: „Intră și șterge asta și asta”. Stochează toate setările și accesele necesare.

Putem deja să scriem teste normale pentru acest lucru, deoarece nu este diferit de software-ul obișnuit: un fel de apiha este batjocorit, îl trageți și vedeți ce se întâmplă.

Rezultatele testelor: Testarea unitară, care ar trebui să ofere sistemul de operare într-un minut, nu o dă. Și tipurile de testare mai sus în piramidă sunt eficiente, dar acoperă doar o parte din probleme.

Programare pereche

Testele sunt, desigur, bune. Puteți scrie multe dintre ele, pot fi de diferite tipuri. Ei vor lucra la nivelul lor și ne vor oferi feedback. Dar problema cu testele unitare proaste, care dau cel mai rapid sistem de operare, rămâne. În același timp, îmi doresc în continuare un sistem de operare rapid, care să fie ușor și plăcut de lucrat. Ca să nu mai vorbim de calitatea soluției rezultate. Din fericire, există tehnici care pot oferi un feedback și mai rapid decât testele unitare. Aceasta este programarea perechilor.

Când scrieți cod, doriți să primiți cât mai repede feedback cu privire la calitatea acestuia. Da, puteți scrie totul într-o ramură de caracteristici (pentru a nu sparge nimic pentru nimeni), puteți face o cerere de extragere în Github, o puteți atribui cuiva a cărui opinie are greutate și așteptați un răspuns.

Dar poți aștepta mult. Oamenii sunt cu toții ocupați, iar răspunsul, chiar dacă există unul, poate să nu fie de cea mai bună calitate. Să presupunem că răspunsul a venit imediat, recenzentul a înțeles instantaneu întreaga idee, dar răspunsul vine totuși târziu, după fapt. Mi-as fi dorit sa fie mai devreme. Acesta este scopul programării în pereche – imediat, în momentul scrierii.

Mai jos sunt stilurile de programare perechi și aplicabilitatea lor în lucrul la IaC:

1. Clasic, Experimentat+Experimentat, schimbare în funcție de cronometru. Două roluri – șofer și navigator. Doi oameni. Ei lucrează pe același cod și își schimbă rolurile după o anumită perioadă de timp predeterminată.

Să luăm în considerare compatibilitatea problemelor noastre cu stilul:

• Problemă: imperfecțiunea instrumentelor și instrumentelor pentru dezvoltarea codului.
  Impact negativ: se dezvoltă mai mult, încetinim, ritmul/ritmul muncii se pierde.
  Cum luptăm: folosim un instrument diferit, un IDE comun și, de asemenea, învățăm comenzi rapide.
• Problemă: implementare lentă.
  Impact negativ: crește timpul necesar pentru a crea o bucată de cod de lucru. Ne plictisim în timp ce așteptăm, mâinile noastre se întind pentru a face altceva în timp ce așteptăm.
  Cum luptăm: nu l-am depășit.
• Problemă: lipsa de abordări și practici.
  Impact negativ: nu există cunoștințe despre cum să o faci bine și cum să o faci prost. Prelungește primirea feedback-ului.
  Cum luptăm: schimbul reciproc de opinii și practici în munca în pereche aproape rezolvă problema.

Principala problemă cu utilizarea acestui stil în IaC este ritmul neuniform de lucru. În dezvoltarea de software tradițională, aveți o mișcare foarte uniformă. Puteți petrece cinci minute și scrie N. Petrece 10 minute și scrie 2N, 15 minute - 3N. Aici poți să stai cinci minute și să scrii N, iar apoi să mai petreci încă 30 de minute și să scrii o zecime de N. Aici nu știi nimic, ești blocat, prost. Investigația necesită timp și distrage atenția de la programare în sine.

Concluzie: în forma sa pură nu este potrivit pentru noi.

2. Ping-pong. Această abordare implică o persoană care scrie testul și o alta face implementarea acestuia. Ținând cont de faptul că totul este complicat cu testele unitare și trebuie să scrieți un test de integrare care durează mult timp pentru programare, toată ușurința ping-pong-ului dispare.

Pot spune că am încercat să separăm responsabilitățile pentru proiectarea unui script de testare și implementarea codului pentru acesta. Un participant a venit cu scenariul, în această parte a lucrării era responsabil, el a avut ultimul cuvânt. Iar celălalt era responsabil de implementare. A mers bine. Calitatea scenariului cu această abordare crește.

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

3.Stil puternic. Practică dificilă. Ideea este că un participant devine navigatorul directiv, iar cel de-al doilea are rolul de driver de execuție. În acest caz, dreptul de a lua decizii revine exclusiv navigatorului. Driverul imprimă doar și poate influența ceea ce se întâmplă cu un cuvânt. Rolurile nu se schimbă mult timp.

Bun pentru învățare, dar necesită abilități soft puternice. Aici ne-am clătinat. Tehnica era dificilă. Și nici măcar nu e vorba de infrastructură.

Concluzie: poate fi folosit potențial, nu renunțăm să încercăm.

4. Mobbing, roi și toate stilurile cunoscute, dar nelistate Nu o luăm în considerare, pentru că Nu l-am încercat și este imposibil să vorbim despre asta în contextul muncii noastre.

Rezultate generale la utilizarea programării perechilor:

• Avem un ritm de lucru neuniform, ceea ce este confuz.
• Ne-am întâlnit cu abilități soft insuficient de bune. Iar tematica nu ajută la depășirea acestor neajunsuri ale noastre.
• Testele lungi și problemele cu instrumentele fac dificilă dezvoltarea asociată.

5. În ciuda acestui fapt, au existat succese. Am venit cu propria noastră metodă „Convergență - Divergență”. 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 singură sarcină împreună. Stăm împreună o vreme: unul scrie, celălalt stă și urmărește echipa de suport. Apoi ne dispersăm ceva timp, fiecare face niște lucruri independente, apoi ne adunăm din nou, ne sincronizăm foarte repede, facem ceva împreună și ne împrăștiem din nou.

Planificare și comunicare

Ultimul bloc de practici prin care se rezolvă problemele OS este organizarea muncii cu sarcinile în sine. Aceasta include și schimbul de experiență în afara muncii în pereche. Să ne uităm la trei practici:

1. Obiective prin arborele obiectivelor. Am organizat managementul de ansamblu al proiectului printr-un arbore care merge la nesfârșit în viitor. Tehnic, urmărirea se face în Miro. Există o sarcină - este un scop intermediar. De aici pleacă fie obiective mai mici, fie grupuri de sarcini. Sarcinile în sine vin de la ei. Toate sarcinile sunt create și menținute pe acest panou.

Această schemă oferă și feedback, care apare o dată pe zi când ne sincronizăm la mitinguri. A avea un plan comun în fața tuturor, dar structurat și complet deschis, permite tuturor să fie conștienți de ceea ce se întâmplă și cât de departe am progresat.

Avantajele viziunii vizuale a sarcinilor:

• Cauzalitate. Fiecare sarcină duce la un obiectiv global. Sarcinile sunt grupate în obiective mai mici. Domeniul infrastructurii în sine este destul de tehnic. Nu este întotdeauna clar imediat ce impact specific are asupra afacerii, de exemplu, scrierea unui runbook privind migrarea către un alt nginx. Având cardul țintă în apropiere, este mai clar.
  
  Cauzalitatea este o proprietate importantă a problemelor. Răspunde direct la întrebarea: „Fac ceea ce trebuie?”
• Paralelism. Suntem nouă și este pur și simplu imposibil din punct de vedere fizic să aruncăm pe toți la o singură sarcină. Nici sarcinile dintr-o zonă pot să nu fie întotdeauna suficiente. Suntem nevoiți să paralelizăm munca între grupuri mici de lucru. În același timp, grupurile stau la sarcina lor ceva timp, pot fi întărite de altcineva. Uneori oamenii se îndepărtează de acest grup de lucru. Cineva pleacă în vacanță, cineva face un raport pentru conf. DevOps, cineva scrie un articol pe Habr. A ști ce obiective și sarcini pot fi realizate în paralel devine foarte important.

2. Prezentatorii înlocuitori ai întâlnirilor de dimineață. La stand-up avem această problemă - oamenii fac multe sarcini în paralel. Uneori sarcinile sunt slab legate și nu se înțelege cine face ce. Și părerea unui alt membru al echipei este foarte importantă. Acestea sunt informații suplimentare care pot schimba cursul rezolvării problemei. Desigur, de obicei există cineva cu tine, dar sfaturile și sfaturile sunt întotdeauna utile.

Pentru a îmbunătăți această situație, am folosit tehnica „Changing the Leading Stand-Up”. Acum sunt rotite în funcție de o anumită listă, iar asta își are efectul. Când este rândul tău, ești forțat să te scufunzi și să înțelegi ce se întâmplă pentru a conduce o întâlnire Scrum bună.

3. Demo intern. Ajutorul în rezolvarea unei probleme din programarea perechilor, vizualizarea pe arborele problemelor și ajutorul la întâlnirile scrum de dimineață sunt bune, dar nu ideale. Ca cuplu, ești limitat doar de cunoștințele tale. Arborele de sarcini ajută la înțelegerea globală cine face ce. Iar prezentatorul și colegii de la întâlnirea de dimineață nu se vor scufunda adânc în problemele tale. Cu siguranță ar putea rata ceva.

Soluția a fost găsită prin demonstrarea muncii depuse unul altuia și apoi discutarea acesteia. Ne întâlnim o dată pe săptămână timp de o oră și arătăm detalii despre soluțiile la sarcinile pe care le-am făcut în ultima săptămână.

În timpul demonstrației, este necesar să dezvăluiți detaliile sarcinii și asigurați-vă că ați demonstrat funcționarea acesteia.

Raportul poate fi realizat folosind o listă de verificare.1. Intrați în context. De unde a venit sarcina, de ce a fost chiar necesară?

2. Cum a fost rezolvată problema înainte? De exemplu, era necesar un clic masiv al mouse-ului sau era imposibil să faci nimic.

3. Cum îl îmbunătățim. De exemplu: „Uite, acum există scriptosik, aici este readme.”

4. Arată cum funcționează. Este recomandabil să implementați direct un scenariu de utilizator. Vreau X, fac Y, văd Y (sau Z). De exemplu, implementez NGINX, fumez adresa URL și obțin 200 OK. Dacă acțiunea este lungă, pregătiți-o din timp pentru a o putea arăta mai târziu. Este indicat să nu-l rupeți prea mult cu o oră înainte de demo, dacă este fragil.

5. Explicați cât de cu succes a fost rezolvată problema, ce dificultăți rămân, ce nu este finalizat, ce îmbunătățiri sunt posibile în viitor. De exemplu, acum CLI, apoi va exista automatizare completă în CI.

Este recomandabil ca fiecare difuzor să o țină la 5-10 minute. Dacă discursul tău este evident important și va dura mai mult, coordonează-l în avans pe canalul de preluare a sre.

După partea față în față există întotdeauna o discuție în fir. Aici apare feedback-ul de care avem nevoie cu privire la sarcinile noastre.

Ca urmare, se efectuează un sondaj pentru a determina utilitatea a ceea ce se întâmplă. Acesta este un feedback cu privire la esența discursului și la importanța sarcinii.

Concluzii lungi și ce urmează

Poate părea că tonul articolului este oarecum pesimist. Este gresit. Două niveluri inferioare de feedback, și anume testele și programarea perechilor, funcționează. Nu la fel de perfect ca în dezvoltarea tradițională, dar există un efect pozitiv din aceasta.

Testele, în forma lor actuală, oferă doar o acoperire parțială a codului. Multe funcții de configurare ajung netestate. Influența lor asupra muncii efective la scrierea codului este scăzută. Cu toate acestea, testele de integrare au un efect și vă permit să efectuați refactorizări fără teamă. Aceasta este o mare realizare. De asemenea, odată cu schimbarea focalizării către dezvoltarea în limbaje de nivel înalt (avem python, go), problema dispare. Și nu aveți nevoie de multe verificări pentru „clei”; o verificare generală de integrare este suficientă.

Lucrul în perechi depinde mai mult de anumite persoane. Există factorul sarcină și abilitățile noastre soft. La unii oameni iese foarte bine, la alții merge mai rău. Cu siguranță există beneficii din asta. Este clar că, chiar dacă regulile muncii în pereche nu sunt suficient respectate, însuși faptul de a îndeplini sarcini împreună are un efect pozitiv asupra calității rezultatului. Personal, mi se pare mai ușor și mai plăcut să lucrez în perechi.

Modalități de influențare la nivel superior a sistemului de operare - planificarea și lucrul cu sarcini produc exact efecte: schimb de cunoștințe de înaltă calitate și calitate îmbunătățită a dezvoltării.

Scurte concluzii într-un singur rând

• Practicienii HR lucrează în IaC, dar cu mai puțină eficiență.
• Întărește ceea ce funcționează.
• Vino cu propriile mecanisme și practici compensatorii.

Sursa: www.habr.com