🥇Infrastructure as Code: kuidas XP abil probleeme ületada

Tere, Habr! Varem kurtsin ma elu üle infrastruktuuri kui koodi paradigmas ja ei pakkunud välja lahendusi tekkinud olukorrale. Täna olen tagasi, et rääkida, millised lähenemisviisid ja praktikad aitavad välja murda meeleheite sügavikust ja suunata olukorda õigesse suunda.

Eelmisel artiklil „Infrastruktuur kui kood: esimene tutvustus“ Jagasin oma muljeid sellest valdkonnast, püüdsin mõelda praegusele olukorrale ning isegi oletasin, et tuntud ja kõikide arendajate teadlikud praktikud võivad aidata. Võis näida, et seal oli palju kaebusi elu üle, kuid ei olnud ettepanekuid keerulise olukorra lahendamiseks.

Kes me oleme, kus me oleme ja millised on meie probleemid

Praegu oleme SRE onboarding meeskonnas, mis koosneb kuuest programmeerijast ja kolmest infrastruktuuriinsenerist. Me kõik proovime kirjutada infrastruktuuri kui koodi (IaC). Teeme seda, sest põhimõtteliselt oskame me kirjutada koodi ja meie taust on keskmise taseme arendaja oma.

Meil on paar plussikut: teatud taust, teatavate praktikate tundmine, koodikirjutamise oskus ja soov õppida uut.
Ja on ka üks nõrk koht, mis on miinus: infrastruktuuri alusmaterjali puudulikud teadmised.

Tehnoloogiatehnoloogiate kogu, mida me oma IaC-s kasutame.

Terraform ressursside loomisel.
Packer piltide kokkupanemiseks. Need on Windows, CentOS 7 pildid.
Jsonnet, et luua võimas kogumik drone.io-s, samuti Packer jsoni genereerimiseks ja meie terraformi moodulite jaoks.
Azure.
Ansible piltide valmistamisel.
Python abiteenuste ja provisoneerimis skriptide jaoks.
Ja kõik see VSCode'is pluginatega, mis on jagatud meeskonna liikmete vahel.

Minu järeldus eelmise artikli oli selline: proovisin sisendada (kõigepealt endasse) optimismi, tahtsin öelda, et proovime tuntud lähenemisviise ja praktikaid, et võidelda meie valdkonnas esinevate raskuste ja keerukustega.

Praegu võitleme selliste IaC probleemidega:

Tööriistade ja koodiarenduse vahendite puudulik täiustatus.
Aeglane juurutamine. Infrastruktuur on osa reaalsest maailmast, mis ei pruugi olla kiire.
Puuduvad lähenemisviisid ja praktikad.
Me oleme uued ja teame vähe.

Ekstreemne programmeerimine (XP) kiirustab appi

Kõigile arendajatele on hästi tuntud äärmuslik programmeerimine (XP) ja selle taga olevad praktikud. Paljud meist on sellise lähenemisega töötanud ja see on olnud edukas. Miks mitte kasutada sealsete põhimõtete ja praktikate põhjalikku üldistamiseks, et ületada infrastruktuuri raskusi? Otsustasime selle lähenemise rakendada ja vaadata, mis sellest saab.

XP lähenemise sobivuse kontrollimine teie valdkondaToon välja keskkonna kirjelduse, mille jaoks XP sobib hästi, ja kuidas see meiega seondub:

1. Dynaamiliselt muutuvad tarkvaranõuded. Meile oli selge, kui kaua eesmärk on. Kuid üksikasju saab muuta. Me otsustame ise, kuhu me peame liikuma, seega nõuded muutuvad perioodiliselt (enamasti meie enda poolt). Kui rääkida SRE meeskonnast, kes teeb ise automatiseerimist ja määratleb ise nõuded ning töö ulatuse, siis see punkt kehtib meie jaoks hästi.

