Орос дахь DevOps-ийн байдал 2020

Аливаа зүйлийн төлөв байдлыг хэрхэн ойлгох вэ?

Та янз бүрийн мэдээллийн эх сурвалж, тухайлбал вэбсайт дээрх нийтлэл, туршлагаас олж авсан санал бодолдоо найдаж болно. Та хамт ажиллагсад, танилуудаасаа асууж болно. Өөр нэг сонголт бол хурлын сэдвүүдийг харах явдал юм: хөтөлбөрийн хороо нь салбарын идэвхтэй төлөөлөгчид байдаг тул холбогдох сэдвүүдийг сонгоход бид тэдэнд итгэдэг. Тусдаа салбар бол судалгаа, тайлан юм. Гэхдээ асуудал байна. Дэлхий дахинд DevOps-ийн төлөв байдлын судалгааг жил бүр хийдэг, гадаадын компаниуд тайлан гаргадаг, Оросын DevOps-ийн талаар бараг мэдээлэл байдаггүй.

Харин ийм судалгаа хийсэн өдөр ирж, өнөөдөр үр дүнгийн талаар ярих болно. Орос дахь DevOps-ийн байдлыг компаниуд хамтран судалжээ.Экспресс 42"Мөн"Онтико". Экспресс 42 нь технологийн компаниудад DevOps-ийн дадлага, хэрэгслийг хэрэгжүүлэх, хөгжүүлэхэд тусалдаг бөгөөд Орост DevOps-ийн талаар анхлан ярьсан хүмүүсийн нэг юм. Судалгааны зохиогчид болох Игорь Курочкин, Виталий Хабаров нар Экспресс 42-д дүн шинжилгээ хийж, зөвлөгөө өгөхийн зэрэгцээ янз бүрийн компаниудад үйл ажиллагаа явуулж байсан техникийн мэдлэгтэй, туршлагатай байдаг. 8 жилийн турш хамт олон янз бүрийн асуудалтай, өөр өөр соёл, инженерийн төлөвшил бүхий гарааны бизнесээс эхлээд олон арван компани, төслүүдийг судалж үзсэн.

Игорь, Виталий нар илтгэлдээ судалгааны явцад ямар асуудал тулгараад байгаа, тэдгээрийг хэрхэн шийдвэрлэсэн, мөн DevOps судалгааг зарчмын хувьд хэрхэн явуулдаг, Express 42 яагаад өөрөө хийхээр шийдсэн тухай өгүүлэв. Тэдний тайланг үзэх боломжтой энд.

DevOps судалгаа

Ярилцлагыг Игорь Курочкин эхлүүлэв.

Бид DevOps-ийн бага хурлын үеэр үзэгчдээс "Та энэ жилийн DevOps-ын төлөв байдлын тайланг уншсан уу?" Цөөн хүн гараа өргөдөг бөгөөд бидний судалгаагаар гурав дахь нь л тэднийг судалж байгааг харуулсан. Хэрэв та ийм тайланг хэзээ ч харж байгаагүй бол бүгд ижил төстэй гэдгийг шууд хэлье. Ихэнхдээ "Өнгөрсөн жилтэй харьцуулахад ..." гэх мэт хэллэгүүд байдаг.

Энд бидэнд эхний асуудал байна, дараа нь дахиад хоёр асуудал байна:

1. Өнгөрсөн жилийн мэдээлэл бидэнд алга. Орос дахь DevOps-ийн байдал хэнд ч сонирхолгүй;
2. Арга зүй. Таамаглалыг хэрхэн шалгах, асуулт хэрхэн бүтээх, дүн шинжилгээ хийх, үр дүнг харьцуулах, холболтыг хэрхэн олох нь тодорхойгүй байна;
3. Нэр томьёо. Бүх тайлангууд англи хэл дээр, орчуулга хийх шаардлагатай, нийтлэг DevOps тогтолцоо хараахан зохион бүтээгдээгүй байгаа бөгөөд хүн бүр өөрийн гэсэн хувилбарыг гаргаж ирдэг.

Дэлхий даяар DevOps төлөв байдлын шинжилгээ хэрхэн хийгдсэнийг харцгаая.

Түүхэн үндэслэл

DevOps судалгааг 2011 оноос хойш хийж байна. Тохиргооны удирдлагын системийг зохион бүтээгч хүүхэлдэй хамгийн түрүүнд тэдгээрийг удирдан явуулсан. Тухайн үед энэ нь дэд бүтцийг код хэлбэрээр дүрслэх үндсэн хэрэгслийн нэг байсан. 2013 он хүртэл эдгээр судалгаанууд нь хаалттай судалгаа байсан бөгөөд олон нийтэд мэдээлдэггүй.

2013 онд DevOps дээрх бүх томоохон номыг хэвлэгч IT Revolution гарч ирэв. Хүүхэлдэйтэй хамт тэд DevOps-ийн анхны хэвлэлийг бэлтгэсэн бөгөөд 4 гол хэмжигдэхүүн анх удаа гарч ирэв. Дараа жил нь ThoughtWorks хэмээх зөвлөх компани аж үйлдвэрийн дадлага, багаж хэрэгслийн талаарх тогтмол технологийн радаруудаараа алдартай. Мөн 2015 онд аргачлалтай хэсэг нэмэгдэж, шинжилгээг хэрхэн хийдэг нь тодорхой болсон.

