"Devopsni qanday amalga oshirish kerak" degan savol ko'p yillar davomida mavjud, ammo yaxshi materiallar ko'p emas. Ba'zan siz qanday bo'lishidan qat'i nazar, o'z vaqtini sotishga muhtoj bo'lgan aqlli bo'lmagan maslahatchilarning reklamalari qurboni bo'lasiz. Ba'zan bu megakorporatsiyalar kemalari koinotning kengliklarini qanday haydashlari haqida noaniq, juda umumiy so'zlar. Savol tug'iladi: bu biz uchun nima muhim? Hurmatli muallif, g'oyalaringizni ro'yxatda aniq shakllantira olasizmi?
Bularning barchasi kompaniya madaniyatini o'zgartirish natijalari haqida ko'p haqiqiy amaliyot va tushunchalar to'planmaganligidan kelib chiqadi. Madaniyatdagi o'zgarishlar uzoq muddatli narsalar bo'lib, natijalari bir hafta yoki bir oy ichida paydo bo'lmaydi. Bizga yillar davomida kompaniyalar qanday qurilgani va muvaffaqiyatsizlikka uchraganini ko'rish uchun etarlicha keksa odam kerak.
Jon Uillis - DevOpsning otalaridan biri. Jon juda ko'p kompaniyalar bilan ishlashda o'n yillik tajribaga ega. Yaqinda Jon ularning har biri bilan ishlashda sodir bo'ladigan o'ziga xos naqshlarni sezishni boshladi. Ushbu arxetiplardan foydalangan holda, Jon kompaniyalarni DevOps transformatsiyasining haqiqiy yo'liga yo'naltiradi. Ushbu arxetiplar haqida uning DevOops 2018 konferentsiyasidagi hisobotining tarjimasida o'qing.
Ma'ruzachi haqida:
35 yildan ortiq IT menejmenti, Canonical-da OpenCloud salafini yaratishda ishtirok etgan, 10 ta startapda ishtirok etgan, ulardan ikkitasi Dell va Docker-ga sotilgan. Hozirda u SJ Technologies kompaniyasining DevOps va raqamli amaliyotlar bo'yicha vitse-prezidenti.
Keyingi - Jonning nuqtai nazaridan hikoya.
Mening ismim Jon Uillis va meni topishning eng oson joyi Twitterda, . Menda Gmail va GitHub-da bir xil taxalluslar bor. A siz mening hisobotlarimning video yozuvlarini va ular uchun taqdimotlarni topishingiz mumkin.
Men turli yirik kompaniyalarning bosh direktorlari bilan ko'p uchrashuvlar o'tkazaman. Ular ko'pincha DevOps nima ekanligini tushunmasliklari haqida shikoyat qiladilar va ularga tushuntirishga harakat qilgan har bir kishi boshqa narsa haqida gapiradi. Yana bir keng tarqalgan shikoyat shundaki, DevOps ishlamaydi, garchi direktorlar hamma narsani ularga tushuntirilganidek qilishayotganga o'xshaydi. Gap yoshi yuz yildan oshgan yirik kompaniyalar haqida bormoqda. Ular bilan suhbatlashgandan so'ng, men ko'p muammolar uchun yuqori texnologiya emas, balki nisbatan past texnologiyali echimlar eng mos keladi degan xulosaga keldim. Bir necha hafta davomida men turli bo'limlardagi odamlar bilan gaplashdim. Postdagi birinchi rasmda ko'rganingiz mening so'nggi loyiham, xona uch kunlik ishdan keyin shunday ko'rinishga ega edi.
DevOps nima?
Haqiqatan ham, agar siz 10 xil odamdan so'rasangiz, ular 10 xil javob berishadi. Ammo qiziq tomoni shundaki, bu o'nta javobning barchasi to'g'ri bo'ladi. Bu erda noto'g'ri javob yo'q. Men taxminan 10 yil davomida DevOps bilan juda chuqur shug'ullanganman va birinchi DevOpsDayda birinchi amerikalik bo'lganman. Men DevOps bilan shug'ullanadigan barchadan aqlliman deb aytmayman, lekin bunga ko'p kuch sarflagan odam deyarli yo'q. Men DevOps inson kapitali va texnologiya birlashganda paydo bo'lishiga ishonaman. Biz ko'pincha insoniy o'lchovni unutamiz, garchi biz barcha madaniyatlar haqida ko'p gapiramiz.
Endi bizda juda ko'p ma'lumotlar, besh yillik akademik tadqiqotlar, nazariyalarni sanoat miqyosida sinovdan o'tkazish mavjud. Ushbu tadqiqotlar shuni ko'rsatadiki, agar siz tashkiliy madaniyatdagi ba'zi xatti-harakatlar namunalarini birlashtirsangiz, siz 2000x tezlikka erishishingiz mumkin. Ushbu tezlashtirish barqarorlikning teng darajada yaxshilanishi bilan mos keladi. Bu DevOps har qanday kompaniyaga olib kelishi mumkin bo'lgan foydaning miqdoriy o'lchovidir. Bir necha yil oldin men Fortune 5000 kompaniyasining bosh direktoriga DevOps haqida gapirgan edim.Taqdimotga tayyorgarlik ko'rayotganimda juda asabiylashdim, chunki ko'p yillik tajribamni 5 daqiqada umumlashtirishim kerak edi.
Oxirida men quyidagilarni berdim DevOps ta'rifi: Bu inson kapitalini yuqori samarali tashkiliy kapitalga aylantirish imkonini beruvchi amaliyot va naqshlar majmuidir. Bunga misol qilib, Toyota kompaniyasining so'nggi 50 yoki 60 yil davomida qanday ishlashini keltirish mumkin.
(Bundan keyin bunday diagrammalar ma'lumotnoma sifatida emas, balki illyustratsiya sifatida taqdim etiladi. Ularning mazmuni har bir yangi kompaniya uchun farq qiladi. Biroq, rasmni alohida ko'rish va kattalashtirish mumkin.
Eng muvaffaqiyatli bunday amaliyotlardan biri qiymat xar xaritalash. Bu haqda bir nechta yaxshi kitoblar yozilgan, ulardan eng muvaffaqiyatlisi Karen Martin tomonidan yozilgan. Ammo o'tgan yil davomida men hatto bu yondashuv juda yuqori texnologiyali degan xulosaga keldim. Albatta, bu juda ko'p afzalliklarga ega va men uni juda ko'p ishlatganman. Ammo bosh direktor sizdan nima uchun uning kompaniyasi yangi relslarga o'ta olmasligini so'raganda, qiymat oqimini xaritalash haqida gapirishga hali erta. Avval javob berilishi kerak bo'lgan yana ko'p asosiy savollar mavjud.
O'ylaymanki, ko'pchilik hamkasblarimning xatosi shundaki, ular kompaniyaga besh balldan iborat ko'rsatma berib, keyin olti oydan keyin qaytib kelib, nima bo'lganini ko'rishadi. Hatto qiymat oqimini xaritalash kabi yaxshi sxema, aytaylik, ko'r nuqtalarga ega. Turli kompaniyalarning direktorlari bilan yuzlab intervyulardan so'ng, men muammoni uning tarkibiy qismlariga ajratishga imkon beradigan ma'lum bir naqsh ishlab chiqdim va endi biz ushbu komponentlarning har birini tartibda muhokama qilamiz. Har qanday texnologik echimlarni qo'llashdan oldin men ushbu naqshdan foydalanaman va natijada mening barcha devorlarim diagrammalar bilan qoplangan. Yaqinda men investitsiya fondi bilan ishladim va men 100-150 ta shunday sxemalar bilan yakunlandim.
Yomon madaniyat nonushta uchun yaxshi yondashuvlarni iste'mol qiladi
Asosiy g'oya shundan iboratki, agar tashkilotning madaniyati yomon bo'lsa, hech qanday Lean, Agile, SAFE va DevOps yordam bermaydi. Bu xuddi akvatorsiz chuqurlikka sho'ng'ish yoki rentgensiz operatsiya kabi. Boshqacha qilib aytganda, Drucker va Demingni ifodalash uchun: yomon tashkiliy madaniyat har qanday yaxshi tizimni bo'g'ilmasdan yutib yuboradi.
Ushbu asosiy muammoni hal qilish uchun siz quyidagi amallarni bajarishingiz kerak:
- Barcha ishlarni ko'rinadigan qilish: barcha ishlarni ko'rinadigan qilish kerak. Bu ma'lum bir ekranda ko'rsatilishi kerak degan ma'noda emas, balki u kuzatilishi kerak degan ma'noda.
- Konsolidatsiyalangan ishlarni boshqarish tizimlari: boshqaruv tizimlarini birlashtirish zarur. "Qabilaviy" bilimlar va institutsional bilimlar muammosida 9 ta holatdan 10 tasida to'siq odamlardir. Kitobda muammo bitta shaxs, Brent bilan bog'liq edi, bu esa loyihaning uch yilga kechiktirilishiga sabab bo'ldi. Va men bu "Brents" larga hamma joyda duch kelaman. Ushbu to'siqlarni hal qilish uchun men ro'yxatimizning keyingi ikkita elementidan foydalanaman.
- Cheklovlar nazariyasi metodologiyasi: cheklovlar nazariyasi.
- Hamkorlik xakerlari: hamkorlik xakerlari.
- Toyota Kata (): Men Toyota Kata haqida ko'p gapirmayman. Agar qiziqsangiz, mening githubimda bu mavzularning deyarli har birida.
- Bozorga yo'naltirilgan tashkilot: bozorga yo'naltirilgan tashkilot.
- Chapga o'tish auditorlari: tsiklning dastlabki bosqichlarida audit.
Men tashkilot bilan ishlashni juda oddiy boshlayman: men kompaniyaga borib, xodimlar bilan gaplashaman. Ko'rib turganingizdek, yuqori texnologiya yo'q. Sizga kerak bo'lgan narsa - yozish uchun. Men bir xonada bir nechta jamoalarni to'playman va ular menga aytganlarini mening 7 arxetipim nuqtai nazaridan tahlil qilaman. Va keyin men ularga marker beraman va hozirgacha baland ovozda aytganlarini doskaga yozishni so'rayman. Odatda bunday turdagi uchrashuvlarda hamma narsani yozadigan bitta odam bor va eng yaxshi holatda u muhokamaning 10 foizini yozib qo'yishi mumkin. Mening usulim bilan bu ko'rsatkichni taxminan 40% ga oshirish mumkin.
(Ushbu rasmni alohida ko'rish mumkin )
Mening yondashuvim Uilyam Shnayderning ishiga asoslangan. ). Yondashuv har qanday tashkilotni to'rtta kvadratga bo'lish mumkin degan fikrga asoslanadi. Men uchun bu sxema odatda tashkilotni tahlil qilishda yuzaga keladigan boshqa yuzlab sxemalar bilan ishlash natijasidir. Aytaylik, bizda yuqori darajadagi nazoratga ega, ammo malakasi past tashkilot bor. Bu juda istalmagan variant: hamma chiziqni oyoq osti qilganda, lekin hech kim nima qilishni bilmaydi.
Bir oz yaxshiroq variant - bu yuqori darajadagi nazorat va malakaga ega. Agar bunday kompaniya foydali bo'lsa, unda DevOps kerak emas. Nazorat darajasi yuqori, malakasi va hamkorlik darajasi past, lekin ayni paytda yuqori darajadagi madaniyat (ekin etishtirish) bilan ishlash eng qiziq. Demak, korxonada ishlashni yaxshi ko‘radiganlar ko‘p va mehnat aylanmasi past.
(Ushbu rasmni alohida ko'rish mumkin )
Menimcha, qat'iy ko'rsatmalarga ega usullar haqiqatga erishish yo'lida to'sqinlik qiladi. Ayniqsa, qiymat oqimini xaritalashda ma'lumot qanday tuzilishi kerakligi haqida ko'plab qoidalar mavjud. Ishning dastlabki bosqichlarida, men hozir gapiryapman, bu qoidalar hech kimga kerak emas. Agar qo'lida marker bo'lgan kishi doskada kompaniyadagi haqiqiy vaziyatni tasvirlab bersa, bu ishlarning holatini tushunishning eng yaxshi usuli. Bunday ma'lumotlar direktorlarga etib bormaydi. Ayni paytda odamning gapini bo'lib, u qandaydir o'qni noto'g'ri chizgan deb aytish ahmoqlikdir. Ushbu bosqichda oddiy qoidalarni qo'llash yaxshiroqdir, masalan: ko'p darajali abstraktsiyani oddiygina ko'p rangli markerlar yordamida yaratish mumkin.
Takror aytaman, yuqori texnologiya yo'q. Qora marker hamma narsa qanday ishlashining ob'ektiv haqiqatini tasvirlaydi. Qizil marker bilan odamlar hozirgi vaziyatda nima yoqtirmasligini belgilaydilar. Buni men emas, ular yozishi muhim. Uchrashuvdan keyin CIOga borganimda, tuzatish kerak bo'lgan 10 ta narsa ro'yxatini taklif qilmayman. Men kompaniyadagi odamlar aytgan so'zlar va mavjud tasdiqlangan namunalar o'rtasidagi bog'liqlikni topishga intilaman. Nihoyat, ko'k marker muammoning mumkin bo'lgan echimlarini taklif qiladi.
(Ushbu rasmni alohida ko'rish mumkin )
Ushbu yondashuvning misoli endi yuqorida tasvirlangan. Shu yil boshida men bitta bank bilan ishladim. U yerdagi xavfsizlik xodimlari dizayn va talablarni ko'rib chiqishga kelmasliklari kerakligiga ishonch hosil qilishdi.
(Ushbu rasmni alohida ko'rish mumkin )
Va keyin biz boshqa bo'limlarning odamlari bilan gaplashdik va ma'lum bo'ldiki, taxminan 8 yil oldin dasturiy ta'minot ishlab chiqaruvchilari xavfsizlik xodimlarini ishni sekinlashtirgani uchun ishdan bo'shatishgan. Va keyin bu taqiqqa aylandi, bu odatiy hol sifatida qabul qilindi. Garchi aslida hech qanday taqiq yo'q edi.
Uchrashuvimiz juda chalkash tarzda o'tdi: taxminan uch soat davomida besh xil jamoa menga kod va assambleya o'rtasida nima sodir bo'layotganini tushuntira olishmadi. Va bu eng oddiy narsa bo'lib tuyuladi. Aksariyat DevOps maslahatchilari hamma buni allaqachon biladi deb taxmin qilishadi.
Keyin to'rt soat jim turgan IT boshqaruvi bo'yicha mas'ul shaxs biz uning mavzusiga kelganimizda birdan jonlandi va bizni juda uzoq vaqt band qildi. Oxirida men undan uchrashuv haqida qanday fikrda ekanligini so'radim va uning javobini hech qachon unutmayman. U shunday dedi: "Ilgari men bankimizda dasturiy ta'minotni etkazib berishning faqat ikkita usuli bor deb o'ylardim, ammo endi men ularning beshtasi borligini bilaman va men uchtasini ham bilmasdim."
(Ushbu rasmni alohida ko'rish mumkin )
Ushbu bankdagi so'nggi uchrashuv investitsion dasturiy ta'minot jamoasi bilan bo'ldi. Aynan u bilan qog'oz varag'ida marker bilan diagramma yozish taxtadan ko'ra yaxshiroq va hatto aqlli doskadan ham yaxshiroq ekanligi ma'lum bo'ldi.
Siz ko'rib turgan fotosuratlar bizning uchrashuvimizning to'rtinchi kunida mehmonxona konferentsiya xonasi qanday ko'rinishga ega edi. Va biz bu sxemalardan naqshlarni, ya'ni arxetiplarni qidirish uchun foydalandik.
Shunday qilib, men ishchilarga savollar beraman, ular javoblarni uchta rangdagi (qora, qizil va ko'k) markerlar bilan yozadilar. Men ularning javoblarini arxetiplar uchun tahlil qilaman. Keling, barcha arxetiplarni tartibda muhokama qilaylik.
1. Barcha ishlarni ko'rinadigan qilish: ishni ko'rinadigan qilish
Men ishlayotgan kompaniyalarning aksariyati noma'lum ishlarning juda yuqori foiziga ega. Misol uchun, bu bir xodim boshqasiga kelib, shunchaki biror narsa qilishni so'raganida. Katta tashkilotlarda 60% rejalashtirilmagan ish bo'lishi mumkin. Va ishlarning 40% gacha hech qanday tarzda hujjatlashtirilmaydi. Agar bu Boeing bo'lsa, men hayotimda boshqa hech qachon ularning samolyotiga chiqmagan bo'lardim. Agar ishning faqat yarmi hujjatlashtirilgan bo'lsa, unda bu ish to'g'ri bajarilganmi yoki yo'qmi, noma'lum. Boshqa barcha usullar foydasiz bo'lib chiqadi - hech narsani avtomatlashtirishga urinishning ma'nosi yo'q, chunki ma'lum bo'lgan 50% ishning eng izchil va aniq qismi bo'lishi mumkin, avtomatlashtirish katta natijalarni bermaydi va eng yomoni narsalar ko'rinmas yarmida. Hujjatlar yo'q bo'lganda, men allaqachon aytib o'tgan "Brents" ni topa olmay, har xil buzish va yashirin ishlarni topish mumkin emas. Dominika DeGrandisning ajoyib kitobi bor . U ochib beradi besh xil "vaqt oqish" (vaqt o'g'rilari):
- Jarayonda juda ko'p ish (WIP)
- Noma'lum bog'liqliklar
- Rejadan tashqari ish
- Qarama-qarshi ustuvorliklar
- E'tiborsiz ish
Bu juda qimmatli tahlil va kitob ajoyib, ammo ma'lumotlarning atigi 50% ko'rinadigan bo'lsa, bu maslahatlarning barchasi foydasiz. 90% dan yuqori aniqlikka erishilsa, Dominika tomonidan taklif qilingan usullardan foydalanish mumkin. Men xo'jayin qo'l ostidagiga 15 daqiqalik topshiriq beradigan vaziyatlar haqida gapiryapman, lekin buning uchun unga uch kun kerak bo'ladi; lekin boshliq bu qo‘l ostidagining boshqa to‘rt-besh kishiga qaramligini bilmaydi.
Feniks loyihasi - bu uch yil kechikkan loyiha haqida ajoyib hikoya. Qahramonlardan biri shu sababli ishdan bo'shatiladi va u o'ziga xos Sokrat sifatida taqdim etilgan boshqa qahramon bilan uchrashadi. U nima noto'g'ri ekanligini aniqlashga yordam beradi. Ma'lum bo'lishicha, kompaniyada bitta tizim administratori bor, uning ismi Brent va barcha ishlar qandaydir tarzda u orqali o'tadi. Yig'ilishlarning birida qo'l ostidagilardan biriga savol beriladi: nega har bir yarim soatlik ish bir hafta davom etadi? Javob navbat nazariyasi va Littl qonunining juda soddalashtirilgan taqdimotidir va bu taqdimotda 90% band bo'lganda har bir ish soati 9 soat davom etishi ma'lum bo'ldi. Har bir topshiriq boshqa yetti kishiga yuborilishi kerak, shuning uchun bu soat 63 soat, 7 marta 9 bo'ladi. Men aytmoqchi bo'lganim, Little qonuni yoki har qanday murakkab navbat nazariyasini qo'llash uchun hech bo'lmaganda ma'lumotlarga ega bo'lishingiz kerak.
Shunday qilib, men ko'rinish haqida gapirganda, men hamma narsa ekranda ekanligini anglatmayman, lekin sizda hech bo'lmaganda ma'lumotlar bor. Ular buni qilganda, ko'pincha juda katta hajmdagi rejalashtirilmagan ish borligi ma'lum bo'ladi, ular qandaydir tarzda Brentga kerak bo'lmaganda yuboriladi. Brent esa ajoyib yigit, u hech qachon yo‘q demaydi, lekin o‘z ishini qanday bajarayotganini hech kimga aytmaydi.
Ish ko'rinadigan bo'lsa, ma'lumotlarni aniq tasniflash mumkin (fotosuratda Dominik shunday qilyapti), beshta vaqt oqishining mavhumligini qo'llash va avtomatlashtirishni qo'llash mumkin.
2. Ishlarni boshqarish tizimlarini birlashtirish: Vazifalarni boshqarish
Men aytayotgan arxetiplar piramidaning bir turi. Agar birinchisi to'g'ri bajarilgan bo'lsa, ikkinchisi allaqachon qo'shimchaning bir turi. Ularning aksariyati startaplar uchun ishlamaydi, ular Fortune 5000 kabi yirik kompaniyalar uchun yodda tutilishi kerak. Men ishlagan oxirgi kompaniyada 10 ta chipta sotish tizimi mavjud edi. Bir jamoada Remedy bor edi, boshqasi o'z tizimini yozgan, uchinchisi Jiradan foydalangan va ba'zilari elektron pochta bilan shug'ullangan. Agar kompaniyada 30 xil quvur liniyasi bo'lsa, xuddi shunday muammo paydo bo'ladi, lekin menda bunday holatlarning barchasini muhokama qilishga vaqtim yo'q.
Men odamlar bilan chiptalar qanday yaratilganligini, ular bilan nima sodir bo'lishini va ularni qanday chetlab o'tishlarini muhokama qilaman. Eng qizig'i, yig'ilishlarimizda odamlar juda samimiy gapirishadi. Men "katta ta'sir" berilishi kerak bo'lgan chiptalarga qancha odam "kichik ta'sir" qo'yishini so'radim. Ma'lum bo'lishicha, deyarli hamma buni qiladi. Men qoralash bilan shug'ullanmayman va odamlarni aniqlamaslikka har tomonlama harakat qilaman. Ular menga chin dildan nimanidir tan olishsa, men odamni bermayman. Ammo deyarli har bir kishi tizimni chetlab o'tganda, bu barcha xavfsizlik asosan deraza oynasi ekanligini anglatadi. Shuning uchun ushbu tizim ma'lumotlaridan hech qanday xulosa chiqarish mumkin emas.
Chipta muammosini hal qilish uchun siz bitta asosiy tizimni tanlashingiz kerak. Agar siz Jira dan foydalansangiz, uni Jira-da saqlang. Agar biron bir muqobil bo'lsa, u yagona bo'lsin. Xulosa shuki, chiptalar rivojlanish jarayonidagi yana bir qadam sifatida qaralishi kerak. Har bir harakat chiptaga ega bo'lishi kerak, bu ish jarayoni orqali o'tishi kerak. Chiptalar jamoaga yuboriladi, u ularni hikoyalar taxtasiga joylashtiradi va keyin ular uchun javobgarlikni o'z zimmasiga oladi.
Bu barcha bo'limlarga, jumladan, infratuzilma va operatsiyalarga ham tegishli. Bunday holda, hech bo'lmaganda vaziyat haqida ishonchli fikrni shakllantirish mumkin. Ushbu jarayon o'rnatilgandan so'ng, to'satdan har bir ariza uchun kim javobgar ekanligini aniqlash oson bo'ladi. Chunki hozir biz yangi xizmatlarning 50 foizini emas, balki 98 foizini olamiz. Agar ushbu asosiy jarayon ishlayotgan bo'lsa, butun tizimda aniqlik yaxshilanadi.
Xizmatlar quvuri
Bu yana faqat yirik korporatsiyalar uchun amal qiladi. Agar siz yangi sohada yangi kompaniya bo'lsangiz, yengingizni shimalang va Travis CI yoki CircleCI bilan ishlang. Fortune 5000 kompaniyalari haqida gap ketganda, men ishlagan bankda sodir bo'lgan voqea. Google ularga keldi va ularga eski IBM tizimlarining diagrammalari ko'rsatildi. Google yigitlari sarosimaga tushib so'rashdi - buning manba kodi qayerda? Lekin manba kodi, hatto GUI ham yo'q. Bu yirik tashkilotlar bilan shug'ullanishi kerak bo'lgan haqiqat: qadimgi meynfreymdagi 40 yillik bank yozuvlari. Mijozlarimdan biri KeyBank ilovasi uchun Circuit Breaker naqshli Kubernetes konteynerlaridan va Chaos Monkey-dan foydalanadi. Ammo bu konteynerlar oxir-oqibat COBOL ilovasiga ulanadi.
Google yigitlari mening mijozimning barcha muammolarini hal qilishlariga to'liq ishonishdi va keyin ular savollar berishni boshladilar: IBM datapipe nima? Ularga aytiladi: bu ulagich. U nimaga ulanadi? Sperry tizimiga. Va bu nima? Va hokazo. Bir qarashda shunday ko'rinadi: qanday DevOps bo'lishi mumkin? Lekin, aslida, bu mumkin. Ish jarayonini etkazib berish guruhlariga topshirishga imkon beruvchi etkazib berish tizimlari mavjud.
3. Cheklovlar nazariyasi: Cheklovlar nazariyasi
Keling, uchinchi arxetipga o'tamiz: institutsional/"qabilaviy" bilim. Qoida tariqasida, har qanday tashkilotda hamma narsani biladigan va hamma narsani boshqaradigan bir nechta odamlar bor. Bular tashkilotda eng uzoq vaqt ishlagan va barcha vaqtinchalik echimlarni biladiganlardir.
Bu diagrammada paydo bo'lganida, men bunday odamlarni marker bilan aylantiraman: masalan, barcha yig'ilishlarda ma'lum bir Lu ishtirok etgani ma'lum bo'ldi. Va menga tushunarli: bu mahalliy Brent. CIO meni futbolka va krossovkada va IBM kompaniyasidan kostyum kiygan yigitni tanlaganida, men rejissyorga boshqa yigit aytmaydigan va rejissyor eshitishni yoqtirmasligi mumkin bo'lgan narsalarni aytib bera olaman. . Men ularga aytamanki, ularning shirkatidagi muammo Fred va Lou ismli kimdir. Bu darboğazni yechish kerak, ularning bilimlarini u yoki bu tarzda olish kerak.
Bunday muammoni hal qilish uchun men, masalan, Slack-dan foydalanishni taklif qilishim mumkin. Aqlli direktor so'raydi - nega? Odatda, bunday hollarda DevOps maslahatchilari javob berishadi: chunki hamma buni qilmoqda. Agar rejissyor chindan ham aqlli bo‘lsa, shunday deydi. Va bu erda suhbat tugaydi. Bunga mening javobim shunday: chunki kompaniyada to'rtta darboğaz bor, Fred, Lou, Suzi va Jeyn. Ularning bilimlarini institutsionalizatsiya qilish uchun avval Slack-ni joriy qilish kerak. Sizning barcha vikilaringiz mutlaqo bema'nilik, chunki ularning mavjudligi haqida hech kim bilmaydi. Agar muhandislik jamoasi front-end va back-end ishlab chiqishda ishtirok etsa va hamma bilishi kerakki, ular front-end ishlab chiqish guruhi yoki infratuzilma jamoasi bilan bog'lanishlari mumkin. O'shanda Lou yoki Fredning wikiga qo'shilish vaqti bo'lishi mumkin. Va keyin Slack'da kimdir nima uchun, aytaylik, 5-bosqich ishlamayotganini so'rashi mumkin. Keyin Lou yoki Fred wikidagi ko'rsatmalarni tuzatadi. Agar siz ushbu jarayonni yo'lga qo'ysangiz, unda ko'p narsa o'z-o'zidan paydo bo'ladi.
Bu mening asosiy fikrim: har qanday yuqori texnologiyalarni tavsiya qilish uchun siz avval ular uchun poydevor qo'yishingiz kerak va buni yuqorida tavsiflangan past texnologiyali echimlar bilan amalga oshirish mumkin. Agar siz yuqori texnologiyalardan boshlasangiz va ular nima uchun kerakligini tushuntirmasangiz, unda, qoida tariqasida, bu yaxshi tugamaydi. Mijozlarimizdan biri juda arzon va oddiy yechim Azure ML dan foydalanadi. Ularning 30 foizga yaqin savollariga o'z-o'zini o'rganish mashinasining o'zi javob berdi. Va bu narsa ma'lumotlar fani, statistika yoki matematika bilan shug'ullanmagan operatorlar tomonidan yozilgan. Bu muhim. Bunday yechimning narxi minimaldir.
4. Hamkorlik xakerlari: hamkorlikni buzish
To'rtinchi arxetip - izolyatsiyaga qarshi kurashish zarurati. Ko'pchilik buni allaqachon bilishadi: izolyatsiya dushmanlikni keltirib chiqaradi. Agar har bir bo'lim o'z qavatida bo'lsa va odamlar liftdan tashqari hech qanday tarzda bir-biri bilan kesishmasa, ular o'rtasida dushmanlik juda oson paydo bo'ladi. Ammo, aksincha, odamlar bir-biri bilan bir xonada bo'lsa, u darhol chiqib ketadi. Agar kimdir umumiy ayblovni tashlasa, masalan, falon interfeys hech qachon ishlamaydi, bunday ayblovni dekonstruksiya qilishdan osonroq narsa yo'q. Interfeysni yozgan dasturchilar faqat aniq savollar berishni boshlashlari kerak va tez orada, masalan, foydalanuvchi asbobdan noto'g'ri foydalanganligi aniq bo'ladi.
Izolyatsiyani engishning ko'plab usullari mavjud. Bir vaqtlar mendan Avstraliyadagi bankka maslahat berishni so'rashdi, lekin men buni rad etdim, chunki mening ikki farzandim va xotinim bor. Ularga yordam berish uchun men qila oladigan narsa grafik hikoya qilishni tavsiya qilish edi. Bu ishlashi isbotlangan narsa. Yana bir qiziqarli usul - yog'siz qahva uchrashuvlari. Katta tashkilotda bu bilimlarni tarqatish uchun ajoyib imkoniyatdir. Bundan tashqari, siz ichki devopsdays, hackathons va hokazolarni o'tkazishingiz mumkin.
5. Kata murabbiyligi
Boshida ogohlantirganimdek, bugun bu haqda gapirmayman. Agar qiziqsangiz, ko'rib chiqishingiz mumkin .
Mayk Roterning ushbu mavzu bo'yicha yaxshi nutqi ham bor:
6. Bozorga yo'naltirilgan: bozorga yo'naltirilgan tashkilot
Bu erda turli xil muammolar mavjud. Masalan, "I" odamlari, "T" odamlari va "E" odamlari. "Men" odamlari faqat bitta narsani qiladigan odamlardir. Odatda ular alohida bo'limlari bo'lgan tashkilotlarda mavjud. "T" - bu odam bir narsada yaxshi, ammo boshqa narsalarni ham yaxshi biladi. "E" yoki hatto "taroq" - bu odamning ko'p qobiliyatlari bo'lsa.
Bu erda Konvey qonuni ishlaydi (), eng soddalashtirilgan shaklda quyidagicha ifodalanishi mumkin: agar kompilyatorda uchta jamoa ishlasa, natijada uchta qismdan iborat kompilyator bo'ladi. Shuning uchun, agar tashkilot ichida yuqori darajadagi izolyatsiya mavjud bo'lsa, bu tashkilotdagi Kubernetes, Circuit to'xtatuvchisi, API kengaytirilishi va boshqa ajoyib narsalar ham tashkilotning o'zi kabi tartibga solinadi. Konveyga ko'ra va barcha yosh geekslarga qaramay.
Ushbu muammoning echimi ko'p marta tasvirlangan. Masalan, Fernando Fernandes tomonidan tasvirlangan tashkiliy arxetiplar mavjud. Men hozir aytib o'tgan muammoli arxitektura, izolyatsiya qilingan holda, funktsiyaga yo'naltirilgan arxitekturadir. Ikkinchi tur - eng yomon, matritsali arxitektura, qolgan ikkitasining tartibsizligi. Uchinchisi, ko'pchilik startaplarda ko'rinadigan narsa va yirik kompaniyalar ham bu turga mos kelishga harakat qilmoqda. Bu bozorga yo'naltirilgan tashkilotdir. Bu erda biz mijozlar so'rovlariga eng tez javob berish uchun optimallashtiramiz. Bu ba'zan tekis tashkilot deb ataladi.
Ko'pchilik bu tuzilmani turli yo'llar bilan ta'riflaydi, menga so'zlar yoqadi jamoalarni qurish/boshqarish, Amazonda ular buni chaqirishadi ikkita pizza jamoasi. Bu tuzilmada barcha “I” toifadagi odamlar bir xizmat atrofida to‘planib, sekin-asta “T” tipiga yaqinlashadi va agar to‘g‘ri boshqaruv o‘rnatilgan bo‘lsa, ular hatto “E”ga ham aylanib qolishlari mumkin. Bu erda birinchi qarama-qarshilik shundaki, bunday tuzilma keraksiz elementlarga ega. Agar sizda testerlarning maxsus bo'limi bo'lishi mumkin bo'lsa, nima uchun har bir bo'limda tester kerak? Men javob beraman: bu holda qo'shimcha xarajatlar butun tashkilotning kelajakda "E" turiga aylanishi uchun narxdir. Ushbu tuzilmada tester asta-sekin tarmoqlar, arxitektura, dizayn va boshqalarni o'rganadi. Natijada, tashkilotning har bir ishtirokchisi tashkilotda sodir bo'layotgan hamma narsadan to'liq xabardor. Agar siz ushbu sxema sanoatda qanday ishlashini bilmoqchi bo'lsangiz, o'qing .
7. Shift-chap auditorlar: tsiklning boshida audit. Ko'rgazmada xavfsizlik qoidalariga rioya qilish
Bu sizning harakatlaringiz, ta'bir joiz bo'lsa, hid sinovidan o'tmaydi. Siz uchun ishlaydigan odamlar ahmoq emas. Agar yuqoridagi misolda bo'lgani kabi, ular hamma joyda kichik ta'sir o'rnatsalar, bu uch yil davom etgan va hech kim hech narsani sezmagan bo'lsa, unda tizim ishlamayotganini hamma juda yaxshi biladi. Yoki boshqa misol - har bir chorshanba kuni hisobotlarni topshirish kerak bo'lgan o'zgarishlar bo'yicha maslahat kengashi. U erda ishlaydigan bir guruh odamlar bor (aytmoqchi, unchalik yaxshi maosh olmaydilar), ular nazariy jihatdan butun tizim qanday ishlashini bilishlari kerak. Va so'nggi besh yil ichida siz bizning tizimlarimiz nihoyatda murakkab ekanligini payqagandirsiz. Besh-olti kishi esa o‘zlari qilmagan va hech narsa bilmagan o‘zgarish haqida qaror qabul qilishlari kerak.
Albatta, bu yondashuv ishlamaydi. Men bunday narsalardan qutulishim kerak, chunki bu odamlar tizimni himoya qilmaydi. Qarorni jamoaning o'zi qabul qilishi kerak, chunki jamoa bunga javobgar bo'lishi kerak. Aks holda, hayotida hech qachon kod yozmagan menejer dasturchiga kod yozish uchun qancha vaqt ketishi kerakligini aytganida paradoksal holat yuzaga keladi. Men ishlagan bir kompaniyada har bir o'zgarishlarni, jumladan, arxitektura kengashi, mahsulot kengashi va boshqalarni ko'rib chiqadigan 7 xil kengash bor edi. Hatto majburiy kutish davri ham bor edi, garchi bir xodim menga o'n yillik ish davomida hech kim ushbu majburiy muddat davomida bu shaxs tomonidan kiritilgan o'zgartirishni rad etmaganligini aytdi.
Auditorlarni bizga qo'shilishga taklif qilish kerak va ulardan qutulish kerak emas. Ularga o'zgarmas ikkilik konteynerlarni yozishingizni ayting, agar ular barcha testlardan o'tsa, abadiy o'zgarmas qoladi. Ularga kod sifatida quvur liniyasi borligini ayting va bu nimani anglatishini tushuntiring. Ularga quyidagi sxemani ko'rsating: barcha zaiflik testlaridan o'tgan konteynerdagi o'zgarmas faqat o'qish uchun ikkilik; va keyin nafaqat hech kim unga tegmaydi, balki quvur liniyasini yaratadigan tizimga ham tegmaydi, chunki u ham dinamik ravishda yaratilgan. Mening Capital One mijozlarim bor, ular blokcheyn kabi narsalarni yaratish uchun Vault-dan foydalanmoqda. Auditor oshpazdan "retseptlar" ni ko'rsatishi shart emas, ishlab chiqarishda Jira chiptasi bilan nima sodir bo'lganligi va buning uchun kim javobgar ekanligi aniq bo'lgan blokcheynni ko'rsatish kifoya.
Shunga ko'ra , 2018 yilda Sonatype tomonidan yaratilgan bo'lib, 2017 yilda 87 milliard OSS yuklab olish so'rovlari bo'lgan.
Zaifliklar tufayli etkazilgan yo'qotishlar juda katta. Bundan tashqari, yuqorida ko'rib turgan raqamlar imkoniyat xarajatlarini o'z ichiga olmaydi. Qisqacha aytganda DevSecOps nima? Darhol aytmoqchimanki, bu nom qanchalik muvaffaqiyatli ekanligi haqida gapirish menga qiziq emas. Gap shundaki, DevOps juda muvaffaqiyatli bo'lganligi sababli, biz ushbu quvur liniyasiga xavfsizlikni qo'shishga harakat qilishimiz kerak.
Ushbu ketma-ketlikka misol:
Bu ma'lum mahsulotlar uchun tavsiya emas, garchi menga hammasi yoqsa ham. Dastlab sanoatdagi tashkiliy paradigmaga asoslangan DevOps mahsulot ustida ishlashning har bir bosqichini avtomatlashtirishga imkon berishini ko'rsatish uchun ularni misol qilib keltirdim.
Xavfsizlikka bir xil yondosha olmasligimiz uchun hech qanday sabab yo'q.
Xulosa
Xulosa sifatida DevSecOps uchun ba'zi maslahatlar beraman. Tizimlaringizni yaratish jarayoniga auditorlarni kiritishingiz va ularni o'qitishga vaqt ajratishingiz kerak. Auditorlar bilan hamkorlik qilish kerak. Keyinchalik, noto'g'ri pozitivlarga qarshi mutlaqo shafqatsiz kurash olib borishingiz kerak. Hatto eng qimmat zaifliklarni skanerlash vositasida ham, signal-shovqin nisbati qanday ekanligini bilmasangiz, ishlab chiquvchilaringiz orasida juda yomon odatlarni yaratishingiz mumkin. Ishlab chiquvchilar voqealar bilan to'lib-toshgan va ularni shunchaki o'chirib tashlashadi. Agar siz Equifax hikoyasi haqida eshitgan bo'lsangiz, u erda eng yuqori ogohlantirish darajasi e'tiborga olinmagan joyda sodir bo'lgan. Bundan tashqari, zaifliklar biznesga qanday ta'sir qilishini aniq ko'rsatadigan tarzda tushuntirilishi kerak. Masalan, bu Equifax hikoyasidagi kabi zaiflik deb ayta olasiz. Xavfsizlik zaifliklari boshqa dasturiy ta'minot muammolari kabi ko'rib chiqilishi kerak, ya'ni ular umumiy DevOps jarayoniga kiritilishi kerak. Jira, Kanban va boshqalar orqali ular bilan ishlashingiz kerak. Ishlab chiquvchilar buni boshqa birov qiladi deb o'ylamasliklari kerak - aksincha, hamma buni qilishi kerak. Nihoyat, odamlarni o'rgatish uchun energiya sarflashingiz kerak.
Foydali havolalar
DevOops konferentsiyasidan sizga foydali bo'lishi mumkin bo'lgan bir nechta nutqlar:
- Sergey Berdnikov, Artyom Kalichkin - Muvaffaqiyat tarixi yoki "Dev+DevOps+Ops" (, )
- Baruch Sadogurskiy, Leonid Igolnik - miqyosdagi DevOps: uchta aktda yunon fojiasi (, )
- Aleksandr Titov, Kirill Tolkachev -
- Timoti Lister -
Izlang DevOops 2020 Moskva - u erda ham juda ko'p qiziqarli narsalar bor.
Manba: www.habr.com