Книжный куб

[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

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

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

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

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

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

[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

[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

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

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

[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

[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

Про 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

Как устроена инженерия в 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

High growth startups: Uber and CloudKitchens with Charles-Axel Dein (Рубрика #Engineering) Посмотрел интересное интервью Charles-Axel Dein, что он дал Gergely Orosz в подкасте Pragmatic Engineer. Гость был 20м инженером в Uber, а сейчас техлид в стартапе CloudKitchens. Также он автор легендарного репозитория Professional Programming Reading List (15 лет собирает полезные статьи, сейчас 48K⭐ на GitHub). Его интересно послушать, так как он застал этот период гипер-роста в Uber и в подкасте рассказывает много историй и выученных уроков из того времени. Если их сократить, то звучат они так 🚀 Команда на взлёте - Гиперрост = лавинообразное расширение команд. В раннем Uber hiring был в режиме нон-стоп - Искали экспертов-генералистов с широким набором навыков: во время гиперроста ценятся адаптируемые люди, а не узкие "винтики". Каждый инженер вовлечён не только в код, но и в продукт: “Programming is only a part of our work... We are highly involved in product decision-making” - Чтобы масштабироваться организационно, Uber даже провёл реорг и разделил инженеров на platform-команды (инфраструктура) и продуктовые команды (продукт) – это решение, "определившее культуру на годы вперёд" - В CloudKitchens Déin применяет тот же принцип: собирать сильные автономные команды, готовые к быстрому росту. ⚙️ Архитектура и масштаб - Суперрост Uber бросил вызов технике. Монолитная Python-кодовая база (~450k строк) перестала тянуть и за ~5 лет её распилили на 1000+ микросервисов - Собственные датацентры тоже трещали по швам; спустя 9 лет Uber затеял большую миграцию в облако - Параллельно строили внутренние платформенные решения (например, observability) для мониторинга и деплоя, чтобы каждая продуктовая команда не изобретала велосипед - Итог: архитектура эволюционирует рывками, и к этому нужно быть готовым. 🔥 Инциденты и автоматика - Молниеносный рост = неизбежные сбои в продакшене. Charles рассказал, как важна отлаженная oncall-культура: быстро реагировать и учиться на пост-моим («blameless» разборы фейлов – наше всё). - В CloudKitchens усвоили урок того, что не стоит автоматизировать всё подряд слепо. Сначала надо сделать вручную и убедиться, что процесс вообще имеет смысл – sanity check! Иначе автоматизация может сама привнести баги (designer errors). Проще говоря, manual first, automation second. 🤕 Burnout vs Imposter Syndrome - Работа в режиме hypergrowth выматывает, стоит беречь энергию и не загонять себя в хронический burnout - В быстрорастущих командах норма чувствовать себя некомпетентным. Вместо того чтобы паниковать, стоит использовать это чувство как драйвер роста - раз ты ощущаешь дискомфорт, значит реально растёшь вне зоны комфорта. 🔜 Продуктивность и рост - Чтобы успевать в хаосе гиперроста, нужны личные лайфхаки. Charles - фанат методологии GTD (Getting Things Done) и приложения Things для таск-менеджмента: эти инструменты помогают держать фокус и не тонуть в делах - Кроме того, он непрерывно учится: уже 15 лет пополняет свой список чтения для программистов (тот самый repo на 48K⭐) и поглощает тонны инфы - Также он советует прокачивать CS-базис: понимание, как работают компиляторы, операционные системы и прочий tech fundamentals. Такие фундаментальные скиллы остаются ценными при любом стеке и любом цикле хайпа. 💯 Карьерные инсайты - Hypergrowth-компания ценит инженеров, которые делают больше, чем просто писать код. Главное - ownership и гибкость мышления: топ-инженеры берут ответственность, думают о продукте и подтягивают команду, а не только фичи выкатывают& - На интервью лучше не читерить, а показать свой реальный скилл пусть с небольшими огрехами, чем идеальные, но чужие решения. Если суммаризировать, то hypergrowth компании - это хаос, скорость, риски и огромные возможности:) #Architecture #Engineering #Management #VC #Startup #Software #Leadership

10 years of engineering at Nubank: Lessons from scaling to 122+ million customers (Рубрика #Architecture) Недавно прочитал статью про эволюцию NuBank за 10 лет от Lucas Cavalcant, Distinguished Software Engineer and Senior Architect. Эта история эволюции мне показалась интересной, поэтому я решил рассказать про lessons learned Лидерство вне кода Техническое лидерство требует не только писать отличный код, но и умения ясно доносить идеи, вдохновлять команду и направлять её к решению - особенно когда у вас нет формальных "рычагов" руководителя (это особенность staff+ ветки IC). По мере роста роли инженера - ему приходится заниматься стратегическим планированием, координировать несколько команд и принимать крупные технические решения. У нас в Т тоже есть такая ветка, о которой я много рассказывал. Карьерный путь (техника vs менеджмент) В первые годы Nubank инженеры работали в режиме выживания - проблемы возникали ежедневно, и каждый бросался их чинить. Лишь к 2017 году появились первые менеджеры, и многие сеньоры (включая Лукаса Кавалканти) тогда осознали, что им ближе трек IC (individual contributor) и компания это учла: в 2018-м Lucas стал первым Principal Engineer, а недавно поднялся до Distinguished Engineer. Эволюция архитектуры под гиперрост Масштабирование с нуля (в 2013 году) до десятков и сотен миллионов клиентов потребовало постоянных архитектурных переделок. - Изначально система Nubank была написана на Clojure с базой Datomic и развёртывалась монолитно в AWS (CloudFormation + AMI). Подробнее в выступлении 2017 года на QCon. А про использование AWS здесь - С ростом нагрузки перешли на Docker и Kubernetes, распилили монолит на микросервисы, а позже создали core-банкинг платформу, способную поддерживать множество продуктов в разных странах. Подробнее в статье 2019 года про микросервисы - Международная экспансия внесла новые требования (локальные регуляции, языки и т.д.) Но не все масштабные решения оказались долговечны: шардирование данных, введённое в 2016-м, сначала выручало, но в итоге уткнулось в физические пределы (AWS не успевало выдавать новые сервера). Сегодня, как отмечает спикер, для дальнейшего роста нужны уже принципиально новые архитектурные подходы. Стандарты vs инновации На заре Nubank инженеры сами объединялись в "гильдии" для экспериментов с технологиями и инструментами помимо основной продуктовой работы. Такой подход породил культуру инноваций, но плохо масштабировался. Сейчас в компании есть отдельные платформенные команды, создающие общие инструменты и инфраструктуру - это позволяет продуктовым командам фокусироваться на своих фичах. Причем платформенным командам приходится изобретать новые подходы, инструменты и операционные практики, т.к. на масштабе Nubank часто нет готовых решений Производительность команды без выгорания Спикер делит свой путь на два этапа: ранние стартап-годы с бешеным темпом (постоянный "пожарный режим") и более структурированное настоящее, где выстроены процессы, не допускающие бесконечного тушения инцидентов. Его совет: на старте карьеры или продукта стоит выкладываться по максимуму, но постоянно так работать невозможно. Со временем Nubank сознательно улучшил work-life balance команд. Взгляд в будущее (AI и финтех) В качестве следующего большого рывка названы технологии искусственного интеллекта - прежде всего большие языковые модели (LLM). Они могут резко повысить продуктивность разработчиков, но есть риск генерировать больше изменений, чем команды смогут осмысленно потребить и сопровождать. Вызов в том, чтобы найти правильные кейсы, где AI действительно даёт стабильную пользу, а не тонны лишнего кода. Параллельно в самом финтехе происходят прорывы: например, запущенная в Бразилии система мгновенных платежей Pix радикально изменила то, как люди обращаются с деньгами . Подобные инновации, по мнению спикера, будут и дальше стирать границы между рынками и странами, задавая новые требования к масштабируемой архитектуре финансовых сервисов. #Software #Engineering #Management #Architecture #Processes #Staff #SRE #DevOps

[2/2] The History of the Future: Oculus, Facebook, and the Revolution That Swept Virtual Reality (Oculus. Как создать лучшую в мире VR компанию и потерять все?) (Рубрика #Games) Продолжая рассказ про книгу "The History of Future" надо рассказать про основную канву истории Палмер Лаки начал с мечты о доступном VR-шлеме. Будучи подростком, он коллекционировал старые гарнитуры виртуальной реальности и видел их недостатки - узкий угол обзора, низкое разрешение и высокую цену. В своем трейлере во дворе родительского дома Лаки экспериментировал с линзами и дисплеями, и в итоге создал прототип Oculus Rift с широким углом обзора ~90° и малой задержкой обновления картинки. Прорывом стал 2012 год. Лаки активно общался на форумах VR-энтузиастов и однажды получил личное письмо от кумира детства - Джона Кармака, где тот попросил выслать ему прототип Rift. Джон был настолько впечатлен им, что показал Rift в действии на выставке E3 2012 при демонстрации Doom 3 BFG Edition. Эта демонстрация вызвала интерес к проекту. Вокруг Лаки сформировалась команда единомышленников: к нему присоединились Брендан Ирибэ, Нейт Митчелл и Майкл Антонов, решившие основать компанию Oculus VR для развития технологии. В августе 2012 они запустили кампанию на Kickstarter, предлагая VR-гарнитуру для разработчиков игр (собрали 2.4m $). Успех Kickstarter привёл к приходу крупных инвесторов. В 2013 году Oculus получил $75 млн от венчурных фондов во главе с Andreessen Horowitz. Лаки отвечал за технологию, а управление финансами и ростом взяли на себя Ирибэ и профессиональные инвесторы. К Oculus присоединились новые звёзды: Джон Кармак (ex id Software) и Майкл Абраш (ex Valve), что подчеркнуло серьёзность намерений команды. В течение 2013 года Oculus выпустил несколько версий devkit’ов Rift для разработчиков, и интерес к VR только рос. Кульминацией взлёта стала покупка Oculus корпорацией Facebook в 2014 году. Марк Цукерберг лично посетил офис Oculus для демонстрации и был поражён: он назвал Rift "одной из самых крутых вещей, что я видел". В марте 2014 Facebook объявил о приобретении Oculus VR за ~$2 млрд (кеш и акции).Эта новость ошеломила отрасль: с одной стороны, гигантские ресурсы Facebook обещали ускорить развитие VR, с другой - часть сообщества встретила сделку настороженно. Тем не менее, финансовый успех был налицо: 21-летний Палмер Лаки попал на обложку Forbes, а его состояние оценили в ~$700 млн. Компания же стала подразделением Facebook, продолжив работу над потребительской версией Rift. В 2016 году наконец вышел потребительский Oculus Rift CV1, ознаменовав начало новой эры VR-устройств на рынке. Однако вместе с достижениями нарастали и проблемы. Например, ZeniMax, бывший работодатель Кармака, предъявил иск, обвиняя Oculus в присвоении технологий VR. В 2017 году суд частично встал на сторону ZeniMax - сумма компенсации была $250 млн. В том же 2016 году Палмер Лаки оказался в центре скандала - Лаки перевел 10к$ организации Nimble America, что разместила 1 билборд с карикатурой Хилари Клинтон. Также он под псевдонимом NimbleRichMan публиковал резкие политические комментарии. Для имиджа Oculus и Facebook (где руководство в основном придерживалось иных взглядов) это стало ударом. Facebook постарался минимизировать ущерб: Лаки принес публичные извинения, написав, что сожалеет о том, как его действия повлияли на репутацию Oculus. После этого основатель фактически исчез из поля зрения, а весной 2017 года Палмер Лаки покинул Facebook/Oculus. Фактически, основателя вытеснили из созданной им же компании. После увольнения Палмер Лаки недолго оставался в тени. В 2017 году, вскоре покинув Facebook, он основал новую компанию - Anduril Industries, выбрав для себя совершенно иную сферу деятельности. Anduril занимается разработкой высокотехнологичных систем безопасности и обороны - от автономных дронов-наблюдателей до стационарных башен слежения с ИИ. Стартап Лаки быстро получил поддержку инвесторов и правительственные контракты в США. #Software #Hardware #Engineering #Management #Leadership #Startup #Strategy

[1/2] The History of the Future: Oculus, Facebook, and the Revolution That Swept Virtual Reality (Oculus. Как создать лучшую в мире VR компанию и потерять все?) (Рубрика #Games) С большим интересом я проглотил эту документалку о стремительном взлете стартапа взлёте Oculus VR, создавшего революционный VR-шлем Oculus Rift. Автор книги – американский писатель Блейк Дж. Харрис, известный по бестселлеру Console Wars (2014) о битве Sega vs Nintendo. Для работы над этой книгой Харрис получил беспрецедентный доступ к команде компании: с 2016 года он провёл сотни интервью с ключевыми сотрудниками Oculus, наблюдая запуск первого продукта и жизнь стартапа после многомиллиардного поглощения Facebook. Итогом стала захватывающая история о том, как группа энтузиастов пыталась "воплотить будущее" ... и что из этого вышло (запрещенная в России компания Meta на этой волне даже переименовалась из Facebook, но про это в книге не упоминается). Главным героем книги является Палмер Лаки - молодой самоучка и изобретатель, который в 19 лет сконструировал в своем трейлере прототип VR-шлема Oculus Rift, но и не думал о создании компании. Но его переубедил Брендан Ирибэ - сооснователь и первый CEO Oculus VR. Брендан был опытным менеджером из игровой индустрии, он помог превратить любительский проект в бизнес - привлёк инвесторов и выстроил команду, разделив с Лаки стратегическое руководство компанией. Также в этой истории замешан Джон Кармак - легендарный программист (создатель Doom и Quake), чьё участие придало проекту весомость. Кармак увлёкся прототипом Лаки и интегрировал его в демонстрацию игры Doom 3 BFG Edition на E3 2012, чем произвёл фурор. А в 2013 году Кармак оставил id Software и стал техническим директором (CTO) Oculus VR, усилив компанию своим авторитетом и экспертизой. Ну и куда уж без Марка Цукерберга, сыгравшего ключевую роль во второй части истории. Увидев потенциал Oculus Rift, Марк в 2014 году приобрёл Oculus VR за ~$2 млрд. Причем в этой книге он не герой истории, а катализатор перемен - после сделки Oculus из стартапа превратился в подразделение корпорации Facebook, что принесло как ресурсы для развития, так и новые вызовы ... В продолжении я расскажу основную канву истории и поделюсь финалом, который объясняет почему в России не очень широко известно про изобретателя Лаки Палмера, но хорошо известно про Джона Кармака и его участие в истории Oculus. #Software #Hardware #Engineering #Management #Leadership #Startup #Strategy

Extreme DevOps Automation - доклад от Revolut на QCon 2025 (Рубрика #PlatformEngineering) Интересный доклад c QCon 2025 от Sérgio Amorim про работу их DevOps команды. Суть в том, что у ребят из Revolut практичный подход к своей платформе разработки - они плотно сидят на Google Cloud, одновременно добавляя кастомные автоматизации сверху. При таком подходе у них получается, что 15 инженеров могут поддерживать масштаб порядка 1.3к инженеров, 1.2к микросервисов и 1.1к баз данных (что ребята из платформенной команды поддерживают сами). В итоге, получается чуть меньше 1 сервиса и 1 бд на одного инженера:) Для управления всем этим используется три столпа - Каталог сервисов в виде внутреннего решения Tower - это главный источник истины - Паттерны и стандарты для унификации подходов - Автоматизации GitOps при помощи внутренней системы Rhea А теперь давайте подробнее глянем под капот 1. Tower (каталог сервисов IDP) Здесь существует минимальный набор параметров для сервиса: стек (Java/Python/Scala/ML), владелец, связи с БД/сервисами, окружения, критичность (tier), SLO, стоимость, "качество метаданных" и пр. В итоге, это не "статичная CMDB", а портал, откуда начинается управление и в который возвращается обратная связь (качество, аптайм, стоимость). Меньше полей - выше заполненность и точность данных → тем надёжнее автоматика. 2. Паттерны как "сужение свободы" ради скорости и соответствия Малое число поддерживаемых стеков и шаблонов развёртывания. Это повышает повторяемость, упрощает владение и даёт выигрыш в соответствие требованиям - стандартизация автоматически реализует корпоративные и регуляторные правила 3. Автоматизация как Control Plane Rhea «транспилирует» данные из Tower в коммиты (реализуя подход GitOps): - генерирует пайплайны TeamCity и права на деплой для нужных команд (~10к управляемых пайплайнов) - создаёт политики доступа к секретам (Vault) ровно по зарегистрированным связям сервис↔база (~37к политик секретов) - создаёт ресурсы в Kubernetes/облаке - формирует шаблонные алерты/дашборды/правила (~20к стандартных алертов и ~3к кастом‑алертов) Всё это - без ручных действий команд Для сервисов важен и вопрос observability - все начинается со SLO, которые тоже настраиваются в Tower, дальше автоматика генерирует стандартизованные алерты по сервисам и БД, а внутренний диспетчер шлёт единообразные сообщения в Slack командам‑владельцам. Слишком "шумные" системы признаются техдолгом: при накоплении баг‑тикетов включается стопор изменений до улучшения стабильности (этакая реализация error budget). Кстати, у сервисов всего 4 типовых уровня доступности (99.99/99.9/99.8/99.5) Отдельно автор доклада рассказал про управление базами данных, а точнее Postgres, для которых не используются managed решения от Google, а команда DevOps сама оперирует ими, чтобы катать спокойно мажорные обновления СУБД + играть с репликами как хочется. Если проанализировать устройство платформы, то можно отметить, что это работает из-за ряда факторов - Минимальная платформа поверх облака - можно использовать облачную инфру провайдера, а поверх делать только необходимое - Governance вшит прямо в happy path платформы - важные правила (SLO, алерты, секреты, права) применяются автоматически, потому что единственный удобный путь запуска системы - через каталог и паттерны. Ничего "донастраивать руками" не нужно и часто нельзя. - Каталог систем + GitOps. Tower фактически становится "API компании" для всего инженерного ландшафта. Один набор артефактов порождает пайплайны, политики, ресурсы и мониторинг. Это снижает расхождение реальности и деклараций. - Стандарты на масштабе ускоряют, а не тормозят. Ограничение стеков + шаблоны деплоя убирают вариативность, ускоряя онбординг и снижая операционный риск. - SLO/алерты как механизм управления продуктом. Унифицированный шумомер и error‑budget freeze принуждают команды держать стабильность, а не "продавливаться" релизами любой ценой. - Фокус DevOps‑платформы - не "поддержка руками", а инжиниринг инструментов и продуктовая работа над DX. #Software #Engineering #Management #Architecture #Processes

„Я понял, что это конец“: как создатель „Алисы“ уволился из „Сбера“, эмигрировал и строит AI‑стартап (Рубрика #AI) Посмотрел интересное интервью Константина Круглова, что он дал Елизавете Осетинской, иностранному агенту. Сам гость в этом выпуске очень интерсные - Константин до отъезда из России успел поработать в Tinkoff Digital, где строил платформу для programmatic buying, в Yandex, где занимался Алисой, а также в SberDevices, где тоже делал железо для колонок и голосовых ассистентов. После событий 22 года он уехал зарубеж и соосновал Aiphoria, enterprise‑платформа голосовых AI‑агентов. Кстати, это популярная тема - например, Брет Тейлор рассказывал о том, что строит сейчас такую платформу Sierra, а он ex-CTO Meta, ex-CEO Salesforce и ex-председатель правления OpenAI:) Интервью длилось почти два с половиной часа, поэтому обо всем рассказывать не буду, но подсвечу интересные мысли для инженеров и фаундеров технологических стартапов, которые можно извлечь из него 1. Как делали железо и почему это урок про скорость Константин рассказал про запуск колонки в Яндексе - Битва за долю рынка, а не за технологическую чистоту. Идея "умной колонки" родилась как ответ на возможный заход Amazon в РФ - Инженерные ходы, что применялись при разработке: реверс‑инжиниринг существующих устройств; покупка и доработка технологии (Cubic AI) для построения микрофонной решётки, многомесячный кранч, чтобы отработать технологию - Итог - работающее устройство, устойчивый спрос 2. Оргдизайн и "скорость принятия решений" Гость сравнил между Яндекс и Сбер с точки зрения культуры - Яндекс: горизонтальная организация, высокое трение между командами - приходится «продавать» фичу каждому соседу. - Сбер: «отточенная немецкая машина» - вертикаль, где решения и имплементация могут идти быстрее; при этом лидер (Греф) лично в теме и помнит контекст. Мне кажется, что гость оценивает Сбер по тому, как он работал с топ-приоритетом Грефа, когда на его инициативы была зеленая волна - именно это обеспечивало скорость изменений:) А что бы было, если бы это не было топ-темой? 3. Причины отъезда из России Были личные причины, но гость их не назвал, а вот про рабочие поговорил. Ему была важно, что он занимается фронтир вещами, а после 24 февраля это уже не реально. В итоге, за несколько дней он принял решение сменить среду на ту, где есть плотность талантов, капитала и заказчиков. 4. А про что стартап Aiphoria, который соосновал гость Это платформа enterprise‑класса для голос‑first AI‑агентов: голосовые агенты, агенты в мессенджерах и email. Есть поддержка разных языков, on-prem для заказчиков типа банков, примеры сценариев для автоматизации: поддержка клиентов, взыскания, продажи, рекрутинг и др. Стратегией запуска было сначала доказать бизнес‑ценность на продакшене и выйти в прибыль, потом привлекать капитал под масштабирование. В общем и целом, очень интересное интервью, из которого можно еще узнать про работу рекламных технологий, сложности проектирования железа, как поднимать инвестирование на стартапы и все такое. #Startup #AI #Engineering #Leadership #Software