Suhbat muhokamasi asosida
So'nggi paytlarda DevOps va SRE ta'rifi ustida haqiqiy janglar avj oldi.
Ko'p jihatdan ushbu mavzu bo'yicha munozaralar allaqachon tishlarimni, shu jumladan men ham chekka qo'yganiga qaramay, men ushbu mavzu bo'yicha o'z nuqtai nazarimni Xabra jamoatchiligi sudiga etkazishga qaror qildim. Qiziqqanlar uchun mushukka xush kelibsiz. Va hamma narsa yangidan boshlansin!
Sana oldin
Shunday qilib, qadimgi davrlarda dasturiy ta'minot ishlab chiqaruvchilari va server ma'murlari guruhi alohida yashagan. Birinchisi kodni muvaffaqiyatli yozdi, ikkinchisi birinchisiga aytilgan turli xil iliq, mehribon so'zlardan foydalanib, serverlarni o'rnatdi, vaqti-vaqti bilan ishlab chiquvchilarga kelib, javoban "mening mashinamda hamma narsa ishlaydi" degan keng qamrovli xabarni oldi. Biznes dasturiy ta'minotni kutayotgan edi, hamma narsa bo'sh edi, vaqti-vaqti bilan buzildi, hamma asabiylashdi. Ayniqsa, bu tartibsizlik uchun pul to'lagan kishi. Shonli chiroq davri. Xo'sh, siz DevOps qaerdan kelganini allaqachon bilasiz.
DevOps amaliyotlarining tug'ilishi
Keyin jiddiy yigitlar kelib, aytishdi - bu sanoat emas, siz bunday ishlay olmaysiz. Va ular hayot aylanish modellarini olib kelishdi. Bu erda, masalan, V-model.
Xo'sh, biz nimani ko'ramiz? Biznes kontseptsiya bilan birga keladi, me'morlar dizayn echimlari, ishlab chiquvchilar kod yozadilar va keyin muvaffaqiyatsizlikka uchraydi. Kimdir mahsulotni sinovdan o'tkazadi, kimdir uni oxirgi foydalanuvchiga etkazib beradi va bu mo''jizaviy modelning chiqishida dengiz bo'yida va'da qilingan ob-havoni kutayotgan yolg'iz biznes mijozi o'tiradi. Biz bu jarayonni o'rnatishga imkon beradigan usullar kerak degan xulosaga keldik. Va biz ularni amalga oshiradigan amaliyotlarni yaratishga qaror qildik.
Amaliyot nima degan mavzuda lirik chekinish
Amaliyot deganda men texnologiya va intizomning kombinatsiyasini nazarda tutyapman. Terraform kodidan foydalangan holda infratuzilmani tavsiflash amaliyoti bunga misoldir. Intizom - bu infratuzilmani kod bilan qanday tasvirlash, u ishlab chiquvchining boshida, texnologiya esa terraformaning o'zi.
Va ular ularni DevOps amaliyotlari deb atashga qaror qilishdi - menimcha, ular Rivojlanishdan Operatsiyalargacha degani edi. Biz turli xil aqlli narsalarni o'ylab topdik - CI/CD amaliyotlari, IaC printsipiga asoslangan amaliyotlar, ulardan minglab. Va biz ketamiz, ishlab chiquvchilar kod yozadilar, DevOps muhandislari tizim tavsifini kod ko'rinishida ishchi tizimlarga aylantiradilar (ha, kod, afsuski, shunchaki tavsif, lekin tizimning timsoli emas), etkazib berish davom etmoqda, va hokazo. Kechagi ma'murlar yangi amaliyotlarni o'zlashtirib, g'urur bilan DevOps muhandislari sifatida qayta tayyorgarlikdan o'tishdi va hammasi u erdan ketdi. Kech bo'ldi, tong bo'ldi... kechirasiz, u yerdan emas.
Yana hammasi yaxshi emas, Xudoga shukur
Hamma narsa tinchlanib, turli xil ayyor "metodistlar" DevOps amaliyotlari bo'yicha qalin kitoblar yozishni boshlashlari bilan, mashhur DevOps muhandisi kimligi va DevOps ishlab chiqarish madaniyati ekanligi haqida munozaralar jimgina avj oldi, norozilik yana paydo bo'ldi. To'satdan ma'lum bo'ldiki, dasturiy ta'minotni etkazib berish mutlaqo ahamiyatsiz vazifadir. Har bir rivojlanish infratuzilmasi o'z stekiga ega, uni qayerdadir yig'ishingiz kerak, qayerdadir atrof-muhitni joylashtirishingiz kerak, bu erda sizga Tomcat kerak, bu erda uni ishga tushirishning ayyor va murakkab usuli kerak - umuman olganda, sizning boshingiz ayyor. Va g'alati darajada muammo, birinchi navbatda, jarayonlarni tashkil qilishda bo'lib chiqdi - bu etkazib berish funktsiyasi, xuddi to'siq kabi, jarayonlarni blokirovka qila boshladi. Bundan tashqari, hech kim Operatsiyalarni bekor qilmadi. Bu V-modelda ko'rinmaydi, lekin o'ng tomonda hali ham butun hayot aylanishi mavjud. Natijada, qandaydir tarzda infratuzilmani saqlash, monitoringni kuzatish, hodisalarni hal qilish, shuningdek etkazib berish bilan shug'ullanish kerak. Bular. ishlab chiqishda ham, ishlashda ham bir oyog'ingiz bilan o'tiring - va birdan bu rivojlanish va operatsiyalar bo'lib chiqdi. Va keyin mikroservislar haqida umumiy shov-shuv paydo bo'ldi. Va ular bilan mahalliy mashinalardan ishlab chiqish bulutga o'tishni boshladi - mahalliy ravishda biror narsani disk raskadrovka qilishga harakat qiling, agar o'nlab va yuzlab mikroservislar mavjud bo'lsa, doimiy yetkazib berish omon qolish vositasiga aylanadi. "Kichik kamtarona kompaniya" uchun hammasi yaxshi edi, lekin baribir? Google haqida nima deyish mumkin?
Google tomonidan SRE
Google keldi, eng katta kaktuslarni yedi va qaror qildi - bizga bu kerak emas, bizga ishonchlilik kerak. Va ishonchlilik boshqarilishi kerak. Va men ishonchlilikni boshqaradigan mutaxassislar kerak deb qaror qildim. Men ularni SR muhandislari deb chaqirdim va bu siz uchun, buni odatdagidek yaxshi bajaring, dedim. Mana SLI, mana SLO, mana monitoring. Va operatsiyaga burnini tiqdi. Va u o'zining "ishonchli DevOps" SRE deb ataydi. Hammasi yaxshidek tuyuladi, lekin Google bir nopok buzg'unchilikni amalga oshirishi mumkin edi - SR muhandislari lavozimiga malakali ishlab chiquvchi, shuningdek, ozgina uy vazifasini bajargan va ish tizimlarining ishlashini tushunadigan odamlarni yollash. Bundan tashqari, Googlening o'zi ham bunday odamlarni ishga olishda muammolarga duch kelmoqda - asosan bu erda u o'zi bilan raqobatlashayotgani uchun - kimgadir biznes mantiqini tasvirlab berish kerak. Etkazib berish muhandislarni bo'shatish uchun tayinlangan edi, SR - muhandislar ishonchlilikni boshqaradilar (albatta, to'g'ridan-to'g'ri emas, balki infratuzilmaga ta'sir qilish, arxitekturani o'zgartirish, o'zgarishlar va ko'rsatkichlarni kuzatish, hodisalar bilan shug'ullanish orqali). Yaxshi, qila olasiz . Agar siz Google bo'lmasangiz-chi, lekin ishonchlilik hali ham qandaydir tashvish uyg'otadi?
DevOps g'oyalarini ishlab chiqish
Aynan shu vaqtda lxc dan o'sgan Docker keldi, keyin Docker Swarm va Kubernetes kabi turli xil orkestratsiya tizimlari va DevOps muhandislari nafas olishdi - amaliyotlarning birlashishi etkazib berishni soddalashtirdi. Bu uni shu darajada soddalashtirdiki, hatto ishlab chiquvchilarga etkazib berishni autsorsing qilish mumkin bo'ldi - deployment.yaml nima. Konteynerlash muammoni hal qiladi. Va CI/CD tizimlarining etukligi allaqachon bitta faylni yozish darajasida va biz boramiz - ishlab chiquvchilar buni o'zlari hal qilishlari mumkin. Va keyin biz o'zimizning SREni qanday qilishimiz haqida gapira boshlaymiz, ... bilan yoki hech bo'lmaganda kimdir bilan.
SRE Googleda emas
Xo'sh, biz yetkazib berishni topshirdik, shekilli, biz nafas olamiz, eski yaxshi kunlarga qaytishimiz mumkin, qachonki adminlar protsessor yuklanishini kuzatib, tizimlarni sozlab, sekin va osoyishta krujkalardan tushunarsiz narsalarni ho'plashdi... To'xtang. Shuning uchun biz hamma narsani boshladik (bu juda achinarli!). To'satdan ma'lum bo'ldiki, Google yondashuvida biz ajoyib amaliyotlarni osongina o'zlashtira olamiz - bu protsessorning yuklanishi emas, u erda disklarni qanchalik tez-tez o'zgartirishimiz yoki bulutdagi xarajatlarni optimallashtirish emas, lekin biznes ko'rsatkichlari bir xil mashhur. SLx. Va hech kim ulardan infratuzilmani boshqarishni olib tashlamagan va ular voqealarni hal qilishlari va vaqti-vaqti bilan navbatchilik qilishlari va umuman biznes jarayonlarini kuzatib borishlari kerak. Bolalar, asta-sekin yaxshi darajada dasturlashni boshlang, Google allaqachon sizni kutmoqda.
Xulosa qilish uchun. To'satdan, lekin siz allaqachon o'qishdan charchadingiz va siz tupurib, maqolaga sharhda muallifga yozishni kutolmaysiz. DevOps yetkazib berish amaliyoti sifatida har doim bo'lgan va shunday bo'ladi. Va u hech qaerga ketmaydi. Operatsion amaliyotlar to'plami sifatida SRE bu etkazib berishni muvaffaqiyatli qiladi.
Manba: www.habr.com