Үнэнийг хэлэхэд, Иван мониторингийн хэлтсийн хамт ажиллагсдынхаа дэмий хүчин чармайлтыг байнга инээдэг байв. Тэд компанийн удирдлагын захисан хэмжүүрүүдийг хэрэгжүүлэхийн тулд маш их хүчин чармайлт гаргасан. Тэд маш завгүй байсан тул өөр хэн нэгнийг юу ч хийхийг хүсэхгүй байв.
Гэхдээ энэ нь удирдлагад хангалтгүй байсан - тэд илүү олон шинэ хэмжигдэхүүнүүдийг байнга захиалж, өмнө нь хийж байсан зүйлээ маш хурдан ашиглахаа больсон.
Сүүлийн үед хүн бүр LeadTime-ийн талаар ярих болсон - бизнесийн шинж чанаруудыг хүргэх цаг. Энэ хэмжигдэхүүн нь галзуу тоог харуулсан - нэг даалгавар биелүүлэхэд 200 хоног. Хүн бүр яаж өхөөрдөм, аахаж, гараа тэнгэрт өргөв!
Хэсэг хугацааны дараа чимээ шуугиан аажмаар буурч, удирдлага өөр хэмжүүр үүсгэх тушаалыг хүлээн авав.
Иванд шинэ хэмжүүр харанхуй буланд чимээгүйхэн үхэх нь тодорхой байв.
Үнэхээр Иван энэ тоог мэдсэнээр хэнд ч юу ч хэлэхгүй гэж бодов. 200 хоног эсвэл 2 хоног - ялгаа байхгүй, учир нь тоогоор нь шалтгааныг тодорхойлж, сайн эсвэл муу гэдгийг ойлгох боломжгүй юм.
Энэ бол хэмжүүрийн ердийн урхи юм: шинэ хэмжүүр нь оршин тогтнохын мөн чанарыг хэлж, ямар нэгэн нууц нууцыг тайлбарлах болно. Хүн бүр үүнд маш их найдаж байгаа ч яагаад ч юм юу ч болохгүй. Тийм ээ, учир нь нууцыг хэмжүүрээс олох ёсгүй!
Иванын хувьд энэ бол өнгөрсөн үе шат байв. Тэр үүнийг ойлгосон хэмжилтийн хувьд бүх нууцыг хайх ёстой , өөрөөр хэлбэл Энэ хэмжигдэхүүн үүссэн гэсэн үг юм.
Онлайн дэлгүүрийн хувьд нөлөөллийн объект нь мөнгө авчирдаг үйлчлүүлэгчид байх ба DevOps-ийн хувьд дамжуулах хоолойг ашиглан түгээлт үүсгэж, түгээдэг багууд байх болно.
Нэгэн өдөр Иван танхимд тухтай сандал дээр суугаад, нөлөөллийн объект нь багууд гэдгийг харгалзан DevOps хэмжигдэхүүнийг хэрхэн харахыг хүсч байгаагаа сайтар бодож үзэхээр шийджээ.
DevOps хэмжүүрийн зорилго
Хүн бүр хүргэх хугацааг багасгахыг хүсч байгаа нь ойлгомжтой. 200 хоног бол мэдээж сайн зүйл биш.
Гэхдээ яаж, энэ асуулт байна уу?
Тус компани олон зуун багийг ажиллуулдаг бөгөөд өдөр бүр олон мянган түгээлтүүд DevOps шугамаар дамждаг. Хүргэлтийн бодит хугацаа нь түгээлтийн хэлбэрээр гарч ирнэ. Баг бүр өөрийн гэсэн цаг хугацаа, өөрийн гэсэн онцлогтой байх болно. Энэ эмх замбараагүй байдлын дунд яаж юм олох вэ?
Хариулт нь аяндаа гарч ирсэн - бид асуудалтай багуудаа олж, тэдэнтэй юу болж байгааг, яагаад ийм удаж байгааг олж мэдэх, мөн "сайн" багаас бүгдийг хэрхэн хурдан хийхийг сурах хэрэгтэй. Үүнийг хийхийн тулд та DevOps стенд бүрт багуудын зарцуулсан цагийг хэмжих хэрэгтэй.
“Системийн зорилго нь багийг индэр дээр гарсан хугацаанд нь үндэслэн сонгох явдал юм. Үүний үр дүнд бид тоо биш харин сонгосон хугацаатай тушаалуудын жагсаалтыг авах ёстой.
Хэрэв бид индэр дээр нийт хэдэн цаг зарцуулсан, зогсоолуудын хоорондох завсарлагад хэр их цаг зарцуулсныг олж мэдвэл бид багуудаа олж, тэднийг дуудаж, шалтгааныг нь илүү нарийвчлан ойлгож, арилгах боломжтой" гэж Иван бодлоо.
DevOps-д хүргэх хугацааг хэрхэн тооцоолох вэ
Үүнийг тооцоолохын тулд DevOps процесс болон түүний мөн чанарыг судлах шаардлагатай байв.
Тус компани нь хязгаарлагдмал тооны системийг ашигладаг бөгөөд мэдээллийг зөвхөн тэдгээрээс авах боломжтой бөгөөд өөр хаана ч байхгүй.
Компанийн бүх ажлыг Жира-д бүртгэсэн. Даалгаврыг авах үед түүнд зориулж салбар үүсгэсэн бөгөөд хэрэгжүүлсний дараа BitBucket болон Pull Request-д амлалт өгсөн. PR (Татах хүсэлт) хүлээн авмагц түгээлт автоматаар үүсгэгдэж, Nexus репозиторт хадгалагдсан.
Дараа нь түгээлтийг Женкинс ашиглан хэд хэдэн стенд дээр байрлуулж, автомат болон гарын авлагын туршилтын зөв эсэхийг шалгав.
Иван ямар системээс ямар мэдээлэл авах боломжтойг тайлбарлав.
- Nexus-аас - Түгээлт үүсгэх хугацаа болон тушаалын код агуулсан хавтасны нэр
- Женкинсээс – Ажил бүрийн эхлэх цаг, үргэлжлэх хугацаа, үр дүн, ажлын нэр (ажлын параметрт), үе шатууд (ажлын алхамууд), Nexus дахь түгээлтийн холбоос.
- Иван Жира, БитБакет нарыг дамжуулах хоолойд оруулахгүй байхаар шийдсэн, учир нь... Тэд бэлэн түгээлтийг стенд дээр тараах биш харин хөгжлийн үе шаттай илүү холбоотой байв.
Боломжит мэдээлэлд үндэслэн дараахь диаграммыг зурав.
Түгээлтийг бий болгоход хэр их хугацаа шаардагдах, тэдгээрт хэр их цаг зарцуулдгийг мэдэхийн тулд та DevOps дамжуулах хоолойг бүхэлд нь (бүтэн мөчлөг) туулах нийт зардлыг хялбархан тооцоолж болно.
Иванын дуусгасан DevOps хэмжигдэхүүнүүд энд байна:
- Үүсгэсэн түгээлтийн тоо
- Индэр дээр “ирж”, “дамсан” түгээлтийн хувь
- Стенд дээр зарцуулсан хугацаа (зогсоолын мөчлөг)
- Бүтэн мөчлөг (бүх зогсоолын нийт хугацаа)
- Ажлын үргэлжлэх хугацаа
- Зогсоолын хоорондох завсарлага
- Нэг стенд дээр ажил эхлэх хоорондох завсарлага
Нэг талаас, хэмжүүрүүд нь DevOps дамжуулах хоолойг цаг хугацааны хувьд маш сайн тодорхойлж байсан бол нөгөө талаас тэдгээрийг маш энгийн гэж үздэг байв.
Ажлаа сайн хийсэнд сэтгэл хангалуун байсан Иван илтгэл тавиад удирдлагад танилцуулахаар явлаа.
Тэр гунигтай, гараа доошлуулсаар буцаж ирэв.
"Ах аа, энэ бол бүтэлгүйтэл" гэж инээдтэй хамтрагч инээмсэглэв ...
Дэлгэрэнгүйг нийтлэлээс уншина уу "".
Эх сурвалж: www.habr.com