Şirkətimiz SRE komandasının işə qəbulu prosesindədir. Mən bütün bu hekayəyə inkişaf tərəfdən gəldim. Bu prosesdə mən digər tərtibatçılarla bölüşmək istədiyim fikirlər və anlayışlar əldə etdim. Bu əks məqalədə nə baş verdiyini, necə baş verdiyini və hər kəsin bununla necə yaşamağa davam edə biləcəyini danışıram.
Daxili tədbirimizdə çıxışlar əsasında yazılan silsilə yazıların davamı :
2. İnfrastruktur kod kimi. (Burdasan)
3. C# modellərindən istifadə edərək Typescript müqavilələrinin yaradılması. (Davam edir...)
4. Raft konsensus alqoritminə giriş. (Davam edir...)
...
Biz ideyaları həyata keçirərək SRE komandası yaratmağa qərar verdik . Onlar öz tərtibatçıları arasından proqramçıları işə götürdülər və onları bir neçə ay məşq etməyə göndərdilər.
Komandanın aşağıdakı məşq vəzifələri var idi:
- Əsasən Microsoft Azure-da kod şəklində olan infrastrukturumuzu təsvir edin (Terraform və ətrafdakı hər şey).
- Tərtibatçılara infrastrukturla işləməyi öyrədin.
- Tərtibatçıları vəzifəyə hazırlayın.
İnfrastruktur anlayışını kod kimi təqdim edirik
Adi dünya modelində (klassik idarəetmə) infrastruktur haqqında biliklər iki yerdə yerləşir:
- Yaxud ekspertlərin başlarında bilik şəklində.
- Yaxud bu məlumat bəzi yazı makinalarındadır, bəziləri isə mütəxəssislərə məlumdur. Ancaq autsayderin (bütün komandamız qəfil öləcəyi təqdirdə) nəyin işlədiyini və necə işlədiyini anlaya biləcəyi fakt deyil. Maşın haqqında çoxlu məlumat ola bilər: aksesuarlar, cronjobs, qorxudan (bax. ) disk və baş verə biləcəklərin sadəcə sonsuz siyahısı. Həqiqətən nə baş verdiyini anlamaq çətindir.
Hər iki halda biz özümüzü asılı vəziyyətə salmış vəziyyətdə görürük:
- və ya ölümcül, xəstəliyə məruz qalan, aşiq olan, əhval dəyişikliyi və sadəcə bayağı işdən çıxarılan bir insandan;
- və ya fiziki olaraq işləyən maşından, o da düşür, oğurlanır və sürprizlər və narahatlıqlar təqdim edir.
Sözsüz ki, ideal olaraq hər şey insan tərəfindən oxuna bilən, saxlanıla bilən, yaxşı yazılmış koda çevrilməlidir.
Beləliklə, kod kimi infrastruktur (Incfastructure as Code - IaC) bütün mövcud infrastrukturun kod şəklində təsviri, həmçinin onunla işləmək və ondan real infrastrukturun həyata keçirilməsi üçün əlaqəli alətlərdir.
Niyə hər şeyi koda çevirmək lazımdır?İnsanlar maşın deyil. Hər şeyi xatırlaya bilmirlər. İnsanın və maşının reaksiyası fərqlidir. Avtomatlaşdırılmış hər şey insan tərəfindən edilən hər şeydən potensial olaraq daha sürətlidir. Ən əsası həqiqətin yeganə mənbəyidir.
Yeni SRE mühəndisləri haradan gəlir?Beləliklə, biz yeni SRE mühəndislərini işə götürmək qərarına gəldik, amma onları haradan əldə etmək olar? Düzgün cavablarla rezervasiya edin () bizə deyir: tərtibatçılardan. Axı onlar kodla işləyirlər və siz ideal vəziyyətə çatırsınız.
Uzun müddət şirkətimizdən kənarda kadr bazarında onları çox axtardıq. Amma etiraf etməliyik ki, bizim istəklərimizə uyğun gələni tapmadıq. Öz xalqım arasında axtarmalı oldum.
Problemlər İnfrastruktur kod kimi
İndi infrastrukturun koda necə kodlaşdırıla biləcəyinə dair nümunələrə baxaq. Kod yaxşı yazılıb, yüksək keyfiyyətli, şərhlər və boşluqlarla.
Terraforma-dan nümunə kodu.
Ansible-dan nümunə kodu.
Cənablar, kaş bu qədər sadə olsaydı! Biz real dünyadayıq və o, sizi təəccübləndirməyə, sürprizlər və problemlər təqdim etməyə həmişə hazırdır. Onlarsız burada da edə bilməz.
1. Birinci problem, əksər hallarda IaC-nin bir növ dsl olmasıdır.
Və DSL, öz növbəsində, strukturun təsviridir. Daha doğrusu, nəyə sahib olmalısınız: Json, Yaml, öz dsl ilə çıxan bəzi böyük şirkətlərin modifikasiyaları (HCL terraformda istifadə olunur).
Problem ondadır ki, o, asanlıqla belə tanış şeyləri ehtiva edə bilməz:
- dəyişənlər;
- şərtlər;
- bir yerdə şərhlər yoxdur, məsələn, Json-da, standart olaraq təmin edilmir;
- funksiyalar;
- və hətta siniflər, miras və bütün bunlar kimi yüksək səviyyəli şeylərdən danışmıram.
2. Belə kodun ikinci problemi ondan ibarətdir ki, əksər hallarda bu, heterojen bir mühitdir. Adətən siz oturub C# ilə işləyirsiniz, yəni. bir dil, bir yığın, bir ekosistem ilə. Və burada çox müxtəlif texnologiyalarınız var.
Python ilə bash Json-un daxil olduğu bəzi prosesi işə saldıqda çox real vəziyyətdir. Siz onu təhlil edirsiniz, sonra başqa bir generator daha 30 fayl yaradır. Bütün bunlar üçün giriş dəyişənləri Azure Key Vault-dan qəbul edilir ki, onlar Go-da yazılmış drone.io üçün plagin tərəfindən yığılır və bu dəyişənlər jsonnet şablon mühərrikindən generasiya nəticəsində yaranan yaml-dan keçir. Bu qədər müxtəlif mühitiniz olduqda ciddi şəkildə yaxşı təsvir edilmiş koda sahib olmaq olduqca çətindir.
Bir vəzifə çərçivəsində ənənəvi inkişaf bir dillə gəlir. Burada çoxlu dillərlə işləyirik.
3. Üçüncü problem köklənmədir. Bizim üçün hər şeyi edən redaktorları (Ms Visual Studio, Jetbrains Rider) sərinləməyə öyrəşmişik. Bir də axmaq olsaq belə deyəcəklər ki, biz səhv edirik. Normal və təbii görünür.
Ancaq yaxınlıqda bir yerdə quraşdırılmış, dəstəklənən və ya dəstəklənməyən bəzi plaginlər olan VSCode var. Yeni versiyalar çıxdı və dəstəklənmir. Funksiyanı həyata keçirmək üçün banal keçid (hətta mövcud olsa belə) mürəkkəb və qeyri-trivial problemə çevrilir. Dəyişənin sadə adının dəyişdirilməsi onlarla fayldan ibarət layihənin təkrarıdır. O sizə lazım olanı yerləşdirsə, şanslı olacaqsınız. Əlbəttə ki, burada və orada arxa işıqlandırma var, avtomatik tamamlama var, haradasa formatlama var (baxmayaraq ki, Windows-da terraformda mənim üçün işləmədi).
Bu yazı zamanı 0.12 aydır buraxılmasına baxmayaraq, 3 versiyasını dəstəkləmək üçün hələ buraxılmayıb.
Unutmaq vaxtıdır...
- Hata ayıklama.
- Refaktorinq aləti.
- Avtomatik tamamlama.
- Kompilyasiya zamanı səhvlərin aşkar edilməsi.
Gülməli, lakin bu həm də inkişaf müddətini artırır və qaçılmaz olaraq baş verən səhvlərin sayını artırır.
Ən pisi odur ki, biz necə dizayn etmək, faylları qovluqlarda təşkil etmək, parçalamaq, kodun saxlanıla bilən, oxunaqlı olması və s. haqqında deyil, bu əmri necə düzgün yaza biləcəyimi düşünməyə məcburuq, çünki mən onu birtəhər səhv yazmışam. .
Bir başlanğıc olaraq, terraformları öyrənməyə çalışırsınız və IDE sizə heç kömək etmir. Sənədləri olanda içəri girib baxın. Ancaq yeni bir proqramlaşdırma dilinə daxil olsaydınız, IDE sizə belə bir növün olduğunu söyləyərdi, lakin belə bir şey yoxdur. Ən azı int və ya string səviyyəsində. Bu tez-tez faydalıdır.
Bəs testlər?
Siz soruşursunuz: "Bəs testlər, cənab proqramçılar?" Ciddi adamlar istehsalda her seyi yoxlayir ve cox cetindir. Veb saytından terraform modulu üçün vahid test nümunəsidir .
Onların yaxşı sənədləri var. Mən həmişə Microsoft-u sənədlərə və təlimlərə yanaşmasına görə bəyənmişəm. Ancaq bunun mükəmməl kod olmadığını başa düşmək üçün Bob əmi olmağa ehtiyac yoxdur. Sağdakı doğrulamaya diqqət yetirin.
Vahid testində problem ondadır ki, siz və mən Json çıxışının düzgünlüyünü yoxlaya bilərik. Mənə 5 parametr atdım və 2000 sətirdən ibarət Json ayaq örtüyü verdim. Mən burada baş verənləri təhlil edə, test nəticəsini təsdiqləyə bilərəm...
Go-da Json-u təhlil etmək çətindir. Və siz Go-da yazmalısınız, çünki Go-da terraform yazdığınız dildə test etmək üçün yaxşı təcrübədir. Kodun özünün təşkili çox zəifdir. Eyni zamanda, bu, sınaq üçün ən yaxşı kitabxanadır.
Microsoft özü modullarını yazır, onları bu şəkildə sınaqdan keçirir. Əlbəttə ki, açıq mənbədir. Haqqında danışdığım hər şey gəlib düzəldə bilər. Mən oturub bir həftə ərzində hər şeyi düzəldə bilərəm, açıq mənbə VS kodu plaginləri, terraformlar, atlı üçün plagin düzəldə bilərəm. Bəlkə bir neçə analizator yazın, linterlər əlavə edin, sınaq üçün kitabxanaya töhfə verin. Mən hər şeyi edə bilərəm. Amma etməli olduğum şey bu deyil.
Ən yaxşı təcrübələr İnfrastruktur kod kimi
Gəlin davam edək. IaC-də testlər yoxdursa, IDE və tuning pisdirsə, ən azı ən yaxşı təcrübələr olmalıdır. Mən indicə Google Analytics-ə getdim və iki axtarış sorğusunu müqayisə etdim: Terraform ən yaxşı təcrübələri və C# ən yaxşı təcrübələri.
Biz nə görürük? Acımasız statistika bizim xeyrimizə deyil. Materialın miqdarı eynidir. C# inkişafında biz sadəcə olaraq materiallarla doluyuq, super ən yaxşı təcrübələrimiz var, ekspertlər tərəfindən yazılmış kitablar, həmçinin bu kitabları tənqid edən digər ekspertlərin kitabları üzərində yazılmış kitablar var. Rəsmi sənədlər, məqalələr, təlim kursları və indi də açıq mənbə inkişafı dənizi.
IaC sorğusuna gəlincə: burada siz yüksək yüklənmə və ya HashiConf hesabatlarından, rəsmi sənədlərdən və Github-dakı çoxsaylı məsələlərdən az-az məlumat toplamağa çalışırsınız. Ümumiyyətlə bu modulları necə yaymaq olar, onlarla nə etmək lazımdır? Deyəsən, bu, əsl problemdir... Cənablar, hər hansı bir sual üçün Github-da sizə 10 şərh veriləcək bir icma var. Amma dəqiq deyil.
Təəssüflər olsun ki, indiki məqamda ekspertlər yenicə ortaya çıxmağa başlayır. İndiyə qədər onlardan çox azdır. Cəmiyyətin özü isə ibtidai səviyyədə asılır.
Bütün bunlar hara gedir və nə etməli
Siz hər şeyi atıb C#-a, atlı dünyasına qayıda bilərsiniz. Amma yox. Əgər bir həll tapa bilmirsinizsə, niyə belə məşğul olursunuz? Aşağıda öz subyektiv qənaətlərimi təqdim edirəm. Şərhlərdə mənimlə mübahisə edə bilərsiniz, maraqlı olacaq.
Şəxsən mən bir neçə şeyə mərc edirəm:
- Bu sahədə inkişaf çox sürətlə gedir. Budur DevOps üçün sorğuların cədvəli.
Mövzu şırınga ola bilər, amma sferanın böyüməsi faktı bir qədər ümid verir.Əgər bir şey bu qədər sürətlə böyüyərsə, o zaman sizə nə edəcəyinizi və nə etməməyinizi söyləyəcək ağıllı insanlar mütləq peyda olacaqlar. Populyarlığın artması ona gətirib çıxarır ki, bəlkə də kiminsə vscode üçün jsonnet-ə nəhayət plagin əlavə etməyə vaxtı olacaq ki, bu da ctrl+shift+f vasitəsilə onu axtarmaq əvəzinə funksiyanı həyata keçirməyə keçməyə imkan verəcək. Şeylər inkişaf etdikcə daha çox material ortaya çıxır. Google-dan SRE haqqında kitabın nəşri bunun gözəl nümunəsidir.
- Adi inkişafda burada uğurla tətbiq edə biləcəyimiz işlənmiş texnika və təcrübələr var. Bəli, sınaq və heterojen bir mühit, qeyri-kafi alətlər ilə nüanslar var, lakin faydalı və faydalı ola biləcək çox sayda təcrübə toplanıb.
Önəmsiz bir nümunə: cüt proqramlaşdırma vasitəsilə əməkdaşlıq. Bunu anlamağa çox kömək edir. Yaxınlıqda nəyisə başa düşməyə çalışan qonşunuz varsa, birlikdə daha yaxşı başa düşəcəksiniz.
Refaktorinqin necə aparıldığını başa düşmək hətta belə bir vəziyyətdə belə onu həyata keçirməyə kömək edir. Yəni hər şeyi bir anda dəyişə bilməzsən, ancaq adını dəyişdir, sonra yerini dəyişdir, sonra bəzi hissəni vurğulaya bilərsən, oh, amma burada kifayət qədər şərh yoxdur.
Nəticə
Mülahizələrimin pessimist görünməsinə baxmayaraq, mən gələcəyə ümidlə baxıram və hər şeyin bizim (və sizin) xeyrinə olacağına ürəkdən ümid edirəm.
Növbəti məqalənin ikinci hissəsi hazırlanır. Burada mən öyrənmə prosesimizi təkmilləşdirmək və infrastrukturla işləmək üçün çevik inkişaf təcrübələrindən necə istifadə etməyə çalışdığımızdan danışacağam.
Mənbə: www.habr.com