2016 онд судалгааны зохиогчид өөрсдийн DORA (DevOps Research and Assessment) компаниа байгуулж, жилийн тайлангаа нийтэлжээ. Дараа жил нь DORA болон Puppet сүүлийн хамтарсан тайлангаа гаргажээ.

Тэгээд нэг сонирхолтой зүйл эхэлсэн:

2018 онд компаниуд хуваагдаж, хоёр бие даасан тайлан гарсан: нэг нь хүүхэлдэй, хоёр дахь нь DORA Google-тэй хамтран гаргасан. DORA нь үндсэн хэмжүүрүүд, гүйцэтгэлийн профайл, үндсэн хэмжүүрүүд болон компанийн хэмжээнд гүйцэтгэлд нөлөөлдөг инженерийн практикт өөрийн арга зүйгээ үргэлжлүүлэн ашигласаар байна. Мөн хүүхэлдэй нь DevOps-ийн үйл явц, хувьслын тайлбар бүхий өөрийн арга барилыг санал болгосон. Гэвч энэ түүх үндэслэгдээгүй тул 2019 онд Хүүхэлдэй энэ аргачлалаас татгалзаж, үндсэн туршлагууд болон тэдний үзэл бодлоос DevOps-т хэрхэн нөлөөлдөг талаар жагсаасан тайлангийн шинэ хувилбарыг гаргасан. Дараа нь өөр нэг үйл явдал болсон: Google DORA-г худалдаж авсан бөгөөд тэд хамтдаа өөр нэг тайлан гаргасан. Та түүнийг харсан байж магадгүй.

Энэ жил бүх зүйл төвөгтэй болсон. Хүүхэлдэй өөрийн гэсэн судалгааг эхлүүлсэн нь мэдэгдэж байна. Тэд үүнийг биднээс долоо хоногийн өмнө хийсэн бөгөөд энэ нь аль хэдийн дууссан. Бид үүнд оролцож, ямар сэдвийг сонирхож байгааг харлаа. Одоо “Попет” дүн шинжилгээ хийж, тайлангаа гаргахаар бэлтгэж байна.

Гэхдээ DORA болон Google-ээс ямар нэгэн мэдэгдэл хийгээгүй байна. XNUMX-р сард судалгаа ихэвчлэн эхлэх үед DORA-г үүсгэн байгуулагчдын нэг Николь Форсгрен өөр компанид шилжсэн гэсэн мэдээлэл ирсэн. Тиймээс бид энэ жил DORA-аас судалгаа, тайлан гарахгүй гэж таамагласан.

Орост байдал ямар байна вэ?

Бид DevOps судалгаа хийгээгүй. Бид чуулган дээр үг хэлж, бусдын олж мэдсэн зүйлийг дахин ярьж, Райффайзенбанк 2019 онд "ДевОпсийн төлөв"-ийг орчуулсан (та тэдний мэдэгдлийг Habré дээрээс олж болно), тэдэнд маш их баярлалаа. Тэгээд энэ бүгд.

Тиймээс бид DORA-гийн арга зүй, дүгнэлтийг ашиглан Орос улсад өөрсдийн судалгаа хийсэн. Бид Райффайзенбанкны хамтран ажиллагсдын тайланг судалгаандаа, тэр дундаа нэр томъёо, орчуулгыг синхрончлоход ашигласан. Салбартай холбоотой асуултуудыг DORA тайлан болон энэ жилийн Хүүхэлдэйн асуулгын хуудаснаас авсан.

Судалгааны үйл явц

Тайлан нь зөвхөн эцсийн хэсэг юм. Судалгааны бүх үйл явц нь дөрвөн үндсэн үе шатаас бүрдэнэ.

Бэлтгэл үе шатанд бид салбарын мэргэжилтнүүдээс ярилцлага авч, таамаглалын жагсаалтыг бэлтгэсэн. Тэдгээрийн үндсэн дээр асуултуудыг нэгтгэж, наймдугаар сарыг бүхэлд нь санал асуулга явуулж эхэлсэн. Дараа нь бид дүн шинжилгээ хийж, тайлангаа өөрөө бэлтгэсэн. DORA-ийн хувьд энэ үйл явц 6 сар үргэлжилнэ. Бид 3 сарын дотор уулзсан бөгөөд одоо бидэнд хангалттай цаг байсангүй гэдгийг ойлгож байна: зөвхөн дүн шинжилгээ хийснээр та ямар асуулт асуух ёстойгоо ойлгох болно.

оролцогчид

Гадны бүх сурвалжлага оролцогчдын хөрөг зургаар эхэлдэг бөгөөд ихэнх нь Оросоос биш. ОХУ-ын судалгаанд оролцогчдын хувь жилээс жилд 5-1% хооронд хэлбэлздэг бөгөөд энэ нь ямар нэгэн дүгнэлт гаргах боломжийг олгодоггүй.

Accelerate State of DevOps 2019 тайлангийн газрын зураг:

Судалгааны явцад бид 889 хүнтэй ярилцлага хийж чадсан - энэ нь маш их юм (DORA тайландаа жил бүр мянга орчим хүнээс санал асуулга авдаг) бөгөөд энд бид зорилгодоо хүрсэн:

Манай бүх оролцогчид төгсгөлд хүрээгүй нь үнэн: гүйцэтгэлийн хувь нь хагасаас арай бага болсон. Гэхдээ энэ нь төлөөлөх дээж авч, шинжилгээ хийхэд хангалттай байсан. DORA тайландаа дүүргэлтийн хувийг задруулдаггүй тул энд харьцуулалт байхгүй.

Аж үйлдвэр, албан тушаал

Манай судалгаанд оролцогчид хэдэн арван салбарыг төлөөлдөг. Хагас нь мэдээллийн технологийн чиглэлээр ажилладаг. Үүний дараа санхүүгийн үйлчилгээ, худалдаа, харилцаа холбоо гэх мэт. Албан тушаалын дунд мэргэжилтнүүд (хөгжүүлэгч, шалгагч, ашиглалтын инженер) болон удирдлагын ажилтнууд (баг, бүлэг, талбайн дарга, захирал) орно.

Хоёр хүн тутмын нэг нь дунд хэмжээний компанид ажилладаг. Гурав дахь хүн бүр томоохон компаниудад ажилладаг. Ихэнх нь 9 хүртэлх хүнтэй багаар ажилладаг. Бид үндсэн үйл ажиллагааны талаар тусад нь асуусан бөгөөд ихэнх нь ямар нэгэн байдлаар үйл ажиллагаатай холбоотой бөгөөд 40 орчим хувь нь бүтээн байгуулалтад оролцож байна.

Тиймээс бид янз бүрийн салбар, компани, багуудын төлөөлөгчдийг харьцуулах, дүн шинжилгээ хийх зорилгоор мэдээлэл цуглуулсан. Шинжилгээний талаар миний хамтран зүтгэгч Виталий Хабаров хэлэх болно.

Шинжилгээ, харьцуулалт

Виталий Хабаров: Бидний судалгааг бөглөж, анкет бөглөж, цаашдын дүн шинжилгээ, таамаглалыг шалгахад шаардлагатай мэдээллээр хангасан бүх оролцогчдод маш их баярлалаа. Үйлчлүүлэгчид болон үйлчлүүлэгчдийнхээ ачаар бид салбарынхаа асуудлуудыг тодорхойлж, судалгаандаа туршиж үзсэн таамаглалыг боловсруулахад тусалсан баялаг туршлагатай болсон.

Харамсалтай нь, та нэг талаас асуултын жагсаалт, нөгөө талаас өгөгдөл авч, ямар нэгэн байдлаар харьцуулж, "Тийм ээ, бүх зүйл ийм байна, бидний зөв байсан" гэж хэлээд тарааж болохгүй. Үгүй ээ, бид эндүүрээгүй, бидний дүгнэлт найдвартай байхын тулд арга зүй, статистикийн аргууд хэрэгтэй. Дараа нь бид эдгээр өгөгдөл дээр үндэслэн цаашдын ажлаа хийж болно.

Гол хэмжүүрүүд

Бид "DevOps-ийн төлөв байдлыг хурдасгах" номонд дэлгэрэнгүй тайлбарласан DORA аргачлалыг үндэс болгон авсан. Бид гол хэмжүүрүүд нь Оросын зах зээлд тохирох эсэх, тэдгээрийг DORA-гийн ашигладаг "Оросын аж үйлдвэр гадаадын үйлдвэртэй хэр нийцэж байна вэ?" Гэсэн асуултад хариулахын тулд ашиглаж болох эсэхийг шалгасан.

Гол хэмжүүрүүд:

1. Байршуулах давтамж. Програмын шинэ хувилбарыг үйлдвэрлэлийн орчинд хэр олон удаа ашигладаг вэ (төлөвлөсөн өөрчлөлтүүд, засварууд болон ослын хариу үйлдлийг эс тооцвол)?
2. Хүргэгдэх хугацаа. Өөрчлөлт хийх (функцийг код болгон бичих) болон өөрчлөлтийг үйлдвэрлэлийн орчинд нэвтрүүлэх хооронд дундаж хугацаа хэд вэ?
3. Сэргээх хугацаа. Хэрэг явдал, үйлчилгээ муудсан эсвэл програмын хэрэглэгчдэд нөлөөлж буй алдаа илрүүлсний дараа програмыг үйлдвэрлэлийн орчинд сэргээхэд дунджаар хэр хугацаа шаардагдах вэ?
4. Амжилтгүй өөрчлөлтүүд. Үйлдвэрлэлийн орчинд байршуулсан ажлын хэдэн хувь нь программ хангамжийн доройтол эсвэл осолд хүргэж, засч залруулах шаардлагатай (өөрчлөлтүүдийг буцаах, засвар эсвэл засварыг боловсруулах) вэ?

DORA судалгаандаа эдгээр хэмжүүрүүд болон байгууллагын гүйцэтгэлийн хоорондын уялдаа холбоог олж тогтоосон. Бид үүнийг бас судалгаандаа туршиж үздэг.

