Как устроена инженерия в Uber (Рубрика #Engineering)

После воспоминаний про былые дни в Uber от Charles-Axel Dein я заинтересовался тем, а как сейчас устроена инженерная часть Uber и собрал примерно такую информацию.

Инженерное крыло компании насчитывает 4к+ инженеров (в 2023 их было 4k) и распределено по всему миру. Инженерные команды делятся на две категории: “program” и “platform". Program команды полностью владеют своей частью продукта (как клиентской частью в приложении, так и необходимым бэкендом) и метриками его успеха. В свою очередь Platform-команды специализируются на развитиии универсальных технологических компонентов и инфраструктуры, которыми пользуются все продуктовые группы.

В 2023 году в Uber были большие перемены в IT - были созданы отдельные ветки под эти program и platform направления
- Правин Нага стал CTO по направлениям Mobility и Delivery, который курирует развитие всех пользовательских продуктов и приложений Uber с
- Альберт Гринберг стал VP по платформенной инженерии (раньше он работал VP в Azure). Он отвечает за общую техническую платформу, инфраструктуру, данные и инструменты.

Если говорить про архитектуру и инфраструктуру, то уже к 2016 году ребята распилили монолит на множество микросервисов, каждый отвечающий за свою функцию (поиск автомобилей, расчёт цены, профили пользователей, платежи, карты, уведомления и т.д.). Такая распределённая архитектура позволила командам развивать разные части системы параллельно и масштабировать их независимо. Однако она же требовала передовых решений для оркестрации, хранения данных и мониторинга - они создавали собственный "облачный" стек внутри компании. Например, в том же 2016 году ребята рассказывали как они разработали "Schemaless" - свой datastore с использованием MySQL. Дальше часть сервисов мигрировала в облака, например, Fulfillment платформа к 2021 году переехала на движок хранения в виде Google Spanner в GCP.

До начала 2023 года 95% нагрузок жили inhouse, а дальше пошел масштабный переезд в публичное облако, что было анонсировано в результатах Q1 2023 для инвесторов. Uber заключил стратегические соглашения с Google Cloud и Oracle Cloud на 7 лет, чтобы перенести свои серверные системы в облака этих провайдеров. Такой мультиоблачный подход выбран для повышения надёжности и гибкости. Кстати, в Oracle облаке они поехали на ARM-процессоры Ampere для сокращения костов и уже к 2024 году тысячи сервисов Uber мигрировали на Arm-архитектуру в Oracle Cloud, что дало выигрыш в соотношении цена/производительность и снизило зависимость от x86.

Backend архитектура построена вокруг контейнеризации и оркестратора, что позволяет разработчикам деплоить обновления сотни тысяч раз в неделю без простоев. В ходе переезда в облако Uber заменил устаревшую самописную систему деплоя (µDeploy) на новую multicloud платформу под названием “Up”. Благодаря этому к 2022 году в облако переехало 2+ mln 2 ядер, а также большинство сервисных команд абстрагировались от низкоуровневых деталей (т.е. для разработчиков деплой микросервиса теперь одинаков вне зависимости от среды: inhouse или cloud).

Развитие AI можно разделить на эпохи (подробнее в статье 2024 года):
1. Предиктивная ML (2016–2019) - упор на табличные задачи (ETA, риск, прайсинг) с XGBoost и зарождающиеся DL-кейсы (3D-маппинг, автопилот), запуск централизованной платформы Michelangelo и фичестора Palette
2. Масштабирование deep learning (2019–2023) - переход к DL как first-class citizen, унификация инструментов в Michelangelo 2.0, рост использования DL моделей (1+ mln rps)
3. Gen AI этап (с 2023) - LLM/GenAI для клиентского опыта и внутренней продуктивности, развитие LLMOps и GenAI Gateway с доступом к внешним и собственным моделям при сохранении единой платформы и MLOps-процессов.

В 2023 году компания запустила инициативу Uber AI Solutions, где предлагает своим корпоративным клиентам сервис по сбору и разметке данных для обучения моделей, а также тестированию AI-систем. А вот автономные машины Uber сам не развивает, а партнерится с внешними компаниями.

#Architecture #Management #Software #Leadership

Про Revolut (Рубрика #Business)

После изучения подхода Revolut к своей автоматизации разработки мне стало интересно, а куда они в принципе движутся, если исходить из публичных источников (в основном их же анонсов своей стратегии).

1) Куда движется Revolut (планы 2025–2027)
Компания открыла глобальный штаб в лондонском Canary Wharf и заложила инвестпрограмму на ~$13 млрд на 5 лет; целевой ориентир - 100 млн клиентов к середине 2027 года (в сентябре 2025 было 65 млн клиентов). Вектор роста: международная экспансия, продуктовые инновации, усиление B2B‑направления и партнёрства:
- Латинская Америка. В 2025 Revolut получил окончательное разрешение начать банковские операции в Мексике; в Колумбии - авторизацию на учреждение банка (первый из двух регэтапов).
- Индия. Официальный запуск в 2025 с интеграцией UPI; публичная цель - 20 млн пользователей к 2030.
- Западная Европа. Открыт региональный хаб в Париже и объявлена программа инвестиций €1,1 млрд на 3 года; подача заявки на французскую банковскую лицензию.
- Великобритания. В 2024 получили статус authorised with restrictions (стадия mobilisation); формальный запуск UK‑банка планировался в 2025.

2) Оргструктура и как устроена разработка
- Корпоративное управление. Совет директоров из 8 человек: председатель, 2 исполнительных директора и 5 независимых НЕД; работа ведётся через 4 комитета (аудит, риск/комплаенс, вознаграждения, назначения).
- Инженерия через "скводы" и "владение продуктом". Revolut работает маленькими кросс‑функциональными командами (типично 6–8 человек). Product Owner управляют командами как "локальные СЕО", что даёт end‑to‑end ответственность (в компании ~150 таких product owners)
- Масштаб ИТ. 1.3k инженеров, 1. 2k микросервисов, 1. 1k БД; платформой DevOps управляет команда ~15 инженеров благодаря высокому уровню автоматизации (централизованный каталог систем, self‑service пайплайны).
- Инженерная культура. Явная ставка на "качество в руках разработчиков": нет выделенного QA, инженеры сами пишут тесты, мониторят и эксплуатируют свои сервисы.

