Как построить эффективную стратегию мониторинга с высокой наблюдаемостью

Давайте сразу определимся: самым важным в разработке сейчас является производительность и надежность вашей инфраструктуры, потому что если ваш проект лагает или работает через раз, вас не спасут никакие фичи. Клиент просто уйдет к конкурентам.

Исходя из постулата выше, роль мониторинга систем в последние годы резко возросла. Наши системы перешли от технологических новшеств к статусу критической инфраструктуры, без которой повседневная жизнедеятельность просто невозможна. Однако существует зияющая пропасть между формальным мониторингом и мониторингом, который будет соответствовать сложности и глубине современных систем.

Зачастую, даже не смотря на то, что инженеры признают важность эффективного мониторинга, ожидания почти никогда не сходятся с реальностью построения и эксплуатации подобных систем. Ведь достижение всестороннего охвата, который бы полноценно отражал взаимодействие с пользователем, является крайне непростой задачей. И тут на первый план выходят идеи Observability или «наблюдаемости». Воспринимать его стоит не просто как мониторинг или комплекс мер, а как глобальный системный подход к выстраиванию работы с инфраструктурой проекта и его системами.

Наблюдаемость (англ. observability) — это подход к разработке программного обеспечения и управления инфраструктурой, направленный на применение методов, которые позволяют контроллируемо вести разработку приложения и в любой момент времени четко понимать его состояние и статус.

Часто усилия по внедрению обсервабилити начинаются за здравие, и как и нужно — фокусируются вокруг работоспособности критического пользовательского опыта в приложении. Однако, организация действительно полноценного обсервабилити требует больших усилий, и поэтому часто происходят обломы. Этот процесс требует глубокого понимания работы системы за пределами простых проверок, которые лежат на поверхности: «сайт работает», «сервис доступен». Это требует понимания того, что обсервабилити — фундаментальная часть понимания того, как вообще работает система, и как организован пользовательский опыт в приложении (user journey — т.е. как пользователь использует приложение).

К сожалению, многие разработчики даже зная сказанное выше, наступают на одни и те же грабли. Сначала они стремятся всесторонне контролировать свои приложения и сервисы, а в итоге оказываются ограничены приоритетами бизнес-процессов или вовсе изначально скудным инструментарием мониторинга. В итоге мы получаем перекос между скоростью разработки и наблюдаемостью системы, то есть ситуацию, когда разработчик больше не имеет сил и ресурсов бороться с запросами бизнеса на новые фичи и окончательно концентрируется исключительно на кодинге того, что сказали кодить. В такой ситуации развитие системы мониторинга остается за бортом.

По-настоящему глубокий подход к наблюдаемости требует перехода к системному анализу, пониманию пользовательских потоков и симметричного проявления воли как со стороны команды разработки, так и со стороны менеджмента проекта. На практике это означает, что вам нужно не просто расставить галочки мониторинга функций, а постоянно получать обратную связь от своих коллег. Фактически, наблюдаемость теперь — еще один процесс в разработке программного обеспечения, так как в нем участвуют все звенья команды, от рядовых инженеров до специалистов по продукту и менеджеров проекта. Без полноценного вовлечения в процесс построения наблюдаемости всех частей команды вы не сможете составить реальную карту пользовательского пути и определить ключевые узлы, на которые стоит обратить внимание.

Далее по тексту мы представим идеальное видение того, какой должна быть система наблюдаемости и способы ее реализации. Конечно же, мы понимаем, что идеал в современных реалиях практически недостижим из-за самой природы современной разработки с ее постоянно изменяющимся инструментарием, инновационными подходами и бесконечным пилением новых фич. Но условное описание «идеальной сферической системы в вакууме» может использоваться в качестве эталона, к которому можно будет «приложить» свою текущую систему мониторинга и проверить, насколько далеко вы от подобной системы на данный момент.

Ниже мы рассмотрим две самые критические вещи, за которыми нужно следить обязательно.

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

Чек-лист покрытия:

• Убедитесь в возможности входа в систему и посещении ключевых страниц.
• Проверьте время загрузки ключевых страниц и выполнения действий.
• Отслеживайте ошибки JavaScript на основных пользовательских сценариях.
• Убедитесь, что важные функции работают корректно.

Чек-лист оповещений:

• Установите оповещения о неудачных попытках входа в систему или увеличении времени логина.
• Установите оповещении об увеличении времени загрузки страницы сверх заданного порога.
• Отслеживайте количество ошибок JavaScript на критических сценариях поведения пользователя.
• Настройте оповещения о сбоях или других проблемах с производительностью ваших критически важных функций.

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

Чек-лист покрытия:

• Регулярно проводить сверку коэффициентов конверсии и других ключевых показателей.
• Настроить оповещения о внезапных изменениях дохода или других чувствительных данных подобного рода.
• Провести анализ источников трафика и показателей вовлеченности на предмет аномалий.
• Скоординировать работу технической и бизнес-команды для сверки влияния технических неполадок на бизнес-показатели.

Чек-лист оповещений:

• Установите оповещения о значительном падении или изменении коэффициентов конверсии.
• Отслеживайте динамику доходов и других финансовых данных.
• Следите за аномалиях в источниках трафика и скачками в показателях вовлеченности пользователей, которые отклоняются от исторических паттернов их поведения.
• Внедряйте межфункциональные оповещения, чтобы уведомлять сразу и технические, и бизнес-команды об обнаруженных проблемах.

