Nega muhandislar ilovalar monitoringi haqida qayg'urmaydilar?

Hammaga juma muborak! Do'stlar, bugun biz kursga bag'ishlangan nashrlar seriyasini davom ettiramiz "DevOps amaliyotlari va vositalari", chunki kurs uchun yangi guruhda darslar keyingi hafta oxirida boshlanadi. Shunday ekan, boshlaylik!

Nega muhandislar ilovalar monitoringi haqida qayg'urmaydilar?

Monitoring - bu faqatgina. Bu ma'lum fakt. Nagios-ni olib keling, masofaviy tizimda NRPE-ni ishga tushiring, NRPE TCP port 5666-da Nagios-ni sozlang va sizda monitoring bor.

Bu juda oson, bu qiziq emas. Endi sizda protsessor vaqti, disk quyi tizimi, operativ xotira uchun asosiy ko'rsatkichlar mavjud bo'lib, ular sukut bo'yicha Nagios va NRPE-ga taqdim etiladi. Ammo bu aslida "monitoring" emas. Bu hali boshlanishi.

(Odatda ular PNP4Nagios, RRDtool va Thruk-ni o'rnatadilar, Slack-da bildirishnomalarni o'rnatadilar va to'g'ridan-to'g'ri nagioseexchange-ga o'tadilar, ammo buni hozircha qoldiraylik).

Yaxshi monitoring aslida juda murakkab, siz kuzatayotgan ilovaning ichki qismlarini bilishingiz kerak.

Kuzatuv qiyinmi?

Har qanday server, xoh u Linux yoki Windows bo'lsin, ta'rifiga ko'ra qandaydir maqsadga xizmat qiladi. Apache, Samba, Tomcat, fayllarni saqlash, LDAP - bu xizmatlarning barchasi bir yoki bir nechta jihatlarda ko'proq yoki kamroq noyobdir. Har birining o'z funktsiyasi, o'ziga xos xususiyatlari bor. Server yuklanganda siz uchun qiziqarli bo'lgan ko'rsatkichlar, KPI (asosiy samaradorlik ko'rsatkichlari) olishning turli usullari mavjud.

Nega muhandislar ilovalar monitoringi haqida qayg'urmaydilar?
Surat muallifi Lyuk Khesser haqida Unsplash

(Koshki mening asboblar panelim neon ko'k bo'lsa - orzu bilan xo'rsinib - ... hmm ...)

Xizmatlarni taqdim etadigan har qanday dasturiy ta'minot ko'rsatkichlarni yig'ish mexanizmiga ega bo'lishi kerak. Apache moduliga ega mod-status, server holati sahifasini ko'rsatish. Nginx bor - stub_status. Tomcat asosiy o'lchovlarni ko'rsatadigan JMX yoki maxsus veb-ilovalarga ega. MySQL-da "global holatni ko'rsatish" buyrug'i va boshqalar mavjud.
Xo'sh, nega ishlab chiquvchilar o'zlari yaratgan ilovalarga o'xshash mexanizmlarni yaratmaydilar?

Buni faqat ishlab chiquvchilar qiladimi?

Ko'rsatkichlarni joylashtirishga ma'lum darajada befarqlik faqat ishlab chiquvchilar bilan chegaralanmaydi. Men Tomcat-dan foydalangan holda ilovalarni ishlab chiqqan kompaniyalarda ishladim va umumiy Tomcat xato jurnallaridan tashqari, o'z ko'rsatkichlarini, xizmat faoliyati jurnallarini taqdim etmadi. Ba'zi ishlab chiquvchilar ertalab soat 3:15 da ularni o'qish uchun omadsiz bo'lgan tizim ma'muri uchun hech qanday ahamiyatga ega bo'lmagan juda ko'p jurnallarni yaratadilar.

Nega muhandislar ilovalar monitoringi haqida qayg'urmaydilar?
Surat muallifi Tim Gouv haqida Unsplash

Bunday mahsulotlarni chiqarishga imkon beradigan tizim muhandislari ham vaziyat uchun ma'lum bir javobgarlikni o'z zimmalariga olishlari kerak. Bir nechta tizim muhandislari ushbu ko'rsatkichlar kontekstisiz va ularni amaliy faoliyat nuqtai nazaridan izohlash qobiliyatisiz jurnallardan mazmunli ko'rsatkichlarni olishga harakat qilish uchun vaqt yoki g'amxo'rlik qiladi. Ba'zilar "hozirda nimadir noto'g'ri (yoki tez orada) noto'g'ri" ko'rsatkichlaridan tashqari, undan qanday foyda olishlarini tushunishmaydi.

Ko'rsatkichlarga bo'lgan ehtiyoj haqidagi fikrlashning o'zgarishi nafaqat ishlab chiquvchilar, balki tizim muhandislari orasida ham bo'lishi kerak.

Nafaqat muhim voqealarga javob berishi, balki ular sodir bo'lmasligini ta'minlashi kerak bo'lgan har qanday tizim muhandisi uchun ko'rsatkichlarning etishmasligi odatda buni amalga oshirishga to'sqinlik qiladi.

Biroq, tizim muhandislari odatda o'z kompaniyalari uchun pul ishlash uchun kod bilan shug'ullanmaydilar. Ular muammolarni aniqlash, ishlash muammolari haqida xabardorlikni oshirish va hokazolarda tizim muhandisi mas'uliyatining muhimligini tushunadigan etakchi ishlab chiquvchilarga muhtoj.

Bu o'ziga tortadigan narsa

Devops mentaliteti rivojlanish (dev) va operatsiyalar (ops) fikrlash o'rtasidagi sinergiyani tasvirlaydi. "Davops qilish" deb da'vo qiladigan har qanday kompaniya:

  1. ehtimol ular bo'lmagan narsalarni aytish ("Malika kelini" memini nazarda tutgan holda - "Menimcha, bu siz o'ylagan narsani anglatmaydi!")
  2. Mahsulotni doimiy takomillashtirish munosabatini rag'batlantirish.

Agar siz uning hozir qanday ishlashini bilmasangiz, mahsulotni yaxshilay olmaysiz va u yaxshilanganligini bilasiz. Agar siz uning tarkibiy qismlari qanday ishlashini, u bog'liq bo'lgan xizmatlarni, asosiy og'riqli nuqtalari va muammolarini tushunmasangiz, mahsulot qanday ishlashini bila olmaysiz.
Agar siz yuzaga kelishi mumkin bo'lgan qiyinchiliklarga e'tibor bermasangiz, Postmortem yozishda "Beshta nega" texnikasiga amal qila olmaysiz. Mahsulot qanday ishlashini koβ€˜rish yoki uning β€œoddiy va baxtli” koβ€˜rinishini bilish uchun hamma narsani bitta ekranga joylashtira olmaysiz.

Chapga, chapga siljiting, men LEEEE dedim -

Men uchun Devopsning asosiy tamoyillaridan biri bu "chapga siljish". Ushbu kontekstda chapga siljish imkoniyatni o'zgartirishni anglatadi (mas'uliyat yo'q, lekin faqat imkoniyatlar) tizim muhandislari odatda ahamiyat beradigan ishlarni bajarish uchun, masalan, unumdorlik koΚ»rsatkichlarini yaratish, jurnallardan samaraliroq foydalanish va h.k., Dasturiy taΚΌminotni yetkazib berish muddati davomida chapga.

Nega muhandislar ilovalar monitoringi haqida qayg'urmaydilar?
Surat muallifi Makers tomonidan NESA haqida Unsplash

Dasturiy ta'minotni ishlab chiquvchilar kompaniyaning barcha shakllari, ko'rsatkichlari, jurnallari, monitoring interfeyslari va eng muhimi, monitoringni amalga oshirish uchun foydalanadigan monitoring vositalaridan foydalanishi va bilishi kerak. ularning mahsuloti ishlab chiqarishda qanday ishlashini tomosha qiling. Ishlab chiquvchilar o'lchovlarni ko'rmaguncha va ularning tashqi ko'rinishiga, mahsulot egasi ularni keyingi brifingda CTOga qanday taqdim etishiga va hokazolarga ta'sir qilmaguncha monitoringga kuch va vaqt sarflashga majbur qila olmaysiz.

Qisqasi

  1. Otingizni suvga olib boring. Ishlab chiquvchilarga o'zlari uchun qancha muammolardan qochishlari mumkinligini ko'rsating, ularga o'z ilovalari uchun to'g'ri KPI va o'lchovlarni aniqlashga yordam bering, shunda CTO tomonidan baqirgan mahsulot egasining qichqirig'i kamroq bo'ladi. Ularni muloyimlik bilan va xotirjamlik bilan nurga olib boring. Agar bu ishlamasa, ularni yoki mahsulot egasini imkon qadar tezroq ilovalardan ushbu ko'rsatkichlarni olishni amalga oshirish uchun pora bering, tahdid qiling va aldab, keyin diagrammalarni chizing. Bu qiyin bo'ladi, chunki u ustuvor vazifa sifatida ko'rilmaydi va mahsulot yo'l xaritasida ko'plab daromad keltiruvchi loyihalar kutilmoqda. Shuning uchun, mahsulotga monitoringni amalga oshirish uchun sarflangan vaqt va xarajatlarni oqlash uchun sizga biznes ishi kerak bo'ladi.
  2. Tizim muhandislariga tungi uyquga yordam bering. Chiqarilayotgan har qanday mahsulot uchun "ketaylik" nazorat ro'yxatidan foydalanish yaxshi narsa ekanligini ko'rsating. Va ishlab chiqarishdagi barcha ilovalar ko'rsatkichlar bilan qoplanganligiga ishonch hosil qilish, ishlab chiquvchilarga nima va qayerda noto'g'ri ketayotganini ko'rish imkonini berib, tunda yaxshiroq uxlashingizga yordam beradi. Biroq, har qanday ishlab chiquvchini, mahsulot egasini yoki texnik direktorni g'azablantirish va xafa qilishning to'g'ri yo'li - bu davom etish va qarshilik ko'rsatishdir. Agar oxirgi daqiqagacha yana kutsangiz, bu xatti-harakat har qanday mahsulotning chiqarilish sanasiga ta'sir qiladi, shuning uchun yana chapga siljiting va bu muammolarni imkon qadar tezroq loyiha rejangizga kiriting. Agar kerak bo'lsa, mahsulot yig'ilishlariga yo'l oling. Soxta mo'ylov va kigiz yoki boshqa narsalarni kiying, u hech qachon muvaffaqiyatsiz bo'lmaydi. Xavotirlaringizni bildiring, aniq foydalarni ko'rsating va xushxabarni tarqating.
  3. Har ikkala ishlab chiqish (ishlab chiqish) va operatsiyalar (operatsiyalar) qizil zonaga o'tish mahsulot ko'rsatkichlarining ma'nosi va oqibatlarini tushunishiga ishonch hosil qiling. Ops-ni mahsulot salomatligining yagona qo'riqchisi sifatida qoldirmang, ishlab chiquvchilar ham ishtirok etishiga ishonch hosil qiling (#productsquads).
  4. Jurnallar ajoyib narsa, lekin ko'rsatkichlar ham. Ularni birlashtiring va jurnallaringiz katta alangali foydasiz to'p ichida axlatga aylanishiga yo'l qo'ymang. Ishlab chiquvchilarga nima uchun ularning jurnallarini boshqa hech kim tushunmasligini tushuntiring va ko'rsating, ularga ertalab soat 3:15 da keraksiz jurnallarga qarash qanday ekanligini ko'rsating.

Nega muhandislar ilovalar monitoringi haqida qayg'urmaydilar?
Surat muallifi Marko Horvat haqida Unsplash

Ana xolos. Yangi material keyingi hafta chiqariladi. Agar siz kurs haqida ko'proq ma'lumot olishni istasangiz, sizni taklif qilamiz ochiq kun, dushanba kuni bo'lib o'tadi. Va endi biz an'anaviy tarzda sharhlaringizni kutamiz.

Manba: www.habr.com

a Izoh qo'shish