🥇Infrastructure as Code: kuidas probleemidega tegeleda XP abil

Tere, Habr! Varem kaebasin ma elu üle, mis põhines Infrastructure as code paradigmil, ning ei pakkunud lahendusi olemasolevale olukorrale. Täna olen tagasi, et rääkida lähenemistest ja praktikatest, mis aitavad pääseda meeleheitevõimest ja suunata olukord õiges suunas.

Eelnevas artiklis „Infrastructure as code: esimene tutvumine“ Olen jaganud oma muljeid selle valdkonna kohta, püüdnud mõelda praegusele olukorrale ja isegi oletanud, et kõik tuntud praktikad, mis on arendajatele teada, võivad abiks olla. Võis tunduda, et seal oli palju kaebusi elu üle, kuid mitte ühtegi väljapakutud lahendust.

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

Oleme praegu Sre Onboarding Teamis, mis koosneb kuuest programmeerijast ja kolmest infrastruktuuriinsenerist. Kõik püüame kirjutada Infrastructure as code (IaC). Teeme seda, sest põhimõtteliselt oskame kirjutada koodi ja meil on arenguharidus tasemel 'üle keskmise'.

Meil on mitmeid plusse: teatud taust, praktiliste teadmiste oskus, koodikirjutamise oskus ja soov õppida uut.
Ja on ka nõrk koht, mis on miinus: infrastruktuuri teoreetiliste teadmiste puudumine.

Tehnoloogiad, mida me oma IaC-s rakendame.

Terraform ressursside loomiseks.
Packer piltide koostamiseks. Need on Windows, CentOS 7 pildid.
Jsonnet, et luua võimas kogum drone.io-s ning genereerida packer json ja meie Terraformi mooduleid.
Azure.
Ansible piltide ettevalmistamisel.
Python abiteenuste ja provizionimise skriptide jaoks.
Ja kõik see VSCode'is pluginate abil, mida jagavad meeskonna liikmed.

Minu eelmisest artiklist tuli selline järeldus: ma püüdsin sisendada (esmajärjekorras endasse) optimismi, soovisin öelda, et proovime tuntud lähenemisi ja tavasid, et võidelda selle valdkonna raskuste ja probleemidega.

Praegu seisame silmitsi järgmiste IaC probleemidega:

Tööriistade, koodiarenduse vahendite puudulikkus.
Aeglane juurutamine. Infrastruktuur on osa reaalsest maailmast ja see võib olla aeglane.
Lähenemiste ja praktikate puudumine.
Me oleme uued ja ei tea palju.

Ekstremalne programmeerimine (XP) kiirendab appi.

Kõigile arendajatele on hästi tuttav äärmuslik programmeerimine (XP) ja selle taga olevad praktikad. Paljudele meist on lähenemine tuttav ja see on olnud edukas. Miks mitte kasutada sealsete põhimõtete ja praktikate rakendamist, et tõhusalt lahendada infrastruktuuri väljakutseid? Otsustasime selle lähenemise rakendada ja vaadata, mis sellest välja tuleb.

XP lähenemise rakendamise sobivuse kontrollimine teie valdkonnasKirjeldan keskkonda, mille jaoks XP sobib hästi, ja kuidas see meiega seondub:

1. Dünaamiliselt muutuvaid tarkvaranõudeid. Meil oli selge, mis on lõppeesmärk. Kuid detailides võib varieerida. Me otsustame ise, kuhu suunduda, seega nõuded muutuvad perioodiliselt (enamasti meie enda poolt). Kui võtta SRE meeskond, kes ise teeb automatiseerimise ja piirab nõudeid ja töö ulatust, siis see punkt sobib hästi.

2. Uued tehnoloogiad toovad projekti fikseeritud ajaga seotud riskid. Meie võime sattuda riskidesse, kui kasutame midagi meile tundmatut. See on 100% meie juhtum. Kogu meie projekt põhineb tehnoloogiatel, millega me polnud lõpuni tuttavad. See on pidev probleem, kuna infrastruktuuri valdkonnas tekib pidevalt uusi tehnoloogiaid.

