Salom, Xabr! Men o'n yildan beri Highload IT tizimlarini qo'llab-quvvatlayman. Men ushbu maqolada nginx-ni 1000+ RPS rejimida yoki boshqa texnik narsalarda ishlash uchun sozlash muammolari haqida yozmayman. Men bunday tizimlarni qo'llab-quvvatlash va ishlatishda yuzaga keladigan jarayonlardagi muammolar haqida o'z kuzatishlarimni baham ko'raman.
Monitoring
Texnik qo‘llab-quvvatlash xizmati “Nima uchun... sayt yana ishlamayapti?” mazmuni bilan so‘rov kelguncha kutmaydi. Sayt ishdan chiqqanidan keyin bir daqiqa ichida qo'llab-quvvatlash muammoni ko'rishi va uni hal qilishni boshlashi kerak. Ammo sayt aysbergning uchi. Uning mavjudligi kuzatilishi kerak bo'lgan birinchilardan biridir.
Onlayn do'konning qolgan tovarlari ERP tizimidan kelmasa, nima qilish kerak? Yoki mijozlar uchun chegirmalarni hisoblaydigan CRM tizimi javob berishni to'xtatdimi? Sayt ishlayotganga o'xshaydi. Shartli Zabbix o'zining 200 javobini oladi. Navbatchi smena monitoringdan hech qanday bildirishnoma olmagan va “Taxtlar oʻyini”ning yangi mavsumining birinchi epizodini xursandchilik bilan tomosha qilmoqda.
Monitoring ko'pincha faqat xotira holatini, RAM va server protsessor yukini o'lchash bilan chegaralanadi. Ammo biznes uchun veb-saytda mahsulot mavjudligini olish muhimroqdir. Klasterdagi bitta virtual mashinaning shartli ravishda ishlamay qolishi trafikning unga borishni to'xtatishiga va boshqa serverlarga yuklanishning oshishiga olib keladi. Kompaniya pul yo'qotmaydi.
Shuning uchun, serverlardagi operatsion tizimlarning texnik parametrlarini kuzatishdan tashqari, siz biznes ko'rsatkichlarini sozlashingiz kerak. To'g'ridan-to'g'ri pulga ta'sir qiluvchi ko'rsatkichlar. Tashqi tizimlar bilan turli xil o'zaro ta'sirlar (CRM, ERP va boshqalar). Muayyan vaqt uchun buyurtmalar soni. Muvaffaqiyatli yoki muvaffaqiyatsiz mijoz avtorizatsiyalari va boshqa ko'rsatkichlar.
Tashqi tizimlar bilan o'zaro ta'sir
Yillik aylanmasi milliard rubldan ortiq bo'lgan har qanday veb-sayt yoki mobil ilova tashqi tizimlar bilan o'zaro ta'sir qiladi. Yuqorida aytib o'tilgan CRM va ERP dan boshlab, xaridlarni tahlil qilish va mijozga u albatta sotib oladigan (aslida emas) mahsulotni taklif qilish uchun savdo ma'lumotlarini tashqi Big Data tizimiga o'tkazish bilan yakunlanadi. Har bir bunday tizim o'z yordamiga ega. Va ko'pincha bu tizimlar bilan muloqot og'riqni keltirib chiqaradi. Ayniqsa, muammo global bo'lsa va uni turli tizimlarda tahlil qilishingiz kerak bo'lsa.
Ba'zi tizimlar ma'murlari uchun telefon raqami yoki telegramma beradi. Biror joyda siz menejerlarga xat yozishingiz yoki ushbu tashqi tizimlarning xato izdoshlariga o'tishingiz kerak. Hatto bitta yirik kompaniya kontekstida ham turli xil tizimlar ko'pincha turli xil amaliy hisob tizimlarida ishlaydi. Ba'zan ilovaning holatini kuzatish imkonsiz bo'lib qoladi. Siz bitta shartli Jirada so'rov olasiz. Keyin bu birinchi Jiraning izohida siz boshqa Jiradagi masalaga havola qo'ydingiz. Ilovadagi ikkinchi Jirada kimdir allaqachon sharh yozmoqda muammoni hal qilish uchun shartli administrator Andreyga qo'ng'iroq qilishingiz kerak. Va shunga o'xshash.
Ushbu muammoning eng yaxshi yechimi, masalan, Slack-da aloqa uchun yagona maydon yaratish bo'ladi. Tashqi tizimlarni ishlatish jarayonining barcha ishtirokchilarini qo'shilishga taklif qilish. Shuningdek, ilovalarni takrorlamaslik uchun bitta treker. Ilovalar bir joyda kuzatilishi kerak, monitoring bildirishnomalaridan tortib kelajakda xatoliklarni hal qilishgacha. Siz aytasizki, bu haqiqatga to'g'ri kelmaydi va tarixan shunday bo'lganki, biz bitta trekerda ishlaymiz va ular boshqasida ishlaydi. Turli xil tizimlar paydo bo'ldi, ularning o'zlarining avtonom IT guruhlari bor edi. Men roziman va shuning uchun muammo yuqoridan CIO yoki mahsulot egasi darajasida hal qilinishi kerak.
Siz o'zaro aloqada bo'lgan har bir tizim muammolarni ustuvorlik bo'yicha hal qilish uchun aniq SLA bilan xizmat sifatida yordam berishi kerak. Va shartli admin Andrey siz uchun bir daqiqa bo'lganda emas.
To'siqli odam
Loyihada (yoki mahsulotda) har bir kishining ta'tilga chiqishi o'z rahbarlari orasida siqilishga olib keladigan odam bormi? Bu devops muhandisi, tahlilchisi yoki ishlab chiquvchisi bo'lishi mumkin. Axir, faqat devops muhandisi qaysi serverlarda qaysi konteynerlar o'rnatilganligini, muammo yuzaga kelganda konteynerni qanday qayta ishga tushirishni biladi va umuman, har qanday murakkab muammoni usiz hal qilib bo'lmaydi. Sizning murakkab mexanizmingiz qanday ishlashini faqat tahlilchi biladi. Qaysi ma'lumotlar oqimi qaerga ketadi. Qaysi xizmatlarga so'rovlarning qaysi parametrlari bo'yicha, qaysilariga javob olamiz.
Jurnallarda nima uchun xatolar borligini kim tezda tushunadi va mahsulotdagi muhim xatoni tezda tuzatadi? Albatta, bir xil ishlab chiquvchi. Boshqalar ham bor, lekin negadir faqat u tizimning turli modullari qanday ishlashini tushunadi.
Ushbu muammoning ildizi hujjatlarning etishmasligi. Axir, agar tizimingizning barcha xizmatlari tavsiflangan bo'lsa, unda muammoni tahlilchisiz hal qilish mumkin edi. Agar devops bir necha kun band bo'lgan jadvalidan chiqib, barcha serverlar, xizmatlar va odatiy muammolarni hal qilish bo'yicha ko'rsatmalarni tasvirlab bergan bo'lsa, u holda u yo'qligida muammoni hal qilish mumkin edi. Dam olish vaqtida plyajda pivoni tezda tugatish va muammoni hal qilish uchun wi-fi izlash kerak emas.
Yordamchi xodimlarning malakasi va mas'uliyati
Yirik loyihalarda kompaniyalar ishlab chiquvchilarning ish haqini kamaytirmaydilar. Ular shunga o'xshash loyihalardan qimmat o'rta yoki qariyalarni qidirmoqdalar. Qo'llab-quvvatlash bilan vaziyat biroz boshqacha. Ular bu xarajatlarni har tomonlama kamaytirishga harakat qilmoqdalar. Kompaniyalar kechagi arzon Enikey ishchilarini yollashadi va jasorat bilan jangga kirishadilar. Agar biz Zelenograddagi zavodning tashrif qog'ozi veb-sayti haqida gapiradigan bo'lsak, bu strategiya mumkin.
Agar biz yirik onlayn-do'kon haqida gapiradigan bo'lsak, unda ishlamay qolishning har bir soati Enikey ma'murining oylik maoshidan qimmatroqdir. Keling, boshlanish nuqtasi sifatida yillik aylanmaning 1 milliard rublini olaylik. Bu reytingdan har qanday onlayn-do'konning minimal aylanmasi . Ushbu miqdorni yiliga soatlar soniga bo'linib, 100 000 rubldan ortiq sof yo'qotishlarni oling. Va agar siz tungi soatlarni hisoblamasangiz, bu miqdorni xavfsiz tarzda ikki barobarga oshirishingiz mumkin.
Lekin asosiy narsa pul emas, to'g'rimi? (yo'q, albatta, asosiysi) Obro'ni yo'qotish ham bor. Taniqli onlayn-do'konning qulashi ham ijtimoiy tarmoqlarda, ham tematik ommaviy axborot vositalarida nashrlarda sharhlar to'lqiniga olib kelishi mumkin. Va oshxonadagi do'stlarning "U erda hech narsa sotib olmang, ularning veb-sayti doimo ishlamayapti" tarzidagi suhbatlarini umuman o'lchash mumkin emas.
Endi mas'uliyat. Mening amaliyotimda navbatchi administrator saytning mavjud emasligi haqidagi monitoring tizimi xabariga o'z vaqtida javob bermagan holat bo'lgan. Yozning yoqimli juma oqshomida Moskvadagi taniqli onlayn-do'konning veb-sayti jimgina yotardi. Shanba kuni ertalab ushbu saytning mahsulot menejeri nima uchun sayt ochilmaganini tushunmadi va Slack-dagi qo'llab-quvvatlash va shoshilinch xabarnoma chatlarida jimlik hukm surdi. Bunday xato bizga olti raqamga qimmatga tushdi va bu navbatchi o'z ishi.
Mas'uliyat - rivojlantirish qiyin mahorat. Yoki odamda bor yoki yo'q. Shuning uchun, suhbatlar davomida men uning mavjudligini turli savollar bilan aniqlashga harakat qilaman, bu odam mas'uliyatni o'z zimmasiga olishga odatlanganligini bilvosita ko'rsatadi. Agar biror kishi ota-onasi aytgani uchun universitetni tanladim yoki xotinim maoshim yo'q, deb ish joyini o'zgartirdi, deb javob bersa, unda bunday odamlarga aralashmagan ma'qul.
Rivojlanish guruhi bilan o'zaro aloqa
Foydalanuvchilar ish paytida mahsulot bilan bog'liq oddiy muammolarga duch kelganda, qo'llab-quvvatlash ularni o'z-o'zidan hal qiladi. Muammoni qayta ishlab chiqarishga harakat qiladi, jurnallarni tahlil qiladi va hokazo. Ammo mahsulotda xatolik paydo bo'lganda nima qilish kerak? Bunday holda, qo'llab-quvvatlash ishlab chiquvchilarga vazifa beradi va bu erda qiziqarli boshlanadi.
Ishlab chiquvchilar doimo haddan tashqari yuklanadi. Ular yangi xususiyatlarni yaratadilar. Savdodagi xatolarni tuzatish eng qiziqarli faoliyat emas. Keyingi sprintni yakunlash uchun muddatlar yaqinlashmoqda. Va keyin qo'llab-quvvatlashdan yoqimsiz odamlar kelib: "Hamma narsani darhol tark eting, bizda muammolar bor", deyishadi. Bunday vazifalarning ustuvorligi minimaldir. Ayniqsa, muammo eng muhim bo'lmasa va saytning asosiy funksionalligi ishlayotgan bo'lsa va reliz menejeri ko'zlari bo'rtib yurmasa va yozing: "Bu vazifani zudlik bilan keyingi nashrga yoki tuzatishga qo'shing."
Oddiy yoki past ustuvor bo'lgan muammolar nashrdan nashrga ko'chiriladi. “Vazif qachon bajariladi?” degan savolga. Siz quyidagi uslubdagi javoblarni olasiz: "Kechirasiz, hozir juda ko'p vazifalar bor, jamoangiz rahbarlaridan yoki bo'shatish menejeridan so'rang."
Hosildorlik muammolari yangi xususiyatlarni yaratishdan ko'ra ustuvor ahamiyatga ega. Agar foydalanuvchilar doimo xatolarga duch kelsa, yomon sharhlar uzoq kutilmaydi. Buzilgan obro'ni tiklash qiyin.
Rivojlanish va qo'llab-quvvatlash o'rtasidagi o'zaro ta'sir masalalari DevOps tomonidan hal qilinadi. Ushbu qisqartma ko'pincha ishlab chiqish uchun sinov muhitini yaratishga yordam beradigan, CICD quvurlarini quradigan va sinovdan o'tgan kodni tezda ishlab chiqarishga olib keladigan aniq shaxs shaklida qo'llaniladi. DevOps - bu jarayonning barcha ishtirokchilari bir-biri bilan chambarchas aloqada bo'lgan va dasturiy mahsulotlar va xizmatlarni tezda yaratish va yangilashga yordam beradigan dasturiy ta'minotni ishlab chiqishga yondashuv. Men tahlilchilar, ishlab chiquvchilar, testerlar va qo'llab-quvvatlashni nazarda tutyapman.
Ushbu yondashuvda qo'llab-quvvatlash va rivojlanish o'z maqsadlari va vazifalariga ega bo'lgan turli bo'limlar emas. Rivojlanish operatsiyada ishtirok etadi va aksincha. Tarqalgan jamoalarning mashhur iborasi: "Muammo men tomonda emas" endi chatlarda tez-tez ko'rinmaydi va oxirgi foydalanuvchilar biroz xursand bo'lishadi.
Manba: www.habr.com