Pull to refresh

Функциональные мониторинги в Яндексе

IT systems testing
Мониторите ли вы свои сервисы в продакшене? Чья у вас это зона ответственности?

Часто, когда речь заходит о мониторингах, приходят на ум серверные разработчики, системные администраторы и DBA, которые должны следить за очередями обработки данных, наличием свободного места на дисках, за жизнеспособностью отдельных хостов и нагрузкой.
Такие мониторинги действительно дают много информации о сервисе, но далеко не всегда показывают, как сервис работает для реального пользователя. Поэтому, в качестве дополнения к системным мониторингам, мы создали в Яндексе систему функциональных мониторингов, отслеживающих состояние сервиса через конечные интерфейсы – через то, как приложение выглядит и работает в браузере, и то, как оно работает на уровне API.
Что же такое функциональные мониторинги в нашем понимании? Чтобы лучше это понять, давайте посмотрим на то, как все развивалось.

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

Что же это и зачем


Почему функциональные тесты, написанные для регрессионного тестирования и успешно отработавшие в тестинге, находят проблемы в продакшене?
Мы выявили несколько причин:

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


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

Поставщики данных


Хороший пример страницы, зависящей от поставщиков данных, – это главная страница Яндекса.
Погода и Новости, Афиша и Телепрограмма, даже фото дня с саджестом поиска – это данные от внешних и внутренних поставщиков.
Например, в Архангельске блок Афиши однажды выглядел так:
image
Тогда как в Мурманске все было в порядке
image

Это произошло потому, что поставщик не прислал данные для Архангельска (или не обновился импорт на нашей стороне). Иногда эта проблема носит разовый характер, а в некоторых случаях могут быть сформулированы KPI по проценту доступных данных и их свежести.

«Железные» проблемы


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

Деградация сервиса с течением времени


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

Итак, функциональные мониторинги – это функциональные автотесты, «заточенные» на поиск определенных проблем и постоянно запускаемые в продакшене.

Что внутри


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

Для предотвращения ложных срабатываний наша система, реализованная на основе фреймворка Apache Camel, позволяет агрегировать несколько последовательных результатов от одного теста в одно событие. Например, можно настроить фильтрацию 3 из 5, которая позволит нотифицировать о поломке только в случае, если тест выдал ошибку 3 раза в 5 последовательных запусках (аналогично можно задать, например, фильтрацию 2 из 2 или убрать фильтрацию – 1 из 1). При этом важно и то, как часто запускается тест, чтобы задержка при такой фильтрации была приемлемой.

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

Рецепт


Идея функциональных мониторингов очень проста, и такие мониторинги бывают очень эффективны в работе.
Рецепт приготовления:
1. Проанализировать, какие части вашего сервиса могут ломаться в продакшене и почему.
2. Написать (или отобрать из имеющихся) автотесты на эту функциональность.
3. Запускать эти тесты в продакшене так часто, как вам нужно и как позволяют системы запуска тестов.
4. Обрабатывать результаты и нотифицировать о поломках, сравнивать с другими источниками информации о жизни сервиса.

PS: Уже давно нас занимает вопрос, насколько распространена идея функциональных мониторингов и как она применяется в других компаниях. Кто-то говорит о таком подходе, как о само собой разумеющемся, кто-то, узнав, решает реализовать у себя, а кто-то считает такие мониторинги лишними при наличии системных мониторингов.
А как вы отслеживаете состояние ваших сервисов в продакшене, какие инструменты и их сочетания используете?
Tags:тестированиемониторинг
Hubs: IT systems testing
Total votes 23: ↑18 and ↓5 +13
Views8.7K

Popular right now

Senior QA Engineer (Growth)
from 2,500 to 3,500 $PandaDocRemote job
QA Engineer (mobile, web)
to 150,000 ₽J'JOСанкт-Петербург
IT Recruiter
from 50,000 ₽Red LabRemote job
IT рекрутер
from 50,000 to 80,000 ₽КавычкиRemote job
Рекрутер (IT)
from 30,000 to 70,000 ₽ЛАНИТУфа

Top of the last 24 hours