Në kompaninë tonë po ndodh procesi i onboarding-ut të ekipit SRE. Unë kam hyrë në këtë histori nga ana e zhvillimit. Gjatë këtij procesi kam pasur mendime dhe njohuri që dëshiroj t'i ndaj me zhvillues të tjerë. Në këtë artikull-reflektim flas për atë që po ndodh, si ndodh, dhe si duhet të vazhdojmë me këtë.
Vazhdim i serisë së artikujve të shkruar sipas motiveve të fjalimeve në ngjarjen tonë të brendshme :
2. Infrastruktura si kod. (Ju jeni këtu)
3. Gjenerimi i kontratave Typescript nga modelet C#. (Në proces…)
4. Hyrje në algoritmin e konsensusit Raft. (Në proces…)
…
Ne vendosëm të formonim ekipin SRE, duke realizuar idetë . Punësuam programues nga zhvilluesit tanë dhe i dërguam për trajnim për disa muaj.
Ekipit iu vunë këto detyra për studim:
- Të përshkruajnë infrastrukturën tonë, që është kryesisht në Microsoft Azure, në formë kodi (Terraform dhe të gjitha që lidhen me të).
- Të mësojnë zhvilluesit se si të punojnë me infrastrukturën.
- Të përgatisin zhvilluesit për rolet e ndihmës.
Po futim konceptin e Infrastrukturës si kod
Në modelin e zakonshëm të botës (administrimi klasik), njohuritë rreth infrastrukturës ndodhin në dy vende:
- Ose në formën e njohurive në kokat e ekspertëve.
- Ose kjo informacion është në disa pajisje, një pjesë e të cilave e dinë ekspertët. Por nuk është e sigurt që një person i jashtëm (nëse ekipi ynë papritur vdes) do të mund të kuptojë se çfarë dhe si funksionon. Pajisja mund të ketë shumë informacione: aksesa, punë cron, montimin e diskëve (shih. ) dhe një listë të pafundme të asaj që mund të ndodhë. Është e vështirë të kuptosh se çfarë po ndodh realisht.
Në të dyja rastet, ne përfundojmë në një kurth, duke u bërë të varur:
- ose nga një person i cili është mortal, i ndjeshëm ndaj sëmundjeve, dashurive, ndryshimeve të humorit dhe thjesht largimeve banale;
- ose nga një makinë që funksionon fizikisht, që gjithashtu mund të bjerë, të vidhet, të sjellë surpriza dhe shqetësime.
Natyrisht, zgjidhja e duhura është që, në mënyrë ideale, gjithçka të transferohet në kod të lexueshëm nga njeriu, të mirëmbajtur dhe të shkruar me cilësi.
Kështu, infrastruktura si kod (Infrastructure as Code – IaC) është një përshkrim i gjithë infrastrukturës ekzistuese në formë kode, si dhe mjetet për ta menaxhuar atë dhe për të krijuar infrastrukturën reale nga ky kod.
Pse ta kthejmë gjithçka në kodNjerëzit nuk janë makina. Ata nuk mund të mbajnë mend gjithçka. Reaksioni i njeriut dhe i makinës është ndryshe. E gjithë automatizimi potencialisht punon më shpejt se çdo gjë që bën një njeri. E vetmja gjë thelbësore është një burim i vetëm të vërtetash (single source of truth).
Nga vijnë inxhinierët e rinj SREPra, ne vendosëm të angazhojmë inxhinierë të rinj SRE, por nga t'i marrim? Një libër me përgjigje të sakta () na thotë: nga zhvilluesit. Sepse ata punojnë me kodin, dhe ju arrini një gjendje ideale.
Kemi kërkuar gjatë dhe shumë për ta në tregun e punës jashtë kompanisë sonë. Por duhet të pranojmë se nuk gjetëm asnjë sipas kërkesave tona. Duhej të kërkonim mes të tanishmëve tanë.
Problemet e Infrastrukturës si Kod
Tani le të shikojmë shembuj të asaj si infrastruktura mund të jetë e koduar. Kodi është shkruar mirë, me cilësi, me komente dhe hapësira.
Shembulli i kodit nga Terraform.
Shembulli i kodit nga Ansible.
Të nderuar, por nëse do të ishte kaq e thjeshtë! Ne jemi në një botë reale, dhe ajo gjithmonë është e gatshme t'ju befasojë, t'ju sjellë surpriza dhe probleme. Kjo është pjesë e përvojës edhe këtu.
1. Problemi i parë është se në shumicën e rasteve IaC është një lloj dsl.
Dhe DSL, nga ana tjetër, është një përshkrim i strukturës. Më saktë, atij që duhet të keni: Json, Yaml, modifikime nga disa kompani të mëdha që krijuan dsl-in e tyre (në Terraform përdoret HCL).
Problemi është se në të mund të mungojnë gjëra që na duken të zakonshme si:
- variablat;
- kushtet;
- në disa raste mungojnë komentet, për shembull, në Json, ato nuk parashikohen si standard;
- funksionet;
- dhe këtu nuk po flas për gjëra me nivel më të lartë, si klasat, trashëgimia dhe të ngjashme.
2. Problemi i dytë i këtij kodi është se shpesh është një mjedis heterogjen.Zakonisht, ju punoni me C#, pra me një gjuhë, një stack, një ekosistem. Ndërsa këtu keni një shumëllojshmëri të madhe teknologjish.
Një situatë plotësisht reale është kur një bashkëpunim me Python fillon një proces, në të cilin futet një Json. Ju e analizoni atë, pastaj një gjenerator tjetër prodhon edhe 30 skedarë të tjerë. Të gjitha këto marrin variablat hyrës nga Azure Key Vault, të cilat janë të tërhequra nga një plugin për drone.io, të shkruara në Go, dhe këta variabla kalojnë përmes një yaml që rezulton nga gjenerimi nga një shabllon jsonnet. Mjaft e vështirë të kesh një kod të shkruar mirë kur ke një ambient kaq të ndryshëm.
Zhvillimi tradicional brenda një detyre zakonisht përdor një gjuhë të vetme. Këtu, megjithatë, ne punojmë me një numër të madh gjuhësh.
3. Problemi i tretë – janë mjetet. Ne jemi mësuar me redaktorë të shkëlqyer (Ms Visual Studio, Jetbrains Rider), të cilët gjithçka e bëjnë për ne. Edhe nëse ne gabojmë, ata do të thonë se nuk jemi të drejtë. Duket se është normale dhe e natyrshme.
Por dikur, pranë nesh është VSCode, ku ka disa skedarë ndihmës që instalohen, mbështeten ose nuk mbështeten. Kanë dalë versione të reja, dhe ato nuk janë mbështetur. Një kalim i thjeshtë në implementimin e funksionit (edhe nëse ai ekziston) bëhet një problem i komplikuar dhe jo trivial. Një thjeshtë ndryshim emri të një variabli – është një zëvendësim në projekt nga dhjetëra skedarë. Ka shpresë, nëse ai zëvendëson atë që duhet. Sigurisht, ndonjëherë ka ndriçim sintaksor, ka auto plotësim, diku ka formatim (ndonëse unë në Terraform në Windows nuk arrita ta aktivizoj).
Në momentin e shkruar ende nuk e kanë lëshuar për të mbështetur versionin 0.12, megjithatë ai është lëshuar për 3 muaj.
Ka ardhur koha të harrojmë për…
- Dekodimin.
- Mjeti i rifaksionit.
- Auto përfundimi.
- Zbulimin e gabimeve gjatë përpunimit.
Është qesharake, por kjo e rrit kohën e zhvillimit dhe rrit numrin e gabimeve që ndodhin pa dyshim.
E keqja më e madhe është se ne jemi të detyruar të mendojmë jo se si ta projektuojmë dhe ta organizojmë kodin në dosje, ta decompozitojmë, ta bëjmë të mbështetur, të lexueshëm dhe kështu me radhë, por se si ta shkruajmë korrekt këtë komandë, sepse e kam shkruar ndonjëherë gabim.
Si një fillestar, po përpiqeni të mësoni Terraform, por IDE-ja nuk ju ndihmon fare. Kur ka dokumentacion – hyni, shikoni. Por nëse do të hynit në një gjuhë programimi të re, IDE-ja do t'ju tregonte se ka një tip të tillë, dhe një të tillë nuk ka. Të paktën, në nivelin int ose string. Kjo shpesh është shumë e dobishme.
Por si janë testet?
Do të pyesni: "Por si janë testet, zotërinj programues?" Djemtë seriozë testojnë gjithçka në prodhim, dhe kjo është e ashpër. Ja një shembull testi njësi për modulin Terraform nga faqja .
Ata kanë dokumentacion të mirë. Microsoft gjithmonë më ka pëlqyer për qasjen e tyre ndaj dokumentacionit dhe mësimit. Por nuk është e nevojshme të jesh xhaxhai Bob për të kuptuar se këtu nuk është kodi ideal. Kushtojini vëmendje validimit, që është nxjerrë në të djathtë.
Problemi me testin njësi është se ne mund të kontrollojmë saktësinë e JSON-it në dalje. Kam futur 5 parametra, dhe më doli një JSON me 2000 rreshta. Mund ta analizoj çfarë ndodh këtu, ta validoj rezultatin e testit...
Është e vështirë të analizosh Json në Go. Duhet të shkruash në Go, sepse Terraform në Go është një praktikë e mirë për atë që teston në gjuhën në të cilën shkruan. Organizimi i kodit është shumë i dobët. Megjithatë, kjo është biblioteka më e mirë për testimin.
Madre Microsoft shkruan modulat e tij, duke i testuar në këtë mënyrë. Sigurisht, kjo është Open Source. Gjithçka që po them mund të vij dhe të rregulloj. Mund të ulem dhe brenda një jave të rregulloj gjithçka, të bëj open source plugin për VS Code, Terraform, të krijoj një plugin për Rider. Ndoshta, të shkruaj disa analizues, të lidh linters, të kontribuoj në bibliotekën për testim. Mund të bëj gjithçka. Por nuk është kjo që duhet të bëj.
Praktikat më të mira Infrastructure as Code.
Të vazhdojmë më tej. Nëse në IaC nuk ka teste, është dobët me IDE dhe mjetet, atëherë duhet të ketë të paktën praktikat më të mira. Thjesht hyra në Google Analytics dhe bëra një krahasim midis dy kërkesave të kërkimit: praktikave më të mira të Terraform dhe praktikave më të mira të c#.
Çfarë po shohim? Një statistikë të ashpër që nuk është në favorin tonë. Sa i përket sasisë së materialit – është po aq e njëjtë. Në zhvillimin e C#, thjesht notojmë në material, kemi praktikat më të mira, libra të shkruar nga ekspertët, si dhe libra të shkruar nga ekspertë të tjerë që kritikojnë ato libra. Një det i tërë dokumentacioni zyrtar, artikuj, kurse edukative dhe tani edhe zhvillimi open source.
Sa i përket kërkesës për IaC: këtu po përpiqeni të mbledhni informacion në mënyrë të shpërndarë nga prezantimet e high-load-it ose HashiConf, nga dokumentacioni zyrtar dhe shumë çështjeve në GitHub. Si duhet të shpërndahen këto module, çfarë duhet të bëni me to? Duket se kjo është një problem real... Por ekziston një komunitet, zotërinj, ku për çdo pyetje do merrni 10 komente në GitHub. Por kjo nuk është një garanci.
Fatkeqësisht, në këtë moment ekspertët sapo po fillojnë të shfaqen. Aktualisht janë shumë pak. Dhe vetë komiteti është në fazën e hershme.
Në çfarë drejtimi po shkon çdo gjë dhe çfarë duhet të bëjmë
Mund të heqësh gjithçka dhe të kthehesh në C#, në botën e rider-it. Por jo. Pse do të angazhoheshe në këtë, nëse jo për të gjetur një zgjidhje? Më poshtë po sjell përfundimet e mia subjektive. Mund të qëndrosh me mendimin tim në komentet, do të ishte interesante.
Personalish, unë fokusoham në disa gjëra:
- Zhvillimi në këtë fushë po ndodh shumë shpejt. Po sjell grafikun e kërkesave për DevOps.
Ndoshta tema është populiste, por fakti që fusha po rritet, sjell një shpresë të caktuar.Nëse diçka rritet kaq shpejt, do të ketë patjetër njerëz të zgjuar që do të thonë se si duhet bërë dhe si nuk duhet. Rritja e popullaritetit çon në atë që ndoshta dikush do të ketë kohë të përfundojë përfundimisht një plugin për jsonnet për vscode, i cili do të lejojë kalimin në implementimin e funksionit, në vend që ta kërkosh përmes ctrl+shift+f. Kur gjithçka po zhvillohet, ka më shumë materiale. Këtu është edhe dalja e librit nga Google për SRE, një shembull i shkëlqyer për këtë.
- Ka janë metodologji dhe praktika të zhvilluara në zhvillimin e zakonshëm që ne mund t'i aplikojmë me sukses këtu. Po, ka nuanca me testimin dhe mjedisin heterogjen, dhe mungesë mjetesh, por është mbledhur një numër të madh praktikash që mund të jenë të dobishme dhe ndihmuese.
Një shembull banal: puna e përbashkët përmes pair programming. Kjo ndihmon shumë për të kuptuar më mirë. Kur ke një koleg pranë, që gjithashtu po përpiqet të kuptojë diçka, së bashku do të kuptoni më mirë.
Të kuptuarit se si bëhet refaktorizimi ndihmon edhe në një situatë të tillë për ta realizuar atë. Kështu, ti mund të mos e ndryshosh gjithçka në të njëjtën kohë, por të ndryshosh emërtimin, pastaj të ndryshosh pozicionin, pastaj ndoshta të veçosh një pjesë të caktuar, oh, dhe këtu mungojnë komentet.
Përfundimi
Pavarësisht se argumentet e mia mund të duken pesimiste, unë shikoj me shpresë në të ardhmen dhe shpresoj sinqerisht se ne (dhe ju) do të arrijmë të gjithë.
Pas kësaj, po përgatitet pjesa e dytë e artikullit. Në të do të flas për mënyrën se si kemi provuar të aplikojmë praktikat e zhvillimit të fleksibël për të përmirësuar procesin tonë të mësimit dhe punën me infrastrukturën.
Burimi: habr.com
