Привет, Хабр! Я Артем, групп-лид в Т-Банке. Я пришел в Т почти пять лет назад и с тех пор так или иначе всегда работал в домене «Кэшбэки» — одной из важных фич нашей экосистемы. А сегодня руковожу тремя стримами: кэшбэк-платформой, обработкой чеков для начисления кэшбэка и платформой доступности бонусных спецпредложений клиентам.
Моя статья — пятая в проекте «20 в 20» к 20-летию Т-Банка, в котором мы рассказываем об ИТ-хабах в разных городах и о людях в них. Сегодня — о минском ИТ-хабе, которому в этом году уже пять лет!
Начав в инфраструктурной команде, я прошел путь через роль SRE-лида на 20 команд, перешел в тимлидство команды разработки и дошел до руководителя нескольких команд. С каждым шагом менялся характер задач: от настройки конкретных сервисов — к выстраиванию процессов, от процессов — к работе с людьми, от работы с людьми — к работе с бизнес-результатом.
В статье делюсь тем, как менялся мой взгляд на вопрос обеспечения надежности, с чем столкнулся, чему научился и что общего между работой инженера и менеджера.
Минск — первый международный ИТ-хаб
Я пришел в минский хаб, когда он только начинал формироваться — как первый международный центр разработки в истории Т-Банка. Здесь я рос как инженер и становился частью сообщества, в котором ценят не только код, но и культуру, доверие и готовность делиться знаниями.
Мы работаем как часть единой инженерной команды компании: участвуем в развитии общих продуктов, платформ и сервисов вместе с коллегами из других городов. Активно взаимодействуем с локальными ИТ-сообществами и сотрудничаем с техническими вузами.
В Минске есть инженеры по всем ключевым направлениям: Backend, Mobile, QA, Data, SRE и инфраструктурные команды. Команды работают как над клиентскими продуктами, так и над внутренними платформами и сервисами, которые используются по всей компании.
За пять лет работы хаба у нас появилось больше возможностей в развитии внутренних сообществ и расширении продуктов, над которыми мы работаем. А еще минский хаб очень про людей. Нам удалось сохранить атмосферу взаимовыручки несмотря на рост команды: от 38 специалистов в 2021 году до 1 100 сегодня. У нас многие знают друг друга лично и готовы помочь не только по рабочим вопросам.
У нас сильное внутреннее комьюнити и за пределами офиса. Ребята регулярно собираются на партии в мафию, вместе ходят в походы, а у любителей активного отдыха даже сформировалось собственное сообщество по сплавам на байдарках.
Еще одна особенность — большое количество людей, которые работают с нами практически с первых месяцев существования хаба. Это создает ощущение преемственности и помогает сохранять культуру центра по мере его роста.
Мы очень гордимся тем, что Минск — это не только про сильную инженерию, но и про развитие людей. Через Т-Образование в команды Т-Банка за пять лет вышло больше 100 джунов из Беларуси. Многие из них сегодня выросли в уверенных специалистов, продолжают строить карьеру внутри компании и уже сами учат новичков.
Онбординг через сбой в Cassandra
Начало моей карьеры в Т-Банке совпало с формированием профессии SRE, а попал я в инфраструктурную команду Нефинансовых сервисов. Как полагается, в первую неделю я получал доступы, настраивал окружение, проходил обучающие курсы и погружался в то, чем занимается SRE. Наша команда занималась разными нефинансовыми продуктами, ну а мне посчастливилось оказаться в продукте «Выгода».
Витриной «Выгоды» является раздел «Кэшбэк и бонусы» в приложении банка, где клиент может посмотреть и воспользоваться партнерскими спецпредложениями. Мне рассказали, чем занимается проект, показали наше обилие сервисов, объяснили зоны ответственности. А потом коллега, который вместе со мной отвечал за продукт, ушел в отпуск.
Через неделю моей самостоятельной работы часов в 11 вечера мне позвонили с незнакомого российского номера. «Мошенники», — подумал я, а оказалось — мой руководитель. У нас сломалась Cassandra. Руководитель сказал: «Ты теперь отвечаешь за это. Разбирайся. Мы тебе доверяем».
В тот вечер я заонбордился по полной программе: и доступы все проверил, и взаимосвязи между сервисами изучил, и какие-то первые проблемы начал замечать. Правду говорят, что лучшее обучение — это практика
Тот момент — хороший пример, когда не поднимаешься до уровня ожиданий, а падаешь до уровня навыков. Столкновение с неожиданностью провоцирует синдром самозванца, но это нормально — чего-то не знать. По-моему, не нормально, когда ты с этим ничего не делаешь. Как у реки два берега, так и тут вариантов всего два: либо сдаться, либо идти читать документацию и решать проблему.
Я бы, наверное, не работал в Т, если бы не выбирал второй вариант. Впоследствии видел много похожих сбоев, когда сталкивались с чем-то малознакомым, помогали чинить сбои в других контекстах. Проходить мимо проблем — это не про меня и моих коллег. Чуть позже я узнал термин «проактивность» — это полезное качество что для SRE, что для менеджера.
В случае с надежностью мысль я разверну так: крепче спит инженер той команды, которая проактивно вкладывается в надежность.
От реактивного реагирования к проактивной надежности
Изначально работа инфраструктурного инженера в нашей команде подразумевала развертывание и поддержку инфраструктурных сервисов по запросам команд, автоматизацию рутинных процессов, помощь в работе с базовой инфраструктурой и консультативную помощь по вопросам надежности и обеспечения наблюдаемости.
С течением времени менялись подходы, разработчики начали больше погружаться в вопросы надежности и наблюдаемости своих сервисов, их развертывания и эксплуатации. Так совпало, что продукт «Выгода» резко начал расти: появилось несколько новых продуктов и команд. А где стремительный рост, там и куча проблем.
В тот год количество людей и команд, с которыми мы работали, выросло в 4 раза! В какой-то момент стало ясно, что при нашем интенсивном росте продукта, количества сервисов и команд все начинают потихоньку бежать разные стороны, не замечая, как часто решают одни и те же проблемы.
Некоторые сбои на разных системах происходили по очень схожим причинам. Появилось понимание, что нужно фокусно заниматься вопросами надежности. Нужно больше внимания уделять системным решениям, унификации и стандартам работы, целеполаганию в обеспечении надежности сервисов и процессам вокруг них. Так появилась роль SRE-лида, и ее предложили мне.
Работа SRE-лида в первую очередь коммуникация:
Во время сбоя — координация работ по устранению инцидента, организация работ по постмортему, постановка и контроль выполнения задач по предотвращению подобных сбоев в будущем. Blameless culture помогала: никто не искал виновного, все сосредоточены на том, чтобы решить проблему и сделать так, чтобы она не повторялась. Ошибаться не страшно — страшно не учиться.
В спокойное время — анализ узких мест, планирование масштабирования, повышение отказоустойчивости, сбор обратной связи.
Многое приходилось делать впервые, и не всегда было понятно, как правильно, поэтому принцип test and learn подошел как нельзя лучше. Я приходил к старшему коллеге с идеями: на одни он говорил «круто, давай сделаем», на другие — «уже есть, почитай». Так я рос как инженер и как SRE-лид.
За то время, пока я был SRE-лидом, удалось унифицировать процессы деплоя на все контуры, шаблонизировать описания деплойментов и организацию конфигов сервисов, ввести практику выноса метрик и проб на отдельный сервер, начали писать ранбуки, появились шаблоны досок в Grafana, чек-листы приемки сервисов на поддержку SRE, были унифицированы алерты, составлен DRP, начали работать с бюджетом ошибок.
Когда надежность становится ограничением
Последние три квартала уже в качестве ИТ-лида я занимаюсь кэшбэк-платформой — она позволяет любому продукту внутри экосистемы внедрить механику кэшбэка через несколько простых интеграций:
через Kafka — передавать объекты начисления (товары, магазины, заправки, кинопоказы и другие сущности);
через Kafka — отправлять данные о заказах для начисления кэшбэка;
через REST/gRPC — получать данные о ставках, максимальных процентах и индивидуальных предложениях для клиентов.
Интегрируясь с платформой, продукт получает инструмент вовлечения и удержания клиентов. Мы как платформа рассчитываем процентные ставки и абсолютные значения кэшбэка согласно указанным условиям акции, предоставляем возможность завести акции для своих клиентов и выполнить начисление кэшбэка на целевое действие клиента — факт совершения оплаты заказа внутри продукта.
На момент передачи в мою команду платформа уже использовалась примерно в 20 продуктах, и это число растет. Дневная пиковая нагрузка составляла ~1.2–1.3k RPS. Даже незначительное повышение вызывало деградацию времени ответа.
Система развивалась два года в режиме стартапа. Техническим долгом и оптимизациями занимались только когда «прижимало» — из-за сбоев или недовольства клиентов. Авторизация была реализована по остаточному принципу: мы не знали, кто наши потребители, какие у них сценарии, какие методы они используют. При росте нагрузки только по косвенным признакам можно было понять, кто ее генерирует.
Первая же фича, реализованная моей командой, добавила +1k RPS. Параллельно поступали запросы на новые интеграции. Собрав все запросы от потребителей и новых интеграций, мы поняли, что к концу 2026 года нагрузка может превысить 10k RPS. При этом требование к времени ответа — 100 мс по 99-му перцентилю — было в разы строже текущих показателей.
Сложилась ситуация, когда дальнейшее развитие платформы стало невозможным без экстренных мер по обеспечению надежности и масштабированию сервиса.
За полгода мы увеличили пропускную способность с 1.3k до 4.5k RPS без деградации времени ответа. В некоторых сценариях уже достигли целевых 100 мс.
Выросли за счет:
оптимизации SQL-запросов;
физического разделения данных по разным БД PostgreSQL;
отказа от Hibernate в тех местах, где он давал слишком большой оверхед;
переноса части нагрузки по чтению на реплику;
переработки кэшей с внедрением Vaulkey.
В ближайших планах — еще больше оптимизаций, рефакторинг кода с последовательными запросами в дерево запросов для параллелизации, переработка авторизации с возможностью ввода рейт-лимитов для потребителей, перевод части сценариев на работу с предподготовленными агрегатами в Cassandra.
Команда провела большую работу по изучению потребителей: задокументировала интеграции, нашла ответственных, описала бизнес-сценарии. Начали внедрять ИИ-инструменты для обработки обращений — консультаций, сопровождения, запросов на интеграцию.
Все это силами шести-семи человек, параллельно с реализацией крупных фич и жизни в новой для нас платформе с очень широким контекстом. За полгода мы пережили десятки сбоев. Но именно они помогли нам лучше понять систему и научиться быстрее реагировать.
Сейчас мы развиваем кэшбэк-платформу как настоящую платформу — с фокусом на непрерывное техническое совершенствование.
Заключение
Когда я пришел в минский хаб, не думал, что через четыре года буду рассказывать о масштабировании платформы. Но главный мой вывод — не про RPS, не про latency и даже не про отказ от Hibernate. Он про среду.
Хорошая система не появляется сама. Она растет там, где люди чувствуют доверие, где можно ошибиться, где опыт передается не по документам, а в разговорах за чашкой кофе. Где можно прийти с идеей и тебя не осудят, а спросят: «А как проверим?»
Минск — первый международный ИТ-хаб в истории Т-Банка. Мы работаем как часть единой инженерной команды компании и растем вместе с ней. Если вы ищете место, где можно расти — не только по карьерной лестнице, но и как инженер, как лидер, как человек, — возможно, стоит заглянуть в один из наших хабов. Особенно если вы не боитесь первых сбоев в 11 вечера.
Другие статьи проекта «20 в 20»: