Инфрақұрылым код ретінде: XP көмегімен проблемаларды қалай жеңуге болады

Сәлем, Хабр! Бұрын мен Инфрақұрылымдағы өмірге кодтық парадигма ретінде шағымдандым және ағымдағы жағдайды шешу үшін ештеңе ұсынбадым. Бүгін мен сізге үмітсіздік тұңғиығынан құтылуға және жағдайды дұрыс бағытта басқаруға қандай тәсілдер мен тәжірибелер көмектесетінін айту үшін қайтамын.

Алдыңғы мақалада «Инфрақұрылым код ретінде: алғашқы танысу» Мен осы саладан алған әсерлеріммен бөлістім, осы саладағы ағымдағы жағдайды ойлауға тырыстым, тіпті барлық әзірлеушілерге белгілі стандартты тәжірибелер көмектесе алатынын ұсындым. Өмірге қатысты шағымдар көп сияқты көрінуі мүмкін, бірақ қазіргі жағдайдан шығудың жолдары туралы ұсыныстар болмады.

Біз кімбіз, қайдамыз және қандай проблемаларымыз бар

Біз қазір алты бағдарламашы мен үш инфрақұрылым инженерінен тұратын Sre Onboarding Team құрамындамыз. Біз бәріміз Инфрақұрылымды код (IaC) ретінде жазуға тырысамыз. Біз мұны істейміз, өйткені біз негізінен кодты қалай жазу керектігін білеміз және «орташа деңгейден жоғары» әзірлеушілер болған тарихымыз бар.

• Бізде бірқатар артықшылықтар бар: белгілі бір фон, тәжірибелерді білу, код жазу мүмкіндігі, жаңа нәрселерді үйренуге деген ұмтылыс.
• Ал салбырап тұрған жері бар, бұл да минус: инфрақұрылымдық жабдық туралы білімнің болмауы.

IaC жүйесінде біз қолданатын технологиялық стек.

• Ресурстарды құруға арналған терраформа.
• Суреттерді жинауға арналған бума. Бұл Windows, CentOS 7 кескіндері.
• Jsonnet drone.io-да қуатты құрылымды жасауға, сонымен қатар json пакетін және терраформ модульдерімізді генерациялауға арналған.
• Azure.
• Кескіндерді дайындау кезінде жауап береді.
• Көмекші қызметтерге және сценарийлерді дайындауға арналған Python.
• Мұның бәрі VSCode-де топ мүшелері арасында ортақ плагиндері бар.

Менің пікірімнен қорытынды соңғы мақала былай болды: мен (ең алдымен өзіме) оптимизмді оятуға тырыстым, осы саладағы қиындықтар мен күрделіліктерді жеңу үшін бізге белгілі тәсілдер мен тәжірибелерді қолданып көретінімізді айтқым келді.

Қазіргі уақытта біз келесі IaC мәселелерімен күресіп жатырмыз:

• Кодты әзірлеуге арналған құралдар мен құралдардың жетілмегендігі.
• Баяу орналастыру. Инфрақұрылым нақты әлемнің бөлігі және ол баяу болуы мүмкін.
• Тәсілдер мен тәжірибелердің болмауы.
• Біз жаңамыз және көп нәрсені білмейміз.

Экстремалды бағдарламалау (XP) көмекке

Барлық әзірлеушілер Extreme Programming (XP) және оның артында тұрған тәжірибелерді жақсы біледі. Көпшілігіміз осы тәсілмен жұмыс істедік және ол сәтті болды. Олай болса, инфрақұрылымдық қиындықтарды жеңу үшін неге сол жерде айтылған қағидаттар мен тәжірибелерді қолданбасқа? Біз осы әдісті қолданып, не болатынын көруді шештік.

Сіздің салаңызға XP әдісінің қолданылуын тексеруМұнда XP қолайлы ортаның сипаттамасы және оның бізге қатысы бар:

