Внедрять мониторинг просто потому, что все так делают — такая себе идея. Это не волшебная таблетка, которая творит чудеса. Инструмент бесполезен, если нет понимания, зачем он нужен и как использовать данные. Если понимание есть, то грамотно настроенный мониторинг способен на многое. Речь не столько о стабильной работе системы. Инструмент может помочь получить средства на развитие продукта и даже спасти команду от расформирования. Senior product manager в Booking.com Андрей Менде рассказал, как изменилась жизнь его команды благодаря мониторингу.

Материал подготовлен на основе доклада Андрея в Школе мониторинга. Вы можете посмотреть выступление или прочитать текстовый вариант.

Слово Андрею.

Мониторинг — это оверхэд

Раньше я считал, что задачи по мониторингу — это оверхед, и старался не давать команде инвестировать в них больше, чем требовалось.

Я не видел в мониторинге реальной ценности для клиентов. У нас не было измеримых показателей успеха в этой области. Стабильную работу сервиса считать метрикой нельзя. Разве это заслуга мониторинга? А вдруг приложение оставалось бы таким же надёжным, вложи мы в мониторинг меньше времени и сил? Меня ужасно бесило, что это не получается измерить.

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

Моё отношение к мониторингу изменилось, когда я попал в команду Booking.com. У неё были необычные условия работы и очень толковый тимлид, который помог мне по‑новому взглянуть на мониторинговые инструменты.

Механизм рекомендаций на основе Machine Learning

Наша бэкенд‑команда разрабатывала механизм рекомендаций на основе Machine Learning (ML). Мы анализировали данные и пытались угадать, что понравится людям. Дальше оптимизировали механизм, чтобы он выдавал пользователям такие рекомендации, которые бы повысили конверсию продукта.

Когда пилишь фичи, всё более или менее предсказуемо. Придумал и внедрил несколько фич — одна из трёх оказалась полезной и увеличила нужную метрику.

Работа с рекомендательными системами напоминает казино. Многие вещи понимаешь, только попробовав: выкатываешь в продакшн, смотришь, как себя ведут пользователи, проводишь A/B-тесты. По результатам решаешь, куда двигаться дальше. Нужно постоянно экспериментировать — из десяти вариантов выстреливает дай бог один.

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

Проблема

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

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

В общем, мы теряли время, которое могли потратить на эксперименты и поиск полезных для продукта решений. Мы сильно парились — команду могли расформировать.

Решение: мониторинг + фолбек (запасной вариант)

Что мы сделали, чтобы решить проблему? Во‑первых, выделили нашу сырую логику в отдельные сервисы и стали вызывать их из основного сервиса. Дальше настроили отдельный мониторинг. Это помогло обнаружить сервисы с неустойчивой логикой. Мы снабдили их надёжными фолбеками (fallback).

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

Решение стало прорывом для команды и спасло её от расформирования. В результате:

1. Разработчики стали катить быстро и часто. Их поведение изменилось — они перестали бояться экспериментов, потому что знают, что мониторинг и фолбек их подстрахуют.

2. У нас улучшились отношения с другими командами.

3. Благодаря мониторингу появились чёткие данные, на основании которых можно понять, насколько хорошо мы вкладываемся в устойчивость, и планировать следующие шаги.

4. Благодаря тому, что у нас стало больше релизов, мы приносим больше бизнес‑результата.

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

Выводы

1. Мониторинг — это не страховка. Данные мониторинга должны активно использоваться.

2. Следует защитить крупные развивающиеся куски логики надёжным прикрытием — фолбеком.

3. Мониторинг должен быть связан с результатами для бизнеса.

Ещё больше о мониторинге

Слёрм и коллеги из ITSumma, Selectel, Southbridge, KTS и других компаний провели Школу мониторинга. Школа длилась три дня, на стриме выступили 18 экспертов, которые разобрали мониторинг с разных сторон: от философии до бизнеса.

Записи стримов лежат на YouTube. Мы их порезали на доклады и собрали в плейлисты. Посмотреть записи можно в удобное время — каждое выступление занимает не больше 30 минут.

• Философия мониторинга→

• Техническая секция→

• Бизнес-секция→