2. Uute tehnoloogiate kasutamisega seotud riskid fikseeritud ajaprojektides. Meil võivad tekkida riskid teadmata, et me kasutame mõningaid meie jaoks tundmatuid asju. Ja see on 100% meie juhtum. Kogu meie projekt põhineb tehnoloogiate kasutamisel, millega me ei olnud lõpuni tuttavad. See on pidev probleem, sest infrastruktuuri valdkonnas ilmub pidevalt palju uusi tehnoloogiaid.

3,4. Väike, koosoleku (co-located) kujundatud arendustiim. Tehnoloogia, mida te kasutate, võimaldab automatiseeritud üksuse ja funktsionaalseid teste. Need kaks punkti ei sobi meile täpselt. Esiteks, me ei ole koosolekutiim, teisalt on meid üheksa inimest, mis võib pidada suureks tiimiks. Kuigi, vastava määratlemise kohaselt loetakse „suureks“ tiimiks palju, on see 14+ inimest.

Vaatame mõningaid XP praktikaid ja kuidas need mõjutavad tagasiside kiirus ja kvaliteeti.

Tagasiside tsükli põhimõte XP-s

Minu arusaama kohaselt on tagasiside vastus küsimusele, kas ma teen õigesti ja kas me liigume õiges suunas? XP-s on selle kohta jumalik skeem: tagasiside tsükkel ajaliselt. Huvi seisneb selles, et mida madalamal me oleme, seda kiiremini saame võimaluse saada tagasisidet, et vastata vajalikele küsimustele.

See on üsna huvitav teema arutamiseks, et IT-tööstuses on võimalik kiiresti saada tagasisidet. Kujutage ette, kui keeruline on töötada mõne projekti kallal kuus kuud ja alles siis teada saada, et alguses tehti viga. See juhtub nii projekteerimisel kui ka keerukate süsteemide ülesehitamisel.

Meie juhul aitab IaC meid tagasiside. Teen kohe väikese paranduse ülalolevasse skeemi: väljaandmisplaan ei toimu kuutsüklina, vaid toimub mitu korda päevas. Selle tsükliga on seotud mõned praktikad, millest räägime põhjalikumalt.

Oluline: tagasiside võib olla lahendus kõigile ülaltoodud probleemidele. Koos XP praktikatega võib see meid tragöödia õhust välja tõmmata.

Kuidas end tragöödia õhust välja tõmmata: kolm praktikat

Testid

Testimised mainitakse XP tagasiside tsüklis kaks korda. See pole sugugi juhuslik. Need on äärmiselt olulised kogu äärmise programmeerimise tehnika jaoks.

Eeldatakse, et sul on olemas Unit ja Acceptance testid. Ühed annavad tagasisidet mõne minuti jooksul, teised aga mõne päeva jooksul, mistõttu neid kirjutatakse kauem ja nad läbivad harvemini.

On klassikaline testimise piramid, mis näitab, et teatud teste peaks olema rohkem.

Kuidas see skeem kehtib meile IaC projektis? Tegelikult… mitte kuidagi.

Unit testide arv, kuigi neid peaks olema väga palju, ei saa olla liiga suur. Kas nad testivad väga kaudselt midagi. Tegelikult võib öelda, et me ei kirjuta neid üldse. Siiski on meil mõningaid rakendusi, mida suutsime selliste testide jaoks teha:
1. Koodide testimine jsonnet'i peal. See on näiteks meie koostamisprotsess drone'is, mis on piisavalt keeruline. Kood jsonnetis katab end hästi testidega.
  Kasutame seda Unit testimise raamistik Jsonnet'ile.
2. Testid skriptide jaoks, mis toimivad ressursside käivitamisel. Skriptid on Pythonis, seega on ka testide kirjutamine võimalik.
Potentsiaalselt on võimalik kuvada konfiguratsiooni teste, kuid me ei tee seda. Samuti on võimalus seadistada ressursside konfigureerimise kontrollimise reeglite kontrollimist läbi tflint. Kuid Terraform'i jaoks on seal liiga põhilised kontrollid, kuid palju kontrollstsenaariume on kirjutatud AWS jaoks. Ja meie oleme Azure'is, nii et see ei sobi taas.
Komponentide integratsioonitestid: siin sõltub kõik sellest, kuidas sa neid klassifitseerid ja kuhu sa need jagad. Kuid põhimõtteliselt töötavad nad.
Nii näevad välja integratsioonitestid.

