Привет, Хабр! Я Максим, руковожу разработкой систем наблюдаемости и надежности в ижевском ИТ-хабе Т-Банка. Моя статья — часть проекта «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»: 

• Иннерсорс: строим культуру открытого кода в большой компании

• Окружение помогает расти: как в челябинском ИТ-хабе инженер техподдержки стал руководителем проектов

• Как я стал Scala-разработчиком в Иннополисе