Автор: Алексей Мерсон · Код Желтый
Алексей Мерсон работает в Sage — внутренней observability-платформе Т-Банка. Доклад открывает конференцию по надёжности и наблюдаемости, организованную той же командой: это намеренно вводный разговор — синхронизировать понятия, прежде чем идти глубже.
Центральная структура доклада — пирамида качества: в основании надёжность, выше опыт пользователя. Это не абстракция: если система ненадёжна, весь разговор про UX и satisfaction теряет смысл. Надёжность Мерсон определяет через SRE-буки Google — вероятность выполнить требуемые функции без отказов за заданный период. Из этого вырастают SLI (конкретная метрика, связанная с пользовательским опытом), SLO (целевое значение) и бюджет ошибок — то время, которое система может «лечь», не нарушив SLO. Ключевые метрики для оптимизации — MTBF (среднее время между отказами) и MTTR (среднее время восстановления): чем больше первое и меньше второе, тем лучше используется бюджет ошибок. Наблюдаемость нужна именно для того, чтобы обе величины улучшать — без неё, по словам Мерсона, «бежишь через горящий лес с закрытыми глазами».
Кому смотреть: инженерам и тимлидам, которые слышали слова SLO, observability и MTTR в разных контекстах, но хотят разложить их по полочкам и понять, как они связаны между собой — до того как разбираться с конкретными инструментами.
Из этого можно взять в работу: сформулировать для своего сервиса один SLI — одну метрику, напрямую отражающую пользовательский опыт, а не просто аптайм базы данных. Это первый шаг, с которого Мерсон предлагает начинать.
Определение наблюдаемости Мерсон берёт из Splunk: «возможность измерять внутреннее состояние системы по её выходным данным». Не «дашборды», не «алерты», а способность ответить на вопрос о системе, имея только её outputs — метрики, логи, трейсы. Именно эта телеметрическая триада служит фундаментом. Отправная точка при построении мониторинга — четыре золотых сигнала из SRE-книги Google: latency (время выполнения), traffic (нагрузка), errors (процент ошибок), saturation (утилизация ресурсов).
Вторая часть доклада — обзор инструментов и практик Т-Банка. Spirit — платформа инфраструктуры (балансировщики, базы данных, Kubernetes as a service и т.д.). FogDog — система инцидент-менеджмента: каталог услуг, карта здоровья, дежурство, постмортемы. Sage — observability-платформа. Тачат — собственный мессенджер, который используется как канал алертов: Мерсон отдельно объясняет, зачем нужен подконтрольный инструмент вместо Telegram. Колобок — управление релизами с календарём и фич-фризами; есть идея интегрировать его с инцидент-менеджментом так, чтобы релизы останавливались автоматически при исчерпании бюджета ошибок.
На организационном уровне: в Т-Банке есть роль CRO — reliability champion в каждом управлении, отдельный Центр надёжности как юнит на уровне компании и «Вселенная мониторинга» — мобильная команда, помогающая другим командам выстраивать мониторинг. Мерсон считает, что в большой компании без таких фокусированных ролей надёжность не развивается системно.
Итоговая цепочка, которую он формулирует явно: observability → надёжность → качество → пользователи. Держать её в голове полезно, когда нужно объяснять руководству, зачем вкладываться в инфраструктуру.