DevOps-ийн тодорхойлолт нь маш нарийн төвөгтэй тул бид энэ тухай бүр дахин дахин ярилцах хэрэгтэй болдог. Зөвхөн Хабре дээр энэ сэдвээр мянга мянган нийтлэл байдаг. Гэхдээ хэрэв та үүнийг уншиж байгаа бол DevOps гэж юу болохыг мэдэж байгаа байх. Учир нь би тийм биш. сайн уу миний нэрийг Александр Титов (@), бид зүгээр л DevOps-ийн тухай ярих бөгөөд би өөрийн туршлагаа хуваалцах болно.
Би түүхийг хэрхэн ашигтай болгох талаар удаан хугацааны турш бодож байсан тул энд маш олон асуулт байх болно - би өөрөөсөө асууж байгаа асуултууд болон манай компанийн үйлчлүүлэгчдээс асуух асуултууд. Эдгээр асуултад хариулснаар ойлголт сайжирна. Миний бодлоор DevOps яагаад хэрэгтэй вэ, энэ нь юу вэ, миний бодлоор дахиад л DevOps руу явж байгаа гэдгээ хэрхэн ойлгохыг би танд хэлэх болно. Сүүлийн цэг нь асуултууд байх болно. Тэдэнд өөрөө хариулснаар танай компани DevOps руу шилжиж байна уу эсвэл ямар нэгэн байдлаар асуудал байгаа эсэхийг ойлгох боломжтой.
Нэгэн цагт би нэгдэх, худалдан авах давалгааг давж явсан. Эхлээд би Qik нэртэй жижиг стартап компанид ажиллаж байгаад дараа нь Skype хэмээх арай том компани худалдаж авсан ба дараа нь Microsoft хэмээх арай том компани худалдаж авсан. Тэр үед би DevOps-ийн санаа өөр өөр хэмжээтэй компаниудад хэрхэн өөрчлөгдөж байгааг харж эхэлсэн. Үүний дараа би DevOps-ийг зах зээлийн өнцгөөс харах сонирхолтой болж, миний хамт олон Экспресс 42 компанийг үүсгэн байгуулсан. Одоогоос 6 жилийн турш бид зах зээлийн давалгааг дагаж явж байна.
Бусад зүйлсийн дотор би DevOps Москва нийгэмлэгийн зохион байгуулагчдын нэг, DevOps-Days 2017 зохион байгуулагч боловч 2018 оныг зохион байгуулаагүй. Экспресс 42 олон компанитай хамтран ажилладаг. Бид тэнд DevOps-ийг хөгжүүлж, энэ нь хэрхэн болж байгааг харж, дүгнэлт хийж, дүн шинжилгээ хийж, дүгнэлтээ хүн бүрт хэлж, хүмүүсийг DevOps дадлагад сургадаг. Ер нь бид энэ тал дээр туршлага, мэдлэгээ нэмэгдүүлэхийн тулд чадах бүхнээ хийж байна.
Яагаад DevOps
Хүн бүрийг зовоож байдаг хамгийн эхний асуулт бол яагаад? Олон хүмүүс DevOps бол зүгээр л автоматжуулалт эсвэл компани болгонд байдаг ижил төстэй зүйл гэж боддог.
— Бидэнд тасралтгүй интеграци байсан - энэ нь бидэнд DevOps-тэй байсан гэсэн үг бөгөөд яагаад энэ бүх зүйл хэрэгтэй байна вэ? Тэд гадаадад хөгжилдөж байгаа ч биднийг ажиллахад саад болж байна!
Нийгэмлэг, арга зүйг хөгжүүлэх 9 жилийн хугацаанд энэ нь маркетингийн гялбаа биш гэдэг нь аль хэдийн тодорхой болсон боловч яагаад хэрэгтэй байгаа нь тодорхойгүй хэвээр байна. Аливаа хэрэгсэл, үйл явцын нэгэн адил DevOps нь эцсийн дүндээ хүрдэг тодорхой зорилготой байдаг.
Энэ бүхэн дэлхий ертөнц өөрчлөгдөж байгаатай холбоотой. Манай Санкт-Петербургийн сонгодог зохиолчийн дуулсан шиг А цэгээс Б цэг хүртэл тодорхой стратегийн дагуу, үүнд зориулж барьсан тодорхой бүтэцтэй, компаниуд шууд мөрөөдлийн зүг хөдөлдөг бол тэр аж ахуйн нэгжийн арга барилаас холддог.
Зарчмын хувьд мэдээллийн технологийн бүх зүйлийг энэ аргын дагуу барих ёстой. Энд IT нь зөвхөн процессыг автоматжуулахад ашиглагддаг.
Автоматжуулалт тэр бүр өөрчлөгддөггүй, учир нь компани сайн гишгэгдсэн зам руу ороход юуг өөрчлөх вэ? Энэ нь ажилладаг - бүү хүр. Одоо дэлхий дээрх хандлага өөрчлөгдөж байгаа бөгөөд Agile гэж нэрлэгддэг арга нь В төгсгөлийн цэг шууд харагдахгүй байгааг харуулж байна.
Компани зах зээлийг туулж, үйлчлүүлэгчтэй ажиллахдаа зах зээлийг байнга судалж, эцсийн цэгийг B-ийг өөрчилдөг. Түүнээс гадна компани чиглэлээ өөрчлөх тусам илүү их зах зээлийг сонгодог тул эцсийн эцэст амжилтанд хүрдэг. үүр.
Стратегийг миний саяхан мэдсэн нэгэн сонирхолтой компани харуулжээ. One Box Shave бол сахлын машин болон сахлын хэрэгслүүдийг хайрцагт нь хүргэх үйлчилгээ юм. Тэд өөр өөр үйлчлүүлэгчдэд зориулж "хайрцаг"-аа хэрхэн тохируулахаа мэддэг. Энэ нь тодорхой программ хангамжаар хийгддэг бөгөөд дараа нь бараа бүтээгдэхүүн үйлдвэрлэдэг Солонгосын үйлдвэрт захиалга илгээдэг.
Энэ бүтээгдэхүүнийг Unilever нэг тэрбум доллараар худалдаж авсан. Одоо энэ нь Gillette-тэй өрсөлдөж, Америкийн зах зээл дэх хэрэглэгчдийн багагүй хувийг булаан авчээ. One Box Shave хэлэхдээ:
-4 ир? Чи нухацтай байна уу? Энэ нь яагаад хэрэгтэй вэ - энэ нь сахлын чанарыг сайжруулдаггүй. Тусгайлан сонгосон тос, үнэртэн, хоёр иртэй өндөр чанартай сахлын машин нь эдгээр тэнэг 4 Gillette ирээс хамаагүй илүү асуудлыг шийддэг! Бид удахгүй 10 хүрэх үү?
Дэлхий ертөнц ингэж өөрчлөгддөг. Unilever танд үүнийг хийх боломжийг олгодог гайхалтай мэдээллийн технологийн системтэй гэж мэдэгджээ. Эцсийн эцэст энэ нь ойлголт шиг харагдаж байна Зах зээлд гарах хугацаа, аль хэдийн хэн ч ярьж байгаагүй.
Зах зээлд гаргах цаг хугацаа нь бидний хэр олон удаа байршуулахдаа биш юм. Та ихэвчлэн байрлуулж болно, гэхдээ хувилбарын мөчлөг нь урт байх болно. Хэрэв гурван сарын хугацаатай хувилбаруудыг бие биен дээрээ суулгаж, долоо хоногоор шилжүүлбэл компани долоо хоногт нэг удаа байрлуулж байх шиг байна. Мөн санаанаас эхлээд эцсийн хэрэгжих хүртэл 3 сар зарцуулдаг.
Зах зээлд хүрэх хугацаа гэдэг нь санаанаас эцсийн хэрэгжих хүртэлх хугацааг багасгах явдал юм.
Энэ тохиолдолд програм хангамж нь зах зээлтэй харьцдаг. One Box Shave вэбсайт үйлчлүүлэгчтэй ингэж харилцдаг. Тэдэнд худалдагч байдаггүй - зочдод дарж, хүслээ үлдээдэг вэбсайт. Үүний дагуу сайтад шинэ зүйлийг байнга байрлуулж, хүслийн дагуу шинэчилж байх ёстой. Жишээлбэл, Өмнөд Солонгост тэд Оростой харьцуулахад өөрөөр сахлаа хусдаг бөгөөд нарс биш, жишээлбэл, лууван, ванилийн үнэрт дуртай.
Сайтын агуулгыг хурдан өөрчлөх шаардлагатай байдаг тул програм хангамжийн хөгжүүлэлт ихээхэн өөрчлөгддөг. Програм хангамжаар дамжуулан бид үйлчлүүлэгч юу хүсч байгааг олж мэдэх ёстой. Өмнө нь бид үүнийг зарим тойргийн арга замаар, жишээлбэл, бизнесийн менежментээр дамжуулан сурсан. Дараа нь бид үүнийг зохион бүтээж, мэдээллийн технологийн системд шаардлага тавьж, бүх зүйл сайхан болсон. Одоо бол өөр болсон - программ хангамжийг тухайн үйл явцад оролцож буй хүн бүр, тэр дундаа инженерүүд бүтээдэг, учир нь техникийн үзүүлэлтүүдээр тэд зах зээл хэрхэн ажилладаг талаар суралцаж, мөн бизнестэй өөрсдийн ойлголтоо хуваалцдаг.
Жишээ нь, Qik дээр хүмүүс серверт харилцагчийн жагсаалтыг байршуулах үнэхээр дуртай байдгийг бид гэнэт мэдсэн бөгөөд тэд бидэнд програм хангамж өгсөн. Эхэндээ бид энэ талаар огт бодоогүй. Сонгодог компанид хүн бүр үүнийг алдаа гэж шийддэг байсан, учир нь энэ нь маш сайн ажиллах ёстой гэж заагаагүй бөгөөд ерөнхийдөө өвдөг дээрээ хэрэгждэг байсан тул тэд функцийг унтраагаад: "Энэ хэнд ч хэрэггүй, Хамгийн чухал зүйл бол үндсэн функц ажиллах явдал юм." . Технологийн компани үүнийг боломж гэж үзээд үүний дагуу программ хангамжаа өөрчилж эхэлдэг.
1968 онд алсын хараатай залуу Мелвин Конвей дараах санааг дэвшүүлжээ.
Системийг бий болгож буй байгууллага нь тухайн байгууллагын харилцааны бүтцийг хуулбарласан загвараар хязгаарлагддаг.
Нарийвчилсан байдлаар, өөр төрлийн систем үйлдвэрлэхийн тулд та өөр төрлийн компанид харилцааны бүтэцтэй байх ёстой. Хэрэв таны харилцааны бүтэц дээд шатлалтай бол энэ нь зах зээлд хүрэх цаг хугацааны маш өндөр үзүүлэлтийг өгөх системийг бий болгох боломжийг танд олгохгүй.
Унших болно . Энэ нь DevOps-ийн соёл, гүн ухааныг ойлгоход чухал учир нь DevOps-д үндсээрээ өөрчлөгддөг цорын ганц зүйл бол баг хоорондын харилцааны бүтэц юм.
Процессын үүднээс авч үзвэл DevOps-ээс өмнө бүх үе шатууд: аналитик, хөгжүүлэлт, туршилт, үйл ажиллагаа нь шугаман байсан.
DevOps-ийн хувьд эдгээр бүх үйл явц нэгэн зэрэг явагддаг.
Үүнийг хийх цорын ганц арга зам бол зах зээлд гаргах хугацаа юм. Хуучин үйл явцад ажиллаж байсан хүмүүсийн хувьд энэ нь зарим талаараа сансар огторгуй, ерөнхийдөө тийм юм шиг санагддаг.
Тэгэхээр танд яагаад DevOps хэрэгтэй байна вэ?
Дижитал бүтээгдэхүүн боловсруулахад зориулагдсан. Хэрэв танай компани дижитал бүтээгдэхүүнгүй бол DevOps хэрэггүй - энэ нь маш чухал юм.
DevOps нь програм хангамжийн дараалсан үйлдвэрлэлийн хурдны хязгаарлалтыг даван туулдаг. Үүнд бүх үйл явц нэгэн зэрэг явагддаг.
Хэцүү байдал нэмэгддэг. DevOps евангелистууд танд програм хангамжийг гаргахад хялбар болгоно гэж хэлэхэд энэ нь утгагүй зүйл юм.
DevOps-ийн тусламжтайгаар бүх зүйл илүү төвөгтэй болно.
Avito-ийн индэр дээр болсон бага хурал дээр та Docker контейнерийг байрлуулах нь бодит бус ажил гэдгийг харж болно. Нарийн төвөгтэй байдал нь хязгаарлагдмал болж, та нэгэн зэрэг олон бөмбөг тоглох хэрэгтэй болно.
DevOps нь компани дахь үйл явц, зохион байгуулалтыг бүрэн өөрчилдөг - илүү нарийвчлалтайгаар, DevOps биш, харин дижитал бүтээгдэхүүн өөрчлөгддөг. DevOps-д орохын тулд та энэ процессыг бүрэн өөрчлөх шаардлагатай хэвээр байна.
Мэргэжилтэнд зориулсан асуултууд
Чамд юу байна? Компанид ажиллаж, мэргэжилтэн болж төлөвшихдөө өөрөөсөө асууж болох асуултууд.
Танд дижитал бүтээгдэхүүн бий болгох стратеги бий юу? Хэрэв байгаа бол энэ нь аль хэдийн сайн байна. Энэ нь танай компани DevOps руу явж байна гэсэн үг.
Танай компани аль хэдийн дижитал бүтээгдэхүүн бүтээж байна уу? Энэ нь та DevOps-ийн үүднээс ахин нэг түвшинд ахиж, илүү сонирхолтой зүйлийг хийх боломжтой гэсэн үг юм. Би зөвхөн энэ үүднээс л ярьж байна.
Танай компани дижитал бүтээгдэхүүний зах зээлд тэргүүлэгчдийн нэг мөн үү? Spotify, Yandex, Uber бол одоо технологийн дэвшлийн оргилд хүрсэн компаниуд юм.
Эдгээр асуултуудыг өөрөөсөө асуугаарай, хэрэв бүх хариулт нь үгүй бол та энэ компанид DevOps хийх ёсгүй. Хэрэв DevOps-ийн сэдэв танд үнэхээр сонирхолтой байгаа бол магадгүй ... та өөр компани руу шилжих ёстой юу? Хэрэв танай компани DevOps-д орохыг хүсч байгаа ч та бүх асуултанд "Үгүй" гэж хариулсан бол энэ нь хэзээ ч өөрчлөгдөхгүй үзэсгэлэнтэй хирстэй адил юм.
байгууллага
Миний хэлсэнчлэн Конвейн хуулийн дагуу компанийн зохион байгуулалт өөрчлөгддөг. Байгууллагын үүднээс DevOps-ийг компанид нэвтрэхэд юу саад болж байгааг би эхлүүлье.
"Худаг" -ын асуудал
"Silo" гэсэн англи үгийг энд орос хэлэнд "сайн" гэж орчуулсан байна. Энэ асуудлын гол утга нь үүнд л байгаа юм багуудын хооронд мэдээлэл солилцдоггүй. Баг бүр чиглүүлэхийн тулд нийтлэг газрын зураг бүтээхгүйгээр мэргэжлийнхээ талаар гүнзгий судалдаг.
Энэ нь зарим талаараа Москвад ирээд удаагүй байгаа, метроны газрын зураг дээр хэрхэн явахаа хараахан мэдэхгүй байгаа хүнийг санагдуулдаг. Москвачууд ихэвчлэн нутаг дэвсгэрээ маш сайн мэддэг бөгөөд Москва даяар метроны газрын зургийг ашиглан жолоодож чаддаг. Та Москвад анх ирэхдээ ийм чадваргүй, зүгээр л чиг баримжаагаа алдсан байна.
DevOps энэхүү чиг баримжаа алдагдах үеийг даван туулж, бүх хэлтэс хамтран харилцан үйлчлэлийн нийтлэг газрын зургийг бүтээхийг санал болгож байна.
Үүнд хоёр хүчин зүйл саад болж байна.
Корпорацийн удирдлагын тогтолцооны үр дагавар. Энэ нь тусдаа шаталсан "худаг" -д баригдсан. Жишээлбэл, энэ системийг дэмждэг компаниудад тодорхой KPI байдаг. Нөгөөтэйгүүр, мэргэжлийнхээ хязгаараас давж, бүхэл бүтэн системийг удирдахад хэцүү хүний тархи саад болдог. Энэ нь зүгээр л эвгүй юм. Та Бангкокийн нисэх онгоцны буудалд байна гэж төсөөлөөд үз дээ - та хурдан явах замаа олохгүй. DevOps нь жолоодоход бас хэцүү байдаг тул хүмүүс таныг тийшээ очихын тулд хөтөч олох хэрэгтэй гэж хэлдэг.
Гэхдээ хамгийн чухал зүйл бол DevOps-ийн сүнсэнд шингэсэн, Фаулер болон бусад олон номыг уншсан инженерийн хувьд "худаг"-ын асуудал ингэж илэрхийлэгддэг. "худаг" нь "илэрхий" зүйлийг хийхийг зөвшөөрдөггүй. Бид DevOps Moscow-ын дараа ихэвчлэн цугларч, хоорондоо ярилцаж, хүмүүс гомдоллодог.
- Бид зүгээр л CI-г эхлүүлэхийг хүссэн ч удирдлагад хэрэггүй нь тодорхой болсон.
Энэ нь яг ийм учраас тохиолддог CI и Тасралтгүй хүргэх үйл явц олон шалгалтын хил дээр байдаг. Байгууллагын төвшинд “худаг”-ны асуудлыг зүгээр л даван туулахгүй бол юу ч хийсэн, хэчнээн гунигтай байсан ч урагшлах боломжгүй.
Компани дахь үйл явцад оролцогч бүр: backend болон frontend хөгжүүлэгч, тест, DBA, үйл ажиллагаа, сүлжээ, өөрийн чиглэлд ухдаг бөгөөд менежерээс өөр хэн ч нийтлэг газрын зурагтай байдаггүй бөгөөд тэднийг ямар нэгэн байдлаар хянаж, "хуваах" ашиглан удирддаг. ба байлдан дагуулах” арга.
Хүмүүс ямар нэгэн од эсвэл тугны төлөө тэмцэж байна, бүгд өөрсдийн мэдлэгээ ухаж байна.
Үүний үр дүнд энэ бүхнийг хооронд нь холбож, нийтлэг шугам хоолой барих даалгавар гарч ирэхэд од, тугийн төлөө тэмцэх шаардлагагүй болсон үед асуулт гарч ирнэ - ямар ч байсан яах вэ? Бид ямар нэгэн байдлаар зөвшилцөх хэрэгтэй, гэхдээ үүнийг сургуулиас хэн ч бидэнд заагаагүй. Бид сургуулиасаа хойш заалгасан: наймдугаар анги - хөөе! - долдугаар ангитай харьцуулахад! Энд ч мөн адил.
Танай компанид ч ийм байна уу?
Үүнийг шалгахын тулд та өөрөөсөө дараах асуултуудыг асууж болно.
Багууд нийтлэг хэрэглүүрийг ашиглаж, тэдгээр нийтлэг хэрэглүүрийг өөрчлөхөд хувь нэмрээ оруулдаг уу?
Багууд хэр олон удаа өөрчлөгддөг вэ—нэг багийн зарим мэргэжилтнүүд нөгөө баг руу шилждэг вэ? DevOps орчинд энэ нь хэвийн үзэгдэл болдог, учир нь заримдаа хүн өөр мэргэжлийн чиглэлээр юу хийж байгааг ойлгохгүй байх тохиолдол гардаг. Тэрээр өөр хэлтэс рүү шилжиж, тэнд хоёр долоо хоног ажиллаж, энэ хэлтэстэй ажиллах чиг баримжаа, харилцан үйлчлэлийн газрын зургийг бий болгодог.
Өөрчлөлтийн хороо байгуулаад өөрчлөлт хийх боломжтой юу? Эсвэл дээд удирдлага, чиглэлийн хүчтэй гарыг шаардаж байна уу? Би саяхан фэйсбүүк дээр бага мэддэг нэг банк захиалгаар дамжуулан хэрэглүүрийг хэрхэн хэрэгжүүлж байгааг бичсэн: бид захиалга бичдэг, бид үүнийг нэг жилийн хугацаанд хэрэгжүүлдэг, юу болохыг хардаг. Энэ нь мэдээжийн хэрэг урт бөгөөд гунигтай юм.
Менежерүүд компанийн амжилтыг харгалзахгүйгээр хувийн амжилтаа хүлээн авах нь хэр чухал вэ?
Хэрэв та эдгээр асуултуудад өөрөө хариулбал танай компанид ийм асуудал байгаа эсэх нь илүү тодорхой болно.
Дэд бүтцийг код болгон
Энэ асуудлыг шийдвэрлэсний дараа DevOps-т ахиц дэвшил гаргахад хэцүү эхний чухал практик юм код болгон дэд бүтэц.
Ихэнх тохиолдолд дэд бүтцийг код болгон дараах байдлаар ойлгодог.
— Бүгдийг bash дээр автоматжуулъя, админууд гар ажиллагаа багатай байхын тулд өөрсдийгөө скриптээр бүрхье!
Гэхдээ энэ нь үнэн биш юм.
Дэд бүтэц нь код гэдэг нь та өөрийн ажиллаж буй мэдээллийн технологийн системийн төлөв байдлыг байнга ойлгохын тулд код хэлбэрээр дүрслэхийг хэлнэ.
Та бусад багуудтай хамтран хүн бүр ойлгож, чиглүүлэх, чиглүүлэх боломжтой код хэлбэрээр газрын зургийг бүтээдэг. Энэ нь юу хийсэн нь хамаагүй - Тогооч, Ansible, Salt эсвэл Kubernetes-д YAML файлуудыг ашиглах - ялгаа байхгүй.
Чуулган дээр 2GIS-ийн хамтран ажиллагсад бие даасан системийн бүтцийг дүрсэлсэн Кубернетесэд зориулж өөрсдийн дотоод зүйлийг хэрхэн бүтээсэн талаар хэлэв. 500 системийг дүрслэхийн тулд тэдэнд энэ тайлбарыг үүсгэдэг тусдаа хэрэгсэл хэрэгтэй байсан. Ийм тайлбар байгаа үед хүн бүр бие биенээсээ шалгаж, өөрчлөлтийг хянах, хэрхэн өөрчлөх, сайжруулах, юу дутагдаж байгааг хянах боломжтой.
Зөвшөөрч байна, бие даасан bash скриптүүд энэ ойлголтыг өгдөггүй. Миний ажиллаж байсан нэг компанид "зөвхөн бичих" гэсэн нэр хүртэл байдаг байсан - скрипт бичигдсэн үед, гэхдээ унших боломжгүй болсон. Энэ нь танд бас танил болсон гэж бодож байна.
Код шиг дэд бүтэц дэд бүтцийн өнөөгийн байдлыг тодорхойлсон код. Олон бүтээгдэхүүн, дэд бүтэц, үйлчилгээний багууд энэ код дээр хамтран ажилладаг бөгөөд хамгийн чухал нь тэд бүгд энэ код хэрхэн ажилладагийг ойлгох хэрэгтэй.
Код нь шилдэг кодын туршлагын дагуу хадгалагдана: хамтарсан хөгжүүлэлт, кодын хянан үзэх, XP-програмчлал, туршилт, татах хүсэлт, кодын дэд бүтцийн CI - энэ бүхэн тохиромжтой бөгөөд ашиглах боломжтой.
Код нь бүх инженерүүдийн нийтлэг хэл болж хувирдаг.
Код дахь дэд бүтцийг өөрчлөх нь их цаг хугацаа шаарддаггүй. Тиймээ, дэд бүтцийн код нь техникийн өртэй байж болно. Ихэвчлэн багууд спагетти код шиг бичдэг олон скрипт эсвэл бүр Ansible хэлбэрээр "дэд бүтцийг код хэлбэрээр" хэрэгжүүлж эхэлснээс хойш жил хагасын дараа ийм асуудалтай тулгардаг бөгөөд тэд бас скриптүүдийг холих гэж оролддог!
чухал: Хэрэв та энэ зүйлийг хараахан туршиж үзээгүй бол үүнийг санаарай Ansible бол bash биш юм! Баримт бичгийг анхааралтай уншиж, энэ талаар юу бичсэнийг судлаарай.
Кодын хувьд дэд бүтэц гэдэг нь дэд бүтцийн кодыг тусдаа давхарга болгон хуваах явдал юм.
Манай компанид бид 3 үндсэн давхаргыг ялгадаг бөгөөд тэдгээр нь маш тодорхой бөгөөд энгийн боловч үүнээс ч олон байж болно. Та дэд бүтцийн кодоо хараад танд ийм нөхцөл байгаа эсэхээ хэлж болно. Хэрэв ямар ч давхаргыг тодруулаагүй бол та хэсэг хугацаа зарцуулж, бага зэрэг засварлах хэрэгтэй.
суурь давхарга - OS, нөөцлөлтүүд болон бусад доод түвшний зүйлсийг ингэж тохируулдаг, жишээлбэл, Kubernetes-ийг үндсэн түвшинд хэрхэн байрлуулдаг.
Үйлчилгээний түвшин - эдгээр нь таны хөгжүүлэгчдэд үзүүлэх үйлчилгээнүүд юм: үйлчилгээ болгон бүртгэл хөтлөх, үйлчилгээ болгон хянах, мэдээллийн сан нь үйлчилгээ, тэнцвэржүүлэгч нь үйлчилгээ, дараалал нь үйлчилгээ, тасралтгүй хүргэлт үйлчилгээ - хувь хүний багуудын багц үйлчилгээ юм. хөгжлийг хангаж чадна. Энэ бүгдийг таны тохиргооны удирдлагын систем дэх тусдаа модулиудад тайлбарлах шаардлагатай.
Програм хийх давхарга мөн өмнөх хоёр давхаргын орой дээр хэрхэн нээгдэхийг дүрсэлсэн.
Хяналтын асуултууд
Танай компани дэд бүтцийн нэгдсэн сантай юу? Та дэд бүтцийнхээ техникийн өрийг удирдаж байна уу? Та дэд бүтцийн нөөцөд хөгжлийн туршлагыг ашигладаг уу? Таны дэд бүтэц давхаргад хуваагдсан уу? Та үндсэн үйлчилгээ-APP диаграмыг шалгаж болно. Өөрчлөлт хийхэд хэр хэцүү вэ?
Хэрэв та өөрчлөлт хийхэд нэг өдөр хагас зарцуулсан бол энэ нь танд техникийн өртэй байгаа бөгөөд үүнийг шийдвэрлэх шаардлагатай байна гэсэн үг юм. Та дөнгөж сая дэд бүтцийн код дээрээ техникийн өрийн тармуурыг олж харлаа. Бүтээлч байдал, бүх зүйлийг автоматжуулах хүсэл нь бүх зүйл хаа сайгүй зэвэрч, бүх бариулыг арилгаж, CCTL-ийг өөрчлөхийн тулд дэд бүтцийн кодын талыг дахин бичих шаардлагатай болсон ийм олон түүхийг санаж байна. дахин засварлах шаардлагатай байна.
Тасралтгүй хүргэлт
Дебетийг кредиттэй харьцуулж үзье. Эхлээд дэд бүтцийн тодорхойлолт ирдэг бөгөөд энэ нь нэлээд энгийн байж болно. Та бүх зүйлийг нарийвчлан тайлбарлах шаардлагагүй, гэхдээ үүнтэй ажиллахын тулд зарим үндсэн тайлбар шаардлагатай. Тэгэхгүй бол цаашид тасралтгүй хүргэлтээр яах нь тодорхойгүй байна. Эдгээр бүх дадлага таныг DevOps-д ирэхэд нэгэн зэрэг хийгдэх боловч энэ нь танд юу байгаа болон түүнийг хэрхэн удирдах талаар ойлгохоос эхэлдэг. Энэ нь яг л дэд бүтцийг код болгон ашиглах практик юм.
Танд байгаа нь тодорхой болмогц, түүнийг хэрхэн удирдах нь тодорхой болсны дараа та хөгжүүлэгчийн кодыг үйлдвэрлэлд аль болох хурдан илгээх талаар бодож эхэлдэг. Би хөгжүүлэгчтэй хамт "худаг" -ын асуудлыг санаж байна, өөрөөр хэлбэл үүнийг хувь хүмүүс биш, харин баг гаргаж ирдэг.
Бид хамт байхдаа Ваня Евтухович анхны номыг үзсэн Жез Даруухан болон зохиолчдын бүлгүүд "Тасралтгүй хүргэлт", 2009 онд гарсан, бид түүний гарчгийг орос хэл рүү хэрхэн орчуулах талаар удаан бодсон. “Байнга хүргэх” гэж орчуулахыг хүссэн ч харамсалтай нь “Тасралтгүй хүргэлт” гэж орчуулсан. Манай нэр дээр шахалттай орос юм байгаа юм шиг надад санагддаг.
Байнга хүргэх хэрэгсэл
Бүтээгдэхүүний санд байгаа кодыг үргэлж үйлдвэрлэлд татаж авах боломжтой. Тэр сэтгэлээр унахгүй байж болох ч тэр үүнд үргэлж бэлэн байдаг. Үүний дагуу та сүүлний ясны доор ямар нэгэн түгшүүртэй байгаа мэт тайлбарлахад хэцүү мэдрэмжээр код бичдэг. Энэ нь ихэвчлэн дэд бүтцийн кодыг гаргах үед гарч ирдэг. Энэ нь ямар нэгэн түгшүүрийн мэдрэмж байх ёстой - энэ нь кодыг арай өөрөөр бичих боломжийг олгодог тархины үйл явцыг идэвхжүүлдэг. Үүнийг хөгжүүлэлтийн хүрээнд дүрэмд тусгасан байх ёстой.
Тогтвортой хүргэхийн тулд танд дэд бүтцийн платформ дээр ажилладаг олдворын формат хэрэгтэй. Хэрэв та дэд бүтцийн платформ дээр янз бүрийн хэлбэрийн "амьдралын хог хаягдал" хаявал энэ нь нэгдмэл болж, хадгалахад хэцүү, техникийн өрийн асуудал үүсдэг. Олдворын форматыг тохируулах шаардлагатай - энэ бол бас хамтын ажил юм: бид бүгдээрээ цугларч, тархиа шуугиулж, энэ форматыг гаргах хэрэгтэй.
Олдворыг тасралтгүй сайжруулж, дамжуулах хоолойгоор дамжих явцад үйлдвэрлэлийн орчинд тохируулан өөрчлөгддөг. Олдвор дамжуулах хоолойн дагуу хөдөлж байх үед түүнд ямар нэгэн тохиромжгүй зүйл байнга тулгардаг бөгөөд энэ нь таны үйлдвэрлэлд оруулсан эд өлгийн зүйлтэй төстэй байдаг. Хэрэв сонгодог хөгжүүлэлтийн хувьд үүнийг нэвтрүүлэлтийг хийдэг системийн администратор хийдэг бол DevOps процесст энэ нь байнга тохиолддог: энд тэд үүнийг зарим туршилтаар туршиж үзсэн, энд тэд үүнийг Kubernetes кластер руу шидсэн бөгөөд энэ нь бараг ижил төстэй юм. үйлдвэрлэлд, дараа нь тэд гэнэт ачааллын туршилт эхэлсэн .
Энэ нь зарим талаараа Pac-Man тоглоомыг санагдуулдаг - олдвор нь ямар нэгэн түүхийг дамждаг. Үүний зэрэгцээ код нь түүхийг үнэхээр дамжуулж байгаа эсэх, энэ нь таны үйлдвэрлэлтэй ямар нэгэн байдлаар холбоотой эсэхийг хянах нь чухал юм. Үйлдвэрлэлийн түүхийг Тасралтгүй хүргэх процесс руу чирж болно: ямар нэг зүйл унах үед ийм байсан, одоо энэ хувилбарыг систем дотор програмчлаад үзье. Код энэ хувилбараар дамжих бүрт дараагийн удаад ийм асуудал гарахгүй. Та энэ талаар үйлчлүүлэгчдээ хүрэхээс хамаагүй эрт мэдэх болно.
Өөр өөр байршуулах стратеги. Жишээлбэл, та AB тест эсвэл canary deployment ашиглан кодыг өөр өөр үйлчлүүлэгчид дээр өөр өөрөөр туршиж, код хэрхэн ажилладаг талаар мэдээлэл авч, 100 сая хэрэглэгчдэд түгээхээс хамаагүй эрт байна.
"Тууштай хүргэх" нь иймэрхүү харагдаж байна.
Хүргэлтийн процесс Dev, CI, Test, PreProd, Prod нь тусдаа орчин биш бөгөөд эдгээр нь таны олдвор дамждаг галд тэсвэртэй нийлбэр бүхий үе шатууд эсвэл станцууд юм.
Хэрэв танд үндсэн үйлчилгээний APP гэж тодорхойлсон дэд бүтцийн код байгаа бол энэ нь тусална бүх скриптийг бүү мартаарай, мөн тэдгээрийг энэ олдворын код болгон бичих, олдворыг сурталчлах мөн явахдаа үүнийг өөрчил.
Өөрийгөө шалгах асуултууд
Тохиолдлын 95% -д нь онцлог шинж чанарыг тайлбарлахаас үйлдвэрлэлд гаргах хүртэлх хугацаа долоо хоногоос бага байна уу? Дамжуулах хоолойн үе шат бүрт олдворын чанар сайжирч байна уу? Түүгээр дамжсан түүх бий юу? Та өөр өөр байршуулах стратеги ашигладаг уу?
Хэрэв бүх хариулт тийм бол та гайхалтай сайхан байна! Хариултаа сэтгэгдэл дээр бичээрэй - би баяртай байх болно).
Санал хүсэлт
Энэ бол хамгийн хэцүү дасгал юм. DevOpsConf бага хурлын үеэр Infobip-ийн хамтрагч энэ тухай ярихдаа түүний үгэнд бага зэрэг эргэлзэж байсан, учир нь энэ бол үнэхээр бүх зүйлийг хянах хэрэгтэй гэсэн маш нарийн төвөгтэй практик юм!
Жишээлбэл, эрт дээр үед би Qik-д ажиллаж байхдаа бид бүх зүйлийг хянах хэрэгтэй гэдгийг ойлгосон. Бид үүнийг хийсэн бөгөөд одоо бид Zabbix-д 150 зүйлтэй бөгөөд тэдгээрийг байнга хянаж байдаг. Аймшигтай байсан тул техникийн захирал хуруугаа сүм рүүгээ эргүүлэв:
- Залуус аа, та яагаад серверийг тодорхойгүй зүйлээр хүчирхийлээд байгаа юм бэ?
Гэвч энэ нь үнэхээр гайхалтай стратеги гэдгийг харуулсан нэгэн үйл явдал болсон.
Нэг үйлчилгээ байнга доголдож эхэлсэн. Эхэндээ энэ нь гацсангүй, сонирхолтой нь кодыг тэнд нэмээгүй, учир нь энэ нь үндсэн брокер байсан бөгөөд бараг ямар ч бизнесийн функцгүй байсан - энэ нь зөвхөн тусдаа үйлчилгээнүүдийн хооронд мессеж илгээдэг. Үйлчилгээ нь 4 сарын турш өөрчлөгдөөгүй бөгөөд гэнэт "Segmentation fault" алдаатай ажиллаж эхлэв.
Бид цочирдож, Zabbix-д графикуудаа нээсэн бөгөөд долоо хоног хагасын өмнө энэ брокерын ашигладаг API үйлчилгээн дэх хүсэлтийн зан байдал ихээхэн өөрчлөгдсөн нь тодорхой болсон. Дараа нь бид тодорхой төрлийн мессеж илгээх давтамж өөрчлөгдсөнийг харлаа. Хожим нь бид эдгээр нь андройд үйлчлүүлэгчид болохыг олж мэдсэн. Бид асуув:
- Залуус аа, долоо хоног хагасын өмнө та нарт юу тохиолдсон бэ?
Үүний хариуд бид тэд UI-г хэрхэн шинэчилсэн тухай сонирхолтой түүхийг сонссон. Хэн ч HTTP санг өөрчилсөн гэж шууд хэлэх магадлал багатай. Андройдын хэрэглэгчдийн хувьд энэ нь угаалгын өрөөнд саван солихтой адил юм - тэд зүгээр л санахгүй байна. Үүний үр дүнд бид 40 минутын турш ярилцсаны дараа тэд HTTP номын санг өөрчилсөнийг олж мэдсэн бөгөөд түүний үндсэн цаг хугацаа өөрчлөгдсөн. Энэ нь API сервер дээрх хөдөлгөөний зан төлөвийг өөрчлөхөд хүргэсэн бөгөөд энэ нь брокер доторх уралдааныг үүсгэсэн нөхцөл байдалд хүргэсэн бөгөөд энэ нь сүйрч эхлэв.
Гүнзгий хяналтгүйгээр үүнийг нээх нь ерөнхийдөө боломжгүй юм. Байгууллагад "худаг"-ын асуудал байсаар байвал хүн бүр бие бие рүүгээ мөнгө шидсэн тохиолдолд энэ нь олон жил амьдрах болно. Асуудлыг шийдэх боломжгүй тул та зүгээр л серверийг дахин эхлүүлнэ үү. Та өөрт байгаа бүх үйл явдлыг хянаж, хянаж, хянаж, хяналтыг тест болгон ашиглахад - код бичиж, түүнийг хэрхэн хянахаа шууд код хэлбэрээр зааж өгөхөд (бидэнд дэд бүтэц аль хэдийн код хэлбэрээр байгаа) бүх зүйл тодорхой болно. алган дээр. Ийм нарийн төвөгтэй асуудлыг ч хялбархан хянаж байдаг.
Үйлдвэрлэлд бус хүргэх үйл явцын үе шат бүрт олдворт юу тохиолдох тухай бүх мэдээллийг цуглуул.
Хяналтыг CI-д байршуулснаар зарим үндсэн зүйлс тэнд харагдах болно. Дараа нь та тэдгээрийг Test, PredProd болон ачааллын туршилтаас харах болно. Бүх үе шатанд мэдээлэл цуглуулах, зөвхөн хэмжигдэхүүн, статистик төдийгүй бүртгэлүүд: програм хэрхэн гарч ирсэн, гажуудал - бүгдийг цуглуул.
Үгүй бол үүнийг ойлгоход хэцүү байх болно. DevOps нь илүү төвөгтэй гэдгийг би аль хэдийн хэлсэн. Энэ нарийн төвөгтэй байдлыг даван туулахын тулд та ердийн аналитиктай байх хэрэгтэй.
Өөрийгөө хянах асуултууд
Хяналт, бүртгэл нь танд зориулсан хөгжлийн хэрэгсэл мөн үү? Код бичихдээ таны хөгжүүлэгчид, тэр дундаа та үүнийг хэрхэн хянах талаар боддог уу?
Та үйлчлүүлэгчдээс асуудлын талаар сонсдог уу? Хяналт, бүртгэл хөтлөхөөс үйлчлүүлэгчийг илүү сайн ойлгож байна уу? Та хяналт, бүртгэлээс системийг илүү сайн ойлгож байна уу? Та системийн чиг хандлага өсч байгааг хараад, дахиад 3 долоо хоногийн дараа бүх зүйл үхнэ гэдгийг ойлгосон учраас л системийг өөрчилдөг үү?
Эдгээр гурван бүрэлдэхүүн хэсэгтэй болсны дараа та компанидаа ямар дэд бүтцийн платформ байгаа талаар бодож болно.
Дэд бүтцийн платформ
Гол нь энэ нь бүх компанид байдаг өөр өөр хэрэгслүүд биш юм.
Дэд бүтцийн платформын утга учир нь бүх багууд эдгээр хэрэгслийг ашиглаж, хамтдаа хөгжүүлдэгт оршино.
Дэд бүтцийн платформын бие даасан хэсгүүдийг боловсруулах үүрэгтэй тусдаа баг байдаг нь тодорхой байна. Үүний зэрэгцээ инженер бүр дэд бүтцийн платформыг хөгжүүлэх, гүйцэтгэл, сурталчлах үүрэгтэй. Дотоод түвшинд энэ нь нийтлэг хэрэгсэл болдог.
Бүх багууд дэд бүтцийн платформыг хөгжүүлж, өөрийн IDE шиг болгоомжтой ханддаг. Та IDE дээрээ бүх зүйлийг сайхан, хурдан болгохын тулд өөр өөр залгаасуудыг суулгаж, халуун товчлууруудыг тохируулдаг. Та Sublime, Atom эсвэл Visual Studio Code-ийг нээхэд кодын алдаа гарч, ажиллах боломжгүй гэдгийг ойлгосноор та тэр даруй гунигтай болж, IDE-ээ засахаар гүйж байна.
Дэд бүтцийн платформдоо адилхан ханд. Хэрэв та ямар нэг зүйл буруу байгааг ойлгож байгаа бол өөрөө засах боломжгүй бол хүсэлтээ үлдээгээрэй. Энгийн юм байвал өөрөө засаад татах хүсэлтээ явуулаарай залуусаа авч үзээд нэмнэ. Энэ нь хөгжүүлэгчийн толгой дахь инженерийн хэрэгслүүдэд арай өөр хандлага юм.
Дэд бүтцийн платформ нь олдворыг бүтээн байгуулалтаас үйлчлүүлэгч рүү шилжүүлэх, чанарыг байнга сайжруулдаг. IP нь үйлдвэрлэлийн кодтой холбоотой олон түүхээр програмчлагдсан байдаг. Хөгжлийн олон жилийн туршид эдгээр түүхүүд маш олон байдаг бөгөөд тэдгээрийн зарим нь өвөрмөц бөгөөд зөвхөн танд хамааралтай байдаг - тэдгээрийг Google-ээр хайх боломжгүй.
Энэ үед дэд бүтцийн платформ нь таны өрсөлдөх давуу тал болно, учир нь энэ нь өрсөлдөгчийн хэрэгсэлд байхгүй ямар нэг зүйл суулгасан байдаг. Таны IP-г гүнзгийрүүлэх тусам зах зээлд гарах цаг хугацааны хувьд өрсөлдөх давуу тал тань нэмэгдэнэ. Энд харагдана худалдагчийн түгжээний асуудал: Та хэн нэгний платформыг авч болно, гэхдээ хэн нэгний туршлагыг ашигласнаар энэ нь танд хэр хамааралтай болохыг ойлгохгүй байх болно. Тиймээ, компани бүр Амазон шиг платформ байгуулж чадахгүй. Энэ нь компанийн туршлага нь зах зээл дэх байр суурьтай нь холбоотой байдаг хэцүү шугам бөгөөд та тэнд борлуулагчийн түгжээг ашиглах боломжгүй. Үүнийг бас бодох нь чухал.
Энэ схем
Энэ бол DevOps компанийн бүх дадлага, үйл явцыг тохируулахад туслах дэд бүтцийн платформын үндсэн диаграмм юм.
Энэ нь юунаас бүрдэхийг харцгаая.
Нөөцийн зохион байгуулалтын систем, CPU, санах ой, дискийг програмууд болон бусад үйлчилгээнд өгдөг. Үүний дээр - доод түвшний үйлчилгээ: хяналт, бүртгэл, CI/CD хөдөлгүүр, олдвор хадгалах, системийн код болгон дэд бүтэц.
Дээд түвшний үйлчилгээ: өгөгдлийн сан нь үйлчилгээ, дараалал нь үйлчилгээ, ачааллын балансыг үйлчилгээ, зургийн хэмжээг өөрчлөх, үйлчилгээ, Big Data үйлдвэр. Үүний дээр - Таны үйлчлүүлэгчид байнга өөрчлөгддөг кодыг дамжуулах хоолой.
Та өөрийн программ хангамж нь үйлчлүүлэгчид хэрхэн ажилладаг талаар мэдээлэл хүлээн авч, үүнийг өөрчилж, энэ кодыг дахин нийлүүлж, мэдээлэл хүлээн авч, ингэснээр та дэд бүтцийн платформ болон програм хангамжаа байнга хөгжүүлдэг.
Диаграммд хүргэх дамжуулах хоолой нь олон үе шатаас бүрдэнэ. Гэхдээ энэ бол жишээ болгон өгсөн бүдүүвч диаграм юм - үүнийг нэг нэгээр нь давтах шаардлагагүй. Үе шатууд нь үйлчилгээнүүдтэй яг л үйлчилгээтэй харьцдаг - платформын тоосго бүр өөрийн гэсэн түүхийг агуулдаг: нөөцийг хэрхэн хуваарилдаг, програмыг хэрхэн ажиллуулдаг, нөөцтэй ажилладаг, хянагддаг, өөрчлөгддөг.
Платформын хэсэг бүр нь түүхийг агуулдаг гэдгийг ойлгох нь чухал бөгөөд энэ тоосго ямар түүхийг авчирдаг талаар өөрөөсөө асуугаарай, магадгүй үүнийг хаяж, гуравдагч этгээдийн үйлчилгээгээр солих хэрэгтэй. Жишээлбэл, тоосгоны оронд Окметрийг суурилуулах боломжтой юу? Магадгүй залуус энэ мэргэжлийг биднээс хамаагүй илүү хөгжүүлсэн байх. Гэхдээ үгүй байж магадгүй - магадгүй бид өвөрмөц туршлагатай байж магадгүй, бид Prometheus-ийг суулгаж, цаашид хөгжүүлэх хэрэгтэй.
Платформ бий болгох
Энэ бол харилцааны нарийн төвөгтэй үйл явц юм. Та үндсэн дадлагатай болсон үед шаардлага, стандартыг боловсруулдаг янз бүрийн инженер, мэргэжилтнүүдийн хооронд харилцаа холбоо тогтоож, тэдгээрийг янз бүрийн арга хэрэгсэл, арга барил болгон байнга өөрчилж эхэлдэг. Бидний DevOps-д байгаа соёл энд чухал юм.
Соёлтой бол бүх зүйл маш энгийн - Энэ нь хамтын ажиллагаа, харилцааны тухай юм, өөрөөр хэлбэл, бие биетэйгээ нийтлэг салбарт ажиллах хүсэл, нэг зэмсгийг хамтдаа ашиглах хүсэл. Энд пуужингийн шинжлэх ухаан байдаггүй - бүх зүйл маш энгийн, улиг болсон. Жишээлбэл, бид бүгдээрээ орцонд амьдардаг, цэвэрхэн байлгадаг - ийм түвшний соёл.
Чамд юу байна?
Дахин хэлэхэд та өөрөөсөө асууж болно.
Дэд бүтцийн платформ нь зориулагдсан уу? Түүний хөгжлийг хэн хариуцах вэ? Та дэд бүтцийн платформынхаа өрсөлдөх давуу талыг ойлгож байна уу?
Та эдгээр асуултуудыг өөрөөсөө байнга асууж байх хэрэгтэй. Хэрэв ямар нэг зүйлийг гуравдагч этгээдийн үйлчилгээнд шилжүүлэх боломжтой бол түүнийг шилжүүлэх ёстой, хэрэв гуравдагч талын үйлчилгээ таны хөдөлгөөнийг хааж эхэлбэл та өөртөө систем бий болгох хэрэгтэй.
Тиймээс DevOps...
... энэ бол нарийн төвөгтэй систем бөгөөд дараахь зүйлийг агуулсан байх ёстой.
- Дижитал бүтээгдэхүүн.
- Энэхүү дижитал бүтээгдэхүүнийг хөгжүүлдэг бизнесийн модулиуд.
- Код бичдэг бүтээгдэхүүний багууд.
- Тасралтгүй хүргэлтийн практик.
- Үйлчилгээ болгон платформууд.
- Дэд бүтэц нь үйлчилгээ.
- Дэд бүтцийг код болгон.
- DevOps-д суурилуулсан найдвартай байдлыг хангах тусдаа дадлага.
- Энэ бүхнийг дүрсэлсэн санал хүсэлтийн дадлага.
Та энэ диаграммыг ашиглаж, танай компанид аль хэдийн байгаа зүйлийг ямар нэг хэлбэрээр тодруулж болно: үүнийг боловсруулсан уу эсвэл одоо ч гэсэн хөгжүүлэх шаардлагатай байна.
Хэдэн долоо хоногийн дараа дуусна . RIT++-ийн нэг хэсэг болгон. Тасралтгүй хүргэлт, кодын дэд бүтэц, DevOps-ийн өөрчлөлтийн талаар олон гайхалтай тайлангуудыг олж авах чуулганд хүрэлцэн ирээрэй. , эцсийн үнийн эцсийн хугацаа 20-р сарын XNUMX
Эх сурвалж: www.habr.com