See on näide piltide koostamisest Drone CI-s. Et nendeni jõuda, tuleb oodata 30 minutit, kuni Packer'i pilt valmis saab, seejärel veel 15 minutit, kuni nad läbivad. Kuid need on olemas!
Piltide kontrollimise algoritm
1. Esmalt peab Packer pildi täielikult ette valmistama.
2. Testi kõrval on Terraform koos kohaliku olekuga, millega me seda pilti üles seame.
3. Käivitamisel kasutatakse väikest moodulit, mis asub kõrval, et pilti lihtsam kasutada.
4. Kui pildist on VM välja arendatud, saab alustada kontrollimist. Peamiselt viiakse kontrolle läbi masinas. Kontrollitakse, kuidas skriptid alguse juures toimisid ja kuidas demonid töötavad. Selleks siseneme läbi ssh või winrm just üles tõstetud masinasse ja kontrollime konfiguratsiooni olekut või kas teenused on aktiivsed.
Sarnane olukord on integratsioonitestidega ja Terraformi moodulitega. Siin on lühike tabel, mis selgitab selliste testide omadusi.

Tagasiside torustikus on umbes 40 minutit. Kõik toimub väga aeglaselt. Seda saab kasutada regressiooniks, kuid uue arenduse puhul on see täiesti ebatõenäoline. Kui väga-väga hästi selleks valmistuda, valmis olla, skriptid ette valmistada, siis on võimalik lühendada kuni 10 minutini. Kuid see ei ole siiski Unit-testid, mis 5 sekundiga 100 tükki teevad.

Unit-testide puudumine piltide või Terraformi moodulite kokkupanekul võtab töö erinevatele teenustele, mida saab REST-i kaudu lihtsalt kutsuda, või Python-skriptidele.

Näiteks pidime tegema nii, et virtuaalmasina käivitamisel registreerib see end teenusesse ScaleFT, ja kui virtuaalmasin eemaldatakse, kustutab see end.

Kuna ScaleFT on meil teenus, peame temaga töötama API kaudu. Seal on kirjutatud wrapper, mida saab kutsuda ja öelda: "Mine ja kustuta see, see". See hoiab kõiki vajalikke seadistusi ja ligipääse.

Selle peale saame juba kirjutada normaalseid teste, kuna see ei erine tavalisest tarkvarast: mingi API simuleeritakse, sa kutsud seda ja vaatame, mis juhtub.

Testide kokkuvõte: Unit-testimine, mis peaks andma operatsioonisüsteemile minutiga tulemuse, ei anna seda. Siiski kõrgemad testimise tasemed toovad mõju, kuid katavad vaid osa probleemidest.

Paarisarendus

Testid on kindlasti head. Neid saab kirjutada palju, nad võivad olla erinevat tüüpi. Nad töötavad oma tasemel ja annavad meile tagasisidet. Kuid probleem kehvade üksustestidega, mis pakuvad kõige kiiremat tagasisidet, jääb püsima. Samas on ikkagi soov kiiret operatsioonisüsteemi, millega on lihtne ja meeldiv töötada. Rääkimata saadud lahenduse kvaliteedist. Õnneks on olemas tehnikad, mis võimaldavad anda veel kiiremat tagasisidet kui moodulitestid. See on paarisarvestus.

Koodi kirjutades tahaks tagasisidet selle kvaliteedi kohta võimalikult kiiresti saada. Jah, kõik saab kirjutada funktsionaalses haru, et mitte kedagi segada, teha GitHubis pull request, nimetada keegi, kelle arvamus kaalub, ja oodata vastust.

Aga ootamine võib võtta kaua aega. Inimesed on kõik hõivatud ja vastus, isegi kui see tuleb, võib olla mitte kõige kvaliteetsem. Oletame, et vastus tuli kohe, ülevaataja mõistis kohe kogu kontseptsiooni, kuid vastus tuleb ikkagi hilinemisega, postfaktum. Ja see, et tahaks varem. Just paarisarvestus ongi suunatud sellele – et tagasiside tuleks kohe, kirjutamise hetkel.

