Би саяхан Logrocon зохион байгуулсан DevOpsForum 2019-д оролцсон. Энэхүү хуралд оролцогчид бизнес, хөгжил, мэдээллийн технологийн үйлчилгээний мэргэжилтнүүдийн хооронд үр дүнтэй харилцах шийдэл, шинэ арга хэрэгслийг хайж олохыг хичээсэн.
Чуулган амжилттай болж өнгөрлөө: үнэхээр олон хэрэгтэй илтгэлүүд, сонирхолтой илтгэлийн хэлбэрүүд, илтгэгчидтэй маш их харилцах байсан. Хэн ч надад юу ч худалдахыг оролдоогүй нь онцгой чухал бөгөөд сүүлийн үед томоохон хурал дээр илтгэгчид буруутай.
Raiffeisenbank, Alfastrakhovanie, Mango Telecom-ийн автоматжуулалтыг хэрэгжүүлэх туршлага болон бусад нарийн ширийн зүйлсийн талаархи илтгэлүүдийн хэсгээс.
Намайг Яна гэдэг, би шалгагчаар ажилладаг, автоматжуулалт, түүнчлэн DevOps хийдэг, хурал, уулзалтад явах дуртай. Сүүлийн хоёр жилийн хугацаанд би Олег Буниний бага хурал (HighLoad++, TeamLead Conf), Jug арга хэмжээ (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow зэрэгт оролцсон.
Юуны өмнө би хурлын хөтөлбөрт анхаарлаа хандуулж байна. Би илтгэл юу болох талаар бага, харин илтгэгч рүү илүү хардаг. Тайлан нь маш технологитой, сонирхолтой болсон ч тайлангийн шилдэг туршлагыг өөрийн компанидаа хэрэгжүүлэх боломжтой гэдэг нь баримт биш юм. Дараа нь танд чанга яригч хэрэгтэй.
Райффайзенбанк дахь дамжуулах хоолойн төгсгөлд гэрэл
Ихэвчлэн би өөрийн сонирхсон спикерийг хажуу талаас нь хайдаг. DevOpsForum 2019 дээр Райффайзенбанкны илтгэгч Михаил Бижан миний сонирхлыг татав. Тэрээр илтгэлийнхээ үеэр багуудаа DevOps-д хэрхэн аажмаар холбож байгаа, яагаад хэрэгтэй байгаа, DevOps-ийг өөрчлөх санааг бизнест хэрхэн зарах талаар ярилцав. За тэгээд ерөнхийдөө хоолойны үзүүрт байгаа гэрлийг яаж харах вэ гэж ярилаа.
Михаил Бижан, Райффайзенбанкны автоматжуулалтын захирал
Одоо тэдний компанид "DevOps" байхгүй. Энэ нь тэр ажилладаг, гэхдээ бүх багт биш. DevOps-ийг хэрэгжүүлэхдээ тэд тодорхой инженерүүдийн хувьд, мөн бүтээгдэхүүний хэрэгцээ, энэ бүтээгдэхүүнийг бий болгосон платформын төлөвшлийн хувьд багуудын бэлэн байдалд тулгуурладаг. Миша DevOps яагаад хэрэгтэй байгааг бизнест хэрхэн тайлбарлахыг хэлэв.
Банкны сегмент нь өсөлтийн хэд хэдэн хүчин зүйлтэй байдаг: үйлчилгээний өртөг, үйлчлүүлэгчийн баазыг өргөжүүлэх. Үйлчилгээний өртгийг нэмэгдүүлэх нь тийм ч сайн хөшүүрэг биш, харин үйлчлүүлэгчийн баазыг нэмэгдүүлэх нь эсрэгээрээ. Хэрэв өрсөлдөгчид бодитой дажгүй бүтээгдэхүүн гаргавал бүх үйлчлүүлэгчид тийшээ очдог бөгөөд дараа нь цаг хугацаа өнгөрөхөд зах зээл жигдэрч эхэлдэг. Тиймээс зах зээлд шинэ бүтээгдэхүүн нэвтрүүлэх, түүнийг нэвтрүүлэх хурд нь банкуудын гол анхаарлаа хандуулдаг зүйл юм. DevOps нь яг ийм зорилготой бөгөөд бизнесүүд үүнийг ойлгодог.
Дараагийн чухал тэмдэглэл: DevOps нь зах зээлд гарах хугацааг үргэлж бууруулдаггүй. DevOps нь дангаараа ажиллах боломжгүй бөгөөд энэ нь хөгжүүлэлтээс үйлдвэрлэл хүртэл (кодоос хэрэглэгч хүртэл) бүтээгдэхүүнийг бий болгох, зах зээлд гаргах үйл явцын зөвхөн нэг хэсэг юм. Гэхдээ кодын өмнөх бүх зүйл DevOps-тэй шууд холбоотой биш юм. Өөрөөр хэлбэл, маркетерууд олон жилийн турш зах зээлийг судалж, бүх амьдралаа өрсөлдөгчдөө гүйцэж өнгөрөөх боломжтой. Үйлчлүүлэгчид юу хэрэгтэй байгааг хурдан ойлгож, энэ эсвэл бусад функцийг хэрэгжүүлэхийг төлөвлөх шаардлагатай байдаг - ихэнхдээ энэ нь DevOps ажиллах, компани зорилгодоо хүрэхэд хангалтгүй байдаг. Тиймээс юуны түрүүнд Райффайзенбанк DevOps-ийг хэрхэн ашиглах талаар суралцах шаардлагатай гэж бизнес эрхлэгчидтэй санал нэгдэв. Автоматжуулалтын төлөөх автоматжуулалт нь шинэ үйлчлүүлэгчдийн төлөөх тэмцэлд тийм ч их тус болохгүй.
Ерөнхийдөө Миша DevOps-ийг хэрэгжүүлэх хэрэгтэй, гэхдээ ухаалаг байх ёстой гэж үздэг. Өөрчлөлтийн эхэн үед багийн бүтээмж буурч, бага мөнгө олох болно, гэхдээ дараа нь зөвтгөх болно гэдэгт бид бэлэн байх ёстой.
Mango Telecom дахь туршилтын автоматжуулалт
Туршилтын хувьд миний хувьд бас нэгэн сонирхолтой илтгэлийг Mango Telecom компанийн Егор Маслов өгсөн. Танилцуулга нь "SCRUM баг дахь туршилтын бүрэн мөчлөгийн автоматжуулалт" гэж нэрлэгдсэн. DevOps-ийг SCRUM-д зориулж тусгайлан бүтээсэн гэж Егор үзэж байгаа боловч үүнтэй зэрэгцэн DevOps-ийг SCRUM багт нэвтрүүлэх нь нэлээд асуудалтай юм. Энэ нь SCRUM баг үргэлж хаа нэгтээ ажилладаг, шинэлэг зүйлд сатаарч, үйл явцыг дахин бүтээх цаг байдаггүй тул ийм зүйл тохиолддог. Асуудал нь SCRUM нь багийн дэд багийг (туршилтын баг, хөгжүүлэлтийн баг гэх мэт) салгахгүй байгаа явдал юм. Үүнээс гадна, одоо байгаа үйл явцыг автоматжуулахын тулд баримт бичиг шаардлагатай бөгөөд SCRUM-д ихэнхдээ бүрэн баримт бичиг байдаггүй - "бүтээгдэхүүн нь зарим төрлийн бичээсээс илүү чухал юм."
SCRUM руу шилжсэний дараа тестерүүд функцуудыг хэрхэн турших талаар хөгжүүлэгчидтэй зөвлөлдөж эхлэв. Аажмаар функциональ хэмжээ нэмэгдэж, ямар ч баримт бичиг байхгүй болж, туршилтанд хамрагдаагүй функцүүдэд маш олон алдаа гарч эхэлсэн бөгөөд ерөнхийдөө хэн, хэзээ туршиж үзсэн нь тодорхойгүй болсон. Товчхондоо - төөрөгдөл, төөрөгдөл. Бид туршилтын автоматжуулалт руу шилжихээр шийдсэн. Гэвч тэр үед ч бүрэн бүтэлгүйтэл байсан. Тэд дотоод шалгагчдад үл мэдэгдэх стек дээр бичсэн автоматжуулалтын мэргэжилтнүүдийг ажилд авсан. Мэдээжийн хэрэг автотест хийх хүрээ ажилласан боловч аутсорсингуудыг орхисны дараа энэ нь хоёр долоо хоног үргэлжилсэн. Дараа нь хоёр дахь автомат тестийг нэвтрүүлэх оролдлого байв. Энэ нь бүх зүйлийг SCRUM-ийн хүрээнд өөрийн биеэр (зөв вектор: дотооддоо туршлага хуримтлуулах), SCRUM-ийн хүрээнд барьж, үйл явцад баримт бичгийг бий болгох хэрэгтэй гэдгээс эхэлсэн. Автоматжуулалтын стек нь бүтээгдэхүүний стектэй тэнцүү байх ёстой (би энд нэмж байна, JavaScript төслөө өөр зүйлээр туршиж болохгүй). Спринтийн төгсгөлд тэд бүхэл бүтэн багтай автотест хэрхэн ажилладаг талаар демо хийсэн (тустай). Ийнхүү автоматжуулалтын үйл явцад багийн бүх гишүүдийн оролцоо нэмэгдэж, автотестэд итгэх итгэл нэмэгдэж, энэ автомат тестийг ашиглах нь гарцаагүй (мөн байнгын алдааны улмаас сарын дараа тайлбар өгөхгүй).
Дашрамд дурдахад, DevOpsForum 2019 дээр нээлттэй микрофон байсан бөгөөд энэ нь удаан хугацааны туршид мэдэгдэж байсан бөгөөд миний бодлоор илтгэлийн ашигтай хэлбэр юм. Та ингээд тойрон алхаж, тайлан сонсож, дараа нь бага хурал дээр тодорхой сэдэв, асуудлыг хэлэлцэх, асуудлыг шийдвэрлэхэд холбогдох туршлагаа хуваалцах нь зүйтэй гэж шийднэ.
Мөн зохион байгуулагчид богино хэмжээний тайлангийн урсгал хийж байсныг анзаарсан. Тайлан бүр 10 минутаас илүүгүй үргэлжлэх бөгөөд дараа нь асуултууд орно. Ингэснээр та олон сэдвийг нэг дор хөндөж, сонирхсон илтгэгчдээс асуулт асуух боломжтой.
Илтгэлийн хооронд би хурлын түншүүдийн лангууг тойрон алхаж, олон зүйлийг хулгайлсан/хож авсан. Өө, би гарын авлагад дуртай!
Alfastrakhovanie дахь хөгжлийн захиралтай дугуй ширээний болон DevOps-ийн асуудлууд
DevOpsForum 2019 бялууны мөстөлт нь DevOps-ийн мэргэжилтнүүдтэй нэг цаг үргэлжилсэн нэгдсэн хуралдаан байлаа. Антон Исанин (Альфастрахование, хөгжлийн захирал), Наиля Замашкина (Финтек лаборатори, үйл ажиллагааны захирал), Олег Егоркин (Ростелеком, Agile дасгалжуулагч) болон Антон Мартьянов (бие даасан шинжээч, DevOps-ийг үзсэн) дөрвөн оролцогчийг DevOps-ийг өөр өөр өнцгөөс харахыг урьсан. бизнесийн үүднээс).
Мэргэжилтнүүд хүмүүст ойртож суугаад бүх зүйл болж эхлэв: бүтэн цагийн турш үзэгчдийн оролцогчид асуулт асууж, шинжээчид рэп барьжээ. Заримдаа жинхэнэ мэтгэлцээн өрнөдөг байсан. Асуултууд нь маш өөр байсан, жишээлбэл: DevOps инженерүүд хэрэгтэй юу, яагаад тэднийг системийн администратороор сургаж болдоггүй юм бэ, DevOps-ийг хүн бүрт санал болгох ёстой юу, түүний үнэ цэнэ юу вэ гэх мэт.
Дараа нь би Антон Исанинтай биечлэн ярилцсан. Бид DevOps соёлыг айл бүрт авчрах хэрэгцээний талаар ярилцаж, DevOps-ийн өөрчлөлтийн харанхуй талыг илчилсэн.
Бүгд цугларч, DevOps нь бүтээгдэхүүн, бизнес, багт аль алинд нь хэрэгтэй гэж шийдсэн гэж төсөөлөөд үз дээ. Үүнийг хэрэгжүүлье. Бүх зүйл бүтсэн. Бид амьсгалаа гаргалаа. DevOps биднийг үйлчлүүлэгчтэй ойртуулсан тул одоо бид түүний бүх хүслийг хурдан биелүүлэх боломжтой болсон. Үүний үр дүнд бид хатуу дүрэм журам, шаардлага бүхий томоохон ажиллагааны хэлтэстэй болсон бөгөөд энэ нь бүтээгдэхүүний согогийг байнга илрүүлж, олон тооны хүсэлтийг бий болгодог. Түүнээс гадна үйлчлүүлэгч гэнэт товчлуурыг ногоон биш шараар будахыг хүссэн ч гэсэн бүх согогийг "яаралтай" гэсэн статустай болгодог. Төсөл нэмэгдэж, хувилбаруудын тоо нэмэгдэж, үүний дагуу үйлчлүүлэгчдийн шинэ функцүүдийн согог, үл ойлголцлын тоо нэмэгдэж байна. Мэдээллийн доголдлыг мэдээлэхийн тулд Ops нэмэлт 10 хүнийг ажилд авдаг бол хөгжүүлэлт нь тэдгээрийг арилгахын тулд 15 хүнийг ажилд авдаг. Мөн шинэ боломжуудыг нэвтрүүлэхийн оронд баг нь төгсгөлгүй SD-тэй ажиллаж, функцийг хэрэглэгчдэд тайлбарлаж, нэгэн зэрэг дэмжлэг үзүүлдэг. Үүний үр дүнд үйл ажиллагаа болон хөгжүүлэлт хоёулаа ажиллаж байгаа боловч үйлчлүүлэгч болон бизнес сэтгэл хангалуун бус байна: шинэ боломжууд гацаж байна. DevOps байгаа юм шиг харагдаж байна, гэхдээ энэ нь байхгүй юм шиг санагдаж байна.
DevOps-ийг хэрэгжүүлэх хэрэгцээний талаар Антон энэ нь бизнесийн цар хүрээнээс шууд хамаарна гэж тодорхой хэлсэн. Жилд нэг үйлчлүүлэгчид үйлчилгээ үзүүлэх нь компанид тэрбумыг авчирдаг бол DevOps шаардлагагүй (хэрэв та энэ үйлчлүүлэгчид байнга шинэ өөрчлөлт оруулах шаардлагагүй бол). Бүх зүйл шоколадаар бүрхэгдсэн байдаг. Гэхдээ хэрэв бизнес хөгжиж, илүү олон үйлчлүүлэгчид гарч ирвэл та дагаж мөрдөх хэрэгтэй. Дүрмээр бол компанид эхэндээ ямар ч дажгүй Ops байдаггүй. Эхлээд бид бүтээгдэхүүнийг огтолж, зөвхөн дараа нь бүтээгдэхүүн ажиллахын тулд серверүүдийг хянаж, хангамжийг хянах хэрэгтэй гэдгийг ойлгодог. Тэр үед л Ops бий болдог. Опс нь тусдаа хэлтэс болохын хувьд хөгжилд олон саад тотгор учруулж, бүх хүргэлт зогсонги байдалд орно гэдгийг ойлгох хэрэгтэй. Өөрөөр хэлбэл, энэ тохиолдолд DevOps соёл нь аль хэдийн хамааралтай болсон ч түүний харанхуй талыг мартаж болохгүй.
Эх сурвалж: www.habr.com