Зураг:
Сайн уу! Бид тус компанийн автоматжуулалтын инженерүүд мөн бид компанийн бүтээгдэхүүнийг хөгжүүлэхэд дэмжлэг үзүүлдэг: бид хөгжүүлэгчдийн код оруулахаас эхлээд бэлэн бүтээгдэхүүн, лицензийг шинэчлэх сервер дээр нийтлэх хүртэлх бүх угсралтын шугамыг дэмждэг. Албан бусаар биднийг DevOps инженерүүд гэдэг. Энэ нийтлэлд бид програм хангамжийн үйлдвэрлэлийн технологийн үе шатууд, тэдгээрийг хэрхэн харж, хэрхэн ангилах талаар ярихыг хүсч байна.
Материалаас та олон төрлийн бүтээгдэхүүний хөгжлийг зохицуулах нарийн төвөгтэй байдал, технологийн газрын зураг гэж юу болох, шийдлүүдийг оновчтой болгох, хуулбарлахад хэрхэн тусалдаг, боловсруулах үйл явцын үндсэн үе шат, үе шатууд юу вэ, хариуцах чиглэлүүд ямар байдаг талаар мэдэх болно. DevOps болон манай компанийн багуудын хооронд.
Chaos болон DevOps-ийн тухай
DevOps-ийн үзэл баримтлалд хөгжүүлэлтийн хэрэгсэл, үйлчилгээ, тэдгээрийг ашиглах арга зүй, шилдэг туршлагууд багтдаг гэдгийг товч дурдъя. Дэлхий дахиныг онцолж үзье цель Манай компанид DevOps санааг хэрэгжүүлэхээс: энэ нь бүтээгдэхүүний үйлдвэрлэл, засвар үйлчилгээний зардлыг тоон үзүүлэлтээр (хүн-цаг эсвэл машин цаг, CPU, RAM, Диск гэх мэт) тогтмол бууруулж байгаа явдал юм. Бүхэл бүтэн компанийн түвшинд бүтээн байгуулалтын нийт зардлыг бууруулах хамгийн хялбар бөгөөд ойлгомжтой арга юм ердийн цуваа ажлуудыг гүйцэтгэх зардлыг багасгах үйлдвэрлэлийн бүх үе шатанд. Гэхдээ эдгээр үе шатууд юу вэ, тэдгээрийг ерөнхий үйл явцаас хэрхэн ялгах вэ, ямар үе шатуудаас бүрддэг вэ?
Компани нэг бүтээгдэхүүн боловсруулж байх үед бүх зүйл бага эсвэл тодорхой байдаг: ерөнхийдөө замын зураг, хөгжлийн схем байдаг. Гэхдээ бүтээгдэхүүний нэр төрөл нэмэгдэж, илүү олон бүтээгдэхүүн гарч ирэхэд яах вэ? Өнгөц харахад тэдгээр нь ижил төстэй үйл явц, угсрах шугамтай бөгөөд бүртгэл, скрипт дэх "X ялгааг олох" тоглоом эхэлдэг. Идэвхтэй хөгжиж буй 5+ төсөл байгаа бөгөөд хэдэн жилийн турш боловсруулсан хэд хэдэн хувилбарыг дэмжих шаардлагатай бол яах вэ? Бид бүтээгдэхүүний дамжуулах хоолойд аль болох олон шийдлийг дахин ашиглахыг хүсч байна уу эсвэл тус бүрийг өвөрмөц хөгжүүлэхэд мөнгө зарцуулахад бэлэн үү?
Өвөрмөц байдал болон цуврал шийдлүүдийн хоорондын тэнцвэрийг хэрхэн олох вэ?
Эдгээр асуултууд 2015 оноос хойш бидний өмнө улам бүр нэмэгдэж эхэлсэн. Бүтээгдэхүүний тоо нэмэгдэж, бид эдгээр бүтээгдэхүүний угсрах шугамыг дэмждэг автоматжуулалтын хэлтсээ (DevOps) хамгийн бага хэмжээнд хүртэл өргөжүүлэхийг хичээсэн. Үүний зэрэгцээ бид бүтээгдэхүүнүүдийн хооронд аль болох олон шийдлийг хуулбарлахыг хүссэн. Эцсийн эцэст, яагаад арван бүтээгдэхүүнд ижил зүйлийг өөр өөр аргаар хийдэг вэ?
Хөгжлийн захирал: "Залуус аа, бид DevOps бүтээгдэхүүнд юу хийдгийг ямар нэгэн байдлаар үнэлж чадах уу?"
Бид: "Бид мэдэхгүй, бид ийм асуулт асуугаагүй, гэхдээ ямар үзүүлэлтүүдийг анхаарч үзэх хэрэгтэй вэ?"
Хөгжлийн захирал: "Хэн мэдэх вэ! Бодоод үз дээ…”
Тэр алдартай кинон дээр гардаг шиг: "Би зочид буудалд байна! .." - "Өө ... Чи надад зам зааж өгч чадах уу?" Бодсоны дараа бид эхлээд бүтээгдэхүүний эцсийн төлөвийг шийдэх хэрэгтэй гэсэн дүгнэлтэд хүрсэн; энэ нь бидний анхны зорилго болсон.
Тэгэхээр, 10-200 хүнтэй нэлээд том багтай хэдэн арван бүтээгдэхүүнд дүн шинжилгээ хийж, шийдлийг хуулбарлахдаа хэмжигдэхүйц хэмжүүрийг хэрхэн тодорхойлох вэ?
1:0-ээр эмх замбараагүй байдал, эсвэл мөрний ирмэг дээр DevOps-ийг дэмжсэн
Бид BPwin цувралаас IDEF0 диаграм болон бизнесийн үйл явцын янз бүрийн диаграммуудыг ашиглах оролдлого хийж эхэлсэн. Төөрөгдөл нь дараагийн төслийн дараагийн шатны тав дахь квадратын дараа эхэлсэн бөгөөд төсөл бүрийн эдгээр квадратуудыг 50+ алхамын дор урт питоны сүүлэнд зурж болно. Би гунигтай санагдаж, саран дээр уйлахыг хүссэн - энэ нь ерөнхийдөө тохирохгүй байна.
Үйлдвэрлэлийн ердийн даалгавар
Үйлдвэрлэлийн процессыг загварчлах нь маш нарийн төвөгтэй бөгөөд шаргуу ажил юм: та янз бүрийн хэлтэс, үйлдвэрлэлийн сүлжээнээс маш их мэдээлэл цуглуулж, боловсруулж, дүн шинжилгээ хийх хэрэгтэй. Та энэ талаар дэлгэрэнгүйг нийтлэлээс уншиж болно "".
Бид үйлдвэрлэлийн үйл явцаа загварчилж эхлэхдээ компанийнхаа бүтээгдэхүүнийг боловсруулахад оролцож буй ажилтан бүр болон төслийн менежерүүдэд дараахь зүйлийг хэлэх гэсэн тодорхой зорилготой байсан.
- Бүтээгдэхүүн, тэдгээрийн бүрдэл хэсгүүд нь кодын мөрийн үйлдлээс эхлээд суулгагч, шинэчлэлтийн хэлбэрээр хэрэглэгчдэд хэрхэн хүрэх,
- бүтээгдэхүүн үйлдвэрлэх үе шат бүрт ямар нөөцөөр хангагдсан,
- үе шат бүрт ямар үйлчилгээ хамрагддаг,
- үе шат бүрийн хариуцах хүрээг хэрхэн заагласан,
- үе шат бүрийн орох, гарахад ямар гэрээ байдаг.
Зурган дээр дарвал бүрэн хэмжээгээр нээгдэнэ.
Компани дахь бидний ажил хэд хэдэн функциональ чиглэлд хуваагддаг. Дэд бүтцийн чиглэл нь хэлтсийн бүх "төмөр" нөөцийн үйл ажиллагааг оновчтой болгох, түүнчлэн виртуал машин, тэдгээрийн орчныг байрлуулах автоматжуулалтад чиглэгддэг. Хяналтын чиглэл нь 24/7 үйлчилгээний гүйцэтгэлийн хяналтыг өгдөг; Бид мөн хөгжүүлэгчдэд хяналт тавих үйлчилгээ үзүүлдэг. Ажлын урсгалын чиглэл нь багуудад хөгжүүлэлт, туршилтын үйл явцыг удирдах, кодын төлөв байдалд дүн шинжилгээ хийх, төслийн аналитик мэдээлэл авах хэрэгслүүдээр хангадаг. Эцэст нь, webdev чиглэл нь GUS болон FLUS шинэчлэлтийн серверүүд дээр хувилбаруудыг нийтлэх, мөн LicenseLab үйлчилгээг ашиглан бүтээгдэхүүний лицензийг олгодог. Үйлдвэрлэлийн шугамыг дэмжихийн тулд бид хөгжүүлэгчдэд зориулсан олон төрлийн дэмжлэг үзүүлэх үйлчилгээг бий болгож, засвар үйлчилгээ хийдэг (та тэдгээрийн заримын тухай түүхийг хуучин уулзалтууд дээр сонсож болно: и). Бид мөн дотоод автоматжуулалтын хэрэгслүүдийг боловсруулдаг .
Сүүлийн таван жилийн хугацаанд бидний ажилд ижил төрлийн, ердийн үйл ажиллагаанууд хуримтлагдсан бөгөөд бусад хэлтсийн хөгжүүлэгчид голчлон гэгддэг ердийн даалгавар, шийдэл нь бүрэн эсвэл хэсэгчлэн автоматжуулсан, жүжигчдэд хүндрэл учруулахгүй бөгөөд их хэмжээний ажил шаарддаггүй. Тэргүүлэх чиглэлүүдийн хамт бид ийм ажлуудад дүн шинжилгээ хийж, ажлын тусдаа ангиллыг тодорхойлох боломжтой болсон үйлдвэрлэлийн үе шатууд, үе шатууд нь хуваагдашгүй үе шатуудад хуваагдсан бөгөөд хэд хэдэн үе шатууд нийлдэг үйлдвэрлэлийн процессын гинжин.
Технологийн гинжин хэлхээний хамгийн энгийн жишээ бол компани доторх манай бүтээгдэхүүн бүрийг угсрах, байршуулах, турших үе шатууд юм. Жишээлбэл, бүтээх үе шат нь GitLab-аас эх сурвалжийг татаж авах, хамаарал болон гуравдагч талын номын санг бэлтгэх, нэгжийн туршилт болон статик кодын шинжилгээ, GitLab CI дээр бүтээх скриптийг гүйцэтгэх, олдворуудыг хадгалах санд нийтлэх зэрэг олон тусдаа стандарт алхмуудаас бүрдэнэ. Манай дотоод ChangelogBuilder хэрэгслээр дамжуулан хувилбарын тэмдэглэлүүдийг бүтээх, үүсгэх.
Та Habré дээрх манай бусад нийтлэлээс ердийн DevOps даалгаврын талаар уншиж болно: ""Мөн"".
Олон тооны ердийн үйлдвэрлэлийн сүлжээ үүсдэг үйлдвэрлэлийн үйл явц. Процессыг тайлбарлах стандарт арга бол функциональ IDEF0 загваруудыг ашиглах явдал юм.
Үйлдвэрлэлийн CI процессыг загварчлах жишээ
Тасралтгүй интеграцийн тогтолцооны стандарт төслүүдийг боловсруулахад бид онцгой анхаарал хандуулсан. Энэ нь төслүүдийг нэгтгэх боломжийг олгосон бөгөөд үүнийг онцлон тэмдэглэв урамшуулал бүхий бүтээх схемийг гаргах.
Энэ хэрхэн ажилладаг талаар эндээс үзнэ үү. Бүх төслүүд ердийн харагддаг: тэдгээрт Artifactory-ийн агшин зуурын агшинд багтах угсралтын тохиргоог багтаасан бөгөөд дараа нь тэдгээрийг туршилтын вандан сандал дээр байрлуулж, туршиж, дараа нь хувилбарын репозитор руу шилжүүлдэг. Artifactory үйлчилгээ нь баг болон бусад үйлчилгээний хооронд бүтээх бүх олдворыг түгээх нэг цэг юм.
Хэрэв бид хувилбарын схемээ ихээхэн хялбарчилж, ерөнхийд нь оруулбал дараахь үе шатуудыг багтаана.
- платформ хоорондын бүтээгдэхүүний угсралт,
- туршилтын вандан сандал дээр байрлуулах,
- функциональ болон бусад туршилтуудыг явуулах,
- Artifactory дахь агуулахуудыг гаргахын тулд туршсан бүтээцийг дэмжих,
- шинэчлэлтийн серверүүд дээр бүтээгдсэн хувилбаруудыг нийтлэх,
- угсралт, шинэчлэлтийг үйлдвэрлэлд хүргэх,
- бүтээгдэхүүнийг суурилуулах, шинэчлэх ажлыг эхлүүлэх.
Жишээ болгон, энэхүү ердийн хувилбарын схемийн технологийн загварыг (цаашид энгийн загвар гэх) функциональ IDEF0 загвар хэлбэрээр авч үзье. Энэ нь манай CI үйл явцын үндсэн үе шатуудыг тусгасан байдаг. IDEF0 загварууд гэж нэрлэгддэг загварыг ашигладаг ICOM тэмдэглэгээ (Оролт-Хяналт-Гаралт-Механизм) үе шат бүрт ямар нөөцийг ашиглаж байгаа, ямар дүрэм, шаардлагад тулгуурлан ажил гүйцэтгэж байгаа, гаралт гэж юу вэ, ямар механизм, үйлчилгээ эсвэл хүмүүс тодорхой үе шатыг хэрэгжүүлдэг талаар тайлбарлах.
Зурган дээр дарвал бүрэн хэмжээгээр нээгдэнэ.
Дүрмээр бол функциональ загварт үйл явцын тайлбарыг задалж, нарийвчлан тайлбарлах нь илүү хялбар байдаг. Гэвч элементүүдийн тоо нэмэгдэхийн хэрээр тэдгээрийн доторх ямар нэг зүйлийг ойлгоход улам хэцүү болдог. Гэхдээ бодит хөгжилд туслах үе шатууд байдаг: хяналт тавих, бүтээгдэхүүний баталгаажуулалт, ажлын процессыг автоматжуулах болон бусад. Энэ нь масштабын асуудлаас болж бид энэ тайлбарыг орхисон.
Итгэл найдварын төрөлт
Нэг номонд бид технологийн үйл явцыг дүрсэлсэн хуучин Зөвлөлтийн газрын зурагтай танилцсан (дашрамд хэлэхэд эдгээрийг өнөөдөр олон улсын үйлдвэр, их дээд сургуулиудад ашигладаг). Хүлээгээрэй, хүлээгээрэй, учир нь бидэнд бас ажлын урсгал бий!.. Үе шат, үр дүн, хэмжүүр, шаардлага, үзүүлэлт гэх мэт зүйлс бий... Яагаад манай бүтээгдэхүүний дамжуулах хоолойд урсгалын хүснэгтийг хэрэглэж болохгүй гэж? Нэг мэдрэмж төрж байсан: "Энэ бол! Бид зөв утсыг олсон, үүнийг сайн татах цаг болжээ!
Энгийн хүснэгтэд бид бүтээгдэхүүнийг баганаар, технологийн үе шатууд, бүтээгдэхүүний дамжуулах хоолойн үе шатуудыг эгнээгээр бүртгэхээр шийдсэн. Чухал үе бол бүтээгдэхүүн бүтээх алхам гэх мэт том зүйл юм. Мөн алхмууд нь эх кодыг бүтээх сервер рүү татаж авах эсвэл кодыг эмхэтгэх алхам гэх мэт жижиг бөгөөд илүү нарийвчилсан зүйл юм.
Газрын зургийн мөр, баганын огтлолцол дээр бид тодорхой үе шат, бүтээгдэхүүний статусыг тавьдаг. Статусуудын хувьд төлөв байдлын багцыг тодорхойлсон:
- Мэдээлэл алга байна - эсвэл тохиромжгүй. Бүтээгдэхүүний үе шатанд эрэлт хэрэгцээнд дүн шинжилгээ хийх шаардлагатай. Шинжилгээг аль хэдийн хийсэн, гэхдээ шат нь одоогоор шаардлагагүй эсвэл эдийн засгийн үндэслэлгүй байна.
- Хойшлуулсан - эсвэл одоогоор хамааралгүй. Дамжуулах хоолойн энэ үе шат шаардлагатай ч энэ жил хэрэгжүүлэх эрчим хүч алга.
- Төлөвлөсөн. Уг шатыг энэ онд хэрэгжүүлэхээр төлөвлөж байна.
- Хэрэгжүүлсэн. Шугам хоолой дахь үе шатыг шаардлагатай хэмжээгээр хэрэгжүүлдэг.
Төсөл тус бүрээр хүснэгтийг бөглөж эхэлсэн. Эхлээд нэг төслийн үе шат, үе шатыг ангилж, статусыг нь бүртгэсэн. Дараа нь тэд дараагийн төслийг авч, түүний статусыг засч, өмнөх төслүүдэд дутагдаж байсан үе шат, алхмуудыг нэмсэн. Үүний үр дүнд бид бүх үйлдвэрлэлийн шугам хоолойн үе шат, үе шат, тэдгээрийн статусыг тодорхой төсөлд тусгасан болно. Энэ нь бүтээгдэхүүний дамжуулах хоолойн чадамжийн матрицтай төстэй зүйл болсон. Ийм матрицыг бид технологийн газрын зураг гэж нэрлэсэн.
Технологийн газрын зургийн тусламжтайгаар бид тухайн жилийн ажлын төлөвлөгөө, хамтдаа хүрэхийг хүсч буй зорилтуудаа багуудтай хэмжилзүйн хувьд үндэслэлтэй уялдуулдаг: энэ онд төсөлд аль үе шатыг нэмж, алийг нь дараа нь үлдээх вэ. Мөн ажлын явцад бид зөвхөн нэг бүтээгдэхүүнээр дуусгасан үе шатуудад сайжруулалт хийж магадгүй юм. Дараа нь бид газрын зурагаа өргөжүүлж, энэ сайжруулалтыг үе шат эсвэл шинэ алхам болгон нэвтрүүлж, бүтээгдэхүүн тус бүрээр дүн шинжилгээ хийж, сайжруулалтыг давтах боломжийг олж авдаг.
Тэд биднийг эсэргүүцэж магадгүй: "Энэ бүхэн мэдээжийн хэрэг сайн байна, зөвхөн цаг хугацаа өнгөрөхөд алхам, үе шатуудын тоо маш их байх болно. Яаж байх вэ?
Бид шат дамжлага тус бүрийн стандарт, бүрэн гүйцэд шаардлагуудын тодорхойлолтыг танилцуулсан бөгөөд ингэснээр компани дотроо хүн бүрт ижилхэн ойлгомжтой байх болно. Цаг хугацаа өнгөрөхөд сайжруулалт хийснээр алхам нь өөр шат эсвэл шат руу шингэж магадгүй - дараа нь тэд нурах болно. Үүний зэрэгцээ, бүх шаардлага, технологийн нюансууд нь ерөнхийлэх үе шат эсвэл алхамын шаардлагад нийцдэг.
Хуулбарлах шийдлүүдийн үр нөлөөг хэрхэн үнэлэх вэ? Бид маш энгийн аргыг ашигладаг: шинэ үе шатыг хэрэгжүүлэх анхны хөрөнгийн зардлыг жилийн ерөнхий бүтээгдэхүүний өртөгт хамааруулж, дараа нь хуулбарлахдаа бүгдэд нь хуваадаг.
Бүтээн байгуулалтын зарим хэсгийг газрын зураг дээр үе шат, үе шат болгон харуулсан байна. Бид ердийн үе шатуудад автоматжуулалтыг нэвтрүүлэх замаар бүтээгдэхүүний өртгийг бууруулахад нөлөөлж чадна. Үүний дараа бид чанарын шинж чанар, тоон хэмжигдэхүүн, багуудын олж авсан ашгийн өөрчлөлтийг (хүн-цаг эсвэл машин-цаг хэмнэлтээр) авч үздэг.
Үйлдвэрлэлийн процессын технологийн зураг
Хэрэв бид бүх үе шат, алхмуудыг хийж, тэдгээрийг хаягуудаар кодлож, нэг гинж болгон өргөжүүлбэл энэ нь маш урт бөгөөд ойлгомжгүй болно (энэ өгүүллийн эхэнд бидний ярьсан яг ижил "питон сүүл") :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]Эдгээр нь бүтээгдэхүүн бүтээх [Бүтээгдэхүүний], тэдгээрийг туршилтын серверт байрлуулах [Байршуулах], турших [Туршилт], туршилтын үр дүнд үндэслэн хадгалах сангуудыг гаргахын тулд бүтээхийг дэмжих [Дэмжих], лиценз үүсгэх, нийтлэх [Лиценз], нийтлэх үе шатууд юм. GUS шинэчлэлтийн сервер дээр нийтэлж, FLUS шинэчлэлтийн серверт хүргэх, Бүтээгдэхүүний тохиргооны менежмент [Суулгах] ашиглан хэрэглэгчийн дэд бүтцэд бүтээгдэхүүний бүрэлдэхүүн хэсгүүдийг суурилуулах, шинэчлэх, мөн суулгасан бүтээгдэхүүнээс телеметрийн [Телеметрийн] цуглуулга.
Эдгээрээс гадна тусдаа үе шатуудыг ялгаж болно: дэд бүтцийн төлөв байдлын хяналт [InfMonitoring], эх кодын хувилбар гаргах [SourceCodeControl], хүрээлэн буй орчны бэлтгэл [Бэлтгэл], төслийн менежмент [Ажлын урсгал], багийг харилцааны хэрэгслээр хангах [Харилцаа], бүтээгдэхүүний баталгаажуулалт [ Баталгаажуулалт] ба CI процессуудын бие даасан байдлыг хангах [CISelfSufficiency] (жишээлбэл, угсралтын интернетээс хараат бус байдал). Бидний үйл явцын олон арван алхамыг авч үзэхгүй, учир нь тэдгээр нь маш тодорхой байдаг.
Хэрэв та үүнийг хэлбэрээр төсөөлвөл үйлдвэрлэлийн үйл явцыг бүхэлд нь ойлгох, харахад илүү хялбар байх болно технологийн газрын зураг; Энэ бол Загварын бие даасан үйлдвэрлэлийн үе шатууд болон задарсан алхмуудыг мөр болгон бичсэн хүснэгт бөгөөд үе шат, алхам бүр дээр юу хийснийг тайлбарласан багананд бичнэ. Гол ач холбогдол нь үе шат бүрийг хангах нөөц, хариуцлагын бүсийг зааглахад чиглэгддэг.
Бидний хувьд газрын зураг бол нэг төрлийн ангилагч юм. Энэ нь бүтээгдэхүүний үйлдвэрлэлийн томоохон технологийн хэсгүүдийг тусгасан байдаг. Үүний ачаар манай автоматжуулалтын баг хөгжүүлэгчидтэй харилцах, автоматжуулалтын үе шатуудыг хэрэгжүүлэх ажлыг хамтран төлөвлөхөөс гадна үүнд ямар хөдөлмөрийн зардал, нөөц (хүний болон техник хангамж) шаардагдахыг ойлгоход хялбар болсон.
Манай компани дотор газрын зургийг jinja загвараас ердийн HTML файл болгон автоматаар үүсгэж, GitLab Pages серверт байршуулдаг. Бүрэн бүтээгдсэн газрын зургийн жишээ бүхий дэлгэцийн агшинг үзэх боломжтой .
Зурган дээр дарвал бүрэн хэмжээгээр нээгдэнэ.
Товчоор хэлбэл, технологийн газрын зураг нь ердийн функцтэй, тодорхой ангилагдсан блокуудыг тусгасан үйлдвэрлэлийн үйл явцын ерөнхий дүр зураг юм.
Манай замын газрын зураг бүтэц
Газрын зураг нь хэд хэдэн хэсгээс бүрдэнэ.
- Гарчгийн хэсэг - энд газрын зургийн ерөнхий тодорхойлолт, үндсэн ойлголтуудыг танилцуулж, үйлдвэрлэлийн үйл явцын үндсэн нөөц, үр дүнг тодорхойлсон болно.
- Мэдээллийн самбар - энд та бие даасан бүтээгдэхүүний мэдээллийн дэлгэцийг хянах боломжтой бөгөөд бүх бүтээгдэхүүний хэрэгжүүлсэн үе шат, алхмуудын хураангуйг өгсөн болно.
- Технологийн зураг - технологийн процессын хүснэгтийн тодорхойлолт. Газрын зураг дээр:
- бүх үе шат, үе шат, тэдгээрийн кодыг өгсөн;
- үе шатуудын товч бөгөөд бүрэн тайлбарыг өгсөн;
- үе шат бүрт ашигласан оролтын нөөц, үйлчилгээг зааж өгсөн;
- үе шат бүрийн үр дүн, тусдаа алхамыг зааж өгсөн болно;
- үе шат, үе шат бүрийн хариуцлагын бүсийг зааж өгсөн;
- HDD (SSD), RAM, vCPU зэрэг техникийн нөөц, энэ үе шатанд ажлыг дэмжихэд шаардагдах ажлын цаг, одоогийн баримт, ирээдүйд - төлөвлөгөөг тодорхойлсон;
- Бүтээгдэхүүн тус бүрийн хувьд технологийн аль шат, үе шат хэрэгжсэн, хэрэгжүүлэхээр төлөвлөсөн, хамааралгүй, хэрэгжээгүй зэргийг зааж өгсөн болно.
Технологийн зураг дээр үндэслэн шийдвэр гаргах
Газрын зургийг судалсны дараа та ажилтны компанид гүйцэтгэх үүрэг (хөгжлийн менежер, бүтээгдэхүүний менежер, хөгжүүлэгч эсвэл шалгагч) -аас хамааран зарим арга хэмжээ авч болно.
- бодит бүтээгдэхүүн, төсөлд ямар үе шат дутагдаж байгааг ойлгох, тэдгээрийг хэрэгжүүлэх хэрэгцээг үнэлэх;
- Хэд хэдэн хэлтэс өөр өөр үе шатанд ажиллаж байгаа бол тэдгээрийн хоорондын хариуцлагын хүрээг хязгаарлах;
- шатуудын орц, гарц дээр гэрээг тохиролцох;
- ажлынхаа үе шатыг ерөнхий хөгжлийн үйл явцад нэгтгэх;
- үе шат бүрийг хангах нөөцийн хэрэгцээг илүү нарийвчлалтай үнэлэх.
Дээр дурдсан бүх зүйлийг нэгтгэн дүгнэв
Маршрут нь олон талт, өргөтгөх боломжтой, засвар үйлчилгээ хийхэд хялбар байдаг. Хатуу академик IDEF0 загвараас илүү энэ хэлбэрээр үйл явцын тодорхойлолтыг боловсруулж, хадгалах нь илүү хялбар байдаг. Нэмж дурдахад, хүснэгтийн тайлбар нь функциональ загвараас илүү энгийн, илүү танил, бүтэцтэй байдаг.
Алхамуудын техникийн хэрэгжилтийн хувьд бид CrossBuilder тусгай дотоод хэрэгсэлтэй - CI систем, үйлчилгээ, дэд бүтцийн хоорондох давхаргын хэрэгсэл юм. Хөгжүүлэгч нь дугуйгаа огтлох шаардлагагүй: манай CI системд манай дэд бүтцийн онцлогийг харгалзан CrossBuilder хэрэгслийн скриптүүдийн аль нэгийг (даалгавар гэж нэрлэгддэг) ажиллуулахад хангалттай бөгөөд энэ нь үүнийг зөв гүйцэтгэх болно. .
Үр дүн
Нийтлэл нэлээд урт байсан боловч нарийн төвөгтэй үйл явцын загварчлалыг тайлбарлахдаа энэ нь зайлшгүй юм. Эцэст нь би үндсэн санаагаа товчхон хэлмээр байна.
- Манай компанид DevOps санааг нэвтрүүлэх зорилго нь компанийн бүтээгдэхүүний үйлдвэрлэл, засвар үйлчилгээний зардлыг тоон үзүүлэлтээр (хүн-цаг эсвэл машин-цаг, vCPU, RAM, Диск) тогтмол бууруулах явдал юм.
- Технологийн үйл явцын үе шат, үе шатууд болох стандарт цуваа даалгавруудыг гүйцэтгэх зардлыг багасгах нь хөгжлийн нийт зардлыг бууруулах арга зам юм.
- Ердийн даалгавар бол шийдэл нь бүрэн эсвэл хэсэгчлэн автоматжуулсан, гүйцэтгэгчдэд хүндрэл учруулдаггүй, их хэмжээний хөдөлмөрийн зардал шаарддаггүй ажил юм.
- Үйлдвэрлэлийн үйл явц нь үе шатуудаас бүрдэх бөгөөд үе шатууд нь хуваагдашгүй үе шатуудад хуваагддаг бөгөөд энэ нь янз бүрийн цар хүрээ, эзэлхүүний ердийн ажлуудыг илэрхийлдэг.
- Ялгаагүй ердийн ажлуудаас бид нарийн төвөгтэй технологийн хэлхээ, үйлдвэрлэлийн үйл явцын олон түвшний загварт хүрсэн бөгөөд үүнийг функциональ IDEF0 загвар эсвэл илүү энгийн технологийн газрын зургаар дүрсэлж болно.
- Урсгал диаграм нь үйлдвэрлэлийн үйл явцын үе шат, үе шатуудыг хүснэгт хэлбэрээр дүрсэлсэн дүрслэл юм. Хамгийн чухал нь: газрын зураг нь бүх үйл явцыг бүхэлд нь, том хэсгүүдээр нь нарийвчлан харуулах боломжийг олгодог.
- Технологийн зураглал дээр үндэслэн тодорхой бүтээгдэхүүнд үе шатыг нэвтрүүлэх хэрэгцээг үнэлэх, хариуцах чиглэлийг тодорхойлох, үе шатуудын орц, гарц дээр гэрээг тохиролцох, нөөцийн хэрэгцээг илүү нарийвчлалтай үнэлэх боломжтой.
Дараах нийтлэлүүдэд бид газрын зураг дээр технологийн тодорхой үе шатуудыг хэрэгжүүлэхэд ямар техникийн хэрэгслийг ашигладаг талаар илүү дэлгэрэнгүй тайлбарлах болно.
Нийтлэлийн зохиогчид:
- — Positive Technologies-ийн Автоматжуулалтын хэлтсийн дарга (DevOps).
- - Орлогч Positive Technologies-ийн Автоматжуулалтын хэлтсийн дарга (DevOps).
Эх сурвалж: www.habr.com