3,4. Väike, samas asuv laiendatud arendustiim. Kasutatav tehnoloogia võimaldab automatiseeritud üksuste ja funktsionaalsete testide läbiviimist. Need kaks punkti ei sobi meile täpselt. Esiteks, me pole kolokatsiooniga meeskond ja teiseks, meid on üheksa, mis võib olla suur tiim. Kuigi mõnede definitsioonide järgi on "suur" meeskond see, kus on 14+ inimest.

Kaalume mõningaid XP praktikaid ja kuidas need mõjutavad tagasiside kiirus ja kvaliteet.

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

Minu arusaama kohaselt on tagasiside vastus küsimusele, kas ma teen õiget asja ja kas me liigume õigesse suunda? XP-s on selle kohta jumalik skeem: ajaliselt tagasiside tsükkel. Huvi seisneb selles, et mida madalamal me oleme, seda kiiremini saame OS-i, et vastata vajalikele küsimustele.

See on tõeliselt huvitav teema arutamiseks, et meie IT-tööstuses on võimalik kiiresti operatsioonisüsteem saada. Kujutage ette, kui valus on töötada mingi projektiga kuus kuud ja alles seejärel avastada, et alguses tehti viga. Selliseid olukordi juhtub nii projekteerimises kui ka keerukate süsteemide ehitamisel.

Meie juhul aitab IaC meil tagasisidet saada. Teen skeemis väikese paranduse: väljaandmisplaan ei toimu kuu tsüklina, vaid mitu korda päevas. Selle tsükli raames on seotud teatud praktikad, mida vaatame lähemalt.

Oluline: tagasiside võib olla lahendus kõigile ülalkirjeldatud probleemidele. Koos XP praktikatega võib see meid heidutusest välja tõmmata.

Kuidas end heidutusest välja tõmmata: kolm praktikat

Testid

Testimine mainitakse XP tagasiside tsüklis kaks korda. See pole niisama. Need on äärmiselt olulised kogu äärmusliku programmeerimise tehnika jaoks.

Oletatakse, et sul on Unit ja Acceptance testid. Üks annab sulle tagasisidet mõne minuti jooksul, teine mõne päeva jooksul, sest neid kirjutatakse kauem ja neid käivitatakse harvem.

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

Kuidas see skeem meie projektis IaC rakendub? Tegelikult... mitte kuidagi.

Kuigi unit-teste peaks olema väga palju, ei saa neid siiski olla liig palju. Kas nad testivad midagi väga kaudselt. Tegelikult võib öelda, et me neid üldse ei kirjuta. Aga siinkohal on mõned rakendused selliste testide jaoks, mida meil siiski õnnestus teha:
1. Koodi testimine jsonnet'is. See on näiteks meie ehituspipeline drone'is, mis on piisavalt keeruline. Kood jsonnet'is katab testidega hästi.
  Me kasutame seda Unit testing framework for Jsonnet.
2. Testid skriptide jaoks, mida tehakse ressursi käivitamisel. Skriptid on Pythonis, seega on ka nende testid kirjutatavad.
Potentsiaalselt on võimalik kontrollida konfiguratsiooni testides, kuid me ei tee seda. On ka võimalus seadistada ressursi konfigureerimise reeglite kontrollimist läbi tflint. Siiski, lihtsalt terraformi jaoks on seal liiga põhjalikud kontrollid, kuid palju kontrollstsenaariume on kirjutatud AWS jaoks. Meie aga oleme Azure'is, seega see ei sobi jälle.
Komponentide integreerimistests: see sõltub sellest, kuidas sa neid klasifitseerid ja kuhu need paigutad. Kuid need toimivad põhimõtteliselt.
Nii näevad välja integreerimistestid.

