Архитектура большой компании почти никогда не развивается по генеральному плану. Эта глава показывает более честную траекторию: как Т-Банк проходил через эпохи коробочных решений, собственного стека, платформизации и распределенного governance под давлением роста, стоимости изменений и новых ограничений.
Ценность материала в том, что он учит смотреть на архитектуру как на последовательность состояний, а не как на одну правильную конечную схему. По этой траектории хорошо видно, почему решения для стартапа, платформенной компании и мегапроекта с десятками команд принципиально различаются.
В архитектурных обсуждениях этот кейс особенно хорош как живая эволюционная история: через него легко объяснять, как масштаб бизнеса, оргдизайн и инженерные ограничения постепенно меняют приоритеты, роли и способы принятия решений.
Практическая польза главы
Эволюция платформы
Разбирает, как архитектура меняется вместе с масштабом бизнеса, оргструктурой и регуляторными ограничениями.
Migration thinking
Учит планировать переходы между архитектурными состояниями без остановки продуктовой разработки.
Платформенные инвестиции
Помогает оценивать, когда central platform окупает себя и где лучше оставить локальную автономию.
Interview realism
Дает реальные эволюционные кейсы, которыми удобно подкреплять аргументацию в интервью.
Источник
ArchDays 2024
Доклад «Архитектура в Т-Банке: вчера, сегодня, завтра» — расшифровка выступления на конференции.
История развития архитектурных подходов в Т-Банке за 18 лет: от стартапа на коробочных решениях до технологической компании с 46 миллионами клиентов и собственной платформой разработки.
Эволюция архитектуры в Т-Банке
На основе доклада Александра Поломодова на ArchDays 2024
Связанная книга
Continuous Architecture in Practice
6 принципов непрерывной архитектуры: продуктовый подход, NFR, отложенные решения
Что такое архитектура?
Перед погружением в историю важно понять, что мы подразумеваем под архитектурой. На этот счёт существует множество определений от SEI (Software Engineering Institute), IEEE, RUP и других источников. Можно выделить 7 ключевых взглядов:
Организация системы, элементов и их интерфейсов
Скрытие реализации, фокус на взаимодействиях
Элементы, взаимосвязи и свойства для размышления о системе
Governance: политики, модели, стандарты
Фундаментальные решения, дорогие для будущего
Повторно используемые подходы к построению
Согласование решений со стейкхолдерами
"Перефразируя Джорджа Бокса: все определения неправильные, но некоторые полезны."
Philosophy
A Philosophy of Software Design
Обсуждение книги Джона Остерхаута в подкасте Code of Leadership.
Ключевая метафора
❌ Строительная метафора
Редко, когда построив половину небоскрёба, заказчики решают сделать pivot и следующую половину построить горизонтально. А в IT бывает и не такое.
✓ Растительная метафора
Мы постепенно создаём большое рисовое поле: медленно достраиваем и, как в software architecture, не знаем что скрывается на дне.
Четыре фазы развития
Фазы развития архитектуры Т-Банка
2006–2014
COTS
Стартап-фаза: быстрый выход на рынок поверх коробочных решений
1. COTS (2006–2014)
Когда Тинькофф был стартапом, решения строились поверх стандартных коробок. Этот подход оптимален для быстрого выхода на рынок:
Преимущества COTS
- +Уменьшенные начальные затраты
- +Быстрое развёртывание
- +Доказанная надёжность
- +Техническая поддержка вендора
- +Регулярные обновления
TDD — Technologist Driven Development
Технологи (смесь бизнес-аналитиков и проджектов) отвечали за создание продуктов поверх коробочных систем. Не путать с Test-Driven Development!
2. Свой софт (2014–2019)
Компания активно росла, а некоторые коробки стали стоить как крыло самолёта. Геополитические изменения 2014 года усилили осознание минусов COTS:
Недостатки COTS
- −Ограниченная кастомизация — не удовлетворяет потребностям бизнеса
- −Долгосрочные затраты — лицензии на пользователя/ядра растут с бизнесом
- −Vendor lock-in — зависимость от планов вендора
- −Безопасность — популярные решения — цели для атак
- −Сложности интеграций — много middleware кода
Разрабатывать софт самому оказалось сильно сложнее, чем делать интеграции. Некоторые системы рождались, чтобы заменить коробки, но были заменены сами ещё более новыми решениями, пока изначальная коробка продолжала жить.
Spirit
Платформа Spirit
Официальная страница внутренней платформы разработки.
Фундамент
Контейнеризация
Платформенные среды часто строятся вокруг контейнеров и их оркестрации.
3. Platform Engineering (2020–2022)
К 2020 году стало ясно, что создавать свои системы весело, но неэффективно экономически. Каждая команда делала себе инфраструктуру сама — компания не экономила на масштабе.
Рост команд разработки
Инженеров на инфраструктуре
Гетерогенный ландшафт
Принципы платформы Spirit
- Повторяемость и прозрачность жизненного цикла кода
- Управление кодовой базой и оценка качества на всех этапах
- Переход к inner source в компании
- Ориентация на результат
4. Мегапроекты и Governance (2022–2025)
Геополитические изменения 2022 года ускорили движение к IDP. Стартовали два больших направления:
🔥 Проект «Прометей»
Импортозамещение: уход от Oracle и других технологических стоп-слов. Генерация огромного технического долга, который требовалось разгрести.
📈 Программа «100М»
Масштабирование под рост: x2 клиентов, больше продуктов на клиента, ежедневное использование сервисов экосистемы.
Решение
- Активное агитирование за переезд на платформенные XaaS решения
- Расширение возможностей платформ под требования масштабирования
- Эволюционное изменение систем (не революционная перестройка)
Staff+
Fundamentals of Software Architecture
Подробнее о роли архитектора и soft skills.
Кто занимается архитектурой?
Кто занимается архитектурой?
Управление процессом разработки
Проектирование + код
Проектирование и написание кода на минимально необходимом уровне
Фундамент
Виртуализация и VM
Инфраструктура и датацентры опираются на виртуализацию и гипервизоры.
Куда движется Т-Банк
Сейчас единственный путь — инвестировать в собственную технологичность:
Инфраструктура
Свои датацентры, IDP и XaaS сервисы
Децентрализация
Прокачка навыков проектирования у SDE
Зрелый подход
Здравый подход к повторному использованию
Дополнительные материалы
Связанные главы
- Continuous Architecture in Practice - показывает, как принимать решения непрерывно и сохранять скорость изменений в крупных продуктовых командах.
- Fundamentals of Software Architecture - даёт базовые архитектурные характеристики и роль Staff+/архитектора в инженерной организации.
- Как принимать архитектурные решения в эпоху масштаба - добавляет практику RFC/ADR и governance-процесс, который связывает стратегию и ежедневную разработку.
- Контейнеризация - объясняет инфраструктурную основу платформенного подхода и стандартизации окружений разработки.
- Виртуализация - помогает понять фундамент датацентров и инфраструктурных решений, на которых строится платформа.
- Infrastructure as Code - показывает, как масштабировать изменения инфраструктуры через код, ревью и воспроизводимость.
- GitOps - дополняет подход управляемыми deployment-процессами и прозрачной эксплуатацией через Git.
- Data-платформа Т-Банка - показывает, как архитектурная эволюция проявляется в больших data-направлениях и платформенных сервисах.
- ML-платформа Т-Банка - даёт ML-контекст: как платформенные и архитектурные решения переносятся в AI/ML-практику.
- Эволюция AI-ассистента в SRE Т-Банка - связывает архитектурные решения с operational-практикой, надёжностью и автоматизацией поддержки.