Sveiki, Habr! Anksčiau skundžiausi gyvenimu Infrastruktūroje kaip kodo paradigma ir nieko nesiūliau, kaip išspręsti esamą situaciją. Šiandien grįžtu ir papasakosiu, kokie požiūriai ir praktika padės ištrūkti iš nevilties bedugnės ir nukreipti situaciją tinkama linkme.
Ankstesniame straipsnyje Dalinausi savo įspūdžiais apie šią sritį, bandžiau apmąstyti esamą situaciją šioje srityje, netgi pasiūliau, kad gali padėti visiems kūrėjams žinomos standartinės praktikos. Gali atrodyti, kad skundų gyvenimu buvo daug, tačiau pasiūlymų, kaip išeiti iš esamos padėties, nebuvo.
Kas mes esame, kur esame ir kokių problemų turime
Šiuo metu esame Sre Onboarding Team, kurią sudaro šeši programuotojai ir trys infrastruktūros inžinieriai. Mes visi bandome parašyti infrastruktūrą kaip kodą (IaC). Mes tai darome, nes iš esmės žinome, kaip rašyti kodą, ir esame „virš vidurkio“ kūrėjai.
- Turime aibę privalumų: tam tikras išsilavinimas, praktikų išmanymas, gebėjimas rašyti kodą, noras išmokti naujų dalykų.
- Ir yra suglebusi dalis, kuri taip pat yra minusas: žinių apie infrastruktūros techninę įrangą trūkumas.
Technologijų krūva, kurią naudojame savo IaC.
- Terraforma išteklių kūrimui.
- Pakuotė vaizdams surinkti. Tai yra „Windows“, „CentOS 7“ vaizdai.
- Jsonnet, kad sukurtumėte galingą versiją drone.io, taip pat sugeneruotumėte pakerio json ir mūsų terraforminius modulius.
- „Azure“.
- Galima rengiant vaizdus.
- Python, skirtas pagalbinėms paslaugoms ir scenarijų teikimui.
- Ir visa tai VSCode su įskiepiais, kuriais dalijasi komandos nariai.
Išvada iš mano buvo taip: bandžiau įskiepyti (pirmiausia sau) optimizmo, norėjau pasakyti, kad išbandysime mums žinomus požiūrius ir praktikas, kad susitvarkytume su šioje srityje egzistuojančiais sunkumais ir kompleksais.
Šiuo metu kovojame su šiomis IaC problemomis:
- Kodo kūrimo įrankių ir priemonių netobulumas.
- Lėtas diegimas. Infrastruktūra yra realaus pasaulio dalis ir gali būti lėta.
- Trūksta požiūrių ir praktikos.
- Mes nauji ir daug ko nežinome.
Ekstremalus programavimas (XP) į pagalbą
Visi kūrėjai yra susipažinę su ekstremaliu programavimu (XP) ir jo praktika. Daugelis iš mūsų dirbo taikydami šį metodą, ir tai buvo sėkminga. Taigi kodėl nepasinaudojus ten išdėstytais principais ir praktika, kad būtų galima įveikti infrastruktūros iššūkius? Nusprendėme laikytis tokio požiūrio ir pažiūrėti, kas atsitiks.
XP metodo pritaikymo jūsų pramonei patikrinimasČia aprašoma aplinka, kuriai XP puikiai tinka, ir kaip ji susijusi su mumis:
1. Dinamiškai besikeičiantys programinės įrangos reikalavimai. Mums buvo aišku, koks galutinis tikslas. Tačiau detalės gali skirtis. Mes patys nusprendžiame, kur mums reikia taksi, todėl reikalavimai periodiškai keičiasi (daugiausia mes patys). Jei paimtume SRE komandą, kuri pati atlieka automatizavimą ir pati riboja reikalavimus bei darbų apimtis, tai šis punktas puikiai tinka.
2. Rizika, kurią sukelia fiksuoto laiko projektai naudojant naujas technologijas. Naudodami kai kuriuos mums nežinomus dalykus galime susidurti su rizika. Ir tai yra 100% mūsų atvejis. Visas mūsų projektas buvo technologijų, su kuriomis nebuvome iki galo susipažinę, naudojimas. Apskritai tai yra nuolatinė problema, nes... Infrastruktūros sektoriuje nuolat atsiranda daug naujų technologijų.
3,4. Maža, kartu įsikūrusi išplėstinė kūrimo komanda. Naudojama automatizuota technologija leidžia atlikti įrenginio ir funkcinius bandymus. Šie du punktai mums ne visai tinka. Pirma, nesame koordinuota komanda, antra, mūsų yra devyni, kuriuos galima laikyti didele komanda. Nors pagal kai kuriuos „didelės“ komandos apibrėžimus daug yra 14+ žmonių.
Pažvelkime į kai kurias XP praktikas ir kaip jos veikia grįžtamojo ryšio greitį ir kokybę.
XP grįžtamojo ryšio ciklo principas
Mano supratimu, grįžtamasis ryšys yra atsakymas į klausimą, ar aš elgiuosi teisingai, ar mes ten einame? XP tam turi dievišką schemą: laiko grįžtamojo ryšio kilpą. Įdomu tai, kad kuo žemiau esame, tuo greičiau galime priversti OS atsakyti į reikiamus klausimus.
Tai gana įdomi tema diskusijoms, kad mūsų IT pramonėje galima greitai gauti OS. Įsivaizduokite, kaip skaudu šešis mėnesius daryti projektą ir tik tada sužinoti, kad pačioje pradžioje buvo klaida. Tai atsitinka projektuojant ir kuriant sudėtingas sistemas.
Mūsų IaC atveju grįžtamasis ryšys mums padeda. Nedelsdamas šiek tiek pakoreguosiu aukščiau pateiktą diagramą: išleidimo planas neturi mėnesio ciklo, bet vyksta kelis kartus per dieną. Yra keletas su šiuo OS ciklu susijusių praktikų, kurias apžvelgsime išsamiau.
Svarbu: atsiliepimai gali būti visų aukščiau išvardytų problemų sprendimas. Kartu su XP praktika jis gali ištraukti jus iš nevilties bedugnės.
Kaip ištraukti save iš nevilties bedugnės: trys praktikos
Testai
XP grįžtamojo ryšio kilpoje testai paminėti du kartus. Tai ne tik taip. Jie yra nepaprastai svarbūs visai ekstremalaus programavimo technikai.
Daroma prielaida, kad turite vieneto ir priėmimo testus. Vieni atsiliepimą pateikia per kelias minutes, kiti – per kelias dienas, todėl jų rašymas užtrunka ilgiau ir peržiūrimas rečiau.
Yra klasikinė testavimo piramidė, kuri rodo, kad testų turėtų būti daugiau.
Kaip ši sistema mums taikoma IaC projekte? Tiesą sakant... visai ne.
- Vienetinių testų, nepaisant to, kad jų turėtų būti daug, negali būti per daug. Arba jie kažką labai netiesiogiai išbando. Tiesą sakant, galime sakyti, kad mes jų visai nerašome. Tačiau čia yra keletas tokių testų programų, kurias galėjome atlikti:
- Jsonnet kodo testavimas. Tai, pavyzdžiui, mūsų drono surinkimo vamzdynas, kuris yra gana sudėtingas. Jsonnet kodas yra gerai atliktas testais.
Mes naudojame tai . - Testuoja scenarijus, kurie vykdomi paleidus šaltinį. Scenarijai rašomi Python, todėl jais galima rašyti testus.
- Jsonnet kodo testavimas. Tai, pavyzdžiui, mūsų drono surinkimo vamzdynas, kuris yra gana sudėtingas. Jsonnet kodas yra gerai atliktas testais.
- Potencialiai galima patikrinti konfigūraciją testuose, bet mes to nedarome. Taip pat galima konfigūruoti tikrinimo išteklių konfigūracijos taisykles per . Tačiau ten esantys patikrinimai yra tiesiog per paprasti terraformai, tačiau daugelis bandomųjų scenarijų yra parašyti AWS. Mes naudojamės Azure, todėl tai vėlgi netaikoma.
- Komponentų integravimo testai: tai priklauso nuo to, kaip juos klasifikuojate ir kur juos įdėjote. Bet jie iš esmės veikia.
Taip atrodo integracijos testai.
Tai pavyzdys kuriant vaizdus naudojant Drone CI. Norėdami juos pasiekti, turite palaukti 30 minučių, kol susidarys „Packer“ vaizdas, tada palaukite dar 15 minučių, kol jie praeis. Bet jie egzistuoja!Vaizdo tikrinimo algoritmas
- Pakuotojas pirmiausia turi visiškai paruošti vaizdą.
- Šalia bandymo yra terraforma su vietine būsena, kurią naudojame šiam vaizdui panaudoti.
- Išskleidžiant, naudojamas šalia gulintis nedidelis modulis, kad būtų lengviau dirbti su vaizdu.
- Kai VM bus įdiegtas iš vaizdo, patikrinimai gali prasidėti. Iš esmės patikrinimai atliekami automobiliu. Ji tikrina, kaip scenarijai veikė paleidžiant ir kaip veikia demonai. Norėdami tai padaryti, per ssh arba winrm prisijungiame prie naujai sukurto įrenginio ir patikriname konfigūracijos būseną arba ar paslaugos veikia.
- Panaši situacija yra ir su terraformų modulių integravimo testais. Pateikiame trumpą lentelę, paaiškinančią tokių testų ypatybes.
Atsiliepimai apie dujotiekį trunka apie 40 minučių. Viskas vyksta labai ilgai. Jis gali būti naudojamas regresijai, bet naujai plėtrai paprastai nerealu. Jei esate tam labai labai pasiruošę, paruoškite vykdomus scenarijus, tada galite jį sumažinti iki 10 minučių. Bet tai vis tiek nėra vienetiniai testai, kurie 5 dalių atlieka per 100 sekundes.
Vienetinių testų nebuvimas renkant vaizdus ar terraforminius modulius skatina darbą perkelti į atskiras paslaugas, kurias galima tiesiog paleisti per REST, arba į Python scenarijus.
Pavyzdžiui, turėjome įsitikinti, kad paleidus virtualią mašiną ji užsiregistruoja tarnyboje , o kai virtuali mašina buvo sunaikinta, ji pati išsitrynė.
Kadangi turime ScaleFT kaip paslaugą, esame priversti dirbti su ja per API. Ten buvo parašyta įvynioklis, kurį galima traukti ir pasakyti: „Eik ir ištrink šį bei tą“. Jame saugomi visi reikalingi nustatymai ir prieigos.
Tam jau galime rašyti normalius testus, nes tai niekuo nesiskiria nuo įprastos programinės įrangos: pasišaipo iš kažkokios apihos, trauki, o kas bus.
Testų rezultatai: Vienetinis testavimas, kuris turėtų duoti OS per minutę, jo neduoda. Ir aukščiau piramidės testavimo tipai yra veiksmingi, tačiau apima tik dalį problemų.
Porinis programavimas
Testai, žinoma, yra geri. Galite parašyti jų daug, jie gali būti įvairių tipų. Jie dirbs savo lygiu ir pateiks mums atsiliepimų. Tačiau problema dėl blogų vienetų testų, kurie pateikia greičiausią OS, išlieka. Tuo pačiu metu aš vis dar noriu greitos OS, su kuria būtų lengva ir malonu dirbti. Jau nekalbant apie gauto tirpalo kokybę. Laimei, yra būdų, kurie gali suteikti dar greitesnį grįžtamąjį ryšį nei vienetiniai testai. Tai porinis programavimas.
Rašydami kodą norite kuo greičiau gauti atsiliepimų apie jo kokybę. Taip, galite viską įrašyti į funkcijų šaką (kad niekam nieko nesugadintumėte), pateikti užklausą „Github“, priskirti ją kam nors, kurio nuomonė turi svarbos, ir laukti atsakymo.
Bet jūs galite laukti ilgai. Žmonės visi užsiėmę, o atsakymas, net jei ir yra, gali būti ne pats kokybiškiausias. Tarkime, kad atsakymas atėjo iš karto, recenzentas akimirksniu suprato visą mintį, bet atsakymas vis tiek ateina vėlai, po to. Norėčiau, kad tai būtų anksčiau. Būtent į tai ir yra skirtas porinis programavimas – iš karto, rašant.
Žemiau pateikiami porų programavimo stiliai ir jų pritaikymas dirbant su IaC:
1. Klasikinis, patyręs+patyręs, perėjimas pagal laikmatį. Du vaidmenys – vairuotojas ir navigatorius. Du žmonės. Jie dirba su tuo pačiu kodu ir keičia vaidmenis po tam tikro iš anksto nustatyto laiko.
Panagrinėkime mūsų problemų suderinamumą su stiliumi:
- Problema: kodo kūrimo įrankių ir įrankių netobulumas.
Neigiamas poveikis: vystosi ilgiau, sulėtėjame, pasiklysta darbo tempas/ritmas.
Kaip kovojame: naudojame skirtingus įrankius, bendrą IDE ir taip pat mokomės sparčiųjų klavišų. - Problema: lėtas diegimas.
Neigiamas poveikis: pailgėja laikas, kurio reikia norint sukurti veikiančią kodo dalį. Laukdami nusibostame, rankos tiesiasi dar ką nors padaryti, kol laukiame.
Kaip mes kovojame: neįveikėme. - Problema: požiūrių ir praktikos trūkumas.
Neigiamas poveikis: nėra žinių, kaip tai padaryti gerai ir kaip blogai. Prailgina atsiliepimų gavimą.
Kaip kovojame: abipusis keitimasis nuomonėmis ir praktika porose beveik išsprendžia problemą.
Pagrindinė šio stiliaus naudojimo IaC problema yra netolygus darbo tempas. Kurdami tradicinę programinę įrangą, judėjimas yra labai vienodas. Galite skirti penkias minutes ir parašyti N. Skirkite 10 minučių ir parašykite 2N, 15 minučių – 3N. Čia gali sugaišti penkias minutes ir parašyti N, o paskui dar 30 minučių parašyti dešimtadalį N. Čia tu nieko nežinai, tu įklimpęs, kvailys. Tyrimas užtrunka ir atitraukia dėmesį nuo paties programavimo.
Išvada: gryna forma jis mums netinka.
2. Ping-pong. Taikant šį metodą, vienas asmuo rašo testą, o kitas atlieka jo įgyvendinimą. Atsižvelgiant į tai, kad su vienetiniais testais viskas yra sudėtinga ir reikia parašyti integracijos testą, kurio programavimas užtrunka ilgai, visas stalo teniso patogumas išnyksta.
Galiu pasakyti, kad bandėme atskirti atsakomybes kuriant bandomąjį scenarijų ir įdiegiant jo kodą. Vienas dalyvis sugalvojo scenarijų, už šią darbo dalį jis buvo atsakingas, jam priklausė paskutinis žodis. O kitas buvo atsakingas už įgyvendinimą. Tai pavyko gerai. Taikant šį metodą, scenarijaus kokybė didėja.
Išvada: deja, darbo tempas neleidžia naudoti ping-pong kaip porinio programavimo praktikos IaC.
3. Stiprus stilius. . Idėja yra ta, kad vienas dalyvis tampa nurodymų navigatoriumi, o antrasis atlieka vykdymo vairuotojo vaidmenį. Šiuo atveju teisę priimti sprendimus turi išimtinai navigatorius. Vairuotojas tik spausdina ir žodžiu gali paveikti tai, kas vyksta. Vaidmenys nesikeičia ilgą laiką.
Tinka mokymuisi, bet reikalauja stiprių minkštųjų įgūdžių. Čia mes susvyravome. Technika buvo sunki. Ir tai net ne apie infrastruktūrą.
Išvada: tai potencialiai gali būti panaudota, mes nepasiduodame bandydami.
4. Mobingas, spiečius ir visi žinomi, bet neišvardinti stiliai Mes to nesvarstome, nes Mes to nebandėme ir apie tai neįmanoma kalbėti mūsų darbo kontekste.
Bendrieji porinio programavimo rezultatai:
- Mūsų darbo tempas netolygus, o tai glumina.
- Mes susidūrėme su nepakankamai gerais minkštais įgūdžiais. Ir dalykinė sritis nepadeda įveikti šių mūsų trūkumų.
- Ilgi bandymai ir problemos su įrankiais apsunkina porinį kūrimą.
5. Nepaisant to, buvo pasisekimų. Mes sugalvojome savo metodą „Konvergencija – išsiskyrimas“. Trumpai aprašysiu, kaip tai veikia.
Turime nuolatinius partnerius kelioms dienoms (mažiau nei savaitei). Vieną užduotį atliekame kartu. Kurį laiką sėdime kartu: vienas rašo, kitas sėdi ir stebi palaikymo komandą. Tada kurį laiką išsiskirstome, kiekvienas darome kokius nors savarankiškus dalykus, tada vėl susirenkame, labai greitai sinchronizuojamės, kažką darome kartu ir vėl išsiskirstome.
Planavimas ir bendravimas
Paskutinis praktikų blokas, per kurį sprendžiamos OS problemos, yra darbo su pačiomis užduotimis organizavimas. Tai taip pat apima keitimąsi patirtimi, kuri vyksta ne dirbant poromis. Pažvelkime į tris praktikas:
1. Tikslai per tikslų medį. Mes organizavome bendrą projekto valdymą per medį, kuris be galo eina į ateitį. Techniškai sekimas atliekamas Miro. Yra viena užduotis – tai tarpinis tikslas. Iš jo eina arba mažesni tikslai, arba užduočių grupės. Iš jų kyla pačios užduotys. Visos užduotys kuriamos ir prižiūrimos šioje lentoje.
Ši schema taip pat suteikia grįžtamąjį ryšį, kuris atsiranda kartą per dieną, kai sinchronizuojamės mitinguose. Bendras planas prieš visus, bet struktūrizuotas ir visiškai atviras, leidžia kiekvienam žinoti, kas vyksta ir kiek pažengėme į priekį.
Užduočių vizualinio matymo pranašumai:
- Priežastingumas. Kiekviena užduotis veda į tam tikrą visuotinį tikslą. Užduotys sugrupuojamos į mažesnius tikslus. Pats infrastruktūros domenas yra gana techninis. Ne visada iš karto aišku, kokį konkretų poveikį verslui turi, pavyzdžiui, perėjimo į kitą nginx „runbook“ parašymas. Netoliese esant tikslinei kortelei, ji tampa aiškiau.
Priežastinis ryšys yra svarbi problemų savybė. Tai tiesiogiai atsako į klausimą: „Ar aš darau teisingai? - Lygiagretumas. Mūsų yra devyni, ir tiesiog fiziškai neįmanoma mesti visų į vieną užduotį. Vienos srities užduočių taip pat ne visada gali pakakti. Esame priversti lygiagretinti darbą tarp mažų darbo grupių. Tuo pačiu metu grupės kurį laiką atlieka savo užduotį, jas gali sustiprinti kas nors kitas. Kartais žmonės atitrūksta nuo šios darbo grupės. Kažkas išvyksta atostogų, kažkas daro ataskaitą DevOps konf., kažkas rašo straipsnį apie Habr. Labai svarbu žinoti, kokius tikslus ir užduotis galima atlikti lygiagrečiai.
2. Pakaitiniai rytinių susirinkimų vedėjai. Atsistodami turime tokią problemą – žmonės daug užduočių atlieka lygiagrečiai. Kartais užduotys yra laisvai susijusios ir nėra supratimo, kas ką daro. O kito komandos nario nuomonė labai svarbi. Tai papildoma informacija, kuri gali pakeisti problemos sprendimo eigą. Žinoma, dažniausiai su tavimi kas nors būna, bet patarimai ir patarimai visada praverčia.
Siekdami pagerinti šią situaciją, panaudojome techniką „Pasikeitimas pirmaujančiu stovėjimu“. Dabar jie kaitomi pagal tam tikrą sąrašą, ir tai turi savo poveikį. Kai ateina jūsų eilė, esate priversti pasinerti ir suprasti, kas vyksta, kad surengtumėte gerą „Scrum“ susitikimą.
3. Vidinė demonstracinė versija. Pagalba sprendžiant problemą iš porinio programavimo, vizualizavimo problemų medyje ir pagalba scrum susitikimuose ryte yra gera, bet ne ideali. Kaip porą jus riboja tik jūsų žinios. Užduočių medis padeda pasauliniu mastu suprasti, kas ką daro. O vedėjas ir kolegos rytiniame susitikime į jūsų problemas nesigilins. Jie tikrai gali ką nors praleisti.
Išeitis buvo rasta demonstruojant vieni kitiems atliktus darbus, o vėliau juos aptariant. Mes susitinkame kartą per savaitę valandai ir parodome išsamią informaciją apie per pastarąją savaitę atliktų užduočių sprendimus.
Demonstravimo metu būtina atskleisti užduoties detales ir būtinai pademonstruoti jos veikimą.
Ataskaita gali būti parengta naudojant kontrolinį sąrašą.1. Įeikite į kontekstą. Iš kur atsirado užduotis, kodėl ji buvo reikalinga?
2. Kaip problema buvo sprendžiama anksčiau? Pavyzdžiui, reikėjo masiškai spustelėti pelę arba iš viso nieko nebuvo įmanoma padaryti.
3. Kaip mes jį tobuliname. Pavyzdžiui: „Žiūrėk, dabar yra scriptosik, čia yra readme“.
4. Parodykite, kaip tai veikia. Patartina tiesiogiai įgyvendinti tam tikrą vartotojo scenarijų. Noriu X, darau Y, matau Y (arba Z). Pavyzdžiui, aš įdiegiu NGINX, išrūkau URL ir gaunu 200 OK. Jei veiksmas ilgas, pasiruoškite jį iš anksto, kad galėtumėte parodyti vėliau. Patartina jo per daug nesulaužyti likus valandai iki demonstracijos, jei ji trapi.
5. Paaiškinkite, kaip sėkmingai buvo išspręsta problema, kokių sunkumų liko, kas nebaigta, kokie galimi patobulinimai ateityje. Pavyzdžiui, dabar CLI, tada CI bus pilna automatizacija.
Kiekvienam garsiakalbiui patartina išlaikyti 5–10 minučių. Jei jūsų kalba akivaizdžiai svarbi ir užtruks ilgiau, suderinkite tai iš anksto sre-takeover kanale.
Po akis į akį dalies gijoje visada vyksta diskusija. Čia pasirodo atsiliepimai, kurių mums reikia apie savo užduotis.
Dėl to atliekama apklausa, siekiant nustatyti to, kas vyksta, naudingumą. Tai grįžtamasis ryšys apie kalbos esmę ir užduoties svarbą.
Ilgos išvados ir kas toliau
Gali atrodyti, kad straipsnio tonas yra šiek tiek pesimistiškas. Tai yra blogai. Veikia du žemesni grįžtamojo ryšio lygiai, būtent testai ir porinis programavimas. Ne taip tobula, kaip tradicinėje plėtroje, tačiau tai turi teigiamą poveikį.
Testai dabartine forma suteikia tik dalinį kodo aprėptį. Daugelis konfigūravimo funkcijų lieka neišbandytos. Jų įtaka realiam darbui rašant kodą yra maža. Tačiau integracijos testai turi poveikį ir leidžia be baimės atlikti pertvarkymus. Tai puikus pasiekimas. Be to, sutelkus dėmesį į aukšto lygio kalbų kūrimą (turime python, go), problema išnyksta. Ir nereikia daug tikrinti „klijų“, užtenka bendro integravimo patikrinimo.
Darbas poromis labiau priklauso nuo konkrečių žmonių. Yra užduoties veiksnys ir mūsų minkštieji įgūdžiai. Vieniems pavyksta labai gerai, kitiems – prasčiau. Iš to tikrai yra naudos. Akivaizdu, kad net ir nepakankamai laikantis darbo poromis taisyklių, pats užduočių atlikimo kartu faktas turi teigiamos įtakos rezultato kokybei. Asmeniškai man lengviau ir maloniau dirbti poromis.
Aukštesnio lygio įtakos OS būdai – tikslų planavimas ir darbas su užduotimis duoda efektų: kokybiškus žinių mainus ir geresnę kūrimo kokybę.
Trumpos išvados vienoje eilutėje
- HR specialistai dirba IaC, bet mažiau efektyviai.
- Stiprinti tai, kas veikia.
- Sugalvokite savo kompensavimo mechanizmus ir praktiką.
Šaltinis: www.habr.com