Ang aming kumpanya ay nasa proseso ng onboarding ng isang SRE team. Dumating ako sa buong kwentong ito mula sa bahagi ng pag-unlad. Sa proseso, nakaisip ako ng mga kaisipan at insight na gusto kong ibahagi sa ibang mga developer. Sa artikulong ito ng pagmumuni-muni ay pinag-uusapan ko kung ano ang nangyayari, kung paano ito nangyayari, at kung paano patuloy na mabubuhay kasama nito ang lahat.
Pagpapatuloy ng isang serye ng mga artikulo na isinulat batay sa mga talumpati sa aming panloob na kaganapan :
2. Imprastraktura bilang code. (Narito ka)
3. Pagbuo ng mga kontrata ng Typescript gamit ang mga modelong C#. (Isinasagawa...)
4. Panimula sa algorithm ng consensus ng Raft. (Isinasagawa...)
...
Nagpasya kaming lumikha ng isang pangkat ng SRE, na nagpapatupad ng mga ideya . Nag-recruit sila ng mga programmer mula sa kanilang sariling mga developer at ipinadala sila upang magsanay sa loob ng ilang buwan.
Ang koponan ay may mga sumusunod na gawain sa pagsasanay:
- Ilarawan ang aming imprastraktura, na karamihan ay nasa Microsoft Azure sa anyo ng code (Terraform at lahat ng bagay sa paligid).
- Turuan ang mga developer kung paano magtrabaho sa imprastraktura.
- Ihanda ang mga developer para sa tungkulin.
Ipinakilala namin ang konsepto ng Infrastructure bilang code
Sa karaniwang modelo ng mundo (classical administration), ang kaalaman tungkol sa imprastraktura ay matatagpuan sa dalawang lugar:
- O sa anyo ng kaalaman sa mga ulo ng mga eksperto.
- O ang impormasyong ito ay nasa ilang makinilya, na ang ilan ay alam ng mga eksperto. Ngunit hindi isang katotohanan na ang isang tagalabas (kung sakaling ang aming buong koponan ay biglang mamatay) ay magagawang malaman kung ano ang gumagana at kung paano ito gumagana. Maaaring magkaroon ng maraming impormasyon sa isang makina: mga accessory, cronjob, tinakot (tingnan. ) disk at isang walang katapusang listahan ng kung ano ang maaaring mangyari. Mahirap intindihin kung ano ba talaga ang nangyayari.
Sa parehong mga kaso, nakikita natin ang ating sarili na nakulong sa pagiging umaasa:
- o mula sa isang taong mortal, napapailalim sa karamdaman, umiibig, pabagu-bago ng mood at simpleng pagtanggal sa trabaho;
- o mula sa isang pisikal na gumaganang makina, na nahulog din, ninakaw, at nagpapakita ng mga sorpresa at abala.
Hindi sinasabi na ang perpektong lahat ay dapat isalin sa nababasa ng tao, mapanatili, maayos na nakasulat na code.
Kaya, ang imprastraktura bilang code (Incfastructure bilang Code - IaC) ay isang paglalarawan ng buong umiiral na imprastraktura sa anyo ng code, pati na rin ang mga kaugnay na tool para sa pagtatrabaho dito at pagpapatupad ng tunay na imprastraktura mula dito.
Bakit isalin ang lahat sa code?Ang mga tao ay hindi makina. Hindi nila maalala ang lahat. Magkaiba ang reaksyon ng isang tao at ng makina. Ang anumang bagay na awtomatiko ay potensyal na mas mabilis kaysa sa anumang bagay na ginawa ng isang tao. Ang pinakamahalagang bagay ay isang pinagmumulan ng katotohanan.
Saan nagmula ang mga bagong inhinyero ng SRE?Kaya, nagpasya kaming kumuha ng mga bagong inhinyero ng SRE, ngunit saan sila kukuha? Aklat na may tamang sagot () ay nagsasabi sa amin: mula sa mga developer. Pagkatapos ng lahat, gumagana ang mga ito sa code, at nakamit mo ang perpektong estado.
Matagal kaming naghanap sa kanila sa personnel market sa labas ng kumpanya namin. Ngunit kailangan naming aminin na wala kaming nakitang sinuman na nababagay sa aming mga kahilingan. Kinailangan kong maghanap sa aking sariling mga tao.
Problema Imprastraktura bilang code
Ngayon tingnan natin ang mga halimbawa kung paano maaaring i-hardcode ang imprastraktura sa code. Ang code ay mahusay na nakasulat, mataas ang kalidad, na may mga komento at indentasyon.
Halimbawang code mula sa Terraforma.
Halimbawang code mula sa Ansible.
Mga ginoo, kung ito ay napakasimple! Nasa totoong mundo kami, at laging handang sorpresahin ka, ipakita sa iyo ang mga sorpresa at problema. Hindi rin magagawa kung wala sila dito.
1. Ang unang problema ay na sa karamihan ng mga kaso IaC ay isang uri ng dsl.
At ang DSL, sa turn, ay isang paglalarawan ng istraktura. Mas tiyak, kung ano ang dapat na mayroon ka: Json, Yaml, mga pagbabago mula sa ilang malalaking kumpanya na may sariling dsl (ang HCL ay ginagamit sa terraform).
Ang problema ay maaaring madaling hindi ito naglalaman ng mga pamilyar na bagay tulad ng:
- mga variable;
- kundisyon;
- sa isang lugar walang mga komento, halimbawa, sa Json, bilang default ay hindi sila ibinigay;
- mga function;
- at hindi ko man lang pinag-uusapan ang mga bagay na may mataas na antas gaya ng mga klase, mana at lahat ng iyon.
2. Ang pangalawang problema sa naturang code ay madalas na ito ay isang heterogenous na kapaligiran. Kadalasan ay nakaupo ka at nagtatrabaho sa C#, i.e. na may isang wika, isang stack, isang ecosystem. At dito mayroon kang malaking iba't ibang mga teknolohiya.
Ito ay isang tunay na sitwasyon kapag ang bash na may python ay naglulunsad ng ilang proseso kung saan ipinasok si Json. Pag-aralan mo ito, pagkatapos ay gumagawa ang ibang generator ng isa pang 30 file. Para sa lahat ng ito, natatanggap ang mga variable ng input mula sa Azure Key Vault, na pinagsama-sama ng isang plugin para sa drone.io na nakasulat sa Go, at ang mga variable na ito ay dumadaan sa yaml, na nabuo bilang resulta ng pagbuo mula sa jsonnet template engine. Medyo mahirap magkaroon ng mahigpit na inilarawang code kapag mayroon kang magkakaibang kapaligiran.
Ang tradisyonal na pag-unlad sa loob ng balangkas ng isang gawain ay kasama ng isang wika. Dito kami nagtatrabaho sa isang malaking bilang ng mga wika.
3. Ang pangatlong problema ay ang pag-tune. Nakasanayan na namin ang mga cool na editor (Ms Visual Studio, Jetbrains Rider) na ginagawa ang lahat para sa amin. At kahit bobo tayo, sasabihin nilang mali tayo. Parang normal at natural.
Ngunit sa isang malapit na lugar ay mayroong VSCode, kung saan mayroong ilang mga plugin na kahit papaano ay naka-install, sinusuportahan o hindi suportado. Ang mga bagong bersyon ay lumabas at hindi suportado. Ang isang banal na paglipat sa pagpapatupad ng isang function (kahit na ito ay umiiral) ay nagiging isang kumplikado at hindi maliit na problema. Ang isang simpleng pagpapalit ng pangalan ng isang variable ay isang replay sa isang proyekto ng isang dosenang mga file. Maswerte ka kung ilalagay niya ang kailangan mo. Siyempre, mayroong backlighting dito at doon, mayroong auto-completion, sa isang lugar mayroong pag-format (bagaman hindi ito gumana para sa akin sa terraform sa Windows).
Sa oras ng pagsulat na ito ay hindi pa nailalabas upang suportahan ang bersyon 0.12, bagama't ito ay inilabas sa loob ng 3 buwan.
Oras na para kalimutan ang...
- Pagde-debug.
- Refactoring tool.
- Awtomatikong pagkumpleto.
- Pag-detect ng mga error sa panahon ng compilation.
Nakakatawa, ngunit pinapataas din nito ang oras ng pag-unlad at pinapataas ang bilang ng mga error na hindi maiiwasang mangyari.
Ang pinakamasamang bagay ay napipilitan tayong mag-isip hindi tungkol sa kung paano magdisenyo, ayusin ang mga file sa mga folder, mabulok, gawing mapanatili ang code, nababasa, at iba pa, ngunit tungkol sa kung paano ko maisusulat nang tama ang utos na ito, dahil kahit papaano ay naisulat ko ito nang hindi tama. .
Bilang isang baguhan, sinusubukan mong matuto ng mga terraform, at hindi ka talaga tinutulungan ng IDE. Kapag may dokumentasyon, pumasok at tumingin. Ngunit kung nagpapasok ka ng isang bagong programming language, sasabihin sa iyo ng IDE na mayroong ganoong uri, ngunit walang ganoong bagay. Hindi bababa sa antas ng int o string. Ito ay kadalasang kapaki-pakinabang.
Paano ang tungkol sa mga pagsubok?
Itatanong mo: "Paano ang mga pagsubok, mga ginoo na programmer?" Sinusubukan ng mga seryosong lalaki ang lahat sa produksyon, at ito ay matigas. Narito ang isang halimbawa ng isang unit test para sa isang terraform module mula sa website .
Mayroon silang magandang dokumentasyon. Palagi kong gusto ang Microsoft para sa diskarte nito sa dokumentasyon at pagsasanay. Ngunit hindi mo kailangang maging Uncle Bob para maunawaan na hindi ito perpektong code. Tandaan ang pagpapatunay sa kanan.
Ang problema sa isang pagsubok sa yunit ay maaari mong suriin ang kawastuhan ng output ng Json. Naghagis ako ng 5 parameter at binigyan ako ng isang Json footcloth na may 2000 na linya. Maaari kong pag-aralan kung ano ang nangyayari dito, patunayan ang resulta ng pagsubok...
Mahirap i-parse si Json sa Go. At kailangan mong magsulat sa Go, dahil ang terraform sa Go ay isang magandang kasanayan para sa pagsubok sa wika kung saan ka nagsusulat. Ang organisasyon ng code mismo ay napakahina. Kasabay nito, ito ang pinakamahusay na library para sa pagsubok.
Ang Microsoft mismo ay nagsusulat ng mga module nito, sinusubukan ang mga ito sa ganitong paraan. Syempre Open Source ito. Lahat ng sinasabi ko ay pwede mong puntahan at ayusin. Maaari akong umupo at ayusin ang lahat sa isang linggo, open source VS code plugins, terraforms, gumawa ng plugin para sa rider. Maaaring magsulat ng ilang mga analyzer, magdagdag ng mga linter, mag-ambag ng isang library para sa pagsubok. Kaya kong gawin lahat. Pero hindi iyon ang dapat kong gawin.
Pinakamahuhusay na kagawian Imprastraktura bilang code
Mag-move on na tayo. Kung walang mga pagsubok sa IaC, ang IDE at pag-tune ay masama, kung gayon dapat mayroong hindi bababa sa mga pinakamahusay na kasanayan. Pumunta lang ako sa Google Analytics at naghambing ng dalawang query sa paghahanap: Mga pinakamahuhusay na kagawian sa Terraform at pinakamahuhusay na kagawian sa c#.
Ano ang nakikita natin? Ang walang awa na mga istatistika ay hindi pabor sa amin. Ang dami ng materyal ay pareho. Sa pag-unlad ng C#, kami ay nahuhulog lang sa mga materyales, mayroon kaming mga super-best na kasanayan, may mga aklat na isinulat ng mga eksperto, at pati na rin ang mga aklat na isinulat sa mga libro ng ibang mga eksperto na pumupuna sa mga aklat na iyon. Isang dagat ng opisyal na dokumentasyon, mga artikulo, mga kurso sa pagsasanay, at ngayon din ang pag-unlad ng open source.
Tungkol sa kahilingan ng IaC: dito sinusubukan mong mangolekta ng impormasyon nang paunti-unti mula sa highload o mga ulat ng HashiConf, mula sa opisyal na dokumentasyon at maraming mga isyu sa Github. Paano ipamahagi ang mga module na ito sa pangkalahatan, ano ang gagawin sa kanila? Tila ito ay isang tunay na problema ... May isang komunidad, mga ginoo, kung saan para sa anumang tanong ay bibigyan ka ng 10 komento sa Github. Ngunit hindi ito eksakto.
Sa kasamaang palad, sa puntong ito ng oras, ang mga eksperto ay nagsisimula pa lamang na lumitaw. Napakakaunti sa kanila sa ngayon. At ang komunidad mismo ay tumatambay sa paunang antas.
Saan patungo ang lahat ng ito at kung ano ang gagawin
Maaari mong i-drop ang lahat at bumalik sa C#, sa mundo ng rider. Pero hindi. Bakit mo pa ito gagawin kung hindi mo mahanap ang solusyon. Sa ibaba ay ipinakita ko ang aking mga subjective na konklusyon. Maaari kang makipagtalo sa akin sa mga komento, ito ay magiging kawili-wili.
Sa personal, tumaya ako sa ilang bagay:
- Ang pag-unlad sa lugar na ito ay nangyayari nang napakabilis. Narito ang isang iskedyul ng mga kahilingan para sa DevOps.
Maaaring hype ang paksa, ngunit ang mismong katotohanan na lumalaki ang globo ay nagbibigay ng kaunting pag-asa.Kung ang isang bagay ay lumalaki nang napakabilis, pagkatapos ay tiyak na lilitaw ang mga matalinong tao na magsasabi sa iyo kung ano ang dapat gawin at kung ano ang hindi dapat gawin. Ang pagtaas ng katanyagan ay humahantong sa katotohanan na marahil ay magkakaroon ng oras ang isang tao upang sa wakas ay magdagdag ng isang plugin sa jsonnet para sa vscode, na magbibigay-daan sa iyong magpatuloy sa pagpapatupad ng function, sa halip na hanapin ito sa pamamagitan ng ctrl+shift+f. Habang umuunlad ang mga bagay, mas maraming materyales ang lumilitaw. Ang paglabas ng isang libro mula sa Google tungkol sa SRE ay isang mahusay na halimbawa nito.
- May mga binuong pamamaraan at kasanayan sa kumbensyonal na pag-unlad na matagumpay nating mailalapat dito. Oo, may mga nuances sa pagsubok at isang heterogenous na kapaligiran, hindi sapat na tooling, ngunit isang malaking bilang ng mga kasanayan ang naipon na maaaring maging kapaki-pakinabang at kapaki-pakinabang.
Isang maliit na halimbawa: pakikipagtulungan sa pamamagitan ng pares programming. Malaki ang naitutulong upang malaman ito. Kapag mayroon kang kapitbahay sa malapit na sinusubukan ding unawain ang isang bagay, magkakasama kang mas mauunawaan.
Ang pag-unawa kung paano ginagawa ang refactoring ay nakakatulong upang maisakatuparan ito kahit na sa ganoong sitwasyon. Iyon ay, hindi mo maaaring baguhin ang lahat nang sabay-sabay, ngunit baguhin ang pagpapangalan, pagkatapos ay baguhin ang lokasyon, pagkatapos ay maaari mong i-highlight ang ilang bahagi, oh, ngunit walang sapat na mga komento dito.
Konklusyon
Sa kabila ng katotohanan na ang aking pangangatwiran ay maaaring mukhang pessimistic, tumingin ako sa hinaharap nang may pag-asa at taos-pusong umaasa na ang lahat ay gagana para sa amin (at sa iyo).
Ang ikalawang bahagi ng artikulo ay inihahanda sa susunod. Sa loob nito, pag-uusapan ko ang tungkol sa kung paano namin sinubukang gumamit ng mga maliksi na kasanayan sa pag-unlad upang mapabuti ang aming proseso ng pag-aaral at magtrabaho kasama ang imprastraktura.
Pinagmulan: www.habr.com