3) Архитектура и инфраструктура
- Размещение в облаке. Бэкенды и веб‑фронты хостятся в сертифицированных дата‑центрах Google Cloud; развертывание - Kubernetes (GKE), также используется Compute Engine. В 2025 объявлено углубление многолетнего партнёрства с Google Cloud под рост до 100 млн пользователей.
- Бекенд стек. Компания официально называет: Java 21, PostgreSQL (через jOOQ), Redis, Docker/Kubernetes, Google Cloud; архитектурные подходы - DDD, CQRS, TDD.
- Веб‑стек (2021 год). React + TypeScript, Redux, Rush (монорепо), TeamCity (CI/CD), Sentry; автоматические деплои на GKE.
- Микросервисы и события (2020 год). Широкое применение event‑driven архитектуры и собственная шина событий EventStore/EventStream

4) AI/ML: роль и приоритеты
- Клиентские и операционные ассистенты. Revolut официально сообщало о 2 gen AI‑ассистентах, а в 2024 анонсировали новый consumer‑AI‑ассистент и линейку "умных" сервисов (включая пилоты по ипотеке/банкоматам).
- Финансовая безопасность и эффективность. В годовом отчёте за 2024 - $800+ млн потенциального мошенничества предотвращено (оценка).
- Инфраструктурный AI. Расширение партнёрства с Google Cloud и использование Gemini и ML‑сервисов для фрода, персонализации
- Внутренние планы 2025. Компания исследует AI‑агентов для автоматизации продаж и поддержки, а также строит собственных агентов

Если обобщить, то ситуация примерно такая
- Revolut целенаправленно масштабируется глобально (ЛатАм, Индия, Западная Европа) с опорой на лицензирование и локальную инфраструктуру.
- ИТ‑модель - автономные продуктовые команды + небольшие платформенные команды, высокая степень стандартизации и автоматизации разработки
- Техстек - cloud‑native поверх Google Cloud Platform, на беке Java/Postgres/Redis, Kubernetes; на фронте React/TypeScript; ключевые паттерны - микросервисы, событийность, DDD/CQRS.
- AI в приоритете: от ассистентов до фрода и персонализации, с заметным влиянием на метрики безопасности и поддержки.

#Software #Engineering #Management #Architecture #Processes

[1/2] From Predictive to Generative - How Michelangelo Accelerates Uber’s AI Journey (Рубрика #PlatformEngineering)

Когда я изучал как устроена инженерия в Uber, я наткнулся на отличную статью с разбором эволюции ML/AI платформы Michelangelo. Мне показалось интересным отдельно рассказать про все три этапа эволюции платформы, какие у них были предпосылки, что получилось в итоге, а также что можно почерпнуть себе, если вы тоже делаете платформы в своих компаниях.

Ну и начать стоит с того, что в Uber машинное обучение (ML) уже много лет играет ключевую роль практически во всех аспектах бизнеса - от прогнозирования времени прибытия (ETA) и подбора водителя до ранжирования ресторанов в Uber Eats и выявления мошенничества. Для поддержки такого широкого применения ML Uber в 2016 году создала централизованную платформу Michelangelo (вот рассказ от 2017 года об этом), охватывающую весь жизненный цикл ML-моделей - от подготовки данных и обучения до деплоя и онлайн-инференса. Дальше платформа росла и развивалась, пройдя следующих три этапа эволюции

1️⃣ Predictive ML-платформа (2016–2019)
Фокус: табличные данные, модели типа XGBoost, классические predictive задачи: ETA, ценообразование, риск, антифрод.
Запуск Michelangelo 1.0 как централизованной ML-платформы:
- Единый Feature Store для повторного использования фичей,
- Стандартизованные пайплайны обучения/деплоя,
- Инструменты для мониторинга и дебага моделей.
Цель: перестать собирать ML-инфру в каждой команде как с нуля

2️⃣ Deep Learning & Michelangelo 2.0 (2019–2023)
Первая версия была хорошо, но требовалось порешать новые проблемы
- Deep learing начал давать выигрыш по качеству в high‑impact задачах, а платформа его плохо поддерживала
- Моделей и команд много, инструменты фрагментированы.
- Нет единого взгляда на качество моделей и приоритеты.
Ключевые изменения:
- Michelangelo 2.0: единый продукт вместо зоопарка тулов.
- Встроенная поддержка deep learning (GPU, distributed training, PyTorch/TensorFlow и т.д.).
- Добавлены следующие возможности
-- Model Excellence Score - сквозная метрика качества модели (от обучения до продакшена),
-- Tiering (Tier‑1…Tier‑4) для приоритизации ML-проектов по бизнес‑ценности.
-- Canvas / "model iteration as code": monorepo для ML, шаблоны ML-приложений, CI/CD для моделей, нормальные code review и reproducibility.

3️⃣ Generative AI и LLMOps (2023+)
После появления LLM надо было добавить в Michelangelo слой для generative AI:
- GenAI Platform / GenAI Gateway:
- Единый интерфейс к внешним и внутренним LLM (OpenAI, Llama2 и др.),
- Централизованный контроль доступа, логирование, cost‑контроль, безопасная работа с данными.

Michelangelo решили расширить до end‑to‑end LLMOps:
- Хранение и версионирование LLM,
- Репозиторий и version control для prompt’ов,
- Инструменты оценки качества и A/B-тестов LLM.

Технологический стек был выбран следующий: Hugging Face, DeepSpeed (model parallelism), Ray для распределённых вычислений и масштабирования GPU.

В следующем посте расскажу об уроках, что можно извлечь из этой истории об опыте Uber.

#Architecture #Engineering #Management #ML #AI #Software #Leadership #DistributedSystem #SystemDesign

[2/2] From Predictive to Generative - How Michelangelo Accelerates Uber’s AI Journey (Рубрика #PlatformEngineering)

Продолжая рассказ про ML-платформу Michelangelo хочется поделиться уроками, что можно извлечь из рассказа про 8 лет ее эволюции и развития внутри Uber. Вдруг вы тоже планируете делать свою платформу:)

1. Централизованная ML-платформа
Для средних и больших компаний централизация значительно повышает эффективность разработки ML-моделей, избавляя от дублирования и позволяя внедрять стандарты повсеместно. В Uber оргструктура выглядела так: сильная центральная ML Platform team + встраивание ML-инженеров и data scientist’ов в продуктовые команды. Это позволило совместить экспертизу платформы с глубоким знанием домена продукта

2. Единый и гибкий UX
Кто-то любит интерфейсы “point-and-click”, а другие предпочитают всё делать кодом. Но для платформы важно предоставить обе возможности в рамках единого платформенного опыта: UI-инструменты для визуализации и быстрого прототипирования, а также возможность полноценно работать через код (API, конфигурации, Git). В Uber эта дуальность была критичной для принятия платформы разными командами. Причем разные режимы существуют совместно и платформа синхронизирует изменения, будь то через UI или код, обеспечивая согласованность и version control

3. Высокоуровневые шаблоны + доступ к низкоуровневым компонентам
Платформа обеспечивает эффективность за счет предоставления high-level абстракций (шаблоны типовых ML-пайплайнов, авто-настройки, готовые интеграции) для большинства пользователей. Но для продвинутых команд нужно обеспечить доступ к низкоуровневым компонентам для кастомизации. Именно так сделано в Michelangelo 2.0: большинство используют готовые workflow templates и стандартные конфигурации, а power users при необходимости "спускаются" на уровень кастомных pipelines, встроенных в общую систему.

4. Модульная архитектура и открытость
Модульность позволяет компонентам платформы развиваться и масштабироваться независимо друг от друга. Plug-and-play дизайн позволяет быстро внедрять state-of-the-art технологии из open-source или сторонних сервисов по мере их появления. Uber держит фокус на основном пользовательском опыте, но технически может подключать лучшие решения для оркестрации, хранения данных, вычислений и т.д., не ломая общий продукт. Uber предпочитает открытые решения там, где это возможно, но использует и облачные модели, внимательно оценивая косты

5. Осознанное применение Deep Learning
Продвинутые методы вроде DL способны решать очень сложные задачи, но требуют огромных ресурсов и инфраструктуры, что должно быть оправдано бизнес-ценностью. Поэтому архитектура поддерживает разные типы моделей, а выбор делается прагматично. Для команд, планирующих внедрять DL, важно заранее обеспечить поддержку масштабируемого обучения (GPU/TPU, distributed training) и продумать мониторинг продуктивности моделей, так как обслуживание DL в продакшене сложнее и дороже обычных моделей.

6. Приоритизация ML-проектов
Не все модели равны - какие-то напрямую влияют на ключевые метрики бизнеса, другие играют вспомогательную роль. Вводите систему приоритетов (tiers) для ML-проектов, чтобы рационально распределять ресурсы и требования к надежности. Опыт Uber показывает эффективность четкого разделения
- Критичные (tier-1) модели получают максимальный уровень поддержки, мониторинга, строгие процессы деплоя
- Низкоприоритетные экспы (tier-4) могут обслуживаться по упрощенной схеме, предоставляя командам свободу творить, но без расходования чрезмерных ресурсов.

Итого, кажется, что Michelangelo показал путь эволюции платформы для успешного масштабирования AI в крупной компании. Секрет успеха - в постоянном улучшении опыта разработчиков, стандартизации процессов и гибкой архитектуре, готовой к новым технологическим веяниям.

#Architecture #Engineering #Management #ML #AI #Software #Leadership #DistributedSystem #SystemDesign

Сегодня узнал, что визы в Португалию уже готовы. Блиц, блиц - скорость без границ - визовый центр сделал их как раз к плановому возвращению из Португалии:)

