Kompania jonë është në proces të futjes së një ekipi SRE. Unë hyra në gjithë këtë histori nga ana e zhvillimit. Gjatë procesit, unë dola me mendime dhe njohuri që dua t'i ndaj me zhvilluesit e tjerë. Në këtë artikull reflektimi, unë flas për atë që po ndodh, si po ndodh dhe se si të gjithë mund të vazhdojnë të jetojnë me të.
Vazhdimi i një serie artikujsh të shkruar bazuar në fjalimet në eventin tonë të brendshëm :
2. Infrastruktura si kod. (Ti je ketu)
3. Gjenerimi i kontratave Typescript duke përdorur modele C#. (Në vazhdim...)
4. Hyrje në algoritmin e konsensusit Raft. (Në vazhdim...)
...
Ne vendosëm të krijojmë një ekip SRE, duke zbatuar idetë . Ata rekrutuan programues nga radhët e zhvilluesve të tyre dhe i dërguan të trajnohen për disa muaj.
Ekipi kishte këto detyra stërvitore:
- Përshkruani infrastrukturën tonë, e cila është kryesisht në Microsoft Azure në formën e kodit (Terraform dhe gjithçka përreth).
- Mësoni zhvilluesit se si të punojnë me infrastrukturën.
- Përgatitni zhvilluesit për detyrë.
Ne prezantojmë konceptin e Infrastrukturës si kod
Në modelin e zakonshëm të botës (administrimi klasik), njohuritë për infrastrukturën vendosen në dy vende:
- Ose në formën e njohurive në kokat e ekspertëve.
- Ose ky informacion gjendet në disa makina shkrimi, disa prej të cilave janë të njohura për ekspertët. Por nuk është fakt që një i huaj (në rast se i gjithë ekipi ynë vdes papritur) do të jetë në gjendje të kuptojë se çfarë funksionon dhe si funksionon. Mund të ketë shumë informacione për një makinë: aksesorë, kronjob, të frikësuar (shih. ) disk dhe vetëm një listë e pafund e asaj që mund të ndodhë. Është e vështirë të kuptosh se çfarë po ndodh në të vërtetë.
Në të dyja rastet, ne e gjejmë veten të bllokuar duke u bërë të varur:
- ose nga një person që është i vdekshëm, i nënshtruar sëmundjes, dashurisë, luhatjeve të humorit dhe thjesht pushimeve nga puna banale;
- ose nga një makinë që punon fizikisht, e cila gjithashtu bie, vidhet dhe paraqet surpriza dhe shqetësime.
Është e vetëkuptueshme që në mënyrë ideale çdo gjë duhet të përkthehet në kod të lexueshëm nga njeriu, i mirëmbajtur dhe i shkruar mirë.
Kështu, infrastruktura si kod (Incfastructure as Code - IaC) është një përshkrim i të gjithë infrastrukturës ekzistuese në formën e kodit, si dhe mjeteve përkatëse për të punuar me të dhe për të zbatuar infrastrukturën reale prej saj.
Pse të përktheni gjithçka në kod?Njerëzit nuk janë makina. Ata nuk mund të mbajnë mend gjithçka. Reagimi i një personi dhe një makinerie është i ndryshëm. Çdo gjë e automatizuar është potencialisht më e shpejtë se çdo gjë që bëhet nga një njeri. Gjëja më e rëndësishme është një burim i vetëm i së vërtetës.
Nga vijnë inxhinierët e rinj të SRE?Pra, vendosëm të punësojmë inxhinierë të rinj SRE, por nga t'i marrim ata? Rezervoni me përgjigjet e sakta () na tregon: nga zhvilluesit. Në fund të fundit, ata punojnë me kodin dhe ju arrini gjendjen ideale.
Ne kërkuam shumë për ta për një kohë të gjatë në tregun e personelit jashtë kompanisë sonë. Por duhet të pranojmë se nuk gjetëm askënd që i përshtatej kërkesave tona. Më duhej të kërkoja mes njerëzve të mi.
Problemet Infrastruktura si kod
Tani le të shohim shembuj se si infrastruktura mund të kodohet në kod. Kodi është i shkruar mirë, me cilësi të lartë, me komente dhe dhëmbëzime.
Shembull i kodit nga Terraforma.
Shembull i kodit nga Ansible.
Zotërinj, sikur të ishte kaq e thjeshtë! Ne jemi në botën reale, dhe ajo është gjithmonë e gatshme t'ju befasojë, t'ju paraqesë surpriza dhe probleme. Nuk mund të bëjë pa to as 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ë, çfarë duhet të keni: Json, Yaml, modifikime nga disa kompani të mëdha që dolën me dsl-në e tyre (HCL përdoret në terraform).
Problemi është se mund të mos përmbajë lehtësisht gjëra të tilla të njohura si:
- variabla;
- kushtet;
- diku nuk ka komente, për shembull, në Json, si parazgjedhje ato nuk ofrohen;
- funksione;
- dhe nuk po flas as për gjëra të tilla të nivelit të lartë si klasat, trashëgimia dhe të gjitha këto.
2. Problemi i dytë me një kod të tillë është se më shpesh ai është një mjedis heterogjen. Zakonisht ju uleni dhe punoni me C#, d.m.th. me një gjuhë, një pirg, një ekosistem. Dhe këtu keni një larmi të madhe teknologjish.
Është një situatë shumë reale kur bash me python nis një proces në të cilin futet Json. Ju e analizoni atë, pastaj një gjenerator tjetër prodhon 30 skedarë të tjerë. Për të gjitha këto, variablat e hyrjes merren nga Azure Key Vault, të cilat tërhiqen së bashku nga një plugin për drone.io i shkruar në Go, dhe këto variabla kalojnë përmes yaml, i cili u krijua si rezultat i gjenerimit nga motori i shabllonit jsonnet. Është mjaft e vështirë të kesh një kod të përshkruar rreptësisht mirë kur ke një mjedis kaq të larmishëm.
Zhvillimi tradicional në kuadrin e një detyre vjen me një gjuhë. Këtu punojmë me një numër të madh gjuhësh.
3. Problemi i tretë është akordimi. Jemi mësuar të freskojmë redaktorët (Ms Visual Studio, Jetbrains Rider) që bëjnë gjithçka për ne. Dhe edhe nëse jemi budallenj, ata do të thonë se kemi gabuar. Duket normale dhe e natyrshme.
Por diku afër ka VSCode, në të cilën ka disa shtojca që janë disi të instaluara, të mbështetura ose jo të mbështetura. Versionet e reja dolën dhe nuk u mbështetën. Një tranzicion banal në zbatimin e një funksioni (edhe nëse ai ekziston) bëhet një problem kompleks dhe jo i parëndësishëm. Një riemërtim i thjeshtë i një ndryshoreje është një rishikim në një projekt prej një duzinë skedarësh. Do të jeni me fat nëse ai vendos atë që ju nevojitet. Sigurisht, këtu dhe atje ka ndriçim prapa, ka plotësim automatik, diku ka formatim (edhe pse nuk funksionoi për mua në terraform në Windows).
Në kohën e këtij shkrimi nuk janë lëshuar ende për të mbështetur versionin 0.12, megjithëse është lëshuar për 3 muaj.
Është koha për të harruar...
- Korrigjimi.
- Mjet rifaktorimi.
- Përfundimi automatik.
- Zbulimi i gabimeve gjatë përpilimit.
Është qesharake, por kjo gjithashtu rrit kohën e zhvillimit dhe rrit numrin e gabimeve që ndodhin në mënyrë të pashmangshme.
Gjëja më e keqe është se ne jemi të detyruar të mendojmë jo se si të dizajnojmë, organizojmë skedarët në dosje, dekompozojmë, bëjmë kodin të mirëmbajtur, të lexueshëm etj., por se si mund ta shkruaj këtë komandë saktë, sepse disi e kam shkruar gabim. .
Si fillestar, ju po përpiqeni të mësoni terraforma dhe IDE nuk po ju ndihmon aspak. Kur ka dokumentacion, futuni dhe shikoni. Por nëse do të hynit në një gjuhë të re programimi, IDE do t'ju thoshte se ekziston një lloj i tillë, por nuk ka një gjë të tillë. Të paktën në nivelin int ose string. Kjo është shpesh e dobishme.
Po testet?
Ju pyesni: "Po testet, zotërinj programues?" Djem seriozë testojnë gjithçka në prodhim, dhe është e vështirë. Këtu është një shembull i një testi njësi për një modul terraform nga faqja e internetit .
Kanë dokumentacion të mirë. Më ka pëlqyer gjithmonë Microsoft për qasjen e tij ndaj dokumentacionit dhe trajnimit. Por ju nuk keni nevojë të jeni Xha Bob për të kuptuar se ky nuk është kod i përsosur. Vini re vërtetimin në të djathtë.
Problemi me një test njësi është se ju dhe unë mund të kontrollojmë korrektësinë e daljes Json. Unë hodha 5 parametra dhe më dhanë një këllëf Json me 2000 rreshta. Mund të analizoj se çfarë po ndodh këtu, të vërtetoj rezultatin e testit...
Është e vështirë të analizosh Json në Go. Dhe ju duhet të shkruani në Go, sepse terraform in Go është një praktikë e mirë për testimin në gjuhën në të cilën shkruani. Vetë organizimi i kodit është shumë i dobët. Në të njëjtën kohë, kjo është biblioteka më e mirë për testim.
Microsoft vetë i shkruan modulet e tij, duke i testuar ato në këtë mënyrë. Sigurisht që është Open Source. Gjithçka për të cilën po flas mund të vini dhe të rregulloni. Mund të ulem dhe të rregulloj gjithçka brenda një jave, shtojcat me kod të hapur VS, terraformat, të bëj një shtojcë për kalorësin. Ndoshta shkruani disa analizues, shtoni linja, kontribuoni një bibliotekë për testim. Unë mund të bëj gjithçka. Por kjo nuk është ajo që duhet të bëj.
Praktikat më të mira Infrastruktura si kod
Le të vazhdojmë. Nëse nuk ka teste në IaC, IDE dhe akordimi janë të këqija, atëherë duhet të ketë të paktën praktikat më të mira. Sapo shkova në Google Analytics dhe krahasova dy pyetje kërkimi: praktikat më të mira të Terraform dhe praktikat më të mira të c#.
Çfarë shohim? Statistikat e pamëshirshme nuk janë në favorin tonë. Sasia e materialit është e njëjtë. Në zhvillimin e C#, ne thjesht jemi të mbushur me materiale, kemi praktika super më të mira, ka libra të shkruar nga ekspertë, dhe gjithashtu libra të shkruar në libra nga ekspertë të tjerë që kritikojnë ato libra. Një det dokumentacioni zyrtar, artikujsh, kurse trajnimi dhe tani edhe zhvillim me burim të hapur.
Sa i përket kërkesës së IaC: këtu po përpiqeni të mbledhni informacione pak nga pak nga raportet highload ose HashiConf, nga dokumentacioni zyrtar dhe çështje të shumta në Github. Si t'i shpërndani këto module në përgjithësi, çfarë të bëni me to? Duket se ky është një problem i vërtetë... Ka një komunitet, zotërinj, ku për çdo pyetje do t'ju jepen 10 komente në Github. Por nuk është saktësisht.
Fatkeqësisht, në këtë pikë në kohë, ekspertët sapo kanë filluar të dalin. Ka shumë pak prej tyre deri tani. Dhe vetë komuniteti është i varur në nivelin rudimentar.
Ku po shkon e gjithë kjo dhe çfarë duhet bërë
Mund të heqësh gjithçka dhe të kthehesh në C#, në botën e kalorësve. Por jo. Pse do të shqetësoheni ta bëni këtë nëse nuk mund të gjeni një zgjidhje. Më poshtë po paraqes përfundimet e mia subjektive. Ju mund të debatoni me mua në komente, do të jetë interesante.
Personalisht, unë jam duke vënë bast për disa gjëra:
- Zhvillimi në këtë fushë po ndodh shumë shpejt. Këtu është një orar kërkesash për DevOps.
Tema mund të jetë zhurmë, por vetë fakti që sfera po rritet jep pak shpresë.Nëse diçka rritet kaq shpejt, atëherë patjetër do të shfaqen njerëz të zgjuar që do t'ju tregojnë se çfarë të bëni dhe çfarë jo. Rritja e popullaritetit çon në faktin se ndoshta dikush do të ketë kohë të shtojë më në fund një shtojcë në jsonnet për vscode, e cila do t'ju lejojë të kaloni në zbatimin e funksionit, në vend që ta kërkoni atë përmes ctrl+shift+f. Ndërsa gjërat evoluojnë, shfaqen më shumë materiale. Publikimi i një libri nga Google për SRE është një shembull i shkëlqyer i kësaj.
- Ekzistojnë teknika dhe praktika të zhvilluara në zhvillimin konvencional që ne mund t'i zbatojmë me sukses këtu. Po, ka nuanca me testimin dhe një mjedis heterogjen, vegla të pamjaftueshme, por janë grumbulluar një numër i madh praktikash që mund të jenë të dobishme dhe të dobishme.
Një shembull i parëndësishëm: bashkëpunimi përmes programimit në çift. Ndihmon shumë për ta kuptuar atë. Kur keni një fqinj pranë i cili po përpiqet të kuptojë diçka, së bashku do ta kuptoni më mirë.
Të kuptuarit se si bëhet rifaktorimi ndihmon për ta realizuar atë edhe në një situatë të tillë. Kjo do të thotë, ju nuk mund të ndryshoni gjithçka menjëherë, por ndryshoni emërtimin, pastaj ndryshoni vendndodhjen, pastaj mund të nënvizoni një pjesë, oh, por nuk ka komente të mjaftueshme këtu.
Përfundim
Pavarësisht se arsyetimi im mund të duket pesimist, unë e shikoj të ardhmen me shpresë dhe sinqerisht shpresoj se gjithçka do të funksionojë për ne (dhe për ju).
Pjesa e dytë e artikullit po përgatitet në vazhdim. Në të, unë do të flas për mënyrën se si ne u përpoqëm të përdorim praktikat e zhvillimit të shkathët për të përmirësuar procesin tonë të të mësuarit dhe punën me infrastrukturën.
Burimi: www.habr.com