See on näide piltide kokkupanekust Drone CI-s. Nende juurde jõudmiseks tuleb oodata 30 minutit, kuni Packer'i pilt kokku monteeritakse, ja seejärel veel 15 minutit, kuni testid läbivad. Aga nad on olemas!
Piltide kontrollimise algoritm
1. Esmalt peab Packer pildi täielikult ette valmistama.
2. Testi kõrval on Terraform kohaliku olekuga, millega me seda pilti üles seame.
3. Üles seadmise käigus kasutatakse väikest moodulit, mis asub läheduses, et oleks lihtsam pildiga töötada.
4. Kui pildist on loodud VM, võib alustada kontrollimisi. Peamiselt teostatakse kontrollid masinal. Kontrollitakse, kuidas skriptid käivitusel töötavad, ja kuidas demonid toimivad. Selleks siseneme ssh või winrm kaudu just loodud masinasse ja kontrollime konfiguratsiooni seisundit või kas teenused on käivitunud.
Sarnane olukord on integreerimistestidega ka Terraformi moodulites. Siin on lühike tabel, mis selgitab selliste testide eripära.

Tagasiside pipeline'is on umbes 40 minutit. Kõik toimub väga aeglaselt. Seda saab kasutada regressiooniks, kuid uue arenduse jaoks on see täielikult ebareaalne. Kui sellele tõeliselt ette valmistuda, et saada käivitamine ja skriptid, siis võib selle aja vähendada kuni 10 minutini. Kuid see ei ole siiski Unit-testid, mis kestavad 5 sekundit ja katab 100 eset.

Unit-testide puudumine piltide või Terraformi moodulite koostamisel sunnib töö koormust jagama eraldi teenustele, millele saab lihtsalt RESTi kaudu ligi pääseda, või Python-skriptidele.

Näiteks pidime seadistama nii, et virtuaalmaquina käivitatud juhul registreerib see end teenuses ScaleFT, ja virtuaalmaquina hävitamisel eemaldab see end.

Kuna ScaleFT on meil teenusena, oleme sunnitud temaga töötama API kaudu. Seal oli kirjutatud wrapper, mida saab kasutada ja öelda: "Mine ja kustuta see, see". See hoiab kõiki vajalikke sätteid ja ligipääse.

Selle peale saame kirjutada normaalsed testid, kuna see ei erine tavalisest tarkvarast: mõni API moondatakse, sa tõukad ja vaatame, mis juhtub.

Testide tulemused: Üksuse testimine, mis peaks andma OS-i ühe minutiga, ei anna seda. Kuid püramiidi kõrgemad testimisviisid annavad tulemusi, kuid katab vaid osa probleemidest.

Paaris programmeerimine

Testid on kindlasti head. Neid saab palju kirjutada, nad võivad olla erinevat tüüpi. Nad töötavad oma tasanditel ja annavad meile tagasisidet. Kuid probleem kehvade üksuse testidega, mis ei anna kiireimat OS-i, püsib. Samas tahaks ikka kiiret OS-i, millega on lihtne ja meeldiv töötada. Rääkimata saavutatud lahenduse kvaliteedist. Õnneks on tehnikaid, mis suudavad anda veel kiiremat tagasisidet kui moodulitestid. See on paaris programmeerimine.

Koodi kirjutamisel on soov saada tagasisidet selle kvaliteedi kohta nii kiiresti kui võimalik. Jah, kõike saab kirjutada funktsiooniklassis (et mitte kellelegi midagi rikkuda), teha GitHubis pull requesti, määrata kedagi, kelle arvamus loeb, ja oodata vastust.

Kuid ooteaeg võib olla pikk. Inimesed on kõik hõivatud ja isegi kui vastus tuleb, ei pruugi see olla kvalitatiivne. Oletame, et vastus tuli kohe, ülevaataja mõistis idee kiiresti, kuid vastus tuleb ikkagi hiljem. Soov oleks ju varem. Just selleks on paaristöö suunatud, et anda tagasisidet kohe, kirjutamise käigus.

