Біздің компания SRE командасын жұмысқа қабылдау процесінде. Мен бұл оқиғаға даму жағынан келдім. Осы процесте мен басқа әзірлеушілермен бөліскім келетін ойлар мен түсініктерді таптым. Бұл рефлексия мақаласында мен не болып жатқаны, оның қалай болып жатқаны және әркім онымен қалай өмір сүре алатыны туралы сөйлесемін.
Ішкі шарамызда сөйлеген сөздер негізінде жазылған мақалалар топтамасының жалғасы :
2. Инфрақұрылым код ретінде. (Сен мындасың)
3. C# үлгілерін пайдаланып Typescript келісім-шарттарын жасау. (Орындалуда...)
4. Raft консенсус алгоритміне кіріспе. (Орындалуда...)
...
Біз идеяларды жүзеге асыра отырып, SRE командасын құруды шештік . Олар өздерінің әзірлеушілерінен бағдарламашыларды жинап, бірнеше айға оқытуға жіберді.
Командада келесі оқу міндеттері болды:
- Көбінесе Microsoft Azure жүйесінде код түрінде (Terraform және айналасындағылардың барлығы) біздің инфрақұрылымымызды сипаттаңыз.
- Әзірлеушілерге инфрақұрылыммен жұмыс істеуді үйретіңіз.
- Әзірлеушілерді жұмысқа дайындаңыз.
Біз Инфрақұрылым түсінігін код ретінде енгіземіз
Әлемнің әдеттегі үлгісінде (классикалық әкімшілік) инфрақұрылым туралы білім екі жерде орналасқан:
- Немесе сарапшылардың басындағы білім түрінде.
- Немесе бұл ақпарат кейбір жазу машинкаларында бар, олардың кейбіреулері мамандарға белгілі. Бірақ бөгде адам (біздің бүкіл команда кенеттен қайтыс болған жағдайда) не жұмыс істейтінін және қалай жұмыс істейтінін анықтай алатыны шындық емес. Машинада көптеген ақпарат болуы мүмкін: аксессуарлар, кронжобтар, қорқытылған (қараңыз. ) дискі және не болуы мүмкін екендігінің шексіз тізімі. Шын мәнінде не болып жатқанын түсіну қиын.
Екі жағдайда да біз тәуелді боламыз:
- немесе өлімге ұшыраған, ауруға шалдыққан, ғашық болған, көңіл-күйдің өзгеруі және қарапайым жұмыстан босатылған адамнан;
- немесе физикалық жұмыс істейтін машинадан, ол да құлап, ұрланады және тосын сыйлар мен қолайсыздықтар тудырады.
Ең дұрысы, барлығын адам оқи алатын, қолдау көрсететін, жақсы жазылған кодқа аудару керек екені айтпаса да түсінікті.
Осылайша, инфрақұрылым код ретінде (Incfastructure as Code - IaC) код түріндегі барлық қолданыстағы инфрақұрылымның, сондай-ақ онымен жұмыс істеуге және одан нақты инфрақұрылымды жүзеге асыруға арналған байланысты құралдардың сипаттамасы болып табылады.
Неліктен бәрін кодқа аудару керек?Адамдар машина емес. Олар бәрін есіне түсіре алмайды. Адам мен машинаның реакциясы әртүрлі. Кез келген автоматтандырылған нәрсе адам жасаған кез келген нәрседен жылдамырақ. Ең бастысы – ақиқаттың жалғыз көзі.
Жаңа SRE инженерлері қайдан келеді?Сонымен, біз жаңа SRE инженерлерін жалдауды шештік, бірақ оларды қайдан алуға болады? Дұрыс жауаптары бар кітап () бізге былай дейді: әзірлеушілерден. Өйткені, олар кодпен жұмыс істейді, және сіз идеалды күйге жетесіз.
Біз оларды компаниямыздан тыс кадр нарығында ұзақ уақыт іздедік. Бірақ біз сұрауларымызға сәйкес келетін ешкімді таппағанымызды мойындауымыз керек. Мен өз адамдарымның арасынан іздеуге тура келді.
Мәселелер Инфрақұрылым код ретінде
Енді инфрақұрылымды кодқа қатты кодтауға болатын мысалдарды қарастырайық. Код жақсы жазылған, жоғары сапалы, түсініктемелер мен шегіністермен.
Terraforma кодының мысалы.
Ansible кодының мысалы.
Мырзалар, бәрі қарапайым болса болды! Біз шынайы әлемдеміз және ол сізді таң қалдыруға, тосын сыйлар мен проблемаларды ұсынуға әрқашан дайын. Оларсыз мұнда да болмайды.
1. Бірінші мәселе, көп жағдайда IaC қандай да бір dsl түрі болып табылады.
Ал DSL өз кезегінде құрылымның сипаттамасы болып табылады. Дәлірек айтқанда, сізде не болуы керек: Json, Yaml, кейбір ірі компаниялардың модификациялары, олар өздерінің dsl (HCL терраформда қолданылады).
Мәселе мынада, оның құрамында мұндай таныс нәрселер оңай болмауы мүмкін:
- айнымалылар;
- шарттар;
- бір жерде түсініктемелер жоқ, мысалы, Джсонда, олар әдепкі бойынша берілмейді;
- функциялар;
- мен тіпті сыныптар, мұрагерлік және басқалары сияқты жоғары деңгейдегі нәрселер туралы айтпаймын.
2. Мұндай кодтың екінші мәселесі - бұл көбінесе гетерогенді орта. Әдетте сіз C# тілінде отырып жұмыс істейсіз, яғни. бір тілмен, бір стекпен, бір экожүйемен. Ал мұнда сізде көптеген технологиялар бар.
Python көмегімен bash Json енгізілген кейбір процесті іске қосқанда бұл өте нақты жағдай. Сіз оны талдайсыз, содан кейін басқа генератор тағы 30 файлды шығарады. Осының барлығы үшін енгізу айнымалылары Go бағдарламасында жазылған drone.io плагинімен біріктірілген Azure Key Vault ішінен алынады және бұл айнымалылар jsonnet үлгі қозғалтқышынан генерациялау нәтижесінде жасалған yaml арқылы өтеді. Сізде әртүрлі орта болған кезде қатаң сипатталған кодқа ие болу өте қиын.
Бір тапсырма аясындағы дәстүрлі даму бір тілмен келеді. Мұнда біз көптеген тілдермен жұмыс істейміз.
3. Үшінші мәселе – баптау. Біз үшін барлығын жасайтын редакторларды (Ms Visual Studio, Jetbrains Rider) салқындату үшін үйрендік. Ал біз ақымақ болсақ та қателесіп жатырмыз дейді. Бұл қалыпты және табиғи болып көрінеді.
Бірақ жақын жерде VSCode бар, онда қандай да бір түрде орнатылған, қолдау көрсетілетін немесе қолдау көрсетілмейтін кейбір плагиндер бар. Жаңа нұсқалар шықты және оларға қолдау көрсетілмеді. Функцияны жүзеге асыруға банальды көшу (тіпті ол бар болса да) күрделі және тривиальды емес мәселеге айналады. Айнымалының қарапайым атауын өзгерту - ондаған файлдың жобасындағы қайталау. Егер ол сізге қажет нәрсені орналастырса, сіз бақытты боласыз. Әрине, мұнда және мұнда артқы жарықтандыру бар, автоматты аяқтау бар, бір жерде пішімдеу бар (бірақ бұл мен үшін Windows жүйесінде терраформда жұмыс істемеді).
Осы жазу кезінде 0.12 нұсқасын қолдау үшін әлі шығарылған жоқ, бірақ ол 3 ай бойы шығарылды.
Ұмытатын кез келді...
- Жөндеу.
- Рефакторинг құралы.
- Автоматты аяқтау.
- Компиляция кезінде қателерді анықтау.
Бұл күлкілі, бірақ бұл даму уақытын арттырады және сөзсіз орын алатын қателер санын арттырады.
Ең сорақысы, біз қалай құрастыру, файлдарды қалталарға бөлу, ыдырату, кодты сақтау, оқуға ыңғайлы ету және т.б. туралы емес, бұл пәрменді қалай дұрыс жазуға болатыны туралы ойлауға мәжбүрміз, өйткені мен оны әйтеуір қате жаздым. .
Жаңадан бастаушы ретінде сіз терраформаларды үйренуге тырысасыз, ал IDE сізге мүлде көмектеспейді. Құжаттар бар кезде, кіріп қараңыз. Бірақ егер сіз жаңа бағдарламалау тілін енгізсеңіз, IDE сізге мұндай түрі бар екенін айтады, бірақ ондай нәрсе жоқ. Кем дегенде int немесе жол деңгейінде. Бұл жиі пайдалы.
Тесттер ше?
Сіз: «Тесттер туралы не айтасыз, мырзалар, бағдарламашылар?» Байыпты жігіттер барлығын өндірісте сынап көреді және бұл қиын. Мұнда веб-сайттағы терраформ модуліне арналған бірлік сынағының мысалы берілген .
Олардың жақсы құжаттары бар. Маған Microsoft корпорациясының құжаттамаға және оқытуға деген көзқарасы әрқашан ұнады. Бірақ бұл тамаша код емес екенін түсіну үшін сізге Боб ағай болудың қажеті жоқ. Оң жақтағы тексеруге назар аударыңыз.
Бірлік сынағы мәселесі мынада: сіз және мен Json шығысының дұрыстығын тексере аламыз. Мен 5 параметрді енгіздім және 2000 жолдан тұратын Json аяқ киімін бердім. Мен мұнда не болып жатқанын талдай аламын, сынақ нәтижесін растай аламын ...
Go бағдарламасында Джсонды талдау қиын. Go бағдарламасында жазу керек, өйткені Go бағдарламасындағы terraform - сіз жазған тілде тестілеуге арналған жақсы тәжірибе. Кодекстің өзін ұйымдастыру өте әлсіз. Сонымен қатар, бұл тестілеуге арналған ең жақсы кітапхана.
Майкрософттың өзі модульдерін жазады, оларды осылай сынап көреді. Әрине, бұл Open Source. Мен айтып отырғанның бәрі келіп, түзете аласыз. Мен отыра аламын және бір апта ішінде бәрін түзете аламын, ашық бастапқы кодты VS кодының плагиндері, терраформдар, шабандозға плагин жасай аламын. Мүмкін, бірнеше анализатор жазыңыз, линтер қосыңыз, тестілеу үшін кітапханаға үлес қосыңыз. Мен бәрін істей аламын. Бірақ бұл менің істеуім керек емес.
Үздік тәжірибелер Инфрақұрылым код ретінде
Әрі қарай жүрейік. Егер IaC-де сынақтар болмаса, IDE және баптау нашар болса, кем дегенде ең жақсы тәжірибе болуы керек. Мен жаңа ғана Google Analytics қызметіне кіріп, екі іздеу сұрауын салыстырдым: Terraform үздік тәжірибелері және C# үздік тәжірибелері.
Біз не көріп тұрмыз? Аяусыз статистика біздің пайдамызға емес. Материалдың мөлшері бірдей. C# әзірлеуде біз жай ғана материалдарға қанықпыз, бізде ең жақсы тәжірибелер бар, сарапшылар жазған кітаптар, сонымен қатар сол кітаптарды сынайтын басқа сарапшылардың кітаптары бойынша жазылған кітаптар бар. Ресми құжаттардың, мақалалардың, оқу курстарының теңізі, сонымен қатар ашық бастапқы кодты әзірлеу.
IaC сұрауына келетін болсақ: мұнда сіз жоғары жүктеуден немесе HashiConf есептерінен, ресми құжаттамадан және Github-тағы көптеген мәселелерден ақпаратты біртіндеп жинауға тырысасыз. Жалпы бұл модульдерді қалай таратуға болады, олармен не істеу керек? Бұл нағыз проблема сияқты... Қоғамдастық бар, мырзалар, онда кез келген сұраққа Github-та 10 пікір беріледі. Бірақ дәл емес.
Өкінішке орай, қазіргі уақытта мамандар енді ғана пайда бола бастады. Әзірге олардың саны тым аз. Ал қауымның өзі қарапайым деңгейде ілулі тұр.
Мұның бәрі қайда барады және не істеу керек
Сіз бәрін тастап, C# тіліне, шабандоз әлеміне қайта аласыз. Бірақ жоқ. Шешім таба алмасаңыз, мұны неге әуре боласыз? Төменде мен өзімнің субъективті қорытындыларымды ұсынамын. Түсініктемелерде менімен дауласа аласыз, бұл қызықты болады.
Жеке өзім бірнеше нәрсеге бәс тігемін:
- Бұл салада даму өте жылдам жүріп жатыр. Мұнда DevOps үшін сұраулар кестесі берілген.
Тақырып дүрбелең болуы мүмкін, бірақ саланың өсіп келе жатқанының өзі біраз үміт береді.Егер бірдеңе соншалықты тез өсетін болса, онда сізге не істеу керектігін және не істеуге болмайтынын айтатын ақылды адамдар пайда болады. Танымалдықтың артуы, мүмкін біреудің vscode үшін jsonnet плагинін қосуға уақыты болуы мүмкін, бұл сізге ctrl+shift+f арқылы іздеудің орнына функцияны іске асыруға көшуге мүмкіндік береді. Заттар дамыған сайын көбірек материалдар пайда болады. Google-дан SRE туралы кітаптың шығуы - бұл тамаша мысал.
- Дәстүрлі дамуда біз осында сәтті қолдана алатын дамыған әдістер мен тәжірибелер бар. Иә, тестілеудің және гетерогенді ортаның, құралдардың жеткіліксіздігінің нюанстары бар, бірақ пайдалы және пайдалы болуы мүмкін көптеген тәжірибелер жинақталған.
Тривиальды мысал: жұптық бағдарламалау арқылы ынтымақтастық. Оны анықтауға көп көмектеседі. Жақын жерде бір нәрсені түсінуге тырысатын көршіңіз болса, сіз бірге жақсы түсінесіз.
Рефакторингтің қалай орындалатынын түсіну оны осындай жағдайда да жүзеге асыруға көмектеседі. Яғни, сіз бәрін бірден өзгерте алмайсыз, бірақ атауды өзгертіңіз, содан кейін орынды өзгертіңіз, содан кейін кейбір бөліктерді бөлектеуге болады, о, бірақ мұнда түсініктемелер жеткіліксіз.
қорытынды
Менің пікірім пессимистік болып көрінгенімен, мен болашаққа үмітпен қараймын және бәрі біз үшін (және сіз) үшін жақсы болады деп шын жүректен үміттенемін.
Келесі мақаланың екінші бөлімі дайындалуда. Онда мен оқу үдерісін жақсарту және инфрақұрылыммен жұмыс істеу үшін икемді даму тәжірибесін қалай қолдануға тырысқанымыз туралы айтатын боламын.
Ақпарат көзі: www.habr.com