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

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

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

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

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

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

Мониторингът трудно ли е?

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

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

(бих искал таблата ми да са оцветени в неоново синьо — мечтателно въздъхвайки —… хм…)

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

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

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

Автор на снимката Tim Gouw на Unsplash

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

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

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

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

Тази devops работа

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

1. казва нещо, което вероятно не прави (посочен е мем от филма «Принцесата невеста» — «Не мисля, че това означава това, което ти мислиш, че означава!»)
2. поощрява позицията за непрекъснато усъвършенстване на продукта.

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

Сдвиг наляво, НАЛЯВО, КАЗАХ, НАЛЕЕЕЕЕЕ—

За мен един от ключовите принципи на Devops е «Сдвиг наляво» (shift left). Сдвигът наляво в този контекст означава изместване на възможността (не отговорността, а само само управление системами) дава възможност да се правят неща, за които обикновено се грижат системните инженери, например, да се създават метрики за производителност, да се използват логове по-ефективно и т.н., в контекста на жизнения цикъл на доставката на софтуер (Software Delivery Life Cycle).

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

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

Накратко,

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

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

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

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