Järgnevalt toon välja paaristöö stiilid ja nende rakendatavus IaC-lt töötamisel:

1. Klassikaline, kogenud+kogenud, ajapõhine vahetus. Kaks rolli – driver ja navigator. Kaks inimest. Nad töötavad ühe koodi kallal ja vahetavad rolle kindlaksmääratud ajavahemiku järel.

Vaadakem, kui hästi meie probleemid sobivad stiiliga:

Probleem: tööriistade ebatäiuslikkus koodi arendamiseks.
Negatiivne mõju: arendamine venib, tempo/ritm aeglustub.
Kuidas vastu minna: kasutame teisi tööriistu, ühist IDE-d ja õpime veel lisakäsklusi.
Probleem: aeglane juurutamine.
Negatiivne mõju: suurendab aega töötava koodilõigu loomisel. Ootamise ajal igavleb, käed ulatuvad millegi muu järele, kuni ootad.
Kuidas vastu minna: ei ole lahendatud.
Probleem: lähenemiste ja praktikate puudus.
Negatiivne mõju: teadmiste puudumine, kuidas teha hästi ja kuidas halvasti. Pikendab tagasiside saamist.
Kuidas me võitleme: arvamuste ja praktikate vahetus paaristöös peaaegu lahendab probleemi.

Peamine probleem selle stiili rakendamisel IaC-s on ebaregulaarsed töötempos. Traditsioonilises tarkvaraarenduses on sul väga ühtlane tempo. Sa võid kulutada viis minutit ja kirjutada N. Kulutada 10 minutit ja kirjutada 2N, 15 minutit – 3N. Siin võid kulutada viis minutit ja kirjutada N, aga siis kulutada veel 30 minutit ja kirjutada N-i kümnendik. Siin sa ei tea mitte midagi, sul on kinni jäämine, takistus. Selgitamine võtab aega ja häirib otseselt programmeerimist.

Järeldus: puhtal kujul ei sobi meile.

2. Ping-pong. See lähenemine eeldab, et üks osaleja kirjutab testi ja teine teeb selle jaoks rakenduse. Arvestades, et Unit-testidega on kõik keeruline ja tuleb kirjutada pikaajaline integratsioonitest, kaob kogu ping-pongi lihtsus.

Võin öelda, et oleme proovinud testistsenaariumi kavandamise ja selle koodi rakendamise ülesannete jagamist. Üks osaleja mõtles stsenaariumi välja, olles selle tööosa eest vastutav ning viimane sõna kuulus talle. Teine oli vastutav rakendamise eest. See toimis hästi. Sellise lähenemisega paranes stsenaariumi kvaliteet.

Järeldus: kahjuks ei võimalda töö tempo kasutada ping-pong'i kui paarilise programmeerimise praktikat IaC-s.

3. Tugev stiil. Raske praktika.Idee on selles, et üks osaleja muutub suunavaks juhiks, samas kui teine täidab juhina rolli. Otsustusõigused jäävad rangelt juhile. Juhiks olev isik lihtsalt trükib ja suudab sõnadega mõjutada toimuvaid sündmusi. Roolid ei muutu pikaks ajaks.

Sobib hästi harimiseks, kuid nõuab tugevaid pehmeid oskusi. Siin tekkis takistus. Protsess kulges keeruliselt. Asi ei ole isegi infrastruktuuris.

Järeldus: võib-olla on seda potentsiaalselt võimalik rakendada; me ei jäta lootust.

4. Mobbing, swarming ja kõik tuntud, kuid siinkohal mitte mainitud stiilid ei ole arutluse all, kuna ei ole proovitud ja meie töö kontekstis sellest rääkida ei saa.

Paariprogrammeerimise kasutamise põhijäreldused:

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

Oleme pidanud vastu kehvadele suhtlemisoskustele. Ja teemaala ei soodusta nende puuduste ületamist.