WebSummit Lisbon (Рубрика #Conference)

В начале лета мы с женой сгонять на WebSummit в Португалию и купили early-bird tickets. Дальше мы купили билеты на самолет, забронировали отель и подали визу. Сегодня ночью мы должны были вылетать, но ... визовый центр Португалии вместе с консульством не смогли за четыре с половиной месяца рассмотреть заявление на визу и ответить да/нет. Правда, полторы недели назад нам пришлось забрать паспорта для полета на Мальдивы с детишками, но нам сказали вернуть паспорта 5 ноября обратно в визовый центр, чтобы успеть получить штампики 7 ноября. Сегодня 7 ноября, все сроки возврата по билетам и брони прошли, а паспортов нет ... В итоге, поездка на WebSummit сорвалась, денег не вернуть, настроение испорчено. Я отношусь к этому философски - примерно по этой же схеме мы с женой и детьми уже год ждем визу в Канаду, где тоже не могут ответить да/нет, правда, там электронная виза и паспорта не забирают.

В общем, летать походу надо в страны Глобального Юга, а не в те, где тебя мурыжат с визами ... иначе ты играешь в какую-то рулетку с непредсказуемым итогом.

#Conference

[1/2] Про Nubank (Рубрика #Business)

После изучения истории Lucas Cavalcant (distingueshed engineer @ Nubank) про развитие разработки в Nubank мне стало интересно, а какая у них глобальная стратегия и как IT поддерживает эту стратегию. В принципе, при текущем развитии технологий поиска и особенно перевода узнать это не составило труда (я не знаю португальский, но зато его знаю LLM).

В феврале 2025 года Nubank рассказывал про такую стратегию из трех актов

1️⃣ Лидирующая розничная банковская сеть в Латинской Америке.
Nubank стремится построить крупнейший и самый любимый розничный банк в ЛатАм за счёт масштабирования клиентской базы и повышения лояльности. Уже в 2024 году Nubank достиг Net Promoter Score 84 среди клиентов с высоким доходом в Бразилии, что свидетельствует о высоком уровне удовлетворенности. В Бразилии Nubank стал третьим по количеству клиентов финансовым институтом страны, активно привлекая новые сегменты (например, запуск премиальной программы Ultravioleta для состоятельных клиентов).

2️⃣ Выход за пределы финансовых услуг
Компания расширяет продуктовый портфель за рамки классического банкинга, создавая экосистему сервисов. В 2024 году Nubank запустил новые услуги: NuTravel – встроенный сервис планирования путешествий, и NuCel – виртуального мобильного оператора. Эти инициативы расширяют адресный рынок Nubank и повышают вовлечённость клиентов. Например, маркетплейс Nubank за 2024 год привлёк свыше 1 млн покупателей. Такие сервисы дополняют банковские продукты и удерживают пользователей внутри экосистемы Nubank.

3️⃣ Глобальная модель цифрового банка, управляемого AI
Nubank объявил целью стать глобальной AI-ориентированной банковской платформой, активно внедряя искусственный интеллект для повышения эффективности и персонализации продуктов. Это подразумевает, что AI будет лежать в основе как клиентского опыта, так и внутренних операций Nubank. Например, компания инвестирует в генеративный AI для клиентского сервиса и персонализированных финансовых советов. Например, летом 2024 года Nubank купил стартап Hyperplane, что специализируется на foundation models (базовых больших моделях) по финансовым данным и позволяет обучать сотни моделей на первичных данных банка (first-party data) для разных задач - риск, коллекшн, маркетинг и др.

Если говорить про инженерное крыло, то в августе 2025 года случилась перестановка - новым CTO стал Eric Young, ветеран отрасли (экс-VP Engineering Snap, Google, Amazon) с опытом масштабирования инфраструктуры для сотен миллионов пользователей. CTO определяет техническую стратегию Nubank, включая архитектуру, платформенные инвестиции и внедрение инноваций (например, AI). До прихода Янга CTO обязанности выполнял Витор Оливейра, который проработал в компании 10 лет. Кстати, в продолжении я расскажу про тезисы Витора об инженерии в Nubank из подкаста "Hippsters Ponto Tech #459".

#Software #Engineering #Management #Processes

[2/2] Про Nubank (Рубрика #Business)

Продолжая рассказ про Nubank, я хотел кратко изложить тезисы Витора Оливейра, который рассказывал про технологии в Nubank в подкасте "Hippsters Ponto Tech #459" (правда, подкаст на португальском) в апреле 2025 года, а уже в августе 2025 года его сменил Eric Young (экс-VP Engineering Snap, Google, Amazon), что, как по мне, дало ясный знак инвесторам на то, что Nubank готов масштабировать свою инженерную ветку для глобальной экспании, о которой было рассказано в предыдущем посте.

1️⃣ Тесты как “первая линия обороны” Nubank
- В Nubank большой фокус на тестировании: юнит-тесты, интеграционные, multi-service-тесты и эксперименты с genAI генерацией тестов
- Обоснование в том, что для крупного финтеха это не “nice to have”, а "must have", чтобы защитить чувствительные финансовые данные клиентов и держать высокую планку по стабильности, безопасности и приватности

2️⃣ Эволюция архитектуры: от JVM-стека к cloud-first
- Исторически Nubank строился вокруг JVM-стека (Clojure + Kafka), что задавало определённый стиль архитектуры и инженерной культуры (подробнее про историю можно глянуть в посте "10 years of engineering at Nubank")
- Сейчас у ребят стратегия cloud-first, но не "cloud at any cost": они осознанно балансируют между облаком и on-prem, учитывая три критерия: стоимость, контроль и сущность бизнеса

3️⃣ Ключевые инженерные принципы
Витор подчеркнул фундаментальные принципы, которые направляют технические решения
- Иммутабельность - immutable инфраструктура и сервисы
- Стандартизация - однообразие подходов вместо зоопарка технологий
- Continuous Delivery - непрерыная поставка и безопасные релизы
- Минимизация сложности - сознательное сопротивление "архитектурному энтузиазму", который раздувает систему

4️⃣ Компания как система - это не только про технологии
- Nubank смотрит на себя как на целостную систему, где культура и люди не менее важны, чем код и кластеры
- Важно уметь масштабировать команды и процессы под глобальное развитие (новые рынки, разные регуляции, распределённые команды), а не просто "накидывать микросервисы"
- Витор упоминает Conway’s Law: как структура коммуникаций влияет на архитектуру, и почему без правильного оргдизайна хорошую архитектуру не получить

5️⃣ Generative AI - осторожный, прагматичный подход
- Nubank уже использует gen AU, но очень аккуратно: они не гонятся за хайпом, а ищут конкретные, измеримые проблемы, где ИИ реально улучшает эффективность
- У ребят есть отдельные бюджеты и команды, которые экспериментируют с AI-подходами в тестировании и других задачах, системно отсеивая то, что “не взлетает”.
- Главный фильтр: безопасность и приватность данных

6️⃣ Главная мысль выпуска примерно такая
Зрелый финтех строится не вокруг модной технологии, а вокруг
- Строгой инженерной дисциплины (тесты, стандарты, CD)
- Осознанных архитектурных решений (JVM-ядро, cloud-first, но с пониманием ограничений)
- Системного взгляда на организацию и культуру
- Осторожного, прагматичного внедрения AI, где безопасность и ценность важнее демонстраций "магии"

P.S.
Интересно потом будет сравнить эти тезисы Витора с выступлениями Eric Young, нового CTO, что вышел только в конце лета.

#Software #Engineering #Management #Architecture #Processes #SRE #DevOps #Leadership

How high are OpenAI’s compute costs? Possibly a lot higher than we thought (Рубрика #AI)

Всегда интересно считать деньги в чужом кармане, но ещё интереснее, когда эти расчеты позволяют оценить сходимость текущей волны хайпа вокруг AI. Собственно, Financial Times так и сделало, написав статью по мотивам разбора Эда Зитрона, который собрал данные о счетах OpenAI в Azure. В статье FT авторы попытались оценить реальные расходы на inference и получить комментарии от обоих компаний: OpenAI и Microsoft.

Если описывать основные тезисы статьи, то
- Речь идет только про косты на inference, а стоимость тренировок LLM тут не учитывается. А значит это про операционные расходы на обработку запросов пользователей через UI и через API. А capex - это как раз про тренировки
- За 7 последних кварталов OpenAI мог потратить на inference в Azure более $12,4 млрд при оценке выручки около $6,8 млрд. Значит каждый заработанный доллар стоит примерно 2 доллара компании
- За первые 6 месяцев 2025 года inference якобы съел почти $5 млрд, при выручке порядка $4,3 млрд и ранее озвученном “общем” cash burn в $2,5 млрд за тот же период. Выходит, одна только работа моделей стоит дороже, чем официально признаётся весь кост.
- Сложность оценки обуславливается финансовыми взаимоотношения OpenAI с Microsoft, что напооминают рекурсию. OpenAI, по сообщениям, отдаёт до 20% выручки Microsoft, а Microsoft, в свою очередь, делится частью доходов Azure/Bing с OpenAI. Получается замкнутая схема, где деньги бегают по кругу, а стороннему наблюдателю остаётся только гадать, где там настоящая маржа.
- Microsoft и OpenAI числа жёстко не опровергают. FT показали им сглаженные оценки: ответ был в стиле “цифры не совсем точные”, но без альтернативных расчётов.
- Если просто экстраполировать тренд, то где-то к 2033 году суммарная выручка только начнёт покрывать одни inference‑расходы. А если учесть ещё и долю Microsoft - в каких‑то сценариях она их не покрывает вообще.

В итоге, в текущих условиях сходимость бизнес-модели под вопросом, а когда ситуация поменяется - пока не ясно.

#AI #Economics #Management #Future #ML

9 лет в Т-Банке

Очередные 365 дней в компании прошли для меня увлекательно. Ровно год назад я рассказывал как все для меня начиналось в Т и что удалось сделать за 8 лет. Но планы из прошлого года реализовались не полностью - в этом году у нас происходили и происходят очередные трансформации, где с бизнес точки зрения мы перешли от отдельных продуктов к потребностям и сегментам, а технически мы идем в сторону деления на product и platform engineering (чем-то напоминает подход к инженерии в Uber). Эти интересные изменения должны помочь нашей компании взять новые вершины, ну а я попробую помочь всему этому в меру своего разумения.

#Management #SelfDevelopment #Engineering #Processes #Software

Netflix's Engineering Culture (Рубрика #Engineering)

Посмотрел подкаст про инженерную культуру Netflix, где Элизабет Стоун, технический директор компании, делилась своими мыслями (в Netflix 3.5к инженеров и это 25% сотрудников компании). Последние информацию про культуру Netflix я получал из интересной книги "No Rules Rules. Netflix and the Culture of Reinvention", но с тех пор утекло много времени и мне было интересно, а что изменилось с тех времен.

Главный принцип - свобода и ответственность остался все тем же: инженерам доверяют самостоятельное принятие решений без бюрократии, а взамен - полная ответственность за результат. Такая модель невозможна без сильной команды: Netflix стремится нанимать только лучших специалистов и ожидает выдающихся результатов от каждого. Благодаря этому решения принимаются на том уровне иерархии, где достаточно знаний и компетенций (уровне людей и их команд). Ошибки рассматриваются как возможность роста, а не причина для блейма. Проблемы обсуждаются открыто и это укрепляет систему и снижает риск повторения сбоев. В Netflix культивируется культура откровенности: ожидается прямота от каждого, а руководство демонстрирует максимальную прозрачность. Такая открытость формирует атмосферу доверия.

Если перечислять основные инженерные принципы, о которых упоминала Элизабет, то они такие
- Непрерывная обратная связь вместо performance review. Netflix отказался от ежегодных формальных оценок сотрудников. Вместо этого поощряется постоянный честный фидбэк и открытый диалог. Ежегодный опрос 360° служит лишь подстраховкой, выявляя проблемы, не всплывшие в ежедневном общении. Такой подход позволяет сразу корректировать курс, не дожидаясь формальных полугодовых аттестаций.
- Keeper Test. Руководители задают себе вопрос вида, "а стал бы я бороться, чтобы удержать этого сотрудника, если он решит уйти?". Если ответ "нет" - пора откровенно обсудить с подчиненным ситуацию. Это помогает держать высокую планку и вовремя расставаться с теми, кто не соответствует культуре.
- Автономия инженеров. Инженерам Netflix предоставлена широкая свобода действий: они самостоятельно принимают технические решения без многоуровневого согласования. Это ускоряет работу и повышает личную ответственность за результат. Даже в рискованных проектах (например, прямые эфиры) команды действуют автономно, полагаясь лишь на минимальные guardrails для снижения рисков.
- Обучение на ошибках. Каждая неудача - повод для анализа и улучшения. Ребята практикуют подход с blameless postmortems, плюс они были пионерами chaos engineering, создав инструмент Chaos Monkey
- Высокая планка найма. Netflix традиционно привлекает только опытных, сильных инженеров, предлагая им конкурентную оплату труда. От каждого нового сотрудника ждут, что он усилит команду и привнесет свежие идеи. Но Netflix отказалась от практики найма только senior и начала брать выпускников, что привело к появлению отдельных должностей для инженеров разного уровня (что сильно отличается от прошлого подхода компании). Но даже при таком найме они стараются практиковать практику, что каждый новичок должен поднимать планку, а не просто заполнять вакансию.

Если обобщать все выступлении, то в Netflix сильная инженерная культура, что строится на доверии, высоких стандартах и готовности учиться на ошибках. Не каждая команда может полностью отказаться от формальных процессов, но ключевые принципы - честный и быстрый фидбэк, автономия талантливых сотрудников, прозрачность лидеров и непримиримость к посредственности - универсальны.

#Culture #Management #Leadership #Processes #Engineering #Software

State of Devops Russia 2025 (Рубрика #Devops)

Несколько дней назад были опубликованы результаты большого опроса про состояние DevOps в России. Наступили выходные, я его дочитал и решил написать тезисный разбор. Кстати, если этот разбор понравится, то можно его сравнить с глобальным DORA отчетом за 2025 год, о котром я уже писал. Но вернемся к этому опросу

- Производительность команд выросла: суммарная доля высокоэффективных команд (профили Elite и High) увеличилась на 6% по сравнению с прошлым годом, и ключевые показатели эффективности (частота релизов, скорость доставки, время восстановления, процент неудачных изменений) улучшились. Напомню, что в стандартном подходе все компании бьются на 4 кластера: low, medium, high, elite на основе 4 метрик DORA (deployment frequency, lead time for changes, change failure rate, mean time to restore).
- DevEx дает эффект: у высокоэффективных команд налажены быстрые и качественные циклы обратной связи, ниже когнитивная нагрузка и выше автономность инженеров (подробнее про модель DevEx я уже писал)
- Гибридная модель потребления: оркестраторы рабочих нагрузок не используют только ~15% опрошенных, остальные предпочитают c отрывом K8s (~51% разворачивают его on-prem, ~25% гибридно, еще 25% в облаке или нескольких). Данные треть хранит on-prem, треть гибридно, а треть в облаке.
- Повышение использования IDP: внутренние платформы разработки превращаются в обязательный атрибут крупных компаний с активной разработкой. Более 45% респондентов уже используют IDP для управления доступами и поиска необходимой информации. Главная цель развития внутренних платформ на 2025 год – максимальная автоматизация рутинных задач. Крупный бизнес рассматривает IDP как способ унификации процессов разработки и усиления контроля безопасности
- Информационная безопасность стала приоритетом: большинство команд теперь интегрируют её в процессы разработки (77% используют инструменты ИБ)
- Инструменты AI получили массовое распространение: ~71% опрошенных говорят, что применяют AI/ML в работе (чаще всего для генерации кода), при этом более половины уже отмечают рост продуктивности благодаря AI
- Продолжается импортозамещение: растёт использование российских OS и K8s-дистрибутивов вместо зарубежных аналогов
- Ситуация на рынке труда для devops инженеров изменилось: hh-индекс конкуренции (отношение резюме к вакансиям) вырос с 7,7 до 14,9 за год, то есть на одну позицию претендует больше инженеров

Исследование State of DevOps Russia 2025 проведено командой «Экспресс 42» (консалтинговое подразделение компании Flant) и стало пятым ежегодным отчётом о развитии DevOps в России. В опросе участвовало более 3300 специалистов из России и стран СНГ. Респонденты представляли широкий спектр отраслей и ролей в ИТ - среди них были как инженеры и DevOps-специалисты, так и руководители разных уровней из крупных, средних и небольших компаний. В общем, результаты можно с достаточной уверенностью считать репрезентативными для оценки текущего состояния DevOps практик.

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment

Postcriptum State of Devops Russia 2025 (Рубрика #Devops)

Отдельно поделюсь заключительной частью этого отчета, в которой приведена цитата Димы Гаевского, моего друга и коллеги, который у нас отвечает за развитие нашей внутренней платформы разработки.

Российский рынок ПО продолжает идти своим, местами парадоксальным путём: с одной стороны — жёсткое внешнее давление, с другой — необратимое взросление ИТ-ландшафта. В XL-сегменте тренд на интеграцию AI в производственные конвейеры только усилился. «Бигтехи» уже отстроили безопасные внутренние платформы, а теперь метят в AIOps и GenAI-копилотов, выжимая из DevOps максимум продуктивности. Но важно помнить, что даже крупнейшие игроки по-прежнему остаются «догоняющими» по
сравнению с США и Китаем — разрыв бюджетов и доступ к современным GPU остаются вопросом как минимум ближайших двух лет.

Средние и мелкие компании, пережившие кадровую турбулентность 2022 года, решали задачи автономно и почти поголовно выбрали проверенный OSS-стек — GitLab, Ansible, ELK, Kubernetes. Это был единственный рациональный путь на фоне дефицита зрелых российских предложений и высокой технологической неопределённости. Теперь же, когда регуляторика импортозамещения ужесточилась (реестр ПО, квоты в госзакупках, совместимость с «Альт»/Astra), к этому стеку постепенно добавляются отечественные надстройки — от SCA-плагинов с ГОСТ-крипто до репозиториев кода типа GitFlic.

Безопасность стала отдельным фронтом: массовый self-hosting GitLab без выстроенных процессов патч-менеджмента законсервировал множество уязвимостей. Компании начинают вкладываться в SBOM и DevSecOps, чтобы закрыть регуляторный и репутационный риск. Одновременно растёт популярность FinOps: стоимость GPU-кластеров растёт быстрее, чем ROI по экспериментальным AI-проектам, и советы директоров всё чаще спрашивают не «сколько мы натренируем моделей», а «сколько рублей мы сэкономим».

Аппаратные ограничения ощутимы: top-tier NVIDIA/AMD по-прежнему под экспортным контролем, китайские ASIC — решение рабочее, но ставит потолок производительности. Это подталкивает XL-компании к «федеративным» альянсам: банки и ритейл делятся дообученными LLM, промпредприятия — моделями предиктивного обслуживания; государство выступает ранним якорным заказчиком и субсидирует разработки, но объёмы субсидий пока несравнимы с глобальными CAPEX.

Прогноз на ближайшие годы — без паники, но и без иллюзий. Крупные продолжат апстримить AI-инновации и строить FinOps-офисы, страхуя TCO. SMB останутся на OSS-ядре, однако вынужденно потратятся на DevSecOps и аутсорс-SOC. Консолидация усилий пойдёт в двух плоскостях: горизонтальные коалиции гигантов для обмена моделями и вертикальная «надстройка» отечественных решений над универсальным OSS. В результате рынок получит не «западный стек против российского», а гибрид «OSS-база + локальные специализированные модули», что, пожалуй, и есть самый реалистичный сценарий 2025 – 2027 годов.

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment

[1/2] Китайская модель. Почему Китай отставал от Запада, а теперь его обгоняет (Рубрика #Economics)

С большим интересом прочитал книгу Владимира Попова, доктора экономических наук, профессора и специалиста по вопросам экономического развития и переходных экономик. Попов долгое время работал в ведущих научно-исследовательских центрах как в России, так и за рубежом. Он зарекомендовал себя как эксперт в области сравнительного экономического развития. Попов особенно прославился исследованиями причин успехов и неудач разных моделей развития - от «шоковой терапии» и постепенных реформ в постсоциалистических странах до феномена восточноазиатского экономического чуда. Его новая книга о «китайской модели» фактически стала итогом многолетнего изучения этой темы, опирающегося и на академические данные, и на личный опыт автора (Попов часто посещал Китай, свободно владеет несколькими языками, включая китайский).

Главная мысль книги - понять истоки и особенности феноменального рывка Китая и Восточной Азии в целом и оценить, насколько "китайская модель" развития конкурентоспособнее западной либеральной модели. Для этого Попов формулирует три ключевых вопроса, вокруг которых строится повествование
1️⃣ Почему Китай (и вслед за ним другие восточноазиатские страны, исторически опиравшиеся на китайскую цивилизационную модель) в XVIII–XIX веках существенно отстал в развитии - не только от стран Запада, но и от некоторых других развивающихся регионов? Что помешало Китаю в ту эпоху угнаться за Европой?
2️⃣ Как получилось, что с середины XX века именно Восточная Азия стала единственным крупным регионом, которому удалось стремительно сократить разрыв с Западом по уровню экономики? Иными словами, что особенного в политике и экономической стратегии Китая и его соседей (Япония, Корея, Тайвань и т.д.), раз они из аутсайдеров превратились в мировых лидеров?
3️⃣ Является ли нынешняя китайская социально-экономическая модель - основанная на приоритете общественных интересов над частными, на так называемых "азиатских ценностях" - более жизнеспособной и конкурентной, чем либеральная западная модель? И чем в перспективе завершится соперничество этих двух систем?

Ответы на эти вопросы автор дает в 6 частях, название которых позволяет оценить направление мысли автора

Часть I. «Почему Запад разбогател раньше Китая, и почему Китай теперь догоняет Запад?» - Историческая ретроспектива периода примерно с XVI по начало XX века, когда произошёл знаменитый "великое расхождение": Европа ушла вперёд, а Китай остался позади
Часть II. «Только социализм спасёт Китай? После революции 1949 года» – о периоде маоистского Китая. После основания КНР в 1949 году страна пошла по социалистическому пути. Здесь разбирается, каких успехов и ошибок достиг Китай во время правления Мао Цзэдуна
Часть III. «Только капитализм спасёт Китай? После 1979: почему Китай ускорился при переходе к рынку, а Россия замедлилась» - центральная часть книги, посвящённая реформам Дэн Сяопина и последующим десятилетиям быстрого роста. Здесь детально разбирается, как Китай внедрил элементы рынка в плановую экономику и добился скачка
Часть IV. «Только демократия спасёт Китай?» - отход Китая от экономики к политическим и институциональным аспектам (примерно современный период, рубеж XX–XXI вв.)
Часть V. «Только Китай спасёт капитализм? 20 лет вперед» - заключительный раздел, смотрящий в будущее. Здесь рассматривается глобальная перспектива: каким может стать мир в ближайшие десятилетия, если китайская модель продолжит набирать влияние.

В общем, книга получилась очень инетерсной и я читал ее в бумаге, чего и вам рекомендую.
А в следующем посте расскажу про шестиэтапную модель развития Китая по Попову и что можно из нее извлечь другим странам.

#Economics #Strategy #Processes #History #PopularScience

[2/2] Китайская модель. Почему Китай отставал от Запада, а теперь его обгоняет (Рубрика #Economics)

Продолжая рассказ про китайскую модель развития, расскажу про шестиэтапную модель развития Китая по Попову

1️⃣ Политическая и социальная стабильность
Создание сильной центральной власти, единства страны и базового равенства (недопущение крайних форм неравенства) - то, что Китай реализовал после потрясений первой половины XX века, установив жесткую государственную систему и порядок

2️⃣ Мобилизация инвестиций
Обеспечение чрезвычайно высокой нормы накопления - государство изымает и концентрирует значительную часть прибылей в бюджете и направляет их на централизованные инвестиции в развитие. Исторически это происходило, например, через коллективизацию и госрегулирование при Мао, позволившие направить ресурсы на индустриализацию

3️⃣ Повышение эффективности экономики
Внедрение рыночных механизмов и стимулов технического прогресса, чтобы вложения начали давать отдачу. Этот этап - реформы Дэн Сяопина с конца 1970-х, когда сохраняется сильное государство, но допускается конкуренция, частное предпринимательство, иностранные инвестиции и т.д., что резко повысило продуктивность.

4️⃣ Экономический суверенитет
Защита внутреннего рынка и развитие собственных производств посредством импортозамещения и разумного протекционизма. Китай последовательно выращивал национальную промышленность - от стали и автомобилей до высоких технологий - ограждая её на ранних стадиях от уничтожающей конкуренции извне.

5️⃣ Выход на внешние рынки
Ориентация на экспорт и глобальную конкурентоспособность. Достигнув достаточного промышленного потенциала, Китай сделал ставку на захват внешних рынков - благодаря дешёвой рабочей силе и искусственно заниженному курсу юаня его товары стали сверхконкурентоспособны на мировом рынке, что привело к многолетнему экспорту-буму. Кстати, про это можно почитать историю компании Haier, которую упоминает Попов и книгу о которой я уже разбирал

6️⃣ Адаптивность политики и институтов
Постоянное приспособление системы под меняющиеся условия. Китайские власти гибко реагируют на новые вызовы - будь то мировые кризисы, торговые войны или внутренние социальные проблемы. Меняются приоритеты (например, сейчас больший упор на внутреннее потребление и инновации), усиливается или ослабляется госрегулирование в разных сферах по мере необходимости. Эта адаптивность позволяет модели не застаиваться.

Странам, что хотят повторить китайскую модель развития, нужно искать свой баланс между государственным управлением и рыночными механизмами, опираясь на сильные институты, инвестируя в развитие и действуя стратегически. Именно такой комплексный, этапный подход к развитию, по мнению Попова, может стать рецептом успеха и для других стран.

#Economics #Strategy #Processes #History #PopularScience

[1/2] Про Netflix - Бизнес-планы и оргструктура (Рубрика #Business)

После просмотра подкаста с Элизабет Стоун, техническим директором Netflix, мне стало интересно, а как они в общем поживают, куда смотрит бизнес, как выглядит оргструктура и как выглядит инженерная культура и как дела с архитектурой. В первом посте мы обсудим все кроме архитектуры.

Netflix делает ставку на следующие направления

1️⃣ Основной бизнес стриминга
- Здесь увеличиваются инвестиции в оригинальный контент, развиваются инструменты для кинопроизводства
- Совершенствуется персонализация сервиса и монетизируется совмстное использование (платный шеринг)
- Успешно движется пилотирование прямых трансляций
- Идут работы по приросту подписчиков, например, за счет тарифных планов с рекламой

2️⃣ Рекламный бизнес
- Изначально компания быстро вышла на рынок рекламы вместе с Microsoft
- Спустя полтора года после запуска тарифов с рекламой Netflix объявил о создании собственной ad-tech платформы
- Цель - самостоятельно контролировать рекламные технологии, чтобы предлагать брендам более таргетированные и персонализированные объявления для ~270 млн пользователей.

3️⃣ Рынок видеоигр и облачного гейминга
- Начиная с 2021 года Netflix включил мобильные игры в подписку
- В 2024 году Netflix назначил президента по играм Алена Таскана, экс-руководителя студии Epic Games, чьей целью было сделать так, чтобы "играть на Netflix было так же легко, как стримить кино в пятницу вечером"
- В 2025 году Netflix зашла на рынок облачного гейминга и стартовала интеграции игр непосредственно в приложение Netflix на ТВ: пользователь выбирает игру на экране телевизора, а смартфон используется в роли контроллера. Таким образом, Netflix устранняет лишние препятствия для казуальных игроков
- За первые 10 месяцев 2025 года уже есть результаты - количество загрузок игр выросло на 17% (до ~74,8 млн) по сравнению с аналогичным периодом 2024 года.

Если говорить про оргструктуру, то технологическое подразделение играет стратегическую роль. В январе 2023 года сооснователь Рид Хастингс отошёл от оперативного управления, и руководство перешло к двум со-CEO: Тед Сарандос отвечает за контентное направление, а Грег Питерс - за продуктово-техническое. Грег Питерс ранее многие годы возглавлял development и продуктовую организацию Netflix, и с его повышением до co-CEO технологическая повестка получила ещё более высокий приоритет на уровне высшего менеджмента. В конце 2023 года Netflix обновил высший технический состав
- Появилась позиция CTO и на пост главного технического директора назначили Элизабет Стоун (про подкаст с которой я рассказывал раньше). Стоун пришла в Netflix в 2020 году и руководила командой Data & Insights (департамент продуктовой аналитики и науки о данных). Наверное, это назначение подчёркивает, что компания видит свое будущее в тесном симбиозе технологий и анализа данных
- Параллельно должность Chief Product Officer (CPO) заняла Юнис Ким, отвечающая за пользовательский продукт (интерфейсы, рекомендации, игровой UX и т.д.)

По словам Грега Питерса, эти два лидера “будут возглавлять чрезвычайно важную часть нашего сервиса” - то есть всю техническую платформу и пользовательский опыт, улучшая возможности поиска и открытия контента (фильмов, сериалов и игр) для аудитории. Таким образом, на уровне топ-менеджмента создан тандем, в котором технологии и продукт находятся в фокусе развития Netflix.

Если же говорить про инженерную культуру, то ее отлично описала Элизабет в уже упоминавшемся подкасте. А в следующем посте я расскажу про инфраструктуру и архитектуру Netflix (по-крайней мере про то, о чем они рассказывали публично за последние 10-15 лет).

#Culture #Management #Leadership #Processes #Engineering #Software

[2/2] Про Netflix - Инфраструктура, архитектура и AI (Рубрика #Engineering)

Продолжая рассказ про Netflix, надо рассказать про технические основы компании.

Netflix целиком работает в облаке и использует передовую распределённую архитектуру. Все серверные системы Netflix развернуты на AWS - компания завершила полный переход в облако Amazon в 2016 году и с тех пор не владеет собственными дата-центрами. Сегодня инфраструктура Netflix насчитывает сотни и тысячи микросервисов, работающих в нескольких регионах AWS и обслуживающих более 230+ млн аккаунтов по всему миру. Приложения разделены по функциональным сервисам (от профиля пользователя и системы рекомендаций до системы платежей или каталога видео), которые общаются друг с другом через API. Такой переход на микросервисную архитектуру был начат ещё в 2009–2012 годах, когда Netflix разрезал свою монолитную систему на отдельные сервисы для повышения масштабируемости

Netflix построил целый набор внутренних платформенных решений поверх AWS, чтобы упростить жизнь своим разработчикам. Среди них
- Собственная система оркестрации Titus (внутренний проект, потом open source). Titus интегрирован с AWS (управляет EC2-инстансами), позволяя инженерам деплоить свои сервисы в контейнерах без необходимости вручную оперировать виртуальными машинами.
- Собственная система CD Spinnaker (внутренний проект, потом open source). Она работает поверх Titus и автоматизирует развёртывание микросервисов сразу по всем регионам (мульти-регионные деплойменты)
- Собственный API Gateway Zuul (внутренний проект, потом open source). В обновлённой версии Zuul 2 он построен на неблокирующей Netty и выдерживает огромные объемы соединений, выступая первым рубежом масштабирования
- Собственный circuit breaker Hystrix (внутренний проект, потом open source). Интересно, что внутри Netflix от него потом отказались
- Практика chaous engineering и инструменты Chaos Monkey, Simian Army: Latency Monkey, Chaos Kong и др.

Архитектура данных Netflix распределена и масштабируема
- Apache Cassandra используется для высоконагруженных онлайн-хранилищ, где огромные объемы и требуется горизонтальное масштабирование
- Поверх различных хранилищ Netflix реализовал абстрактный слой KV Storage, унифицирующий доступ для разработчиков и инкапсулирующий детали репликации данных
- Для кеширования часто запрашиваемых данных (профили, списки рекомендаций и пр.) в нескольких датацентрах применяется собственный сервис EVCache (поверх memcached)
- Потоковые данные обрабатываются через стриминговую платформу Mantis (внутренний проект, потом open source). Платформа способна в реальном времени фильтровать и агрегировать миллионы событий
- Для пакетных задач big data используется комбинация решений: Keystone - стриминг поверх Kafka, и Genie - оркестратор задач в Hadoop/Spark кластерах (последний релиз в open source был 3 года назад)
- В 2020-х Netflix открыла исходники Conductor - своего оркестратора бизнес-воркфлоу для микросервисов
- В 2024 году выложила в open-source и новую версию оркестратора data/ML-пайплайнов Maestro.

Хотя вычислительные сервисы Netflix работают в AWS, для доставки видео-трафика компания построила собственную CDN-сеть Netflix Open Connect. Эта инфраструктура решает задачу стриминга гигантских объёмов данных (сотни Tbps) с оптимальным качеством. Open Connect представляет собой флот физических caching-апплиансев, которые Netflix устанавливает в узлах интернет-провайдеров по всему миру

Если говорить про AI/ML, то
- Опыт пользователя персонализирован, рекомендации, обложки фильмов
- При помощи AI/ML оптимизируется инфраструктура сервисов, чтобы снизить косты
- AI используется для производства контента, а также, например, для создания трейлеров

В итоге, видно почему Netflix считается технологической компанией.

#Culture #Management #Leadership #Processes #Engineering #Software