Järgnevalt toon välja paarisarvestuse stiilid ja nende rakendatavus IaC töö tegemisel:

1. Klassikaline, kogenud+ kogenud, vahetus ajakava järgi. Kaks rolli – juht ja navigeerija. Kaks inimest. Nad töötavad ühe koodiga ja vahetavad rolle kindla aja jooksul.

Vaatame, kui hästi meie probleemid sobivad stiiliga:

Probleem: tööriistade, koodiarenduse vahendite puudulikkus.
Negatiivne mõju: areng kestab kauem, aeglustume, ritm/tempo kaob.
Kuidas lahendame: rakendame teisi tööriistu, jagame IDE-d ja õpime ka hotkeysid.
Probleem: aeglane juurutamine.
Negatiivne mõju: suurendab aega töötava koodiloo loomisele. Ootamise ajal igavleb, käed tahavad muid asju teha.
Kuidas lahendame: pole suurenenud.
Probleem: lähenede ja praktikate puudumine.
Negatiivne mõju: teadmise puudumine, kuidas teha hästi ja kuidas halvasti. Pika ugruli tagasiside saamine.
Kuidas lahendame: arvamuste ja praktikate vahetus paaritöö käigus lahendab täielikult probleemi.

Peamine probleem selle stiili rakendamisel IaC-s on töö ebaühtlane temp. Traditsioonilise tarkvaraarenduse puhul on sul väga ühtlane liikumine. Sa võid kulutada viis minutit ja kirjutada N. Kulutada 10 minutit ja kirjutada 2N, 15 minutit – 3N. Siin aga võid sa kulutada viis minutit ja kirjutada N ning siis kulutada veel 30 minutit ja kirjutada kümnendiku N-st. Siin sa ei tea midagi, sul on ummik, tõrge. Selgitamine võtab aega ja häirib otseselt programmeerimist.

Kokkuvõte: puhtal kujul ei sobi see meile.

2. Ping-pong. See lähenemine eeldab, et üks osaleja kirjutab testi, teine teostab selle rakenduse. Arvestades, et Unit-testidega on kõik keeruline ja tuleb kirjutada pikaaegne integratsioonitest, kaob kogu ping-pong’i kergus.

Võin öelda, et oleme proovinud kohustuste jagamist testi stsenaariumi koostamise ja koodi selle rakendamise vahel. Üks osaleja mõtles stsenaariumi välja, selles osas oli ta vastutav, tal oli viimane sõna. Teine vastutas rakendamise eest. See töötas hästi. Sellise lähenemise korral tõuseb stsenaariumi kvaliteet.

Kokkuvõte: kahjuks ei võimalda töö tempo ping-pong’i kasutada paarilise programmeerimise praktikana IaC-s.

3. Strong Style. Keeruline praktika.Idee on selles, et üks osaleja suunab ja juhib, teine mängib täitmise rolli. Samal ajal on otsuste tegemise õigus ainult juhil. Draiver lihtsalt kirjutab ja sõnaga saab toimuvatesse sekkuda. Rollid ei muutu kaua aega.

Sobib hästi õpetamiseks, kuid nõuab tugevaid pehmeid oskusi. Sellega meie takerdusime. Technik kulges keeruliselt. Ja asi pole isegi infrastruktuuris.

Kokkuvõte: potentsiaalselt võib rakendada, me ei jäta katsetamata.

4. Mobbing, swarming ja kõik teadaolevad, kuid siinkohal mitte loetletud stiilid ei arutle, kuna me ei ole proovinud ja ei saa sellega seoses meie töö kontekstis midagi öelda.

Üldised kokkuvõtted paarilise programmeerimise kasutamisest:

Meil on ebaühtlane töö tempo, mis segab.

Oleme takerdunud piisavalt hea pehme oskuste puudumisse. Ja aines ei soodusta nende puuduste ületamist.