Pikad testid ja tööriistade probleemid muudavad paariarenduse vaevaliseks.

5. Sellegipoolest oli ka edusamme. Me leiutasime oma meetodi 'Kohtumine - lahkumin.' Koheselt kirjeldan, kuidas see töötab.

Meil on pidevad partnerid paaripäevaseks (alla nädala). Teeme koos ühe ülesande. Osa ajast istume koos: üks kirjutab, teine vaatab kui toeks. Siis lahkume mõneks ajaks, igaüks teeb oma iseseisvaid asju, siis koondume jälle, sünkroniseerime end kiiresti, teeme midagi koos ja lahkume jälle.

Planeerimine ja suhtlemine

Viimane praktikablokk, läbi mille lahendatakse probleemid, on töö korraldamine ülesannete endi juures. Siia kuulub ka kogemuste vahetamine, mis toimub väljaspool paaritööd. Vaatame kolme praktikat:

1. Ülesanded eesmärkide puu kaudu. Projektide haldamine on korraldatud läbi puu, mis ulatub lõputusse tulevikku. Tehniliselt toimub haldamine Miro's. On olemas üks ülesanne – see on vaheeesmärk. Sellest tulenevad kas väiksemad eesmärgid või ülesannete rühmad. Need viivad juba konkreetsete ülesannete juurde. Kõik ülesanded luuakse ja hallatakse sellel tahvlil.

See skeem annab samuti tagasisidet, mis toimub kord päevas, kui me omavahel koondume koosolekuteks. Ühise plaani olemasolu, mis on struktureeritud ja täielikult avatud, võimaldab igal inimesel olla kursis toimuva ning meie edusammudega.

Ülesannete visuaalse nägemise eelised:

Põhjuslikkus. Iga ülesanne viib mingisse globaalsesse eesmärki. Ülesanded rühmitatakse väiksemate eesmärkide järgi. Infrastruktuuri domeen on iseenesest üsna tehniline. Ei ole alati kohe selge, millist mõju ettevõttele avaldab näiteks ränderaamatu koostamine teisele nginx'ile. Eesmärgikaardi olemasolu kõrval muudab selle selgemaks.

Põhjuslikkus on ülesannete oluline omadus. See vastab otse küsimusele: 'Kas ma teen õiget asja?'
Paralleelsus. Meid on üheksa ja pole lihtsalt füüsiliselt võimalik, et kõik ühele ülesandele ründaksid. Ülesandeid ühes valdkonnas ei pruugi ka alati piisavalt olla. Oleme sunnitud jagama tööd väikeste töörühmade vahel. Samal ajal töötavad rühmad mõnda aega oma ülesande kallal, neid võivad tugevdada ka teised. Sellelt töörühmast võivad mõned inimesed kaduda. Keegi läheb puhkusele, keegi esitleb DevOps konverentsil, keegi kirjutab artiklit Habrile. Oluline on teada, millised eesmärgid ja ülesanded saavad paralleelselt teostatud.

2. Vahetavad juhid hommikustel koosolekutel. Standupides tekib selline probleem – paljusid ülesandeid teevad inimesed paralleelselt. Mõnikord on ülesanded nõrgalt seotud ja pole arusaama, kes mida teeb. Ühe tiimiliikme arvamus on väga oluline. See on lisainformatsioon, mis võib muuta ülesande lahendamise kulgu. Loomulikult on tavaliselt sinuga paaris keegi, kuid konsultatsioon ja näpunäited ei ole kunagi üleliigsed.

Selle olukorra parandamiseks rakendasime "Juhtiva stand-up'i vahetuse" tehnikat. Nüüd nad pöörlevad kindlas järjestuses ja see avaldab mõju. Kui on sinu kord, pead süvenema ja aru saama, mis toimub, et hästi läbi viia scrumi kohtumine.

