Привет, Хабр! Я Степан Аксенов, SRE-инженер в Т-Банке. Эта статья — часть проекта «20 в 20», приуроченного к 20-летию компании: в рамках проекта специалисты из разных городов рассказывают о своей работе, инженерной культуре и о том, как устроены распределенные команды внутри большого бигтеха.
Однажды мы отключили проблемные функции на Android с помощью конфигурационной заглушки. Через 15 минут система зафиксировала резкий рост крашей — но уже на iOS. Оказалось, что решение, безопасное для одной платформы, сломало приложение на другой.
Этот случай еще раз подтвердил, что mobile SRE не классический SRE и в нем нельзя полагаться на привычные практики. Нет ни отката, ни новых логов задним числом, ни полного контроля над средой. В статье — как мы адаптируем SRE-подходы под мобильный банкинг, где фронт работает на миллионах устройств, которые мы не контролируем.
Распределенность — часть архитектуры надежности
История нашей сети региональных ИТ-хабов началась в 2017 году. Тогда мы сразу запустили семь хабов в разных городах России, чтобы в каждом регионе появилась своя штаб-квартира Т, как в Москве. Первым городом стал Санкт-Петербург, потом открылся хаб в Новосибирске. Сегодня у нас уже более 25 ИТ-хабов в России и Беларуси.
Мы хотели расширить географию поиска ИТ-специалистов и найти классных профессионалов, которые стали бы работать с топовыми продуктами без необходимости уезжать из родного города. А еще хотелось развивать профессиональное ИТ-сообщество в регионах.
Для больших систем распределенность команды — способ повысить устойчивость разработки, ускорить обратную связь и снизить потери между этапами работы команд.
SRE команды за счет своей географической распределенности могут более гибко планировать работы. Намного удобнее мне проснуться в 07:00 по Новосибирску, чтобы в 07:30 провести работы, чем коллегам из центрального региона не спать до 03:30. То же самое касается и сбоев, которые могут быть продолжительными: сопровождать их намного проще, если в тот момент, когда ты уже устал и вымотался, процесс подхватывает кто-то из коллег в более ресурсном состоянии.
Новосибирский ИТ-хаб открылся в апреле 2017 года. В апреле 2025 мы расширились — теперь у нас полноценный инженерный центр с собственной динамикой, комьюнити и сильными локальными командами.
Например, у нас большая команда Т-Инвестиций, а еще базовых технологий, включая Spirit-команду, которая разрабатывает PaaS-платформу для разработчиков.
Как география команды влияет на реакцию на сбой
Новосибирский хаб устроен так, чтобы поддерживать работу и вызывать желание приходить сюда чаще. В офисе есть важные детали, которые делают его узнаваемым и живым. Переговорки названы в честь знаковых для Новосибирска локаций: «Спортивная», «Мочище», «Большевичка», «Ипподромка», «Кириешкино». На стенах — типовые граффити, по которым можно узнать ИТ-хаб Т-Банка в любом городе. Это не декоративный шум, а часть общей идентичности.
Важно, что офис перестает быть местом обязательного присутствия и становится местом синхронизации. В Новосибирск ежегодно приезжает порядка 100—150 сотрудников Т-Банка из других городов на стратсессии и тимбилдинги. Коллеги любят бывать у нас не только из-за инфраструктуры, но и из-за атмосферы, а для команды это уже вполне измеряемый актив.
На первый взгляд, история про ИТ-хабы — это про HR, бренд работодателя и региональное развитие. Но для SRE это еще и про надежность организационной системы.
Когда команда распределена между городами, а продукт работает на миллионах устройств, устойчивость зависит не только от серверов и метрик. Она зависит от того, насколько быстро команды могут передавать друг другу контекст, как организован дежурный ритм, где сидят эксперты по платформе, как запускаются изменения и кто отвечает за сценарии end-to-end.
Распределенные ИТ-хабы — еще один слой надежности. Они позволяют
ускорять реакцию за счет часовых поясов, локализовать экспертный опыт рядом с командой и строить устойчивую организацию, которая не завязана на один город или офис.
На этой базе становится понятнее, почему mobile SRE в такой компании — не узкая роль, а работа на стыке эксплуатации, разработки, продукта и организационной инженерии.
Распределенность команды в контексте SRE становится операционным преимуществом: мы получаем непрерывное покрытие по времени, быструю передачу контекста и снижение нагрузки на отдельных инженеров.
Мы часто планируем работы на утренние часы по Новосибирску, чтобы избежать пиковой нагрузки на наши системы в целом. Это удобнее и безопаснее: можно провести изменения в более спокойное время, при полной концентрации.
Но главное, контекст не теряется. Мы используем единые каналы коммуникации, шаблоны инцидентов, централизованные дашборды. Благодаря этому инженер в Новосибирске может продолжить расследование, начатое в Петербурге, как будто он участвовал в нем с самого начала.
Это особенно важно при сложных сбоях, когда нужно быстро собрать команду экспертов: по клиентскому приложению, бэкенду, безопасности, краш-репортингу.
Распределенность ускоряет синхронизацию, потому что каждый знает, где искать нужного человека и какие данные уже собраны.
Mobile SRE: зона ответственности вне дата-центра
В Т-Банке несколько SRE-команд — каждая отвечает за свое направление. Моя команда работает с мобильным банком. Нас десять: девять инженеров и аналитик. Большая часть команды — в Москве, но есть коллеги в Санкт-Петербурге и Новосибирске, включая меня.
Наша зона ответственности охватывает весь жизненный цикл мобильного приложения — от сборки до расследования инцидентов в проде. Мы отвечаем за то, как приложение ведет себя на устройстве клиента: при слабом сигнале, на старых телефонах, с закэшированными данными и разными версиями ОС:
поддерживаем CI/CD-пайплайны и инструменты сборки;
настраиваем и развиваем системы наблюдаемости (события, краш-репорты, метрики);
участвуем в доставке релизов;
участвуем в переключении фича-тогглов и постепенном распространении функциональности;
обеспечиваем удаленное управление поведением приложения через конфиги с бэкенда;
улучшаем надежность и безопасность инфраструктуры;
занимаемся мониторингом;
ведем расследование инцидентов и анализ причин;
работаем с командами разработки, тестирования и техподдержки, чтобы закрывать риски end-to-end.
Формально это классический SRE-подход: автоматизация, надежность, снижение MTTR, управление рисками. Но в мобильной среде почти все привычные инструменты работают иначе или не работают вовсе.
Например, у меня был опыт работы с серверными системами: фронтом, API, базами, очередями. Там я контролировал почти весь путь исполнения: сервисы в моем контуре, логи доступны, релиз можно откатить. В мобильном банке такого контроля нет.
Здесь фронт — не в нашем дата-центре. Он на миллионах устройств, которыми мы не управляем. Если что-то пойдет не так, это не ошибка фронта. Для пользователя это значит «банк не работает».
Именно поэтому mobile SRE — это работа в условиях постоянной неопределенности, когда приходится перестраивать даже базовые практики.
Когда фронт на чужом железе: вызовы мобильной эксплуатации
В классической модели SRE есть контроль над большей частью стека: сервером, сетью, процессами, логами. Если что-то пошло не так, можно посмотреть трейс, добавить лог, откатить релиз. Даже в распределенной системе как минимум известно, где работает наш код.
В мобильном банке этого контроля почти нет. Мы отвечаем за приложение, которое живет на устройствах пользователей: на телефонах, планшетах — где угодно. И на этих устройствах миллионы разных конфигураций: старые версии ОС, разные модели, слабый интернет, включенный режим энергосбережения, кэш, который никто не чистил полгода.
Пользователь в тоннеле, связь прыгает, приложение пытается отправить перевод. В этот момент оно может:
потерять сетевой запрос;
зависнуть из-за блокировки UI-потока;
сломаться при парсинге ответа от бэкенда;
не обработать ошибку из-за устаревшего кэша;
упасть при старте, если конфиг пришел в неправильном формате.
Все вне нашего прямого контроля. Мы не можем перезапустить процесс, посмотреть лог в реальном времени, заставить пользователя обновиться. Не можем гарантировать, что новая версия приложения дойдет до всех за день.
В таких условиях надежность строится иначе. Не через реакцию на сбой, а через устойчивость к сбою, наблюдаемость, предсказуемость и гибкость . И первый шаг — переосмыслить, что вообще значит «наблюдаемость» в мире, где логов нет, а метрики собираются с задержкой.
Наблюдаемость в мобилке: не логи, а события и сценарии
Первое, подход к чему пришлось пересмотретьд, — наблюдаемость. В серверном мире все устроено понятно: логи, метрики, алерты, дашборды. В любой момент можно добавить новый лог, изменить порог срабатывания или посмотреть конкретный запрос. В мобильной среде так не получится.
Если событие не было заложено в уже выпущенные версии приложения, я не смогу задним числом добавить новую метрику в проде. Придется ждать следующего релиза, а старые версии приложения еще долго будут у пользователей и продолжат влиять на общую картину.
В мобильном банке мы опираемся на несколько уровней данных.
События приложения — это не логи, а дискретные сигналы, которые приложение отправляет в бэкенд: экран открыт, экран загружен, ошибка показана, операция начата, операция завершена. Из этих событий строятся метрики, на основе которых можно понять, сколько пользователей заходили на экран, на каких версиях приложения они сидят, где возникает деградация.
Но сами по себе экранные метрики не всегда отвечают на главный вопрос SRE: где именно ломается пользовательский путь? Для этого нужны сценарии и реперные точки. Аналитики продуктовых команд выделяют ключевые сценарии, а разработчики встраивают события в критичных точках пользовательского пути. Благодаря этому мы можем посмотреть, сколько клиентов начали перевод, сколько дошли до подтверждения, сколько получили успех, а сколько — ошибку или зависание. Это уже полноценная наблюдаемость пользовательского процесса, а не просто учет экранов.
Логи. Клиентские устройства тоже отправляют логи, но их объем и детализация ограничены. Часть особенно чувствительных компонентов, например связанных с безопасностью, логируется довольно подробно. Есть логи, которые вообще не уходят на бэкенд, а хранятся локально на устройстве. Они используются техподдержкой в отдельных случаях, когда нужно провести глубокое расследование по конкретному устройству.
Краш-репорты. Если приложение упало, мы обязаны об этом узнать. Для этого существует специальная система, куда отправляется подробная информация о падении. Для меня, как Mobile SRE, это один из самых ценных каналов, потому что многие проблемы проявляются только на определенных версиях ОС, типах устройств или при конкретных условиях работы сети и состояниях приложения.
Часть бэкенд-компонентов находится в зоне ответственности нашей команды, а часть — у других SRE. И здесь как раз помогает опыт классической эксплуатации — умение быстро локализовать, где началось отклонение: на клиенте, в сети, в бэкенде или у партнера.
Мобильный релиз — не кнопка Deploy
Еще одно важное отличие от классического SRE — релизный процесс. В привычной серверной модели все более-менее понятно: разработали, протестировали, выкатили по Canary, при проблеме откатили. В мобильной среде такой подход в лоб не работает.
Доставить приложение нужно через магазины приложений или другие каналы распространения, и это добавляет внешний контур управления. Даже если новая версия уже у пользователя, откатить ее мгновенно нельзя. А часть пользователей могут вообще не обновляться долгое время, поэтому в проде одновременно живут несколько поколений приложения.
На практике мы не можем рассчитывать на быстрый rollback как на стандартный механизм снижения риска. Вместо этого нужно проектировать систему так, чтобы она была устойчива к ошибкам релиза. Нам помогают фича-тогглы, конфигурирование с бэкендов, фолбэк-механизмы и тщательное тестирование критичных сценариев.
Идея простая: код уже у пользователя, но новая функциональность по умолчанию может быть выключена. Затем она постепенно включается на ограниченной аудитории, и мы внимательно следим за поведением системы. Такой подход резко снижает blast radius, особенно если речь идет о чувствительных операциях.
Есть еще один нюанс: сотрудники компании — первые пользователи новых функций. И это полезно, но не решает проблему полностью, потому что реальные клиенты могут неделями или месяцами не открывать приложение, а значит, у них старые версии, старые данные в кэше и совсем не те состояния, которые видит внутренний пользователь.
Перед релизом нужно убедиться не только в том, что новая функциональность работает, но и в том, что старая не сломалась, а новые изменения не ударят массово по тем, кто еще не обновился.
Когда небольшая ошибка приводит к проблемам у миллионов пользователей
Для банковского приложения надежность — не просто технический KPI. Это требования регулятора, часть пользовательского доверия и часть продуктовой ответственности.
Если мобильный банк не открывается, не проходит платеж, не показывает нужные данные или падает в критичный момент, пользователь не разделяет проблему на фронт, бэкенд и сеть. Для него это просто «банк не работает».
В финансовом приложении надежность тесно связана с требованиями безопасности и корректности операций. Ошибка в мобильном сценарии — не только неудобство, но и риск потерять транзакцию, нарушить пользовательский путь или получить неконсистентное состояние между клиентом и сервером. Поэтому mobile SRE в банке должен мыслить не только как инженер надежности, но и как владелец пользовательского сценария end-to-end.
Представим типичный сценарий: часть пользователей уже получили новую версию мобильного банка с долгожданной функциональностью. Сама функциональность может быть любой: новый экран, новый раздел, дополнительная настройка, важное для продукта изменение в логике взаимодействия. На небольшой группе пользователей эта возможность включена через фича-тоггл.
Приложение начинает обращаться к бэкенду за конфигурацией новой функции. Дальше возможны разные варианты развития событий. Бэкенд может вернуть ответ в неожиданном формате. Сетевой запрос может упасть. Конфигурационный сервис может быть недоступен. Приложение может некорректно обработать ответ. В результате часть пользователей увидят ошибку, часть — не получат новую функцию, а у части может случиться краш или сломается основной сценарий.
В такой ситуации важно быстро понять, где именно возникла проблема: в клиенте, бэкенд-сервисе, сети или зависимом контуре. Для этого и нужна вся система событий, метрик, логов, краш-репортов и межкомандной координации.
Как мы сломали iOS, пытаясь спасти Android
Поведение отдельной функции в мобильном приложении обычно настраивается с помощью конфигурационных файлов, которые загружаются клиентами по сети. А включать, выключать или менять поведение работающего приложения позволяют фича-тогглы. К моменту сбоя на части клиентов Android был включен фича-тоггл для новой функциональности, а детали его поведения определялись через конфиг-файл.
Во время вечернего дежурства проходил релиз на одном из бэкендов, который находился в зоне ответственности другой SRE-команды. После его завершения у части устройств Android с включенным фича-тогглом и текущим конфигом стал отображаться неверный экран. Мы узнали об этом от системы мониторинга — по росту определенных событий в мобильном банке.
Мы решили полностью отключить функцию, заменив ее конфиг на заглушку. Из-за архитектурной особенности такой способ отключения был значительно быстрее, чем изменение состояния фича-тоггла. Целью было вернуть систему в исходное состояние, минимизировать риски, разобраться в ситуации, внести исправления и только потом возвращаться к постепенному включению функции.
Размещение заглушки и откат релиза на бэкенде ожидаемо снизили количество событий, связанных с некорректным поведением на Android. Но одновременно с этим мы получили оповещение о резком росте крашей уже на устройствах iOS.
Оказалось, что конфиг-заглушка корректно обрабатывался на Android, но приводил к крашу на iOS из-за неочевидных различий в модуле, отвечающем за обработку этого файла. Более того, конфиг закешировался на устройствах iOS и вызывал падение при каждом запуске приложения. Это означало, что у отдельных клиентов полностью пропала возможность пользоваться мобильным банком. Например, человек мог стоять в очереди на кассе и не суметь пополнить счет, чтобы оплатить покупку.
К счастью, краши затронули только устройства сотрудников с новой версией iOS-приложения, которая еще не была доступна широкой аудитории. Так инцидент не вышел за рамки внутреннего тестирования.
Ведение сбоя завершили мои коллеги из Москвы. К этому моменту у меня заканчивалось дежурство и я передал им всю накопленную информацию.
Даже не хочется представлять, что было бы, если бы сбой затронул миллионы реальных клиентов. Сколько неудобств это могло бы им доставить. Нам пришлось бы искать и оповещать всех пострадавших, рекомендуя сбросить данные приложения или переустановить его.
Несмотря на то что инцидент затронул только сотрудников, мы провели его полный анализ и составили постмортем. Определили причины и триггер события, сформировали список задач, чтобы исключить повторение сбоя в будущем. Помимо процессных и архитектурных доработок со стороны SRE в работу включились команды разработки, тестирования и техподдержки.
Этот случай еще раз подчеркнул, насколько важно взаимодействие между всеми командами, участвующими в создании продукта. И какую роль играет распределенная SRE-команда в эффективном реагировании на сложные ситуации.
Вот так, спасая клиентов на Android от отображения одного неверного экрана, мы сломали коллег с iOS-устройствами, лишив возможности пользоваться мобильным банком.
Распределенная команда как фактор устойчивости
Мне кажется, именно распределенная структура компании делает mobile SRE в такой среде особенно эффективным.
Новосибирск — не просто региональный офис, а полноценный инженерный центр с собственной динамикой, локальными сильными командами и опытом. Это важно не только для найма или удобства сотрудников, но и для самой надежности инженерной системы.
Когда члены команды живут в нескольких городах, а работа идет сквозь часовые пояса, легче поддерживать непрерывность сопровождения. Когда рядом есть сильное локальное сообщество, проще обмениваться опытом. Когда офис становится центром притяжения, легче проводить стратсессии, ревью инцидентов, технические обсуждения и внутренние митапы.
Это уже не про удаленную работу, а про распределенную инженерную организацию с предсказуемым операционным ритмом.
Выводы
Канонические SRE-инженеры обслуживают высоконагруженные распределенные системы, применяют широкий спектр классических практик вроде Blue-Green или Canary-Delpoy, повышают наблюдаемость через Golden Signals / Red Metrics и ведут граф зависимостей текущих инсталляций.
Наша команда отличается от обычных SRE тем, что считает фронтовые приложения частью распределенных систем. Это накладывает дополнительные ограничения в виде высокой кардинальности «хвостов» старых версий мобильных приложений в вопросах наблюдаемости, специфику развертывания и дистрибьюции через магазины приложений, невозможность отката бинарных релизов и учета вендорных ограничений на всех уровнях взаимодействия с бэкендами
Mobile SRE в банке — это не просто расширение классической роли. Это работа на стыке инфраструктуры, клиента и продукта, где надежность строится:
через наблюдаемость через события и сценарии;
краш-репортинг и глубокую диагностику;
удаленное управление функциональностью через фича-тогглы и конфиги;
постепенное включение изменений;
тестирование критичных путей end-to-end;
быструю локализацию проблем между клиентом, бэкендом и сетью;
устойчивую распределенную команду.
Наш случай с конфиг-заглушкой — хороший пример: даже быстрое решение может стать источником нового сбоя, если не учитывать все слои системы. Но именно за счет распределенности, четких процессов и командной координации мы смогли быстро разобраться, минимизировать последствия и вынести реальные улучшения.
Все это часть одной системы — не только технической, но и организационной.
И в этом смысле Новосибирск для нас не просто точка на карте. Это часть архитектуры устойчивости.
Другие статьи проекта «20 в 20»: