Гуравдугаар чуулган арванхоёрдугаар сарын 7-нд болсон , Mail.ru Cloud Solutions-ийн дэмжлэгтэйгээр Москвагийн DevOps нийгэмлэгээс зохион байгуулсан. Оролцогчид DevOps-ын тэргүүлэх мэргэжилтнүүдийн илтгэлээс гадна богино хэмжээний сэдэл өгөх Lightning Talks, семинарт оролцож, нээлттэй талбайд харилцах боломжтой.
Бид зургаан илтгэлээс чухал ойлголтуудыг цуглуулж, илтгэлүүдийн ард юу үлдсэнийг олж мэдэхийн тулд хэд хэдэн илтгэгчтэй ярилцлага хийсэн.
Дотор:
- Барух Садогурский, JFrog: "Програм хангамжийг худалдагчаас хэрэглэгч рүү шингэн шиг урсгах"
- Павел Селиванов, Саутбридж: "Дэв болон Оп нар нэг нийтлэг даалгавартай байдаг - үр дүнтэй бүтээгдэхүүн хийх"
- Владимир Утратенко, X5 Retail Group: "Аж ахуйн нэгж дэх DevOps бол өвдөлт, гал түймэргүй хөгжил юм"
- Сергей Пузырев, Facebook: "Үйлдвэрлэлийн инженер нь үйлчилгээг бүхэлд нь анхаарч үздэг: ингэснээр хэрэглэгчид болон хөгжүүлэгчид цагийг сайхан өнгөрөөх болно"
- Михаил Чинков, ЭЛЧ: "Нэг хэлтэс DevOps замыг дагаж чадахгүй, бүх компани үүнийг дагаж мөрдөх ёстой"
- Росбанкны DevOps сонирхогчид: "Цустай аж ахуйн нэгжид DevOps-ийг хэрэгжүүлэх 1000 хоног"
1. Барух Садогурский, JFrog: "Програм хангамжийг худалдагчаас хэрэглэгч рүү шингэн шиг урсгах"
Програм хангамжийн шинэчлэлтийн алдаа нь цаг тутамд тохиолддог бөгөөд хүн бүрт тохиолддог. Илтгэлээс ганцхан аймшгийн түүхийг энд дурдъя: Knight Capital амжилтгүй шинэчлэл хийсний дараа нэг цагийн дотор 440 сая доллар алдсан.
Барух алдаа, хэрэглэгчийн үзэн ядалтаас зайлсхийхэд туслах DevOps-ийн тасралтгүй шинэчлэлтүүдийн талаар ярьсан:
Орон нутгийн буцаалт — ямар нэг зүйл тохиолдвол буцаахын тулд програм хангамжийн өмнөх хувилбарыг төхөөрөмж дээрээ хадгалаарай. Хэрэв бүх зүйл маш муудвал та нөхөөс илгээх боломжгүй бол энэ нь таныг хамгаалах болно.
Агаарын шинэчлэлтүүд - илүү сайн тасралтгүй. Үгүй бол Jaguar хөгжүүлэгчидтэй адил байх болно: тоормосны системд гарсан алдаанаас болж, агаараар шинэчлэх боломжгүй байсан тул машинуудыг худалдаанаас эргүүлэн татах шаардлагатай болсон. Энэ нь өвдөлттэй, үнэтэй байсан.
Тасралтгүй шинэчлэлтүүд — шинэ функц бэлэн болмогц программ хангамжийг тасралтгүй шинэчлэх. Ховор шинэчлэлтүүдийн тусламжтайгаар чухал шинэчлэлтүүд нь чухал биш шинэчлэлтүүдийг хүлээж болно. Теслагийн нэгэн адил санамсаргүй тоормосыг засах ёстой байсан шинэчлэл нь шатрын тоглоомын шинэчлэлтийг хүлээж байв.
Автоматжуулсан байршуулалт - Хүмүүс ердийн үйлдэл хийхдээ муу байдаг тул хүмүүсийг машинаар солих.
Частие обновления - дадал зуршилтай болгож, айдсаас ангижрахад тусална. Ховор шинэчлэлтүүд яаралтай арга хэмжээ болж хувирдаг.
Төхөөрөмжийн төлөв байдлыг мэдэх - эхнээс нь суулгах биш, шинэчлэлтүүдийг турших. Төхөөрөмжийн төлөв байдлаас шалтгаалан шинэчлэлтүүд өөр байж болох тул энэ нь чухал юм.
Канарын хувилбарууд — шинэчлэлтүүдийг цөөн тооны хэрэглэгчдэд хүргэж, ажигла. Энэ нь ямар нэг зүйл буруу болвол хохирлыг бууруулдаг.
Боломжгүй шинэчлэлтүүд - хэрэглэгчдэд зөвхөн шинэ боломжуудыг анзаарч, шинэчлэлт хийх үед хэдэн долоо хоногийн турш үйлчилгээгүй үлдэхгүй байхыг зөвшөөрнө үү.
Бид Барух Садогурскийтэй DevOps-ийн үзэл бодол Орос болон барууны мэдээллийн технологийн хувьд хэрхэн ялгаатай, Cloud удахгүй бидний төлөө бүх зүйлийг хийх эсэх, бүх програм хангамжийн үйлчилгээ aaS схемд шилжих эсэх талаар ярилцлаа - ярилцлагыг үзээрэй.
2. Павел Селиванов, Саутбридж: “Дэв ба Оп хоёрын нэг нийтлэг даалгавар байдаг - үр дүнтэй бүтээгдэхүүн хийх”
Kubernetes-ийг хэрэгжүүлэх нь DevOps-д хүрэхэд тус болохгүй, харин эсрэгээрээ бүх зүйлийг эвдэж чадна. Технологи (хамгийн гайхалтай нь ч гэсэн) яагаад таны бүх асуудлыг шийдэж чадахгүй байгааг Павел тайлбарлав.
Төслийн нарийн төвөгтэй байдал нь кодоос илүү гарсан. Өмнө нь нарийн төвөгтэй програм байсан: төслийн хүрээнд харилцан үйлчлэл, нарийн төвөгтэй хөгжүүлэлт, гэхдээ энгийн бүтэцтэй - администратор үүнийг байрлуулсан, бүх зүйл ажилладаг. Бид микро үйлчилгээ рүү шилжсэн: үйлчилгээ бүр нь энгийн хэрэглээ, стандарт протокол ашиглан харилцаа холбоо, хурдацтай хөгжиж байгаа боловч төслийн бүтэц нь илүү төвөгтэй болсон. Микро үйлчилгээний архитектур бүхий төслийн нарийн төвөгтэй байдал арилаагүй - энэ нь кодоос илүү гарсан. Одоо DevOps инженер үүнийг хариуцаж байна.
Хөгжүүлэгчид DevOps-ийг хэрэгжүүлсний дараа өөрчлөлт хийхийг хүсэхгүй байна. Үүний үр дүнд Кубернетестэй хийсэн ажлын урсгал нь Dev-ээс Ops хүртэл даалгавруудыг хана дээгүүр шидэж байгаа мэт харагдсаар байгаа бөгөөд зөвхөн зүйрлэл биш - Гит ийм хана болж хувирдаг. Хөгжүүлэгч кодыг тэнд байрлуулж, өмнөх шигээ ажилладаг бөгөөд админууд нь Kubernetes, CI/CD болон бусад бүх зүйлтэй.
Гэсэн хэдий ч хөгжүүлэгчид өөрчлөлтийг хүлээн зөвшөөрөх хэрэгтэй. Хөгжүүлэгчид админууд юу хийж байгааг мэдэхгүй, админ нь хөгжүүлэгчид юу болж байгааг мэдэхгүй байгаа нөхцөл байдал нь асуудал үүсгэдэг.
Хэрэв хөгжүүлэгчдийн хувьд юу ч өөрчлөгдөөгүй бол програмын ажиллагаа нь тэдний үүрэг хариуцлага гэдгийг ойлгодоггүй - янз бүрийн техникийн заль мэх ажиллахгүй.
DevOps болон Kubernetes гарч ирснээр хөгжилд их зүйл өөрчлөгдөх болно. Devs нь Ops болон эсрэгээр чадвартай байх ёстой. Эдгээр мэргэжилтнүүд өөрсдийн гэсэн тодорхой ур чадвартай боловч бие биенийхээ ажлыг мэддэг байх ёстой. Dev болон Ops нь Kubernetes-ийг хэрэгжүүлэхийн өмнө найзууд байх хэрэгтэй, эс тэгвээс та өөрт байгаа зүйлээ эвдэх болно.
Павел Селиванов 5 жилийн дараа Кубернетесэд юу тохиолдох, орчин үеийн стартап юун дээр технологийн стек барих ёстой талаар ярьсан - ярилцлагыг үзээрэй.
3. Владимир Утратенко, X5 Retail Group: "Enterprise дахь DevOps бол өвдөлт, гал түймэргүй хөгжил юм"
Хөгжил хэтэрхий удаан, бодит байдалд нийцэхгүй байгааг ойлгосноор компаниуд илүү сайн хөгжиж, илүү хурдан хөгжих хүсэл эрмэлзэлтэй болж, DevOps-ийн өөрчлөлтөд ордог.
Энэ нь хэрхэн тохиолддог, юу болохыг Владимир тайлбарлав.
- Эхлээд компаниуд DevOps инженерийг ажилд авдаг. Энэ бол системийн ахлах администратор бөгөөд үйлдвэрлэлд хувилбарыг нэвтрүүлэх, хөгжлийн орчныг стандартчилах, дэд бүтцийг бий болгох, янз бүрийн асуудлыг илрүүлэх, засах, үйл явцыг автоматжуулах болон бусад техникийн ажлуудад оролцдог.
- Дараа нь нэг DevOps инженер хангалтгүй болж, компани DevOps багийг ажилд авна. Энэ бол өөр өөр инженерүүдийн хүчин чармайлтыг зохион байгуулж, тэднийг нэг чиглэлд төвлөрүүлэх боломжийг олгодог чадамжийн төв юм.
- Үнэн хэрэгтээ DevOps инженер болон DevOps багууд нь DevOps өөрчлөлтийн эсрэг загварууд юм. DevOps нь дадлага, соёлтой холбоотой тул технологийн компаниудад (SRE, Үйлдвэрлэлийн инженерчлэл) DevOps-ийн хэрэгжилтүүд байдаг.
Юу хийх вэ? DevOps-ийн өөрчлөлтийг хэрэгжүүлэх, дадлага хийх, хөгжлийн соёл, технологийн соёлыг төлөвшүүлэхэд туслах түр зуурын DevOps багийг ажилд авна уу.
Бизнес гарч ирж, DevOps-д хөрөнгө оруулалт хийх үед хэд хэдэн хувилбар байж болно: хөөрөх үед бүх зүйл нурах болно; SRE/Production Engineering эсвэл Embedded Ops хэвээр байх болно; үйл явц нь бизнесийн хэмжүүр дээр суурилсан үед BizOps руу шилжих болно.
Владимир Утратенко бидэнд DevOps нь аж ахуйн нэгжид хэр "цустай" байдаг, томоохон жижиглэнгийн худалдаанд хэрхэн хэрэгжүүлдэг тухай ярьж өгсөн - ярилцлагыг үзээрэй.
4. Сергей Пузырев, Facebook: "Үйлдвэрлэлийн инженер нь үйлчилгээг бүхэлд нь анхаарч үздэг: ингэснээр хэрэглэгчид болон хөгжүүлэгчид цагийг сайхан өнгөрөөх болно"
Facebook бол асар олон бүрэлдэхүүн хэсэг, сервер, хүмүүс, дата төвтэй асар том компани юм. Хэдийгээр асар том хэмжээтэй ч гэсэн энэ нь маш хурдан байдаг - хөгжүүлэгчид өдөрт олон удаа үйлчилгээг нэвтрүүлж чаддаг. Түүнчлэн, Facebook хурдацтай хөгжиж байгаа бөгөөд энэ нь зөвхөн хэрэглэгчид болон серверүүдийн тоо төдийгүй хөгжүүлэгчдийн тоо нэмэгдэж байгаа нь үйл явцыг илүү төвөгтэй болгож байна.
Сергей Facebook дээр үйлдвэрлэлийн инженер юу хийдэг талаар хэлэв.
- Үйлдвэрлэлийн инженер маш их кодчилдог, тэр системийн мэдлэгтэй байх ёстой: үйлдлийн систем, файлын систем, мэдээллийн сан, сүлжээ гэх мэт. Түгээмэл систем болон Найдвартай байдлын инженерчлэлтэй ажиллах, өөрөөр хэлбэл бүтээгдэхүүний найдвартай байдлыг дэмжих туршлагатай байх. Энэ нь дуудлагад байх ёстой, өөрөөр хэлбэл хүссэн үедээ дуудлага хийх боломжтой байх ёстой.
- Үйлдвэрлэлийн инженер нь програм хангамжийн инженерээс үйл ажиллагааны ахисан ур чадвараараа ялгаатай боловч үнэндээ програм хангамжийн инженерийн дэд зүйл юм. Програм хангамжийн инженерүүд жишээлбэл, өгөгдөл боловсруулахтай холбоотой нэмэлт ур чадвартай байж болно. Фэйсбүүк дээр ийм мэргэжилтнүүд дуудлагатай байх ёстой бөгөөд энэ нь олон хүмүүсийн хувьд таагүй гэнэтийн бэлэг юм.
- Компани дахь үйлдвэрлэлийн инженерийн хэрэгцээний пирамид нь серверүүд болон тэдгээрийн амьдралын мөчлөгийг хянах, өөрөөр хэлбэл шинэ техник хангамж авах, тохируулах, ашиглалтад оруулахаас эхэлдэг. Дараагийн түвшин нь үйлчилгээний түвшинд ижил байна: хяналт үйлчилгээ ба тэдгээрийн амьдралын мөчлөг. Дараа нь тасралтгүй масштаблах, дэвшилтэт хяналт ирдэг. Үйлчилгээний амьдралын мөчлөг автоматжсаны дараа тэд автомат масштаб руу шилждэг. Эцэст нь масштабыг үр дүнтэй болгож, компани мөнгө, нөөцийг хэмнэхийн тулд тааруулах шаардлагатай.
5. Михаил Чинков, ЭЛЧ: "Нэг хэлтэс DevOps-ийн замыг дагаж чадахгүй, бүхэл бүтэн компани дагаж мөрдөх ёстой"
Михаил DevOps бол тасралтгүй хөгжил гэж үздэг. Та зарим хэрэгслийг танилцуулж, тэнд зогсоож болохгүй. Компаниудыг DevOps болоход ямар бэрхшээл саад болж, практикийг хэрхэн хэрэгжүүлэх вэ?
DevOps-ийг ойлгох ялгаа. Сайн мэдээний номлогчдын үзэж байгаагаар каноник номлол нь 5 багана дээр тулгуурладаг:
- соёл - хүмүүс болон хамтын ажиллагаанд анхаарлаа төвлөрүүлэх;
- автоматжуулалт - ажлын урсгалд дэг журмыг шилжүүлэх;
- lean - хэрэглэгчдэд үнэ цэнийг хүргэхийг онцлон тэмдэглэх;
- хуваалцах - мэдлэгийг тасралтгүй солилцох;
- хэмжүүрүүд болон тэдгээрийг ашиглан санал хүсэлт хүлээн авах.
Компаниуд ихэвчлэн зөвхөн автоматжуулалт, хэрэглэгчдэд үнэ цэнийг хүргэх тал дээр анхаардаг. Гэвч соёл, мэдлэг хуваалцах, хөгжлийг хянах DevOps хэмжигдэхүүнүүд хоцрогдсон.
DevOps стандартчиллын сорилтууд. Бүтээгдэхүүний зорилго нь бүх компаниудын хувьд өөр бөгөөд стандартчилах боломжгүй юм. Компанийн DevOps-ийн төлөв байдал нь компаниас өөрөөс нь хамаардаг боловч олон хүн үүнийг ойлгодоггүй бөгөөд DevOps инженерийг ажилд авахад хангалттай гэж үздэг.
Бид яагаад DevOps болоогүй байна вэ? Хоёр гол асуудал байна. Аж ахуйн нэгжид байгууллагын хөгжил удаашралтай, олон мянган ажилчдын оюун ухаан дахь векторыг өөрчлөхөд бэрхшээлтэй байдаг. Гарааны бизнесүүдэд мэдлэгийн эх үүсвэр хомс, өөрчлөлтөд зориулж нөөцийг хуваарилах асуудал гардаг.
Компани дахь DevOps хөгжлийн үе шатууд:
- эхнийх нь үүлэн доторх дэд бүтэц, гэхдээ энэ нь хэрхэн ажилладагийг нэг эсвэл хоёр админаас өөр хэн ч мэдэхгүй;
- хоёрдугаарт, дэд бүтэц нь бүх инженерүүдэд ойлгомжтой, ойлгомжтой боловч үйл явц нь оновчтой биш;
- Гуравдугаарт - инженерүүд шууд үйлчилгээг бие даан эхлүүлэх, засварлах;
- дөрөвдүгээрт - инженерүүд үндсэн дэд бүтэц, үүлэн доторх ил тод код, товчлуураар байршуулах зэрэгт хувь нэмрээ оруулах болно.
Хамгийн тохиромжтой схем бол хүн бүр дэд бүтцэд хандах эрхтэй, бүх инженерүүд бүтээгдэхүүнд хандах боломжтой бөгөөд юу хийж байгаагаа ойлгох явдал юм.
Соёлын болон техникийн бүх гештальтуудыг хаасны дараа компанийн DevOps-ийн өөрчлөлт нь бизнес болон платформын хэмжүүрүүдийн санал хүсэлтийг харгалзан үзэх болно.
6. Росбанкны DevOps сонирхогчид: "Цустай аж ахуйн нэгжид DevOps-ийг хэрэгжүүлэх 1000 хоног"
Росбанкаас Юрий Булич, Дина Мальцева, Евгений Панков нар гурван жилийн дотор DevOps-т хэрхэн ирсэн тухайгаа ярьжээ. Тодорхой багуудад тодорхой асуудлыг шийдвэрлэх, төвлөрсөн хэрэгслийг хэрэгжүүлэх гэсэн хоёр зорилго байсан.
Энд хүрсэн үр дүн байна:
Бүтээгдэхүүний багуудын үр дүн: 30 дахин хурдан угсрах, 6 дахин хурдан суурилуулалт, бүтэн мөчлөгт 30% хүртэл хэмнэлт. Бид одоо нэг товчлуур дарж бүтээмж рүү шилжих боломжтой болсон
Платформ командын үр дүн: 10 дахин хурдан угсрах, суурилуулах, суурилуулах тоо 87%, автомат туршилтын хамрах хүрээ 46%. Интеграцийн баг нь гацаа байхаа больсон
Тэгэхээр DevOps практикийг цуст аж ахуйн нэгжид хэрхэн хэрэгжүүлэх вэ?
Эхлээд туршилтын төсөл хэрэгжүүл: Багуудыг сонгож, архитектурыг хэрхэн хэрэгжүүлэхээ шийдэж, багаж хэрэгслийг сонго. Бид нээлттэй лицензтэй, банкинд суурилуулсан, тэдэнтэй ажиллах туршлагатай багаж хэрэгслийг сонгосон. Росбанк нь DevOps платформтой хамт хувийн үүлэн сүлжээг нэгэн зэрэг байрлуулсан бөгөөд энэ нь эхэндээ тусалсан. Өмнө нь үүлэн дээр 15 минутын дотор шаардлагатай нөөцийг олж авах боломжтой байсан бол ийм үйл явц долоо хоног үргэлжилж болно.
Банк болон бусад аж ахуйн нэгжүүдэд мэдээллийн аюулгүй байдлын багтай хамтран хязгаарлалтыг урьдчилан боловсруулж, өөрчлөлтийг хэрэгжүүлэх боломжийг олгох шийдлийг олох шаардлагатай байна.
Туршилтын дараа амжилттай шийдлийг өргөжүүлэх шаардлагатай.
- Дамжуулах хоолойг аль болох "шулуун болгох" нь чухал бөгөөд үүнээс шаардлагагүй холбоосыг арилгах, үнэ цэнийг хангагчдыг онцолж, үлдсэн бүрэлдэхүүн хэсгүүдийг арилгах явдал юм. Завсрын бүтээгдэхүүн нь эсрэг загвар юм. Жишээлбэл, Росбанк дээр хэд хэдэн баг дотоод хөгжлийг хөгжүүлээгүй бөгөөд зөвхөн гадаад хөгжлийг үлдээсэн. Энэ нь тусгайлсан DevOps баг бий болоход хүргэсэн бөгөөд энэ нь кодыг гадаадаас дотоод хөгжүүлэгчид рүү шилжүүлэх боломжийг олгосон. Гадны хөгжүүлэлтийг CI/CD-д оруулах замаар асуудлыг шийдсэн бөгөөд ингэснээр тэд кодыг өөрсдөөсөө банк руу шилжүүлээд зогсохгүй амжилттай ажиллахад хариуцлага хүлээх болно.
- Төлөвшлийн загвар нь DevOps-ийн практикийн элементүүд, жагсаасан хэрэгслүүдийг багтаасан бөгөөд гадны ханган нийлүүлэгчидтэй ажиллах онцлогийг харгалзан үзсэн - ирээдүйд энэ нь шинэ багуудад хэрэгжүүлэх ажлын хоцролтыг хурдан бууруулахад тусалсан.
- Бидэнд зөөлөн хяналт, зөвлөмж хэлбэрээр Засаглал хэрэгтэй. Сайн ажилладаг DevOps гарын авлага нь багуудад платформыг зөв ашиглахад тусалдаг зохион байгуулалтын болон багаж хэрэгслийн багц шинж чанарууд юм.
- Та нэн даруй соёлд анхаарлаа хандуулах хэрэгтэй, тэгвэл олон өөрчлөлт илүү хурдан бөгөөд хялбар болно. Дотоод нийгэмлэгээ хөгжүүлж, уулзалт, техникийн семинар, сургалт, хөгжилтэй үйл ажиллагаа явуул. Энэ нь үр дүнгээ өгч байна: хүмүүс туршлагаа хуваалцаж, хэн юу хийснийг харж, хаашаа эргэхээ мэддэг, компани доторхи шуугиан, эрүүл өрсөлдөөн бий.
- Процесст оролцоогүй хүмүүстэй ажиллах нь утгагүй, төлөвшөөгүй багуудтай, сонирхолтой баг, үнэнч хүмүүст хөрөнгө оруулах нь дээр.
- Сонгосон шийдэл нь үүнийг ашигладаг инженерүүдэд тохиромжтой байх ёстой.
- Гадны хөгжил нь хориглогч биш бөгөөд практикийг тэнд хэрэгжүүлэх боломжтой, гол зүйл бол баг өөрөө хүсэл эрмэлзэлтэй байх явдал юм.
Бага зэрэг илүү ашиг тустай
Александр Чистяков, vdsina.ru сайтаас DevOps-ийн хүмүүст уншихад тохиромжтой номнуудын жагсаалт:
- Ирина Якутенко "Хүсэл зориг ба өөрийгөө хянах чадвар."
- Даниел Каннеман "Сэтгэн бодохуй, хурдан, удаан".
- Барбара Окли "Тооны төлөөх оюун ухаан".
- Максим Дорофеев "Жеди техникүүд".
- Виктор Франкл "Хүний утгын эрэл хайгуул".
Тогтмол бай
Бид ч гэсэн DevOps-т дуртай. Цуврал зарлалуудыг дагаж мөрдөөрэй болон @Kubernetes, түүнчлэн бусад Mail.ru Cloud Solutions арга хэмжээнүүд манай Telegram сувагт:
Эх сурвалж: www.habr.com