Гэхдээ дөрвөн гол хэмжүүр нь ямар нэгэн зүйлд нөлөөлж чадах эсэхийг мэдэхийн тулд та ойлгох хэрэгтэй - тэдгээр нь хоорондоо ямар нэгэн байдлаар холбоотой юу? DORA нэг анхааруулгатай эерэгээр хариулав: амжилтгүй өөрчлөлтүүд (Өөрчлөлтийн бүтэлгүйтлийн түвшин) болон бусад гурван хэмжигдэхүүний хоорондын хамаарал арай сул байна. Бид ижил зураг авсан. Хэрэв хүргэх хугацаа, байршуулах давтамж, сэргээх хугацаа нь хоорондоо уялдаатай байвал (бид энэ хамаарлыг Пирсоны хамаарал болон Чаддокийн масштабаар тогтоосон) амжилтгүй өөрчлөлттэй тийм хүчтэй хамаарал байхгүй болно.

Зарчмын хувьд судалгаанд хамрагдагсдын ихэнх нь үйлдвэрлэлд цөөн тооны осол гардаг гэж хариулдаг. Хэдийгээр амжилтгүй өөрчлөлтийн хувьд судалгаанд оролцогчдын бүлгүүдийн хооронд мэдэгдэхүйц ялгаа байсаар байгааг бид дараа нь харах болно, гэхдээ бид энэ хэмжигдэхүүнийг энэ хуваалтад ашиглах боломжгүй байна.

Бид үүнийг (манай зарим үйлчлүүлэгчидтэй дүн шинжилгээ хийж, харилцах явцад олж мэдсэн) үйл явдал гэж үзэж буй зүйлийн талаархи ойлголт бага зэрэг ялгаатай байгаатай холбон тайлбарлаж байна. Хэрэв бид техникийн цонхны үеэр үйлчилгээнийхээ гүйцэтгэлийг сэргээж чадсан бол үүнийг осол гэж үзэж болох уу? Үгүй байх, бид бүгдийг зассан болохоор бид мундаг. Бидний хувьд ердийн, танил горимоор өргөдлөө 10 удаа дахин гүйлгэх шаардлагатай бол бид үүнийг осол гэж үзэж болох уу? Үгүй бололтой. Тиймээс бүтэлгүйтсэн өөрчлөлтүүд бусад хэмжигдэхүүнтэй харьцах эсэх асуудал нээлттэй хэвээр байна. Бид үүнийг улам боловсронгуй болгох болно.

Энд бид хүргэх хугацаа, сэргээх хугацаа, байршуулах давтамж хоёрын хооронд ихээхэн хамааралтай болохыг олж мэдсэн нь чухал юм. Тиймээс бид судалгаанд оролцогчдыг гүйцэтгэлийн бүлгүүдэд хуваахын тулд эдгээр гурван хэмжүүрийг авсан.

Грамм хэр их өлгөх вэ?

Бид шаталсан кластерын шинжилгээг ашигласан:

• Бид хариулагчдыг n хэмжээст орон зайд хуваарилдаг бөгөөд үүнд оролцогч бүрийн координат нь тэдний асуултын хариулт юм.
• Хариуцагч бүрийг жижиг кластер гэж зарласан.
• Бид хоорондоо хамгийн ойр байгаа хоёр кластерыг нэг том кластер болгон нэгтгэдэг.
• Бид дараагийн хос кластеруудыг олж, илүү том кластер болгон нэгтгэдэг.

Ингэж бид бүх судалгаанд оролцогчдоо хэрэгтэй кластерын тоогоор бүлэглэдэг. Дендрограмм (кластер хоорондын холболтын мод) тусламжтайгаар бид хоёр хөрш зэргэлдээх кластеруудын хоорондох зайг хардаг. Бидний хувьд эдгээр кластеруудын хооронд тодорхой зайны хязгаар тогтоож, "Энэ хоёр бүлэг нь бие биенээсээ нэлээд ялгаатай, учир нь тэдгээрийн хоорондох зай асар том" гэж хэлэх л үлдлээ.

Гэхдээ энд нуугдмал асуудал бий: бид кластерын тоонд ямар ч хязгаарлалт байхгүй - бид 2, 3, 4, 10 кластер авах боломжтой. Эхний санаа нь - яагаад манай бүх судалгаанд оролцогчдыг DORA шиг 4 бүлэгт хувааж болохгүй гэж. Гэхдээ бид эдгээр бүлгүүдийн хоорондын ялгаа өчүүхэн болж байгааг олж мэдсэн бөгөөд хариуцагч нь хөрш зэргэлдээх бүлэгт биш харин түүний бүлэгт харьяалагддаг гэдэгт бид итгэлтэй байж чадахгүй. Бид Оросын зах зээлийг дөрвөн бүлэгт хувааж чадахгүй байна. Тиймээс бид статистикийн хувьд мэдэгдэхүйц ялгаа байгаа гурван профайл дээр тогтсон.

Дараа нь бид профайлыг кластераар тодорхойлсон: бид бүлэг тус бүрийн хэмжигдэхүүн бүрийн медианыг авч, гүйцэтгэлийн профайлын хүснэгтийг эмхэтгэсэн. Үнэн хэрэгтээ бид бүлэг бүрийн дундаж оролцогчийн гүйцэтгэлийн профайлыг авсан. Бид үр ашгийн гурван профайлыг тодорхойлсон: Бага, Дунд, Өндөр:

