Infrastruktuur kui kood: kuidas XP abil probleeme ületada

Tere, Habr! Varem kurtsin Infrastruktuuri kui koodiparadigma elu üle ega pakkunud hetkeolukorra lahendamiseks midagi. Täna olen tagasi, et rääkida teile, millised lähenemisviisid ja tavad aitavad teil meeleheite kuristikust põgeneda ja olukorra õiges suunas juhtida.

Ühes varasemas artiklis "Infrastruktuur kui kood: esimene tutvus" Jagasin oma muljeid sellest valdkonnast, püüdsin mõtiskleda selle valdkonna hetkeolukorra üle ja isegi pakkusin, et kõigile arendajatele teadaolevad standardtavad võiksid aidata. Võib tunduda, et elu üle kurdeti palju, kuid praegusest olukorrast väljapääsu ettepanekuid ei tehtud.

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

Oleme praegu Sre Onboarding Teamis, mis koosneb kuuest programmeerijast ja kolmest infrastruktuuriinsenerist. Me kõik püüame kirjutada infrastruktuuri koodina (IaC). Teeme seda seetõttu, et teame põhimõtteliselt, kuidas koodi kirjutada, ja oleme olnud "üle keskmise" arendajad.

• Meil on terve rida eeliseid: kindel taust, tavade tundmine, koodi kirjutamise oskus, soov õppida uusi asju.
• Ja seal on longus osa, mis on ka miinus: teadmiste puudumine infrastruktuuri riistvara kohta.

Tehnoloogiapakk, mida me oma IaC-s kasutame.

• Terraform ressursside loomiseks.
• Pakkija piltide kokkupanemiseks. Need on Windows, CentOS 7 pildid.
• Jsonnet, et teha saidil drone.io võimas ehitus, samuti genereerida packer json ja meie terraformi moodulid.
• Azure.
• Võimalik piltide ettevalmistamisel.
• Python abiteenuste ja skriptide varustamiseks.
• Ja seda kõike VSCode'is koos meeskonnaliikmete vahel jagatud pluginatega.

Järeldus minu poolt viimane artikkel oli selline: püüdsin sisendada (eelkõige endasse) optimismi, tahtsin öelda, et proovime meile teadaolevaid lähenemisi ja praktikaid, et tulla toime selles vallas esinevate raskuste ja keerukustega.

Oleme praegu hädas järgmiste IaC probleemidega:

• Koodi arendamise tööriistade ja vahendite ebatäiuslikkus.
• Aeglane kasutuselevõtt. Infrastruktuur on osa reaalsest maailmast ja see võib olla aeglane.
• Lähenemisviiside ja praktikate puudumine.
• Oleme uued ja ei tea palju.

Extreme Programming (XP) appi

Kõik arendajad tunnevad Extreme Programming (XP) ja selle taga olevaid tavasid. Paljud meist on selle lähenemisviisiga töötanud ja see on olnud edukas. Miks siis mitte kasutada seal sätestatud põhimõtteid ja tavasid infrastruktuuriprobleemide ületamiseks? Otsustasime kasutada seda lähenemisviisi ja vaadata, mis juhtub.

XP lähenemisviisi rakendatavuse kontrollimine teie tööstusesSiin on kirjeldus keskkonnast, kuhu XP sobib, ja kuidas see meiega seotud on:

1. Dünaamiliselt muutuvad tarkvaranõuded. Meile oli selge, mis oli lõppeesmärk. Kuid üksikasjad võivad olla erinevad. Me ise otsustame, kuhu vajame taksot sõita, seega muutuvad nõuded perioodiliselt (peamiselt ise). Kui võtta SRE meeskond, kes teeb ise automatiseerimist ja ise piirab nõudeid ja töömahtu, siis see punkt sobib hästi.

2. Uut tehnoloogiat kasutavate fikseeritud aja projektide põhjustatud riskid. Meile tundmatute asjade kasutamisel võib tekkida oht. Ja see on 100% meie juhtum. Kogu meie projekt hõlmas tehnoloogiate kasutamist, millega me ei olnud täielikult tuttavad. Üldiselt on see pidev probleem, sest... Taristusektoris tekib pidevalt palju uusi tehnoloogiaid.

