Давайте сразу определимся: самым важным в разработке сейчас является производительность и надежность вашей инфраструктуры, потому что если ваш проект лагает или работает через раз, вас не спасут никакие фичи. Клиент просто уйдет к конкурентам.
Исходя из постулата выше, роль мониторинга систем в последние годы резко возросла. Наши системы перешли от технологических новшеств к статусу критической инфраструктуры, без которой повседневная жизнедеятельность просто невозможна. Однако существует зияющая пропасть между формальным мониторингом и мониторингом, который будет соответствовать сложности и глубине современных систем.
Зачастую, даже не смотря на то, что инженеры признают важность эффективного мониторинга, ожидания почти никогда не сходятся с реальностью построения и эксплуатации подобных систем. Ведь достижение всестороннего охвата, который бы полноценно отражал взаимодействие с пользователем, является крайне непростой задачей. И тут на первый план выходят идеи Observability или «наблюдаемости». Воспринимать его стоит не просто как мониторинг или комплекс мер, а как глобальный системный подход к выстраиванию работы с инфраструктурой проекта и его системами.
Наблюдаемость (англ. observability) — это подход к разработке программного обеспечения и управления инфраструктурой, направленный на применение методов, которые позволяют контроллируемо вести разработку приложения и в любой момент времени четко понимать его состояние и статус.
Часто усилия по внедрению обсервабилити начинаются за здравие, и как и нужно — фокусируются вокруг работоспособности критического пользовательского опыта в приложении. Однако, организация действительно полноценного обсервабилити требует больших усилий, и поэтому часто происходят обломы. Этот процесс требует глубокого понимания работы системы за пределами простых проверок, которые лежат на поверхности: «сайт работает», «сервис доступен». Это требует понимания того, что обсервабилити — фундаментальная часть понимания того, как вообще работает система, и как организован пользовательский опыт в приложении (user journey — т.е. как пользователь использует приложение).
К сожалению, многие разработчики даже зная сказанное выше, наступают на одни и те же грабли. Сначала они стремятся всесторонне контролировать свои приложения и сервисы, а в итоге оказываются ограничены приоритетами бизнес-процессов или вовсе изначально скудным инструментарием мониторинга. В итоге мы получаем перекос между скоростью разработки и наблюдаемостью системы, то есть ситуацию, когда разработчик больше не имеет сил и ресурсов бороться с запросами бизнеса на новые фичи и окончательно концентрируется исключительно на кодинге того, что сказали кодить. В такой ситуации развитие системы мониторинга остается за бортом.
По-настоящему глубокий подход к наблюдаемости требует перехода к системному анализу, пониманию пользовательских потоков и симметричного проявления воли как со стороны команды разработки, так и со стороны менеджмента проекта. На практике это означает, что вам нужно не просто расставить галочки мониторинга функций, а постоянно получать обратную связь от своих коллег. Фактически, наблюдаемость теперь — еще один процесс в разработке программного обеспечения, так как в нем участвуют все звенья команды, от рядовых инженеров до специалистов по продукту и менеджеров проекта. Без полноценного вовлечения в процесс построения наблюдаемости всех частей команды вы не сможете составить реальную карту пользовательского пути и определить ключевые узлы, на которые стоит обратить внимание.
Далее по тексту мы представим идеальное видение того, какой должна быть система наблюдаемости и способы ее реализации. Конечно же, мы понимаем, что идеал в современных реалиях практически недостижим из-за самой природы современной разработки с ее постоянно изменяющимся инструментарием, инновационными подходами и бесконечным пилением новых фич. Но условное описание «идеальной сферической системы в вакууме» может использоваться в качестве эталона, к которому можно будет «приложить» свою текущую систему мониторинга и проверить, насколько далеко вы от подобной системы на данный момент.
Ниже мы рассмотрим две самые критические вещи, за которыми нужно следить обязательно.
Работоспособность приложений и взаимодействие с пользователями
Чтобы обеспечить непрерывную работу приложений, нужно прибегнуть к проверкам, которые повторяют действия браузера, имитируя пользовательскую активность. В этот перечень входят проверки возможности логина, проверка корректного функционирования типичных пользовательских операций и выполнение основных действий в приложении.
| Ответ | |
|---|---|
| Цель | Убедиться в работоспособности базовых функций приложения. |
| Кто предоставляет метрики | Команда управления продуктом, которая определяет критические пользовательские сценарии и функциональные возможности. |
| Инструменты | Синтетический мониторинг (через браузер), мониторинг деятельности реальных пользователей (Real User Monitoring или RUM). |
| Что отслеживать | доступность, функциональность и производительность ключевых функций и пользовательских сценариев. |
- Убедитесь в возможности входа в систему и посещении ключевых страниц.
- Проверьте время загрузки ключевых страниц и выполнения действий.
- Отслеживайте ошибки JavaScript на основных пользовательских сценариях.
- Убедитесь, что важные функции работают корректно.
Чек-лист оповещений:
- Установите оповещения о неудачных попытках входа в систему или увеличении времени логина.
- Установите оповещении об увеличении времени загрузки страницы сверх заданного порога.
- Отслеживайте количество ошибок JavaScript на критических сценариях поведения пользователя.
- Настройте оповещения о сбоях или других проблемах с производительностью ваших критически важных функций.
Анализ влияния на бизнес
Кроме инженеров вы можете получить информацию о проблемах или сбоях от вашей бизнес-команды, которая отслеживает конверсии, продажи и доходы от продукта. На первый взгляд все может идти хорошо, но если внезапно у вас обвалились продажи подписок, это может свидетельствовать о проблемах за пределами поля зрения команды, которая занимается мониторингом. Своевременное распознавание таких проблем позволит принять более взвешенное решение и спокойно построить работу продуктовой и технической команды, вместо того, чтобы в панике латать дыры, когда ситуация примет угрожающий характер.
| Ответ | |
|---|---|
| Цель | Убедиться, что критические бизнес-процессы протекают в штатном режиме, причем проверка должна проводиться без привязки к результатам технического мониторинга. |
| Кто предоставляет метрики | Бизнес-аналитики в связке с командой управления продуктом. |
| Инструменты мониторинга | Инструменты бизнес-аналитики (BI), интегрированный с бизнес-аналитикой APM (мониторинг производительности приложения), информационные панели. |
| Что отслеживать | Изменения в бизнес-показателях, закономерности и тренды, которые могли бы указать на наличие технической проблемы, оказывающей влияние на поведение пользователей или достижение бизнес-целей. |
- Регулярно проводить сверку коэффициентов конверсии и других ключевых показателей.
- Настроить оповещения о внезапных изменениях дохода или других чувствительных данных подобного рода.
- Провести анализ источников трафика и показателей вовлеченности на предмет аномалий.
- Скоординировать работу технической и бизнес-команды для сверки влияния технических неполадок на бизнес-показатели.
Чек-лист оповещений:
- Установите оповещения о значительном падении или изменении коэффициентов конверсии.
- Отслеживайте динамику доходов и других финансовых данных.
- Следите за аномалиях в источниках трафика и скачками в показателях вовлеченности пользователей, которые отклоняются от исторических паттернов их поведения.
- Внедряйте межфункциональные оповещения, чтобы уведомлять сразу и технические, и бизнес-команды об обнаруженных проблемах.
Локализация проблем на фронтэнде или бэкэнде
Если погрузиться в нашу экосистему еще сильнее, то для начала важно определить, возникают ли проблемы с интерфейсом, либо же с API-сервисами на серверной части, ориентированными на интерфейс.
| Ответ | |
|---|---|
| Цель | Определить, где возникают проблемы, во внешнем или внутреннем интерфейсном API. |
| Кто предоставляет метрики | Команды фронтенд- и бэкэнд-разработки. |
| Инструменты | Синтетический мониторинг, мониторинг реальных пользовательских пользователей (RUM), интерфейсные API, также рассмотрите возможность использования таких инструментов, как AlertSite, RunScope, Pingdom и т.п. |
- Убедитесь, что все интерфейсные API покрыты мониторингом работоспособности и производительности.
- Настройте ведение журнала ошибок браузера для регистрации сбоев JavaScript и загрузочных ошибок.
- Внедрите мониторинг производительности фронтэнда для отслеживания времени загрузки страниц и пользовательской активности.
Чек-лист оповещений:
- Настройте оповещения о простоях или снижении производительности интерфейсных API на фронтэнде.
- Настройте оповещения о критических ошибок на уровне браузера или о резком росте числа подобных ошибок.
- Отслеживайте и оповещайте о значительных изменениях в производительности фронтэнда, к примеру, о резком увеличении времени загрузки страниц.
Если проблема находится на фронтэнде, то команда деплоя должна откатиться к предыдущей рабочей версии, отключить поломанную функцию с помощью флага, либо же выкатить фикс, который закроет проблему.
Если же что-то произошло с интерфейсным API на бэкэнде, то, в идеальном мире, следующим шагом будет локализация проблемы. Это будет возможно в случае, если все приложение покрыто логированием и трассировкой ошибок, что позволит быстро выявить проблемный участок и облегчит работы по устранению.
К сожалению, мы живем не в идеальном мире и на практике такое получается провернуть не всегда, так что о более реалистичных ситуациях, когда информации недостаточно и где искать — непонятно, мы поговорим далее.
Мониторинг бэкэнда
| Ответ | |
|---|---|
| Цель | Определить точное место и причину ошибок на серверной части, отслеживания источник проблем при мониторинге всего стека служб. |
| Кто предоставляет метрики | Команды внутренней разработки и эксплуатации. |
| Инструменты | Инструменты распределенной трассировки (например, Jaeger, Zipkin), инструменты агрегирования журналов (например, ELK, Splunk) и инструменты мониторинга производительности приложений (APM). |
| Что отслеживать | Производительность конечных точек и частоту ошибок для выявления сбоев серверных служб, журналы ошибок (для понимания характера проблем серверной части), распределенные трассировки запросов (для отслеживания пути ошибки через стек сервисов). |
- Убедитесь, что все серверные службы и конечные точки включены в распределенную трассировку.
- Настройте подробное ведение журнала для отслеживания ошибок и сбоев во всех серверных службах.
- Отслеживайте показатели производительности серверных служб на предмет признаков деградации или сбоя.
Чек-лист оповещений:
- Настройте оповещение о критических ошибках или сбоях в серверных службах, которые могут указывать на пробему.
- Установите пороговые значения для оповещений о снижении производительности, чтобы выявить проблемы до того, как они повлияют на пользователей.
- Используйте обнаружение аномалий в трассировках и журналах, чтобы автоматически оповещать о необычных закономерностях, указывающих на скрытые проблемы.
Пусть тут и приведены основные кейсы, на практике все происходит зачастую совершенно иначе. Разработка продукта, особенно коммерчески прибыльного продукта, проходит в довольно гибком режиме и высоком темпе. В итоге команды разработки могут легко что-нибудь пропустить или попасть в нестандартную ситуацию. Например, трассировка может быть не настроена, из-за чего микросервис вместо корректной информации о сбое может просто не отвечать по HTTP 200. В таких случаях, вместо того, чтобы надеяться исключительно на трассировку, нужно отслеживать ошибки и сбои через специализированные сервисы мониторинга.
Поиск сбоев сервисов
| Ответ | |
|---|---|
| Цель | Обнаружить конкретное место в приложении, где возникла проблема. |
| Кто предоставляет метрики | Команды внутренней разработки и эксплуатации. |
| Инструменты | Используйте инструменты, которые позволяют выполнять пользовательские запросы к API-интерфейсам серверных микросервисов для мониторинга, такие как Postman для ручного тестирования и автоматизированных сценариев, Prometheus для сбора метрик и оповещений на основе этих метрик и Grafana для создания панелей мониторинга, визуализирующих данные. |
| Что отслеживать | Частота и типы ошибок по службам, время ответа службы и выбросы. |
- Внедрите подробное ведение журналов для всех серверных служб, фиксируя как стандартные операции, так и ошибочные состояния.
- Включите проверки работоспособности для всех служб и убедитесь, что каждая из них может сообщить о своем состоянии в любой момент времени.
Чек-лист оповещений:
- Настройте оповещения о любом увеличении количества ошибок в службах, сортируя при этом критические ошибки и просто предупреждения.
- Получайте алерты о любом превышении порогового значения времени ответа службы, ведь это указывает на потенциальные проблемы с производительностью.
Теперь крайне важно получать подробную информацию о потенциальных причинах сбоя или о снижении производительности. Эти проблемы могут быть связаны с деградацией базовой инфраструктуры либо же вызвана связью с другими компонентами системы. Во втором случае речь идет о микрослужбах внутри приложений, подключениях к базам данных, кэшам и прочим хранилищам. Также не стоит забывать о сторонних API и других внешних факторах. На данном этапе крайне важным становится профилирование служб для точного определения неисправной функциональности.
Сервисное профилирование и анализ зависимостей
| Ответ | |
|---|---|
| Цель | Получать подробные профилированные показатели службы, чтобы иметь возможность выявить снижение производительности сервиса или зафиксировать зависшие/прерванные подключения к другим службам. |
| Кто предоставляет метрики | Команда разработки. |
| Инструменты | Инструменты управления производительностью приложений (APM), инструменты мониторинга производительности сети и инструменты сетевого наблюдения. |
| Что отслеживать | Время выполнения службой различных функций, частота ошибок и точки сбоя при взаимодействии с зависимыми службами. |
- Профилируйте и отслеживайте ключевые функции сервисов для выявления узких мест в производительности.
- Отслеживайте время взаимодействия сервисов с базами данных, кэшами и другими внутренними системами хранения для выявления задержек.
- Отслеживайте время подключения и ответа на внешние API, чтобы найти проблемы с тайм-аутом или аномальными задержками.
- Используйте сетевой инструментарий для визуализации и мониторинга потока запросов через архитектуру микросервисов, выявляя неисправные сервисы.
Чек-лист оповещений
- Настройте оповещения о серьезных отклонениях во времени выполнения относительно базовых значений.
- Используйте оповещение о частоте ошибок, превышающее предопределенные пороговые значения в функциях службы или при взаимодействии с зависимостями.
- Внедряйте оповещения о тайм-аутах или значительных задержках при подключениях к базам данных, кэшам, внешним API и другим микросервисам.
Инфраструктурный мониторинг
Итак, мы наконец-то дошли до той области, наблюдаемость которой нормально выстроена в большинстве экосистем. Конечно же, речь идет о серверной/облачной инфраструктуре, на которой и крутится основной продукт. Хотя большинство сценариев, описанных выше (такие как сбои на уровне приложений, проблемы взаимодействия сервисов или неполадки интерфейсов), напрямую не связаны с серверной частью, шанс возникновения многих проблем в работе приложений напрямую зависит от производительности инфраструктурной части или от ее деградации.
| Ответ | |
|---|---|
| Цель | Выявлять и распознавать проблемы, возникающие на уровне приложений, а так же проблемы, возникающие на уровне базовой инфраструктуры. |
| Кто предоставляет метрики | Команды по инфраструктуре и эксплуатации. |
| Инструменты | Инструменты мониторинга инфраструктуры, такие как Prometheus, Grafana, Datadog, а также собственные инструменты мониторинга облачного провайдера. |
| Что отслеживать | Метрики оркестрации контейнеров (например, работоспособность кластера Kubernetes, статусы модулей). Показатели сервера, включая уровень утилизации ЦП, использование памяти, операции дискового ввода-вывода. Сетевые показатели, такие как использование канала, пинг, потеря пакетов. Работоспособность и доступность облачных сервисов и других критически важных компонентов инфраструктуры. |
- Внедрите непрерывный мониторинг жизненно важных показателей всех физических и виртуальных серверов.
- Отслеживайте работоспособность и производительность систем оркестрации контейнеров, чтобы обеспечить оптимальное развертывание и масштабирование приложений.
- Внимательно следите за пропускной способностью сети и ошибками, чтобы выявить потенциальные узкие места или сбои, влияющие на подключение приложений.
- Организуйте мониторинг облачных сервисов и компонентов инфраструктуры на предмет проблем с доступностью и производительностью.
Чек-лист оповещений
- Настройте оповещения на основе пороговых значений для критических показателей сервера (ЦП, память, дисковый ввод-вывод), чтобы быстро определить, когда вычислительные мощности перегружены.
- Настройте оповещения о проблемах с оркестровкой контейнеров, включая неудачные развертывания или неработоспособные модули.
- Установите оповещения о производительности сети, чтобы уведомить команды о потенциальных проблемах с подключением или ухудшении качества сети.
- Внедряйте оповещения о простоях облачных служб или ухудшении производительности, которые могут повлиять на доступность или производительность приложений.
На наш взгляд, перечисленные шаги выстраивают близкую к идеальной экосистему наблюдения, которую хотелось бы видеть на любом проекте. Конечно же, идеал недостижим и к нему можно только стремиться, но всегда приятнее иметь хоть какой-то более-менее релевантный ориентир для установления вектора развития проекта и компании в целом.
Интеграция отзывов пользователей
На этом можно было бы и заканчивать текст, но есть еще один достаточно распространенный сценарий: когда проблемы с приложением остаются незамеченными и достигают широких слоев пользователей. В такие моменты на саппорт начинает сыпаться гора сообщений от недовольных клиентов, которые решили лично сообщить о сбоях или проблемах с производительностью.
Зачастую клиентская поддержка и разработка существуют в разных плоскостях. Пока девелоперы генерируют идеи и разрабатывают разные крутые фичи, команда саппорта оправдывается за то, в чем не виновата и выслушивает просьбы и требования, которые не в состоянии выполнить. Чаще всего саппорт используют в качестве спам-фильтра, задача которого оградить девелоперов от слишком активных пользователей и позволить им спокойно делать свою работу, параллельно собирая обратную связь от клиентов. Очень часто саппорт сообщает разработчикам о критических сбоях или неполадках, потому что в их случае техподдержка получает целый шквал писем. Однако в идеальном мире саппорт должен служить не первой линией оповещения, а только источником подтверждения ранее полученной информации и способом обратной связи с пользователем. То есть, о проблемах с сервисом вы, как девелоперы, должны узнавать не от собственной техподдержки и клиентов, а от систем мониторинга сбоев и производительности.
Только в этом случае вы сможете начать ликвидацию сбоя еще до возникновения вала тикетов, который похоронит под собой ваш саппорт на несколько суток, и сможете дать своим клиентам реальный и правдивый ответ о том, что проблема известна и на текущий момент устраняется. В случае же, если о сбое станет известно непосредственно от клиентов, это приведет только к росту недовольства пользователей.
Однако мир неидеален, так что у вас всегда будут ситуации, когда о проблеме знают только ваши клиенты и сообщают о ней через вашу техническую поддержку. И такие репорты ни в коем случае нельзя игнорировать.
| Ответ | |
|---|---|
| Цель | Использовать отзывы пользователей для выявления и определения приоритетности проблем, не обнаруженных автоматизированными системами мониторинга. |
| Кто предоставляет метрики | Команды поддержки клиентов и управления продуктами. |
| Инструменты | Платформы обратной связи с клиентами, системы заявок в службу поддержки, интегрированные с инструментами мониторинга, инструменты анализа настроений для социальных сетей и форумов. |
| Что отслеживать | Объем и характер проблем, о которых сообщили пользователи. Анализ настроений и отзывов пользователей по различным каналам. Выявление корреляции между отзывами пользователей и показателями, собираемыми системами мониторинга. |
- Внедрите систему категоризации и количественной оценки проблем, о которых сообщают пользователи. Это позволит анализировать тенденции.
- Для удобного мониторинга интегрируйте в централизованную панель управления отзывы пользователей сразу из нескольких источников, включая заявки в службу поддержки, социальные сети и прямые отзывы по другим каналам связи.
- Используйте инструменты анализа настроений, чтобы оценивать настроения пользователей на разных платформа. Это поможет выявлять потенциальные проблемы через анализ тем, которые обсуждают пользователи.
- Выстройте процессы для выявления корреляции между резкого увеличением потока тикетов и сообщений от пользователей с данными инструментов мониторинга для выявления потенциальных сбоев и проблем.
Чек-лист оповещений
- Настройте оповещения в режиме реального времени об аномальном увеличении количества тикетов от пользователей. Это позволит быстро реагировать на возникающие проблемы.
- Настройте оповещения о значительных изменениях в показателях анализа настроений, указывающих на изменение восприятия пользователей, которое может еще быть не отражено в обращениях через службу поддержки.
- Внедряйте межфункциональные оповещения, чтобы гарантировать, что всплески обратной связи от пользователей доходят как до технической команды, так и до команды поддержки клиентов. Это способствует совместному поиску путей решения возникших проблем.
Итого
В этой статье мы изложили базовые элементы философии построения целенаправленной экосистемы наблюдения, а так же подчеркнули важность согласованности усилий по мониторингу, анализу пользовательского опыта и поддержанием работоспособности приложений. Уже в другой публикации мы постараемся рассмотреть конкретные кейсы и разобрать некоторые вещи на практике.
Самое важное в нашем ТГ-канале. Без лишнего спама.
