Infratuzilma kod sifatida: XP yordamida muammolarni qanday engish mumkin

Salom, Xabr! Ilgari men infratuzilmadagi hayotdan kod paradigmasi sifatida shikoyat qildim va mavjud vaziyatni hal qilish uchun hech narsa taklif qilmadim. Bugun men sizga qanday yondashuvlar va amaliyotlar umidsizlik tubidan qochishga va vaziyatni to'g'ri yo'nalishga yo'naltirishga yordam berishini aytib berish uchun qaytib keldim.

Oldingi maqolada "Infratuzilma kod sifatida: birinchi tanishish" Men ushbu sohadagi taassurotlarimni o'rtoqlashdim, ushbu sohadagi mavjud vaziyatni aks ettirishga harakat qildim va hatto barcha ishlab chiquvchilarga ma'lum bo'lgan standart amaliyotlar yordam berishi mumkinligini taklif qildim. Hayotdan shikoyatlar ko'p bo'lib tuyulishi mumkin, ammo hozirgi vaziyatdan chiqish yo'li bo'yicha takliflar yo'q edi.

Biz kimmiz, qayerdamiz va qanday muammolarimiz bor

Biz hozirda oltita dasturchi va uchta infratuzilma muhandisidan iborat Sre Onboarding Team tarkibidamiz. Biz hammamiz Infratuzilmani kod (IaC) sifatida yozishga harakat qilamiz. Biz buni qilamiz, chunki biz asosan kod yozishni bilamiz va "o'rtachadan yuqori" ishlab chiquvchilar bo'lish tariximiz bor.

• Bizda bir qator afzalliklar mavjud: ma'lum bir ma'lumot, amaliyotlarni bilish, kod yozish qobiliyati, yangi narsalarni o'rganish istagi.
• Va sarkma qismi bor, bu ham minus: infratuzilma apparati haqida ma'lumot etishmasligi.

IaC-da biz foydalanadigan texnologiya to'plami.

• Resurslarni yaratish uchun terraform.
• Tasvirlarni yig'ish uchun paket. Bular Windows, CentOS 7 tasvirlari.
• Jsonnet drone.io-da kuchli tuzilma yaratish, shuningdek, json packer va bizning terraform modullarimizni yaratish uchun.
• Azure.
• Tasvirlarni tayyorlashda ishonchli.
• Yordamchi xizmatlar va skriptlarni tayyorlash uchun Python.
• Va bularning barchasi VSCode-da guruh a'zolari o'rtasida bo'lingan plaginlar bilan.

