B2B Engineering Insights & Architectural Teardowns

Масштабирование Uber: архитектура, команды и ИИ

Когда в 2013 году Туан Фам стал первым CTO Uber, компания обрабатывала всего 30 000 поездок в день и регулярно падала. 40 инженеров поддерживали систему, построенную без расчёта на взрывной рост. За семь лет ему удалось превратить разрушающуюся архитектуру в глобальную технологическую платформу, а распределённую команду — в эффективную инженерную организацию.

От монолита к микросервисам

Первые месяцы работы Туан сравнивает с постоянным «пожаротушением». Основные системы были однопоточными и масштабировались вертикально, пока не стало ясно, что «более мощного процессора» уже не хватит. Переход на микросервисную архитектуру стал вопросом выживания. Фам ввёл простое, но ключевое требование: один сервер должен поддерживать несколько городов, а город работать на нескольких серверах. Это обеспечило горизонтальное масштабирование и дало команде год технологического запаса.

Миграция от монолита заняла два года. При темпах роста Uber каждая попытка выделить сервис оборачивалась тем, что другие команды добавляли в монолит новые фичи быстрее, чем «команда распила» успевала их выделять. Так появилось несколько тысяч микросервисов — не как архитектурное решение, а как ответ на давление бизнеса.

Разделение «программ» и «платформ»

Функциональное деление на фронтенд, бэкенд и мобильные команды перестало работать уже при 100 инженерах. Каждый новый продукт требовал переговоров между группами. Фам совместно с Трэвисом Калаником и Джеффом Холдденом переформировал структуру:

  • Program‑команды создавали конечные функции для пользователей.
  • Platform‑команды строили инфраструктуру и инструменты, поддерживающие остальных.

Это решение принесло автономность и ускорило выпуск фич — культуру «самодостаточных» команд позже переняли многие крупные компании.

Внутренние инструменты собственного производства

К 2015 году Uber упёрся в ограничения открытого ПО. Используемый PostgreSQL перестал выдерживать нагрузку, а внешней поддержки не существовало. Команда создала собственные решения: хранилище Schemaless, RPC‑фреймворк TChannel, распределённую систему мониторинга M3 и десятки внутренних сервисов.

Иногда такие разработки казались избыточными, но ключевые из них были неизбежными — экосистема просто не предлагала готовых инфраструктур, способных держать объём Uber в тех масштабах.

Запуск в Китае за пять месяцев

Знаковым примером инженерного аврала стал запуск Uber China. Задача: развернуть изолированную инфраструктуру на территории страны — за два месяца. Реалистичная оценка программы — 18 месяцев.

Инженеры переписали ядро, разделив данные и деплой, добились физического размещения сервисов в Китае и запустились через пять месяцев. Урок Фама: сложнейший объект стоит делать первым — после этого остальное идёт проще.

Командное лидерство и внутренняя культура

Фам добивался высокой «плотности таланта» и создавал среду, где инженеры могут свободно перемещаться между командами. Его принцип: «Это не тюрьма». Возможность внутренних переходов предотвратила отток специалистов и усилила дисциплину менеджеров заботиться о росте людей.

Он также требовал профессионализма — в том числе в деталях. Знаменитое письмо «Мы не Mickey Mouse shop» положило конец хаотическим названиям сервисов, которые мешали навигации по системе.

Эволюция лидера: от реактивного выживания к видению

Фам делил свой путь в Uber на три «тура службы»:

  • Стабилизация инфраструктуры.
  • Мировое масштабирование — запуск новых стран и продуктов.
  • Кризисный этап — удержание компании в турбулентные годы.

Главный вывод: CTO обязан не только чинить текущие проблемы, но и «видеть за угол» — понимать, как должна выглядеть организация через 18–24 месяца и иметь нужных людей к этому моменту.

Новый этап: Faire и роль ИИ

Сегодня Фам — CTO B2B‑платформы Faire, соединяющей производителей и розничные магазины. Там он развивает использование искусственного интеллекта. Команда применяет swarm‑coding — оркестрацию нескольких ИИ‑агентов, работающих параллельно над задачами. В некоторых группах это удвоило продуктивность. Однако, по словам Фама, настоящая сложность не в «зелёных проектах», а в интеграции ИИ в огромные наследованные кодовые базы.

«ИИ поднимает планку для всех, но великих инженеров делает ещё сильнее. Любопытство, бесстрашие и готовность учиться остаются главными критериями», — говорит он.

Что делает CTO эффективным

По наблюдению Фама, успешный технический лидер:

  • строит команду высокой плотности таланта, где культура доверия и ответственности самоусиливается;
  • формирует видение на два года вперёд и подбирает архитектуру и кадры под это будущее;
  • не застывает — «комплацентность равна смерти».

Карьерные фазы инженера

Он предлагает смотреть на карьеру как на последовательность фаз:

  • Первые 5–10 лет — максимальное обучение и сложные задачи.
  • Средний этап — поиск проектов с высоким влиянием, особенно в небольших компаниях.
  • Лидершип — передача опыта и развитие других.

Опыт масштабирования Uber показывает: архитектурные решения рождаются не из теории, а из кризиса. Масштабирование, микросервисы и платформы — лишь следствие умения команд быстро реагировать на реальный рост. Именно этот практический подход, сочетание инженерного реализма и прогнозирования, остаётся главным уроком Туана Фама для архитекторов и техлидов:

«Думайте о завтрашней нагрузке сегодня, но не забывайте, что технологии делают люди.«

Слушать подкаст — The Pragmatic Engineer

×

🚀 Deploy the Blocks

Controls: ← → to move, ↑ to rotate, ↓ to drop.
Mobile: use buttons below.