3,4. Väike, koos paiknev laiendatud arendusmeeskond. Teie kasutatav automatiseeritud tehnoloogia võimaldab teha seadme- ja funktsionaalseid teste. Need kaks punkti meile päris ei sobi. Esiteks ei ole me koordineeritud meeskond ja teiseks on meid üheksa, mida võib pidada suureks meeskonnaks. Kuigi mõne “suure” meeskonna määratluse järgi on palju 14+ inimest.

Vaatame mõningaid XP tavasid ja seda, kuidas need mõjutavad tagasiside kiirust ja kvaliteeti.

XP tagasisideahela põhimõte

Minu arusaamise järgi on tagasiside vastus küsimusele, kas ma teen õigesti, kas me läheme sinna? XP-l on selleks jumalik skeem: aja tagasiside ahel. Huvitav on see, et mida madalamal oleme, seda kiiremini saame OS-i vajalikele küsimustele vastama.

See on üsna huvitav teema aruteluks, et meie IT-tööstuses on võimalik kiiresti OS hankida. Kujutage ette, kui valus on teha projekti kuus kuud ja alles siis teada saada, et kohe alguses oli viga. See juhtub projekteerimisel ja keerukate süsteemide ehitamisel.

Meie IaC puhul aitab meid tagasiside. Teen kohe ülaltoodud diagrammi väikese kohanduse: väljalaskeplaanil pole igakuist tsüklit, vaid see toimub mitu korda päevas. Selle OS-i tsükliga on seotud mõned tavad, mida me vaatame üksikasjalikumalt.

Tähtis: tagasiside võib olla lahendus kõikidele ülaltoodud probleemidele. Koos XP tavadega võib see teid meeleheite kuristikust välja tõmmata.

Kuidas end meeleheite kuristikust välja tõmmata: kolm praktikat

Testid

XP tagasisideahelas mainitakse teste kaks korda. See pole lihtsalt nii. Need on äärmiselt olulised kogu Extreme Programming tehnika jaoks.

Eeldatakse, et teil on ühiku- ja vastuvõtutestid. Mõned annavad teile tagasisidet mõne minuti, teised mõne päeva jooksul, nii et nende kirjutamine võtab kauem aega ja neid vaadatakse harvemini.

On olemas klassikaline testimispüramiid, mis näitab, et teste peaks rohkem olema.

Kuidas see raamistik meie jaoks IaC projektis kehtib? Tegelikult... üldse mitte.

• Ühikteste, hoolimata sellest, et neid peaks olema palju, ei saa olla liiga palju. Või katsetavad nad midagi väga kaudselt. Tegelikult võib öelda, et me ei kirjuta neid üldse. Kuid siin on mõned selliste testide rakendused, mida saime teha:
  1. Jsonneti koodi testimine. See on näiteks meie droonide montaaži torustik, mis on üsna keeruline. Jsonneti kood on testidega hästi kaetud.
     Me kasutame seda Jsonneti üksuse testimise raamistik.
  2. Testib skripte, mis käivitatakse ressursi käivitamisel. Skriptid on kirjutatud Pythonis ja seetõttu saab neile kirjutada teste.