1. Динамикалық өзгеретін бағдарламалық қамтамасыз ету талаптары. Түпкі мақсаттың не екені бізге түсінікті болды. Бірақ мәліметтер әртүрлі болуы мүмкін. Біз таксиге қайда бару керектігін өзіміз шешеміз, сондықтан талаптар мезгіл-мезгіл өзгереді (негізінен өзіміз). Егер автоматтандыруды өзі жасайтын және өзі талаптар мен жұмыс көлемін шектейтін SRE командасын алсақ, онда бұл нүкте жақсы сәйкес келеді.

2. Жаңа технологияны пайдаланатын белгіленген уақыт жобаларынан туындайтын тәуекелдер. Бізге белгісіз нәрселерді пайдаланған кезде қауіптерге тап болуымыз мүмкін. Бұл 100% біздің жағдайымыз. Біздің бүкіл жобамыз бізге толық таныс емес технологияларды пайдалану болды. Жалпы, бұл тұрақты мәселе, өйткені... Инфрақұрылымдық секторда үнемі пайда болатын көптеген жаңа технологиялар бар.

3,4. Шағын, бірге орналасқан кеңейтілген әзірлеу тобы. Сіз пайдаланып жатқан автоматтандырылған технология құрылғы мен функционалдық сынақтарды жүргізуге мүмкіндік береді. Бұл екі тармақ бізге мүлдем сәйкес келмейді. Біріншіден, біз үйлестірілген команда емеспіз, екіншіден, үлкен ұжым деп санауға болатын тоғыз адамбыз. Дегенмен, «үлкен» команданың кейбір анықтамаларына сәйкес, көп адам 14+ адам.

Кейбір XP тәжірибелерін және олардың кері байланыс жылдамдығы мен сапасына қалай әсер ететінін қарастырайық.

XP кері байланыс циклінің принципі

Менің түсінігімде кері байланыс – бұл мен дұрыс істеп жатырмын ба, біз сонда барамыз ба деген сұраққа жауап. XP-де бұл үшін құдай схемасы бар: уақыт бойынша кері байланыс циклі. Бір қызығы, біз неғұрлым төмен болсақ, соғұрлым біз қажетті сұрақтарға жауап беру үшін ОЖ-ны тезірек аламыз.

Бұл біздің IT-индустриямызда ОЖ-ны тез алуға болатыны туралы талқылау үшін өте қызықты тақырып. Алты ай бойы бір жобаны жасау қаншалықты азапты екенін елестетіп көріңізші, содан кейін ғана ең басында қате болғанын біліңіз. Бұл дизайнда және күрделі жүйелердің кез келген құрылысында болады.

Біздің IaC жағдайында кері байланыс бізге көмектеседі. Мен бірден жоғарыдағы диаграммаға шағын түзету енгіземін: шығару жоспарында айлық цикл жоқ, бірақ күніне бірнеше рет болады. Осы операциялық жүйе цикліне байланысты кейбір тәжірибелер бар, біз оларды толығырақ қарастырамыз.

Маңызды: кері байланыс жоғарыда көрсетілген барлық мәселелердің шешімі болуы мүмкін. XP тәжірибелерімен үйлескенде, ол сізді үмітсіздік тұңғиығынан шығара алады.

Өзіңізді үмітсіздік тұңғиығынан қалай шығаруға болады: үш тәжірибе

Тесттер

Тесттер XP кері байланыс циклінде екі рет айтылады. Бұл жай ғана олай емес. Олар бүкіл экстремалды бағдарламалау техникасы үшін өте маңызды.

Сізде бірлік және қабылдау сынақтары бар деп болжанады. Кейбіреулер сізге бірнеше минут ішінде кері байланыс береді, ал басқалары бірнеше күнде, сондықтан оларды жазу ұзаққа созылады және жиі қаралады.

Классикалық тестілеу пирамидасы бар, ол сынақтардың көбірек болуы керек екенін көрсетеді.

Бұл құрылым бізге IaC жобасында қалай қолданылады? Негізінде... мүлде емес.

