Почему инженеры не заботятся о мониторинге приложений?

Всех с пятницей! Друзья, сегодня мы продолжаем серию публикаций посвященных курсу «DevOps практики и инструменты», потому как занятия в новой группе по курсу стартуют уже в конце следующей недели. Итак, начнём!

Мониторинг — это просто. Это известный факт. Поднимите Nagios, запустите NRPE на удалённой системе, настройте Nagios на порт NRPE TCP 5666 и у вас есть мониторинг.

Это так легко, что неинтересно. Теперь у вас есть основные метрики по процессорному времени, дисковой подсистеме, оперативной памяти, поступающие по умолчанию в Nagios и NRPE. Но на самом деле это не «мониторинг» как таковой. Это только начало.

(Обычно ставят PNP4Nagios, RRDtool и Thruk, настраивают уведомления в Slack и идут прямо на nagiosexchange, но пока что опустим это).

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

Мониторинг — это сложно?

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

Автор фото Luke Chesser на 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 by Makers на Unsplash

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

Короче говоря

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

Автор фото Marko Horvat на Unsplash

На этом все. Новый материал выйдет на следующей неделе. Если вы желаете подробнее узнать о курсе, приглашаем на день открытых дверей, который пройдет уже в понедельник. А сейчас мы традиционно ждем ваши комментарии.

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