Сайн уу, Хабр! Өмнө нь би Дэд бүтцийн амьдралын код парадигмын талаар гомдоллож байсан бөгөөд одоогийн нөхцөл байдлыг шийдэхийн тулд юу ч санал болгоогүй. Цөхрөлийн ангалаас ангижрах, нөхцөл байдлыг зөв чиглэлд чиглүүлэхэд тань ямар арга барил, дадал туслахыг би өнөөдөр танд хэлэхээр буцаж байна.
Өмнөх нийтлэлд Би энэ талбайн талаархи сэтгэгдлээ хуваалцаж, энэ бүс дэх өнөөгийн нөхцөл байдлын талаар эргэцүүлэн бодохыг хичээсэн, тэр ч байтугай бүх хөгжүүлэгчдэд мэддэг стандарт туршлага нь тусалж чадна гэж санал болгов. Амьдралын талаар маш их гомдол ирсэн юм шиг санагдаж болох ч өнөөгийн нөхцөл байдлаас гарах арга замын талаар санал ирээгүй.
Бид хэн бэ, хаана байна, бидэнд ямар асуудал байна
Бид одоогоор зургаан программист, гурван дэд бүтцийн инженерээс бүрдсэн Sre Onboarding Team-д ажиллаж байна. Бид бүгд дэд бүтцийг код (IaC) болгон бичихийг оролдож байна. Бид үндсэндээ код бичих арга мэддэг, "дунджаас дээгүүр" хөгжүүлэгч байсан түүхтэй учраас үүнийг хийдэг.
- Бидэнд тодорхой мэдлэг, дадлагын мэдлэг, код бичих чадвар, шинэ зүйл сурах хүсэл зэрэг олон давуу тал бий.
- Мөн суларсан хэсэг байгаа бөгөөд энэ нь бас хасах зүйл юм: дэд бүтцийн техник хангамжийн талаар мэдлэг дутмаг.
Бидний IaC-д ашигладаг технологийн стек.
- Нөөцийг бий болгох Terraform.
- Зураг угсрах савлагч. Эдгээр нь Windows, CentOS 7 зургууд юм.
- Jsonnet нь drone.io-д хүчирхэг бүтээц хийхээс гадна савлагч json болон манай terraform модулиудыг үүсгэх болно.
- Номин.
- Зураг бэлтгэх үед боломжтой.
- Туслах үйлчилгээ болон скрипт бэлтгэхэд зориулсан Python.
- Энэ бүхэн нь багийн гишүүдийн хооронд хуваалцсан залгаасууд бүхий VSCode дээр.
Миний дүгнэлт Ийм байсан: Би өөдрөг үзлийг (хамгийн түрүүнд өөртөө) бий болгохыг хичээсэн бөгөөд энэ салбарт тулгарч буй бэрхшээл, хүндрэлийг даван туулахын тулд бидний мэддэг арга барил, дадлыг туршиж үзэх болно гэж хэлмээр байна.
Одоогоор бид дараах IaC асуудлуудтай тэмцэж байна:
- Код боловсруулах хэрэгсэл, хэрэгслийн төгс бус байдал.
- Удаан байршуулалт. Дэд бүтэц нь бодит ертөнцийн нэг хэсэг бөгөөд энэ нь удаан байж болно.
- Арга барил, арга барил дутмаг.
- Бид шинэ бөгөөд тийм ч их зүйл мэдэхгүй.
Extreme Programming (XP) нь аврахад тусална
Бүх хөгжүүлэгчид Extreme Programming (XP) болон түүний ард байгаа практикийг мэддэг. Бидний олонхи нь энэ аргыг хэрэглэж байсан бөгөөд энэ нь амжилттай болсон. Тэгэхээр дэд бүтцийн бэрхшээлийг даван туулахын тулд тэнд заасан зарчим, практикийг ашиглаж яагаад болохгүй гэж? Бид энэ хандлагыг авч, юу болохыг харахаар шийдсэн.
Танай салбарт XP аргыг хэрэглэх боломжтой эсэхийг шалгаж байнаXP-ийн тохиромжтой орчин болон энэ нь бидэнтэй хэрхэн холбогдож байгааг энд харуулав.
1. Програм хангамжийн шаардлагыг динамикаар өөрчлөх. Эцсийн зорилго нь юу болох нь бидэнд тодорхой байсан. Гэхдээ нарийн ширийн зүйл нь өөр байж болно. Бид хаана такси барихаа өөрсдөө шийддэг тул шаардлага нь үе үе өөрчлөгддөг (гол төлөв өөрсдөө). Хэрэв бид автоматжуулалтыг өөрөө хийдэг, өөрөө шаардлага, ажлын цар хүрээг хязгаарладаг SRE багийг авбал энэ цэг маш сайн тохирно.
2. Шинэ технологи ашиглан тогтсон хугацаатай төслүүдээс үүсэх эрсдэл. Бидэнд үл мэдэгдэх зарим зүйлийг ашиглах үед эрсдэл гарч болзошгүй. Энэ бол 100% бидний тохиолдол юм. Манай төсөл бүхэлдээ бидний сайн мэддэггүй технологийг ашиглах явдал байв. Ерөнхийдөө энэ бол байнгын асуудал, учир нь... Дэд бүтцийн салбарт олон шинэ технологиуд байнга гарч ирж байна.
3,4. Жижиг, хамтран байрладаг өргөтгөсөн хөгжүүлэлтийн баг. Таны ашиглаж буй автомат технологи нь нэгж болон функциональ туршилт хийх боломжийг олгодог. Энэ хоёр цэг бидэнд тийм ч тохирохгүй байна. Нэгдүгээрт, бид уялдаа холбоотой баг биш, хоёрдугаарт, бид есөн бүрэлдэхүүнтэй, том баг гэж үзэж болно. Хэдийгээр "том" багийн зарим тодорхойлолтоор бол ихэнх нь 14+ хүн байдаг.
Зарим XP дадлага болон тэдгээр нь санал хүсэлтийн хурд, чанарт хэрхэн нөлөөлдөгийг харцгаая.
XP санал хүсэлтийн давталтын зарчим
Миний ойлгосноор санал хүсэлт нь би зөв зүйл хийж байна уу, бид тийшээ явж байна уу гэсэн асуултын хариулт юм. XP-д үүнд зориулсан тэнгэрлэг схем байдаг: цаг хугацааны санал хүсэлтийн гогцоо. Сонирхолтой нь бид хэдий чинээ доогуур байна, төдий чинээ хурдан OS-ийг шаардлагатай асуултуудад хариулж чаддаг.
Энэ бол манай мэдээллийн технологийн салбарт OS-ийг хурдан авах боломжтой гэсэн нэлээд сонирхолтой сэдэв юм. Зургаан сарын турш нэг төсөл хийчихээд дараа нь л эхэндээ алдаа байсныг олж мэдэх нь ямар их зовлонтой болохыг төсөөлөөд үз дээ. Энэ нь дизайн болон нарийн төвөгтэй системийг барихад тохиолддог.
Манай IaC тохиолдолд санал хүсэлт бидэнд тусалдаг. Би нэн даруй дээрх диаграммд жижиг тохируулга хийх болно: хувилбарын төлөвлөгөө нь сарын мөчлөггүй, харин өдөрт хэд хэдэн удаа тохиолддог. Энэ үйлдлийн системтэй холбоотой зарим практик байдаг бөгөөд бид үүнийг илүү нарийвчлан авч үзэх болно.
Чухал: санал хүсэлт нь дээр дурдсан бүх асуудлыг шийдвэрлэх боломжтой. XP дадлагатай хослуулан энэ нь таныг цөхрөлийн ангалаас гаргаж чадна.
Өөрийгөө цөхрөлийн ангалаас хэрхэн гаргах вэ: гурван дасгал
Шалгалт
Туршилтуудыг XP-ийн санал хүсэлтийн гогцоонд хоёр удаа дурдсан. Зүгээр ч нэг тийм биш. Эдгээр нь бүхэл бүтэн Extreme Programming техникт маш чухал юм.
Таныг Нэгж, Хүлээн авах тестүүд байгаа гэж үзэж байна. Зарим нь танд хэдхэн минутын дотор, зарим нь хэдхэн өдрийн дотор санал хүсэлтээ өгдөг тул бичихэд удаан хугацаа шаардагдах бөгөөд хянагдах нь бага байдаг.
Сонгодог туршилтын пирамид байдаг бөгөөд энэ нь илүү олон тест байх ёстойг харуулж байна.
IaC төсөлд энэ хүрээ бидэнд хэрхэн хамаатай вэ? Үнэндээ... огтхон ч биш.
- Нэгжийн туршилтууд нь маш олон байх ёстой хэдий ч хэтэрхий олон байж болохгүй. Эсвэл тэд ямар нэг зүйлийг маш шууд бусаар туршиж байна. Уг нь бид тэднийг огт бичдэггүй гэж хэлж болно. Гэхдээ бид ийм туршилт хийх боломжтой хэд хэдэн програмууд энд байна:
- jsonnet кодыг туршиж байна. Жишээлбэл, энэ бол манай нисгэгчгүй онгоц угсрах хоолой бөгөөд энэ нь нэлээд төвөгтэй юм. Jsonnet кодыг тестээр сайн хамруулсан.
Бид үүнийг ашигладаг . - Нөөцийг эхлүүлэх үед гүйцэтгэсэн скриптүүдийн туршилтууд. Скриптүүд нь Python хэл дээр бичигдсэн тул тэдгээр дээр тест бичиж болно.
- jsonnet кодыг туршиж байна. Жишээлбэл, энэ бол манай нисгэгчгүй онгоц угсрах хоолой бөгөөд энэ нь нэлээд төвөгтэй юм. Jsonnet кодыг тестээр сайн хамруулсан.
- Туршилтаар тохиргоог шалгах боломжтой боловч бид үүнийг хийдэггүй. Мөн дамжуулан шалгах нөөцийн тохиргооны дүрмийг тохируулах боломжтой . Гэсэн хэдий ч, тэнд байгаа шалгалтууд нь terraform-ийн хувьд хэтэрхий энгийн боловч олон тестийн скриптүүдийг AWS-д зориулж бичсэн байдаг. Мөн бид Azure дээр байгаа тул энэ нь дахин хамаарахгүй.
- Бүрэлдэхүүн хэсгүүдийг нэгтгэх тестүүд: энэ нь тэдгээрийг хэрхэн ангилж, хаана байрлуулахаас хамаарна. Гэхдээ тэд үндсэндээ ажилладаг.
Интеграцийн тестүүд иймэрхүү харагдаж байна.
Энэ бол Drone CI дээр зураг бүтээх жишээ юм. Тэдэнд хүрэхийн тулд Пакерын дүрс үүсэх хүртэл 30 минут хүлээх хэрэгтэй бөгөөд дараа нь тэд өнгөрөх хүртэл 15 минут хүлээх хэрэгтэй. Гэхдээ тэд байдаг!Зургийн баталгаажуулалтын алгоритм
- Пакер эхлээд зургийг бүрэн бэлтгэх ёстой.
- Туршилтын хажууд орон нутгийн мужтай терраформ байдаг бөгөөд бид энэ зургийг байрлуулахад ашигладаг.
- Илгээх үед зурагтай ажиллахад хялбар болгохын тулд ойролцоо байрлах жижиг модулийг ашигладаг.
- Зурган дээрээс VM-ийг байрлуулсны дараа шалгалтыг эхлүүлж болно. Үндсэндээ шалгалтыг машинаар хийдэг. Энэ нь эхлүүлэх үед скриптүүд хэрхэн ажиллаж, демонууд хэрхэн ажилладагийг шалгадаг. Үүнийг хийхийн тулд ssh эсвэл winrm-ээр дамжуулан бид шинээр суулгасан машин руу нэвтэрч тохиргооны статус эсвэл үйлчилгээ ажиллаж байгаа эсэхийг шалгана.
- Нөхцөл байдал нь terraform-ийн модулиудын интеграцийн тесттэй төстэй юм. Ийм туршилтын онцлогийг тайлбарласан богино хүснэгт энд байна.
Дамжуулах хоолойн талаархи санал хүсэлт ойролцоогоор 40 минут байна. Бүх зүйл маш удаан хугацаанд тохиолддог. Энэ нь регрессийн хувьд ашиглагдаж болох боловч шинэ хөгжлийн хувьд энэ нь ерөнхийдөө бодитой бус юм. Хэрэв та үүнд маш их бэлтгэгдсэн бол ажиллаж байгаа скриптүүдийг бэлтгэ, тэгвэл та үүнийг 10 минут болгож багасгаж болно. Гэхдээ эдгээр нь 5 секундын дотор 100 ширхэг хийдэг нэгжийн туршилт биш хэвээр байна.
Зураг эсвэл терраформ модулиудыг угсрахдаа нэгжийн тест байхгүй байгаа нь ажлыг REST-ээр эсвэл Python скриптээр ажиллуулж болох тусдаа үйлчилгээнд шилжүүлэхийг дэмждэг.
Жишээлбэл, виртуал машин эхлэхэд энэ нь үйлчилгээнд бүртгүүлдэг эсэхийг шалгах шаардлагатай байсан , мөн виртуал машин устах үед өөрөө устгасан.
Бидэнд ScaleFT үйлчилгээ байдаг тул API-ээр дамжуулан үүнтэй ажиллахаас өөр аргагүй болдог. Тэнд "Ороод энийг, тэрийг устга" гэж чирч болохуйц боодол бичсэн байв. Энэ нь шаардлагатай бүх тохиргоо, хандалтыг хадгалдаг.
Энгийн програм хангамжаас ялгаатай биш тул бид ердийн тестүүдийг бичиж болно: ямар нэгэн апиха шоолж, та үүнийг татаж аваад юу болохыг хараарай.
Туршилтын үр дүн: OS-д нэг минутын дотор өгөх ёстой нэгжийн туршилт нь үүнийг өгдөггүй. Пирамидын өндөр түвшний туршилтууд нь үр дүнтэй боловч асуудлын зөвхөн нэг хэсгийг хамардаг.
Хос програмчлал
Туршилтууд нь мэдээж сайн. Та тэдгээрийг маш олон бичиж болно, тэдгээр нь янз бүрийн хэлбэртэй байж болно. Тэд өөрсдийн түвшинд ажиллаж, бидэнд санал хүсэлтээ өгөх болно. Гэхдээ хамгийн хурдан үйлдлийн системийг өгдөг муу Unit тестүүдийн асуудал хэвээр байна. Үүний зэрэгцээ би ажиллахад хялбар, тааламжтай хурдан үйлдлийн системтэй байхыг хүсч байна. Үүссэн шийдлийн чанарыг дурдахгүй өнгөрч болохгүй. Аз болоход, нэгжийн туршилтаас ч илүү хурдан хариу өгөх боломжтой техникүүд байдаг. Энэ бол хос програмчлал юм.
Код бичихдээ түүний чанарын талаар санал хүсэлтийг аль болох хурдан авахыг хүсдэг. Тиймээ, та бүх зүйлийг функцийн салбарт бичиж болно (хэнд ч юу ч эвдэхгүй байхын тулд), Github дээр татах хүсэлт гаргаж, санал бодол нь жинтэй хүнд оноож, хариуг нь хүлээж болно.
Гэхдээ та удаан хүлээх боломжтой. Хүмүүс бүгд завгүй байдаг бөгөөд хариулт нь нэг байсан ч хамгийн чанартай биш байж магадгүй юм. Хариулт нь тэр дороо ирсэн гэж бодъё, хянагч бүх санааг тэр дор нь ойлгосон боловч хариулт нь хожимдсон хэвээр байна. Эрт байсан ч болоосой. Энэ бол хос програмчлалын зорилго юм - бичих үед тэр даруй.
Доорх нь хос програмчлалын хэв маяг ба тэдгээрийг IaC дээр ажиллахад ашиглах боломжтой юм.
1. Сонгодог, Туршлагатай+Туршлагатай, таймераар солино. Жолооч ба залуур гэсэн хоёр үүрэг. Хоёр хүн. Тэд ижил код дээр ажиллаж, тодорхой хугацааны дараа дүрээ сольдог.
Бидний асуудлуудын хэв маягтай нийцэж байгааг авч үзье.
- Асуудал: код боловсруулах хэрэгсэл, хэрэгслийн төгс бус байдал.
Сөрөг нөлөө: хөгжүүлэхэд удаан хугацаа шаардагдана, бид удааширч, ажлын хурд / хэмнэл алдагдана.
Бид хэрхэн тулалддаг: бид өөр хэрэгсэл, нийтлэг IDE ашигладаг, мөн товчлолуудыг сурдаг. - Асуудал: Удаан байршуулалт.
Сөрөг нөлөө: кодын ажлын хэсгийг бүтээхэд шаардагдах хугацааг нэмэгдүүлдэг. Хүлээж байхдаа залхдаг, хүлээх зуураа өөр зүйл хийх гэж гараа сунгадаг.
Бид хэрхэн тулалддаг вэ: бид үүнийг даван туулж чадаагүй. - Асуудал: арга барил, практик дутмаг.
Сөрөг нөлөө: яаж сайн, яаж муу хийх талаар мэдлэггүй. Санал хүсэлт хүлээн авах хугацааг уртасгадаг.
Бид хэрхэн тэмцдэг вэ: хосоор ажиллахдаа харилцан санал бодлоо солилцож, дадлага хийх нь асуудлыг бараг шийддэг.
IaC-д энэ хэв маягийг ашиглах гол асуудал бол ажлын жигд бус хурд юм. Уламжлалт програм хангамж хөгжүүлэхэд та маш жигд хөдөлгөөнтэй байдаг. Та таван минут зарцуулж, N. 10 минут зарцуулж, 2N, 15 минут - 3N бичиж болно. Энд таван минут зарцуулаад N гэж бичээд, дахиад 30 минут зарцуулаад N-ийн аравны нэгийг бичиж болно. Энд чи юу ч мэдэхгүй, чи гацаж байна, тэнэг. Мөрдөн байцаалтын явцад цаг хугацаа шаардагдах бөгөөд программчлахаас сатаардаг.
Дүгнэлт: цэвэр хэлбэрээр энэ нь бидний хувьд тохиромжгүй юм.
2. Ширээний теннис. Энэ арга нь нэг хүн тестийг бичиж, нөгөө нь түүний хэрэгжилтийг хийдэг. Нэгжийн тестийн хувьд бүх зүйл төвөгтэй байдаг бөгөөд та програмчлахад удаан хугацаа шаардагддаг интеграцийн тест бичих шаардлагатай байдаг тул ширээний теннисний бүх хялбар байдал алга болно.
Бид туршилтын скрипт зохиох, түүнд зориулсан кодыг хэрэгжүүлэх үүрэг хариуцлагаа салгаж үзсэн гэж би хэлж чадна. Нэг оролцогч скриптийг гаргаж ирсэн, ажлын энэ хэсэгт тэр хариуцаж, сүүлчийн үгээ хэлсэн. Нөгөөх нь хэрэгжүүлэх үүрэгтэй байсан. Энэ нь сайн болсон. Энэ аргын тусламжтайгаар скриптийн чанар нэмэгддэг.
Дүгнэлт: харамсалтай нь, ажлын хурд нь ширээний теннисийг IaC-д хос програмчлалын дасгал болгон ашиглахыг зөвшөөрдөггүй.
3. Хүчтэй хэв маяг. . Гол санаа нь нэг оролцогч удирдамж чиглүүлэгч болж, хоёр дахь нь гүйцэтгэх жолоочийн үүргийг гүйцэтгэдэг. Энэ тохиолдолд шийдвэр гаргах эрх нь зөвхөн навигаторт хамаарна. Жолооч зөвхөн хэвлэдэг бөгөөд үгээр юу болж байгааг нөлөөлж чадна. Дүрүүд удаан хугацаанд өөрчлөгддөггүй.
Сурахад тохиромжтой, гэхдээ хүчтэй зөөлөн ур чадвар шаарддаг. Энд л бид гацсан. Техник нь хэцүү байсан. Мөн дэд бүтцийн асуудал ч биш.
Дүгнэлт: үүнийг ашиглах боломжтой, бид оролдохоо больсон.
4. Моббинг, бөөгнөрөл болон бүх мэдэгдэж байгаа боловч жагсаалтад ороогүй хэв маяг Бид үүнийг тооцохгүй, учир нь Бид үүнийг туршиж үзээгүй бөгөөд бидний ажлын хүрээнд энэ талаар ярих боломжгүй юм.
Хос програмчлалыг ашиглах ерөнхий үр дүн:
- Манайд ажлын хурд жигд бус байгаа нь будлиантай.
- Бид хангалтгүй сайн зөөлөн ур чадваруудтай тулгарсан. Мөн сэдэв нь бидний эдгээр дутагдлыг арилгахад тус болохгүй.
- Урт хугацааны туршилт, багаж хэрэгсэлтэй холбоотой асуудал нь хосолсон хөгжлийг хүндрүүлдэг.
5. Гэсэн хэдий ч амжилтанд хүрсэн. Бид "Нэгдмэл байдал - Дивергенц" гэсэн өөрийн аргыг боловсруулсан. Энэ нь хэрхэн ажилладаг талаар би товч тайлбарлах болно.
Бид хэд хоногийн турш байнгын түншүүдтэй (долоо хоногоос бага). Бид хамтдаа нэг даалгавар хийдэг. Бид хэсэг хугацаанд хамт сууна: нэг нь бичдэг, нөгөө нь суугаад дэмжлэг үзүүлэх багийг хардаг. Дараа нь бид хэсэг хугацаанд тарж, тус бүр бие даасан зүйл хийдэг, дараа нь бид дахин нийлж, маш хурдан синхрончлол хийж, хамтдаа ямар нэгэн зүйл хийж, дараа нь дахин тардаг.
Төлөвлөлт ба харилцаа холбоо
OS-ийн асуудлыг шийдвэрлэх практикийн сүүлчийн блок бол даалгавартай ажиллах зохион байгуулалт юм. Үүнд хосын ажлаас гадуурх туршлага солилцох зэрэг орно. Гурван практикийг авч үзье:
1. Зорилго модоор дамжуулан зорилтууд. Бид ирээдүйд эцэс төгсгөлгүй явах модоор дамжуулан төслийн ерөнхий удирдлагыг зохион байгуулсан. Техникийн хувьд ажиглалтыг Мирод хийдэг. Нэг даалгавар байдаг - энэ нь завсрын зорилго юм. Үүнээс жижиг зорилтууд эсвэл бүлгүүд даалгаврууд гардаг. Даалгаврууд өөрсдөө тэднээс ирдэг. Бүх даалгавруудыг энэ самбар дээр үүсгэж, хадгалдаг.
Энэ схем нь мөн жагсаал цуглаан дээр синхрончлоход өдөрт нэг удаа тохиолддог санал хүсэлтийг өгдөг. Хүн бүрийн өмнө нэгдсэн төлөвлөгөөтэй, гэхдээ бүтэц зохион байгуулалттай, бүрэн нээлттэй байх нь юу болж байгааг, бид хэр зэрэг ахиц дэвшсэнийг хүн бүр мэддэг байх боломжийг олгодог.
Даалгаврын харааны давуу талууд:
- Шалтгаан холбоо. Даалгавар бүр нь дэлхийн хэмжээний зорилгод хүргэдэг. Даалгавруудыг жижиг зорилгод нэгтгэдэг. Дэд бүтцийн домэйн нь өөрөө нэлээд техникийн шинж чанартай байдаг. Жишээлбэл, өөр nginx рүү шилжих тухай runbook бичих нь бизнест ямар нөлөө үзүүлэх нь тэр бүр тодорхой байдаггүй. Зорилтот картыг ойролцоо байлгах нь илүү ойлгомжтой болгодог.
Шалтгаан холбоо нь асуудлын чухал шинж чанар юм. Энэ нь "Би зөв зүйл хийж байна уу?" Гэсэн асуултад шууд хариулдаг. - Параллелизм. Бид есөн хүн байдаг бөгөөд хүн бүрийг нэг даалгаварт оруулах нь бие махбодийн хувьд боломжгүй юм. Нэг бүсээс хийх даалгавар нь үргэлж хангалттай байдаггүй. Бид жижиг ажлын хэсгүүдийн ажлыг зэрэгцүүлэхээс өөр аргагүйд хүрч байна. Үүний зэрэгцээ бүлгүүд даалгаврынхаа дагуу хэсэг хугацаанд суудаг тул өөр хэн нэгэн тэднийг хүчирхэгжүүлж болно. Заримдаа энэ ажлын хэсгээс хүмүүс холддог. Хэн нэгэн амралтаараа явдаг, хэн нэгэн DevOps conf-д зориулж тайлан гаргадаг, хэн нэгэн Habr дээр нийтлэл бичдэг. Ямар зорилго, даалгавруудыг зэрэгцүүлэн хийж болохыг мэдэх нь маш чухал болж байна.
2. Өглөөний хурлын илтгэгчдийг орлох. Стенд-ап дээр бид ийм асуудалтай тулгардаг - хүмүүс олон ажлыг зэрэгцүүлэн хийдэг. Заримдаа даалгаврууд хоорондоо салшгүй холбоотой байдаг бөгөөд хэн юу хийж байгааг ойлгодоггүй. Мөн багийн өөр нэг гишүүний санал бодол маш чухал. Энэ нь асуудлыг шийдвэрлэх явцыг өөрчлөх нэмэлт мэдээлэл юм. Мэдээжийн хэрэг, ихэвчлэн хэн нэгэн тантай хамт байдаг, гэхдээ зөвлөгөө, зөвлөмжүүд үргэлж хэрэгтэй байдаг.
Энэ байдлыг сайжруулахын тулд бид “Тэргүүний зогсолтыг өөрчлөх” аргыг ашигласан. Одоо тэд тодорхой жагсаалтын дагуу эргэлддэг бөгөөд энэ нь үр дүнтэй байдаг. Таны ээлж болоход та сайн Scrum уулзалт зохион байгуулахын тулд шумбаж, юу болж байгааг ойлгохоос өөр аргагүй болно.
3. Дотоод үзүүлэн. Хос програмчлалын тусламжтайгаар асуудлыг шийдвэрлэхэд туслах, асуудлын модыг дүрслэн харуулах, өглөөний скрам уулзалтанд туслах нь сайн боловч тийм ч тохиромжтой биш юм. Хосуудын хувьд та зөвхөн мэдлэгээрээ хязгаарлагддаг. Даалгаврын мод нь дэлхий даяар хэн юу хийж байгааг ойлгоход тусалдаг. Өглөөний хурлын илтгэгч, хамт олон таны асуудалд гүн гүнзгий орохгүй. Тэд ямар нэг зүйлийг алдаж магадгүй юм.
Хийсэн ажлаа бие биедээ үзүүлж, ярилцаж байж шийдэлд хүрсэн. Бид долоо хоногт нэг удаа нэг цагийн турш уулзаж, өнгөрсөн долоо хоногт хийсэн ажлуудынхаа шийдлийн талаар дэлгэрэнгүй харуулдаг.
Үзүүлбэрийн үеэр даалгаврын нарийн ширийн зүйлийг илчилж, түүний ажиллагааг заавал харуулах шаардлагатай.
Тайланг шалгах хуудас ашиглан хийж болно.1. Контекст руу оруулна уу. Даалгавар хаанаас ирсэн бэ, яагаад шаардлагатай байсан бэ?
2. Өмнө нь асуудлыг хэрхэн шийдэж байсан бэ? Жишээлбэл, хулганыг их хэмжээгээр дарах шаардлагатай байсан эсвэл юу ч хийх боломжгүй байсан.
3. Бид үүнийг хэрхэн сайжруулах вэ. Жишээ нь: "Хараач, одоо scriptosik байна, энд Readme байна."
4. Энэ нь хэрхэн ажилладагийг харуул. Хэрэглэгчийн зарим хувилбарыг шууд хэрэгжүүлэхийг зөвлөж байна. Би X-г хүсч байна, би Y-ийг хүсч байна, би Y (эсвэл Z) -ийг хардаг. Жишээ нь, би NGINX-г байрлуулж, url-г тамхи татаад 200 OK авдаг. Хэрэв үйлдэл урт бол дараа нь харуулахын тулд үүнийг урьдчилан бэлтгэ. Хэрэв энэ нь хэврэг бол үзүүлбэр үзүүлэхээс нэг цагийн өмнө үүнийг эвдэхгүй байхыг зөвлөж байна.
5. Асуудлыг хэрхэн амжилттай шийдвэрлэсэн, ямар хүндрэлүүд үлдсэн, юу нь дуусаагүй, цаашид ямар сайжруулалт хийх боломжтойг тайлбарла. Жишээлбэл, одоо CLI, дараа нь CI-д бүрэн автоматжуулалт байх болно.
Илтгэгч бүр үүнийг 5-10 минут байлгахыг зөвлөж байна. Хэрэв таны яриа чухал бөгөөд удаан үргэлжлэх юм бол sre-takeover сувагт үүнийг урьдчилан зохицуулаарай.
Нүүр тулсан хэсгийн дараа сэдэв дээр үргэлж хэлэлцүүлэг байдаг. Эндээс бидний даалгаварт хэрэгтэй санал хүсэлт гарч ирдэг.
Үүний үр дүнд болж буй үйл явдлын ашиг тусыг тодорхойлох судалгааг явуулдаг. Энэ бол ярианы мөн чанар, даалгаврын ач холбогдлын талаархи санал хүсэлт юм.
Урт дүгнэлт, дараа нь юу хийх вэ
Өгүүллийн өнгө аяс бага зэрэг гутранги юм шиг санагдаж магадгүй. Энэ бол буруу. Туршилт, хос програмчлал гэсэн хоёр доод түвшний санал хүсэлт ажилладаг. Уламжлалт хөгжлийнх шиг төгс биш ч үүнээс эерэг нөлөө гарч байна.
Туршилтууд нь одоогийн хэлбэрээрээ зөвхөн хэсэгчилсэн кодын хамрах хүрээг хангадаг. Олон тохиргооны функцууд нь шалгагдаагүй байдаг. Код бичих үед тэдний бодит ажилд үзүүлэх нөлөө бага байна. Гэсэн хэдий ч интеграцийн тестийн үр нөлөө байдаг бөгөөд тэдгээр нь танд айдасгүйгээр рефакторинг хийх боломжийг олгодог. Энэ бол маш том амжилт юм. Мөн өндөр түвшний хэлийг хөгжүүлэхэд анхаарлаа хандуулснаар (бидэнд python, go байна) асуудал арилах болно. Мөн та "цавуу"-д олон шалгалт хийх шаардлагагүй, ерөнхий нэгтгэлийн шалгалт хангалттай.
Хосоор ажиллах нь тодорхой хүмүүсээс илүү хамаардаг. Даалгаврын хүчин зүйл, бидний зөөлөн ур чадвар байдаг. Зарим хүмүүст энэ нь маш сайн, бусад хүмүүст илүү муу байдаг. Үүнээс мэдээж ашиг тус бий. Хосоор ажиллах дүрмийг хангалттай дагаж мөрдөөгүй байсан ч даалгаврыг хамтдаа гүйцэтгэх баримт нь үр дүнгийн чанарт эерэгээр нөлөөлдөг нь ойлгомжтой. Би хувьдаа хосоороо ажиллах нь илүү хялбар бөгөөд тааламжтай санагддаг.
Үйлдлийн системд нөлөөлөх дээд түвшний арга замууд - даалгавруудыг төлөвлөх, ажиллах нь үр нөлөөг өгдөг: өндөр чанартай мэдлэг солилцох, хөгжлийн чанарыг сайжруулах.
Нэг мөрөнд богино дүгнэлт
- Хүний нөөцийн эмч нар IaC-д ажилладаг боловч үр ашиг багатай байдаг.
- Ажиллаж байгаа зүйлийг бэхжүүл.
- Өөрийнхөө нөхөн олговор олгох механизм, дадлыг бий болго.
Эх сурвалж: www.habr.com