Pikad testid ja tööriistade probleemid muudavad paarilise arendamise vaevatavaks.

5. Sellegipoolest on meil olnud ka edusamme. Me mõtlesime välja oma meetodi "Kokkuviimine - Lahkuviimine." Lühidalt kirjeldan, kuidas see töötab.

Meil on pidevad partnerid paariks päevaks ( vähem kui nädalaks). Teeme ühe ülesande koos. Mõnda aega oleme koos: üks kirjutab, teine istub ja vaatab, nagu tugimeeskond. Siis lahkume mõneks ajaks, igaüks teeb omi asju, seejärel tuleme jälle kokku, sünkroniseerime väga kiiresti, teeme midagi koos ja lahkume jälle.

Planeerimine ja kommunikatsioon

Viimane plokk praktikast, mille kaudu lahendatakse operatsioonisüsteemi probleeme, on ülesannete korraldamine. Siia kuulub ka kogemuste vahetamine, mis on väljaspool paaristööd. Vaatame kolme praktikat:

1. Ülesanded eesmärkide puu kaudu. Projektijuhtimine on organiseeritud puu kaudu, mis ulatub lõputult tulevikku. Tehniliselt toimub juhtimine Miro's. On olemas üks ülesanne - see on vahe-eesmärk. Sellelt lähenevad kas väiksemad eesmärgid või ülesannete grupid. Nendest tulevad juba konkreetsed ülesanded. Kõik ülesanded luuakse ja hallatakse sellel tahvlil.

See skeem annab ka tagasisidet, mis toimub üks kord päevas, kui sünkroniseerime end koosolekutel. Ühise, samas struktureeritud ja täiesti avatud plaani olemasolu võimaldab kõigil olla kursis toimuvaga ja sellega, kui kaugele me progressis oleme jõudnud.

Ülesannete visuaalse nägemise eelised:

Põhjuse seos. Iga ülesanne viib mõne globaalse eesmärgini. Ülesanded grupeeritakse väiksemate eesmärkide järgi. Infrastruktuuri domeen iseenesest on üsna tehniline. Mitte alati ei ole kohe selge, millist konkreetset mõju ärile avaldab näiteks migreerimise käsiraamatu kirjutamine teise nginx-i peale. Ühise sihtkaardi olemasolu teeb selle arusaadavamaks.

Põhjuse seos on ülesannete oluline omadus. See vastab otseselt küsimusele: "Kas ma teen ikka õiget asja?"
Paralleelsus. Meid on üheksa inimest ja kõikide ründamine ühele ülesandele pole füüsiliselt võimalik. Ükski ala ei pruugi alati piisavalt ülesandeid pakkuda. Oleme sunnitud oma tööd paralleelselt jagama väikeste töörühmade vahel. Samal ajal istuvad grupid mõnda aega oma ülesande juures, neid võib tugevdada keegi veel. Mõnikord lahkuvad inimesed sellest töörühmast. Keegi läheb puhkusele, keegi teeb ettekannet DevOps conf konverentsil, keegi kirjutab artiklit Habr'ile. Teada, milliseid eesmärke ja ülesandeid saab paralleelselt teha, on väga oluline.

2. Vahetatavad juhtivad hommikused koosolekud. Standupides tekkis selline probleem – inimesed teevad palju ülesandeid paralleelselt. Mõnikord on ülesanded nõrgalt seotud ja ei ole arusaama, kes mida teeb. Ja ühe meeskonna liikme arvamus on väga oluline. See on täiendav teave, mis suudab muuta ülesande lahendamise käiku. Loomulikult on tavaliselt koos sinuga keegi paaris, kuid nõuanne ja vihjed pole kunagi üleliigsed.

Selle olukorra parandamiseks rakendasime tehnika „Standupi juhi vahetamine“. Nüüd nad rotseerivad kindlatel nimistuil, ja see annab oma efekti. Kui sinu kord kätte saab, oled sunnitud süvenema ja mõistma, mis toimub, et hästi läbi viia scrumi koosolek.