Mendan xulosa oxirgi maqola shunday edi: Men (birinchi navbatda o'zimda) nekbinlikni singdirishga harakat qildim, aytmoqchi edimki, biz bu sohada mavjud qiyinchilik va murakkabliklarni bartaraf etish uchun bizga ma'lum bo'lgan yondashuv va amaliyotlarni sinab ko'ramiz.

Biz hozirda quyidagi IaC muammolari bilan kurashmoqdamiz:

• Kodni ishlab chiqish uchun vositalar va vositalarning nomukammalligi.
• Sekin joylashtirish. Infratuzilma haqiqiy dunyoning bir qismidir va u sekin bo'lishi mumkin.
• Yondashuvlar va amaliyotlarning etishmasligi.
• Biz yangimiz va ko'p narsani bilmaymiz.

Ekstremal dasturlash (XP) yordamga

Barcha ishlab chiquvchilar Extreme Programming (XP) va uning ortida turgan amaliyotlar bilan tanish. Ko'pchiligimiz bu yondashuv bilan ishladik va u muvaffaqiyatli bo'ldi. Xo'sh, nega infratuzilma muammolarini yengish uchun u erda belgilangan tamoyillar va amaliyotlardan foydalanmaslik kerak? Biz ushbu yondashuvni qo'llashga va nima bo'lishini ko'rishga qaror qildik.

XP yondashuvining sanoatingizda qo'llanilishini tekshirishQuyida XP mos keladigan muhit va uning bizga qanday aloqasi borligi tasvirlangan:

1. Dinamik ravishda o'zgaruvchan dasturiy ta'minot talablari. Yakuniy maqsad nima ekanligi bizga ayon bo'ldi. Ammo tafsilotlar boshqacha bo'lishi mumkin. Qaerda taksi qilish kerakligini o'zimiz hal qilamiz, shuning uchun talablar vaqti-vaqti bilan o'zgarib turadi (asosan o'zimiz). Agar biz avtomatlashtirishni o'zi bajaradigan va o'zi talablar va ish hajmini cheklaydigan SRE jamoasini oladigan bo'lsak, unda bu nuqta juda mos keladi.

2. Yangi texnologiyadan foydalangan holda belgilangan vaqtli loyihalar tufayli yuzaga keladigan xavflar. Bizga noma'lum narsalardan foydalanishda xavf-xatarlarga duch kelishimiz mumkin. Va bu 100% bizning holatimizda. Bizning butun loyihamiz biz to'liq tanish bo'lmagan texnologiyalardan foydalanish edi. Umuman olganda, bu doimiy muammo, chunki... Infratuzilma sohasida doimo paydo bo'ladigan ko'plab yangi texnologiyalar mavjud.

3,4. Kichik, birgalikda joylashgan kengaytirilgan ishlab chiqish jamoasi. Siz foydalanayotgan avtomatlashtirilgan texnologiya birlik va funktsional testlarni o'tkazish imkonini beradi. Bu ikki nuqta bizga unchalik mos kelmaydi. Birinchidan, biz muvofiqlashtirilgan jamoa emasmiz, ikkinchidan, biz to'qqiztamiz, uni katta jamoa deb hisoblash mumkin. Garchi, "katta" jamoaning ba'zi ta'riflariga ko'ra, juda ko'p 14+ kishi.

Keling, ba'zi XP amaliyotlarini ko'rib chiqaylik va ular fikr-mulohazalarning tezligi va sifatiga qanday ta'sir qiladi.

XP Teskari aloqa davri printsipi

Mening tushunishimga ko'ra, fikr-mulohaza - bu savolga javob, men to'g'ri ish qilyapmanmi, biz u erga boramizmi? XP-da buning uchun ilohiy sxema mavjud: vaqt bilan bog'lanish davri. Qizig'i shundaki, biz qanchalik past bo'lsak, kerakli savollarga javob berish uchun operatsion tizimni tezroq olishimiz mumkin.

Bu muhokama qilish uchun juda qiziq mavzu, bizning IT-sanoatimizda OSni tezda olish mumkin. Olti oy davomida loyihani amalga oshirish qanchalik og'riqli ekanligini tasavvur qiling va shundan keyingina boshida xatolik borligini bilib oling. Bu dizaynda va murakkab tizimlarning har qanday qurilishida sodir bo'ladi.

IaC holatida fikr-mulohaza bizga yordam beradi. Men zudlik bilan yuqoridagi diagrammaga kichik tuzatish kiritaman: chiqarish rejasi oylik tsiklga ega emas, lekin kuniga bir necha marta sodir bo'ladi. Ushbu operatsion tizim tsikliga bog'liq bo'lgan ba'zi amaliyotlar mavjud, biz ularni batafsilroq ko'rib chiqamiz.

Muhim: fikr-mulohaza yuqorida qayd etilgan barcha muammolarni hal qilishi mumkin. XP amaliyotlari bilan birgalikda u sizni umidsizlik tubidan olib chiqishi mumkin.

O'zingizni tushkunlik tubidan qanday chiqarish mumkin: uchta amaliyot

Sinovlar

Testlar XP geribildirim tizimida ikki marta eslatib o'tiladi. Bu shunchaki shunday emas. Ular butun Ekstremal dasturlash texnikasi uchun juda muhimdir.

Sizda birlik va qabul qilish testlari bor deb taxmin qilinadi. Ba'zilar sizga bir necha daqiqada, boshqalari esa bir necha kun ichida fikr-mulohaza bildiradilar, shuning uchun ularni yozish ko'proq vaqt oladi va kamroq ko'rib chiqiladi.

Klassik sinov piramidasi mavjud bo'lib, u ko'proq testlar bo'lishi kerakligini ko'rsatadi.

Ushbu ramka IaC loyihasida bizga qanday taalluqlidir? Aslida... umuman emas.

• Birlik testlari, ularning ko'p bo'lishi kerakligiga qaramay, juda ko'p bo'lishi mumkin emas. Yoki ular bilvosita biror narsani sinab ko'rishadi. Aslida, biz ularni umuman yozmaymiz, deyishimiz mumkin. Ammo bu erda biz qila oladigan testlar uchun bir nechta ilovalar mavjud:
  1. Jsonnet kodini sinab ko'rish. Bu, masalan, bizning dron yig'ish quvurimiz, bu juda murakkab. Jsonnet kodi testlar bilan yaxshi qamrab olingan.
     Biz buni ishlatamiz Jsonnet uchun birlik test tizimi.
  2. Resurs ishga tushirilganda bajariladigan skriptlar uchun testlar. Skriptlar Python-da yozilgan va shuning uchun ularga testlar yozilishi mumkin.
• Testlarda konfiguratsiyani tekshirish mumkin, ammo biz buni qilmaymiz. Resurs konfiguratsiyasi qoidalarini tekshirish orqali ham sozlash mumkin tflint. Biroq, u erda tekshiruvlar terraform uchun juda oddiy, ammo ko'plab test skriptlari AWS uchun yozilgan. Va biz Azure-damiz, shuning uchun bu yana amal qilmaydi.
• Komponentlarni integratsiyalash testlari: bu ularni qanday tasniflaganingizga va qaerga qo'yganingizga bog'liq. Lekin ular asosan ishlaydi.

  Integratsiya testlari shunday ko'rinadi.

  
  
  Bu Drone CI-da tasvirlarni yaratishga misol. Ularga erishish uchun Packer tasviri paydo bo'lguncha 30 daqiqa kutishingiz kerak, keyin ular o'tib ketishi uchun yana 15 daqiqa kutishingiz kerak. Ammo ular mavjud!

  Rasmni tekshirish algoritmi

  1. Packer avval tasvirni to'liq tayyorlashi kerak.
  2. Sinov yonida mahalliy holatga ega terraform mavjud bo'lib, biz ushbu tasvirni joylashtirish uchun foydalanamiz.
  3. Ochayotganda tasvir bilan ishlashni osonlashtirish uchun yaqin atrofda joylashgan kichik modul ishlatiladi.
  4. VM tasvirdan o'rnatilgach, tekshiruvlar boshlanishi mumkin. Asosan, tekshiruvlar mashinada amalga oshiriladi. U ishga tushirishda skriptlar qanday ishlaganini va demonlar qanday ishlashini tekshiradi. Buni amalga oshirish uchun ssh yoki winrm orqali biz yangi ko'tarilgan mashinaga kiramiz va konfiguratsiya holatini yoki xizmatlar yoqilganligini tekshiramiz.

• Vaziyat terraform modullarida integratsiya testlari bilan o'xshash. Mana bunday testlarning xususiyatlarini tushuntiruvchi qisqa jadval.

  
  
  Quvur bo'yicha qayta aloqa taxminan 40 daqiqa. Hamma narsa juda uzoq vaqt davomida sodir bo'ladi. U regressiya uchun ishlatilishi mumkin, ammo yangi rivojlanish uchun bu umuman haqiqiy emas. Agar siz bunga juda va juda tayyor bo'lsangiz, ishlaydigan skriptlarni tayyorlang, keyin uni 10 daqiqaga qisqartirishingiz mumkin. Ammo bu hali ham birlik testlari emas, ular 5 soniyada 100 qismni bajaradilar.

Tasvirlar yoki terraform modullarini yig'ishda birlik testlarining yo'qligi ishni REST yoki Python skriptlari orqali boshqarilishi mumkin bo'lgan alohida xizmatlarga o'tkazishga undaydi.

Masalan, virtual mashina ishga tushganda u o'zini xizmatda ro'yxatdan o'tkazishiga ishonch hosil qilishimiz kerak edi ScaleFT, va virtual mashina yo'q qilinganida, u o'zini o'chirib tashladi.

Bizda ScaleFT xizmati borligi sababli, biz API orqali u bilan ishlashga majburmiz. U erda o'ram yozilgan edi, uni tortib olib: "Kiring va buni va buni o'chirib tashlang". U barcha kerakli sozlamalar va kirishlarni saqlaydi.

Buning uchun biz allaqachon oddiy testlarni yozishimiz mumkin, chunki u oddiy dasturiy ta'minotdan farq qilmaydi: qandaydir apiha masxara qilinadi, siz uni tortib olasiz va nima bo'lishini ko'rasiz.

Sinov natijalari: OSni bir daqiqada berishi kerak bo'lgan birlik testi uni bermaydi. Piramidada yuqoriroq sinov turlari samarali, ammo muammolarning faqat bir qismini qamrab oladi.

Juftlik dasturlash

Sinovlar, albatta, yaxshi. Siz ulardan ko'pini yozishingiz mumkin, ular har xil turdagi bo'lishi mumkin. Ular o'z darajalarida ishlaydilar va bizga fikr bildiradilar. Ammo eng tezkor operatsion tizimni taqdim etadigan yomon Unit testlari bilan bog'liq muammo saqlanib qolmoqda. Shu bilan birga, men hali ham ishlash uchun qulay va yoqimli bo'lgan tezkor OTni xohlayman. Olingan yechimning sifati haqida gapirmaslik kerak. Yaxshiyamki, birlik testlariga qaraganda tezroq fikr-mulohazalarni ta'minlaydigan texnikalar mavjud. Bu juft dasturlash.

Kodni yozishda siz uning sifati haqida iloji boricha tezroq fikr-mulohaza olishni xohlaysiz. Ha, siz hamma narsani xususiyat bo'limiga yozishingiz mumkin (hech kim uchun hech narsani buzmaslik uchun), Github-da tortishish so'rovini amalga oshirishingiz, uni fikriga ega bo'lgan kishiga tayinlashingiz va javobni kutishingiz mumkin.

Ammo siz uzoq vaqt kutishingiz mumkin. Odamlarning hammasi band va javob, hatto bitta bo'lsa ham, eng sifatli bo'lmasligi mumkin. Aytaylik, javob darhol keldi, sharhlovchi bir zumda butun fikrni tushundi, lekin javob hali ham kech, keyin keladi. Oldinroq bo'lishini istardim. Juftlik dasturlash aynan shu maqsadga qaratilgan - darhol, yozish vaqtida.

Quyida juft dasturlash uslublari va ularning IaC da ishlashda qo‘llanilishi ko‘rsatilgan:

1. Klassik, Tajribali+Tajribali, taymer bo‘yicha siljish. Ikki rol - haydovchi va navigator. Ikki kishi. Ular bir xil kod ustida ishlaydi va ma'lum vaqtdan keyin rollarni almashtiradi.

Keling, muammolarimizning uslub bilan mosligini ko'rib chiqaylik:

• Muammo: kodni ishlab chiqish uchun vositalar va vositalarning nomukammalligi.
  Salbiy ta'sir: rivojlanish uchun ko'proq vaqt talab etiladi, biz sekinlashamiz, ish sur'ati / ritmi yo'qoladi.
  Biz qanday kurashamiz: biz boshqa asboblardan, umumiy IDE-dan foydalanamiz va yorliqlarni o'rganamiz.
• Muammo: sekin o'rnatish.
  Salbiy ta'sir: kodning ishchi qismini yaratish uchun ketadigan vaqtni oshiradi. Kutishda zerikamiz, kutayotganimizda qo'llarimiz boshqa narsa qilish uchun cho'ziladi.
  Biz qanday kurashamiz: biz uni engmadik.
• Muammo: yondashuvlar va amaliyotlarning etishmasligi.
  Salbiy ta'sir: buni qanday qilib yaxshi va qanday qilib yomon bajarish haqida hech qanday ma'lumot yo'q. Fikr-mulohazalarni qabul qilishni uzaytiradi.
  Biz qanday kurashamiz: juftlik ishida o'zaro fikr almashish va amaliyot deyarli muammoni hal qiladi.

IaC-da ushbu uslubdan foydalanishning asosiy muammosi ishning notekis sur'atidir. An'anaviy dasturiy ta'minotni ishlab chiqishda siz juda bir xil harakatga egasiz. Siz besh daqiqa sarflashingiz va N yozishingiz mumkin. 10 daqiqa sarflang va 2N, 15 daqiqa - 3N yozing. Bu yerda siz besh daqiqa vaqt sarflab, N yozishingiz mumkin, keyin yana 30 daqiqa vaqt sarflab, N ning o'ndan bir qismini yozishingiz mumkin. Bu erda siz hech narsani bilmaysiz, tiqilib qoldingiz, ahmoq. Tekshiruv vaqt talab etadi va o'zini dasturlashdan chalg'itadi.

Xulosa: uning sof shaklida u biz uchun mos emas.

2. Ping-pong. Ushbu yondashuv bir kishi testni yozishni, ikkinchisi esa uni amalga oshirishni o'z ichiga oladi. Birlik testlari bilan hamma narsa murakkab ekanligini va siz ko'p dasturlash vaqtini talab qiladigan integratsiya testini yozishingiz kerakligini hisobga olsak, ping-pongning barcha qulayligi yo'qoladi.

Aytishim mumkinki, biz test skriptini ishlab chiqish va uning kodini amalga oshirish uchun javobgarlikni ajratishga harakat qildik. Bitta ishtirokchi stsenariyni o'ylab topdi, ishning bu qismida u mas'ul edi, u oxirgi so'zni aytdi. Ikkinchisi esa amalga oshirish uchun mas'ul edi. Bu yaxshi natija berdi. Ushbu yondashuv bilan skriptning sifati oshadi.

Xulosa: afsuski, ish sur'ati ping-pongdan IaCda juft dasturlash amaliyoti sifatida foydalanishga imkon bermaydi.

3.Kuchli uslub. Qiyin amaliyot. G'oya shundan iboratki, bitta ishtirokchi direktiv navigatorga aylanadi, ikkinchisi esa ijro etuvchi haydovchi rolini oladi. Bunday holda, qaror qabul qilish huquqi faqat navigatorga tegishli. Haydovchi faqat chop etadi va so'z bilan nima sodir bo'layotganiga ta'sir qilishi mumkin. Rollar uzoq vaqt o'zgarmaydi.

O'rganish uchun yaxshi, lekin kuchli yumshoq ko'nikmalarni talab qiladi. Mana shu yerda biz qotib qoldik. Texnika qiyin edi. Va bu hatto infratuzilma haqida ham emas.

Xulosa: undan potentsial foydalanish mumkin, biz urinishlardan voz kechmaymiz.

4. Mobbing, shiddat va barcha ma'lum, ammo sanab o'tilmagan uslublar Biz buni hisobga olmaymiz, chunki Biz buni sinab ko'rmadik va ishimiz kontekstida bu haqda gapirish mumkin emas.

Juftlik dasturlashdan foydalanish bo'yicha umumiy natijalar:

• Bizda ish sur'ati notekis, bu esa chalkash.
• Biz yetarli darajada yaxshi yumshoq ko'nikmalarga duch keldik. Mavzu sohasi esa bizning bu kamchiliklarimizni bartaraf etishga yordam bermaydi.
• Uzoq sinovlar va asboblar bilan bog'liq muammolar juftlashgan rivojlanishni qiyinlashtiradi.

5. Shunga qaramay, muvaffaqiyatlar bo'ldi. Biz o'zimizning "Konvergensiya - Divergentsiya" usulini ishlab chiqdik. Bu qanday ishlashini qisqacha tasvirlab beraman.

Bir necha kun (bir haftadan kam) doimiy hamkorlarimiz bor. Biz birgalikda bitta vazifani bajaramiz. Biz bir muddat birga o'tiramiz: biri yozadi, ikkinchisi o'tirib, qo'llab-quvvatlovchi jamoani kuzatadi. Keyin biz bir muncha vaqt tarqalib ketamiz, har biri mustaqil ishlarni qiladi, keyin biz yana birlashamiz, juda tez sinxronlashamiz, birgalikda biror narsa qilamiz va keyin yana tarqalib ketamiz.

Rejalashtirish va aloqa

OS muammolari hal qilinadigan amaliyotlarning oxirgi bloki - bu vazifalarning o'zlari bilan ishlashni tashkil etish. Bunga juftlikdan tashqari tajriba almashish ham kiradi. Keling, uchta amaliyotni ko'rib chiqaylik:

1. Maqsadlar daraxti orqali maqsadlar. Biz loyihaning umumiy boshqaruvini kelajakka cheksiz ketadigan daraxt orqali tashkil qildik. Texnik jihatdan kuzatuv Miroda amalga oshiriladi. Bitta vazifa bor - bu oraliq maqsad. Undan kichikroq maqsadlar yoki vazifalar guruhlari chiqadi. Vazifalarning o'zi ulardan kelib chiqadi. Barcha vazifalar ushbu doskada yaratiladi va saqlanadi.

Ushbu sxema shuningdek, biz mitinglarda sinxronlashda kuniga bir marta sodir bo'ladigan fikr-mulohazalarni taqdim etadi. Hammaning oldida umumiy rejaga ega bo'lish, lekin tuzilgan va to'liq ochiq, hammaga nima bo'layotgani va biz qanchalik rivojlanganligimizdan xabardor bo'lish imkonini beradi.

Vazifalarni vizual ko'rishning afzalliklari:

• Sabablilik. Har bir vazifa qandaydir global maqsadga olib keladi. Vazifalar kichikroq maqsadlarga guruhlangan. Infratuzilma domenining o'zi juda texnikdir. Masalan, boshqa nginx-ga o'tish bo'yicha runbook yozish biznesga qanday aniq ta'sir ko'rsatishi har doim ham darhol aniq emas. Nishon kartaning yaqinida bo'lishi buni aniqroq qiladi.
  
  Sebep bog'liqligi muammolarning muhim xususiyatidir. U to'g'ridan-to'g'ri savolga javob beradi: "Men to'g'ri ish qilyapmanmi?"
• Parallellik. Biz to'qqiz kishimiz va hammani bitta vazifaga topshirish jismonan imkonsizdir. Bir sohadagi vazifalar har doim ham etarli bo'lmasligi mumkin. Biz kichik ishchi guruhlar o'rtasidagi ishni parallellashtirishga majburmiz. Shu bilan birga, guruhlar bir muncha vaqt o'z vazifalari bo'yicha o'tirishadi, ular boshqa birov tomonidan kuchaytirilishi mumkin. Ba'zida odamlar bu ishchi guruhdan uzoqlashadilar. Kimdir ta'tilga chiqadi, kimdir DevOps konf. uchun hisobot beradi, kimdir Habrda maqola yozadi. Qanday maqsad va vazifalarni parallel ravishda bajarish mumkinligini bilish juda muhim bo'ladi.

2. Ertalabki yig'ilishlarning o'rinbosarlari. Stend-uplarda bizda bunday muammo bor - odamlar parallel ravishda ko'plab vazifalarni bajaradilar. Ba'zida vazifalar bir-biri bilan chambarchas bog'liq va kim nima qilayotganini tushunib bo'lmaydi. Va boshqa jamoa a'zosining fikri juda muhim. Bu muammoni hal qilish yo'nalishini o'zgartirishi mumkin bo'lgan qo'shimcha ma'lumot. Albatta, odatda siz bilan kimdir bor, lekin maslahat va maslahatlar har doim foydalidir.

Ushbu vaziyatni yaxshilash uchun biz "Etakchi stend-upni o'zgartirish" texnikasidan foydalandik. Endi ular ma'lum bir ro'yxatga ko'ra aylantiriladi va bu o'z ta'sirini ko'rsatadi. Sizning navbatingiz kelganda, siz Scrum uchrashuvini yaxshi o'tkazish uchun sho'ng'in va nima bo'layotganini tushunishga majbur bo'lasiz.

3. Ichki demo. Juftlik dasturlashdan muammoni hal qilishda yordam berish, muammo daraxtida vizualizatsiya va ertalab skrum yig'ilishlarida yordam berish yaxshi, lekin ideal emas. Er-xotin sifatida siz faqat bilimingiz bilan cheklanasiz. Vazifalar daraxti global miqyosda kim nima qilayotganini tushunishga yordam beradi. Ertalabki yig'ilishda taqdimotchi va hamkasblar sizning muammolaringizga chuqur kirmaydi. Ular, albatta, biror narsani o'tkazib yuborishlari mumkin.

Bajarilgan ishlarni bir-biriga ko‘rsatib, keyin muhokama qilishda yechim topildi. Biz haftada bir marta bir soat davomida uchrashamiz va o'tgan haftada qilgan vazifalarimiz yechimlari tafsilotlarini ko'rsatamiz.

Namoyish paytida topshiriqning tafsilotlarini ochib berish va uning ishlashini ko'rsatishga ishonch hosil qilish kerak.

Hisobot nazorat ro'yxati yordamida amalga oshirilishi mumkin.1. Kontekstga kiring. Vazifa qaerdan paydo bo'ldi, nega kerak edi?

2. Muammo avval qanday hal qilingan? Masalan, sichqonchani katta bosish kerak edi yoki umuman hech narsa qilish mumkin emas edi.

3. Biz uni qanday yaxshilaymiz. Misol uchun: "Mana, endi skriptosik bor, mana readme."

4. Qanday ishlashini ko'rsating. Ba'zi foydalanuvchi stsenariylarini bevosita amalga oshirish tavsiya etiladi. Men X istayman, men Y qilaman, Y (yoki Z) ni ko'raman. Misol uchun, men NGINX-ni ishlataman, url-ni chekaman va 200 OK olaman. Agar harakat uzoq bo'lsa, uni keyinroq ko'rsatish uchun oldindan tayyorlang. Agar u mo'rt bo'lsa, demodan bir soat oldin uni juda ko'p buzmaslik tavsiya etiladi.

5. Muammo qanchalik muvaffaqiyatli hal qilinganligini, qanday qiyinchiliklar saqlanib qolayotganini, nima tugallanmaganligini, kelajakda qanday yaxshilanishlar mumkinligini tushuntiring. Misol uchun, endi CLI, keyin CIda to'liq avtomatlashtirish bo'ladi.

Har bir ma'ruzachi uni 5-10 daqiqagacha ushlab turishi tavsiya etiladi. Agar sizning nutqingiz muhim bo'lsa va ko'proq vaqt talab qilsa, buni sre-takeover kanalida oldindan muvofiqlashtiring.

Yuzma-yuz qismdan keyin har doim mavzuda muhokama bo'ladi. Bu erda bizning vazifalarimiz bo'yicha kerakli fikr-mulohazalar paydo bo'ladi.

Natijada, sodir bo'layotgan narsalarning foydaliligini aniqlash uchun so'rov o'tkaziladi. Bu nutqning mohiyati va topshiriqning ahamiyati haqida fikr-mulohazalar.

Uzoq xulosalar va keyin nima

Maqolaning ohangi biroz pessimistik bo'lib tuyulishi mumkin. Bu unday emas. Teskari aloqaning ikkita quyi darajasi, ya'ni testlar va juft dasturlash ishlaydi. An'anaviy rivojlanishdagi kabi mukammal emas, lekin undan ijobiy ta'sir bor.

Sinovlar hozirgi ko'rinishida faqat qisman kodni qamrab oladi. Ko'pgina konfiguratsiya funktsiyalari sinovdan o'tkazilmaydi. Kod yozishda ularning haqiqiy ishga ta'siri past. Biroq, integratsiya testlarining ta'siri bor va ular qo'rqmasdan refaktoringni amalga oshirishga imkon beradi. Bu katta yutuq. Bundan tashqari, diqqatni yuqori darajadagi tillarda rivojlantirishga o'tkazish bilan (bizda python bor, go) muammo yo'qoladi. Va "elim" uchun ko'p tekshiruvlar kerak emas, umumiy integratsiyani tekshirish kifoya.

Juftlikda ishlash ko'proq aniq odamlarga bog'liq. Vazifa omili va bizning yumshoq ko'nikmalarimiz mavjud. Ba'zi odamlarda bu juda yaxshi ishlaydi, boshqalarda esa yomonroq ishlaydi. Buning albatta foydasi bor. Ko'rinib turibdiki, juftlik bilan ishlash qoidalariga yetarlicha rioya qilinmasa ham, topshiriqlarni birgalikda bajarish faktining o'zi natija sifatiga ijobiy ta'sir ko'rsatadi. Shaxsan menga juftlikda ishlash osonroq va yoqimliroq.

OTga ta'sir qilishning yuqori darajadagi usullari - rejalashtirish va vazifalar bilan ishlash aniq samara beradi: yuqori sifatli bilim almashinuvi va ishlab chiqish sifati yaxshilanadi.

Bir qatorda qisqa xulosalar

• HR amaliyotchilari IaC da ishlaydi, ammo unumdorligi past.
• Ishlayotgan narsani kuchaytiring.
• O'zingizning kompensatsiya mexanizmlari va amaliyotlarini o'ylab toping.

Manba: www.habr.com