DevOps нь сүүлийн хэдэн жилийн турш маш алдартай сэдэв болсон. Олон хүмүүс үүнд элсэхийг мөрөөддөг боловч практикээс харахад зөвхөн цалингийн түвшингээс л шалтгаална.
Зарим хүмүүс энэ нэр томъёоны мөн чанарыг тэр бүр мэддэггүй, ойлгодоггүй ч гэсэн DevOps-ийг намтар дээрээ жагсаасан байдаг. Зарим хүмүүс Ansible, GitLab, Jenkins, Terraform гэх мэтийг (жагсаалтыг таны амтанд нийцүүлэн үргэлжлүүлж болно) судалсны дараа шууд "devopsist" болно гэж боддог. Энэ нь мэдээжийн хэрэг үнэн биш юм.
Сүүлийн хэдэн жилийн турш би янз бүрийн компаниудад DevOps-ийг хэрэгжүүлэх ажилд голчлон оролцсон. Үүнээс өмнө тэрээр системийн администратороос мэдээллийн технологийн захирал хүртэл 20 гаруй жил ажилласан. Одоогоор Playgendary-д DevOps-ийн ахлах инженер.
DevOps гэж хэн бэ
"DevOps гэж хэн бэ?" Гэсэн өөр нэг асуултын дараа нийтлэл бичих санаа төрсөн. Энэ нь юу вэ, хэн бэ гэдгийг тогтоосон нэр томъёо хараахан гараагүй байна. Зарим хариултууд энд байна . Эхлээд би үүнээс гол санааг онцолж, дараа нь ажиглалт, бодлоо хуваалцах болно.
DevOps бол ажилд авах мэргэжилтэн биш, олон нийтийн хэрэгсэл биш, инженерүүдтэй хөгжүүлэгчдийн хэлтэс биш юм.
DevOps бол философи, арга зүй юм.
Өөрөөр хэлбэл, энэ нь хөгжүүлэгчид системийн администраторуудтай идэвхтэй харилцахад тусалдаг практикийн багц юм. Энэ нь ажлын процессуудыг хооронд нь холбож, нэгтгэх явдал юм.
DevOps гарч ирснээр мэргэжилтнүүдийн бүтэц, үүрэг ижил хэвээр байсан (хөгжүүлэгчид байдаг, инженерүүд байдаг), гэхдээ харилцан үйлчлэлийн дүрэм өөрчлөгдсөн. Хэлтсийн хоорондын хил хязгаар бүдгэрч байна.
DevOps-ийн зорилгыг гурван зүйлээр тодорхойлж болно.
- Програм хангамжийг байнга шинэчилж байх ёстой.
- Програм хангамжийг хурдан хийх ёстой.
- Програм хангамжийг хялбар, богино хугацаанд ашиглах ёстой.
DevOps-д зориулсан ганц хэрэгсэл байхгүй. Хэд хэдэн бүтээгдэхүүнийг тохируулах, хүргэх, судлах нь DevOps компанид гарч ирсэн гэсэн үг биш юм. Маш олон хэрэгсэл байдаг бөгөөд тэдгээр нь бүгд өөр өөр үе шатанд ашиглагддаг боловч нэг нийтлэг зорилгод үйлчилдэг.
Энэ бол DevOps хэрэгслүүдийн зөвхөн нэг хэсэг юм
Би DevOps инженерийн албан тушаалд 2 жил гаруй хүмүүстэй ярилцлага хийж байгаа бөгөөд энэ нэр томъёоны мөн чанарыг тодорхой ойлгох нь хичнээн чухал болохыг ойлгосон. Би хуваалцахыг хүссэн тодорхой туршлага, ажиглалт, бодол санаагаа хуримтлуулсан.
Ярилцлагын туршлагаас би дараах зургийг харж байна. DevOps-ийг ажлын байр гэж үздэг мэргэжилтнүүд ихэвчлэн хамт ажиллагсадтайгаа үл ойлголцдог.
Гайхалтай жишээ байсан. Нэг залуу ярилцлагандаа маш их ухаалаг үгсийг анкет дээрээ бичжээ. Сүүлийн гурван ажилдаа 5-6 сар ажилласан туршлагатай. Би хоёр гарааны бизнесээ "хөөрөөгүй" учраас орхисон. Гэхдээ гурав дахь компанийн тухайд тэрээр түүнийг тэнд хэн ч ойлгохгүй гэж хэлэв: хөгжүүлэгчид Windows дээр код бичдэг бөгөөд захирал нь энэ кодыг ердийн Docker-д "боож", CI/CD дамжуулах хоолойд оруулахыг албаддаг. Тэр залуу одоогийн ажлын газар болон хамт ажиллагсдынхаа талаар маш их сөрөг зүйл хэлсэн - Би зүгээр л "Та заан зарахгүй" гэж хариулахыг хүссэн.
Дараа нь би түүнээс нэр дэвшигч бүрийн жагсаалтад багтсан асуултыг асуув.
— Таны хувьд DevOps ямар утгатай вэ?
-Ер нь эсвэл би яаж хүлээж авч байна вэ?
Би түүний хувийн бодлыг сонирхсон. Тэрээр энэ нэр томъёоны онол, гарал үүслийг мэддэг байсан ч тэдэнтэй эрс санал нийлэхгүй байв. Тэрээр DevOps бол ажлын байр гэж итгэж байсан. Энд л түүний асуудлын үндэс оршдог. Үүнтэй адил санал бодолтой бусад мэргэжилтнүүд.
"DevOps-ийн ид шид"-ийн талаар маш их сонссон ажил олгогчид ирж, энэ "ид шид"-ийг бүтээх хүнийг хайж олохыг хүсдэг. "DevOps бол ажил" ангиллын өргөдөл гаргагчид ийм хандлагаар хүлээлтийг хангаж чадахгүй гэдгийг ойлгохгүй байна. Ерөнхийдөө тэд DevOps-ийг анкет дээрээ бичсэн, учир нь энэ нь чиг хандлага бөгөөд үүний төлөө тэд маш их мөнгө төлдөг.
DevOps арга зүй ба философи
Арга зүй нь онолын болон практик байж болно. Манай тохиолдолд энэ нь хоёр дахь нь юм. Миний дээр дурдсанчлан DevOps бол зорилгодоо хүрэхийн тулд ашигладаг дадлага, стратегийн багц юм. Тухайн тохиолдол бүрт компанийн бизнесийн үйл явцаас хамааран энэ нь ихээхэн ялгаатай байж болно. Энэ нь үүнийг илүү сайн эсвэл дордуулдаггүй.
DevOps арга зүй нь зөвхөн зорилгодоо хүрэх хэрэгсэл юм.
Одоо DevOps философи гэж юу болох талаар. Мөн энэ нь магадгүй хамгийн хэцүү асуулт юм.
Одоогоор албан ёсоор батлагдаагүй байгаа тул товч бөгөөд товч хариултыг томъёолоход нэлээд хэцүү байдаг. DevOps гүн ухааныг баримтлагчид практикт илүү идэвхтэй оролцдог тул философи хийх цаг байдаггүй. Гэсэн хэдий ч энэ бол маш чухал үйл явц юм. Тэгээд ч инженерийн үйл ажиллагаатай шууд холбоотой. Мэдлэгийн тусгай талбар ч байдаг - .
Манай их сургуульд тийм хичээл байгаагүй, би 90-ээд оны үед олдсон материалаа ашиглан бүгдийг өөрөө судлах ёстой байсан. Сэдэв нь инженерийн боловсролын хувьд сонголттой тул хариулт нь албан ёсны бус байна. Гэхдээ DevOps-д нухацтай шингэсэн хүмүүс компанийн бүх үйл явцын тодорхой "сүнс" эсвэл "ухамсаргүй цогц байдлыг" мэдэрч эхэлдэг.
Би өөрийн туршлагаа ашиглан энэ гүн ухааны зарим "постулатын"-ыг албан ёсоор гаргахыг оролдсон. Үр дүн нь дараах байдалтай байна.
- DevOps бол мэдлэг, үйл ажиллагааны тусдаа хэсэгт салгаж болох бие даасан зүйл биш юм.
- Компанийн бүх ажилчид үйл ажиллагаагаа төлөвлөхдөө DevOps аргачлалыг удирдан чиглүүлэх ёстой.
- DevOps нь компанийн бүх үйл явцад нөлөөлдөг.
- DevOps нь үйлчилгээгээ хөгжүүлэх, үйлчлүүлэгчийн тав тухыг дээд зэргээр хангахын тулд компани доторх аливаа үйл явцын цаг хугацааны зардлыг бууруулах зорилготой юм.
- Орчин үеийн хэлээр бол DevOps бол цаг хугацааны зардлыг бууруулах, бидний эргэн тойронд байгаа мэдээллийн технологийн бүтээгдэхүүний чанарыг сайжруулахад чиглэсэн компанийн ажилтан бүрийн идэвхтэй байр суурь юм.
Миний "постулууд" бол тусдаа хэлэлцэх сэдэв гэж би бодож байна. Харин одоо ямар нэгэн зүйл дээр тулгуурлах зүйл байна.
DevOps юу хийдэг
Энд гол үг бол харилцаа холбоо юм. Маш олон харилцаа холбоо байдаг бөгөөд үүнийг санаачлагч нь яг ижил DevOps инженер байх ёстой. Яагаад тэр вэ? Учир нь энэ бол философи, арга зүй, тэгээд л инженерийн мэдлэг юм.
Барууны хөдөлмөрийн зах зээлийн талаар би 100% итгэлтэй ярьж чадахгүй. Гэхдээ би Оросын DevOps зах зээлийн талаар маш их зүйлийг мэддэг. Олон зуун ярилцлагаас гадна сүүлийн жил хагасын хугацаанд би Оросын томоохон компани, банкуудад зориулсан "DevOps-ийг хэрэгжүүлэх" үйлчилгээний олон зуун техникийн урьдчилсан худалдаанд оролцсон.
Орос улсад DevOps нь маш залуу, гэхдээ аль хэдийн чиг хандлагатай сэдэв хэвээр байна. Миний мэдэж байгаагаар зөвхөн Москвад ийм мэргэжилтнүүдийн дутагдал 2019 онд 1000 гаруй хүн байсан. Мөн ажил олгогчдод зориулсан Кубернетес гэдэг үг бараг л бухын улаан өөдөстэй адил юм. Энэ хэрэгслийг дагаж мөрддөг хүмүүс үүнийг шаардлагагүй, эдийн засгийн хувьд ашигтай газар ч ашиглахад бэлэн байна. Ажил олгогч нь ямар тохиолдолд юуг ашиглах нь илүү тохиромжтой болохыг тэр бүр ойлгодоггүй бөгөөд зөв байршуулснаар Kubernetes кластерыг хадгалах нь ердийн кластер схемийг ашиглан програм байрлуулахаас 2-3 дахин их зардал шаарддаг. Танд үнэхээр хэрэгтэй газар хэрэглээрэй.
DevOps-ийг хэрэгжүүлэх нь мөнгөний хувьд үнэтэй байдаг. Мөн дангаараа бус бусад салбарт эдийн засгийн үр өгөөжөө өгч байгаа тохиолдолд л зөвтгөгддөг.
DevOps инженерүүд бол үнэндээ анхдагчид бөгөөд тэд компанид энэ аргачлалыг хамгийн түрүүнд хэрэгжүүлж, үйл явцыг бий болгох ёстой хүмүүс юм. Үүнийг амжилттай хэрэгжүүлэхийн тулд мэргэжилтэн бүх түвшний ажилчид, хамт олонтой байнга харилцаж байх ёстой. Миний хэлдэгчлэн компанийн бүх ажилчид DevOps-ийг хэрэгжүүлэх үйл явцад оролцох ёстой: цэвэрлэгчээс эхлээд гүйцэтгэх захирал хүртэл. Мөн энэ бол урьдчилсан нөхцөл юм. Хэрэв багийн хамгийн залуу гишүүн DevOps гэж юу болох, зохион байгуулалтын тодорхой арга хэмжээ яагаад хийгддэгийг мэдэхгүй, ойлгодоггүй бол амжилттай хэрэгжүүлэх нь үр дүнд хүрэхгүй.
Мөн DevOps инженер үе үе захиргааны нөөц ашиглах шаардлагатай болдог. Жишээлбэл, баг нь DevOps хэрэгсэл, аргачлалыг хүлээн авахад бэлэн биш байх үед "байгаль орчны эсэргүүцлийг" даван туулах.
Хөгжүүлэгч нь зөвхөн код болон тест бичих ёстой. Үүнийг хийхийн тулд түүнд төслийн дэд бүтцийг бүхэлд нь байрлуулж, орон нутгийн хэмжээнд дэмжих супер хүчирхэг зөөврийн компьютер хэрэггүй. Жишээлбэл, урд талын хөгжүүлэгчид мэдээллийн сан, S3 эмулятор (minio) гэх мэт програмын бүх элементүүдийг зөөврийн компьютер дээрээ хадгалдаг. Өөрөөр хэлбэл, тэрээр орон нутгийн дэд бүтцийг хадгалахад маш их цаг зарцуулж, ийм шийдлийн бүх асуудалтай ганцаараа тэмцэж байна. Урд талын кодыг боловсруулахын оронд. Ийм хүмүүс аливаа өөрчлөлтөд маш тэсвэртэй байж чаддаг.
Харин эсрэгээрээ шинэ арга хэрэгсэл, арга хэрэгсэл нэвтрүүлж, энэ үйл явцад идэвхтэй оролцож байгаадаа баяртай байдаг багууд байдаг. Хэдийгээр энэ тохиолдолд ч гэсэн DevOps-ийн инженер болон багийн хоорондох харилцаа холбоо цуцлагдаагүй.
DevOps шаардлагагүй үед
DevOps шаардлагагүй нөхцөл байдал байдаг. Энэ бол баримт юм - үүнийг ойлгож, хүлээн зөвшөөрөх хэрэгтэй.
Юуны өмнө, энэ нь аливаа компанид (ялангуяа жижиг бизнес эрхлэгчдэд) хамаатай бөгөөд тэдний ашиг нь үйлчлүүлэгчдэд мэдээллийн үйлчилгээ үзүүлдэг мэдээллийн технологийн бүтээгдэхүүн байгаа эсэхээс шууд хамаардаггүй. Энд бид компанийн вэбсайтын тухай яриагүй байна, энэ нь статик "нэрийн хуудас" эсвэл динамик мэдээний блок гэх мэт.
Үйлчлүүлэгчийн тань сэтгэл ханамж, тан руу буцаж ирэх хүсэл нь үйлчлүүлэгчтэй харилцах эдгээр мэдээллийн үйлчилгээний хүртээмж, чанар, зорилтот байдлаас шалтгаалбал DevOps шаардлагатай.
Үүний тод жишээ бол алдартай банк юм. Тус компани нь уламжлалт үйлчлүүлэгчийн оффисгүй, баримт бичгийн урсгалыг шуудангаар эсвэл шуудангаар явуулдаг бөгөөд олон ажилчид гэрээсээ ажилладаг. Тус компани зүгээр нэг банк байхаа больж, миний бодлоор хөгжингүй DevOps технологи бүхий мэдээллийн технологийн компани болж хувирсан.
Бусад олон жишээ, лекцийг сэдэвчилсэн уулзалт, хурлын бичлэгээс олж болно. Би тэдний заримд нь биечлэн очиж үзсэн - энэ нь энэ чиглэлээр хөгжихийг хүсч буй хүмүүст маш хэрэгтэй туршлага юм. DevOps дээрх сайн лекц, материал бүхий YouTube сувгуудын холбоосууд энд байна:
Одоо бизнесээ хараад энэ талаар бодоорой: Танай компани болон түүний ашиг нь хэрэглэгчийн харилцан үйлчлэлийг идэвхжүүлэхийн тулд мэдээллийн технологийн бүтээгдэхүүнээс хэр хамааралтай вэ?
Хэрэв танай компани жижиг дэлгүүрт загас зардаг бол мэдээллийн технологийн цорын ганц бүтээгдэхүүн нь хоёр 1С: Аж ахуйн нэгжийн тохиргоо (Нягтлан бодох бүртгэл ба UNF) бол DevOps-ийн талаар ярих нь утгагүй юм.
Хэрэв та томоохон худалдаа, үйлдвэрлэлийн байгууллагад ажилладаг бол (жишээлбэл, ан агнуурын буу үйлдвэрлэдэг) энэ талаар бодох хэрэгтэй. Та санаачлагыг гартаа авч, DevOps-ийг хэрэгжүүлэх хэтийн төлөвийг удирдлагадаа дамжуулж болно. За, үүнтэй зэрэгцэн энэ үйл явцыг удирдаарай. Идэвхтэй байр суурь бол DevOps философийн чухал зарчмуудын нэг юм.
Жилийн санхүүгийн эргэлтийн хэмжээ, хэмжээ нь танай компанид DevOps хэрэгтэй эсэхийг тодорхойлох гол шалгуур биш юм.
Хэрэглэгчидтэй шууд харьцдаггүй томоохон аж үйлдвэрийн аж ахуйн нэгжийг төсөөлье. Жишээлбэл, зарим автомашин үйлдвэрлэгчид болон автомашины үйлдвэрүүд. Би одоо сайн мэдэхгүй байна, гэхдээ миний өнгөрсөн туршлагаас харахад олон жилийн турш бүх харилцагчийн харилцаа имэйл болон утсаар хийгдсэн.
Тэдний үйлчлүүлэгчид бол автомашины дилерүүдийн хязгаарлагдмал жагсаалт юм. Мөн тус бүрийг үйлдвэрлэгчээс мэргэжилтэн томилдог. Бүх дотоод баримт бичгийн урсгал SAP ERP-ээр дамждаг. Дотоод ажилтнууд нь үндсэндээ мэдээллийн системийн үйлчлүүлэгчид байдаг. Гэхдээ энэ IS нь кластерийн системийг удирдах сонгодог арга хэрэгслээр удирддаг. Энэ нь DevOps практикийг ашиглах боломжийг үгүйсгэдэг.
Эндээс дүгнэлт: Хэрэв бид өгүүллийн эхнээс арга зүйн зорилгыг эргэн санавал ийм аж ахуйн нэгжүүдийн хувьд DevOps-ийг хэрэгжүүлэх нь тийм ч чухал зүйл биш юм. Гэхдээ тэд өнөөдөр зарим DevOps хэрэгслийг ашигладаг байхыг би үгүйсгэхгүй.
Нөгөөтэйгүүр, DevOps арга зүй, философи, практик, хэрэгслийг ашиглан программ хангамж хөгжүүлдэг олон жижиг компаниуд байдаг. Мөн тэд DevOps-ийг хэрэгжүүлэх зардал нь програм хангамжийн зах зээлд үр дүнтэй өрсөлдөх боломжийг олгодог зардал гэж тэд үзэж байна. Ийм компаниудын жишээг харж болно .
DevOps хэрэгтэй эсэхийг ойлгох гол шалгуур бол таны мэдээллийн технологийн бүтээгдэхүүн компани болон үйлчлүүлэгчдэд ямар үнэ цэнэтэй вэ.
Компанийн ашиг олдог гол бүтээгдэхүүн нь програм хангамж юм бол танд DevOps хэрэгтэй. Хэрэв та бусад бүтээгдэхүүн ашиглан жинхэнэ мөнгө олох нь тийм ч чухал биш юм. Үүнд онлайн дэлгүүрүүд эсвэл тоглоомтой гар утасны програмууд орно.
Санхүүжилтийн ачаар аливаа тоглоом бий: тоглогчдын шууд болон шууд бус. Playgendary дээр бид 200 гаруй хүний оролцоотойгоор үнэ төлбөргүй гар утасны тоглоом бүтээдэг. Бид DevOps-ийг хэрхэн ашигладаг вэ?
Тийм ээ, дээр дурдсантай яг адилхан. Би хөгжүүлэгчид болон тестерүүдтэй байнга харилцаж, DevOps арга зүй, хэрэгслийн талаар ажилчдад дотоод сургалт явуулдаг.
Одоо бид Женкинсийг Unity-тэй бүх угсралтын шугамыг гүйцэтгэх, дараа нь App Store болон Play Market-т байршуулах CI/CD дамжуулах хэрэгсэл болгон идэвхтэй ашиглаж байна. Сонгодог хэрэгслийн багцаас дэлгэрэнгүй:
- Асана - төслийн менежментэд зориулагдсан. Женкинстэй нэгтгэх тохиргоо хийгдсэн.
- Google Meet - видео уулзалтад зориулагдсан.
- Slack - харилцаа холбоо, янз бүрийн сэрэмжлүүлэг, түүний дотор Женкинсийн мэдэгдлүүдэд зориулагдсан.
- Atlassian Confluence - баримт бичиг, бүлгийн ажилд зориулагдсан.
Бидний ойрын төлөвлөгөөнд SonarQube ашиглан статик кодын шинжилгээг нэвтрүүлэх, тасралтгүй интеграцийн үе шатанд Selenium ашиглан автоматжуулсан UI тест хийх зэрэг орно.
Оронд дүгнэлтийг
Би дараах бодлоор төгсөхийг хүсч байна: өндөр мэргэшсэн DevOps инженер болохын тулд хүмүүстэй хэрхэн шууд харилцаж сурах нь амин чухал юм.
DevOps инженер бол багийн тоглогч юм. Тэгээд өөр юу ч биш. Хамтран ажиллагсадтайгаа харилцах санаачлага нь зарим нөхцөл байдлын нөлөөн дор биш харин түүнээс гарах ёстой. DevOps-ийн мэргэжилтэн нь багийн хамгийн сайн шийдлийг харж, санал болгох ёстой.
Тийм ээ, аливаа шийдлийг хэрэгжүүлэхэд маш их хэлэлцүүлэг шаардагдах бөгөөд эцэст нь энэ нь бүхэлдээ өөрчлөгдөж магадгүй юм. Бие даан хөгжиж, санаагаа дэвшүүлж, хэрэгжүүлдэг ийм хүн баг болон ажил олгогчийн хувьд үнэ цэнийг нэмэгдүүлдэг. Энэ нь эцэстээ түүний сарын цалингийн хэмжээ эсвэл нэмэлт урамшуулал хэлбэрээр тусгагдсан болно.
Эх сурвалж: www.habr.com