Защо инженерите не се интересуват от мониторинга на приложенията?

Честит петък на всички! Приятели, днес продължаваме поредицата от публикации, посветени на курса „Практики и инструменти на DevOps“, тъй като заниманията в новата група за курса започват в края на следващата седмица. И така, да започваме!

Мониторингът е само. Това е известен факт. Изведете Nagios, стартирайте NRPE на отдалечената система, конфигурирайте Nagios на NRPE TCP порт 5666 и имате наблюдение.

Толкова е лесно, че не е интересно. Сега имате основни показатели за процесорно време, дискова подсистема, RAM, предоставени по подразбиране на Nagios и NRPE. Но това всъщност не е „мониторинг“ като такъв. Това е само началото.

(Обикновено те инсталират PNP4Nagios, RRDtool и Thruk, настройват известията в Slack и отиват направо към nagiosexchange, но нека оставим това засега).

Добър мониторинг всъщност е доста сложно, наистина трябва да знаете вътрешността на приложението, което наблюдавате.

Трудно ли е наблюдението?

Всеки сървър, независимо дали е Linux или Windows, по дефиниция ще служи за някаква цел. Apache, Samba, Tomcat, съхранение на файлове, LDAP - всички тези услуги са повече или по-малко уникални в едно или повече отношения. Всеки има своя собствена функция, свои собствени характеристики. Има различни начини да получите показатели, KPI (ключови показатели за ефективност), които са интересни за вас, когато сървърът е под натоварване.

Автор на снимката Люк Чесер на Unsplash

(Иска ми се таблата ми да са неоново сини - въздиша замечтано -... хм...)

Всеки софтуер, който предоставя услуги, трябва да има механизъм за събиране на показатели. Apache има модул mod-status, показвайки страницата за състояние на сървъра. Nginx има - stub_status. Tomcat има JMX или персонализирани уеб приложения, които показват ключови показатели. MySQL има команда "покажи глобален статус" и т.н.
Така че защо разработчиците не вграждат подобни механизми в приложенията, които създават?

Само разработчиците ли правят това?

Определено ниво на безразличие към вграждането на метрики не е ограничено до разработчиците. Работих в компании, където разработваха приложения с помощта на Tomcat и не предоставяха собствени показатели, никакви регистрационни файлове за дейността на услугата, с изключение на общи регистрационни файлове за грешки на Tomcat. Някои разработчици генерират много регистрационни файлове, които не означават нищо за системния администратор, който няма късмета да ги прочете в 3:15 сутринта.

Автор на снимката Тим Гау на Unsplash

Системните инженери, които позволяват пускането на такива продукти, също трябва да носят известна отговорност за ситуацията. Малко системни инженери имат време или грижа да се опитат да извлекат значими показатели от регистрационните файлове, без контекста на тези показатели и способността да ги интерпретират в светлината на дейността на приложението. Някои не разбират как могат да се възползват от това, освен индикаторите „нещо в момента (или скоро ще бъде) нередно“.

Промяна в мисленето по отношение на необходимостта от показатели трябва да настъпи не само сред разработчиците, но и сред системните инженери.

За всеки системен инженер, който трябва не само да реагира на критични събития, но и да гарантира, че те няма да се появят, липсата на показатели обикновено е пречка за това.

Системните инженери обаче обикновено не се занимават с код, за да правят пари за своята компания. Те се нуждаят от водещи разработчици, които разбират важността на отговорността на системния инженер при идентифициране на проблеми, повишаване на осведомеността относно проблеми с производителността и други подобни.

Това devops нещо

Манталитетът на devops описва синергията между мисленето за развитие (dev) и операциите (ops). Всяка компания, която твърди, че „прави devops“, трябва:

1. казвайки неща, които вероятно не казват (визирайки мема The Princess Bride - „Не мисля, че означава това, което мислите, че означава!“)
2. Насърчавайте нагласа за непрекъснато подобряване на продукта.