Гүйцэтгэлийн профайлыг тодорхойлоход 4 үндсэн хэмжүүр тохиромжтой гэсэн таамаглалыг бид эндээс баталж, барууны болон Оросын зах зээлд хоёуланд нь ажилладаг. Бүлгүүдийн хооронд ялгаа байгаа бөгөөд энэ нь статистик ач холбогдолтой юм. Хэдийгээр бид анх судалгаанд оролцогчдыг энэ параметрээр хуваагаагүй ч дундаж үзүүлэлтийн хувьд амжилтгүй өөрчлөлтийн хэмжүүрийн хувьд гүйцэтгэлийн профайлуудын хооронд мэдэгдэхүйц ялгаа байгааг би онцолж байна.

Дараа нь асуулт гарч ирнэ: энэ бүгдийг хэрхэн ашиглах вэ?

Яаж хэрэглэх вэ

Хэрэв бид ямар нэгэн баг, 4 гол хэмжигдэхүүнийг авч, хүснэгтэд хэрэглэвэл 85% тохиолдолд бид бүрэн тохирохгүй - энэ бол зүгээр л дундаж оролцогч бөгөөд бодит байдал дээр байгаа зүйл биш юм. Бид бүгд (мөн баг бүр) арай өөр.

Бид шалгасан: бид хариулагчдынхаа болон DORA-ийн гүйцэтгэлийн профайлыг авч, хэдэн оролцогч энэ эсвэл өөр профайлтай таарч байгааг харав. Судалгаанд хамрагдагсдын ердөө 16% нь аль нэгэн профайлд орсон болохыг бид олж мэдсэн. Үлдсэн бүхэн нь хаа нэгтээ тараагдсан байна:

Энэ нь үр ашгийн профайл нь хязгаарлагдмал хүрээтэй гэсэн үг юм. Эхний ойролцоо байгаа газраа ойлгохын тулд та энэ хүснэгтийг ашиглаж болно: "Өө, бид Дунд эсвэл Дээд зэрэгт ойр байх шиг байна!" Хэрэв та хаашаа явахаа ойлговол энэ нь хангалттай байж магадгүй юм. Гэхдээ таны зорилго тогтмол, тасралтгүй сайжирч, хаана хөгжих, юу хийхээ илүү сайн мэдэхийг хүсч байвал нэмэлт хөрөнгө хэрэгтэй болно. Бид тэднийг тооцоолуур гэж нэрлэдэг:

• DORA тооцоолуур
• Тооны машин Express 42* (хөгжүүлж байгаа)
• Өөрийн хөгжүүлэлт (та өөрийн дотоод тооцоолуурыг үүсгэж болно).

Тэд юунд хэрэгтэй вэ? Ойлгох:

• Манай байгууллагын хамт олон манай стандартад нийцэж байна уу?
• Үгүй бол манай компанийн эзэмшсэн мэргэжлийн ур чадварын хүрээнд хурдасгаж тусалж чадах уу?
• Хэрэв тийм бол бид илүү сайн хийж чадах уу?

Та мөн компанийн доторх статистик мэдээллийг цуглуулахын тулд тэдгээрийг ашиглаж болно:

• Бидэнд ямар багууд байна вэ?
• Багуудыг профайл болгон хуваах;
• Харна уу: Өө, эдгээр командууд хангалтгүй ажиллаж байна (тэдгээр нь бага зэрэг татдаггүй), гэхдээ эдгээр нь гайхалтай: тэд өдөр бүр, алдаагүй, нэг цаг хүрэхгүй хугацаатай ажилладаг.

Дараа нь та манай компанид эдгээр багуудад шаардлагатай туршлага, багаж хэрэгсэл байгааг олж мэдэх боломжтой.

Эсвэл, хэрэв та компани дотроо өөрийгөө маш сайн мэдэрдэг, олон хүнээс илүү гэдгээ ойлгодог бол арай илүү том харагдаж болно. Энэ бол зөвхөн Оросын үйлдвэр юм: бид өөрсдийгөө хурдасгахын тулд Оросын үйлдвэрт шаардлагатай мэдлэгийг олж авч чадах уу? Экспресс 42 тооцоолуур энд туслах болно (энэ нь боловсруулагдаж байна). Хэрэв та Оросын зах зээлээс илүү гарсан бол хараарай DORA тооцоолуур мөн дэлхийн зах зээлд.

Сайн байна. Хэрэв та DORA тооцоолуур дээрх Элит бүлэгт байгаа бол яах ёстой вэ? Энд сайн шийдэл байхгүй. Та энэ салбарын тэргүүн эгнээнд байх магадлалтай бөгөөд дотоод судалгаа, боловсруулалт, илүү их нөөцийг зарцуулснаар цаашдын хурдатгал, найдвартай байдал боломжтой болно.

Хамгийн амттай - харьцуулалт руу шилжье.

Харьцуулалт

Бид эхэндээ Оросын аж үйлдвэрийг барууны аж үйлдвэртэй харьцуулахыг хүссэн. Хэрэв бид шууд харьцуулж үзвэл бид цөөн тооны профайлтай бөгөөд тэдгээр нь хоорондоо арай илүү холилдсон бол хил хязгаар нь арай бүдэгэрсэн байна:

Манай элит жүжигчид Өндөр жүжигчдийн дунд нуугдаж байдаг, гэхдээ тэд тэнд байдаг - эдгээр нь мэдэгдэхүйц өндөрлөгт хүрсэн элит, ганц эвэртүүд юм. Орос улсад Элит профайл ба Өндөр зэрэглэлийн хоорондох ялгаа хараахан хангалттай биш байна. Ирээдүйд инженерийн соёл, инженерийн практикийг хэрэгжүүлэх чанар, компаниудын туршлагаас үүдэн энэ тусгаарлалт бий болно гэж бид бодож байна.