• Konfiguratsiooni on potentsiaalselt võimalik testides kontrollida, kuid me seda ei tee. Samuti on võimalik konfigureerida ressursside konfiguratsioonireeglite kontrollimise kaudu tflint. Sealsed kontrollid on aga terraformi jaoks lihtsalt liiga elementaarsed, kuid paljud testskriptid on kirjutatud AWS-i jaoks. Ja me oleme Azure'is, nii et see jällegi ei kehti.
• Komponentide integreerimise testid: see sõltub sellest, kuidas te need klassifitseerite ja kuhu need asetate. Kuid nad põhimõtteliselt töötavad.

  Integratsioonitestid näevad välja sellised.

  
  
  See on näide piltide loomisel Drone CI-s. Nendeni jõudmiseks peate ootama 30 minutit, kuni Packeri kujutis moodustub, ja seejärel veel 15 minutit, kuni need mööduvad. Aga nad on olemas!

  Pildi kinnitamise algoritm

  1. Pakkija peab esmalt pildi täielikult ette valmistama.
  2. Testi kõrval on kohaliku olekuga terravorm, mida kasutame selle pildi juurutamiseks.
  3. Avamisel kasutatakse pildiga töötamise hõlbustamiseks väikest moodulit, mis asub läheduses.
  4. Kui VM on pildilt juurutatud, võib kontrollimine alata. Põhimõtteliselt toimub kontroll autoga. See kontrollib, kuidas skriptid käivitamisel töötasid ja kuidas deemonid töötavad. Selleks logime ssh või winrm kaudu sisse äsja tõstetud masinasse ja kontrollime konfiguratsiooni olekut või seda, kas teenused on üleval.

• Sarnane on olukord terraformi moodulite integratsioonitestidega. Siin on lühike tabel, mis selgitab selliste testide funktsioone.

  
  
  Tagasiside torustiku kohta on umbes 40 minutit. Kõik juhtub väga pikka aega. Seda saab kasutada regressiooniks, kuid uue arenduse jaoks on see üldiselt ebareaalne. Kui olete selleks väga-väga valmis, valmistage ette jooksvad skriptid, siis saate seda vähendada 10 minutini. Kuid need pole ikkagi ühikutestid, mis teevad 5 tükki 100 sekundiga.

Ühiktestide puudumine piltide või terravormi moodulite kokkupanemisel julgustab nihutama tööd eraldi teenustele, mida saab lihtsalt RESTi kaudu käivitada, või Pythoni skriptidele.

Näiteks pidime veenduma, et kui virtuaalmasin käivitub, registreerib see end teenuses ScaleFTja kui virtuaalmasin hävitati, kustutas see ennast.

Kuna meil on teenusena ScaleFT, oleme sunnitud sellega API kaudu töötama. Sinna oli kirjutatud ümbris, mida võis tõmmata ja öelda: "Mine sisse ja kustuta see ja see." See salvestab kõik vajalikud seaded ja juurdepääsud.

Selle jaoks saame juba tavalisi teste kirjutada, kuna see ei erine tavalisest tarkvarast: mõnitatakse mingit apiha, tõmbad selle ja vaatad, mis saab.

Testide tulemused: Ühiktestimine, mis peaks OS-i minutiga andma, seda ei anna. Ja püramiidi kõrgemal tasemel testimise tüübid on tõhusad, kuid katavad ainult osa probleemidest.

Paari programmeerimine

Testid on muidugi head. Saate neid kirjutada palju, neid võib olla erinevat tüüpi. Nad töötavad oma tasemel ja annavad meile tagasisidet. Kuid probleem halbade ühikutestidega, mis annavad kiireima OS-i, jääb alles. Samas tahaks ikkagi kiiret OS-i, millega on lihtne ja mõnus töötada. Rääkimata saadud lahenduse kvaliteedist. Õnneks on tehnikaid, mis võivad anda isegi kiiremat tagasisidet kui ühikutestid. See on paarisprogrammeerimine.

Koodi kirjutades soovite saada võimalikult kiiresti tagasisidet selle kvaliteedi kohta. Jah, saate kõik funktsioonide harusse kirjutada (et mitte kellegi jaoks midagi rikkuda), teha Githubis tõmbetaotluse, määrata selle kellelegi, kelle arvamusel on kaalu, ja oodata vastust.

Kuid võite kaua oodata. Inimesed on kõik hõivatud ja vastus, isegi kui see on olemas, ei pruugi olla kõige kvaliteetsem. Oletame, et vastus tuli kohe, arvustaja sai kogu ideest kohe aru, kuid vastus tuleb ikkagi hilja, tagantjärele. Soovin, et see oleks varem. Just sellele on paarisprogrammeerimine suunatud – kohe, kirjutamise ajal.

Allpool on paar programmeerimisstiilid ja nende rakendatavus IaC-ga töötamisel:

