Hər kəsin cümə günü mübarək! Dostlar, bu gün biz kursa həsr olunmuş nəşrlər silsiləsini davam etdiririk , çünki kurs üçün yeni qrupda dərslər gələn həftənin sonunda başlayacaq. Beləliklə, başlayaq!
Monitorinqdir yalnız. Bu məlum faktdır. Nagios-u yetişdirin, uzaq sistemdə NRPE-ni işə salın, NRPE TCP port 5666-da Nagios-u konfiqurasiya edin və monitorinqiniz var.
O qədər asandır ki, maraqlı deyil. İndi Nagios və NRPE-yə defolt olaraq təchiz edilmiş CPU vaxtı, disk alt sistemi, RAM üçün əsas ölçüləriniz var. Ancaq bu əslində "nəzarət" deyil. Bu hələ başlanğıcdır.
(Adətən PNP4Nagios, RRDtool və Thruk quraşdırırlar, Slack-də bildirişlər qururlar və birbaşa nagioseexchange-ə gedirlər, lakin gəlin bunu hələlik tərk edək).
Yaxşı monitorinq əslində olduqca mürəkkəbdir, siz həqiqətən izlədiyiniz tətbiqin daxili hissələrini bilməlisiniz.
Monitorinq çətindir?
İstənilən server, istər Linux, istərsə də Windows, müəyyən bir məqsədə xidmət edəcəkdir. Apache, Samba, Tomcat, fayl saxlama, LDAP - bütün bu xidmətlər bir və ya bir neçə cəhətdən az və ya çox unikaldır. Hər birinin öz funksiyası, öz xüsusiyyətləri var. Server yükləndikdə sizin üçün maraqlı olan ölçüləri, KPI-ləri (əsas performans göstəriciləri) əldə etməyin müxtəlif yolları var.
Photo by haqqında
(Kaş ki, idarə panellərim neon mavi olsaydı - xəyalpərəst ah-... hmm...)
Xidmətlər təqdim edən hər hansı proqramın ölçüləri toplamaq mexanizmi olmalıdır. Apache moduluna malikdir mod-status, server statusu səhifəsini göstərir. Nginx var - stub_status. Tomcat-da əsas ölçüləri göstərən JMX və ya xüsusi veb proqramları var. MySQL-də "qlobal statusu göstər" və s. əmri var.
Bəs niyə tərtibatçılar yaratdıqları tətbiqlərdə oxşar mexanizmlər qurmurlar?
Bunu yalnız tərtibatçılar edir?
Metriklərin yerləşdirilməsinə müəyyən laqeydlik yalnız tərtibatçılarla məhdudlaşmır. Mən Tomcat-dan istifadə edərək proqramlar hazırladıqları şirkətlərdə işləmişəm və ümumi Tomcat xəta qeydləri istisna olmaqla, heç bir öz ölçülərini, xidmət fəaliyyəti qeydlərini təqdim etməmişdilər. Bəzi tərtibatçılar səhər saat 3:15-də onları oxumaq şansı olmayan sistem administratoru üçün heç bir əhəmiyyət kəsb etməyən çoxlu qeydlər yaradırlar.
Photo by haqqında
Bu cür məhsulların buraxılmasını təmin edən sistem mühəndisləri də vəziyyətə görə müəyyən məsuliyyət daşımalıdırlar. Bir neçə sistem mühəndisinin həmin ölçülərin kontekstindən və tətbiq fəaliyyətinin işığında onları şərh etmək bacarığı olmadan, loglardan mənalı ölçüləri çıxarmağa çalışmaq üçün vaxt və ya qayğı var. Bəziləri "hal-hazırda bir şey səhvdir (yaxud tezliklə olacaq)" göstəricilərindən başqa, bundan necə faydalana biləcəklərini anlamırlar.
Metriklərə ehtiyacla bağlı düşüncə dəyişikliyi təkcə tərtibatçılar arasında deyil, həm də sistem mühəndisləri arasında baş verməlidir.
Yalnız kritik hadisələrə cavab verməli, həm də onların baş verməməsini təmin etməli olan hər hansı bir sistem mühəndisi üçün ölçülərin olmaması adətən buna mane olur.
Bununla belə, sistem mühəndisləri adətən şirkətləri üçün pul qazanmaq üçün kodla məşğul olmurlar. Onlara problemlərin müəyyən edilməsində, performans problemləri haqqında məlumatlılığın artırılmasında və s. işlərdə sistem mühəndisinin məsuliyyətinin vacibliyini dərk edən aparıcı tərtibatçılara ehtiyacı var.
Bu, bir şeyi devşirir
Devops mentaliteti inkişaf (dev) və əməliyyatlar (ops) düşüncəsi arasındakı sinerji təsvir edir. "Devops" etdiyini iddia edən hər hansı bir şirkət:
- yəqin ki, etmədikləri şeyləri söyləmək (The Princess Bride mem-a istinad edərək - "Məncə, bunun sizin düşündüyünüz kimi mənası yoxdur!")
- Məhsulun davamlı təkmilləşdirilməsi münasibətini təşviq edin.
Siz məhsulu təkmilləşdirə və onun hal-hazırda necə işlədiyini bilmirsinizsə, onun təkmilləşdirildiyini bilə bilməzsiniz. Əgər onun komponentlərinin necə işlədiyini, asılı olduğu xidmətləri, əsas ağrı nöqtələrini və darboğazlarını başa düşməsəniz, məhsulun necə işlədiyini bilə bilməzsiniz.
Potensial darboğazları izləməsəniz, Postmortem yazarkən Five Whys texnikasına əməl edə bilməyəcəksiniz. Məhsulun necə işlədiyini görmək və ya "normal və xoşbəxt" kimi göründüyünü bilmək üçün hər şeyi bir ekrana qoya bilməyəcəksiniz.
Sola sürüşdürün, SOL, LEEEE DEDİM
Mənim üçün Devops-un əsas prinsiplərindən biri “sola sürüşdürmək”dir. Bu kontekstdə sola sürüşdürmək imkanı dəyişdirmək deməkdir (məsuliyyət yoxdur, lakin yalnız imkanlar) sistem mühəndislərinin adətən əhəmiyyət verdiyi şeyləri etmək, məsələn, performans göstəriciləri yaratmaq, qeydlərdən daha səmərəli istifadə etmək və s., Proqram Təminatının Həyat Dövründə sola.
Photo by haqqında
Proqram tərtibatçıları şirkətin bütün formalarında, ölçülərində, qeydlərində, monitorinq interfeyslərində və ən əsası monitorinqi həyata keçirmək üçün istifadə etdiyi monitorinq alətlərindən istifadə etməli və bilməlidirlər. onların məhsulunun istehsalda necə işlədiyinə baxın. Tərtibatçıları ölçüləri görənə və onların necə göründüyünə, məhsul sahibinin növbəti brifinqdə onları CTO-ya necə təqdim etdiyinə və s.
Qisa sözlə
- Atınızı suya aparın. Tərtibatçılara özləri üçün nə qədər problemdən qaça biləcəklərini göstərin, onlara tətbiqləri üçün düzgün KPI və ölçüləri müəyyən etməyə kömək edin ki, CTO tərəfindən qışqırılan məhsul sahibinin qışqırması daha az olsun. Onları yumşaq və sakitcə işığa gətirin. Əgər bu işə yaramırsa, o zaman onlara və ya məhsul sahibinə rüşvət verin, hədələyin və aldadın ki, bu göstəriciləri tətbiqlərdən mümkün qədər tez əldə etsin və sonra diaqramları çəkin. Bu, prioritet kimi görünməyəcəyi üçün çətin olacaq və məhsulun yol xəritəsində bir çox gəlir gətirən layihələr gözləniləcək. Buna görə də, məhsulun monitorinqini həyata keçirmək üçün sərf olunan vaxt və xərcləri əsaslandırmaq üçün sizə biznes nümunəsi lazımdır.
- Sistem mühəndislərinə yaxşı gecə yuxusu almağa kömək edin. Onlara göstərin ki, buraxılan hər hansı məhsul üçün “buraxılsın” yoxlama siyahısından istifadə etmək yaxşı bir şeydir. İstehsalda olan bütün tətbiqlərin ölçülərlə örtüldüyünə əmin olmaq, tərtibatçılara nəyin səhv olduğunu və harada olduğunu görməyə imkan verməklə gecə daha yaxşı yatmağınıza kömək edəcək. Bununla belə, hər hansı bir tərtibatçını, məhsul sahibini və ya CTO-nu qıcıqlandırmaq və məyus etmək üçün düzgün yol israr etmək və müqavimət göstərməkdir. Yenə son dəqiqəyə qədər gözləsəniz, bu davranış hər hansı məhsulun buraxılış tarixinə təsir edəcək, ona görə də yenidən sola keçin və bu məsələləri mümkün qədər tez layihə planınıza daxil edin. Lazım gələrsə, məhsul görüşlərinə yolunuzu ayırın. Saxta bığ və keçə və ya başqa bir şey geyin, heç vaxt uğursuz olmayacaq. Narahatlıqlarınızı bildirin, aydın faydalar nümayiş etdirin və təbliğ edin.
- Həm inkişafın (inkişaf), həm də əməliyyatların (əməliyyatların) qırmızı zonaya keçən məhsul ölçülərinin mənasını və nəticəsini başa düşdüyünə əmin olun. Ops-u məhsulun sağlamlığının yeganə qoruyucusu kimi tərk etməyin, tərtibatçıların da iştirak etdiyinə əmin olun (#productsquads).
- Qeydlər əla bir şeydir, amma ölçülər də. Onları birləşdirin və jurnallarınızın nəhəng yanan bir faydasız topunda zibilliyə çevrilməsinə imkan verməyin. Tərtibatçılara niyə başqa heç kimin onların qeydlərini başa düşməyəcəyini izah edin və göstərin, səhər saat 3:15-də yararsız jurnallara baxmağın necə olduğunu göstərin.
Photo by haqqında
Hamısı budur. Yeni material gələn həftə yayımlanacaq. Kurs haqqında daha çox öyrənmək istəyirsinizsə, sizi dəvət edirik Bazar ertəsi günü baş tutacaq. İndi də ənənəvi olaraq şərhlərinizi gözləyirik.
Mənbə: www.habr.com