DevOps haqida gapirganda asosiy fikrni tushunish qiyinmi? Biz siz uchun aniq o'xshashliklarni, ajoyib formulalarni va mutaxassislarning maslahatlarini to'pladik, ular hatto mutaxassis bo'lmaganlarga ham maqsadga erishishga yordam beradi. Oxir-oqibat, bonus Red Hat xodimlarining shaxsiy DevOpsidir.
DevOps atamasi 10 yil oldin paydo bo'lgan va Twitter xeshtegidan IT olamidagi kuchli madaniy harakatga aylandi, bu haqiqiy falsafa ishlab chiquvchilarni ishlarni tezroq bajarishga, tajriba o'tkazishga va oldinga siljishga undaydi. DevOps raqamli transformatsiya kontseptsiyasi bilan uzviy bog'langan. Ammo IT terminologiyasi bilan tez-tez sodir bo'lganidek, so'nggi o'n yil ichida DevOps o'zi haqida ko'plab ta'riflar, talqinlar va noto'g'ri tushunchalarga ega bo'ldi.
Shuning uchun siz DevOps haqida tez-tez savollarni eshitishingiz mumkin, bu agile bilan bir xilmi? Yoki bu qandaydir maxsus metodologiyami? Yoki bu "hamkorlik" so'zining boshqa sinonimimi?
DevOps ko'plab turli tushunchalarni (doimiy yetkazib berish, uzluksiz integratsiya, avtomatlashtirish va h.k.) o'z ichiga oladi, shuning uchun muhim narsalarni distillash qiyin bo'lishi mumkin, ayniqsa siz ushbu mavzuga ishtiyoqli bo'lsangiz. Biroq, bu mahorat juda foydali, siz o'z fikrlaringizni boshliqlarga etkazishga harakat qilyapsizmi yoki oddiygina oilangiz yoki do'stlaringizdan kimgadir ishingiz haqida gapirib bersangiz ham. Shuning uchun, keling, DevOps-ning terminologik nuanslarini hozircha chetga surib, katta rasmga e'tibor qarataylik.
DevOps nima: 6 ta ta'rif va o'xshashliklar
Biz mutaxassislardan DevOps mohiyatini iloji boricha sodda va qisqacha tushuntirishni so'radik, shunda uning qiymati har qanday texnik bilimga ega o'quvchilarga tushunarli bo'ladi. Ushbu suhbatlar natijalariga asoslanib, biz DevOps haqidagi hikoyangizni yaratishga yordam beradigan eng ajoyib o'xshashlik va ajoyib formulalarni tanladik.
1. DevOps - bu madaniy harakat
"DevOps - bu madaniy harakat bo'lib, unda ikkala tomon (dasturiy ta'minot ishlab chiquvchilari va IT-tizimlar bilan ishlash bo'yicha mutaxassislar) dasturiy ta'minotdan kimdir foydalanishni boshlamaguncha haqiqiy foyda keltirmasligini tan oladilar: mijozlar, mijozlar, xodimlar, maqsad emas", deydi Evelin Oerlich, katta tadqiqotchi. DevOps instituti tahlilchisi. "Shuning uchun ikkala tomon birgalikda dasturiy ta'minotni tez va sifatli yetkazib berishni ta'minlaydilar."
2. DevOps dasturchilarni kuchaytirishga qaratilgan.
"DevOps ishlab chiquvchilarga ilovalarga egalik qilish, ularni ishga tushirish va yetkazib berishni boshidan oxirigacha boshqarish imkonini beradi."
Liberty Mutual sug'urta kompaniyasining DevOps platformalari direktori Jai Shniepp: "Odatda, DevOps avtomatlashtirilgan jarayonlarni qurish va amalga oshirish orqali ishlab chiqarishga ilovalarni etkazib berishni tezlashtirish usuli sifatida muhokama qilinadi". "Ammo men uchun bu muhimroq narsa." DevOps ishlab chiquvchilarga ilovalar yoki muayyan dasturiy ta'minot qismlariga egalik qilish, ularni ishga tushirish va ularni boshidan oxirigacha etkazib berishni boshqarish imkonini beradi. DevOps mas'uliyat chalkashligini bartaraf qiladi va avtomatlashtirilgan, ishlab chiquvchilar tomonidan boshqariladigan infratuzilmani yaratishda ishtirok etayotgan barchaga yo'l-yo'riq ko'rsatadi.
3. DevOps ilovalarni yaratish va yetkazib berishda hamkorlik haqida.
"Sodda qilib aytganda, DevOps - bu dasturiy ta'minotni ishlab chiqarish va yetkazib berishga bo'lgan yondashuv, bu erda hamma birgalikda ishlaydi", deydi BMC kompaniyasining raqamli biznesni avtomatlashtirish bo'limi prezidenti va rahbari Gur Staf.
4. DevOps - bu quvur liniyasi
"Konveyerni yig'ish faqat barcha qismlar bir-biriga mos keladigan bo'lsa mumkin."
"Men DevOps-ni avtomobil yig'ish liniyasi bilan taqqoslagan bo'lardim", deb davom etadi Gur xodimlari. – Bu g‘oya barcha qismlarni oldindan loyihalash va yasashdan iborat bo‘lib, ular keyinchalik individual sozlanmasdan yig‘ilishi mumkin. Konveyerni yig'ish faqat barcha qismlar bir-biriga mos keladigan bo'lsa mumkin. Dvigatelni loyihalashtirgan va quradiganlar uni korpusga yoki ramkaga qanday o'rnatishni o'ylab ko'rishlari kerak. Tormoz qo'yganlar g'ildiraklar haqida o'ylashlari kerak va hokazo. Dasturiy ta'minot bilan ham xuddi shunday bo'lishi kerak.
Biznes mantig'ini yoki foydalanuvchi interfeysini yaratuvchi ishlab chiquvchi mijozlar ma'lumotlarini saqlaydigan ma'lumotlar bazasi, foydalanuvchi ma'lumotlarini himoya qilish uchun xavfsizlik choralari va xizmat katta, ehtimol hatto ko'p million dollarlik foydalanuvchilar auditoriyasiga xizmat qila boshlaganda bularning barchasi qanday ishlashi haqida o'ylashi kerak. ."
“Odamlarni faqat o'z vazifalariga e'tibor qaratishdan ko'ra, boshqalar bajaradigan ish qismlari haqida hamkorlik qilishga va o'ylashga undash eng katta to'siqdir. Agar siz buni qila olsangiz, sizda raqamli o'zgarish uchun ajoyib imkoniyat bor ", deya qo'shimcha qiladi Gur Staff.
5. DevOps - bu odamlar, jarayonlar va avtomatlashtirishning to'g'ri kombinatsiyasi
DevOps institutining ijrochi direktori Jeyn Groll DevOpsni tushuntirish uchun ajoyib o'xshashlikni taklif qildi. Uning so'zlariga ko'ra, "DevOps uchta asosiy toifadagi ingredientlardan iborat retseptga o'xshaydi: odamlar, jarayon va avtomatlashtirish. Ushbu ingredientlarning aksariyati boshqa sohalar va manbalardan olinishi mumkin: Lean, Agile, SRE, CI/CD, ITIL, etakchilik, madaniyat, asboblar. DevOps-ning siri, har qanday yaxshi retsept kabi, ilovalarni yaratish va chiqarish tezligi va samaradorligini oshirish uchun ushbu ingredientlarning to'g'ri nisbatlarini va aralashmasini qanday olishdir.
6. DevOps - bu dasturchilar Formula 1 jamoasi kabi ishlaydi
"Poyga boshidan oxirigacha rejalashtirilgan emas, aksincha, marradan startgacha."
"DevOps tashabbusidan nimani kutish kerakligi haqida gapirganda, men NASCAR yoki Formula 1 poyga jamoasi misolidan foydalanaman", deydi Chris Short, Red Hat bulutli platformasi marketingi katta menejeri va DevOps'ish axborot byulletenining noshiri. - Bunday jamoaning etakchisi bitta maqsadni qo'yadi: poyga yakunida jamoada mavjud resurslar va uning boshiga tushgan qiyinchiliklarni hisobga olgan holda eng yuqori o'rinni egallash. Bunda poyga boshidan oxirigacha emas, aksincha, marradan boshgacha rejalashtirilgan. Birinchidan, oldingizga ulkan maqsad qo'yiladi, so'ngra unga erishish yo'llari aniqlanadi. Keyin ular kichik vazifalarga bo'linadi va jamoa a'zolariga topshiriladi.
“Jamoa poyga oldidan butun haftani pit-stopni takomillashtirishga sarflaydi. U mashaqqatli poyga kunida formasini saqlab qolish uchun kuch mashqlari va kardiyo mashg'ulotlari bilan shug'ullanadi. Poyga davomida yuzaga kelishi mumkin bo'lgan muammolarni birgalikda hal qilishda mashq qiladi. Xuddi shunday, ishlab chiqish guruhi yangi versiyalarni tez-tez chiqarish ko'nikmalarini o'rgatishi kerak. Agar sizda bunday ko'nikmalar va yaxshi ishlaydigan xavfsizlik tizimi bo'lsa, ishlab chiqarishga yangi versiyalarni ishga tushirish ham tez-tez sodir bo'ladi. Bunday dunyoqarashda tezlikni oshirish xavfsizlikni oshirishni anglatadi”, - deydi Short.
"Bu" to'g'ri ish " qilish haqida emas, - deb qo'shimcha qiladi Short, - bu istalgan natijaga to'sqinlik qiladigan imkon qadar ko'p narsalarni yo'q qilish haqida. Haqiqiy vaqtda olingan fikr-mulohazalar asosida hamkorlik qiling va moslashtiring. Anomaliyalarga tayyor bo'ling va ularning maqsadingizga erishishga ta'sirini kamaytirish uchun sifatni yaxshilashga harakat qiling. Bu bizni DevOps dunyosida kutayotgan narsadir.
DevOps-ni qanday kengaytirish mumkin: mutaxassislardan 10 ta maslahat
Shunchaki DevOps va ommaviy DevOps butunlay boshqacha narsalar. Birinchisidan ikkinchisiga boradigan yo'lda qanday qilib to'siqlarni engib o'tish kerakligini aytamiz.
Ko'pgina tashkilotlar uchun DevOpsga sayohat oson va yoqimli boshlanadi. Kichik ishtiyoqli jamoalar tuziladi, eski jarayonlar yangilari bilan almashtiriladi va birinchi muvaffaqiyatlar uzoq kutilmaydi.
Afsuski, bu shunchaki yolg'on glitz, taraqqiyot illyuziyasi, deydi Ben Grinnell, boshqaruvchi direktor va North Highland konsalting kompaniyasining raqamli bo'limi rahbari. Erta g'alabalar, albatta, dalda beradi, lekin ular DevOps-ni tashkilot bo'ylab keng qo'llash bo'yicha yakuniy maqsadga erishishga yordam bermaydi.
Natijada "biz" va "ular" o'rtasida bo'linish madaniyati ekanligini ko'rish oson.
"Ko'pincha tashkilotlar asosiy DevOps uchun yo'l ochadi, deb o'ylagan holda, boshqalar bu yo'ldan borishga qodirmi yoki xohlamaydimi, deb o'ylamasdan, bu kashshof loyihalarni boshlaydilar", deb tushuntiradi Ben Grinnell. - Bunday loyihalarni amalga oshirish uchun jamoalar odatda boshqa joylarda shunga o'xshash ishlarni qilgan, ammo tashkilotingiz uchun yangi bo'lgan o'ziga ishongan "Varangiyaliklar" dan jalb qilinadi. Shu bilan birga, ular hamma uchun majburiy bo'lib qoladigan qoidalarni buzish va yo'q qilishga da'vat etiladi. Natija bilim va ko'nikmalarni uzatishga to'sqinlik qiladigan "biz" va "ular" madaniyati ekanligini ko'rish oson.
"Va bu madaniy muammo DevOps-ni kengaytirish qiyin bo'lgan sabablardan biridir. DevOps jamoalari tez rivojlanayotgan IT-kompaniyalarga xos boʻlgan texnik qiyinchiliklarga duch kelmoqda”, dedi Scalyr asoschisi va raisi Stiv Nyuman.
“Zamonaviy dunyoda xizmatlar ehtiyoj paydo bo'lishi bilanoq o'zgaradi. Doimiy ravishda yangi funksiyalarni joriy qilish va amalga oshirish juda yaxshi, lekin bu jarayonni muvofiqlashtirish va yuzaga keladigan muammolarni bartaraf etish haqiqiy bosh og'rig'idir, deya qo'shimcha qiladi Stiv Nyuman. - Juda tez rivojlanayotgan tashkilotlarda o'zaro faoliyat guruhlari muhandislari o'zgarishlar va u yaratadigan qaramlik darajasidagi kaskad effektlarini ko'rish uchun kurashmoqda. Qolaversa, muhandislar bu imkoniyatdan mahrum bo‘lganlarida xursand bo‘lmaydilar va natijada yuzaga keladigan muammolar mohiyatini tushunishlari qiyinlashadi”.
Yuqorida tavsiflangan ushbu qiyinchiliklarni qanday engish va DevOps-ni yirik tashkilotda ommaviy qabul qilishga o'tish mumkin? Mutaxassislar, hatto sizning yakuniy maqsadingiz dasturiy ta'minotni ishlab chiqish tsiklini va biznes jarayonlarini tezlashtirish bo'lsa ham, sabr-toqatni talab qiladi.
1. Madaniyatni o'zgartirish vaqt talab qilishini unutmang.
Jeyn Groll, DevOps instituti ijrochi direktori: "Menimcha, DevOps-ning kengayishi epchil rivojlanish kabi bosqichma-bosqich va iterativ bo'lishi kerak (va bir xil darajada madaniyatga ham tegishli). Agile va DevOps kichik jamoalarga urg'u beradi. Ammo bu jamoalar soni va integratsiyasi ortib borar ekan, biz ko'proq odamlarning yangi ishlash usullarini o'zlashtiramiz va buning natijasida ommaviy madaniy o'zgarishlar yuz beradi.
2. Rejalashtirish va platforma tanlash uchun yetarli vaqt sarflang
Eran Kinsbruner, Perfecto kompaniyasining yetakchi texnik evangelisti: “Ishlash hajmini oshirish uchun DevOps jamoalari avval anʼanaviy jarayonlar, vositalar va koʻnikmalarni birlashtirishni oʻrganishi, soʻngra DevOpsning har bir alohida bosqichini asta-sekin tarbiyalashi va barqarorlashtirishi kerak. Hammasi foydalanuvchi hikoyalari va qiymat oqimlarini sinchkovlik bilan rejalashtirishdan boshlanadi, so'ngra magistralga asoslangan ishlab chiqish yoki kodni tarmoqqa ajratish va birlashtirish uchun eng mos keladigan boshqa yondashuvlardan foydalangan holda dasturiy ta'minot va versiyalarni boshqarishni yozishdan boshlanadi.
“Keyin integratsiya va sinov bosqichi keladi, bu yerda avtomatlashtirish uchun kengaytiriladigan platforma allaqachon talab qilinadi. Bu erda DevOps jamoalari uchun ularning mahorat darajasi va loyihaning yakuniy maqsadlariga mos keladigan to'g'ri platformani tanlash muhimdir.
Keyingi bosqich - ishlab chiqarishga joylashtirish va bu orkestrlash vositalari va konteynerlar yordamida to'liq avtomatlashtirilgan bo'lishi kerak. DevOps ning barcha bosqichlarida (ishlab chiqarish simulyatori, QA muhiti va haqiqiy ishlab chiqarish muhiti) virtuallashtirilgan muhitga ega bo'lish va tegishli xulosalarni olish uchun har doim testlar uchun faqat eng so'nggi ma'lumotlardan foydalanish muhimdir. Analytics aqlli bo'lishi va tezkor va amaliy fikr-mulohazalarga ega bo'lgan katta ma'lumotlarni qayta ishlashga qodir bo'lishi kerak.
3. Aybni javobgarlikdan olib tashlang.
Gordon Xaff, RedHat Evangelist: "Tajriba o'tkazishga imkon beruvchi va rag'batlantiradigan tizim va atmosferani yaratish, tezkor dasturiy ta'minotni ishlab chiqishda muvaffaqiyatli muvaffaqiyatsizliklar deb ataladigan narsalarga imkon beradi. Bu muvaffaqiyatsizliklar uchun boshqa hech kim javobgar emas degani emas. Darhaqiqat, kim javobgar ekanligini aniqlash osonroq bo'ladi, chunki "mas'ul bo'lish" endi "halokatga sabab bo'lish" degani emas. Ya'ni, mas'uliyatning mohiyati sifat jihatidan o'zgaradi. To'rt omil muhim ahamiyatga ega: buzilish darajasi, yondashuvlar, ishlab chiqarish jarayonlari va rag'batlantirish. (Ushbu omillar haqida ko'proq Gordon Xuffning "DevOps darslari: sog'lom tajribalarning 4 jihati" maqolasida o'qishingiz mumkin.)
4. Oldinga yo'lni tozalang
Ben Grinnell, North Highland konsalting kompaniyasining boshqaruvchi direktori va raqamli bo'limi rahbari: “Mashqlarga erishish uchun men kashshof loyihalar bilan birgalikda “yoʻllarni tozalash” dasturini ishga tushirishni tavsiya qilaman. Ushbu dasturning maqsadi DevOps kashshoflari ortda qoldiradigan axlatni, masalan, eskirgan qoidalar va shunga o'xshash narsalarni tozalashdir, shunda oldinga yo'l aniq bo'lib qoladi.
“Yangi ish usullarining muvaffaqiyatlarini keng nishonlash orqali, kashshof guruhdan tashqariga chiqadigan muloqot orqali odamlarga tashkiliy yordam va jadallikni bering. DevOps loyihalarining keyingi to'lqinida ishtirok etayotgan va DevOps-dan birinchi marta foydalanishdan asabiy bo'lgan odamlarga murabbiylik qiling. Va unutmangki, bu odamlar kashshoflardan juda farq qiladi. ”
5. Asboblarni demokratlashtirish
Stiv Nyuman, Scalyr asoschisi va raisi: “Asboblar odamlardan yashirilmasligi kerak va ular vaqt sarflashni istagan har bir kishi uchun nisbatan oson o'rganishi kerak. Jurnallarni so'rash qobiliyati asbobdan foydalanish uchun "sertifikatlangan" uch kishi bilan cheklangan bo'lsa, sizda juda katta hisoblash muhiti bo'lsa ham, muammoni hal qilish uchun har doim maksimal uch kishi mavjud bo'ladi. Boshqacha aytganda, bu erda jiddiy (biznes) oqibatlarga olib kelishi mumkin bo'lgan darboğaz mavjud.
6. Jamoada ishlash uchun ideal sharoit yarating
Tom Klark, ITVdagi Common Platform rahbari: “Siz hamma narsani qila olasiz, lekin hamma narsani birdaniga emas. Shunday qilib, katta maqsadlar qo'ying, kichikdan boshlang va tez takrorlashda oldinga boring. Vaqt o'tishi bilan siz ishlarni bajarish uchun obro'ga ega bo'lasiz, shuning uchun boshqalar sizning usullaringizdan foydalanishni xohlashadi. Va juda samarali jamoa yaratish haqida tashvishlanmang. Buning o'rniga, odamlarga ideal ish sharoitlarini ta'minlang va samaradorlik keyin bo'ladi."
7. Konvey qonuni va Kanban taxtalari haqida unutmang
Logan Daigle, CollabNetVersionOne dasturiy ta'minotini yetkazib berish va DevOps strategiyasi direktori: “Konvey qonunining oqibatlarini tushunish muhimdir. Mening oddiy iboramda ushbu qonun biz yaratgan mahsulotlar va biz buni amalga oshirish uchun foydalanadigan jarayonlar, shu jumladan DevOps ham bizning tashkilotimiz bilan bir xil tarzda tuzilganligini bildiradi.
"Agar tashkilotda siloslar ko'p bo'lsa va dasturiy ta'minotni rejalashtirish, yaratish va chiqarishda boshqaruv ko'p marta qo'lni almashtirsa, masshtabni o'zgartirish samarasi nolga teng yoki qisqa muddatli bo'ladi. Agar tashkilot bozorga yo'naltirilgan holda moliyalashtiriladigan mahsulotlar atrofida o'zaro faoliyat guruhlarni tuzsa, muvaffaqiyatga erishish imkoniyati keskin ortadi.
“Mashtabni kengaytirishning yana bir muhim jihati Kanban taxtalarida barcha bajarilayotgan ishlarni (WIP, workinprogress) aks ettirishdir. Tashkilotda odamlar buni ko'rishi mumkin bo'lgan joyga ega bo'lsa, bu hamkorlikni rag'batlantiradi, bu esa masshtabni kengaytirishga ijobiy ta'sir qiladi.
8. Eski chandiqlarni qidiring
Manuel Pais, DevOps maslahatchisi va Team Topologies hammuallifi: "DevOps amaliyotlarini Dev va Ops-dan tashqarida qo'llash va ularni boshqa funktsiyalarga qo'llashga urinish eng maqbul yondashuv emas. Bu, albatta, qandaydir ta'sir ko'rsatadi (masalan, qo'lda boshqarishni avtomatlashtirish orqali), lekin agar biz etkazib berish va qayta aloqa jarayonlarini tushunishdan boshlasak, ko'proq narsaga erishish mumkin.
"Agar tashkilotning IT tizimida eski izlar bo'lsa - o'tmishdagi hodisalar natijasida amalga oshirilgan, lekin o'z ahamiyatini yo'qotgan (mahsulotlar, texnologiyalar yoki jarayonlarning o'zgarishi tufayli) protseduralar va boshqaruv mexanizmlari - ularni albatta olib tashlash kerak. yoki samarasiz yoki keraksiz jarayonlarni avtomatlashtirishdan ko'ra silliqlashtirildi.
9. DevOps variantlarini ko'paytirmang
Entoni Edvards, Eggplant operatsion direktori: "DevOps - bu juda noaniq atama, shuning uchun har bir jamoa o'zining DevOps versiyasini tugatadi. Agar tashkilotda birdaniga 20 xil DevOps mavjud bo'lsa, ular bir-biriga juda mos kelmaydigan bo'lsa, bundan ham yomoni yo'q. Uchta ishlab chiqish guruhining har biri ishlab chiqish va mahsulotni boshqarish o'rtasida o'ziga xos, maxsus interfeysga ega bo'lishi mumkin emas. Shuningdek, mahsulotlar ishlab chiqarish simulyatoriga o'tkazilganda fikr-mulohazalarni qayta ishlash uchun o'ziga xos umidlarga ega bo'lmasligi kerak. Aks holda, siz hech qachon DevOps-ni kengaytira olmaysiz."
10. DevOps biznes qiymatini va'z qiling
Stiv Nyuman, Scalyr asoschisi va raisi: “DevOps qiymatini tan olishga harakat qiling. O'rganing va qilayotgan ishingizning foydalari haqida erkin gaplashing. DevOps - bu ajoyib vaqt va pulni tejaydigan vosita (shunchaki o'ylab ko'ring: kamroq ishlamay qolish, tiklanish uchun o'rtacha vaqt qisqaroq) va DevOps jamoalari ushbu tashabbuslarning biznes muvaffaqiyati uchun ahamiyatini tinimsiz ta'kidlashi (va va'z qilishi) kerak. Shunday qilib, siz tarafdorlar doirasini kengaytirishingiz va DevOpsning tashkilotdagi ta'sirini oshirishingiz mumkin.
BONUS
ning Bizning DevOps-larimiz 13-sentabrda yetib boradi - ha, Red Hat dasturiy ta'minot ishlab chiqaruvchisi sifatida o'zining DevOps guruhlari va amaliyotlariga ega.
Tashkilotning boshqa guruhlari uchun ichki avtomatlashtirish xizmatlarini ishlab chiqadigan muhandisimiz Mark Birger o'z tarixini sof rus tilida so'zlab beradi - Red Hat DevOps jamoasi Ansible tomonidan boshqariladigan Hat Virtualization virtual muhitidan ilovalarni to'liq konteyner formatiga qanday ko'chirgani haqida. OpenShift platformasi.
Lekin bu hammasi emas:
Tashkilotlar ish yuklarini konteynerlarga o'tkazgandan so'ng, ilovalarni kuzatishning an'anaviy usullari ishlamasligi mumkin. Ikkinchi ma'ruzada biz jurnalga kirish usulini o'zgartirish motivatsiyasini tushuntiramiz va bizni zamonaviy jurnallar va monitoring usullariga olib borgan yo'lning davomini ko'rsatamiz.
Manba: www.habr.com