3. Sisemine demo. Abiks ülesande lahendamisel paarilise programmeerimise kaudu, ülesannete puu visualiseerimine ja hommikul scrumi koosolekutel abistamine – see on hea, kuid mitte ideaalne. Paaris oled piiratud vaid oma teadmistest. Ülesannete puu aitab globaalselt mõista, kes ja mida teeb. Ja juht ning kolleegid hommikul kohtumisel ei süvene sügavale sinu probleemidesse. Nad võivad tõesti midagi tähelepanuta jätta.

Lahendus leiti demonstreerides tehtud tööd üksteisele ja seejärel arutades neid. Koome kord nädalas tunniks kokku ja näitame ülesannete lahenduste detaile, mida oleme viimase nädala jooksul teinud.

Demonstreerimise protsessis tuleb ülesande detaile paljastada ja kindlasti demonstreerida selle toimimist.

Ettekannet saab teha kontrollnimekirja alusel.1. Viige konteksti. Kust tuli ülesanne, miks see üldse vajalik oli?

2. Kuidas ülesanne varem lahendati? Näiteks, oli vajalik massiivne hiireklikkimine või oli midagi täiesti võimatu teha.

3. Kuidas me seda parendame. Näiteks: „Vaadake, nüüd on skript, siin on readme“.

4. Näidake, kuidas see töötab. Soovitavalt viia läbi mõni kasutaja stsenaarium. Tahan X, teen Y, näen Z (või Y). Näiteks, deplooin NGINX-i, vaatan URL-i, saan 200 OK. Kui tegevus võtab kaua aega, valmistage see ette varem, et hiljem näidata. Soovitavalt, et tund enne demonstreerimist ei rikuks seda liiga palju.

5. Selgitage, kui hästi probleem on lahendatud, millised raskused on jäänud, mis on lõpetamata, millised täiustused on tulevikus võimalikud. Näiteks, praegu on cli, hiljem tuleb täielik automatiseerimine CI-s.

Iga esineja peaks jääma 5-10 minuti piiridesse. Kui teie esitlus on juba niikuinii oluline ja võtab rohkem aega, leppige see eelnevalt kokku kanalis sre-takeover.

Pärast otse esitlust järgneb kindlasti arutelu teemas. Just siis ilmneb vajalik tagasiside meie ülesannete kohta.

Kokkuvõttes viiakse läbi küsitlus, et välja selgitada toimuva kasulikkus. See on juba tagasiside enda esituse sisu ja ülesande olulisuse kohta.

Pikad kokkuvõtted ja mis edasi

Võib tunduda, et artikli toon on mõnevõrra pessimistlik. See pole nii. Kaks madalamat taset tagasiside saamiseks, nimelt testid ja paaritöö, toimivad. Mitte nii täielikult kui traditsioonilises arenduses, kuid positiivne efekt on olemas.

Testid, oma praeguses vormis, annavad vaid osalise katvuse koodis. Palju konfiguratsioonifunktsioone jääb katsetamata. Nende mõju otsesele tööle koodi kirjutamisel on madal. Siiski on integratsioonitestidel mõju ning just need võimaldavad muretu refaktoreerimist. See on suur saavutus. Samuti probleem kaob, kui fookus suunatakse kõrgema taseme programmeerimiskeeltele (meil on python, go). Ja liimiks on palju kontrollimist ja pole vaja, piisab üldisest integratsioonitestist.

Töö paaris sõltub rohkem konkreetsetest inimestest. On ülesande tegur ja meie pehmed oskused. Kellegagi töötab väga hästi, kellegagi halvemini. Sellest on kindlasti kasu. Selge on, et isegi paari töö reeglite kasutamise puudumise korral mõjutab koos ülesannete täitmine positiivselt tulemuse kvaliteeti. Isiklikult on mul paaris töötada lihtsam ja meeldivam.

Kõrgema taseme meetodid mõju avaldamiseks operatsioonisüsteemile – planeerimine ja ülesannetega töötamine toovad kindlasti tulemusi: kvaliteetne teadmiste vahetus ja arenduse kvaliteedi paranemine.