1. Klassikaline, Kogenud + Kogenud, nihutage taimeriga. Kaks rolli – juht ja navigaator. Kaks inimest. Nad töötavad sama koodi kallal ja vahetavad rolle pärast teatud etteantud ajavahemikku.

Mõelgem meie probleemide ühilduvusele stiiliga:

• Probleem: koodiarenduse tööriistade ja tööriistade ebatäiuslikkus.
  Negatiivne mõju: arenemine võtab kauem aega, aeglustume, töötempo/rütm läheb käest.
  Kuidas me võitleme: kasutame erinevaid tööriistu, ühist IDE-d ja õpime ka otseteid.
• Probleem: aeglane juurutamine.
  Negatiivne mõju: pikendab töötava koodiosa loomiseks kuluvat aega. Meil hakkab oodates igav, käed sirutuvad, et ootamise ajal midagi muud teha.
  Kuidas me võitleme: me ei saanud sellest üle.
• Probleem: lähenemiste ja tavade puudumine.
  Negatiivne mõju: puudub teadmine, kuidas seda hästi teha ja kuidas seda halvasti teha. Pikendab tagasiside saamist.
  Kuidas me võitleme: vastastikune arvamuste ja tavade vahetamine paaristöös lahendab probleemi peaaegu.

Peamine probleem selle stiili kasutamisel IaC-s on ebaühtlane töötempo. Traditsioonilises tarkvaraarenduses on teil väga ühtlane liikumine. Võite kulutada viis minutit ja kirjutada N. Kulutage 10 minutit ja kirjutage 2N, 15 minutit - 3N. Siin saate kulutada viis minutit ja kirjutada N ja seejärel kulutada veel 30 minutit ja kirjutada kümnendiku N-st. Siin sa ei tea midagi, sa oled ummikus, loll. Uurimine võtab aega ja häirib programmeerimisest endast.

Järeldus: puhtal kujul see meile ei sobi.

2. Ping-pong. See lähenemine hõlmab seda, et üks inimene kirjutab testi ja teine ​​teeb selle rakendamise. Võttes arvesse asjaolu, et Unit testidega on kõik keeruline ja peate kirjutama integratsioonitesti, mille programmeerimine võtab kaua aega, kaob kogu pingpongi lihtsus.

Võin öelda, et proovisime testskripti kujundamise ja selle koodi juurutamise eest vastutust eraldada. Üks osaleja mõtles välja stsenaariumi, selles tööosas vastutas ta, temale jäi viimane sõna. Ja teine ​​vastutas rakendamise eest. See tuli hästi välja. Selle lähenemisviisiga skripti kvaliteet tõuseb.

Järeldus: paraku ei võimalda töötempo IaC-s pingpongi paarisprogrammeerimise praktikana kasutada.

3. Tugev stiil. Raske praktika. Idee seisneb selles, et ühest osalejast saab juhiste navigaator ja teine ​​täidab täitmisjuhi rolli. Sel juhul on otsustusõigus eranditult navigaatoril. Juht ainult prindib ja saab toimuvat sõnaga mõjutada. Rollid ei vahetu kaua.

Hea õppimiseks, kuid nõuab tugevaid pehmeid oskusi. Siin me koperdasime. Tehnika oli raske. Ja see ei puuduta isegi infrastruktuuri.

Järeldus: seda saab potentsiaalselt kasutada, me ei loobu proovimisest.

4. Mobbing, sülemlemine ja kõik tuntud, kuid mitte loetletud stiilid Me ei arvesta sellega, sest Me pole seda proovinud ja sellest on võimatu oma töö kontekstis rääkida.

Üldised tulemused paarisprogrammeerimise kasutamise kohta:

• Meil on ebaühtlane töötempo, mis tekitab segadust.
• Meil tekkisid ebapiisavalt head pehmed oskused. Ja ainevaldkond ei aita neid meie puudusi ületada.
• Pikad testid ja probleemid tööriistadega muudavad paarisarenduse keeruliseks.