Хэрэв бид Оросын үйлдвэрлэлийн хүрээнд шууд харьцуулалт хийх юм бол өндөр зэрэглэлийн багууд бүх талаараа илүү байгааг харж болно. Эдгээр хэмжигдэхүүнүүд болон байгууллагын гүйцэтгэлийн хооронд хамаарал байдаг гэсэн таамаглалыг бид мөн баталсан: Өндөр зэрэглэлийн багууд зорилгодоо хүрэхээс гадна зорилгодоо хүрэх магадлал өндөр байдаг.
Өндөр зэрэглэлийн баг болж, үүгээр зогсохгүй:

Гэхдээ энэ жил онцгой бөгөөд бид цар тахлын үед компаниуд хэрхэн ажиллаж байгааг шалгахаар шийдсэн: Өндөр зэрэглэлийн багууд салбарын дунджаас хамаагүй сайн ажиллаж, илүү сайн мэдэрч байна:

• Шинэ бүтээгдэхүүн гаргах магадлал 1,5-2 дахин их,
• Хэрэглээний дэд бүтцийн найдвартай байдал ба/эсвэл гүйцэтгэлийг сайжруулах магадлал 2 дахин их.

Өөрөөр хэлбэл, тэдний аль хэдийн олж авсан ур чадвар нь тэднийг илүү хурдан хөгжүүлэх, шинэ бүтээгдэхүүн гаргах, одоо байгаа бүтээгдэхүүнийг өөрчлөх, улмаар шинэ зах зээл, шинэ хэрэглэгчдийг эзлэхэд тусалсан:

Манай багуудад өөр юу тусалсан бэ?

Инженерийн практик

Бидний туршсан дадлага тус бүрийн чухал үр дүнгийн талаар би танд хэлэх болно. Магадгүй өөр зүйл багуудад тусалсан байх, гэхдээ бид DevOps-ийн тухай ярьж байна. DevOps дотроос бид өөр өөр профайлтай багуудын ялгааг олж хардаг.

Үйлчилгээ болгон платформ

Бид платформын нас болон багийн профайлын хооронд мэдэгдэхүйц хамаарлыг олж чадаагүй: Платформууд бага ба өндөр багуудын аль алинд нь нэгэн зэрэг гарч ирсэн. Гэхдээ сүүлийнх нь платформ нь дунджаар илүү олон үйлчилгээ, программчлалын интерфейсээр хангадаг. Мөн платформын багууд өөрсдийн хөгжүүлэгчид болон багуудад платформыг ашиглахад нь тусалж, тэдний асуудал, платформтой холбоотой тохиолдлыг илүү олон удаа шийдэж, бусад багийг сургах магадлал өндөр байдаг.

Дэд бүтцийг код болгон

Энд бүх зүйл нэлээд стандарт юм. Дэд бүтцийн кодын ажлыг автоматжуулах, дэд бүтцийн агуулахад хэр их мэдээлэл хадгалагдаж байгаа хоорондын хамаарлыг бид олж мэдсэн. Өндөр түвшний командууд нь репозиторуудад илүү их мэдээллийг хадгалдаг: энэ нь дэд бүтцийн тохиргоо, CI / CD дамжуулах хоолой, орчны тохиргоо, бүтээх параметрүүд юм. Тэд энэ мэдээллийг илүү олон удаа хадгалж, дэд бүтцийн кодтой илүү сайн ажиллаж, дэд бүтцийн кодтой ажиллах илүү олон процесс, даалгавруудыг автоматжуулдаг.

Сонирхолтой нь, бид дэд бүтцийн туршилтуудад мэдэгдэхүйц ялгаа хараагүй. Би үүнийг өндөр түвшний багууд ерөнхийдөө тестийн автоматжуулалттай байдагтай холбон тайлбарлаж байна. Тэд дэд бүтцийн туршилтаар тусад нь анхаарал сарниулах ёсгүй, харин програмуудыг шалгадаг тестүүд бөгөөд тэдний ачаар тэд юу, хаана эвдэрсэнээ аль хэдийн олж хардаг.

Интеграци ба хүргэлт

Хамгийн уйтгартай хэсэг, учир нь бид танд илүү их автоматжуулалттай байх тусам кодтой сайн ажиллах тусам илүү сайн үр дүнд хүрэх магадлал өндөр болно гэдгийг бид баталсан.

архитектур

Бид бичил үйлчилгээ гүйцэтгэлд хэрхэн нөлөөлж байгааг харахыг хүссэн. Үнэн хэрэгтээ, микро үйлчилгээг ашиглах нь гүйцэтгэлийн үзүүлэлтүүдийн өсөлттэй холбоогүй тул тийм биш юм. Бичил үйлчилгээнүүд нь өндөр түвшний командууд болон бага зэрэглэлийн командуудад ашиглагддаг.

