Mūsu uzņēmumā notiek SRE komandas onboarding process. Es pievienojos šai lietai no izstrādes puses. Procesa laikā man radās domas un ieskati, ar kuriem es vēlos dalīties ar citiem izstrādātājiem. Šajā rakstā-es domāju, es runāju par to, kas notiek, kā notiek un kā visiem tālāk ar to dzīvot.
Turpinājums rakstu sērijai, kas rakstīta uz iekšējo pasākumu uzstāšanās motīviem. :
2. Infrastruktūra kā kods. (Tu esi šeit)
3. Typescript līgumu ģenerēšana no c# modeļiem. (Process turpinās…)
4. Ievads Raft konsensa algoritmā. (Process turpinās…)
…
Mēs nolēmām izveidot SRE komandu, īstenojot idejas . Ieguvām programmētājus no saviem izstrādātājiem un nosūtījām viņus mācīties uz dažiem mēnešiem.
Komanda saskārās ar sekojošiem mācību uzdevumiem:
- Pārveidot mūsu infrastruktūru, kas lielākoties ir Microsoft Azure, kodā (Terraform un viss, kas pie tā piedera).
- Iemācīt izstrādātājiem strādāt ar infrastruktūru.
- Sagatavot izstrādātājus dežūrām.
Ieviešam jēdzienu Infrastruktūra kā kods.
Parastajā pasaules modelī (klasiskais administrēšana) zināšanas par infrastruktūru atrodas divās vietās:
- Vai nu ekspertu prātu zināšanās.
- Vai šīs zināšanas atrodas kādās iekārtās, no kurām daļu zina eksperti. Bet nav garantijas, ka kāds no malas (ja mūsu komanda pēkšņi aizietu) spēs saprast, kas un kā darbojas. Mašīnā var būt daudz informācijas: piekļuves, cron uzdevumi, pielāgots (skat. ) disks un vienkārši bezgalīgs saraksts ar to, kas var notikt. Ar to grūti saprast, kas realitātē notiek.
Abos gadījumos mēs nonākam slazdā, kļūstot atkarīgi:
- vai nu no cilvēka, kurš ir mirstīgs, pakļauts slimībām, iemīlēšanām, garastāvokļa svārstībām un vienkāršiem atlaišanas gadījumiem;
- vai nu no fiziski strādājošas mašīnas, kas arī var sabojāties, tikt nolaupīta, radīt pārsteigumus un neērtības.
Pašsaprotami, ka risinājums ir ideāli visu pārvērst cilvēka lasāmā, uzturētā, kvalitatīvi rakstītā kodā.
Tādējādi infrastruktūra kā kods (Infrastructure as Code – IaC) ir visu pieejamo infrastruktūras apraksts koda veidā, kā arī saistītie rīki, kas ļauj ar to strādāt un realizēt reālu infrastruktūru no tā.
Kāpēc visu pārvērst kodāCilvēki nav mašīnas. Viņi nevar atcerēties visu. Cilvēka un mašīnas reakcija ir atšķirīga. Viss automatizētais potenciāli darbojas ātrāk nekā viss, ko dara cilvēks. Galvenais ir viens patiesības avots (single source of truth).
Kā rodas jauni SRE inženieriTātad mēs nolēmām pievienot jaunus SRE inženierus, bet no kurienes tos ņemt? Grāmata ar pareizajām atbildēm () māca, ka no izstrādātājiem. Galu galā viņi strādā ar kodu, un jūs sasniedzat ideālo stāvokli.
Mēs ilgi un cītīgi meklējām viņus darba tirgū ārpus mūsu uzņēmuma. Bet esam spiesti atzīt, ka neatradām nevienu, kas atbilstu mūsu prasībām. Vajadzēja tīrīt starp savējiem.
Infrastruktūras kā koda problēmas
Tagad aplūkosim piemērus tam, kā infrastruktūra var būt ierakstīta kodā. Kodam jābūt labi uzrakstītam, kvalitatīvam, ar komentāriem un atstarpēm.
Koda piemērs no Terraform.
Koda piemērs no Ansible.
Dārgie kolēģi, bet ja viss būtu tik vienkārši! Mēs taču esam reālajā pasaulē, un tā vienmēr ir gatava jūs pārsteigt ar pārsteigumiem un problēmām. Šeit tas arī nav izņēmums.
1. Pirma problēma ir tāda, ka visbiežāk IaC ir kāds DSL.
Un DSL, savukārt, ir struktūras apraksts. Precīzāk, tas, kas jums jābūt: Json, Yaml, izmaiņas no kādām lielām kompānijām, kuras izstrādājušas savu DSL (Terraformā tiek izmantots HCL).
Problēma ir tāda, ka tajā var viegli nepietikt tādām ierastām lietām kā:
- mainīgie;
- apstākļi;
- kaut kur nav komentāru, piemēram, Json, to noklusējumā nav paredzēti;
- funkcijas;
- un to vēl pat nepieminot augstākā līmeņa lietas, piemēram, klases, mantošana un visu pārējo.
2. Otrā šāda koda problēma – visbiežāk tas ir heterogēna vide.. Parasti jūs sēžat un strādājat ar C#, t.i., ar vienu valodu, vienu steku, vienu ekosistēmu. Bet šeit jums ir milzīgs tehnoloģiju daudzveidības spektrs.
Pavisam reāla situācija ir tāda, ka bash ar Python izpilda kādu procesu, kurā tiek iekļauts JSON. Jūs to analizējat, pēc tam vēl kāds ģenerators izdod vēl 30 failus. Visam šim ienāk ieejas mainīgie no Azure Key Vault, kas paņemti ar drone.io spraudni, kas uzrakstīts Go, un šie mainīgie tiek apstrādāti caur YAML, kas iegūts, ģenerējot no jsonnet veidne. Pietiekami grūti ir saglabāt precīzi labi aprakstītu kodu, kad jums ir tik dažāda vide.
Tradicionālā izstrāde vienas uzdevuma ietvaros notiek ar vienu valodu. Šajā gadījumā mēs strādājam ar daudzām valodām.
3. Trešā problēma ir rīku izmantošana.. Mēs esam pieraduši pie foršiem redaktoriem (Ms Visual Studio, Jetbrains Rider), kuri visu dara mūsu vietā. Un pat ja mēs nedaudz kļūdāmies, tie mums paziņo, ka neesam pareizi. Izskatās, ka tas ir normāli un dabiski.
Bet blakus ir VSCode, kurā ir daži spraudņi, kas kaut kā tiek uzstādīti, atbalstīti vai neatbalstīti. Iznāca jaunas versijas, kuras netika atbalstītas. Parasts pāreja uz funkcijas īstenošanu (pat ja tā ir) kļūst sarežģīta un netriviala problēma. Vienkārša mainīgā pārdēvēšana ir meklēšana projektā desmitos failu. Veiksmes gadījumā tā aizvietos to, kas nepieciešams. Protams, kaut kur ir sintakses izcelšana, ir automātiskā pabeigšana, kaut kur ir formatēšana (bet man tas terrafārmē uz Windows neizdevās).
Šī raksta rakstīšanas brīdī vēl nav izlaists, lai atbalstītu versiju 0.12, lai gan tā ir izlaista jau pirms 3 mēnešiem.
Ir pienācis laiks aizmirst par...
- Numuru novēršanas rīku.
- Mērķis ir atkal aprakstīts.
- Automātiskā pabeigšana.
- Kļūdu atklāšana kompilēšanas laikā.
Ir smieklīgi, bet tas palielina attīstības laiku un palielina neizbēgamās kļūdas, kas noteikti notiek.
Visbīstamākais ir tas, ka mēs esam spiesti domāt nevis par to, kā pareizi noformēt, kā salikt failus mapēs, dekomponēt, padarīt atbalstāmu, lasāmu kodu un tā tālāk, bet par to, kā es varu pareizi uzrakstīt šo komandu, jo es to kaut kā nepareizi uzrakstīju.
Kā iesācējs jūs mēģināt saprast Terraform, bet IDE jums nepalīdz. Kad ir dokumentācija - jūs ieejat un paskatāties. Bet, ja jūs iemācāties jaunu programmēšanas valodu, IDE norādītu, ka ir šāds tips, un tāda nav. Vismaz int vai string līmenī. Tas bieži ir noderīgi.
Bet kā ar testiem?
Jūs varētu jautāt: „Kā tad ar testiem, godājamie programmētāji?” Nopietni speciālisti visu testē ražošanā, un tas ir nopietni. Šeit ir piemere vienību testa Terraform moduļa ar vietni. .
Viņiem ir laba dokumentācija. Microsoft vienmēr ir patikuši viņu pieeja dokumentācijai un mācībām. Bet nevajag būt tēti Bobam, lai saprastu, ka šeit nav ideāls kods. Pievērsiet uzmanību validācijai, kas ir izdalīta pa labi.
Problēma ar vienību testu ir tāda, ka mēs varam pārbaudīt Jsona precizitāti iznākumā. Es ievadīju 5 parametrus, un man tika izsniegts Json pavadījums ar 2000 rindām. Es varu analizēt, kas te notiek, validēt testu rezultātu…
Grūti analizēt Json Go. Un jā, ir jāraksta Go, jo Terraform ir Go – tā ir laba prakse testēt tajā valodā, kurā raksti. Paša koda organizācija ir ļoti vājš. Tomēr šī ir labākā bibliotēka testēšanai.
Pats Microsoft raksta savus moduļus, testējot tos šādā veidā. Protams, tā ir Open Source. Viss, par ko es runāju, ir tāдā veidā, ka jūs varat nākt un labot. Es varu sēdēt un nedēļas laikā visu salabot, open-sorcēt VS Code spraudņus, Terraform, izveidot spraudni Rideram. Varbūt uzrakstīt pāris analizatorus, pievienot linters, ieguldīt bibliotēkā testēšanai. Viss, ko es varu izdarīt. Bet man nevajadzētu to darīt.
Labākās prakses Infrastructure as code
Turpinām. Ja IaC nav testu, ir slikti ar IDE un rīkiem, tad vismaz jābūt labākajām praksēm. Es vienkārši iegāju Google Analytics un veicu divu meklējumu pieprasījumu salīdzinājumu: Terraform labākās prakses un C# labākās prakses.
Ko mēs redzam? Nežēlīgu statistiku ne mūsu labā. Attiecībā uz materiāla apjomu – tas ir tas pats. C# izstrādē mēs vienkārši peldamies materiālos, mums ir vislabākās prakses, ir grāmatas, ko uzrakstījuši eksperti, un arī grāmatas, ko uzrakstījuši pie ekspertiem, kas kritizē tās grāmatas. Jūra oficiālās dokumentācijas, rakstu, mācību kursu, tagad vēl arī open source izstrāde.
Attiecībā uz IaC pieprasījumu: šeit jūs pa maziem gabaliem mēģināt savākt informāciju no augsta slodzes ziņojumiem vai HashiConf, no oficiālās dokumentācijas un daudziem jautājumiem GitHub. Kā vispār izplatīt šos moduļus, ko ar tiem darīt? Izskatās, ka tas ir reāls izaicinājums… Ir taču kopiena, godājamie, kur uz jebkuru jautājumu jums dos 10 komentārus GitHub. Bet tā nav tāda garantija.
Diemžēl šobrīd eksperti tikai sāk parādīties. Līdz šim to ir pārāk maz. Un visa kopiena ir tikai savas attīstības sākumstadijā.
Uz kuru pusi tas viss virzās un ko darīt
Varbūt visu pamest un atgriezties pie C#, uz rajdera pasauli. Bet nē. Kāpēc jūs vispār to darītu, ja neatrast risinājumu? Zemāk es sniedzu savus subjektīvos secinājumus. Varat ar mani strīdēties komentāru sadaļā, būs interesanti.
Personīgi es esmu izvēlējies vairākas lietas:
- Attīstība šajā jomā norit ļoti ātri. Šeit ir pieprasījumu grafiks par DevOps.
Varbūt tēma ir modīga, bet fakts, ka joma aug, sniedz zināmu cerību.Ja kaut kas aug tik ātri, noteikti parādīsies gudri cilvēki, kas teiks, kā tas jādara un kā ne. Pieaugot popularitātei, kāds galu galā varēs pabeigt jsonnet spraudni VSCode, kas ļaus pāriet uz funkcijas implementāciju, nevis meklēt to caur ctrl+shift+f. Kad viss attīstās, parādās vairāk materiālu. Tas pats Google jaunā grāmata par SRE ir lielisks tam piemērs.
- Ikdienas izstrādē ir izstrādātas metodes un prakses, kuras mēs varam veiksmīgi izmantot šeit. Jā, ir nianses ar testēšanu un heterogēnu vidi, nepietiekama rīku komplekta, bet ir uzkrāta liela skaitā prakses, kas var būt noderīgas un palīdzēt.
Banāls piemērs: kopdarbs, izmantojot pair programming. Tas ļoti palīdz labāk saprast. Kad tev blakus ir kaimiņš, kurš arī mēģina kaut ko saprast, kopā jūs sapratīsiet labāk.
Izpratne par to, kā notiek refaktorizācija, palīdz arī šādā situācijā to veikt. Tas nozīmē, ka tu vari nemainīt visu uzreiz, bet mainīt nosaukumus, tad mainīt izvietojumu, pēc tam varbūt izcelt kādu daļu, ak, šeit trūkst komentāru.
Secinājums
Neskatoties uz to, ka mani spriedumi var šķist pesimistiski, es ar cerību skatos nākotnē un patiesi ceru, ka mums (un jums) viss izdosies.
Nākamajā daļā gatavojas otrais raksts. Tajā es pastāstīšu par to, kā mēs mēģinājām pielietot elastīgas izstrādes prakses, lai uzlabotu mūsu mācību procesu un darbu ar infrastruktūru.
Avots: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish