В 2019 году Т-Банк остался без Splunk и вместо срочной замены на очередной коммерческий стек пошел в собственную разработку. Из этого решения выросла платформа наблюдаемости Sage Observability, а вместе с ней и отдельная инженерная история: как команда из примерно 15 человек доросла до направления на 100+ специалистов и почему на таком масштабе главной проблемой становится уже не код, а ownership.
Об этом сообщает Habr / Карьера со ссылкой на Максима, руководителя разработки систем наблюдаемости и надежности в ижевском ИТ-хабе Т-Банка. По его словам, исчезновение Splunk в 2019-м поставило банк перед двойной задачей: быстро закрыть технологический разрыв и не попасть в новый вендорский замок. Внутренняя платформа наблюдаемости должна была выдерживать серьезную нагрузку, расти вместе с бизнесом и покрывать не только инфраструктуру, но и бизнес-метрики, клиентские приложения, безопасность и инциденты.
Масштаб, который у Sage есть сейчас, объясняет, почему проект давно перестал быть просто «еще одной системой мониторинга». В публикации фигурируют 2000+ серверов, поток телеметрии на уровне 10+ ГБ/с и более 11 ПБ хранения за две недели. На старте все это делала команда примерно из 15 человек, строившая платформу почти с нуля. Теперь речь идет уже о 100+ сотрудниках, а на таком размере привычная схема, где «все знают все», начинает ломаться довольно быстро. Пока людей мало, она выглядит удобной: решения принимаются быстро, контекст общий, а критичные знания держатся в головах. Когда команд становится много, тот же подход превращается в противоположность эффективности: общая ответственность становится ничьей, синхронизации съедают время, а узкие места концентрируются вокруг нескольких самых опытных инженеров.
Почему рост команды оказался сложнее роста платформы
Именно поэтому в Т-Банке, судя по описанию, довольно рано пришли к доменной модели. Sage разделили на зоны ответственности: логи, метрики, трейсы и другие направления. За каждым блоком появился конкретный владелец и технический лидер. На первичную нарезку границ ушло около трех месяцев, а еще через полгода их пришлось корректировать. Это, пожалуй, самая полезная часть всей истории для любой крупной разработки: ownership почти никогда не возникает «естественным образом», особенно если система уже разрослась. Его приходится проектировать так же осознанно, как схему хранения данных или API между сервисами.
Эффект от такого перехода автор описывает без лишней романтики. Решения стали приниматься быстрее, снизилась нагрузка на людей, которые раньше были универсальной точкой входа по любому вопросу, а рост команды перестал автоматически означать потерю контекста. Параллельно расширялся и стек платформы. Например, детектор аномалий на телеметрии в Sage написан на Python и Scala. Мотивация тут прагматичная: если речь идет о ML-задачах, Python остается рабочим выбором, даже если основной контур платформы устроен иначе. Для русскоязычной инженерной аудитории это еще одно напоминание, что зрелая платформа наблюдаемости почти всегда складывается из нескольких технологических слоев, а не из одного «правильного» языка и одного «правильного» инструмента.
Следом пришлось пересобирать и процессы. В публикации перечислены довольно приземленные, но болезненные для многих компаний вещи: формализованный онбординг, единый процесс найма, архитектурный комитет, WIP-лимиты, регулярное планирование и пересмотр ежедневных ритуалов. Это звучит не так эффектно, как рассказ про петабайты телеметрии, но именно здесь обычно и проваливаются быстрорастущие платформенные команды. Если поток задач не ограничен, а решение спорных архитектурных вопросов зависит от того, кто громче говорит на созвоне, масштаб продукта начинает работать против самой команды. В Т-Банке архитектурный комитет со временем превратился в механизм, через который фиксируют решения в RFC и ADR, разбирают спорные случаи и не теряют контекст в меняющейся системе.
Дежурства, распределенка и стык с инцидентами
Отдельно показателен пересмотр ответственности за прод. Раньше релизы требовали обязательного одобрения от SRE, теперь днем на проде дежурят разработчики, а в остальное время эту функцию берут на себя SRE. При этом инфраструктурная ответственность SRE-состава сохраняется круглосуточно. По сути, команда сдвигается в сторону классического принципа you build it, you run it, но без резкого отказа от инженерных страховочных механизмов. Для бизнеса это важный сигнал: если разработка не участвует в эксплуатации, скорость поставки может расти только на бумаге. На практике же цена ошибки перекладывается на отдельную сервисную прослойку, а это плохо работает и для качества, и для мотивации.
Еще один важный слой истории связан с распределенной работой. Sage изначально собиралась как команда, растянутая от Минска до Красноярска. Чтобы не утонуть в часовых поясах и разрыве контекста, внутри договорились о едином рабочем окне с 10:00 до 17:00 по Москве и выстроили обязательный ритм встреч: по пятницам планирование внутри команд, по понедельникам общий синк направлений, раз в две недели демо, плюс техтолки и архитектурные комитеты. Логика тут довольно трезвая: удаленка сама по себе команду не ломает, ее ломает отсутствие четких правил взаимодействия. Для HR и руководителей это, возможно, одна из самых прикладных мыслей во всей публикации. Распределенная команда не становится зрелой от одного факта, что люди сидят в разных городах. Она становится рабочей только тогда, когда договоренности зафиксированы и соблюдаются.
Наконец, в тексте есть и свежий организационный штрих. С 1 января 2026 года Максим отвечает еще и за разработку системы инцидент-менеджмента Finedog. Ранее Finedog и Sage развивались параллельно, из-за чего на переходах между обнаружением проблемы, заведением инцидента, поиском причин и координацией действий возникали лишние переключения между двумя системами. Объединение разработки и продуктового развития этих направлений выглядит как попытка выпрямить цепочку от сигнала до реакции. И это, вероятно, следующий этап взросления: если платформа наблюдаемости умеет хорошо находить проблему, но путь до управляемого инцидента остается ломаным, бизнес все равно платит за эту разницу временем простоя и нервами команд.
История Sage Observability интересна не потому, что крупный банк построил собственный observability-стек, хотя и это само по себе показательно. Гораздо важнее другое: на масштабе в сотни инженеров и петабайты данных конкурентным преимуществом становится не только технология, но и способность жестко определить зоны владения, пересобрать процессы и убрать лишние переходы между командами и продуктами. Для многих российских ИТ-компаний это уже не теория, а довольно близкое будущее.