"Devops-ийг хэрхэн хэрэгжүүлэх вэ" гэсэн асуулт олон жилийн турш байсаар ирсэн боловч тийм ч сайн материал байдаггүй. Заримдаа та яаж ч хамаагүй цагаа зарах хэрэгтэй тийм ч ухаалаг бус зөвлөхүүдийн зар сурталчилгааны золиос болдог. Заримдаа эдгээр нь мегакорпорацуудын хөлөг онгоцууд орчлон ертөнцийг хэрхэн хагалах тухай тодорхойгүй, туйлын ерөнхий үгс юм. Асуулт гарч ирнэ: энэ нь бидэнд ямар хамаатай вэ? Эрхэм зохиолч, та саналаа жагсаалтад тодорхой томъёолж чадах уу?
Энэ бүхэн нь компанийн соёлын өөрчлөлтийн үр дүнгийн талаархи бодит туршлага, ойлголт төдийлөн хуримтлагдаагүйгээс үүдэлтэй юм. Соёлын өөрчлөлт нь урт хугацааны зүйл бөгөөд үр дүн нь долоо хоног, сарын дараа гарахгүй. Олон жилийн турш компаниуд хэрхэн бүтээгдэж, дампуурсныг харсан хүн бидэнд хэрэгтэй байна.
Жон Уиллис - DevOps-ийн эцгүүдийн нэг. Жон асар олон компанитай хамтран ажилласан олон арван жилийн туршлагатай. Саяхан Жон тэдэнтэй ажиллахдаа тодорхой хэв маягийг анзаарч эхэлсэн. Эдгээр архетипийг ашиглан Жон компаниудыг DevOps-ийн өөрчлөлтийн жинхэнэ зам руу чиглүүлдэг. Эдгээр архетипүүдийн талаар түүний DevOops 2018 бага хурлын тайлангийн орчуулгаас уншина уу.
Илтгэгчийн тухай:
Мэдээллийн технологийн менежментийн чиглэлээр 35 гаруй жил ажилласан, Canonical дахь OpenCloud-ийн өмнөх хувилбарыг бүтээхэд оролцож, 10 гарааны бизнест оролцож, хоёрыг нь Dell болон Docker-д худалдсан. Одоогоор тэрээр SJ Technologies компанийн DevOps болон дижитал практик хариуцсан дэд ерөнхийлөгчөөр ажиллаж байна.
Дараагийнх нь Жонны үзэл бодлоос түүх юм.
Намайг Жон Уиллис гэдэг бөгөөд намайг олоход хамгийн хялбар газар бол Twitter, . Би Gmail болон GitHub дээр ижил нэртэй байна. А Та миний тайлангийн видео бичлэг, тэдэнд зориулсан танилцуулгыг олж болно.
Би янз бүрийн томоохон компаниудын захирал нартай олон уулзалт хийдэг. Тэд DevOps гэж юу болохыг ойлгохгүй байна гэж ихэвчлэн гомдоллодог бөгөөд үүнийг тайлбарлахыг оролдсон хүн бүр өөр зүйлийн талаар ярьдаг. Өөр нэг нийтлэг гомдол бол DevOps ажиллахгүй байгаа хэдий ч захирлууд тэдэнд тайлбарласны дагуу бүх зүйлийг хийж байгаа мэт санагдаж байна. Бид зуу гаруй жилийн настай томоохон компаниудын тухай ярьж байна. Тэдэнтэй ярилцсаны дараа би олон асуудалд өндөр технологи биш, харин харьцангуй бага технологийн шийдлүүд хамгийн тохиромжтой байдаг гэсэн дүгнэлтэд хүрсэн. Хэдэн долоо хоногийн турш би өөр өөр хэлтсийн хүмүүстэй ярилцсан. Бичлэг дээрх хамгийн эхний зурган дээр таны харж байгаа зүйл бол миний сүүлчийн төсөл, гурван өдрийн ажлын дараа өрөө яг ийм харагдаж байв.
DevOps гэж юу вэ?
Үнэхээр 10 өөр хүнээс асуувал 10 өөр хариулт өгнө. Гэхдээ сонирхолтой зүйл бол эдгээр арван хариулт бүгд зөв байх болно. Энд буруу хариулт байхгүй. Би 10 орчим жилийн турш DevOps-т нэлээд гүнзгий орсон бөгөөд анхны DevOpsDay-д анхны Америк хүн байсан. Би DevOps-д оролцож байгаа бүх хүмүүсээс илүү ухаалаг гэж хэлэхгүй, гэхдээ үүнд маш их хүчин чармайлт гаргасан хүн бараг байхгүй. DevOps нь хүний хөрөнгө, технологи нэгдэхэд бий болдог гэдэгт би итгэдэг. Бид бүх төрлийн соёлын талаар их ярьдаг ч хүний хэмжүүрийг мартдаг.
Одоо бидэнд маш олон тоо баримт, таван жилийн эрдэм шинжилгээний судалгаа, онолыг үйлдвэрлэлийн хэмжээнд туршиж үзсэн. Эдгээр судалгаагаар та байгууллагын соёл дахь зан үйлийн зарим хэв маягийг нэгтгэж чадвал 2000 дахин хурдасч чадна гэж бидэнд хэлж байна. Энэ хурдатгал нь тогтвортой байдлын адил сайжирсантай таарч байна. Энэ бол DevOps ямар ч компанид авчрах ашиг тусын тоон хэмжүүр юм. Хэдэн жилийн өмнө би нэг Fortune 5000 компанийн гүйцэтгэх захиралд DevOps-ийн талаар ярьж байсан.Танилцуулга хийхээр бэлдэж байхдаа олон жилийн туршлагыг 5 минутын дотор дүгнэх ёстой байсан тул маш их сандарч байсан.
Эцэст нь би дараахь зүйлийг өгсөн DevOps-ийн тодорхойлолт: Энэ нь хүний капиталыг өндөр үр ашигтай байгууллагын капитал болгон хувиргах үйл ажиллагаа, хэв маягийн цогц юм. Жишээ нь Тоёота сүүлийн 50, 60 жил ажилласан арга барил юм.
(Цаашид ийм диаграммыг лавлах материал биш, харин зураг чимэглэл болгон өгсөн болно. Тэдний агуулга нь шинэ компани бүрт өөр өөр байх болно. Гэхдээ зургийг тусад нь харж, томруулж болно.
Хамгийн амжилттай ийм дасгалуудын нэг бол өртгийн урсгалын зураглал. Энэ талаар хэд хэдэн сайн ном бичсэн бөгөөд хамгийн амжилттай нь Карен Мартин юм. Гэвч сүүлийн нэг жилийн хугацаанд би ийм арга барил ч гэсэн хэтэрхий өндөр технологид нийцсэн гэсэн дүгнэлтэд хүрсэн. Энэ нь мэдээж олон давуу талтай бөгөөд би үүнийг маш их ашигласан. Гэхдээ гүйцэтгэх захирал танаас компани нь яагаад шинэ төмөр зам руу шилжиж чадахгүй байгааг асуухад үнэ цэнийн урсгалын зураглалын талаар ярихад эрт байна. Эхлээд хариулах ёстой өөр олон үндсэн асуултууд байна.
Миний олон хамт ажиллагсдын гаргадаг алдаа бол тэд зүгээр л компанидаа таван оноотой зааварчилгаа өгчихөөд зургаан сарын дараа буцаж ирээд юу болсныг хардаг явдал гэж би бодож байна. Үнэ цэнийн урсгалын зураглал гэх мэт сайн схем ч гэсэн сохор цэгүүдтэй гэж хэлье. Төрөл бүрийн компаниудын захирлуудтай олон зуун ярилцлага хийсний дараа би асуудлыг бүрэлдэхүүн хэсгүүдэд нь хуваах боломжийг олгодог тодорхой загварыг боловсруулсан бөгөөд одоо бид эдгээр бүрэлдэхүүн хэсгүүдийг дарааллаар нь хэлэлцэх болно. Технологийн ямар нэгэн шийдлийг хэрэглэхээс өмнө би энэ загварыг ашигладаг бөгөөд үүний үр дүнд миний бүх хана диаграммаар бүрхэгдсэн байдаг. Саяхан дундын сантай ажиллаж байгаад 100-150 ийм схемтэй болчихлоо.
Муу соёл нь өглөөний цайнд сайн ханддаг
Гол санаа нь: Байгууллагын соёл өөрөө муу байвал Lean, Agile, SAFE болон DevOps нь тус болохгүй. Энэ нь шумбах хэрэгсэлгүйгээр гүн рүү шумбах, рентген зураг авахгүйгээр ажиллахтай адил юм. Өөрөөр хэлбэл, Дракер, Деминг хоёрын хэллэгээр: Муу зохион байгуулалтын соёл нь ямар ч сайн системийг боомилохгүйгээр залгих болно.
Энэ гол асуудлыг шийдэхийн тулд та дараах алхмуудыг хийх хэрэгтэй.
- Бүх ажлыг харагдуулах: Та бүх ажлыг харагдахуйц болгох хэрэгтэй. Заавал ямар нэг дэлгэцэн дээр гарч байх ёстой гэдэг утгаараа биш, харин ажиглаж болохуйц байх ёстой гэсэн утгаараа.
- Ажлын удирдлагын нэгдсэн системүүд: удирдлагын тогтолцоог нэгтгэх шаардлагатай. “Овгийн” мэдлэг, институцийн мэдлэгийн асуудалд 9 тохиолдлын 10-д нь хүмүүс гацаанд ордог. Номонд Асуудал нь Брент хэмээх ганц хүнтэй холбоотой байсан бөгөөд энэ нь төслийг төлөвлөсөн хугацаанаас гурван жилээр хоцроход хүргэсэн. Би эдгээр "Брентүүд"-тэй хаа сайгүй тааралддаг. Эдгээр саад бэрхшээлийг арилгахын тулд би жагсаалтын дараагийн хоёр зүйлийг ашигладаг.
- Хязгаарлалтын онолын арга зүй: хязгаарлалтын онол.
- Хамтын ажиллагааны хакерууд: хамтын ажиллагааны хакерууд.
- Toyota Kata (): Би Toyota Kata-ийн талаар нэг их ярихгүй. Хэрэв сонирхож байвал миний github дээр Эдгээр сэдвүүдийн бараг бүх талаар.
- Зах зээлд чиглэсэн байгууллага: зах зээлд чиглэсэн байгууллага.
- Зүүн талын аудиторууд: мөчлөгийн эхний үе шатанд аудит хийх.
Би нэг байгууллагатай маш энгийнээр ажиллаж эхэлдэг: Би компанид очиж, ажилчидтай ярилцдаг. Таны харж байгаагаар өндөр технологи байхгүй. Танд хэрэгтэй зүйл бол бичих зүйл юм. Би хэд хэдэн багийг нэг өрөөнд цуглуулж, тэдний надад хэлсэн зүйлийг миний 7 архетипийн үүднээс задлан шинжилдэг. Тэгээд би тэдэнд маркер өгч, өнөөг хүртэл чангаар хэлсэн бүх зүйлээ самбар дээр бичихийг хүснэ. Ихэвчлэн ийм төрлийн уулзалтад бүх зүйлийг бичдэг нэг хүн байдаг бөгөөд хамгийн сайндаа тэр хэлэлцүүлгийн 10% -ийг бичиж чаддаг. Миний аргын тусламжтайгаар энэ үзүүлэлтийг 40% хүртэл нэмэгдүүлэх боломжтой.
(Энэ зургийг тусад нь харж болно )
Миний арга барил Уильям Шнайдерын бүтээл дээр суурилдаг. ). Аливаа байгууллагыг дөрвөн квадратад хувааж болно гэсэн санаан дээр тулгуурласан арга барил юм. Миний хувьд энэ схем нь ихэвчлэн байгууллагад дүн шинжилгээ хийх явцад гарч ирдэг бусад олон зуун схемүүдтэй хамтран ажилласны үр дүн юм. Манайд хяналт өндөртэй ч чадамж муутай байгууллага байна гэж бодъё. Энэ бол туйлын хүсээгүй сонголт юм: хүн бүр эгнээнд хөл тавьж байгаа ч юу хийхээ хэн ч мэдэхгүй.
Илүү сайн сонголт бол өндөр түвшний хяналт, ур чадвар бүхий сонголт юм. Хэрэв ийм компани ашигтай бол DevOps хэрэггүй байж магадгүй юм. Хяналт өндөртэй, чадвар муутай, хамтын ажиллагаатай хэрнээ соёлтой (таримал) компанитай ажиллах нь хамгийн сонирхолтой. Энэ нь тус компанид ажиллах дуртай хүмүүс олон, ажиллах хүчний эргэлт бага байна гэсэн үг.
(Энэ зургийг тусад нь харж болно )
Миний бодлоор хатуу удирдамжтай аргууд үнэнд хүрэх замд саад болдог. Ялангуяа үнэ цэнийн урсгалын зураглалд мэдээлэл хэрхэн бүтэцтэй байх талаар олон дүрэм байдаг. Миний одоо ярьж байгаа ажлын эхний үе шатанд эдгээр дүрэм хэнд ч хэрэггүй. Хэрэв гартаа тэмдэглэгээтэй хүн самбар дээр компанийн бодит байдлыг дүрсэлсэн бол энэ нь нөхцөл байдлыг ойлгох хамгийн сайн арга юм. Ийм мэдээлэл дарга нарт хүрдэггүй. Яг энэ мөчид тэр хүний яриаг таслаад ямар нэг сумыг буруу зурсан гэж хэлэх нь тэнэг хэрэг. Энэ үе шатанд энгийн дүрмийг ашиглах нь илүү дээр юм, жишээлбэл: олон өнгийн тэмдэглэгээг ашиглан олон түвшний хийсвэрлэлийг үүсгэж болно.
Би давтан хэлэхэд өндөр технологи байхгүй. Хар тэмдэглэгээ нь бүх зүйл хэрхэн ажилладаг бодит бодит байдлыг дүрсэлдэг. Хүмүүс өнөөгийн нөхцөл байдлын талаар юу дургүй байгааг улаан тэмдэглэгээгээр тэмдэглэдэг. Үүнийг би биш тэд бичих нь чухал. Уулзалтын дараа би CIO дээр очихдоо засах шаардлагатай 10 зүйлийн жагсаалтыг санал болгодоггүй. Би компанийн хүмүүсийн хэлж байгаа зүйл болон одоо байгаа батлагдсан загваруудын хоорондын уялдаа холбоог олохыг хичээдэг. Эцэст нь цэнхэр тэмдэглэгээ нь асуудлыг шийдэх боломжит шийдлүүдийг санал болгодог.
(Энэ зургийг тусад нь харж болно )
Энэ аргын жишээг одоо дээр дүрсэлсэн болно. Энэ оны эхээр нэг банктай ажиллаж байсан. Тэндхийн аюулгүй байдлын ажилтнууд дизайн, шаардлагын үнэлгээнд ирэх ёсгүй гэдэгт итгэлтэй байв.
(Энэ зургийг тусад нь харж болно )
Тэгээд бид бусад хэлтсийн хүмүүстэй ярилцсан бөгөөд 8 жилийн өмнө програм хангамж хөгжүүлэгчид хамгаалалтын ажилчдыг ажлаа удаашруулж байсан тул халсан байна. Дараа нь энэ нь хориг болж хувирсан бөгөөд үүнийг ердийн зүйл мэтээр хүлээн авсан. Хэдийгээр бодит байдал дээр ямар ч хориг байгаагүй.
Бидний уулзалт маш будлиантай өрнөсөн: гурван цаг орчим таван өөр баг код болон чуулганы хооронд юу болж байгааг надад тайлбарлаж чадсангүй. Мөн энэ нь хамгийн энгийн зүйл юм шиг санагдаж байна. Ихэнх DevOps зөвлөхүүд бүгд үүнийг аль хэдийн мэддэг гэж үздэг.
Тэгтэл дөрвөн цаг чимээгүй байсан МТ-ийн засаглал хариуцсан хүн сэдвийнх нь сэдэв рүү ороход гэнэт сэргэж биднийг маш удаан эзэллээ. Төгсгөлд нь би түүнээс уулзалтын талаар юу гэж бодож байгааг нь асуухад хариултыг нь хэзээ ч мартахгүй. Тэрээр хэлэхдээ: "Би өмнө нь манай банк программ хангамжийг хүргэх хоёрхон аргатай гэж боддог байсан, гэхдээ одоо би эдгээрийн тав нь байдгийг мэдэж байна, гурвыг нь ч мэдэхгүй байна."
(Энэ зургийг тусад нь харж болно )
Энэ банкинд хамгийн сүүлд хөрөнгө оруулалтын программ хангамжийн багтай уулзсан. Түүнтэй хамт цаасан дээр тэмдэглэгээ бүхий диаграм бичих нь самбар дээрээс, ухаалаг самбараас ч илүү дээр болох нь тогтоогджээ.
Таны харж байгаа гэрэл зургууд бол бидний уулзалтын дөрөв дэх өдөр зочид буудлын хурлын танхим ямар харагдаж байсан юм. Мөн бид эдгээр схемүүдийг хэв маяг, өөрөөр хэлбэл архетип хайхад ашигласан.
Тиймээс би ажилчдаас асуулт асууж, хариултыг гурван өнгийн (хар, улаан, цэнхэр) тэмдэглэгээгээр бичдэг. Би тэдний хариултыг архетипийн хувьд шинжилдэг. Одоо бүх архетипүүдийг дарааллаар нь авч үзье.
1. Бүх ажлыг харагдахуйц болгох: Ажлыг харагдуулах
Миний хамтран ажилладаг ихэнх компаниудад үл мэдэгдэх ажил маш өндөр хувьтай байдаг. Жишээлбэл, энэ нь нэг ажилтан нөгөөдөө ирж, зүгээр л ямар нэг зүйл хийхийг хүсэх явдал юм. Томоохон байгууллагуудад 60% төлөвлөгдөөгүй ажил байж болно. Мөн ажлын 40 хүртэлх хувийг ямар нэгэн байдлаар баримтжуулаагүй байна. Хэрвээ Боинг байсан бол би амьдралдаа дахиж хэзээ ч тэдний онгоцонд суухгүй байсан. Ажлын тал хувийг л баримтжуулсан бол энэ ажил зөв хийгдэж байна уу, үгүй юу гэдэг нь мэдэгдэхгүй. Бусад бүх аргууд нь ашиггүй болж хувирдаг - аливаа зүйлийг автоматжуулах гэж оролдох нь утгагүй юм, учир нь мэдэгдэж байгаа 50% нь ажлын хамгийн уялдаатай, тодорхой хэсэг байж болох бөгөөд автоматжуулалт нь маш сайн үр дүн өгөхгүй бөгөөд хамгийн муу зүйл юм. юмс үл үзэгдэх хагаст байдаг. Баримт бичиг байхгүй тохиолдолд бүх төрлийн хакерууд, далд ажлыг олох боломжгүй, миний өмнө ярьсан "Брент"-ийг олохгүй. Доминика ДеГрандисын гайхалтай ном бий . Тэр илчилдэг таван өөр "цаг хугацааны алдагдал" (цаг хугацааны хулгайчид):
- Хэт их ажил явагдаж байна (WIP)
- Үл мэдэгдэх хамаарал
- Төлөвлөөгүй ажил
- Зөрчилтэй тэргүүлэх чиглэлүүд
- Үл тоомсорлосон ажил
Энэ бол маш үнэ цэнэтэй дүн шинжилгээ бөгөөд ном нь маш сайн, гэхдээ өгөгдлийн зөвхөн 50% нь харагдаж байвал энэ бүх зөвлөгөө ашиггүй болно. 90% -иас дээш нарийвчлалтай бол Доминикагийн санал болгож буй аргуудыг ашиглаж болно. Би дарга нь доод албан тушаалтанд 15 минутын даалгавар өгдөг нөхцөл байдлын талаар ярьж байна, гэхдээ түүнд гурван өдөр шаардлагатай; гэтэл дарга нь энэ доод албан тушаалтныг XNUMX-XNUMX хүнээс хамааралтай гэдгийг үнэндээ мэддэггүй.
Финиксийн төсөл бол гурван жил хэтэрхий оройтсон төслийн тухай гайхалтай түүх юм. Үүний улмаас дүрүүдийн нэг нь ажлаас халагдах тул Сократын дүр төрхтэй өөр дүртэй уулздаг. Тэр яг юу буруу болсныг ойлгоход тусалдаг. Энэ компанид Брент гэдэг нэг системийн администратор байдаг бөгөөд бүх ажил ямар нэгэн байдлаар түүгээр дамждаг. Уулзалтын нэг дээр доод албан тушаалтнуудын нэг нь: Яагаад хагас цагийн ажил бүр долоо хоног болдог вэ? Хариулт нь дарааллын онол болон Литлийн хуулийн маш хялбаршуулсан танилцуулга бөгөөд энэ танилцуулгад 90% -ийн ачаалалтай үед ажлын цаг бүр 9 цаг зарцуулдаг болохыг харуулж байна. Даалгавар бүрийг өөр долоон хүнд илгээх шаардлагатай бөгөөд ингэснээр тэр цаг нь 63 цаг болж, 7 дахин үржих нь 9. Миний хэлэх гэсэн санаа бол Бяцхан хууль эсвэл ямар нэгэн нарийн төвөгтэй дарааллын онолыг ашиглахын тулд та ядаж өгөгдөлтэй байх хэрэгтэй.
Тиймээс би харагдах байдлын талаар ярихдаа бүх зүйл дэлгэцэн дээр байгаа гэсэн үг биш, харин танд ядаж өгөгдөл байгаа гэсэн үг юм. Үүнийг хийх үед маш их хэмжээний төлөвлөгдөөгүй ажил байгаа нь ихэвчлэн Брент рүү ямар нэгэн байдлаар илгээгдэж, шаардлагагүй үед гарч ирдэг. Мөн Брент бол агуу залуу, тэр хэзээ ч үгүй гэж хэлэхгүй, гэхдээ тэр ажлаа хэрхэн хийдэг талаар хэнд ч хэлдэггүй.
Ажил харагдах үед өгөгдлийг сайтар ангилж (зураг дээр Доминикагийн хийж байгаа зүйл), таван цаг алдагдсаны хийсвэрлэлийг хэрэглэж, автоматжуулалтыг ашиглаж болно.
2. Ажлын удирдлагын тогтолцоог нэгтгэх: Ажлын менежмент
Миний яриад байгаа архетипүүд бол нэг төрлийн пирамид юм. Хэрэв эхнийх нь зөв хийгдсэн бол хоёр дахь нь аль хэдийн нэг төрлийн нэмэлт юм. Эдгээрийн ихэнх нь гарааны бизнест тохирохгүй, Fortune 5000 гэх мэт томоохон компаниудын хувьд үүнийг санаж байх хэрэгтэй. Миний хамгийн сүүлд ажиллаж байсан компани 10 тасалбарын системтэй байсан. Нэг баг нь Remedy-тэй байсан бол нөгөө нь өөрийн гэсэн ямар нэгэн систем бичсэн, гурав дахь нь Жира ашигладаг, зарим нь цахим шуудангаар ажиллаж байсан. Хэрэв компани 30 өөр шугам хоолойтой бол ижил асуудал үүсдэг, гэхдээ надад ийм бүх тохиолдлыг хэлэлцэх цаг алга.
Би хүмүүстэй тасалбарыг яг яаж бүрдүүлдэг, дараа нь тэдэнд юу тохиолдох, хэрхэн тойрч гарах талаар ярилцдаг. Хамгийн сонирхолтой нь манай хурал дээр хүмүүс нэлээд чин сэтгэлээсээ ярьдаг. Би хэр олон хүн "их нөлөө" өгөх ёстой тасалбар дээр "бага зэргийн / нөлөө үзүүлэхгүй" гэж асуув. Бараг хүн бүр үүнийг хийдэг нь тогтоогдсон. Би буруушаах ажилд оролцдоггүй бөгөөд хүмүүсийг танихгүй байхыг бүх талаар хичээдэг. Тэд надад ямар нэг зүйлийг чин сэтгэлээсээ хүлээхэд би тэр хүнийг өгөхгүй. Гэхдээ бараг бүх хүн системийг тойрч гарахад бүх аюулгүй байдал нь үндсэндээ цонхны чимэглэл гэсэн үг юм. Тиймээс энэ системийн мэдээллээс ямар ч дүгнэлт хийх боломжгүй.
Тасалбарын асуудлыг шийдэхийн тулд нэг үндсэн системийг сонгох хэрэгтэй. Хэрэв та Jira-г ашигладаг бол Jira-г хадгалаарай. Хэрэв өөр хувилбар байгаа бол энэ нь цорын ганц байх болтугай. Хамгийн гол нь тасалбарыг хөгжүүлэх үйл явцын өөр нэг алхам гэж үзэх ёстой. Үйлдэл бүр нь тасалбартай байх ёстой бөгөөд энэ нь хөгжлийн ажлын урсгалаар дамжих ёстой. Тасалбарыг баг руу илгээдэг бөгөөд тэд үүнийг үлгэрийн самбар дээр байрлуулж, дараа нь хариуцна.
Энэ нь дэд бүтэц, үйл ажиллагаа зэрэг бүх хэлтэст хамаарна. Энэ тохиолдолд нөхцөл байдлын талаар дор хаяж зарим үндэслэлтэй санааг бий болгох боломжтой. Энэ үйл явц тогтоогдсоны дараа гэнэт өргөдөл бүрийг хэн хариуцаж байгааг тодорхойлоход хялбар болно. Яагаад гэвэл одоо бид 50% биш, 98% шинэ үйлчилгээг авч байна. Хэрэв энэ үндсэн процесс ажиллаж байвал системийн хэмжээнд нарийвчлал сайжирна.
Үйлчилгээний шугам хоолой
Энэ нь зөвхөн томоохон корпорациудад л хамаатай. Хэрэв та шинэ салбарт ажиллаж байгаа шинэ компани бол ханцуй шамлан Travis CI эсвэл CircleCI-тэй хамтран ажиллана уу. Fortune 5000 компаниудын тухай ярихад миний ажиллаж байсан банкинд тохиолдсон нэг тохиолдол. Google тэдэн дээр ирж, хуучин IBM системүүдийн диаграммыг үзүүлэв. Google-ийн залуус эргэлзэн асуув - үүний эх код хаана байна? Гэхдээ GUI байтугай эх код байхгүй. Энэ бол томоохон байгууллагуудын шийдвэрлэх ёстой бодит байдал юм: 40 жилийн настай банкны бүртгэлүүд эртний үндсэн компьютер дээр. Миний үйлчлүүлэгчдийн нэг нь Circuit Breaker загвар бүхий Kubernetes контейнер, дээр нь Chaos Monkey, бүгдийг нь KeyBank программд ашигладаг. Гэхдээ эдгээр контейнерууд нь COBOL програмтай холбогддог.
Google-ийн залуус миний үйлчлүүлэгчийн бүх асуудлыг шийднэ гэдэгт бүрэн итгэлтэй байсан бөгөөд дараа нь тэд асуулт асууж эхлэв: IBM datapipe гэж юу вэ? Тэдэнд: энэ бол холбогч юм. Энэ нь юутай холбогддог вэ? Sperry систем рүү. Тэгээд тэр юу вэ? гэх мэт. Эхлээд харахад: ямар төрлийн DevOps байж болох вэ? Гэвч үнэн хэрэгтээ энэ нь боломжтой юм. Хүргэлтийн багуудад ажлын урсгалыг шилжүүлэх боломжийг олгодог хүргэх системүүд байдаг.
3. Хязгаарлалтын онол: Хязгаарлалтын онол
Гурав дахь архетип рүү шилжье: институцийн/"овгийн" мэдлэг. Дүрмээр бол аливаа байгууллагад бүх зүйлийг мэддэг, бүгдийг удирддаг хэд хэдэн хүмүүс байдаг. Эдгээр нь тухайн байгууллагад хамгийн удаан ажилласан, бүх асуудлыг шийдэх арга замыг мэддэг хүмүүс юм.
Диаграм дээр гарч ирэхэд би ийм хүмүүсийг тусгайлан тэмдэглэгээгээр дугуйлдаг: жишээлбэл, бүх уулзалтанд тодорхой Лу оролцож байгаа нь харагдаж байна. Энэ нь надад тодорхой байна: энэ бол орон нутгийн Брент юм. CIO намайг подволк, пүүз өмссөн, IBM компанийн костюмтай залуу хоёрын аль нэгийг сонгоход би захиралд нөгөө залуугийн хэлэхгүй, захирал нь сонсоход дургүй байж магадгүй зүйлийг хэлж чаддаг учраас намайг сонгосон. . Тэдний компанид саад тотгор учруулдаг хүн бол Фред, Лу гэдэг хүн гэдгийг би тэдэнд хэлдэг. Энэ гацааг тайлах, тэдний мэдлэгийг ямар нэгэн байдлаар олж авах хэрэгтэй.
Энэ төрлийн асуудлыг шийдэхийн тулд би жишээ нь Slack ашиглахыг санал болгож болно. Ухаалаг захирал асуух болно - яагаад? Ихэвчлэн ийм тохиолдолд DevOps-ийн зөвлөхүүд хариулдаг: учир нь хүн бүр үүнийг хийдэг. Захирал үнэхээр ухаантай юм бол: тэгээд яахав. Ингээд яриа хэлэлцээ өндөрлөж байна. Үүнд би хариулж байна: учир нь компанид Фред, Лу, Сюзи, Жэйн гэсэн дөрвөн гацаа байдаг. Тэдний мэдлэгийг институци болгохын тулд эхлээд Slack-ийг нэвтрүүлэх хэрэгтэй. Таны бүх вики бол утгагүй зүйл, учир нь тэдний оршин тогтнох талаар хэн ч мэдэхгүй. Хэрэв инженерийн баг нь урд болон хойд талын хөгжилд оролцож байгаа бол хүн бүр урд талын хөгжүүлэлтийн баг эсвэл дэд бүтцийн багтай холбогдож асуулт асууж болно гэдгийг мэдэх шаардлагатай. Тэр үед Лу эсвэл Фред хоёр викид нэгдэх цаг гарах байх. Дараа нь Slack-д хэн нэгэн яагаад 5-р алхам ажиллахгүй байгааг асууж магадгүй. Дараа нь Лу эсвэл Фред вики дээрх зааврыг засах болно. Хэрэв та энэ үйл явцыг бий болговол олон зүйл аяндаа биелэгдэх болно.
Энэ бол миний гол санаа юм: аливаа өндөр технологийг санал болгохын тулд эхлээд тэдгээрийн суурийг цэгцлэх ёстой бөгөөд үүнийг дээр дурдсан бага технологийн шийдлүүдийн тусламжтайгаар хийж болно. Хэрэв та өндөр технологиос эхэлж, яагаад хэрэгтэй байгааг тайлбарлаагүй бол дүрмээр бол энэ нь сайнаар дуусдаггүй. Манай үйлчлүүлэгчдийн нэг нь маш хямд бөгөөд энгийн шийдэл болох Azure ML-г ашигладаг. Тэдний асуултын 30 орчим хувьд нь өөрөө суралцах машин хариулсан байна. Энэ зүйлийг өгөгдлийн шинжлэх ухаан, статистик, математикт оролцдоггүй операторууд бичсэн. Энэ бол ач холбогдолтой юм. Ийм шийдлийн өртөг хамгийн бага байдаг.
4. Хамтран ажиллах хакерууд: Хамтран ажиллах хакерууд
Дөрөв дэх архетип бол тусгаарлалттай тэмцэх хэрэгцээ юм. Ихэнх хүмүүс үүнийг аль хэдийн мэддэг: тусгаарлалт нь дайсагналыг төрүүлдэг. Хэрэв хэлтэс бүр өөрийн давхарт байрладаг бөгөөд хүмүүс лифтээс бусад тохиолдолд бие биетэйгээ огтлолцдоггүй бол тэдний хооронд дайсагнал маш амархан үүсдэг. Харин эсрэгээрээ хүмүүс бие биетэйгээ нэг өрөөнд байвал тэр даруй орхино. Хэн нэгэн ерөнхий буруутгалыг шидэх үед, жишээлбэл, ийм интерфейс хэзээ ч ажиллахгүй бол ийм буруутгалыг задлахад хялбар зүйл байхгүй. Интерфэйсийг бичсэн програмистууд тодорхой асуултуудыг асууж эхлэх хэрэгтэй бөгөөд жишээлбэл, хэрэглэгч уг хэрэгслийг буруу ашигласан нь удахгүй тодорхой болно.
Тусгаарлах байдлыг даван туулах олон арга бий. Нэг удаа намайг Австралийн банкинд зөвлөгөө өгөхийг хүссэн ч би хоёр хүүхэд, эхнэртэй болохоор татгалзсан. Тэдэнд туслахын тулд миний хийж чадах зүйл бол график өгүүлэхийг санал болгох явдал байв. Энэ бол үр дүнтэй болох нь батлагдсан зүйл юм. Өөр нэг сонирхолтой арга бол туранхай кофены уулзалт юм. Томоохон байгууллагад энэ нь мэдлэгийг түгээх маш сайн сонголт юм. Нэмж дурдахад та дотоод devopsday, hackathon гэх мэтийг зохион байгуулж болно.
5. Катаг дасгалжуулах
Би эхэндээ анхааруулсанчлан өнөөдөр энэ талаар ярихгүй. Хэрэв та сонирхож байвал үзэж болно .
Энэ сэдвээр Майк Ротерын сайн яриа байдаг:
6. Зах зээлд чиглэсэн: зах зээлд чиглэсэн байгууллага
Энд янз бүрийн асуудал байна. Жишээлбэл, "I" хүмүүс, "T" хүмүүс, "E" хүмүүс. "Би" хүмүүс бол зөвхөн нэг л зүйлийг хийдэг хүмүүс юм. Ихэвчлэн тэд тусгаарлагдсан хэлтэстэй байгууллагуудад байдаг. "Т" гэдэг нь тухайн хүн нэг зүйлд сайн ч бусад зүйлд ч сайн байхыг хэлдэг. "Э" эсвэл бүр "сам" нь хүн олон ур чадвартай байдаг.
Конвейн хууль энд ажилладаг (), үүнийг хамгийн хялбаршуулсан хэлбэрээр дараах байдлаар илэрхийлж болно: хэрэв хөрвүүлэгч дээр гурван баг ажиллавал үр дүн нь гурван хэсгээс бүрдсэн эмхэтгэгч болно. Тиймээс, хэрэв байгууллага доторх өндөр түвшний тусгаарлалт байгаа бол энэ байгууллагад Kubernetes, Circuit breaker, API өргөтгөл болон бусад гоёмсог зүйлсийг тухайн байгууллагатай ижил байдлаар зохион байгуулна. Конвейгийн хэлснээр, та бүх залуу гейкүүдээ харамсаж байна.
Энэ асуудлын шийдлийг олон удаа тайлбарласан. Жишээлбэл, Фернандо Фернандесийн тодорхойлсон зохион байгуулалтын архетипүүд байдаг. Миний сая ярьсан тэр асуудалтай архитектур нь тусгаарлагдсан, функцэд чиглэсэн архитектур юм. Хоёр дахь төрөл нь хамгийн муу, матрицын архитектур, нөгөө хоёрын замбараагүй байдал юм. Гурав дахь нь ихэнх стартапуудад ажиглагддаг зүйл бөгөөд томоохон компаниуд ч энэ төрөлд тохирохыг хичээдэг. Энэ нь зах зээлд чиглэсэн байгууллага юм. Энд бид хэрэглэгчийн хүсэлтэд хамгийн хурдан хариу өгөхийн тулд оновчтой болгодог. Үүнийг заримдаа хавтгай байгууллага гэж нэрлэдэг.
Олон хүмүүс энэ бүтцийг янз бүрээр тайлбарладаг, би үг хэллэгт дуртай баг байгуулах/ажиллуулах, Amazon дээр тэд үүнийг дууддаг хоёр пиццаны баг. Энэ бүтцэд “I” төрлийн бүх хүмүүс нэг үйлчилгээнд нэгдэж, аажмаар “Т” төрөлд ойртож, зөв удирдлагатай бол “Е” ч болж болно. Энд байгаа эхний эсрэг заалт бол ийм бүтэц нь шаардлагагүй элементүүдтэй байдаг. Тестерийн тусгай хэлтэстэй байж чадвал хэлтэс бүрт шалгагч яагаад хэрэгтэй вэ? Үүнд би хариулж байна: Энэ тохиолдолд нэмэлт зардал нь бүхэл бүтэн байгууллагын ирээдүйд "Е" хэлбэрт шилжих үнэ юм. Энэ бүтцэд шалгагч аажмаар сүлжээ, архитектур, дизайн гэх мэтийг сурдаг. Үүний үр дүнд тухайн байгууллагад оролцогч бүр тухайн байгууллагад болж буй бүх зүйлийг бүрэн мэддэг. Хэрэв та энэ схем аж үйлдвэрт хэрхэн ажилладагийг мэдэхийг хүсвэл уншина уу .
7. Зүүн ээлжийн аудиторууд: мөчлөгийн эхэн үед аудит хийх. Аюулгүй байдлын дүрмийг дагаж мөрдөхийг харуулах
Энэ нь таны үйлдэл үнэрийн шалгалтыг давж чадахгүй байх үед юм. Таны төлөө ажилладаг хүмүүс тэнэг биш. Дээрх жишээн дээрх шиг, тэд хаа сайгүй бага зэргийн нөлөөлөл үзүүлж, энэ нь гурван жил үргэлжилсэн бөгөөд хэн ч юу ч анзаараагүй бол систем ажиллахгүй байгааг бүгд сайн мэднэ. Эсвэл өөр нэг жишээ - өөрчлөлтийн зөвлөх зөвлөл, тухайлбал лхагва гараг бүр тайлангаа ирүүлэх шаардлагатай. Тэнд (дашрамд хэлэхэд тийм ч сайн цалин авдаггүй) хэсэг бүлэг хүмүүс ажилладаг бөгөөд тэд онолын хувьд систем бүхэлдээ хэрхэн ажилладагийг мэддэг байх ёстой. Мөн сүүлийн таван жилийн хугацаанд манай систем үнэхээр нарийн төвөгтэй болохыг та анзаарсан байх. Мөн тав, зургаан хүн хийгээгүй, юу ч мэдэхгүй өөрчлөлтийн талаар шийдвэр гаргах ёстой.
Мэдээжийн хэрэг, энэ арга нь ажиллахгүй. Энэ хүмүүс тогтолцоогоо хамгаалахгүй байгаа учраас би ийм зүйлээс салах ёстой. Шийдвэрийг баг өөрөө гаргах ёстой, учир нь баг нь хариуцах ёстой. Тэгэхгүй бол амьдралдаа нэг ч удаа код бичиж үзээгүй менежер программист код бичихэд хэр хугацаа шаардагдахыг хэлснээр гаж нөхцөл байдал үүсдэг. Миний ажиллаж байсан нэг компанид архитектурын самбар, бүтээгдэхүүний самбар гэх мэт өөрчлөлт бүрийг хянадаг 7 өөр зөвлөл байдаг. Заавал хүлээх хугацаа хүртэл байсан ч нэг ажилтан арван жил ажиллахдаа энэ хугацаанд энэ хүний хийсэн өөрчлөлтийг хэн ч үгүйсгэж байгаагүй гэж хэлсэн.
Аудиторуудыг бидэнтэй нэгдэхийг урьж, тэднээс салахгүй байх хэрэгтэй. Хэрэв та бүх шалгалтыг давж чадвал үүрд хувиршгүй хэвээр үлдэх хувиршгүй хоёртын контейнер бичээрэй гэж хэлээрэй. Тэдэнд код болгон дамжуулах хоолой байгаа гэдгээ хэлээд энэ нь юу гэсэн үг болохыг тайлбарла. Дараах схемийг тэдэнд үзүүлээрэй: бүх эмзэг байдлын тестийг давсан чингэлэг дэх зөвхөн унших боломжтой хоёртын файл; тэгээд хэн ч түүнд хүрэхгүй, дамжуулах хоолойг бий болгож буй системд ч хүрдэггүй, учир нь энэ нь динамикаар бүтээгдсэн байдаг. Надад Vault ашиглан блокчэйн шиг зүйлийг бүтээж байгаа Capital One үйлчлүүлэгч бий. Аудитор тогоочоос "жор" үзүүлэх шаардлагагүй бөгөөд үйлдвэрлэлд Жира тасалбар юу болсон, хэн үүнийг хариуцах нь тодорхой болох блокчэйнийг харуулахад хангалттай.
Дагуу , Sonatype 2018 онд бүтээсэн бөгөөд 2017 онд 87 тэрбум OSS татаж авах хүсэлт ирсэн байна.
Эмзэг байдлын улмаас учирсан хохирол нь асар их юм. Түүгээр ч зогсохгүй, дээр дурдсан тоонуудад боломжийн зардлыг оруулаагүй болно. Товчхондоо DevSecOps гэж юу вэ? Энэ нэр хэр амжилттай байгаа талаар ярих сонирхолгүй байгаагаа шууд хэлье. Гол нь DevOps маш амжилттай болсон тул бид уг дамжуулах хоолойд аюулгүй байдлыг нэмэхийг хичээх хэрэгтэй.
Энэ дарааллын жишээ:
Энэ нь тодорхой бүтээгдэхүүний зөвлөмж биш боловч надад бүгд таалагддаг. Аж үйлдвэрийн зохион байгуулалтын парадигм дээр үндэслэсэн DevOps нь бүтээгдэхүүний ажлын үе шат бүрийг автоматжуулах боломжийг олгодог гэдгийг харуулахын тулд би тэдгээрийг жишээ болгон дурдлаа.
Аюулгүй байдлын асуудалд бид ижил хандлагаар хандаж чадахгүй байсан шалтгаан байхгүй.
Үр дүн
Дүгнэж хэлэхэд би DevSecOps-ийн талаар хэдэн зөвлөгөө өгөх болно. Та өөрийн системийг бий болгох үйл явцад аудиторуудыг оролцуулж, тэднийг сургахад цаг зарцуулах хэрэгтэй. Та аудиторуудтай хамтран ажиллах хэрэгтэй. Дараа нь та хуурамч эерэг зүйлсийн эсрэг туйлын хэрцгий тэмцэл хийх хэрэгтэй. Эмзэг байдлыг шалгах хамгийн үнэтэй хэрэгсэл байсан ч гэсэн дохио-дуу чимээний харьцаа ямар байдгийг мэдэхгүй бол хөгжүүлэгчдийн дунд маш муу зуршлыг бий болгож чадна. Хөгжүүлэгчид үйл явдалд дарагдаж, зүгээр л устгах болно. Хэрэв та Equifax-ийн түүхийн талаар сонссон бол хамгийн өндөр сэрэмжлүүлэгийг үл тоомсорлож байсан тэнд яг ийм зүйл болсон. Түүнчлэн, эмзэг байдлыг бизнест хэрхэн нөлөөлж байгааг тодорхой тайлбарлах хэрэгтэй. Жишээлбэл, энэ нь Equifax түүхтэй ижил эмзэг байдал гэж хэлж болно. Аюулгүй байдлын эмзэг байдлыг бусад програм хангамжийн асуудлуудтай адил авч үзэх ёстой, өөрөөр хэлбэл тэдгээрийг DevOps-ийн ерөнхий процесст оруулах ёстой. Та Жира, Канбан гэх мэтээр дамжуулан тэдэнтэй ажиллах хэрэгтэй. Хөгжүүлэгчид өөр хэн нэгэн үүнийг хийх болно гэж бодох ёсгүй - эсрэгээр, хүн бүр үүнийг хийх ёстой. Эцэст нь та хүмүүсийг сургахад эрч хүчээ зарцуулах хэрэгтэй.
Ашигтай холбоосууд
DevOops бага хурлаас танд хэрэг болохуйц цөөн хэдэн илтгэл энд байна:
- Сергей Бердников, Артём Каличкин - Амжилтын түүх буюу “Дев+ДевОпс+Опс” (, )
- Барух Садогурский, Леонид Иголник - Хэмжээ дээрх DevOps: Гурван үйлдэлтэй Грекийн эмгэнэлт явдал (, )
- Александр Титов, Кирилл Толкачев -
- Тимоти Листер -
Орж харах DevOops 2020 Москва - Тэнд бас олон сонирхолтой зүйл байдаг.
Эх сурвалж: www.habr.com