Текстовый курс по DevOps
Как организовать мониторинг (телеметрию) для управления жизненным циклом ПО в DevOps?
По опыту работы в ИТ вы знаете, как трудно найти первопричину сбоя. Проблема может быть в приложениях, средах или других компонентах, с которыми они связаны.
В истории относительно сложных клиентских и серверных платформ за последние 50 лет часто повторялся такой сценарий: когда сервер плохо работает, выдаёт ошибки и не выполняет свою задачу, его просто перезапускают в надежде, что это поможет. Перезапуск действительно иногда временно устраняет проблему, в которой так и не разобрались. Если это не помогает, идут к разработчикам и тестировщикам, которые якобы плохо поставили ПО и не обнаружили проблему при проверке. Такой хаос снижает удовлетворённость клиентов услугами и портит рабочую атмосферу в организации.
Ведущие организации DevOps редко перезапускают серверы при устранении проблем. Они системно выявляют и устраняют сбои. Чтобы понять первопричины и сопутствующие факторы, они опираются на телеметрию рабочих систем. Их среднее время восстановления (MTTR) в 96 раз лучше, чем у других организаций. Иными словами, они устраняют проблемы в рабочих системах в 96 раз быстрее средней компании. Одна из ключевых технических практик лидеров DevOps — внедрять телеметрию в ПО и приложения.
Что такое телеметрия?
Проще говоря, телеметрия — процесс регистрации поведения ваших систем.
Спроектируйте ПО, рабочие и предрабочие среды и конвейер развёртывания так, чтобы они непрерывно создавали записи телеметрии. Ваша цель — собирать достаточно данных, чтобы убедиться в корректной работе сервисов в рабочих средах. Если возникает проблема, записи помогут быстро понять, в чём она состоит, и принять обоснованные меры.
Телеметрия также позволяет сопоставить ваше представление о работе систем с тем, что происходит на самом деле, и увидеть, насколько они совпадают.
Создайте инфраструктуру телеметрии
Для телеметрии нужны два основных компонента:
- Запись телеметрических метрик Все высокоэффективные DevOps-организации постоянно записывают сотни тысяч метрик на каждом уровне приложений, сред и конвейера развёртывания. Например, события бизнес-логики, такие как число продаж, или показатели работоспособности серверных платформ, полученные при мониторинге операционных систем, баз данных, дискового и сетевого ввода-вывода, оперативной памяти, процессора и безопасности.
- Централизованная платформа для управления метриками Платформа хранит метрики и события. Она позволяет визуализировать данные, отслеживать тенденции, делать выборки, отправлять оповещения и выявлять аномалии. Она преобразует журналы в метрики, например в число критических исключений приложения. События конвейера развёртывания — коммиты, откаты, установки, удаления и результаты автоматизированных тестов в рабочих и предрабочих средах — также следует хранить в той же инфраструктуре телеметрии.
Вы, ваша команда DevOps и все заинтересованные стороны, работающие с ней, должны иметь возможность самостоятельно получать данные телеметрии через API и графические интерфейсы без подачи заявок на доступ.
Все сведения телеметрии должны быть на 100% доступны организации, за исключением метрик, которые могут нарушить конфиденциальность и поставить под угрозу безопасность клиентов.
Виды телеметрических метрик
- Метрики уровня бизнеса Например, результаты A/B-тестирования, прибыль, выручка, число новых пользователей, средняя длительность сеансов, число завершённых заказов и число прерванных оформлений заказов.
- Метрики уровня приложения Например, время ответа приложений, продолжительность транзакций, число дампов памяти и критических исключений.
- Метрики уровня инфраструктуры Например, серверный трафик, операции дискового и сетевого ввода-вывода, использование оперативной памяти, процессора и диска.
- Метрики клиентского уровня Например, время ответа и ошибки клиентских приложений, включая веб-приложения, мобильные приложения, приложения на JavaScript и другие.
- Метрики уровня конвейера развёртывания Например, коммиты, время и частота развёртываний, состояние сред и зелёные, жёлтые или красные статусы по итогам автоматизированных тестов.
Группируйте метрики иерархически по категориям и вложенным подкатегориям, чтобы вам и вашей команде DevOps было легко их интерпретировать.
Делайте понятными записи журналов приложений, из которых затем формируются телеметрические метрики. Как вы распределяете записи по категориям событий, так же группируйте и телеметрию. Пример уровней: Debug, Info, Warn, Error и Fatal.
Используйте телеметрию для поиска решений
Если в организации принято искать виноватых, никто не захочет делать изменения в рабочих системах полностью прозрачными и показывать телеметрию. В такой обстановке первопричины выявляются редко, а главное — организация не приобретает новых знаний.
Чтобы использовать телеметрию для решения проблем, сделайте её создание повседневной задачей всей команды DevOps. Создайте удобные библиотеки, чтобы для записи телеметрии хватало одной строки кода.
Записывайте события изменения данных в системе управления версиями и работающих средах. Так по телеметрии будет легко увидеть связь между изменениями в системах и их влиянием на клиентов.
Например, на диаграмме ниже хорошо видно, что одно из последних развёртываний в четверг вечером, вероятно, вызвало рост числа неудачных покупок при оформлении заказа.
Сопоставьте успешные и неудачные развёртывания с динамикой бизнес-активности.
Посмотреть исходную схему ↗(Источники: Measure Anything, Measure Everything, DevOps Handbook)
Телеметрия помогает обсуждать проблемы предметно. Вам и командам DevOps нечего скрывать друг от друга и от заинтересованных сторон. Поэтому постоянно отслеживайте и показывайте им такие диаграммы в реальном времени, чтобы быстро выявлять проблемы и видеть возможную связь между развёртываниями и ключевыми бизнес-событиями. Бизнес лучше понимает, чем занимаетесь вы и ваша команда, а разработчики и инженеры эксплуатации DevOps видят связь между инцидентами и развёртываниями.
Телеметрия позволяет заметить проблемы, пока их легко и дёшево исправить. Устраняйте их, прежде чем они распространятся и породят новые.
С помощью телеметрии вы и команда DevOps можете выявлять закономерности в ключевых показателях бизнеса и технологий и настраивать оповещения об аномалиях. Сначала пороги могут быть выбраны неверно и давать ложные срабатывания. Это нормально. Не паникуйте и не позволяйте обесценивать усилия и вложения в инфраструктуру телеметрии. Как и с другими задачами сложной системы, вы разберётесь и настроите пороги, подходящие вам, клиентам и бизнесу.
ВЫВОДЫ
Ведущие организации DevOps выражают последствия проблем в измеримых показателях бизнеса, например в количестве потерянных клиентов или недополученной выручке. Благодаря этому сотрудники внимательнее относятся к телеметрии в рабочих и предрабочих средах. Они вкладывают время и ресурсы в её создание и использование и опираются на неё, чтобы быстро выявлять и устранять ошибки.
