Vebinarda ovoz yomon, shuning uchun biz uni transkripsiya qildik.
Mening ismim Medvedev Eduard. Bugun men SRE nima, SRE qanday paydo bo'lganligi, SRE muhandislari qanday ish mezonlari borligi, ishonchlilik mezonlari haqida, bir oz uning monitoringi haqida gaplashaman. Biz tepada yuramiz, chunki siz bir soat ichida ko'p narsani ayta olmaysiz, lekin men qo'shimcha ko'rib chiqish uchun materiallar beraman va biz hammamiz sizni kutamiz . yanvar oyining oxirida Moskvada.
Birinchidan, SRE nima ekanligini - Sayt ishonchliligi muhandisligi haqida gapiraylik. Va u qanday qilib alohida pozitsiya, alohida yo'nalish sifatida paydo bo'ldi. Hammasi an'anaviy rivojlanish doiralarida Dev va Ops ikkita butunlay boshqa jamoa bo'lib, odatda ikkita butunlay boshqa maqsadlarga ega ekanligi bilan boshlandi. Rivojlanish guruhining maqsadi yangi xususiyatlarni ishlab chiqarish va biznes ehtiyojlarini qondirishdir. Operatsiyalar jamoasining maqsadi hamma narsa ishlayotganiga va hech narsa buzilmasligiga ishonch hosil qilishdir. Shubhasiz, bu maqsadlar to'g'ridan-to'g'ri bir-biriga ziddir: hamma narsa ishlashi va hech narsa buzilmasligi uchun imkon qadar kamroq yangi xususiyatlarni ishga tushiring. Shu sababli, hozirgi DevOps deb ataladigan metodologiya hal qilmoqchi bo'lgan ko'plab ichki ziddiyatlar mavjud.
Muammo shundaki, bizda DevOps-ning aniq ta'rifi va DevOps-ning aniq amalga oshirilishi yo'q. Men 2 yil oldin Ekaterinburgdagi konferentsiyada nutq so'zladim va shu paytgacha DevOps bo'limi "DevOps nima" ma'ruzasi bilan boshlandi. 2017-yilda Devops deyarli 10 yoshda, lekin biz hali ham nima ekanligini bahslashamiz. Va bu Google bir necha yil oldin hal qilishga uringan juda g'alati vaziyat.
2016 yilda Google sayt ishonchliligi muhandisligi deb nomlangan kitobni chiqardi. Va aslida, aynan shu kitob bilan SRE harakati boshlandi. SRE - bu DevOps paradigmasining ma'lum bir kompaniyada o'ziga xos tatbiq etilishi. SRE muhandislari tizimlarning ishonchli ishlashini ta'minlashga intiladi. Ular asosan ishlab chiquvchilardan, ba'zida kuchli rivojlanish foniga ega ma'murlardan keladi. Va ular tizim ma'murlari ilgari qilgan ishni qiladilar, ammo kodlar bo'yicha tizimni ishlab chiqish va bilish bo'yicha kuchli ma'lumotlar bu odamlarning odatiy ma'muriy ishlarga moyil emasligiga, balki avtomatlashtirishga moyil bo'lishiga olib keladi.
Ma'lum bo'lishicha, SRE jamoalarida DevOps paradigmasi tizimli muammolarni hal qiladigan SRE muhandislari mavjudligi bilan amalga oshiriladi. Mana, Dev va Ops o'rtasidagi odamlar 8 yildan beri gaplashayotgan bir xil aloqa. SRE ning roli arxitektor roliga o'xshaydi, chunki yangi kelganlar SREga aylanmaydi. O'z karerasining boshida odamlar hali hech qanday tajribaga ega emaslar, kerakli bilim kengligiga ega emaslar. Chunki SRE aniq nima va qachon noto'g'ri bo'lishi mumkinligi haqida juda nozik bilimni talab qiladi. Shuning uchun, bu erda, qoida tariqasida, kompaniya ichida ham, tashqarisida ham biroz tajriba kerak.
Ular SRE va devops o'rtasidagi farq tasvirlangan yoki yo'qligini so'rashadi. U hozirgina tasvirlangan. Biz SRE ning tashkilotdagi o'rni haqida gapirishimiz mumkin. Ushbu klassik DevOps yondashuvidan farqli o'laroq, Ops hali ham alohida bo'lim bo'lib, SRE ishlab chiqish guruhining bir qismidir. Ular mahsulot ishlab chiqarishda ishtirok etadilar. Hatto SRE bir ishlab chiquvchidan boshqasiga o'tadigan rol bo'lgan yondashuv mavjud. Ular kodni ko'rib chiqishda, masalan, UX dizaynerlari, ishlab chiquvchilarning o'zlari, ba'zan mahsulot menejerlari kabi ishtirok etadilar. SRElar bir xil darajada ishlaydi. Biz ularni tasdiqlashimiz kerak, ularni ko'rib chiqishimiz kerak, shunda har bir joylashtirish uchun SRE shunday deydi: “Yaxshi, bu joylashtirish, bu mahsulot ishonchlilikka salbiy ta'sir ko'rsatmaydi. Va agar shunday bo'lsa, unda ba'zi maqbul chegaralar ichida. Bu haqda ham gaplashamiz.
Shunga ko'ra, SRE kodni o'zgartirish uchun veto huquqiga ega. Va umuman olganda, agar SRE noto'g'ri amalga oshirilsa, bu qandaydir kichik nizolarga olib keladi. Sayt ishonchliligi muhandisligi haqidagi xuddi shu kitobda ko'p qismlar, hatto bittasi ham, bu ziddiyatlardan qanday qochish kerakligini aytadi.
Ular SRE axborot xavfsizligi bilan qanday bog'liqligini so'rashadi. SRE axborot xavfsizligi bilan bevosita shug'ullanmaydi. Asosan, yirik kompaniyalarda bu jismoniy shaxslar, testerlar, tahlilchilar tomonidan amalga oshiriladi. Ammo SRE ular bilan o'zaro aloqada bo'ladi, chunki ba'zi operatsiyalar, ba'zi majburiyatlar, xavfsizlikka ta'sir qiluvchi ba'zi joylashtirishlar mahsulotning mavjudligiga ham ta'sir qilishi mumkin. Shu sababli, SRE umuman olganda har qanday jamoalar, shu jumladan xavfsizlik guruhlari, shu jumladan tahlilchilar bilan o'zaro aloqada. Shuning uchun, SRElar asosan DevOps-ni amalga oshirishga harakat qilganda kerak bo'ladi, lekin shu bilan birga, ishlab chiquvchilar uchun yuk juda katta bo'ladi. Ya'ni, ishlab chiqish guruhining o'zi endi ular Ops uchun javobgar bo'lishlari kerakligi bilan bardosh bera olmaydi. Va alohida rol mavjud. Bu rol byudjetda rejalashtirilgan. Ba'zida bu rol jamoaning kattaligida belgilanadi, alohida shaxs paydo bo'ladi, ba'zan esa ishlab chiquvchilardan biri unga aylanadi. Jamoada birinchi SRE shunday paydo bo'ladi.
SRE ta'sir qiladigan tizimning murakkabligi, operatsiyaning ishonchliligiga ta'sir qiluvchi murakkablik zarur va tasodifiydir. Zarur murakkablik - bu mahsulotning murakkabligi yangi mahsulot xususiyatlari talab qiladigan darajada oshib borishi. Tasodifiy murakkablik - bu tizimning murakkabligi ortib borayotganida, lekin mahsulot xususiyati va biznes talablari bunga bevosita ta'sir qilmaydi. Ma'lum bo'lishicha, ishlab chiquvchi biror joyda xatoga yo'l qo'ygan yoki algoritm optimal emas yoki maxsus ehtiyojlarsiz mahsulotning murakkabligini oshiradigan ba'zi qo'shimcha qiziqishlar kiritilgan. Yaxshi SRE har doim bu vaziyatni kesib tashlashi kerak. Ya'ni, tasodifiy qo'shilish tufayli qiyinchilik kuchaygan har qanday majburiyat, har qanday joylashtirish, tortishish so'rovi bloklanishi kerak.
Savol shundaki, nima uchun jamoaga katta bilimga ega bo'lgan muhandis, tizim ma'murini yollash kerak emas. Bizga aytilishicha, muhandis rolidagi ishlab chiquvchi eng yaxshi kadrlar yechimi emas. Muhandis rolidagi ishlab chiquvchi har doim ham eng yaxshi kadrlar echimi emas, lekin bu erda gap shundaki, Ops bilan shug'ullanadigan ishlab chiquvchi avtomatlashtirishga biroz ko'proq intiladi, uni amalga oshirish uchun biroz ko'proq bilim va ko'nikmaga ega. bu avtomatlashtirish. Va shunga ko'ra, biz nafaqat muayyan operatsiyalar uchun vaqtni, nafaqat muntazam, balki MTTR (O'rtacha tiklanish vaqti, tiklanish vaqti) kabi muhim biznes parametrlarini ham qisqartiramiz. Shunday qilib, va biz bu haqda biroz keyinroq gaplashamiz, biz tashkilot uchun pul tejaymiz.
Endi SRE ning ishlash mezonlari haqida gapiraylik. Va birinchi navbatda ishonchlilik haqida. Kichik kompaniyalarda, startaplarda ko‘pincha shunday bo‘ladiki, odamlar xizmat yaxshi yozilsa, mahsulot yaxshi va to‘g‘ri yozilsa, u ishlaydi, buzilmaydi, deb o‘ylashadi. Hammasi shu, biz yaxshi kod yozamiz, shuning uchun buzish uchun hech narsa yo'q. Kod juda oddiy, buzish uchun hech narsa yo'q. Bular bizga testlar kerak emasligini aytadigan bir xil odamlardir, chunki qarang, bu uchta VPI usuli, nega bu erda sindirish kerak.
Bularning barchasi noto'g'ri, albatta. Va bu odamlar amalda bunday kodni tez-tez chaqishadi, chunki narsalar buziladi. Ishlar ba'zida eng oldindan aytib bo'lmaydigan tarzda buziladi. Ba'zida odamlar yo'q, bu hech qachon bo'lmaydi, deyishadi. Va bu har doim sodir bo'ladi. Bu etarlicha tez-tez sodir bo'ladi. Va shuning uchun hech kim 100% mavjud bo'lishga intilmaydi, chunki 100% mavjudlik hech qachon sodir bo'lmaydi. Bu norma. Va shuning uchun biz xizmatning mavjudligi haqida gapirganda, biz doimo to'qqizta haqida gapiramiz. 2 to'qqiz, 3 to'qqiz, 4 to'qqiz, 5 to'qqiz. Agar biz buni uzilish vaqtiga aylantirsak, masalan, 5 to'qqiz, demak, bu yiliga 5 daqiqadan bir oz ko'proq ishlamay qolish, 2 to'qqiz - 3,5 kunlik ishlamay qolish.
Ammo ma'lum bir nuqtada POI, investitsiyalarning daromadliligi pasaygan. Ikki to'qqizdan uch to'qqizga o'tish 3 kundan ortiq vaqtni qisqartirishni anglatadi. To'rtta to'qqizdan beshtagacha o'tish, ishlamay qolish vaqtini yiliga 47 daqiqaga qisqartiradi. Va biznes uchun bu muhim emasligi ma'lum bo'ldi. Va umuman olganda, talab qilinadigan ishonchlilik texnik masala emas, birinchi navbatda, bu biznes masalasi, bu mahsulot masalasi. Mahsulot foydalanuvchilari uchun to'xtab qolishning qaysi darajasi maqbuldir, ular nimani kutishadi, ular qancha pul to'laydi, masalan, qancha pul yo'qotadi, tizim qancha pul yo'qotadi.
Bu erda muhim savol - qolgan komponentlarning ishonchliligi qanday. Chunki ishonchliligi 4 to‘qqizlik smartfonda 5 va 2 to‘qqiz orasidagi farq ko‘rinmaydi. Taxminan aytganda, agar sizning xizmatingizdagi smartfonda yiliga 10 marta biror narsa buzilib qolsa, katta ehtimol bilan 8 marta OS tomonida buzilish sodir bo'lgan. Foydalanuvchi bunga o'rganib qolgan va yiliga yana bir marta e'tibor bermaydi. Ishonchlilikni oshirish va daromadni oshirish narxini o'zaro bog'lash kerak.
Faqat SRE haqidagi kitobda 4 to'qqizdan 3 to'qqizgacha ko'tarilishning yaxshi misoli bor. Ma'lum bo'lishicha, mavjudlikning o'sishi 0,1% dan bir oz kamroq. Va agar xizmatning daromadi yiliga 1 million dollar bo'lsa, daromadning o'sishi 900 dollarni tashkil qiladi. Agar to'qqizta narxni oshirish uchun bizga yiliga 900 dollardan kam mablag 'sarflansa, o'sish moliyaviy jihatdan mantiqiy bo'ladi. Agar u yiliga 900 dollardan ko'proq xarajat qilsa, endi mantiqiy emas, chunki daromadning o'sishi oddiygina mehnat xarajatlarini, resurs xarajatlarini qoplamaydi. Va biz uchun 3 ta to'qqiz etarli bo'ladi.
Bu, albatta, barcha so'rovlar teng bo'lgan soddalashtirilgan misol. Va 3 to'qqizdan 4 to'qqizgacha borish juda oson, lekin shu bilan birga, masalan, 2 to'qqizdan 3 gacha bo'lganida, bu allaqachon 9 ming dollarni tejash, bu moliyaviy ma'noga ega bo'lishi mumkin. Tabiiyki, haqiqatda ro'yxatga olish so'rovining bajarilmasligi sahifani ko'rsatmaslikdan ko'ra yomonroqdir, so'rovlar turli vaznga ega. Ular biznes nuqtai nazaridan butunlay boshqacha mezonga ega bo'lishi mumkin, ammo baribir, qoida tariqasida, agar biz ba'zi o'ziga xos xizmatlar haqida gapirmasak, bu juda ishonchli taxmindir.
Xizmat uchun arxitektura yechimini tanlashda SRE koordinatorlardan biri ekanligi haqida savol oldik. Aytaylik, mavjud infratuzilmaga integratsiyalashuv nuqtai nazaridan, uning barqarorligi yo'qolmasligi uchun. Ha, SRElar, xuddi shunday tarzda, so'rovlarni qabul qilish, majburiyatlarni qabul qilish, relizlar arxitekturaga, yangi xizmatlarni, mikroservislarni joriy etishga, yangi echimlarni amalga oshirishga ta'sir qiladi. Nega oldin aytdimki, tajriba kerak, malaka kerak. Darhaqiqat, SRE har qanday arxitektura va dasturiy yechimdagi blokirovka qiluvchi ovozlardan biridir. Shunga ko'ra, muhandis sifatida SRE, birinchi navbatda, nafaqat tushunishi, balki ba'zi bir aniq qarorlar ishonchlilik, barqarorlikka qanday ta'sir qilishini tushunishi va bu biznes ehtiyojlari bilan qanday bog'liqligini va qaysi nuqtai nazardan maqbul bo'lishi mumkinligini tushunishi kerak. qaysi emas.
Shuning uchun, endi biz faqat ishonchlilik mezonlari haqida gapirishimiz mumkin, ular SREda an'anaviy ravishda SLA (Xizmat darajasi to'g'risida kelishuv) sifatida belgilanadi. Ehtimol, tanish atama. SLI (xizmat darajasi ko'rsatkichi). SLO (xizmat darajasining maqsadi). Xizmat ko'rsatish darajasi to'g'risidagi kelishuv, ehtimol, ramziy atamadir, ayniqsa siz tarmoqlar, provayderlar va xosting bilan ishlagan bo'lsangiz. Bu sizning butun xizmatingizning ishlashini, jarimalarni, xatolar uchun ba'zi jazolarni, ko'rsatkichlarni, mezonlarni tavsiflovchi umumiy kelishuvdir. Va SLI mavjudlik ko'rsatkichining o'zi. Ya'ni, SLI nima bo'lishi mumkin: xizmatdan javob vaqti, foiz sifatida xatolar soni. Bu qandaydir fayl hosting bo'lsa, tarmoqli kengligi bo'lishi mumkin. Tanib olish algoritmlari haqida gap ketganda, indikator, masalan, hatto javobning to'g'riligi ham bo'lishi mumkin. SLO (Service Level Objective) mos ravishda SLI indikatori, uning qiymati va davrining birikmasidir.
Aytaylik, SLA shunday bo'lishi mumkin. Xizmatdan yil davomida 99,95% foydalanish mumkin. Yoki har chorakda 99 soat ichida 3 ta muhim qo'llab-quvvatlash chiptalari yopiladi. Yoki so'rovlarning 85 foizi har oy 1,5 soniya ichida javob oladi. Ya'ni, xatolar va muvaffaqiyatsizliklar juda oddiy ekanligini asta-sekin tushunamiz. Bu maqbul holat, biz buni rejalashtirmoqdamiz, hatto ma'lum darajada hisoblaymiz. Ya'ni, SRE xatolarga yo'l qo'yishi mumkin bo'lgan tizimlarni quradi, ular xatolarga normal javob berishi kerak, bu esa ularni hisobga olishi kerak. Va iloji bo'lsa, ular xatolarni shunday hal qilishlari kerakki, foydalanuvchi ularni sezmaydi yoki sezmaydi, ammo qandaydir vaqtinchalik echim bor, buning natijasida hamma narsa to'liq qulab tushmaydi.
Misol uchun, agar siz YouTube-ga video yuklasangiz va YouTube uni darhol o'zgartira olmasa, agar video juda katta bo'lsa, format optimal bo'lmasa, so'rov tabiiy ravishda kutish vaqti bilan bajarilmaydi, YouTube 502 xatosini bermaydi. , YouTube: “Biz hamma narsani yaratdik, videongiz qayta ishlanmoqda. Taxminan 10 daqiqada tayyor bo'ladi." Bu, masalan, front-end ishlab chiqishdan tanish bo'lgan oqlangan degradatsiya printsipi, agar siz buni hech qachon qilgan bo'lsangiz.
Ishonchlilik, xatolar, kutishlar bilan ishlash uchun juda muhim bo'lgan biz gaplashadigan keyingi atamalar MTBF va MTTR. MTBF - muvaffaqiyatsizliklar orasidagi o'rtacha vaqt. MTTR Tiklanish uchun o'rtacha vaqt, tiklanish uchun o'rtacha vaqt. Ya'ni, xato aniqlangan paytdan boshlab, xatolik paydo bo'lgan paytdan boshlab xizmat to'liq normal ishlashga qaytarilgunga qadar qancha vaqt o'tdi. MTBF asosan kod sifati bo'yicha ish bilan belgilanadi. Ya'ni, SRElarning "yo'q" deb aytishi mumkinligi. Va siz butun jamoani tushunishingiz kerak, SRE "yo'q" desa, u buni zararli ekanligi uchun emas, yomonligi uchun emas, aks holda hamma azob chekishi uchun aytadi.
Shunga qaramay, men tez-tez murojaat qiladigan kitobda juda ko'p maqolalar, ko'plab usullar, ko'plab usullar mavjud, boshqa ishlab chiquvchilar SREni yomon ko'ra boshlamasligiga qanday ishonch hosil qilish kerak. Boshqa tomondan, MTTR sizning SLOlaringiz (Xizmat darajasidagi maqsad) ustida ishlash haqida. Va bu asosan avtomatlashtirish. Chunki, masalan, bizning SLO - har chorakda 4 to'qqizta ish vaqti. Bu shuni anglatadiki, 3 oy ichida biz 13 daqiqa to'xtab qolishga ruxsat berishimiz mumkin. Va ma'lum bo'lishicha, MTTR 13 daqiqadan oshmasligi kerak. Agar biz 13 daqiqada kamida 1 ta to'xtab qolishga javob beradigan bo'lsak, bu biz chorak uchun butun byudjetni tugatganimizni anglatadi. Biz SLOni buzamiz. Avariyaga javob berish va tuzatish uchun 13 daqiqa mashina uchun juda ko'p, lekin odam uchun juda qisqa. Chunki odam ogohlantirish olguncha, u javob bermaguncha, xatoni tushunmaguncha, bir necha daqiqa o'tadi. Biror kishi uni qanday tuzatish kerakligini, nimani tuzatish kerakligini, nima qilish kerakligini tushunmaguncha, bu yana bir necha daqiqa. Va aslida, agar siz shunchaki serverni qayta ishga tushirishingiz yoki yangi tugunni ko'tarishingiz kerak bo'lsa ham, qo'lda MTTR 7-8 daqiqani tashkil qiladi. Jarayonni avtomatlashtirishda MTTR ko'pincha soniya, ba'zan millisekundlarga etadi. Google odatda millisekundlar haqida gapiradi, lekin aslida, albatta, hamma narsa unchalik yaxshi emas.
Ideal holda, SRE o'z ishini deyarli to'liq avtomatlashtirishi kerak, chunki bu to'g'ridan-to'g'ri MTTR, uning ko'rsatkichlari, butun xizmatning SLO va shunga mos ravishda biznes foydasiga ta'sir qiladi. Vaqt o'tib ketgan bo'lsa, bizdan SRE aybi bormi, deb so'raladi. Yaxshiyamki, hech kim aybdor emas. Va bu balmeless postmortem deb ataladigan alohida madaniyat, biz bugun bu haqda gapirmaymiz, lekin biz uni Slurm-da tahlil qilamiz. Bu juda ko'p gapirish mumkin bo'lgan juda qiziqarli mavzu. Taxminiy qilib aytadigan bo'lsak, har chorakda belgilangan vaqtdan oshib ketgan bo'lsa, unda oz-ozdan hamma aybdor, demak, hammani ayblash unumli emas, o'rniga, balki hech kimni ayblamay, vaziyatni to'g'rilab, borimiz bilan ishlaylik. Mening tajribamga ko'ra, bu yondashuv ko'pchilik jamoalar uchun biroz begona, ayniqsa Rossiyada, lekin u mantiqiy va juda yaxshi ishlaydi. Shuning uchun, men maqolaning oxirida ushbu mavzu bo'yicha o'qishingiz mumkin bo'lgan adabiyotlarni tavsiya qilaman. Yoki Slurm SRE-ga keling.
Keling, tushuntiraman. Agar chorakda SLO vaqti oshib ketgan bo'lsa, to'xtab turish vaqti 13 daqiqa emas, balki 15 daqiqa bo'lsa, bunga kim aybdor bo'lishi mumkin? Albatta, SRE aybdor bo'lishi mumkin, chunki u qandaydir yomon majburiyat yoki joylashtirishni aniq qilgan. Buning uchun ma'lumotlar markazi ma'muri aybdor bo'lishi mumkin, chunki u qandaydir rejadan tashqari texnik xizmat ko'rsatgan bo'lishi mumkin. Agar buning uchun ma'lumotlar markazining ma'muri aybdor bo'lsa, unda SLOni muvofiqlashtirganda texnik xizmat ko'rsatishni hisoblamagan Ops xodimi aybdor. Menejer, texnik direktor yoki ma'lumotlar markazi shartnomasini imzolagan va ma'lumotlar markazining SLA talab qilinadigan to'xtash vaqti uchun mo'ljallanmaganligiga e'tibor bermagan kishi aybdor. Shunga ko'ra, bu vaziyatda hamma asta-sekin aybdor. Bu esa bu vaziyatda aybni birovga yuklashdan ma’no yo‘qligini bildiradi. Lekin, albatta, tuzatish kerak. Shuning uchun o'limdan keyingi tekshiruvlar mavjud. Va agar siz, masalan, GitHub postmortems-ni o'qigan bo'lsangiz va bu har doim juda qiziqarli, kichik va har bir alohida holatda kutilmagan voqea bo'lsa, siz hech kim bu aniq shaxs aybdor deb aytmaganligini almashtirishingiz mumkin. Ayb har doim aniq nomukammal jarayonlarga yuklanadi.
Keling, keyingi savolga o'tamiz. Avtomatlashtirish. Boshqa kontekstlarda avtomatlashtirish haqida gapirganda, men ko'pincha siz tejaganingizdan ko'ra ko'proq vaqt sarflamasdan, vazifani avtomatlashtirish ustida qancha vaqt ishlashingiz mumkinligini aytadigan jadvalga murojaat qilaman. Ichimlik bor. Gap shundaki, SRElar vazifani avtomatlashganda, ular nafaqat vaqtni, balki pulni tejashadi, chunki avtomatlashtirish MTTR ga bevosita ta'sir qiladi. Ular, ta'bir joiz bo'lsa, xodimlar va ishlab chiquvchilarning ma'naviyatini tejashadi, bu ham tugaydigan manbadir. Ular tartibni qisqartiradilar. Va bularning barchasi ish va natijada biznesga ijobiy ta'sir ko'rsatadi, garchi avtomatlashtirish vaqt xarajatlari nuqtai nazaridan mantiqiy emasdek tuyulsa ham.
Aslida, u deyarli har doim bor va SRE rolida biror narsa avtomatlashtirilmasligi kerak bo'lgan juda kam holatlar mavjud. Keyinchalik xato byudjeti, xatolar uchun byudjet deb ataladigan narsa haqida gapiramiz. Darhaqiqat, agar siz o'zingiz uchun belgilagan SLOdan ko'ra hamma narsa siz uchun yaxshiroq bo'lsa, bu ham unchalik yaxshi emas. Bu juda yomon, chunki SLO nafaqat pastki chegara, balki taxminiy yuqori chegara sifatida ham ishlaydi. O'zingizga SLO 99% mavjudligini belgilaganingizda va aslida sizda 99,99% bo'lsa, sizda biznesga umuman zarar keltirmaydigan tajribalar uchun joy borligi ma'lum bo'ladi, chunki siz o'zingiz hammasini birgalikda aniqlagansiz va siz bu joy ishlatilmaydi. Sizning xatolaringiz uchun byudjetingiz bor, bu sizning holatlaringizda ishlatilmaydi.
U bilan nima qilamiz. Biz uni hamma narsa uchun ishlatamiz. Ishlab chiqarish sharoitida sinovdan o'tkazish, ishlashga ta'sir qilishi mumkin bo'lgan yangi xususiyatlarni ishlab chiqarish, relizlar, texnik xizmat ko'rsatish, rejalashtirilgan to'xtash vaqtlari uchun. Teskari qoida ham amal qiladi: agar byudjet tugagan bo'lsa, biz yangi hech narsa chiqara olmaymiz, chunki aks holda biz SLOdan oshib ketamiz. Byudjet allaqachon tugagan, biz biror narsani chiqardik, agar u ishlashga salbiy ta'sir ko'rsatsa, ya'ni bu o'z-o'zidan SLOni to'g'ridan-to'g'ri oshiradigan tuzatish bo'lmasa, biz byudjetdan tashqariga chiqamiz va bu yomon holat. , uni tahlil qilish, o'limdan keyin va, ehtimol, ba'zi jarayonlarni tuzatish kerak.
Ya'ni, agar xizmatning o'zi yaxshi ishlamasa va SLO sarflansa va byudjet eksperimentlarga emas, ayrim nashrlarga emas, balki o'z-o'zidan sarflansa, qiziqarli xususiyatlar o'rniga ba'zi qiziqarli tuzatishlar o'rniga, qiziqarli nashrlar o'rniga. Har qanday ijodiy ish o'rniga, byudjetni tartibga solish yoki SLOni tahrirlash uchun ahmoqona tuzatishlar bilan shug'ullanishingiz kerak bo'ladi va bu ham tez-tez sodir bo'lmasligi kerak bo'lgan jarayon.
Shu sababli, xatolar uchun ko'proq byudjetga ega bo'lgan vaziyatda hamma manfaatdor: SRE ham, ishlab chiquvchilar ham. Ishlab chiquvchilar uchun xatolar uchun katta byudjet siz relizlar, testlar, tajribalar bilan shug'ullanishingiz mumkinligini anglatadi. SRElar uchun xatolar uchun byudjet va bu byudjetga kirish ularning bevosita o'z vazifalarini yaxshi bajarayotganligini anglatadi. Va bu qandaydir qo'shma ishning motivatsiyasiga ta'sir qiladi. Agar siz o'zingizning SRElaringizni ishlab chiquvchi sifatida tinglasangiz, yaxshi ish uchun ko'proq joy va kamroq tartibli bo'lasiz.
Ma'lum bo'lishicha, ishlab chiqarishdagi tajribalar katta jamoalarda SREning juda muhim va deyarli ajralmas qismidir. Va bu odatda xaos muhandisligi deb ataladi, bu Netflix jamoasi tomonidan Chaos Monkey deb nomlangan yordam dasturini chiqargan.
Chaos Monkey CI/CD quvuriga ulanadi va ishlab chiqarishda serverni tasodifiy ishdan chiqaradi. Shunga qaramay, SRE tuzilmasida biz buzilgan serverning o'zi yomon emasligi haqida gapiramiz, bu kutilmoqda. Va agar u byudjet doirasida bo'lsa, u maqbuldir va biznesga zarar etkazmaydi. Albatta, Netflix yetarlicha ortiqcha serverlarga, yetarlicha replikatsiyaga ega, bularning barchasi tuzatilishi mumkin va umuman foydalanuvchi buni sezmasligi uchun va bundan tashqari, hech kim biron bir byudjet uchun bitta serverni tark etmaydi.
Netflix bir muncha vaqt davomida bunday yordamchi dasturlarning to'liq to'plamiga ega edi, ulardan biri Chaos Gorilla Amazonning mavjud zonalaridan birini butunlay o'chirib qo'yadi. Va bunday narsalar, birinchi navbatda, nimaga ta'sir qilishi, nimaga bog'liqligi to'liq aniq bo'lmaganda, yashirin bog'liqliklarni ochishga yordam beradi. Va bu, agar siz mikroservis bilan ishlayotgan bo'lsangiz va hujjatlar unchalik mukammal bo'lmasa, bu sizga tanish bo'lishi mumkin. Va yana, bu koddagi xatolarni sahnalashda qo'lga kirita olmaydigan darajada aniqlashga yordam beradi, chunki har qanday sahnalashtirish aniq simulyatsiya emas, chunki yuk shkalasi boshqacha, yuk sxemasi boshqacha, uskunalar shuningdek, ehtimol, boshqa. Eng yuqori yuklar ham kutilmagan va oldindan aytib bo'lmaydigan bo'lishi mumkin. Va yana byudjetdan tashqariga chiqmaydigan bunday testlar infratuzilmadagi xatolarni aniqlashga yordam beradi, bu sahnalashtirish, avtotestlar, CI / CD quvurlari hech qachon ushlamaydi. Va bularning barchasi sizning byudjetingizga kiritilgan ekan, sizning xizmatingiz u erda tushib ketganligi muhim emas, garchi u juda qo'rqinchli bo'lib tuyulsa ham, server ishdan chiqdi, bu qanday dahshatli tush. Yo'q, bu normal, bu yaxshi, bu xatolarni ushlashga yordam beradi. Agar sizda byudjet bo'lsa, uni sarflashingiz mumkin.
Savol: Qanday adabiyotlarni tavsiya qilishim mumkin? Ro'yxat oxirida. Ko'p adabiyot bor, men bir nechta hisobotlarni maslahat beraman. Bu qanday ishlaydi va SRE o'z dasturiy mahsuloti bo'lmagan yoki minimal ishlab chiqilgan kompaniyalarda ishlaydi. Masalan, asosiy faoliyat dasturiy ta'minot bo'lmagan korxonada. Asosiy faoliyati dasturiy ta'minot bo'lmagan korxonada SRE hamma joyda bo'lgani kabi ishlaydi, chunki korxonada siz ishlab chiqilmagan bo'lsa ham dasturiy mahsulotlardan foydalanishingiz kerak, yangilanishlarni chiqarishingiz kerak, o'zgartirishingiz kerak. infratuzilma, siz o'sishingiz kerak, siz masshtablashingiz kerak. Va SRElar ushbu jarayonlarda yuzaga kelishi mumkin bo'lgan muammolarni aniqlash va bashorat qilishga yordam beradi va ba'zi o'sish boshlanganidan keyin va biznes ehtiyojlari o'zgargandan keyin ularni nazorat qiladi. Chunki agar sizda kamida bir nechta serverlar bo'lsa va sizda hech bo'lmaganda biroz o'sish kutilsa, SREga ega bo'lish uchun dasturiy ta'minotni ishlab chiqishda qatnashish mutlaqo shart emas.
Xuddi shu narsa kichik loyihalar, kichik tashkilotlar uchun ham amal qiladi, chunki yirik kompaniyalarning byudjeti va tajriba uchun joy bor. Ammo shu bilan birga, bu tajribalarning barcha mevalaridan istalgan joyda foydalanish mumkin, ya'ni SRE, albatta, Google, Netflix, Dropbox-da paydo bo'ldi. Ammo shu bilan birga, kichik kompaniyalar va startaplar allaqachon siqilgan materiallarni o'qishlari, kitoblarni o'qishlari, hisobotlarni tomosha qilishlari mumkin. Ular bu haqda tez-tez eshitishni boshlaydilar, aniq misollarni ko'rishadi, menimcha, bu yaxshi, bu haqiqatan ham foydali bo'lishi mumkin, bu bizga ham kerak, bu ajoyib.
Ya'ni, ushbu jarayonlarni standartlashtirish bo'yicha barcha asosiy ishlar siz uchun allaqachon qilingan. Sizning kompaniyangizda SRE ning rolini aniq belgilashingiz va bu amaliyotlarning barchasini amalda qo'llashni boshlashingiz kerak, ular allaqachon tasvirlangan. Ya'ni, kichik kompaniyalar uchun foydali tamoyillardan bu har doim SLA, SLI, SLO ta'rifi. Agar siz dasturiy ta'minot bilan shug'ullanmasangiz, bular ichki SLA va ichki SLO, xatolar uchun ichki byudjet bo'ladi. Bu deyarli har doim jamoada va biznesda qiziqarli munozaralarga olib keladi, chunki siz infratuzilmaga, ideal jarayonlarni qandaydir tashkil etishga sarflayotganingiz ma'lum bo'lishi mumkin, ideal quvur liniyasi zarur bo'lganidan ancha ko'p. Va siz IT bo'limida mavjud bo'lgan ushbu 4 ta to'qqizta sizga hozir kerak emas. Shu bilan birga, siz vaqt sarflashingiz, xatolar uchun byudjetni boshqa narsaga sarflashingiz mumkin.
Shunga ko'ra, monitoring va monitoringni tashkil etish har qanday hajmdagi kompaniya uchun foydalidir. Va umuman olganda, bunday fikrlash usuli, xatolar maqbul bo'lgan joyda, byudjet mavjud bo'lgan joyda, Maqsadlar mavjud bo'lgan joyda, 3 kishilik startaplardan boshlab, har qanday hajmdagi kompaniya uchun yana foydalidir.
Texnik nuanslarning oxirgisi - bu monitoring. Chunki agar biz SLA, SLI, SLO haqida gapiradigan bo'lsak, biz byudjetga mos keladimi yoki yo'qmi, Maqsadlarimizga mos keladimi yoki yo'qmi va yakuniy SLAga qanday ta'sir qilishimizni kuzatmasdan tushuna olmaymiz. Monitoring shunday bo'lishini ko'p marta ko'rganman: ba'zi qiymatlar mavjud, masalan, serverga so'rov vaqti, o'rtacha vaqt yoki ma'lumotlar bazasiga so'rovlar soni. U muhandis tomonidan belgilangan standartga ega. Agar ko'rsatkich me'yordan chetga chiqsa, u holda elektron pochta keladi. Bularning barchasi, qoida tariqasida, mutlaqo befoyda, chunki bu ogohlantirishlarning ko'pligiga, monitoringdan kelgan xabarlarning ko'pligiga olib keladi, qachonki odam, birinchi navbatda, har safar ularni sharhlashi kerak, ya'ni metrikaning qiymatini aniqlashi kerak. ba'zi harakatlar zarurati. Ikkinchidan, u bu ogohlantirishlarni sezishni to'xtatadi, chunki undan hech qanday harakat talab etilmaydi. Bu yaxshi monitoring qoidasi va SRE amalga oshirilganda birinchi qoida shundan iboratki, bildirishnoma faqat harakat talab qilinganda kelishi kerak.
Standart holatda, hodisalarning 3 darajasi mavjud. Ogohlantirishlar bor, chiptalar bor, jurnallar mavjud. Ogohlantirishlar zudlik bilan chora ko'rishni talab qiladigan har qanday narsadir. Ya'ni, hamma narsa buzilgan, siz hozir uni tuzatishingiz kerak. Kechiktirilgan harakatni talab qiladigan narsa chiptalardir. Ha, siz biror narsa qilishingiz kerak, qo'lda biror narsa qilishingiz kerak, avtomatlashtirish muvaffaqiyatsiz tugadi, lekin keyingi bir necha daqiqada buni qilish shart emas. Jurnallar - bu harakatni talab qilmaydigan har qanday narsa va umuman olganda, agar ishlar yaxshi ketsa, hech kim ularni hech qachon o'qimaydi. Siz faqat jurnallarni o'qib chiqishingiz kerak bo'ladi, qachonki, orqaga qarab, bir muncha vaqt davomida biror narsa buzilganligi ma'lum bo'ldi, biz bu haqda bilmaganmiz. Yoki siz biron bir tadqiqot qilishingiz kerakmi? Ammo umuman olganda, hech qanday harakat talab qilmaydigan hamma narsa jurnallarga o'tadi.
Bularning barchasining yon ta'siri sifatida, agar biz qanday hodisalar harakatlarni talab qilishini aniqlagan bo'lsak va bu harakatlar qanday bo'lishi kerakligini yaxshi tasvirlab bergan bo'lsak, bu harakatni avtomatlashtirish mumkinligini anglatadi. Ya'ni, nima bo'ladi. Biz ogohlantirishdan ketamiz. Keling, harakatga o'tamiz. Biz ushbu harakatning tavsifiga o'tamiz. Va keyin biz avtomatlashtirishga o'tamiz. Ya'ni, har qanday avtomatlashtirish hodisaga reaktsiya bilan boshlanadi.
Monitoringdan biz Kuzatish mumkin bo'lgan atamaga o'tamiz. So'nggi bir necha yil ichida bu so'z atrofida biroz shov-shuv ham bo'ldi. Va kontekstdan tashqari bu nimani anglatishini kam odam tushunadi. Ammo asosiy nuqta shundaki, Kuzatish qobiliyati tizim shaffofligi uchun ko'rsatkichdir. Agar biror narsa noto'g'ri bo'lgan bo'lsa, aynan nima noto'g'ri bo'lganini va tizimning o'sha paytdagi holatini qanchalik tez aniqlashingiz mumkin. Kod nuqtai nazaridan: qaysi funktsiya muvaffaqiyatsiz tugadi, qaysi xizmat muvaffaqiyatsiz tugadi. Qanday holatda edi, masalan, ichki o'zgaruvchilar, konfiguratsiya. Infratuzilma nuqtai nazaridan, bu qaysi mavjudlik zonasida nosozlik sodir bo'lgan va agar sizda Kubernetlar bo'lsa, qaysi podda nosozlik yuz bergan, podaning holati qanday bo'lgan. Va shunga ko'ra, Observability MTTR bilan bevosita aloqada. Xizmatning kuzatilishi qanchalik yuqori bo'lsa, xatoni aniqlash osonroq bo'ladi, xatoni tuzatish osonroq bo'ladi, xatoni avtomatlashtirish osonroq bo'ladi, MTTR past bo'ladi.
Yana kichik kompaniyalarga o'tsak, hozir ham jamoaning kattaligi bilan qanday kurashish kerakligi va kichik jamoa alohida SREni yollash kerakmi yoki yo'qligini so'rash juda keng tarqalgan. Bu haqda biroz oldinroq gapirgan edik. Startap yoki, masalan, jamoa rivojlanishining dastlabki bosqichlarida bu mutlaqo kerak emas, chunki SRE o'tish rolini bajarishi mumkin. Va bu jamoani biroz jonlantiradi, chunki hech bo'lmaganda turli xillik mavjud. Bundan tashqari, bu odamlarni o'sish bilan, umuman olganda, SRE mas'uliyati sezilarli darajada o'zgarishiga tayyorlaydi. Agar siz odamni yollagan bo'lsangiz, unda, albatta, u qandaydir umidlarga ega. Va bu umidlar vaqt o'tishi bilan o'zgarmaydi, lekin talablar juda o'zgaradi. Shuning uchun, SREni qanday yollash dastlabki bosqichlarda juda qiyin. O'zingizni o'stirish ancha oson. Ammo bu haqda o'ylashga arziydi.
Faqatgina istisno, ehtimol, o'sish uchun juda qattiq va aniq belgilangan talablar mavjud bo'lganda. Ya'ni, startap bo'lsa, bu investorlar tomonidan qandaydir bosim, bir vaqtning o'zida bir necha marta o'sish uchun qandaydir prognoz bo'lishi mumkin. Keyin SREni yollash asosan oqlanadi, chunki u oqlanishi mumkin. Bizda o'sish uchun talablar bor, bizga bunday o'sish bilan hech narsa buzilmasligi uchun javobgar bo'ladigan odam kerak.
Yana bir savol. Ishlab chiquvchilar bir necha marta sinovlardan o'tadigan, ammo ishlab chiqarishni buzadigan, bazani yuklaydigan, boshqa funktsiyalarni buzadigan, qaysi jarayonni amalga oshirishni buzadigan xususiyatni kesib tashlaganida nima qilish kerak. Shunga ko'ra, bu holda, kiritilgan xatolar uchun byudjet hisoblanadi. Va ba'zi xizmatlar, ba'zi xususiyatlar allaqachon ishlab chiqarishda sinovdan o'tkazilmoqda. Bu kanareyka bo'lishi mumkin, faqat oz sonli foydalanuvchilar, lekin ishlab chiqarishda allaqachon xususiyat ishga tushirilganda, lekin agar biror narsa buzilgan bo'lsa, masalan, barcha foydalanuvchilarning yarmi uchun u hali ham javob beradi degan umidda. xatolar uchun byudjet. Shunga ko'ra, ha, xato bo'ladi, ba'zi foydalanuvchilar uchun hamma narsa buziladi, lekin biz allaqachon bu normal ekanligini aytdik.
SRE vositalari haqida savol bor edi. Ya'ni, SRElar ishlatadigan, boshqalar ishlatmaydigan biror narsa bormi? Aslida, ba'zi bir yuqori ixtisoslashgan yordamchi dasturlar mavjud, masalan, yuklarni simulyatsiya qiladigan yoki kanareyka A / B sinovlari bilan shug'ullanadigan dasturiy ta'minot mavjud. Lekin, asosan, SRE asboblar to'plami sizning ishlab chiquvchilaringiz allaqachon foydalanayotgan narsadir. Chunki SRE to'g'ridan-to'g'ri ishlab chiqish guruhi bilan o'zaro ishlaydi. Va agar sizda turli xil vositalar bo'lsa, sinxronizatsiya qilish uchun vaqt kerak bo'ladi. Ayniqsa, agar SRElar katta jamoalarda, bir nechta jamoalar bo'lishi mumkin bo'lgan yirik kompaniyalarda ishlasa, bu erda kompaniya miqyosidagi standartlashtirish katta yordam beradi, chunki agar 50 ta jamoada 50 ta turli utilitlardan foydalanilsa, bu SRE ularni bilishi kerakligini anglatadi. hammasi. Va, albatta, bu hech qachon sodir bo'lmaydi. Va ish sifati, hech bo'lmaganda ba'zi jamoalarning nazorat sifati sezilarli darajada pasayadi.
Vebinarimiz o'z nihoyasiga yetmoqda. Men ba'zi asosiy narsalarni aytib berishga muvaffaq bo'ldim. Albatta, bir soat ichida SRE haqida hech narsa aytish va tushunish mumkin emas. Ammo umid qilamanki, men ushbu fikrlash tarzini, asosiy asosiy fikrlarni etkazishga muvaffaq bo'ldim. Va keyin, agar qiziqsangiz, mavzuni o'rganish, mustaqil ravishda o'rganish, uni boshqa odamlar, boshqa kompaniyalar tomonidan qanday amalga oshirilayotganiga qarash mumkin bo'ladi. Va shunga ko'ra, fevral oyining boshlarida bizga Slurm SRE-ga keling.
Slurm SRE - bu uch kunlik intensiv kurs bo'lib, u men hozir nima haqida gapirayotganim haqida gapiradi, lekin yanada chuqurroq, real holatlar bilan, amaliyot bilan, butun intensivlik amaliy ishlarga qaratilgan. Odamlar jamoalarga bo'linadi. Barchangiz haqiqiy holatlar ustida ishlaysiz. Shunga ko'ra, bizda Booking.com instruktorlari Ivan Kruglov va Ben Tayler bor. Bizda Google-dan, San-Frantsiskodan ajoyib Yevgeniy Barabbas bor. Va men ham sizga bir narsa aytaman. Shunday ekan, albatta bizga tashrif buyuring.
Shunday qilib, bibliografiya. SRE bo'yicha havolalar mavjud. xuddi shu kitobda, aniqrog'i Google tomonidan yozilgan SRE haqidagi 2 ta kitobda. Boshqasi , bu erda shartlar va ularning qo'llanilishi biroz batafsilroq. Keyingi 3 ta turli kompaniyalarda SRE bo'yicha hisobotlar. Birinchi - , bu Google kompaniyasining Ben Trenerining asosiy ma'ruzasi. Ikkinchi - . Uchinchisi yana . dan to'rtinchi hisobot , 5 mamlakatda faqat 190 ta asosiy SRE xodimlariga ega. Bularning barchasini ko'rib chiqish juda qiziq, chunki DevOps turli kompaniyalar va hatto turli jamoalar uchun juda boshqacha narsalarni anglatgani kabi, SRE ham bir xil o'lchamdagi kompaniyalarda juda boshqacha mas'uliyatga ega.
Xaos muhandisligi tamoyillari bo'yicha yana 2 ta havola: , . Va oxirida Ajoyib ro'yxatlar seriyasidan 3 ta ro'yxat mavjud , haqida va haqida . SRE ro'yxati juda katta, bularning barchasini ko'rib chiqish shart emas, 200 ga yaqin maqolalar mavjud. Men u erdan imkoniyatlarni rejalashtirish va o'limdan keyingi begunohlik haqida maqolalarni tavsiya qilaman.
Qiziqarli maqola:
Shu vaqtgacha meni tinglaganingiz uchun rahmat. Umid qilamanki, siz biror narsani o'rgandingiz. Umid qilamanki, sizda ko'proq o'rganish uchun etarli material bor. Va ko'rishguncha. Umid qilamanki, fevralda.
Vebinarni Eduard Medvedev olib bordi.
PS: o'qishni yaxshi ko'radiganlar uchun Eduard havolalar ro'yxatini berdi. Amalda tushunishni afzal ko'rganlar xush kelibsiz .
Manba: www.habr.com