Израилийн анхны DevOps сертификатыг санаачлагч, зааварлагчдын нэг, Otomato Software-ийн үүсгэн байгуулагч, захирал Антон Вайсс өнгөрсөн жилийн үзэсгэлэнд үг хэлэв. эмх замбараагүй байдлын онол ба эмх замбараагүй инженерчлэлийн үндсэн зарчмуудын талаар, мөн ирээдүйн DevOps-ийн хамгийн тохиромжтой зохион байгуулалт хэрхэн ажилладаг талаар тайлбарлав.
Бид тайлангийн текст хувилбарыг бэлтгэсэн.
Өглөөний мэнд
Москвад хоёр дахь жилдээ зохион байгуулагдаж буй DevOpsDays, би энэ тайзан дээр хоёр дахь удаагаа гарч байна, та нарын олонх нь хоёр дахь удаагаа энэ өрөөнд байна. Энэ нь юу гэсэн үг вэ? Энэ нь Орос дахь DevOps хөдөлгөөн өсөж, үржиж, хамгийн чухал нь 2018 онд DevOps гэж юу болох талаар ярих цаг нь болсон гэсэн үг юм.
2018 онд DevOps аль хэдийн мэргэжил болсон гэж бодож байгаа гараа өргөх үү? Ийм байдаг. Өрөөнд ажлын байрны тодорхойлолтод "DevOps инженер" гэж бичсэн DevOps инженерүүд байгаа юу? Өрөөнд DevOps менежерүүд байгаа юу? Тийм зүйл байхгүй. DevOps архитекторууд уу? Бас үгүй. Хангалтгүй. Хэн ч өөрсдийгөө DevOps инженер гэж хэлдэггүй нь үнэн үү?
Тэгэхээр та нарын ихэнх нь үүнийг эсрэг хэв маяг гэж бодож байна уу? Ийм мэргэжил байх ёсгүй гэж үү? Бид хүссэн бүхнээ бодож болно, гэвч биднийг бодож байх зуур энэ салбар DevOps бүрээний дуунаар урагшилж байна.
DevDevOps хэмээх шинэ сэдвийн талаар хэн сонссон бэ? Энэ нь хөгжүүлэгчид болон хөгжүүлэгчдийн хооронд үр дүнтэй хамтран ажиллах боломжийг олгодог шинэ техник юм. Бас тийм ч шинэ биш. Твиттерээс харахад тэд 4 жилийн өмнөөс энэ тухай ярьж эхэлсэн. Өнөөг хүртэл энэ сонирхол нэмэгдэж, өсч байна, өөрөөр хэлбэл асуудал байна. Асуудлыг шийдэх хэрэгтэй.
Бид бүтээлч хүмүүс, зүгээр л амардаггүй. Бид хэлэхдээ: DevOps бол хангалттай өргөн хүрээтэй үг биш, түүнд янз бүрийн, сонирхолтой элементүүд байхгүй хэвээр байна. Мөн бид нууц лабораторидоо очиж сонирхолтой мутаци үүсгэж эхэлдэг: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Логик нь төмөр шиг, тийм үү? Манай хүргэлтийн систем ажиллахгүй, систем тогтворгүй, хэрэглэгчид маань сэтгэл хангалуун бус, программ хангамжийг цаг тухайд нь гаргах цаг байхгүй, төсөвтөө багтахгүй байна. Энэ бүхнийг бид яаж шийдэх гэж байна? Бид шинэ үг гаргах болно! Энэ нь "Ops" гэж дуусч, асуудал шийдэгдэнэ.
Тиймээс би энэ аргыг "Ops, тэгээд асуудал шийдэгдсэн" гэж нэрлэдэг.
Хэрэв бид энэ бүхнийг яагаад бодож олсныг өөртөө сануулбал энэ бүхэн бүдгэрнэ. Програм хангамжийг хүргэх болон энэ үйл явцад өөрсдийн ажлыг аль болох саадгүй, өвдөлтгүй, үр дүнтэй, хамгийн чухал нь тааламжтай болгохын тулд бид DevOps-ийн энэ бүх зүйлийг санаачилсан.
DevOps өвдөлтөөс болж өссөн. Мөн бид зовлон зүдгүүрээс залхаж байна. Мөн энэ бүхнийг хэрэгжүүлэхийн тулд бид мөнх ногоон практикт тулгуурладаг: үр дүнтэй хамтын ажиллагаа, урсгалын дадлага, хамгийн чухал нь системийн сэтгэлгээ, учир нь үүнгүйгээр ямар ч DevOps ажиллахгүй.
Систем нь юу вэ?
Хэрэв бид системийн сэтгэлгээний талаар аль хэдийн ярьж байгаа бол систем гэж юу болохыг өөртөө сануулъя.
Хэрэв та хувьсгалт хакер бол таны хувьд систем нь илт муу юм. Чамайг нөмөрч, хүсээгүй зүйлээ хийхэд хүргэдэг үүл юм.
Системийн сэтгэлгээний үүднээс авч үзвэл систем нь хэсгүүдээс бүрдсэн бүхэл бүтэн юм. Энэ утгаараа бидний хүн нэг бүр систем юм. Бидний ажилладаг байгууллагууд системтэй. Тэгээд та бид хоёрын барьж байгаа зүйлийг систем гэдэг.
Энэ бүхэн нь нэг том нийгэм-технологийн системийн нэг хэсэг юм. Хэрэв бид энэ нийгэм-технологийн систем хэрхэн хамтран ажилладагийг ойлгосон тохиолдолд л бид энэ асуудалд ямар нэг зүйлийг үнэхээр оновчтой болгох боломжтой болно.
Системийн сэтгэлгээний үүднээс авч үзвэл систем нь янз бүрийн сонирхолтой шинж чанартай байдаг. Нэгдүгээрт, энэ нь хэсгүүдээс бүрддэг бөгөөд энэ нь түүний зан байдал нь хэсгүүдийн зан төлөвөөс хамаардаг гэсэн үг юм. Түүнээс гадна түүний бүх хэсгүүд нь харилцан хамааралтай байдаг. Систем хэдий чинээ олон хэсэгтэй байх тусам түүний зан төлөвийг ойлгох эсвэл урьдчилан таамаглахад хэцүү байдаг.
Зан төлөвийн үүднээс авч үзвэл өөр нэг сонирхолтой баримт бий. Систем нь өөрийн бие даасан хэсгүүдийн аль нь ч хийж чадахгүй зүйлийг хийж чадна.
Доктор Рассел Аккоффын (системийн сэтгэлгээг үндэслэгчдийн нэг) хэлснээр үүнийг бодлын туршилтаар нотлоход тун амархан. Жишээлбэл, өрөөнд байгаа хэн код бичихийг мэддэг вэ? Маш олон гар байдаг бөгөөд энэ нь бидний мэргэжилд тавигдах гол шаардлагуудын нэг учраас энэ нь хэвийн үзэгдэл юм. Та яаж бичихээ мэддэг ч таны гар чамаас тусдаа код бичиж чадах уу? "Миний гар код бичдэггүй, харин миний тархи код бичдэг" гэж хэлэх хүмүүс байдаг. Таны тархи таниас тусдаа код бичиж чадах уу? За, үгүй байх.
Тархи бол гайхалтай машин, бид тэнд хэрхэн ажилладагийг 10% мэдэхгүй ч бидний бие болох системээс тусдаа ажиллаж чадахгүй. Үүнийг батлахад амархан: гавлынхаа ясыг онгойлгож, тархиа гаргаж, компьютерийн өмнө тавиад, түүнд энгийн зүйл бичихийг оролдоорой. Жишээлбэл, Python хэл дээрх "Сайн уу, дэлхий".
Хэрэв систем нь аль ч хэсэг нь тусад нь хийж чадахгүй зүйлийг хийж чадвал энэ нь түүний зан төлөв нь түүний хэсгүүдийн зан төлөвөөр тодорхойлогддоггүй гэсэн үг юм. Энэ нь юугаар тодорхойлогддог вэ? Энэ нь эдгээр хэсгүүдийн харилцан үйлчлэлээр тодорхойлогддог. Үүний дагуу илүү олон хэсэг байх тусам харилцан үйлчлэл нь илүү төвөгтэй байх тусам системийн үйл ажиллагааг ойлгох, урьдчилан таамаглахад хэцүү байдаг. Мөн энэ нь ийм системийг эмх замбараагүй болгодог, учир нь системийн аль ч хэсэгт үл үзэгдэх аливаа өөрчлөлт нь огт тааварлашгүй үр дүнд хүргэж болзошгүй юм.
Анхны нөхцөл байдалд ийм мэдрэмтгий байдлыг анх Америкийн цаг уурч Эд Лоренз нээж, судалжээ. Дараа нь үүнийг "эрвээхэйний эффект" гэж нэрлэж, "эмх замбараагүй байдлын онол" хэмээх шинжлэх ухааны сэтгэлгээний хөдөлгөөнийг хөгжүүлэхэд хүргэсэн. Энэ онол нь 20-р зууны шинжлэх ухааны томоохон парадигмын өөрчлөлтүүдийн нэг болсон.
Эмх замбараагүй байдлын онол
Эмх замбараагүй байдлыг судалдаг хүмүүс өөрсдийгөө эмх замбараагүй гэж нэрлэдэг.
Чухамдаа энэ тайланг гаргах болсон шалтгаан нь нарийн төвөгтэй тархсан систем, олон улсын томоохон байгууллагуудтай хамтран ажиллаж байхдаа би ийм л хүн юм шиг санагдаж байгаагаа хэзээ нэгэн цагт ойлгосон. Би бол эмх замбараагүй байдал судлаач. Энэ нь үндсэндээ "Би энд юу болоод байгааг ойлгохгүй байна, энэ талаар юу хийхээ мэдэхгүй байна" гэж хэлэх ухаалаг арга юм.
Миний бодлоор та нарын олонхи нь ийм мэдрэмжтэй байдаг тул та бас эмх замбараагүй хүмүүс юм. Би таныг эмх замбараагүй байдлын нэгдэлд урьж байна. Эрхэм эмх замбараагүй судлаачид та бид хоёрын судлах системүүдийг "цогц дасан зохицох систем" гэж нэрлэдэг.
Дасан зохицох чадвар гэж юу вэ? Дасан зохицох чадвар гэдэг нь ийм дасан зохицох систем дэх хэсгүүдийн хувь хүний болон хамтын зан төлөв өөрчлөгдөж, өөрөө зохион байгуулагдаж, систем дэх үйл явдал эсвэл гинжин хэлхээнд хариу үйлдэл үзүүлэхийг хэлнэ. Өөрөөр хэлбэл, систем нь өөрийгөө зохион байгуулах замаар өөрчлөлтөд дасан зохицдог. Мөн өөрийгөө зохион байгуулах энэхүү чадвар нь чөлөөт бие даасан төлөөлөгчдийн сайн дурын, бүрэн төвлөрсөн бус хамтын ажиллагаанд суурилдаг.
Ийм системийн өөр нэг сонирхолтой шинж чанар нь тэдгээрийг чөлөөтэй өргөжүүлэх боломжтой байдаг. Эмх замбараагүй инженер-инженерүүдийн хувьд бидний сонирхлыг татах нь дамжиггүй. Тэгэхээр, хэрэв бид нарийн төвөгтэй системийн зан төлөв нь түүний хэсгүүдийн харилцан үйлчлэлээр тодорхойлогддог гэж хэлсэн бол бид юуг сонирхох ёстой вэ? Харилцаа холбоо.
Өөр хоёр сонирхолтой дүгнэлт байна.
Нэгдүгээрт, нарийн төвөгтэй системийг түүний хэсгүүдийг хялбарчлах замаар хялбарчлах боломжгүй гэдгийг бид ойлгож байна. Хоёрдугаарт, нарийн төвөгтэй системийг хялбарчлах цорын ганц арга бол түүний хэсгүүдийн хоорондын харилцан үйлчлэлийг хялбарчлах явдал юм.
Бид хэрхэн харьцдаг вэ? Та бид хоёр бол хүний нийгэм хэмээх том мэдээллийн системийн нэг хэсэг юм. Бид нийтлэг хэлээр дамжуулан, хэрэв бидэнд байгаа бол, хэрэв бид үүнийг олвол харилцдаг.
Гэхдээ хэл өөрөө дасан зохицох цогц систем юм. Үүний дагуу, илүү үр дүнтэй, энгийн харилцахын тулд бид ямар нэгэн протокол үүсгэх хэрэгтэй. Энэ нь бидний хооронд мэдээлэл солилцохыг илүү хялбар, урьдчилан таамаглах, илүү ойлгомжтой болгох зарим тэмдэг, үйлдлийн дараалал юм.
Нарийн төвөгтэй байдал, дасан зохицох чадвар, төвлөрлийг сааруулах, эмх замбараагүй байдал руу чиглэсэн чиг хандлага бүх зүйлд ажиглагдаж болно гэдгийг хэлмээр байна. Мөн та бид хоёрын барьж буй системүүд болон бидний нэг хэсэг болсон системүүдэд.
Үндэслэлгүй байхын тулд бидний бий болгож буй систем хэрхэн өөрчлөгдөж байгааг харцгаая.
Та энэ үгийг хүлээж байсан, би ойлгож байна. Бид DevOps бага хуралд оролцож байна, өнөөдөр энэ үгийг зуу мянга орчим удаа сонсох болно, дараа нь бид шөнө зүүдлэх болно.
Бичил үйлчилгээнүүд нь DevOps-ын практикт хариу үйлдэл үзүүлэхийн тулд бий болсон програм хангамжийн анхны архитектур бөгөөд энэ нь манай системийг илүү уян хатан, илүү өргөтгөх боломжтой болгож, тасралтгүй хүргэх боломжийг хангах зорилготой юм. Тэр яаж үүнийг хийдэг вэ? Үйлчилгээний хэмжээг бууруулж, эдгээр үйлчилгээг боловсруулахад тулгарч буй асуудлын цар хүрээг багасгаж, хүргэх хугацааг багасгадаг. Өөрөөр хэлбэл, бид системийн хэсгүүдийг багасгаж, хялбарчилж, тэдгээрийн тоог нэмэгдүүлж, үүний дагуу эдгээр хэсгүүдийн хоорондын харилцан үйлчлэлийн нарийн төвөгтэй байдал байнга нэмэгддэг, өөрөөр хэлбэл бидний шийдэх ёстой шинэ асуудлууд гарч ирдэг.
Бичил үйлчилгээнүүд нь төгсгөл биш, микро үйлчилгээнүүд нь ерөнхийдөө аль хэдийн өчигдөр болсон, учир нь Сервергүй ирж байна. Бүх серверүүд шатсан, ямар ч сервер, ямар ч үйлдлийн систем, зүгээр л цэвэр гүйцэтгэх код. Тохиргоо нь тусдаа, мужууд нь тусдаа, бүх зүйл үйл явдлаар хянагддаг. Гоо сайхан, цэвэрхэн, нам гүм, ямар ч үйл явдал, юу ч болдоггүй, бүрэн дэг журамтай.
Нарийн төвөгтэй байдал хаана байна вэ? Хэцүү нь мэдээжийн хэрэг харилцан үйлчлэлд байдаг. Нэг функц дангаараа хэр ихийг хийж чадах вэ? Энэ нь бусад функцуудтай хэрхэн харьцдаг вэ? Мессежийн дараалал, мэдээллийн сан, тэнцвэржүүлэгч. Алдаа гарсан тохиолдолд зарим үйл явдлыг хэрхэн яаж сэргээх вэ? Маш олон асуулт, цөөн хариулт.
Microservices болон Serverless нь бидний Cloud Native гэж нэрлэгддэг шинэлэг хүмүүс юм. Энэ бүхэн үүлтэй холбоотой. Гэхдээ үүл нь мөн чанараараа хязгаарлагдмал байдаг. Бид үүнийг тархсан систем гэж ойлгоод дасчихсан. Үнэндээ үүл үйлчилгээ үзүүлэгчдийн серверүүд хаана амьдардаг вэ? Дата төвүүдэд. Өөрөөр хэлбэл, бид энд нэг төрлийн төвлөрсөн, маш хязгаарлагдмал, тархсан загвартай.
Өнөөдөр бид "Зүйлсийн интернет" гэдэг нь энгийн таамаглалаар ч гэсэн ойрын таваас арван жилийн хугацаанд интернетэд холбогдсон олон тэрбум төхөөрөмж биднийг хүлээж байна гэсэн том үг биш гэдгийг бид ойлгож байна. Асар их хэмжээний хэрэгцээтэй, хэрэггүй өгөгдөл нь үүлэнд нэгтгэгдэж, үүлэн дээрээс байршуулах болно.
Үүл үргэлжлэхгүй тул бид захын тооцоолол гэж нэрлэгддэг зүйлийн талаар улам бүр ярьж байна. Эсвэл би "манан тооцоолол" гэсэн гайхалтай тодорхойлолтод дуртай. Энэ нь романтизм ба нууцлаг ид шидийн үзлээр бүрхэгдсэн байдаг.
Манангийн тооцоолол. Гол нь үүл нь ус, уур, мөс, чулуунуудын төвлөрсөн бөөгнөрөл юм. Мөн манан бол агаар мандалд бидний эргэн тойронд тархсан усны дуслууд юм.
Манангийн парадигмд ихэнх ажлыг эдгээр дуслууд бүрэн бие даасан байдлаар эсвэл бусад дуслуудтай хамтран гүйцэтгэдэг. Тэд үнэхээр дарагдсан үедээ л үүлэн рүү ханддаг.
Энэ нь дахин төвлөрлийг сааруулах, бие даасан байдал, мэдээжийн хэрэг та нарын ихэнх нь энэ бүхэн хаашаа явж байгааг аль хэдийн ойлгосон, учир нь та блокчейн талаар дурдахгүй бол төвлөрлийг сааруулах талаар ярьж болохгүй.
итгэдэг хүмүүс байдаг, Эдгээр нь cryptocurrency хөрөнгө оруулалт хийсэн хүмүүс юм. Над шиг итгэсэн мөртлөө айдаг хүмүүс байдаг. Мөн итгэдэггүй хүмүүс байдаг. Энд та өөрөөр хандаж болно. Технологи байна, шинэ үл мэдэгдэх зүйл байна, асуудал байна. Аливаа шинэ технологийн нэгэн адил энэ нь хариулахаасаа илүү олон асуултыг бий болгодог.
Блокчэйнтэй холбоотой шуугиан бол ойлгомжтой. Алтны гүйлгээг хойш нь харвал технологи нь өөрөө илүү их эрх чөлөө, илүү бие даасан байдал, түгээн дэлгэрсэн дэлхийн итгэлцэл гэсэн гэрэлт ирээдүйн гайхалтай амлалтыг өгдөг. Юу хүсээгүй юм бэ?
Үүний дагуу дэлхий даяар улам олон инженерүүд төвлөрсөн бус програмуудыг боловсруулж эхэлж байна. Энэ бол зүгээр л "Аан, блокчэйн бол зүгээр л муу хэрэгжсэн тархсан мэдээллийн сан юм" гэж хэлэхээр үгүйсгэх аргагүй хүч юм. Эсвэл үл итгэгчдийн хэлэх дуртай байдаг шиг: "Блокчэйнд зориулсан бодит програм байхгүй." Бодоод үзвэл 150 жилийн өмнө тэд цахилгааны тухай ижил зүйлийг хэлж байсан. Тэд зарим талаараа зөв байсан, учир нь өнөөдөр цахилгаан эрчим хүчийг бий болгож байгаа зүйл нь 19-р зуунд ямар ч боломжгүй байсан.
Дашрамд хэлэхэд дэлгэцэн дээр ямар лого байгааг хэн мэдэх вэ? Энэ бол Hyperledger юм. Энэ нь Линуксийн сангийн ивээл дор хэрэгжиж буй төсөл бөгөөд блокчэйн технологиудыг багтаасан болно. Энэ бол манай нээлттэй эх сурвалжийн нийгэмлэгийн хүч чадал юм.
Эмх замбараагүй инженерчлэл
Тэгэхээр бидний боловсруулж байгаа тогтолцоо улам бүр нарийн төвөгтэй, эмх замбараагүй, дасан зохицох чадвартай болж байна. Netflix бол микро үйлчилгээний системийн анхдагчид юм. Тэд үүнийг хамгийн түрүүнд ойлгож, Simian Army гэж нэрлэсэн багаж хэрэгслийг боловсруулсан бөгөөд хамгийн алдартай нь . Тэр юу гэж нэрлэгддэг болохыг тодорхойлсон .
Дашрамд хэлэхэд, бид тайлан дээр ажиллах явцад энэ текстийг орос хэл рүү хүртэл орчуулсан тул очно уу , унших, сэтгэгдэл бичих, загнах.
Товчхондоо эмх замбараагүй байдлын инженерчлэлийн зарчмууд дараахь зүйлийг хэлж байна. Нарийн төвөгтэй тархсан системүүд нь угаасаа урьдчилан таамаглах боломжгүй бөгөөд угаасаа алдаатай байдаг. Алдаа гарах нь гарцаагүй бөгөөд энэ нь бид эдгээр алдааг хүлээн зөвшөөрч, эдгээр системүүдтэй огт өөр аргаар ажиллах шаардлагатай гэсэн үг юм.
Бид өөрсдөө ийм дасан зохицох чадвар, өөрийгөө зохион байгуулах, оршин тогтнох чадвараа туршихын тулд эдгээр алдааг үйлдвэрлэлийн системдээ нэвтрүүлэхийг хичээх ёстой.
Мөн энэ нь бүх зүйлийг өөрчилдөг. Бид системийг үйлдвэрлэлд хэрхэн нэвтрүүлэхээс гадна тэдгээрийг хэрхэн хөгжүүлж, хэрхэн туршиж үздэг. Кодыг тогтворжуулах, царцаах үйл явц байхгүй, харин эсрэгээр, тогтворгүй болох үйл явц байнга явагддаг. Бид системийг устгаж, цаашид оршин тогтнохыг нь харахыг хичээж байна.
Тархсан системийн интеграцийн протоколууд
Үүний дагуу энэ нь манай системийг ямар нэгэн байдлаар өөрчлөхийг шаарддаг. Тэд илүү тогтвортой байхын тулд хэсгүүдийн хоорондын харилцан үйлчлэлийн зарим шинэ протокол хэрэгтэй. Ингэснээр эдгээр хэсгүүд тохиролцож, ямар нэгэн байдлаар өөрийгөө зохион байгуулах боломжтой болно. Бүх төрлийн шинэ хэрэгслүүд, шинэ протоколууд гарч ирдэг бөгөөд үүнийг би "тархсан системүүдийн харилцан үйлчлэлийн протоколууд" гэж нэрлэдэг.
Би юу яриад байгаа юм бэ? Нэгдүгээрт, төсөл . Зарим нь ерөнхий тархсан хяналтын протоколыг бий болгохыг оролддог бөгөөд энэ нь нарийн төвөгтэй тархсан системийг дибаг хийхэд зайлшгүй шаардлагатай хэрэгсэл юм.
Цаашид - . Бид системд юу тохиолдохыг урьдчилан таамаглах боломжгүй, өөрөөр хэлбэл түүний ажиглалт, ажиглалтыг нэмэгдүүлэх хэрэгтэй гэж бид хэлдэг. Opentracing нь манай системд ажиглагдах боломжийг олгодог хэрэгслүүдийн бүлэгт багтдаг. Гэхдээ систем бидний хүлээж байгаа шиг ажиллаж байгаа эсэхийг тодорхойлохын тулд бидэнд ажиглалт хэрэгтэй. Хүлээгдэж буй зан үйлийг бид хэрхэн тодорхойлох вэ? Ямар нэг бодлого, зарим дүрэм журмыг тодорхойлох замаар. Нээлттэй бодлогын агент төсөл нь хандалтаас эхлээд нөөцийн хуваарилалт хүртэлх хүрээг хамарсан энэхүү багц дүрмийг тодорхойлохоор ажиллаж байна.
Бидний хэлсэнчлэн манай системүүд улам бүр үйл явдалд тулгуурлаж байна. Сервергүй бол үйл явдалд тулгуурласан системийн гайхалтай жишээ юм. Үйл явдлыг систем хооронд дамжуулах, хянахын тулд бидэнд үйл явдлын талаар хэрхэн ярих, бие биедээ дамжуулах нийтлэг хэл, нийтлэг протокол хэрэгтэй. Төслийг ингэж нэрлэдэг .
Бидний системүүдийг байнга тогтворгүй болгож буй өөрчлөлтийн байнгын урсгал нь програм хангамжийн олдворуудын тасралтгүй урсгал юм. Энэхүү байнгын өөрчлөлтийн урсгалыг хадгалахын тулд бидэнд програм хангамжийн олдвор гэж юу болох, хэрхэн шалгагдсан, ямар шалгалтыг давсан талаар ярилцах нийтлэг протокол хэрэгтэй. Төслийг ингэж нэрлэдэг . Энэ нь програм хангамжийн олдворуудын нийтлэг мета өгөгдлийн протокол юм.
Эцэст нь хэлэхэд, хэрэв бид системээ бүрэн бие даасан, дасан зохицох чадвартай, өөрөө зохион байгуулалттай байлгахыг хүсч байвал тэдэнд өөрийгөө таних эрхийг өгөх ёстой. Төсөл дуудсан Энэ бол түүний хийдэг зүйл юм. Энэ нь мөн Cloud Native Computing сангийн ивээл дор хэрэгжиж буй төсөл юм.
Эдгээр төслүүд бүгд залуу, тэдэнд бидний хайр, бидний баталгаа хэрэгтэй. Энэ бүхэн нээлттэй эх сурвалж, бидний туршилт, хэрэгжилт. Тэд технологи хаашаа явж байгааг харуулж байна.
Гэхдээ DevOps хэзээ ч технологийн талаар голчлон анхаарч байгаагүй, энэ нь үргэлж хүмүүсийн хамтын ажиллагааны тухай байсаар ирсэн. Үүний дагуу хэрэв бидний хөгжүүлж буй системүүд өөрчлөгдөхийг хүсч байвал бид өөрсдөө өөрчлөгдөх ёстой. Үнэн хэрэгтээ бид ямар ч байсан өөрчлөгдөж байна, бидэнд сонголт байхгүй.
Гайхалтай зүйл байна Их Британийн зохиолч Рэйчел Ботсман, хүн төрөлхтний түүхийн туршид итгэлцлийн хувьслын тухай бичсэн. Тэрээр хэлэхдээ, анхдагч нийгэмд итгэлцэл нь орон нутгийн шинжтэй байсан, өөрөөр хэлбэл бид зөвхөн танил хүмүүст л итгэдэг байсан.
Дараа нь маш урт үе байсан - итгэлцэл төвлөрч, бид нэг төрийн эсвэл төрийн байгууллагад харьяалагддаг гэдгээрээ үл таних хүмүүст итгэж эхэлсэн харанхуй үе байсан.
Энэ бол бидний орчин үеийн ертөнцөд бидний харж байгаа зүйл юм: итгэлцэл улам бүр тархаж, төвлөрсөн бус болж, мэдээллийн урсгалын эрх чөлөө, мэдээллийн хүртээмж дээр суурилдаг.
Хэрэв та бодож байгаа бол энэ итгэлийг бий болгож байгаа энэхүү хүртээмжтэй байдал бол та бид хоёрын хэрэгжүүлж байгаа зүйл юм. Энэ нь хуучин мэдээллийн технологийн төвлөрсөн, шаталсан байгууллагууд ажиллахаа больсон тул бидний хамтран ажиллах арга барил, үүнийг хийх арга барил хоёулаа өөрчлөгдөх ёстой гэсэн үг юм. Тэд үхэж эхэлдэг.
DevOps байгууллагын үндэс
Ирээдүйн хамгийн тохиромжтой DevOps байгууллага бол бие даасан багаас бүрдэх төвлөрсөн бус, дасан зохицох систем бөгөөд тус бүр нь бие даасан хүмүүсээс бүрддэг. Эдгээр багууд дэлхий даяар тархсан бөгөөд асинхрон холбоог ашиглан бие биетэйгээ үр дүнтэй хамтран ажиллаж, өндөр ил тод харилцааны протоколуудыг ашигладаг. Маш үзэсгэлэнтэй, тийм үү? Маш сайхан ирээдүй.
Мэдээжийн хэрэг, соёлын өөрчлөлтгүйгээр эдгээрийн аль нь ч боломжгүй юм. Бид өөрчлөлтийн манлайлал, хувийн хариуцлага, дотоод урам зоригтой байх ёстой.
Энэ бол DevOps байгууллагын үндэс суурь юм: мэдээллийн ил тод байдал, асинхрон харилцаа холбоо, өөрчлөлтийн манлайлал, төвлөрлийг сааруулах.
Шатах
Бидний нэг хэсэг болсон системүүд болон бидний барьж буй системүүд улам эмх замбараагүй болж байгаа бөгөөд хүмүүс бид энэ бодлыг даван туулахад хэцүү, удирдлагын хуурмаг байдлаас татгалзахад хэцүү байдаг. Бид тэднийг үргэлжлүүлэн хянахыг хичээдэг бөгөөд энэ нь ихэвчлэн ядрахад хүргэдэг. Би үүнийг өөрийн туршлагаас хэлж байна, би бас шатсан, үйлдвэрлэлийн гэнэтийн бүтэлгүйтлээс болж тахир дутуу болсон.
Бид угаасаа хяналтгүй аливаа зүйлийг хянах гэж оролдох үед шаталт үүсдэг. Бид шатаж дуусаад шинэ зүйл хийх хүсэлгүй болж, өөрийгөө хамгаалж, байгаа зүйлээ хамгаалж эхэлдэг тул бүх зүйл утга учираа алддаг.
Инженерийн мэргэжил бол юуны түрүүнд бүтээлч мэргэжил гэдгийг өөртөө байнга сануулах дуртай байдаг. Хэрэв бид ямар нэгэн зүйлийг бүтээх хүсэл эрмэлзэлээ алдвал үнс болж, үнс болж хувирдаг. Хүмүүс шатаж, бүх байгууллага шатаж байна.
Миний бодлоор эмх замбараагүй байдлын бүтээлч хүчийг л хүлээн зөвшөөрч, түүний зарчмын дагуу хамтын ажиллагааг бий болгож байж л мэргэжлийнхээ сайн сайхныг алдахгүй байхад тустай.
Миний танаас хүсч байгаа зүйл бол ажилдаа дуртай, бидний хийж байгаа зүйлд дуртай. Энэ ертөнц мэдээллээр тэжээгддэг, бид үүнийг тэжээх нэр төрийн хэрэг. Тиймээс эмх замбараагүй байдлыг судалцгаая, эмх замбараагүй байцгаая, үнэ цэнийг бий болгоё, шинийг бий болгоё, яахав, асуудал бол бидний нэгэнт олж мэдсэнээр гарцаагүй, гарч ирэхэд нь бид зүгээр л “Ops!” гэж хэлээд асуудал шийдэгдэнэ. .
Chaos Monkey-ээс өөр юу вэ?
Ер нь энэ бүх хэрэгслүүд маш залуу байдаг. Яг ижил Netflix өөрсөддөө зориулж хэрэгслүүд бүтээжээ. Өөрийнхөө хэрэгслийг бий болго. Эмх замбараагүй инженерчлэлийн зарчмуудыг уншиж, хэн нэгний аль хэдийн бий болгосон бусад хэрэгслийг хайж олохын оронд эдгээр зарчмуудыг дагаж мөрдөөрэй.
Таны системүүд хэрхэн эвдэрч, эвдэрч, хэрхэн тэсвэрлэж байгааг ойлгохыг хичээ. Энэ хамгийн түрүүнд ирдэг. Мөн та багаж хэрэгслийг хайж болно. Бүх төрлийн төсөл байдаг.
Бүрэлдэхүүн хэсгүүдийг нь хялбарчлах замаар системийг хялбарчлах боломжгүй гэж хэлээд тэр даруй микро үйлчилгээ рүү шилжиж, бүрэлдэхүүн хэсгүүдийг өөрөө хялбарчилж, харилцан үйлчлэлийг хүндрүүлдэг тэр мөчийг би сайн ойлгосонгүй. Эдгээр нь үндсэндээ хоорондоо зөрчилддөг хоёр хэсэг юм.
Энэ нь зөв, микро үйлчилгээ нь ерөнхийдөө маш маргаантай сэдэв юм. Үнэн хэрэгтээ эд ангиудыг хялбарчлах нь уян хатан байдлыг нэмэгдүүлдэг. Микро үйлчилгээ юу өгдөг вэ? Тэд бидэнд уян хатан байдал, хурдыг өгдөг ч энгийн байдлыг өгдөггүй нь лавтай. Тэд хүндрэлийг нэмэгдүүлдэг.
Тэгэхээр DevOps философийн хувьд микро үйлчилгээ тийм ч сайн зүйл биш гэж үү?
Аливаа сайн сайхан урвуу талтай. Үүний давуу тал нь уян хатан байдлыг нэмэгдүүлж, өөрчлөлтийг илүү хурдан хийх боломжийг олгодог боловч бүхэл системийн нарийн төвөгтэй байдал, улмаар эмзэг байдлыг нэмэгдүүлдэг.
Гэсэн хэдий ч юуг илүү онцолж байна: харилцан үйлчлэлийг хялбарчлах уу эсвэл хэсгүүдийг хялбарчлах уу?
Мэдээжийн хэрэг, харилцан үйлчлэлийг хялбарчлахыг онцолж байна, учир нь бид үүнийг тантай хэрхэн хамтран ажиллаж байгаа талаас нь авч үзвэл, юуны өмнө бид ажлыг хялбарчлах биш харин харилцан үйлчлэлийг хялбарчлахад анхаарах хэрэгтэй. бидний хүн нэг бүр тус тусад нь. Учир нь ажлыг хөнгөвчлөх нь робот болж хувирна гэсэн үг. Энд McDonald's-т заавар байгаа үед энэ нь хэвийн ажилладаг: энд та бургераа тавьдаг, энд та соусаа хийнэ. Энэ нь бидний бүтээлч ажилд огт тохирохгүй.
Таны хэлсэн бүхэн өрсөлдөөнгүй ертөнцөд амьдардаг, эмх замбараагүй байдал нь маш эелдэг, энэ эмх замбараагүй байдал дотор ямар ч зөрчилдөөн байхгүй, хэн ч идэж, алахыг хүсдэггүй гэж үнэн үү? Өрсөлдөөн ба DevOps ямар байх ёстой вэ?
Яахав, ямар өрсөлдөөний тухай ярьж байгаагаас шалтгаална. Ажлын байран дахь өрсөлдөөн үү, эсвэл компаниуд хоорондын өрсөлдөөн үү?
Үйлчилгээ нь хэд хэдэн компани биш учраас оршин тогтнож буй үйлчилгээний өрсөлдөөний тухай. Бид шинэ төрлийн мэдээллийн орчинг бүрдүүлж байгаа бөгөөд ямар ч орчин өрсөлдөөнгүйгээр амьдрах боломжгүй. Хаа сайгүй өрсөлдөөн бий.
Яг ижил Netflix, бид тэднийг үлгэр жишээ болгон авдаг. Тэд яагаад ийм зүйл гаргасан бэ? Учир нь тэд өрсөлдөх чадвартай байх ёстой байсан. Хөдөлгөөний уян хатан байдал, хурд нь яг маш өрсөлдөөнт шаардлага бөгөөд энэ нь манай системд эмх замбараагүй байдлыг бий болгодог. Өөрөөр хэлбэл, эмх замбараагүй байдал бол бидний хүсч байгаа учраас ухамсартайгаар хийдэг зүйл биш, харин дэлхий үүнийг шаарддаг учраас тохиолддог зүйл юм. Бид зүгээр л дасан зохицох хэрэгтэй. Мөн эмх замбараагүй байдал нь өрсөлдөөний үр дүн юм.
Энэ нь эмх замбараагүй байдал нь зорилгогүй гэсэн үг үү? Эсвэл бидний харахыг хүсэхгүй байгаа зорилгууд уу? Бид байшинд байгаа бөгөөд бусдын зорилгыг ойлгохгүй байна. Өрсөлдөөн гэдэг нь бид тодорхой зорилготой, дараагийн мөч бүрт хаана хүрэхээ мэддэгтэй холбоотой. Энэ бол миний бодлоор DevOps-ийн мөн чанар юм.
Мөн асуултыг хараарай. Бид бүгдээрээ амьд үлдэх, үүнийг хийх нэг зорилготой гэж би бодож байна
хамгийн том таашаал. Мөн аливаа байгууллагын өрсөлдөөний зорилго нэг байдаг. Амьдрах нь ихэвчлэн өрсөлдөөнөөр дамждаг тул та юу ч хийж чадахгүй.
Энэ жилийн чуулган 7-р сарын 11-нд Технополист болно. Бид XNUMX-р сарын XNUMX хүртэл тайлангийн материалыг хүлээн авч байна. Хэрэв та ярихыг хүсвэл бидэнтэй холбоо барина уу.
Оролцогчдын бүртгэл нээлттэй, тасалбарын үнэ 7000 рубль байна. Бидэнтэй нэгд!
Эх сурвалж: www.habr.com