Kampuni yetu iko katika harakati za kuabiri timu ya SRE. Nilikuja kwenye hadithi hii yote kutoka upande wa maendeleo. Katika mchakato huo, nilikuja na mawazo na maarifa ambayo ningependa kushiriki na wasanidi programu wengine. Katika makala hii ya kutafakari ninazungumzia kile kinachotokea, jinsi kinatokea, na jinsi kila mtu anaweza kuendelea kuishi nacho.
Muendelezo wa mfululizo wa makala yaliyoandikwa kulingana na hotuba katika tukio letu la ndani :
2. Miundombinu kama kanuni. (Uko hapa)
3. Uzalishaji wa mikataba ya Typescript kwa kutumia miundo ya C#. (Inaendelea...)
4. Utangulizi wa algorithm ya makubaliano ya Raft. (Inaendelea...)
...
Tuliamua kuunda timu ya SRE, kutekeleza mawazo . Waliajiri watengenezaji programu kutoka kwa watengenezaji wao wenyewe na kuwatuma kutoa mafunzo kwa miezi kadhaa.
Timu ilikuwa na kazi zifuatazo za mafunzo:
- Eleza miundombinu yetu, ambayo zaidi iko katika Microsoft Azure katika mfumo wa msimbo (Terraform na kila kitu karibu).
- Wafundishe watengenezaji jinsi ya kufanya kazi na miundombinu.
- Tayarisha watengenezaji kwa wajibu.
Tunatanguliza dhana ya Miundombinu kama kanuni
Katika mfano wa kawaida wa ulimwengu (utawala wa kitamaduni), maarifa juu ya miundombinu iko katika sehemu mbili:
- Au kwa namna ya ujuzi katika vichwa vya wataalam.
- Au habari hii iko kwenye mashine za kuchapa, ambazo zingine zinajulikana na wataalam. Lakini sio ukweli kwamba mtu wa nje (ikiwa timu yetu yote itakufa ghafla) ataweza kujua ni nini kinachofanya kazi na jinsi inavyofanya kazi. Kunaweza kuwa na habari nyingi kwenye mashine: vifaa, cronjobs, vitisho (ona. ) diski na orodha isiyo na mwisho ya kile kinachoweza kutokea. Ni vigumu kuelewa ni nini hasa kinatokea.
Katika visa vyote viwili, tunajikuta tumenaswa katika kuwa tegemezi:
- au kutoka kwa mtu ambaye ni wa kufa, chini ya ugonjwa, kuanguka kwa upendo, mabadiliko ya mhemko na kufukuzwa kwa banal tu;
- au kutoka kwa mashine ya kufanya kazi ya kimwili, ambayo pia huanguka, huibiwa, na inatoa mshangao na usumbufu.
Ni wazi kwamba kila kitu kinapaswa kutafsiriwa katika msimbo unaoweza kusomeka, unaoweza kudumishwa na kuandikwa vizuri.
Kwa hivyo, miundombinu kama kanuni (Infastructure as Code - IaC) ni maelezo ya miundombinu yote iliyopo katika mfumo wa kanuni, pamoja na zana zinazohusiana za kufanya kazi nayo na kutekeleza miundombinu halisi kutoka kwayo.
Kwa nini utafsiri kila kitu kwa msimbo?Watu sio mashine. Hawawezi kukumbuka kila kitu. Mwitikio wa mtu na mashine ni tofauti. Kitu chochote kiotomatiki kinaweza kuwa haraka kuliko chochote kinachofanywa na mwanadamu. Jambo muhimu zaidi ni chanzo kimoja cha ukweli.
Wahandisi wapya wa SRE wanatoka wapi?Kwa hiyo, tuliamua kuajiri wahandisi wapya wa SRE, lakini wapi kupata yao? Weka kitabu chenye majibu sahihi () inatuambia: kutoka kwa watengenezaji. Baada ya yote, wanafanya kazi na kanuni, na unafikia hali bora.
Tuliwatafuta sana kwa muda mrefu kwenye soko la wafanyikazi nje ya kampuni yetu. Lakini lazima tukubali kwamba hatukupata mtu yeyote aliyefaa maombi yetu. Ilinibidi kutafuta kati ya watu wangu mwenyewe.
Matatizo Miundombinu kama kanuni
Sasa hebu tuangalie mifano ya jinsi miundombinu inaweza kuwa ngumu katika kanuni. Nambari imeandikwa vizuri, ubora wa juu, na maoni na indentations.
Nambari ya mfano kutoka Terraforma.
Msimbo wa mfano kutoka Ansible.
Waungwana, ikiwa tu ingekuwa rahisi sana! Tuko katika ulimwengu wa kweli, na iko tayari kukushangaza, kukuletea mshangao na shida. Huwezi kufanya bila wao hapa pia.
1. Tatizo la kwanza ni kwamba katika hali nyingi IaC ni aina fulani ya dsl.
Na DSL, kwa upande wake, ni maelezo ya muundo. Kwa usahihi zaidi, unachopaswa kuwa nacho: Json, Yaml, marekebisho kutoka kwa baadhi ya makampuni makubwa ambayo yalikuja na dsl yao wenyewe (HCL inatumika kwa terraform).
Shida ni kwamba inaweza isiwe na vitu vya kawaida kama vile:
- vigezo;
- masharti;
- mahali fulani hakuna maoni, kwa mfano, katika Json, kwa default hawajatolewa;
- kazi;
- na sizungumzii hata juu ya mambo ya hali ya juu kama matabaka, urithi na hayo yote.
2. Shida ya pili ya nambari kama hiyo ni kwamba mara nyingi ni mazingira tofauti. Kawaida unakaa na kufanya kazi na C #, i.e. na lugha moja, rundo moja, mfumo ikolojia mmoja. Na hapa una aina kubwa ya teknolojia.
Ni hali halisi wakati bash na python inazindua mchakato fulani ambao Json ameingizwa. Unaichambua, kisha jenereta nyingine hutoa faili zingine 30. Kwa haya yote, vigeu vya pembejeo hupokelewa kutoka kwa Vault ya Ufunguo wa Azure, ambayo huvutwa pamoja na programu-jalizi ya drone.io iliyoandikwa katika Go, na vigeu hivi hupitia yaml, ambayo ilitolewa kutokana na uzalishaji kutoka kwa injini ya kiolezo cha jsonnet. Ni ngumu sana kuwa na nambari iliyoelezewa vizuri wakati una mazingira tofauti kama haya.
Maendeleo ya kimapokeo ndani ya mfumo wa kazi moja huja na lugha moja. Hapa tunafanya kazi na idadi kubwa ya lugha.
3. Tatizo la tatu ni kurekebisha. Tumezoea kuwafurahisha wahariri (Bis Visual Studio, Jetbrains Rider) ambao hutufanyia kila kitu. Na hata tukiwa wajinga, watasema kwamba tumekosea. Inaonekana ya kawaida na ya asili.
Lakini mahali fulani karibu kuna VSCode, ambayo kuna programu-jalizi ambazo kwa namna fulani zimesakinishwa, kuungwa mkono au hazitumiki. Matoleo mapya yalitoka na hayatumiki. Mpito wa banal kwa kutekeleza kazi (hata ikiwa iko) inakuwa shida ngumu na isiyo ya kawaida. Kubadilisha jina rahisi ni uchezaji wa marudio katika mradi wa faili kadhaa. Utakuwa na bahati ikiwa ataweka kile unachohitaji. Kwa kweli, kuna taa nyuma hapa na pale, kuna ukamilishaji-otomatiki, mahali pengine kuna umbizo (ingawa haikufanya kazi kwangu kwa mpangilio kwenye Windows).
Wakati wa uandishi huu bado haijatolewa ili kusaidia toleo la 0.12, ingawa limetolewa kwa miezi 3.
Ni wakati wa kusahau kuhusu ...
- Utatuzi.
- Chombo cha kurekebisha tena.
- Kukamilisha kiotomatiki.
- Kugundua makosa wakati wa mkusanyiko.
Inachekesha, lakini hii pia huongeza muda wa maendeleo na huongeza idadi ya makosa ambayo hutokea bila kuepukika.
Jambo baya zaidi ni kwamba tunalazimishwa kufikiria sio juu ya jinsi ya kuunda, kupanga faili kwenye folda, kutengana, kufanya msimbo uhifadhiwe, usomeke, na kadhalika, lakini kuhusu jinsi ninaweza kuandika amri hii kwa usahihi, kwa sababu kwa namna fulani niliandika vibaya. .
Kama anayeanza, unajaribu kujifunza terraforms, na IDE haikusaidii hata kidogo. Wakati kuna nyaraka, nenda ndani na uangalie. Lakini ikiwa ungeingia katika lugha mpya ya programu, IDE ingekuambia kuwa kuna aina kama hiyo, lakini hakuna kitu kama hicho. Angalau kwa kiwango cha int au kamba. Hii mara nyingi ni muhimu.
Vipi kuhusu vipimo?
Unauliza: "Vipi kuhusu majaribio, waandaaji wa programu?" Vijana wakubwa hujaribu kila kitu kwenye uzalishaji, na ni ngumu. Hapa kuna mfano wa jaribio la kitengo cha moduli ya terraform kutoka kwa wavuti .
Wana nyaraka nzuri. Nimependa Microsoft kila wakati kwa mbinu yake ya uhifadhi wa nyaraka na mafunzo. Lakini hauitaji kuwa Mjomba Bob kuelewa kuwa hii sio nambari kamili. Kumbuka uthibitisho wa kulia.
Shida ya jaribio la kitengo ni kwamba wewe na mimi tunaweza kuangalia usahihi wa matokeo ya Json. Nilitupa vigezo 5 na nikapewa kitambaa cha miguu cha Json na mistari 2000. Ninaweza kuchambua kinachoendelea hapa, thibitisha matokeo ya mtihani ...
Ni vigumu kumchanganua Json katika Go. Na unahitaji kuandika kwa Go, kwa sababu terraform katika Go ni mazoezi mazuri ya kujaribu katika lugha ambayo unaandika. Shirika la kanuni yenyewe ni dhaifu sana. Wakati huo huo, hii ni maktaba bora ya kupima.
Microsoft yenyewe inaandika moduli zake, kuzijaribu kwa njia hii. Bila shaka ni Open Source. Kila kitu ninachozungumza unaweza kuja kurekebisha. Ninaweza kukaa chini na kurekebisha kila kitu kwa wiki, programu-jalizi za msimbo wa VS wazi, terraforms, kutengeneza programu-jalizi ya mpanda farasi. Labda andika wachambuzi kadhaa, ongeza linters, toa maktaba ya majaribio. Ninaweza kufanya kila kitu. Lakini sivyo ningepaswa kufanya.
Mbinu bora za Miundombinu kama kanuni
Hebu tuendelee. Ikiwa hakuna majaribio katika IaC, IDE na urekebishaji ni mbaya, basi lazima angalau kuwe na mazoea bora. Nimeenda kwa Google Analytics na kulinganisha maswali mawili ya utafutaji: Mbinu bora za Terraform na mbinu bora za c#.
Tunaona nini? Takwimu zisizo na huruma hazitufai. Kiasi cha nyenzo ni sawa. Katika ukuzaji wa C#, tunajishughulisha na nyenzo, tuna mazoea bora zaidi, kuna vitabu vilivyoandikwa na wataalam, na pia vitabu vilivyoandikwa na wataalam wengine wanaokosoa vitabu hivyo. Bahari ya nyaraka rasmi, vifungu, kozi za mafunzo, na sasa pia maendeleo ya chanzo wazi.
Kuhusu ombi la IaC: hapa unajaribu kukusanya taarifa kidogo kidogo kutoka kwa ripoti za juu au za HashiConf, kutoka kwa hati rasmi na masuala mengi kwenye Github. Jinsi ya kusambaza moduli hizi kwa ujumla, nini cha kufanya nao? Inaonekana kwamba hii ni tatizo la kweli ... Kuna jumuiya, waheshimiwa, ambapo kwa swali lolote utapewa maoni 10 kwenye Github. Lakini si hasa.
Kwa bahati mbaya, wakati huu kwa wakati, wataalam wanaanza kujitokeza. Kuna wachache sana kati yao hadi sasa. Na jamii yenyewe inaning'inia katika kiwango cha chini kabisa.
Haya yote yanaenda wapi na nini cha kufanya
Unaweza kuacha kila kitu na kurudi kwa C #, kwa ulimwengu wa mpanda farasi. Lakini hapana. Kwa nini ujisumbue kufanya hivi ikiwa huwezi kupata suluhisho. Hapo chini ninawasilisha hitimisho langu la msingi. Unaweza kubishana nami katika maoni, itakuwa ya kuvutia.
Binafsi, ninaweka dau kwenye mambo machache:
- Maendeleo katika eneo hili yanafanyika haraka sana. Hii hapa ni ratiba ya maombi ya DevOps.
Mada inaweza kuwa hype, lakini ukweli kwamba nyanja inakua inatoa matumaini.Ikiwa kitu kinakua haraka sana, basi watu wenye akili watatokea ambao watakuambia nini cha kufanya na nini usifanye. Kuongezeka kwa umaarufu kunaongoza kwa ukweli kwamba labda mtu atakuwa na wakati wa hatimaye kuongeza programu-jalizi kwa jsonnet kwa vscode, ambayo itawawezesha kuendelea na kutekeleza kazi, badala ya kutafuta kupitia ctrl+shift+f. Kadiri mambo yanavyoendelea, nyenzo zaidi huonekana. Kutolewa kwa kitabu kutoka Google kuhusu SRE ni mfano bora wa hili.
- Kuna mbinu na mazoea yaliyotengenezwa katika ukuzaji wa kawaida ambayo tunaweza kutumia kwa mafanikio hapa. Ndio, kuna nuances na upimaji na mazingira tofauti, zana haitoshi, lakini idadi kubwa ya mazoea imekusanywa ambayo inaweza kuwa muhimu na kusaidia.
Mfano mdogo: ushirikiano kupitia programu ya jozi. Inasaidia sana kuitambua. Unapokuwa na jirani karibu ambaye pia anajaribu kuelewa kitu, pamoja mtaelewa vizuri zaidi.
Kuelewa jinsi refactoring inafanywa husaidia kutekeleza hata katika hali kama hiyo. Hiyo ni, huwezi kubadilisha kila kitu mara moja, lakini ubadilishe jina, kisha ubadilishe eneo, basi unaweza kuonyesha sehemu fulani, oh, lakini hakuna maoni ya kutosha hapa.
Hitimisho
Licha ya ukweli kwamba hoja yangu inaweza kuonekana kuwa ya kukata tamaa, ninatazamia siku zijazo kwa tumaini na tumaini la dhati kwamba kila kitu kitafanya kazi kwa ajili yetu (na wewe).
Sehemu ya pili ya makala inatayarishwa ijayo. Ndani yake, nitazungumza kuhusu jinsi tulivyojaribu kutumia mazoea ya maendeleo ya kisasa ili kuboresha mchakato wetu wa kujifunza na kufanya kazi na miundombinu.
Chanzo: mapenzi.com