Гэхдээ хамгийн чухал зүйл бол өндөр түвшний багуудын хувьд бичил үйлчилгээний архитектурт шилжсэнээр үйлчилгээгээ бие даан хөгжүүлж, нэвтрүүлэх боломжийг олгодог. Хэрэв архитектур нь хөгжүүлэгчдэд багийн гаднах хэн нэгнийг хүлээхгүйгээр бие даан ажиллах боломжийг олгодог бол энэ нь хурдыг нэмэгдүүлэх гол чадвар юм. Энэ тохиолдолд микро үйлчилгээнүүд тусалдаг. Зөвхөн тэдний хэрэгжилт нь тийм ч чухал үүрэг гүйцэтгэдэггүй.

Энэ бүхнийг бид хэрхэн олж мэдсэн бэ?

Бид DORA аргачлалыг бүрэн хуулбарлах амбицтай төлөвлөгөөтэй байсан ч нөөц хомс байсан. Хэрэв DORA ивээн тэтгэгч их ашигладаг, тэдний судалгаа хагас жил болдог бол бид судалгаагаа богино хугацаанд хийсэн. Бид DORA шиг DevOps загварыг бүтээхийг хүссэн бөгөөд үүнийг ирээдүйд хийх болно. Одоогоор бид дулааны зураглалаар хязгаарлагдаж байна:

Бид инженерийн дадлагын хуваарилалтыг профайл тус бүрээр нь судалж үзээд өндөр зэрэглэлийн багууд дунджаар инженерийн дадлагыг илүү ашигладаг болохыг олж мэдсэн. Та энэ бүхний талаар илүү ихийг манай нийтлэлээс уншиж болно тайлагнах.

Өөрчлөлт хийхийн тулд нарийн төвөгтэй статистикаас энгийн статистик руу шилжье.

Бид өөр юу олж мэдсэн бэ?

Хэрэгсэл

Ихэнх командуудыг Линукс гэр бүлийн үйлдлийн систем ашигладаг болохыг бид харж байна. Гэхдээ Windows нь чиг хандлагатай хэвээр байна - манай судалгаанд оролцогчдын дор хаяж дөрөвний нэг нь түүний аль нэг хувилбарыг ашигласан гэж тэмдэглэжээ. Зах зээлд ийм хэрэгцээ байгаа бололтой. Тиймээс та эдгээр чадварыг хөгжүүлж, чуулганд илтгэл тавьж болно.

Оркеструудын дунд энэ нь хэнд ч нууц биш, Кубернетес тэргүүлдэг (52%). Дараагийн ээлжийн найруулагч нь Docker Swarm (ойролцоогоор 12%) юм. Хамгийн алдартай CI систем нь Jenkins болон GitLab юм. Хамгийн алдартай тохиргооны удирдлагын систем бол Ansible, дараа нь бидний хайртай Shell юм.

Амазон нь одоогоор тэргүүлэгч үүлэн хостинг үйлчилгээ үзүүлэгч юм. Оросын үүлсийн эзлэх хувь аажмаар нэмэгдэж байна. Ирэх жил Оросын үүлэн үйлчилгээ үзүүлэгчид ямар сэтгэгдэлтэй байх, тэдний зах зээлд эзлэх хувь нэмэгдэх эсэх нь сонирхолтой байх болно. Тэдгээрийг ашиглаж болно, энэ нь сайн:

Би Игорь руу үг хэлье, тэр дахиад хэдэн статистик мэдээлэл өгөх болно.

Туршлагыг түгээх

Игорь Курочкин: Бид тус тусад нь судалгаанд оролцогчдоос инженерийн практикийг компанид хэрхэн хуваарилж байгааг зааж өгөхийг хүссэн. Ихэнх компаниудад янз бүрийн хэв маягаас бүрдэх холимог арга байдаг бөгөөд туршилтын төслүүд маш их алдартай байдаг. Бид мөн профайлуудын хооронд бага зэрэг ялгаатай байгааг харсан. Мэргэжилтнүүдийн жижиг багууд ажлын процесс, багаж хэрэгслийг өөрчилж, амжилттай туршлагыг бусад багтай хуваалцах үед Өндөр түвшний төлөөлөгчид "Доороос гарах санаачилга" загварыг ихэвчлэн ашигладаг. Medium-д энэ нь олон нийт, шилдэг төвүүдийг бий болгох замаар компанийг бүхэлд нь хамарсан дээрээс доош чиглэсэн санаачилга юм.

Agile болон DevOps

Agile болон DevOps хоёрын холболтын тухай асуудал энэ салбарт байнга яригддаг. Энэ асуудлыг 2019/2020 оны Agile байдлын тайланд мөн тусгасан тул бид Agile болон DevOps үйл ажиллагаа нь компаниудад хэрхэн холбогдож байгааг харьцуулахаар шийдлээ. Agile-гүй DevOps нь ховор гэдгийг бид олж мэдсэн. Судалгаанд оролцогчдын тал хувь нь Agile-ийн тархалт хамаагүй эрт эхэлсэн бөгөөд 20 орчим хувь нь нэгэн зэрэг эхэлснийг ажигласан бөгөөд Agile болон DevOps дадлага байхгүй байгаа нь бага зэрэглэлийн шинж тэмдгүүдийн нэг байх болно.

Тушаалын топологи

Өнгөрсөн оны сүүлээр номБагийн топологи”, тушаалын топологийг тайлбарлах хүрээг санал болгодог. Энэ нь Оросын компаниудад хамаарах эсэх нь бидэнд сонирхолтой болсон. Тэгээд бид "Та ямар хэв маягийг олж байна вэ?" Гэсэн асуултыг асуув.