• Бірлік сынақтары, олардың көп болуы керек екеніне қарамастан, тым көп болуы мүмкін емес. Немесе олар бір нәрсені жанама түрде сынап жатыр. Шындығында, біз оларды мүлдем жазбаймыз деп айта аламыз. Бірақ біз жасай алдық осындай сынақтарға арналған бірнеше қосымшалар:
  1. jsonnet кодын сынау. Бұл, мысалы, біздің дрондарды құрастыру құбыры, ол өте күрделі. Jsonnet коды сынақтармен жақсы қамтылған.
     Біз мұны қолданамыз Jsonnet үшін бірлік тестілеу жүйесі.
  2. Ресурс іске қосылғанда орындалатын сценарийлерге арналған сынақтар. Сценарийлер Python тілінде жазылған, сондықтан оларға тесттер жазуға болады.
• Конфигурацияны сынақтарда тексеруге болады, бірақ біз мұны жасамаймыз. Сондай-ақ, ресурс конфигурациясының ережелерін тексеру арқылы конфигурациялауға болады тфлинт. Дегенмен, ондағы тексерулер terraform үшін өте қарапайым, бірақ көптеген сынақ сценарийлері AWS үшін жазылған. Біз Azure қолданбасындамыз, сондықтан бұл қайтадан қолданылмайды.
• Құрамдас бөліктерді біріктіру сынақтары: бұл сіз оларды қалай жіктегеніңізге және қайда қойғаныңызға байланысты. Бірақ олар негізінен жұмыс істейді.

  Интеграциялық сынақтар осылай көрінеді.

  
  
  Бұл Drone CI жүйесінде кескіндерді құрудың мысалы. Оларға жету үшін Packer кескіні пайда болғанша 30 минут күту керек, содан кейін олардың өтуін тағы 15 минут күту керек. Бірақ олар бар!

  Суретті тексеру алгоритмі

  1. Пакер алдымен кескінді толығымен дайындауы керек.
  2. Сынақтың жанында жергілікті күйі бар терраформа бар, біз оны осы кескінді орналастыру үшін қолданамыз.
  3. Ашу кезінде суретпен жұмыс істеуді жеңілдету үшін жақын жерде орналасқан шағын модуль қолданылады.
  4. VM кескіннен қолданылғаннан кейін тексерулер басталуы мүмкін. Негізінен тексеру көлікпен жүргізіледі. Ол іске қосу кезінде сценарийлердің қалай жұмыс істегенін және демондардың қалай жұмыс істейтінін тексереді. Мұны істеу үшін ssh немесе winrm арқылы біз жаңадан орнатылған құрылғыға кіріп, конфигурация күйін немесе қызметтердің жұмыс істеп тұрғанын тексереміз.

• Жағдай terraform модульдеріндегі интеграциялық сынақтармен ұқсас. Міне, осындай сынақтардың ерекшеліктерін түсіндіретін қысқа кесте.

  
  
  Құбыр бойынша кері байланыс шамамен 40 минутты құрайды. Барлығы өте ұзақ уақыт бойы жүреді. Оны регрессия үшін қолдануға болады, бірақ жаңа даму үшін ол әдетте шындыққа жанаспайды. Егер сіз бұған өте дайын болсаңыз, іске қосылған сценарийлерді дайындаңыз, содан кейін оны 10 минутқа дейін қысқартуға болады. Бірақ бұл 5 секундта 100 бөлікті жасайтын бірлік сынақтары емес.

Кескіндерді немесе терраформалық модульдерді құрастыру кезінде бірлік сынақтарының болмауы жұмысты REST арқылы іске қосуға болатын бөлек қызметтерге немесе Python сценарийлеріне ауыстыруды ынталандырады.

Мысалы, виртуалды машина іске қосылғанда оның қызметте тіркелетініне көз жеткізуіміз керек еді ScaleFT, және виртуалды машина жойылғанда, ол өзін жойды.

Бізде ScaleFT қызметі болғандықтан, біз онымен API арқылы жұмыс істеуге мәжбүрміз. Онда сіз тартып алып: «Кіріңіз де, мынаны да, мынаны да жойыңыз» деп айтуға болатын қаптама жазылған. Ол барлық қажетті параметрлер мен рұқсаттарды сақтайды.