5. Sellele vaatamata oli ka õnnestumisi. Mõtlesime välja oma meetodi “Lähenemine – lahknevus”. Kirjeldan lühidalt, kuidas see töötab.

Meil on püsipartnerid mõneks päevaks (alla nädalaks). Teeme koos ühe ülesande. Istume mõnda aega koos: üks kirjutab, teine ​​istub ja vaatab tugimeeskonda. Siis läheme mõnda aega laiali, kumbki teeb mingeid iseseisvaid asju, siis tuleme uuesti kokku, sünkroniseerime väga kiiresti, teeme midagi koos ja läheme jälle laiali.

Planeerimine ja suhtlemine

Viimane praktikate plokk, mille kaudu OS-i probleeme lahendatakse, on töö korraldamine ülesannete endaga. See hõlmab ka paaristöövälist kogemuste vahetamist. Vaatame kolme praktikat:

1. Eesmärgid eesmärgipuu kaudu. Korraldasime projekti üldise juhtimise läbi puu, mis ulatub lõputult tulevikku. Tehniliselt toimub jälgimine Miros. On üks ülesanne – see on vaheeesmärk. Sellest lähevad kas väiksemad eesmärgid või ülesannete rühmad. Ülesanded ise tulevad neilt. Kõik ülesanded luuakse ja säilitatakse sellel tahvlil.

See skeem annab ka tagasisidet, mis toimub kord päevas, kui rallidel sünkroniseerime. Kõigi ees ühise plaani omamine, kuid struktureeritud ja täiesti avatud, võimaldab kõigil olla kursis sellega, mis toimub ja kui kaugele oleme arenenud.

Ülesannete visuaalse nägemise eelised:

• Põhjuslikkus. Iga ülesanne viib mingi globaalse eesmärgini. Ülesanded on rühmitatud väiksemateks eesmärkideks. Infrastruktuuri domeen ise on üsna tehniline. Alati pole kohe selge, milline konkreetne mõju on ettevõttele näiteks teisele nginxile ülemineku kohta käsiraamatu kirjutamine. Kui sihtkaart on läheduses, muutub see selgemaks.
  
  Põhjuslikkus on probleemide oluline omadus. See vastab otse küsimusele: "Kas ma teen õigesti?"
• Paralleelsus. Meid on üheksa ja on lihtsalt füüsiliselt võimatu kõiki ühe ülesandega täita. Ka ühe valdkonna ülesannetest ei pruugi alati piisata. Oleme sunnitud paralleelselt töötama väikeste töörühmade vahel. Samal ajal istuvad rühmad mõnda aega oma ülesande täitmisel, neid saab tugevdada keegi teine. Mõnikord langevad inimesed sellest töörühmast eemale. Keegi läheb puhkusele, keegi teeb DevOpsi konfi aruande, keegi kirjutab artikli Habrist. Väga oluliseks muutub teadmine, milliseid eesmärke ja ülesandeid saab paralleelselt teha.

2. Hommikuste koosolekute asendusettekandjad. Stand-up’idel on meil see probleem – inimesed teevad paljusid ülesandeid paralleelselt. Mõnikord on ülesanded lõdvalt seotud ja puudub arusaam, kes mida teeb. Ja teise meeskonnaliikme arvamus on väga oluline. See on lisateave, mis võib probleemi lahendamise kulgu muuta. Loomulikult on tavaliselt keegi kaasas, kuid nõuanded ja näpunäited on alati kasulikud.

Selle olukorra parandamiseks kasutasime tehnikat "Juhtiva seisja muutmine". Nüüd pööratakse neid kindla nimekirja järgi ja sellel on oma mõju. Kui on teie kord, olete sunnitud sukelduma ja mõistma, mis toimub, et korraldada hea Scrumi koosolek.

3. Sisemine demo. Abi probleemi lahendamisel paarisprogrammeerimisest, visualiseerimisest probleemipuul ja abi hommikustel scrumi koosolekutel on hea, kuid mitte ideaalne. Paarina piiravad teid ainult teie teadmised. Ülesandepuu aitab globaalselt aru saada, kes mida teeb. Ja hommikuse koosoleku saatejuht ja kolleegid ei sukeldu teie probleemidesse sügavale. Kindlasti võivad nad millestki ilma jääda.

