15 сервисов, 1 контракт, 1 дашборд: как не утонуть в мониторинге при быстром росте
Программный комитет ещё не принял решения по этому докладу
Целевая аудитория
Тезисы
Допуслуги к авиабилетам — страховки, выбор мест, багаж — за три года выросли из побочного заработка в значимую долю выручки авиа-направления Туту. Но архитектурно они спроектированы по принципу graceful degradation: если допуслуга не ответила или упала, пользователь просто покупает билет без неё. Сервисы-потребители в соседних командах видят ошибку, но за выручку по услугам отвечают не они. В итоге те, кому падение бьёт по деньгам, узнают о нём последними — иногда через контакт-центр, иногда случайно.
Это значит, что качественный мониторинг на нашей стороне — единственный способ быстро узнать о проблеме и не терять деньги. И именно он у нас был в худшем состоянии: 15 Go-микросервисов, 15 почти одинаковых дашбордов, ∼40 алертов с разной логикой, а самая прибыльная услуга — страховки — год прожила без мониторинга вообще.
Все 15 сервисов реализуют единый protobuf-контракт с методами поиска, выписки и возврата и ходят во внешние API ∼10 партнёров. Это архитектурное решение, принятое для масштабирования бизнеса, стало фундаментом для масштабирования наблюдаемости. Я расскажу, как мы использовали единообразие сервисов, чтобы построить мониторинг, который растёт вместе с бизнесом, а не против него.
В ИТ больше 15 лет, 12 из них — в авиа-команде Туту. Пришла фронтендером, а теперь руковожу командой бекендеров. По дороге, конечно, погрузилась в Go, эксплуатацию, менеджмент и обнаружила, что строить системы и собирать команды не менее увлекательно, чем скруглять уголки. Вместе с командой запустили больше 15 допуслуг за два года
Видео
Другие доклады секции
SRE и эксплуатация систем