Біз бұл үшін қалыпты сынақтарды жаза аламыз, өйткені бұл қарапайым бағдарламалық жасақтамадан еш айырмашылығы жоқ: қандай да бір апиха мазақ етеді, сіз оны тартып аласыз және не болатынын көресіз.

Сынақтардың нәтижелері: ОЖ бір минутта беруі керек бірлік тестілеу оны бермейді. Ал пирамидадан жоғары тестілеу түрлері тиімді, бірақ мәселелердің бір бөлігін ғана қамтиды.

Жұптық бағдарламалау

Тесттер, әрине, жақсы. Сіз олардың көпшілігін жаза аласыз, олар әртүрлі болуы мүмкін. Олар өз деңгейінде жұмыс істеп, бізге кері байланыс береді. Бірақ ең жылдам операциялық жүйені беретін нашар Unit сынақтары проблемасы қалады. Сонымен қатар, мен әлі де оңай және жұмыс істеуге ыңғайлы жылдам ОЖ алғым келеді. Алынған шешімнің сапасы туралы айтпағанның өзінде. Бақытымызға орай, бірлік сынақтарына қарағанда тезірек кері байланысты қамтамасыз ететін әдістер бар. Бұл жұптық бағдарламалау.

Кодты жазу кезінде оның сапасы туралы мүмкіндігінше жылдам кері байланыс алғыңыз келеді. Иә, сіз барлығын функция тармағына жаза аласыз (ешкімге ештеңені бұзбау үшін), Github-та тарту сұрауын жасап, оны пікірі бар адамға тағайындап, жауапты күте аласыз.

Бірақ сіз ұзақ күте аласыз. Адамдардың бәрі бос емес, жауап бар болса да, жоғары сапалы болмауы мүмкін. Жауап бірден келді делік, рецензент барлық идеяны бірден түсінді, бірақ жауап әлі де кеш, фактіден кейін келеді. Мен ертерек болғанын қалаймын. Жұптық бағдарламалау дәл осы мақсатқа бағытталған - бірден, жазу кезінде.

Төменде жұптық бағдарламалау стильдері және олардың IaC жұмысында қолданылуы берілген:

1. Классикалық, Тәжірибелі+Тәжірибелі, таймер бойынша ауысым. Екі рөл – жүргізуші және навигатор. Екі адам. Олар бір кодта жұмыс істейді және белгілі бір алдын ала белгіленген уақыт кезеңінен кейін рөлдерді ауыстырады.

Мәселелеріміздің стильмен үйлесімділігін қарастырайық:

• Мәселе: кодты әзірлеуге арналған құралдар мен құралдардың жетілмегендігі.
  Теріс әсері: дамуға ұзағырақ уақыт қажет, біз баяулаймыз, жұмыс қарқыны/ритмі жоғалады.
  Біз қалай күресеміз: біз басқа құралдарды, жалпы IDE пайдаланамыз, сонымен қатар төте жолдарды үйренеміз.
• Мәселе: баяу орналастыру.
  Теріс әсер: кодтың жұмыс бөлігін жасауға кететін уақытты арттырады. Күтіп отырып жалығып кетеміз, күткенше қолымыз басқа нәрсеге созылады.
  Біз қалай күресеміз: біз оны жеңе алмадық.
• Мәселе: тәсілдер мен тәжірибелердің жетіспеушілігі.
  Теріс әсері: оны қалай жақсы және қалай нашар орындау керектігі туралы білім жоқ. Кері байланыс алуды ұзартады.
  Біз қалай күресеміз: жұптық жұмыста өзара пікір алмасу және тәжірибе дерлік мәселені шешеді.

IaC-де бұл стильді қолданудың негізгі мәселесі - жұмыстың біркелкі емес қарқыны. Дәстүрлі бағдарламалық жасақтама әзірлеуде сізде өте біркелкі қозғалыс бар. Бес минут жұмсап, N жазуға болады. 10 минут жұмсап, 2N, 15 минут - 3N жазуға болады. Мұнда сіз бес минут жұмсап, N деп жаза аласыз, содан кейін тағы 30 минут жұмсап, N-нің оннан бір бөлігін жаза аласыз. Мұнда сіз ештеңе білмейсіз, сіз кептеліп қалдыңыз, ақымақ. Тергеу уақытты алады және өзін бағдарламалаудан алшақтатады.