Lahendus leiti üksteisele tehtud tööde demonstreerimises ja seejärel arutluses. Kohtume kord nädalas tunniks ja näitame üksikasju viimase nädala jooksul tehtud ülesannete lahendustest.

Demonstratsiooni käigus on vaja paljastada ülesande üksikasjad ja kindlasti demonstreerida selle toimimist.

Aruande saab koostada kontrollnimekirja abil.1. Sisenege konteksti. Kust ülesanne tuli, miks see üldse vajalik oli?

2. Kuidas probleem varem lahendati? Näiteks oli vaja massiivset hiireklõpsu teha või polnud üldse võimalik midagi teha.

3. Kuidas me seda täiustame. Näiteks: "Vaata, nüüd on scriptosik, siin on readme."

4. Näidake, kuidas see töötab. Soovitatav on mõni kasutajastsenaarium otse rakendada. Ma tahan X-i, ma teen Y-d, ma näen Y-d (või Z-d). Näiteks juurutan NGINX-i, suitsetan URL-i ja saan 200 OK. Kui tegevus on pikk, valmistage see ette, et saaksite seda hiljem näidata. Kui see on habras, ei ole soovitatav seda tund enne demot liiga palju lõhkuda.

5. Selgitage, kui edukalt probleem lahendati, millised raskused on jäänud, mis on pooleli, millised on võimalikud parandused tulevikus. Näiteks nüüd CLI, siis tuleb CI-s täisautomaatika.

Igal kõlaril on soovitatav hoida seda 5-10 minutit. Kui teie kõne on ilmselgelt oluline ja võtab kauem aega, kooskõlastage see eelnevalt sre-takeover kanalis.

Pärast näost näkku osa on teemas alati arutelu. Siin ilmubki tagasiside, mida oma ülesannete kohta vajame.

Selle tulemusena viiakse läbi küsitlus, et selgitada välja toimuva kasulikkus. See on tagasiside kõne olemuse ja ülesande tähtsuse kohta.

Pikad järeldused ja mis edasi

Võib tunduda, et artikli toon on mõneti pessimistlik. See on vale. Kaks madalamat tagasiside taset, nimelt testid ja paarisprogrammeerimine, toimivad. Mitte nii täiuslik kui traditsioonilises arengus, kuid sellel on positiivne mõju.

Testid pakuvad praegusel kujul ainult osalist koodikatvust. Paljud konfiguratsioonifunktsioonid jäävad testimata. Nende mõju tegelikule tööle koodi kirjutamisel on väike. Integratsioonitestidel on aga mõju ja need võimaldavad kartmatult refaktoringuid läbi viia. See on suur saavutus. Samuti kaob probleem, kui keskendutakse kõrgetasemeliste keelte arendamisele (meil on python, go). Ja te ei vaja "liimi" jaoks palju kontrolle, piisab üldisest integratsioonikontrollist.

Paaris töötamine sõltub rohkem konkreetsetest inimestest. Seal on ülesande faktor ja meie pehmed oskused. Mõne inimesega tuleb see väga hästi välja, mõnel halvemini. Sellest on kindlasti kasu. Selge on see, et isegi kui paaristöö reegleid piisavalt ei järgita, mõjub juba ainuüksi ülesannete koos sooritamise fakt tulemuse kvaliteedile positiivselt. Mulle isiklikult tundub, et paaristöö on lihtsam ja nauditavam.

Kõrgema tasemega OS-i mõjutamise viisid – ülesannete täpne planeerimine ja nendega töötamine annavad efekte: kvaliteetne teadmistevahetus ja arenduskvaliteedi paranemine.

Lühikesed järeldused ühel real

• Personalitöötajad töötavad IaC-s, kuid väiksema efektiivsusega.
• Tugevdage seda, mis töötab.
• Mõelge välja oma kompensatsioonimehhanismid ja -tavad.

Allikas: www.habr.com