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

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

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

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

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

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

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

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

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

Работоспособность приложений и взаимодействие с пользователями

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

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

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

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

Анализ влияния на бизнес

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

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

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

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

Локализация проблем на фронтэнде или бэкэнде

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

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

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

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

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

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

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

Мониторинг бэкэнда

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

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

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

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

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

Поиск сбоев сервисов

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

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

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

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

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

Сервисное профилирование и анализ зависимостей

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

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

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

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

Инфраструктурный мониторинг

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

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

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

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

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

Интеграция отзывов пользователей

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

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

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

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

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

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

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

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

Итого

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

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