Қорытынды: оның таза түрінде ол бізге жарамайды.

2. Пинг-понг. Бұл тәсіл бір адамның сынақты жазуын, ал екіншісі оны жүзеге асыруды қамтиды. Unit сынақтарымен бәрі күрделі екенін және бағдарламалауға көп уақыт алатын интеграциялық сынақты жазу керек екенін ескере отырып, пинг-понгтың барлық жеңілдігі жоғалады.

Сынақ сценарийін құрастыру және оның кодын енгізу үшін жауапкершілікті бөлуге тырыстық деп айта аламын. Бір қатысушы сценариймен келді, жұмыстың бұл бөлігінде ол жауапты болды, ол соңғы сөзді айтты. Ал екіншісі орындауға жауапты болды. Бұл жақсы нәтиже берді. Бұл тәсілмен сценарийдің сапасы артады.

Қорытынды: өкінішке орай, жұмыс қарқыны IaC-де жұптық бағдарламалау тәжірибесі ретінде пинг-понгты пайдалануға мүмкіндік бермейді.

3. Күшті стиль. Күрделі жаттығу. Идея мынада: бір қатысушы директивалық навигатор болады, ал екіншісі орындау драйвері рөлін алады. Бұл жағдайда шешім қабылдау құқығы тек навигаторға жүктеледі. Драйвер тек басып шығарады және не болып жатқанына сөзбен әсер ете алады. Рөлдер ұзақ уақыт бойы өзгермейді.

Оқу үшін жақсы, бірақ күшті жұмсақ дағдыларды қажет етеді. Міне, біз іркіліп қалдық. Техника қиын болды. Бұл тіпті инфрақұрылым туралы да емес.

Қорытынды: оны әлеуетті түрде пайдалануға болады, біз тырысудан бас тартпаймыз.

4. Моббинг, сварминг және барлық белгілі, бірақ тізімде жоқ стильдер Біз оны қарастырмаймыз, өйткені Біз оны сынап көрмедік және бұл туралы біздің жұмысымыздың контекстінде айту мүмкін емес.

Жұптық бағдарламалауды қолдану бойынша жалпы нәтижелер:

• Бізде жұмыс қарқыны біркелкі емес, бұл түсініксіз.
• Біз жеткіліксіз жұмсақ дағдыларға тап болдық. Ал пәндік сала біздегі бұл кемшіліктерді жоюға көмектеспейді.
• Ұзақ сынақтар мен құралдарға қатысты мәселелер жұптық дамуды қиындатады.

5. Осыған қарамастан, табыстар болды. Біз өзіміздің «Конвергенция – Дивергенция» әдісін ойлап таптық. Мен оның қалай жұмыс істейтінін қысқаша сипаттаймын.

Бізде бірнеше күн (бір аптадан аз) тұрақты серіктестер бар. Бір тапсырманы бірге орындаймыз. Бірге отырамыз: бірі жазады, екіншісі отырады, қолдау тобын бақылайды. Содан кейін біз біраз уақытқа тараймыз, әрқайсысы бір-бірінен тәуелсіз нәрселерді жасайды, содан кейін біз қайтадан жиналамыз, өте жылдам синхрондаймыз, бірге бірдеңе жасаймыз, содан кейін қайтадан тараймыз.

Жоспарлау және коммуникация

ОЖ мәселелері шешілетін тәжірибелердің соңғы блогы тапсырмалардың өздерімен жұмысты ұйымдастыру болып табылады. Бұған жұптық жұмыстан тыс тәжірибе алмасу да кіреді. Үш тәжірибені қарастырайық:

1. Мақсат ағашы арқылы мақсаттар. Біз жобаны жалпы басқаруды болашаққа шексіз кететін ағаш арқылы ұйымдастырдық. Техникалық тұрғыдан қадағалау Мирода жүзеге асырылады. Бір міндет бар – ол аралық мақсат. Одан кішігірім мақсаттар немесе тапсырмалар топтары шығады. Тапсырмалардың өзі солардан шығады. Барлық тапсырмалар осы тақтада жасалады және сақталады.