Не можете да подобрите продукт и да знаете, че е подобрен, ако не знаете как работи в момента. Не можете да знаете как работи даден продукт, ако не разбирате как работят компонентите му, услугите, от които зависи, основните му болкови точки и пречки.
Ако не следите за потенциални тесни места, няма да можете да следвате техниката Пет защо, когато пишете Postmortem. Няма да можете да поставите всичко на един екран, за да видите как работи даден продукт или да знаете как изглежда „нормален и щастлив“.

Преместване наляво, НАЛЯВО, КАЗАХ ЛИИИ-

За мен един от ключовите принципи на Devops е „изместване наляво“. Преместване наляво в този контекст означава изместване на възможността (без отговорност, но само способности), за да правите неща, от които системните инженери обикновено се интересуват, като например създаване на показатели за производителност, по-ефективно използване на регистрационни файлове и т.н., вляво в жизнения цикъл на доставка на софтуер.

Автор на снимката NESA от Makers на Unsplash

Разработчиците на софтуер трябва да могат да използват и да познават инструментите за мониторинг, които компанията използва, за да извършва мониторинг във всичките му форми, показатели, регистриране, интерфейси за мониторинг и, най-важното, наблюдавайте как техният продукт работи в производството. Не можете да накарате разработчиците да инвестират усилия и време в мониторинг, докато не могат да видят показателите и да повлияят на това как изглеждат, как собственикът на продукта ги представя на CTO на следващия брифинг и т.н.

Накратко казано

1. Заведете коня си до водата. Покажете на разработчиците колко проблеми могат да избегнат за себе си, помогнете им да идентифицират правилните KPI и показатели за техните приложения, така че да има по-малко викове от страна на собственика на продукта, на когото крещи CTO. Изведете ги на светлина, нежно и спокойно. Ако това не проработи, тогава подкупете, заплашвайте и примамете или тях, или собственика на продукта, за да внедрите получаването на тези показатели от приложенията възможно най-бързо и след това начертайте диаграмите. Това ще бъде трудно, тъй като няма да се разглежда като приоритет, а продуктовата пътна карта ще включва много проекти за генериране на приходи. Следователно ще ви е необходим бизнес случай, за да оправдаете времето и разходите, изразходвани за внедряване на мониторинг в продукта.
2. Помогнете на системните инженери да се наспят добре. Покажете им, че използването на контролен списък „да пуснем“ за всеки пуснат продукт е добро нещо. Уверяването, че всички приложения в производството са покрити с показатели, ще ви помогне да спите по-добре през нощта, като позволи на разработчиците да видят какво се обърка и къде. Въпреки това, правилният начин да раздразните и разочаровате всеки разработчик, собственик на продукт или технически директор е да упорствате и да се съпротивлявате. Това поведение ще се отрази на датата на пускане на всеки продукт, ако изчакате отново до последната минута, така че преместете отново наляво и вкарайте тези проблеми в плана на проекта си възможно най-скоро. Ако е необходимо, отидете на продуктови срещи. Носете фалшиви мустаци и филц или нещо подобно, никога няма да се провали. Изложете притесненията си, покажете ясни ползи и проповядвайте.
3. Уверете се, че както разработката (dev), така и операциите (ops) разбират значението и последствията от преминаването на продуктовите показатели в червената зона. Не оставяйте Ops като единствен пазител на здравето на продукта, уверете се, че разработчиците също са включени (#productsquads).
4. Дневниците са страхотно нещо, но също и показателите. Комбинирайте ги и не позволявайте вашите трупи да се превърнат в боклук в огромна пламтяща топка от безполезност. Обяснете и покажете на разработчиците защо никой друг няма да разбере техните журнали, покажете им какво е да гледате безполезни журнали в 3:15 сутринта.

Автор на снимката Марко Хорват на Unsplash

Това е всичко. Нов материал ще бъде пуснат следващата седмица. Ако искате да научите повече за курса, ви каним Отворен ден, което ще се проведе в понеделник. А сега по традиция очакваме вашите коментари.

Източник: www.habr.com