Если погрузиться в нашу экосистему еще сильнее, то для начала важно определить, возникают ли проблемы с интерфейсом, либо же с API-сервисами на серверной части, ориентированными на интерфейс.

Чек-лист покрытия:

• Убедитесь, что все интерфейсные API покрыты мониторингом работоспособности и производительности.
• Настройте ведение журнала ошибок браузера для регистрации сбоев JavaScript и загрузочных ошибок.
• Внедрите мониторинг производительности фронтэнда для отслеживания времени загрузки страниц и пользовательской активности.

Чек-лист оповещений:

• Настройте оповещения о простоях или снижении производительности интерфейсных API на фронтэнде.
• Настройте оповещения о критических ошибок на уровне браузера или о резком росте числа подобных ошибок.
• Отслеживайте и оповещайте о значительных изменениях в производительности фронтэнда, к примеру, о резком увеличении времени загрузки страниц.

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

Если же что-то произошло с интерфейсным API на бэкэнде, то, в идеальном мире, следующим шагом будет локализация проблемы. Это будет возможно в случае, если все приложение покрыто логированием и трассировкой ошибок, что позволит быстро выявить проблемный участок и облегчит работы по устранению.

К сожалению, мы живем не в идеальном мире и на практике такое получается провернуть не всегда, так что о более реалистичных ситуациях, когда информации недостаточно и где искать — непонятно, мы поговорим далее.

Чек-лист покрытия:

• Убедитесь, что все серверные службы и конечные точки включены в распределенную трассировку.
• Настройте подробное ведение журнала для отслеживания ошибок и сбоев во всех серверных службах.
• Отслеживайте показатели производительности серверных служб на предмет признаков деградации или сбоя.

Чек-лист оповещений:

• Настройте оповещение о критических ошибках или сбоях в серверных службах, которые могут указывать на пробему.
• Установите пороговые значения для оповещений о снижении производительности, чтобы выявить проблемы до того, как они повлияют на пользователей.
• Используйте обнаружение аномалий в трассировках и журналах, чтобы автоматически оповещать о необычных закономерностях, указывающих на скрытые проблемы.

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

Чек-лист покрытия:

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

Чек-лист оповещений:

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

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

Чек-лист покрытия

• Профилируйте и отслеживайте ключевые функции сервисов для выявления узких мест в производительности.
• Отслеживайте время взаимодействия сервисов с базами данных, кэшами и другими внутренними системами хранения для выявления задержек.
• Отслеживайте время подключения и ответа на внешние API, чтобы найти проблемы с тайм-аутом или аномальными задержками.
• Используйте сетевой инструментарий для визуализации и мониторинга потока запросов через архитектуру микросервисов, выявляя неисправные сервисы.

Чек-лист оповещений

• Настройте оповещения о серьезных отклонениях во времени выполнения относительно базовых значений.
• Используйте оповещение о частоте ошибок, превышающее предопределенные пороговые значения в функциях службы или при взаимодействии с зависимостями.
• Внедряйте оповещения о тайм-аутах или значительных задержках при подключениях к базам данных, кэшам, внешним API и другим микросервисам.

Итак, мы наконец-то дошли до той области, наблюдаемость которой нормально выстроена в большинстве экосистем. Конечно же, речь идет о серверной/облачной инфраструктуре, на которой и крутится основной продукт. Хотя большинство сценариев, описанных выше (такие как сбои на уровне приложений, проблемы взаимодействия сервисов или неполадки интерфейсов), напрямую не связаны с серверной частью, шанс возникновения многих проблем в работе приложений напрямую зависит от производительности инфраструктурной части или от ее деградации.

Чек-лист покрытия

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

Чек-лист оповещений

• Настройте оповещения на основе пороговых значений для критических показателей сервера (ЦП, память, дисковый ввод-вывод), чтобы быстро определить, когда вычислительные мощности перегружены.
• Настройте оповещения о проблемах с оркестровкой контейнеров, включая неудачные развертывания или неработоспособные модули.
• Установите оповещения о производительности сети, чтобы уведомить команды о потенциальных проблемах с подключением или ухудшении качества сети.
• Внедряйте оповещения о простоях облачных служб или ухудшении производительности, которые могут повлиять на доступность или производительность приложений.

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

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

Зачастую клиентская поддержка и разработка существуют в разных плоскостях. Пока девелоперы генерируют идеи и разрабатывают разные крутые фичи, команда саппорта оправдывается за то, в чем не виновата и выслушивает просьбы и требования, которые не в состоянии выполнить. Чаще всего саппорт используют в качестве спам-фильтра, задача которого оградить девелоперов от слишком активных пользователей и позволить им спокойно делать свою работу, параллельно собирая обратную связь от клиентов. Очень часто саппорт сообщает разработчикам о критических сбоях или неполадках, потому что в их случае техподдержка получает целый шквал писем. Однако в идеальном мире саппорт должен служить не первой линией оповещения, а только источником подтверждения ранее полученной информации и способом обратной связи с пользователем. То есть, о проблемах с сервисом вы, как девелоперы, должны узнавать не от собственной техподдержки и клиентов, а от систем мониторинга сбоев и производительности.

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

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

Чек-лист покрытия

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

Чек-лист оповещений

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

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

Самое важное в нашем ТГ-канале ^[2]. Без лишнего спама.