Бұл схема сонымен қатар митингтерде синхрондау кезінде күніне бір рет болатын кері байланысты қамтамасыз етеді. Барлығының алдында ортақ жоспардың болуы, бірақ құрылымды және толығымен ашық болу, барлығына не болып жатқанын және біздің қаншалықты алға жылжығанымызды білуге ​​мүмкіндік береді.

Тапсырмаларды визуалды көрудің артықшылықтары:

• Себептілік. Әрбір тапсырма қандай да бір жаһандық мақсатқа әкеледі. Тапсырмалар кішірек мақсаттарға топтастырылған. Инфрақұрылымдық доменнің өзі өте техникалық. Мысалы, басқа nginx-ке көшу туралы runbook жазу бизнеске қандай нақты әсер ететіні әрқашан бірден анық бола бермейді. Мақсатты картаның жанында болуы оны анық етеді.
  
  Себептілік - мәселелердің маңызды қасиеті. Ол: «Мен дұрыс істеп жатырмын ба?» деген сұраққа тікелей жауап береді.
• Параллелизм. Біз тоғызбыз және барлығын бір тапсырмаға тастау физикалық тұрғыдан мүмкін емес. Бір саланың тапсырмалары әрқашан жеткіліксіз болуы мүмкін. Біз шағын жұмыс топтары арасындағы жұмысты параллельдеуге мәжбүрміз. Бұл кезде топтар өз тапсырмалары бойынша біраз уақыт отырады, оларды басқа біреу күшейте алады. Кейде адамдар бұл жұмыс тобынан кетіп қалады. Біреу демалысқа барады, біреу DevOps conf үшін есеп жасайды, біреу Habr туралы мақала жазады. Қандай мақсаттар мен міндеттерді қатар орындауға болатынын білу өте маңызды болады.

2. Таңертеңгілік жиналыстарды алмастырушы баяндамашылар. Стенд-аптарда бізде бұл мәселе бар - адамдар көптеген тапсырмаларды қатар орындайды. Кейде тапсырмалар бір-бірімен байланыссыз және кім не істеп жатқанын түсінбейді. Ал басқа топ мүшесінің пікірі өте маңызды. Бұл мәселені шешу барысын өзгерте алатын қосымша ақпарат. Әрине, әдетте сізбен бірге біреу бар, бірақ кеңестер мен кеңестер әрқашан пайдалы.

Бұл жағдайды жақсарту үшін біз «Жетекші стенд-апты өзгерту» әдісін қолдандық. Енді олар белгілі бір тізім бойынша айналдырылады және бұл өз әсерін тигізеді. Сіздің кезегіңіз келгенде, сіз жақсы Scrum кездесуін өткізу үшін сүңгуге және не болып жатқанын түсінуге мәжбүрсіз.

3. Ішкі демонстрация. Жұптық бағдарламалаудан мәселені шешуге көмектесу, мәселе ағашындағы визуализация және таңертеңгі скрам жиналыстарында көмек жақсы, бірақ тамаша емес. Ерлі-зайыптылар ретінде сіз тек біліміңізбен шектелесіз. Тапсырмалар ағашы кімнің не істеп жатқанын жаһандық деңгейде түсінуге көмектеседі. Таңертеңгілік жиналыста жүргізуші мен әріптестер сіздің проблемаларыңызға терең бойламайды. Олар, әрине, бірдеңені жіберіп алуы мүмкін.

Атқарылған жұмыстарды бір-біріне көрсетіп, кейін оны талқылаудан шешім табылды. Біз аптасына бір рет бір сағат бойы кездесіп, өткен аптада орындаған тапсырмалардың шешімдерін көрсетеміз.

Демонстрация кезінде тапсырманың егжей-тегжейлерін ашып, оның жұмысын міндетті түрде көрсету керек.

Есепті бақылау тізімі арқылы жүргізуге болады.1. Мәтінмәнге кіріңіз. Тапсырма қайдан келді, ол не үшін қажет болды?