3. Sisemine demo. Abiks probleemide lahendamisel on paarist programmimine, ülesannete puu visualiseerimine ja hommikused scrumi koosolekud – see on hea, aga mitte ideaalne. Paari koostöös oled piiratud ainult oma teadlikega. Ülesannete puu aitab üldiselt mõista, kes ja mida teeb. Ja juht ja kolleegid hommikusel koosolekul ei süvene sügavalt su probleemidesse. Nad võivad kindlasti midagi ka mööda lasta.

Lahendus leiti omavahel tehtud tööde demonstreerimise ja nende järgneva arutelu kaudu. Me koguneme kord nädalas tunniks ja näitame ülesannete lahenduste detaile, mida oleme teinud viimase nädala jooksul.

Demonstreerimise käigus tuleb avada ülesande üksikasjad ja kindlasti näidata selle toimimist.

Ettekanne võib toimuda kontrollnimekirja alusel.1. Toodud konteksti. Kust see ülesanne tuli, miks see üldse vajalik oli?

2. Kuidas see probleem varem lahendatud oli? Näiteks oli vajalik massiline hiireklikkimine või ei saanud midagi teha.

3. Kuidas me seda parandame. Näiteks: „Külastage, nüüd on olemas skript, siin on readme“.

4. Näidake, kuidas see töötab. Soovitavalt teostage mõni kasutajascenario otse. Tahan X, teen Y, näen Z (või Y). Näiteks, deployin NGINX, kontrollin URL-i, saan 200 OK. Kui tegevus kestab kaua, valmistage see ette eelnevalt, et hiljem näidata. Soovitav on, et tund aega enne demot eriti ei katki läheks, kui see on õrn.

5. Selgitage, kui edukalt probleem lahendati, millised raskused jäävad, mis on lõpetamata, millised edusammud on tulevikus võimalikud. Näiteks, praegu on CLI, hiljem tuleb täielik automatiseerimine CI-s.

Iga esineja peaks mahtuma 5-10 minutitesse. Kui teie ettekande on ilmnevalt oluline ja võtab rohkem aega, leppige see eelnevalt kokku kanalis sre-takeover.

Pärast füüsilist osa toimub kindlasti arutelu teemas. Siin tekib vajalik tagasiside meie ülesannete seadmiseks.

Lõpuks viiakse läbi uuring, et selgitada välja toimuva kasulikkus. See on juba tagasiside esitluse sisust ja ülesande olulisusest.

Pikad järeldused ja mis edasi

Võib tunduda, et artikli toon on veidi pessimistlik. Kuid see ei ole tõsi. Kaks madalama tasandi tagasiside saamise viisi, nimelt testimine ja paarides programmeerimine, toimivad. Mitte nii täiesti nagu traditsioonilises arenduses, kuid positiivne mõju on olemas.

Testid, oma praeguses vormis, pakuvad vaid osalist koodikatte. Paljud konfiguratsioonifunktsioonid jäävad katsetamata. Nende mõju koodi kirjutamise ajal on vähene. Siiski on integratsioonitestide mõju olemas, ja just need võimaldavad turvaliselt refaktoreerida. See on suur saavutus. Samuti, kui keskenduda kõrgetasemelistele programmeerimiskeeltele (meil on Python, Go), kaob probleem. Ja palju kontrollimisi „liimiks” ei ole vajalik, piisab üldisest integratsioonitestist.

Koostöö tõhusus sõltub suuresti inimestest. On olemas ülesande tegur ja meie pehmed oskused. Mõne inimesega sujub koostöö väga hästi, teisega vähem. Sellest on kindlasti kasu. Selgelt mõjutab isegi paarilise töö reeglite mittetäitmine positiivselt tulemuste kvaliteeti. Isiklikult mulle meeldib töötada paaris, see on kergem ja meeldivam.

Kõrgemad meetodid operatsioonisüsteemi mõjutamiseks — planeerimine ja ülesannetega tegelemine toovad kindlasti kaasa kvaliteetse teadmistevahetuse ja arendamise kvaliteedi paranemise.