Судалгаанд хамрагдагсдын тал хувь нь дэд бүтцийн багууд, мөн хөгжүүлэлт, туршилт, ашиглалтын тусгай багууд ажиглагдаж байна. Тусдаа DevOps багууд 45% -ийг тэмдэглэсэн бөгөөд тэдгээрийн дунд High-ийн төлөөлөгчид илүү түгээмэл байдаг. Дараа нь өндөр түвшинд илүү түгээмэл байдаг хөндлөн чиг үүрэг бүхий багууд ирдэг. Тусдаа SRE командууд Өндөр, Дунд зэргийн профайл дээр гарч ирэх ба Доод профайл дээр ховор харагддаг:

DevQaOps харьцаа

Skyeng платформын багийн ахлагчаас бид Facebook дээр энэ асуултыг харсан - тэр компаниуд дахь хөгжүүлэгчид, тестер, администраторуудын харьцааг сонирхож байсан. Бид үүнийг асууж, профайл дээр тулгуурлан хариултуудыг харлаа: Өндөр түвшний төлөөлөгчид хөгжүүлэгч бүрийн хувьд цөөн тооны туршилт, үйл ажиллагааны инженертэй байдаг:

2021 оны төлөвлөгөө

Ирэх жилийн төлөвлөгөөнд оролцогчид дараахь ажлуудыг тэмдэглэв.

Та DevOps Live 2020 бага хурлын уулзварыг эндээс харж болно. Бид хөтөлбөрийг сайтар хянаж үзсэн:

• Дэд бүтэц нь бүтээгдэхүүн
• DevOps хувиргалт
• DevOps туршлагын хуваарилалт
• DevSecOps програмууд
• Кейсийн клуб, хэлэлцүүлэг

Гэхдээ бидний танилцуулах хугацаа бүх сэдвийг хамрахад хангалтгүй юм. Хөшигний ард үлдсэн:

• Платформыг үйлчилгээ болон бүтээгдэхүүн болгон;
• Дэд бүтэц нь код, орчин, үүл;
• Тасралтгүй нэгтгэх, хүргэх;
• Архитектур;
• DevSecOps загварууд;
• Платформ ба хөндлөн функциональ багууд.

Тайлан Бид 50 хуудастай, та үүнийг илүү дэлгэрэнгүй үзэх боломжтой.

Дуусгах

Бидний судалгаа, тайлан нь танд хөгжүүлэлт, туршилт, үйл ажиллагааны шинэ хандлагуудыг туршиж үзэхэд урам зориг өгөхөөс гадна судалгаанд оролцож буй бусад оролцогчидтой өөрийгөө харьцуулах, өөрийн арга барилаа сайжруулах талбаруудыг тодорхойлоход тань тусална гэж найдаж байна.

Орос дахь DevOps-ийн төлөв байдлын анхны судалгааны үр дүн:

• Гол хэмжүүрүүд. Гол хэмжүүрүүд (хүргэх хугацаа, байршуулах давтамж, сэргээх хугацаа, өөрчлөлтийн алдаа) нь хөгжүүлэлт, туршилт, үйл ажиллагааны үйл явцын үр нөлөөг шинжлэхэд тохиромжтой болохыг бид олж мэдсэн.
• Профайл Өндөр, Дунд, Бага. Цуглуулсан мэдээлэлд үндэслэн бид хэмжигдэхүүн, практик, үйл явц, хэрэглүүрийн хувьд өвөрмөц онцлог бүхий Өндөр, Дунд, Бага гэсэн статистикийн ялгаатай бүлгүүдийг ялгаж чадна. Өндөр зэрэглэлийн төлөөлөгчид намаас илүү сайн үр дүнг харуулдаг. Тэд зорилгодоо хүрэх, давах магадлал өндөр байдаг.
• Үзүүлэлтүүд, тахал өвчин, 2021 оны төлөвлөгөө. Энэ жилийн онцгой үзүүлэлт бол компаниуд тахал өвчнийг хэрхэн даван туулсан бэ. Дээд түвшний төлөөлөгчид илүү сайн ажиллаж, хэрэглэгчдийн оролцоо нэмэгдэж, амжилтанд хүрэх гол шалтгаан нь үр ашигтай хөгжүүлэлтийн процесс, хүчтэй инженерийн соёл байв.
• DevOps-ийн дадлага, хэрэгсэл, тэдгээрийн хөгжил. Компаниудын ирэх жилийн үндсэн төлөвлөгөөнд DevOps-ийн дадлага, хэрэгслийг хөгжүүлэх, DevSecOps-ийн практикийг нэвтрүүлэх, байгууллагын бүтцэд өөрчлөлт оруулах зэрэг багтана. DevOps-ийн туршлагыг үр дүнтэй хэрэгжүүлэх, хөгжүүлэх нь туршилтын төслүүд, олон нийт, мэргэжлийн ур чадварын төвүүдийг бий болгох, компанийн дээд, доод түвшний санаачлагуудын тусламжтайгаар хийгддэг.

Бид таны санал хүсэлт, түүх, санал хүсэлтийг сонсох дуртай. Судалгаанд оролцсон бүх хүмүүст баярлалаа, ирэх жил таны оролцоог тэсэн ядан хүлээж байна.

Эх сурвалж: www.habr.com