2. Бұрынғы мәселе қалай шешілді? Мысалы, тінтуірді жаппай басу қажет болды немесе ештеңе істеу мүмкін болмады.

3. Біз оны қалай жетілдіреміз. Мысалы: «Міне, қазір scriptosik бар, міне, Readme».

4. Оның қалай жұмыс істейтінін көрсетіңіз. Кейбір пайдаланушы сценарийін тікелей жүзеге асырған жөн. Мен X қалаймын, мен У жасаймын, Y (немесе Z) көремін. Мысалы, мен NGINX қолданамын, url-ді түтіндеймін және 200 OK аламын. Әрекет ұзақ болса, оны кейінірек көрсету үшін алдын ала дайындаңыз. Демонстрациядан бір сағат бұрын, егер ол нәзік болса, оны көп бұзбаған жөн.

5. Мәселенің қаншалықты сәтті шешілгенін, қандай қиыншылықтар қалғанын, ненің аяқталмағанын, болашақта қандай жақсартулар мүмкін екенін түсіндіріңіз. Мысалы, қазір CLI, содан кейін CI-де толық автоматтандыру болады.

Әрбір спикерге оны 5-10 минутқа дейін ұстаған жөн. Егер сіздің сөзіңіз маңызды болса және ұзағырақ болса, мұны алдын ала sre-takeover арнасында үйлестіріңіз.

Бетпе-бет бөлімнен кейін әрқашан жіпте талқылау болады. Бұл жерде біздің тапсырмаларымыз бойынша қажетті кері байланыс пайда болады.

Нәтижесінде болып жатқан нәрсенің пайдалылығын анықтау үшін сауалнама жүргізіледі. Бұл сөздің мәні мен тапсырманың маңыздылығы туралы кері байланыс.

Ұзақ қорытындылар және әрі қарай не болады

Мақаланың реңі біршама пессимистік болып көрінуі мүмкін. Бұл олай емес. Кері байланыстың екі төменгі деңгейі, атап айтқанда тесттер және жұптық бағдарламалау жұмыс істейді. Дәстүрлі дамудағыдай мінсіз емес, бірақ оның оң әсері бар.

Тесттер, олардың ағымдағы түрінде, тек ішінара кодты қамтуды қамтамасыз етеді. Көптеген конфигурация функциялары тексерілмейді. Кодты жазу кезінде олардың нақты жұмысқа әсері төмен. Дегенмен, интеграциялық сынақтардың әсері бар және олар рефакторингтерді қорықпай жүзеге асыруға мүмкіндік береді. Бұл үлкен жетістік. Сондай-ақ, фокустың жоғары деңгейлі тілдерді дамытуға ауысуымен (бізде питон бар, барыңыз), мәселе жойылады. Және «желімге» көп тексерулер қажет емес, жалпы интеграцияны тексеру жеткілікті.

Жұптық жұмыс нақты адамдарға көбірек байланысты. Тапсырма факторы және біздің жұмсақ дағдыларымыз бар. Кейбір адамдарда бұл өте жақсы жұмыс істейді, басқаларында ол нашар. Мұның пайдасы сөзсіз. Жұптық жұмыс ережелері жеткілікті сақталмаса да, тапсырмаларды бірлесіп орындау фактісінің өзі нәтиженің сапасына оң әсер ететіні анық. Жеке өзім жұппен жұмыс істеу оңайырақ әрі қызықтырақ деп ойлаймын.

ОЖ-ға әсер етудің жоғары деңгейлі тәсілдері – тапсырмаларды жоспарлау және жұмыс істеу дәл нәтиже береді: жоғары сапалы білім алмасу және даму сапасын жақсарту.

Бір қатардағы қысқаша қорытындылар

• HR мамандары IaC жүйесінде жұмыс істейді, бірақ тиімділігі төмен.
• Жұмыс істейтін нәрсені күшейтіңіз.
• Өзіңіздің компенсаторлық механизмдеріңіз бен тәжірибелеріңізді ойлап табыңыз.

Ақпарат көзі: www.habr.com