Привет, Хабр! Я Максим, руковожу разработкой систем наблюдаемости и надежности в ижевском ИТ-хабе Т-Банка. Моя статья — часть проекта «20 в 20», в котором мы рассказываем о региональных ИТ-хабах и о том, как в них растут команды и инженерные практики.
Когда в 2019 году у нас внезапно исчез Splunk, мы столкнулись не только с технической, но и с организационной задачей. Нужно было за короткий срок построить собственную платформу наблюдаемости, которая выдержит нагрузку, не упрется в вендорский замок и сможет развиваться вместе с бизнесом.
Так появился Sage Observability — платформа, через которую мы видим состояние всего ИТ-стека: от инфраструктуры до бизнес-метрик, клиентских приложений и инцидентов.
Но сам продукт — только половина истории. Вторая половина — то, как мы строили команду вокруг него: как делили зоны ответственности, меняли процессы, внедряли архитектурный комитет, перераспределяли дежурства и учились работать распределенной командой без потери контекста.
Рассказываю свою историю, добро пожаловать под кат!
С чего все началось
В 2019 году мы оказались без Splunk: продлить лицензию стало невозможно. На рынке были альтернативы, но повторять историю с жесткой зависимостью от вендора не хотелось. Поэтому приняли решение идти в собственную разработку.
Это не выглядело как быстрый и очевидный путь. Скорее как длинный проект с высоким риском и большой ценой ошибки. Но именно из этого решения вырос Sage Observability.
В том же 2019 я пришел в Т-Банк тимлидом — заниматься тестированием производительности финансовых систем. До этого работал SDET в аутсорс-компании. Этот опыт сильно повлиял на мой подход к качеству, надежности и инженерной дисциплине.
Со временем я перешел в направление наблюдаемости и надежности, где пришлось решать уже не только технические, но и командные задачи. Когда система растет, проблемы начинаются не с кода, а с организации: кто за что отвечает, как принимаются решения, как не теряется контекст и как не выгорают люди.
Sage Observability — это не «еще один мониторинг», а система, через которую видно состояние всего: инфраструктуры, бизнеса, безопасности, клиентских приложений.
По масштабу сейчас:
2000+ серверов
10+ ГБ/с телеметрии
11+ ПБ хранения за 2 недели
Важно, что Sage не сразу был таким. Первые несколько лет это была команда примерно из 15 человек, которая, по сути, строила систему с нуля.
Сейчас команда выросла кратно — уже больше 100 человек, и это совсем другой уровень сложности: больше доменов, больше зависимостей, больше требований к процессам.
Почему маленькая команда перестает работать на большом масштабе
На старте все знают всё. Это удобно, быстро и кажется эффективным. Но на большом масштабе такой подход ломается.
Когда команда растет, общие зоны ответственности превращаются в зоны безответственности. Люди начинают тратить слишком много времени на передачу контекста, решения принимаются медленно, а технический долг и организационный хаос начинают усиливать друг друга.
Мы быстро поняли, что дальше нужен не просто рост команды, а переход к доменной модели. Поэтому поделили систему на области ответственности: логи, метрики, трейсы и другие направления. За каждой зоной должен был появиться конкретный владелец.
На это ушло около трех месяцев. И даже после этого через полгода пришлось донастраивать границы. Но это нормальный процесс: ownership не возникает сам по себе, его нужно выстраивать и закреплять. Вместо модели «все делают всё» мы пришли к системе, где у каждого блока есть своя зона ответственности и свой технический лидер.
Эффекты, которые мы получили:
стало проще принимать решения;
снизилась нагрузка на конкретных людей, которые раньше были точками входа по всем вопросам;
команда начала расти без постоянной потери контекста.
Параллельно мы расширили стек за счет новых фичей. Детектор аномалий на телеметрии написан на Python и Scala, так как ML — это в первую очередь про Python.
Какие процессы пришлось изменить
Когда команда и продукт растут, одного технического решения недостаточно. Приходится пересобирать базовые процессы:
Мы выстроили онбординг, через который проходят все новые разработчики.
Сформировали единый процесс найма, чтобы не собирать его заново под каждую вакансию.
Запустили архитектурный комитет, чтобы управлять изменениями.
Разделили большую команду на доменные.
Пересмотрели ежедневные ритуалы, ввели WIP-лимиты и добавили регулярное планирование.
Из-за масштаба стало важно не просто делать задачи, а управлять потоком работы. Иначе команда начинает тонуть в параллельных инициативах и терять фокус.
Перераспределение ответственности за прод — один из самых чувствительных шагов. Раньше релизы требовали обязательного одобрения от SRE. Сейчас днем на проде дежурят разработчики, а в остальное время — SRE. При этом SRE по-прежнему отвечают за инфраструктуру 24/7.
Перераспределение ответственности непросто внедрять, потому что оно требует доверия и зрелости команды. Но без такой модели невозможно по-настоящему реализовать принцип you build it, you run it. Для нас это шаг к большей инженерной ответственности внутри команды разработки.
С ростом команды стало ясно, что без четкого ритма контекст начинает расползаться.
Сейчас у нас есть обязательные встречи:
по пятницам — планирование в командах;
по понедельникам — общий синк направлений;
раз в две недели — демо;
плюс архитектурные комитеты и техтолки.
Это не бюрократия ради бюрократии. В распределенной и быстрорастущей команде без общего ритма невозможно поддерживать единое понимание целей, зависимостей и текущего состояния системы.
Архитектурный комитет появился для управления изменениями как понятный механизм принятия архитектурных решений. Сначала это был простой формат, который помогал не принимать решения хаотично. Со временем он превратился в рабочий инструмент, через который мы:
фиксируем архитектурные решения в формате RFC и ADR;
разбираем спорные и сложные случаи;
не теряем контекст в быстро меняющейся системе.
За три года формат комитета менялся несколько раз. И это нормально: по мере роста команды и продукта меняются и сами механизмы управления.
Как работает распределенная команда
Sage Observability изначально строилась как распределенная команда: от Минска до Красноярска. Чтобы такая модель работала, нам пришлось договориться о едином рабочем окне с 10:00 до 17:00 по Москве, пересобрать встречи и регулярно синхронизироваться.
Удаленная и распределенная работа не ломает команду сама по себе. Ломает команду отсутствие договоренностей. Мы стараемся сохранять инженерную культуру без микроменеджмента и постоянного контроля. Для нас важны ответственность, самостоятельность и прозрачные зоны владения.
Главная боль, с которой мы столкнулись на масштабе, — это контекст. Слишком много сервисов, слишком много зависимостей, слишком много общих зон, за которые отвечают все и одновременно никто. В таких условиях решения начинают замедляться, а проблемы — теряться между командами.
Выход оказался простым по форме и сложным по внедрению: явный ownership и доменные команды. Когда понятно, кто владеет частью системы, становится проще развивать продукт, принимать решения и масштабировать команду без потери управляемости.
С 1 января 2026 года я стал отвечать за разработку системы инцидент-менеджмента — Finedog. Раньше мы развивали эти два продукта параллельно. У нас часто были проблемы на стыках перехода от обнаружения проблемы к заведению инцидента, от поиска проблемы и обратно к координации инцидента.
Четыре простых действия предполагают четыре перехода между двумя системами по кругу. Чтобы выпрямить этот путь и упростить работы, мы решили объединить разработку и продуктовое развитие двух систем в одном направлении. Это позволило пошарить между командами инженерную экспертизу и культуру, а в итоге еще и усилить обе команды.
Хаб как место силы
Для меня отдельно важна история Ижевска. Часть команды была в Москве, я сам — в Ижевске. Это не просто еще одна географическая точка, а полноценный ИТ-хаб, который рос вместе с продуктами. Здесь сильная инженерная база — во многом благодаря индустриальному прошлому города — и при этом довольно живая локальная тусовка: митапы, комьюнити, плотное общение между командами.
Когда мы начинали, в Ижевске в контуре Sage Observability был буквально один человек. Сейчас — несколько инженеров, полноценная часть продуктовой разработки с ownership своих зон. Локально команда — и за счет плотной вовлеченности в продукт — одна из самых «заряженных»: люди не просто пилят задачи, а хорошо понимают, как устроена система целиком.
Я сам почти каждый день хожу в офис — он в 400 метрах от дома. В ковид какое-то время вообще был там единственным «жителем». Параллельно я много времени вкладываю в профессиональное сообщество: участвую в конференциях, в том числе в программных комитетах. Это помогает не замыкаться только на внутреннем контексте и сверяться с индустрией.
Плюс я преподаю и регулярно выступаю — мы сотрудничаем с обоими государственными вузами города — ИжГТУ и УдГУ. А еще мои коллеги ведут курс по алгоритмам и структурам данных в ИжГТУ, участвуют в ярмарках вакансий и проводят junior-митапы.
Один из самых приятных эффектов — когда ребята сначала защищают диплом, а через пару лет приходят к нам и уже сами рассказывают про Sage.
Технологический стек ижевского хаба широкий: у нас работают Java-, .NET-, Go- и JS-разработчики (React и Angular), iOS- и Android-разработчики, системные и бизнес-аналитики, SRE-инженеры, а также QA-специалисты всех профилей: бэкенд, фронтенд и мобайл. Команды разрабатывают и поддерживают мобильный банк, платежные платформы, Единую лояльность, B2B Шопинг, Benefit Solution, Compensation Solution, интерфейсы экосистемы и экосистемную безопасность, Т-ЦОД, Sage и другие.
А еще у нас появилась новая традиция — кулинарные мастер-классы. Традицию запустил наш коллега, известный в команде как гурман и мастер домашней еды. На Новый год он дарил коллегам домашний зефир — такой вкусный, что все сразу спрашивали рецепт. Вместо того чтобы писать его в чат, он предложил: «А давайте сделаем мастер-класс?»
Если вдруг зайдете к нам в гости — на первом этаже, скорее всего, услышите гитару. Там сидят особенно музыкальные ребята, которые специально приобрели инструмент в офис, чтобы играть в перерывах. Это не часть HR-программы — это просто то, как у нас получается работать: серьезно над продуктом, но с легкостью в атмосфере.
Что дальше
Мы продолжаем развивать Sage Observability как платформу наблюдаемости с ИИ: она помогает улучшать пользовательский опыт, обеспечивает сквозное наблюдение за ИТ-стеком и доступностью сервисов.
Нельзя однажды «настроить» команду и считать вопрос решенным. Меняются люди, задачи, внешние условия, ожидания и сам масштаб системы. Из-за этого процессы, роли и даже формат архитектурного комитета приходится пересматривать снова и снова. Это не признак нестабильности — это нормальная жизнь зрелой инженерной команды.
А если резюмировать всю историю одной фразой, то она будет такой: масштабирование команды — не только про наем. Это про ответственность, границы, ритм, архитектуру и готовность постоянно пересобирать процессы под реальность.
Другие статьи проекта «20 в 20»:
TatianaShapo
очень прикольная история про зефир! Он до сих пор кажется мне чем-то сложным