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

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

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

Това е толкова лесно, че не е интересно. Сега имате основните метрики за процесорно време, дискова подсистема, оперативна памет, получаващи се по подразбиране в 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“, трябва да:

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

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

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

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

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

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

С други думи

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

Автор на снимката Marko Horvat на Unsplash

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

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