Из этой серии статей вы узнаете о, вероятно, самом глупом, легко предотвратимом и дорогом провале 21-го века, из-за которого Microsoft чуть не потеряла своего самого крупного клиента (OpenAI) и доверие правительства США.

Скучным утром понедельника 1 мая 2023 я впервые вышёл на работу в Azure Core в качестве сениор-сотрудника команды Overlake R&D, разработавшей карту выгрузки и сетевой ускоритель Azure Boost.

Azure не был для меня чем-то новым: наверно, это самая длительная моя подписка на облачный сервис, который был запущен в феврале 2010 года под названием Windows Azure.

Не был я и новичком в Microsoft: с 1 января 2013 года я был частью команды разработчиков Windows, а позже помогал выполнять миграцию SharePoint Online в Azure; в дальнейшем я присоединился к команде Core OS в качестве разработчика ядра. В ней я помогал совершенствовать ядро, участвовал в разработке и реализации платформы Container, поддерживающей Docker, Azure Kubernetes, Azure Container Instances, Azure App Services и Windows Sandbox. Выпуск всех этих технологий привёл к получению множества патентов.

Кроме того, я участвовал в мозговом штурме при создании прототипов карт Overlake в 2020-2021 годах, в составлении драфта предложения коммуникационного протокола и сетевого стека Host OS <-> Accelerator Card ещё на том этапе, когда у нас было лишь последовательное соединение отладчика. Также меня привлекали в качестве специалиста по Core OS, и я помогал разработчикам Azure Core диагностировать глубокие проблемы операционной системы.

В 2023 году я вернулся в Azure сразу в должности специалиста, поскольку уже внёс свой вклад в разработку некоторых из технологий, лежащих в основе Azure, и будучи её пользователем в глобальных масштабах больше десятка лет, как снаружи, так и внутри Microsoft.

Так как я был вернувшимся сотрудником, то пропустил обучение для новичков и получил приглашение Global Security на полдень для получения своего бейджа, но мой будущий менеджер спросил, смогу ли я прийти раньше, потому что тем утром у команды должно было состояться ежемесячное совещание по планированию.

Разумеется, я согласился и за несколько минут до десяти уже пришёл ко входу в здание Studio X, находящееся неподалёку от The Commons в западной части кампуса в Редмонде. В холле появился мужчина и открыл мне дверь. Я проследовал за ним по лабиринту из коридоров в зал для совещаний.

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

На экране проектора светился слайд, на котором я увидел множество знакомых аббревиатур: COM, WMI, perf counters, VHDX, NTFS, ETW и десяток других вперемешку с новой терминологией Azure; всё это находилось в прямоугольниках, соединённых путаницей стрелок.

Я тихонько сел на задних рядах и начал слушать, как один из участников рассказывал остальным о масштабном плане портирования текущего стека на ускоритель Overlake. Поначалу мне было не очень понятно, как прямоугольники с компонентами пользовательского режима и ядра Windows связаны с этим планом.

Спустя несколько минут я осмелился задать вопрос: вы планируете портировать эти фичи Windows в Overlake? Он ответил утвердительно, сказав, что они, как минимум, рассматривают такую возможность. Менеджер по разработке выразил некоторые сомнения, а докладчик ответил, что они могут хотя бы «попросить изучить вопрос пару разработчиков-джунов».

В зале на мгновение стало тихо. На своём прежнем месте я видел характеристики оборудования SoC карты Overlake: малый объём RAM и бюджет мощности, составлявший лишь крошечную долю от требований по теплоотводу, на которые можно рассчитывать у обычного серверного CPU.

В то время я разговаривал с разработчиками оборудования: они говорили мне, что могут выделить под мой коммуникационный протокол с общей памятью лишь 4 КБ двухпортовой памяти на FPGA.

Всё в оборудовании было быстрым, эффективным и энергосберегающим, однако команда, в которую я пришёл десять минут назад, серьёзно рассматривала возможность портирования половины Windows на этот крошечный неохлаждаемый чип с Linux размером с ноготь.

Это было похоже на то, как Илон Маск рассказывал о колонизации Марса: сначала взорвём атомные бомбы на полюсах, а потом создадим атмосферу! Проще сказать, чем сделать, правда?

Вся эта организация из 122 человек углубилась в разработку невозможного проекта, связанного с портированием Windows на Linux для поддержки имеющихся агентов управления VM.

Докладчик был ведущим руководителем группы разработки, занимавшейся частью ПО, работавшего в каждом узле Azure; в зале находился и его начальник, менеджер по инженерному взаимодействию с партнёрами, и они на самом деле обдумывали портирование Windows на Linux для поддержки их ПО.

Поначалу я засомневался в своём понимании ситуации. Они серьёзно? Остальная часть доклада не оставила места для сомнений: план был намечен, а лидам разработки было поручено выделить на этот проект людей. Мне сразу стало понятно, что этот план никогда не будет выполнен, и что этой организации требуется большая помощь.

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

Как я узнал позже, стек упирался в потолок масштабирования на 400-ваттном Xeon всего с несколькими десятками VM — это далеко от предела в 1024 VM, на который, как мне было известно, способен гипервизор; при этом такой сервер был шумным соседом, потреблявшим столько ресурсов, что вызывал колебания, заметные из пользовательских VM.

Ни в одной из версий Вселенной не существовало возможности, что этот стек можно уместить в крошечный SoC ARM и отмасштабировать на несколько порядков. Этого просто не будет.

За десятки лет работы в отрасли (и в Microsoft) я повидал многое, но никогда не встречал организацию, столь далёкую от реальности. Следовательно, моей первостепенной задачей стало не освоение новой технологии, а необходимость убедить всю организацию, в том числе и людей намного выше меня, что они самоубийственно бегут к обрыву, как лемминги.

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

Следующие несколько дней я подробнее читал планы, изучал текущие системы и ходил в гости к друзьям из Core OS, моей альма-матер. Я заблудился и попал в странный мир, в котором люди строили бессмысленные планы с уверенностью пьяной LLM.

В частности, полтора часа я лично общался с главой Linux System Group — опытным учёным со степенью PhD из INRIA, одним из тех, кто несколько лет назад нанимал меня в команду разработчиков ядра.

Его организация отвечала за выпуск Mariner Linux (ныне Azure Linux) и урезала дистрибутив, работающий на карте Overlake / Azure Boost. Он любезно ответил на все мои вопросы; от него я узнал, что они выбрали 173 агента (сто семьдесят три) в качестве кандидатов на портирование в Overlake.

Позже я провёл более глубокие исследования и выяснил, что ни один человек, ни одна живая душа в Microsoft не могла чётко сформулировать, зачем для управления узлом Azure требуется до 173 агентов, что они все делают, как взаимодействуют друг с другом, какой у них набор фич и зачем они вообще существуют.

В основе своей Azure продаёт VM, сетевые интерфейсы и хранение данных. Остаётся добавить наблюдаемость (observability) и обслуживание, и этого должно быть достаточно. Всё остальное: SQL, K8s, ИИ-нагрузки и прочее — создаётся в VM при помощи xPU, сетевых интерфейсов и хранилищ данных, а все сложности по обеспечению магии берут на себя гипервизор и добрые люди из команды Core OS.

По-прежнему остаётся загадкой, как ребята из команды Azure пришли к 173 агентам, но чтобы прийти к этому, требуется высокая степень несогласованности, а это путь к катастрофам.

А теперь представьте на секунду, что вся эта неконтролируемая куча управляет VM, на которых работает Claude компании Anthropic, то, что осталось на Azure от OpenAI API, SharePoint Online, государственные облака и другая критическая инфраструктура, и вы приблизитесь к пониманию того, что даже одна песчинка в этом хрупком нагромождении может вызвать глобальный коллапс с серьёзными последствиями для национальной безопасности, подвергающий риску само существование Microsoft.

Но мы всё ещё не дошли до испарившегося триллиона рыночной капитализации, моих писем к CEO, в совет директоров Microsoft, исполнительному вице-президенту Cloud + AI и их абсолютного молчания, до частичной потери OpenAI, падения доверия со стороны правительства США, о котором публично заявил Министр войны США, до потраченных впустую усилий, требований перехода на Rust, ситуации с командой bare-metal OpenAI в Azure Core, до сессий сопровождения из Китая и других стран, а также до отложенных фич, публично объявленных выпущенными ещё в 2023 году, когда работа над ними ещё не началась.

Если у вас есть продакшен-нагрузки в Azure или вы используете его для критичных систем, то эта история для вас важнее, чем вы думаете.

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

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

На моей предыдущей работе в должности разработчика ядра команды Windows Core OS я был подотчётен одному из самых талантливых разработчиков операционных систем, которых встречал в Microsoft.

Он обладал десятками лет опыта, начинал работать ещё с Дэйвом Катлером, создавая те системы Windows, которые привычны нам сегодня. Среди его проектов были Server и Application Silos (с кодовыми названиями Helium и Argon), заложившие фундамент платформы Windows Container.

Также он работал над такими исследовательскими операционными системами, как Midori и Singularity, был одним из первых разработчиков Azure Fabric — мета-операционной системы, выполняющей оркестрацию облачной инфраструктуры Microsoft.

Однажды, в самом начале моей работы под его руководством, он принёс старый командный мерч: свитер с надписью 0xF0FFFF — шестнадцатеричным кодом лазурного цвета [прим. пер.: Azure означает «лазурь»].

За годы работы с ним я узнал не только о проектировании ядер, но и об истоках Azure, а также о невероятном давлении со стороны конкурентов, в условиях которого он сформировался.

В 2006 году Amazon запустила S3 и EC2; Microsoft опоздала к началу гонки публичных облаков, поэтому ей нужно было двигаться быстро. Проект под кодовым названием Red Dog начался с небольшой команды из пяти-шести элитных разработчиков под руководством Катлера.

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

Узлы принадлежат кластерам, управляемым Fabric Controller, которая занимается инвентаризацией ресурсов, размещением VM, предоставлением ресурсов, обслуживанием, балансировкой нагрузок и масштабированием.

Группа агентов, в том числе и центральный RdAgent, отчитывается перед контроллером и оркестрирует локальные ресурсы в каждом узле, а также создание виртуальных машин.

Создание VM по-прежнему похоже на заказ пиццы (если опустить некоторые подробности): пользователь выбирает из меню размеров и ингредиентов: 16 ядер? Хорошо. 128 ГБ памяти? Готово. 32 диска? Без проблем. Четыре NIC? GPU? Будет сделано!

Дальше ПО узла руководит гипервизором при создании раздела, присоединении нужных устройств, добавлении диска с загрузочным образом и запуске VM.

Проект завершился успешно и в феврале 2010 года был выпущен под названием Windows Azure. Но, как это часто происходит с торопливыми работами, выполняемыми под высокой нагрузкой, многие контрибьюторы первоначального кода ядра постепенно занялись другими делами.

В то время Microsoft всё ещё была сильно сосредоточена на PC, планшетах и телефонах. Команды портировали Windows на ARM, выпускали Windows 8 и 8.1 и приобретали Nokia, одновременно переосмысливая архитектуру Xbox One в контексте Hyper-V под руководством Катлера.

Облачные технологии были важны, но не находились в центре внимания. OneDrive и SharePoint работали на отдельной архитектуре, а Azure, несмотря на второе место в гонке, далеко отставал от AWS.

Всего за несколько месяцев до того, как Сатья Наделла стал в феврале 2014 года CEO компании, он сократил должность SDET (Software Development Engineer in Test), что вызвало довольно масштабные увольнения.

Из-за правительственного акта WARN о защите работников Microsoft не могла избавиться от всех должностей тестировщиков, сотни из них остались в штате.

Многие из этих тестировщиков были хорошими исполнителями, но имели ограниченный опыт в системном проектировании и глубокой разработке ПО; они прошли переподготовку.

Некоторые из них стали дата-инженерами, занимающимися телеметрией Windows 10; других перевели на должности в разработке ПО (часто с понижением уровня); третьи оказались в некритичных областях, в том числе в Azure OPEX, где они помогали в поддержании работоспособности систем в ротации дежурств и устранении инцидентов.

Перенесёмся немного вперёд во времени: большими частями Azure занимаются эти бывшие тестировщики. Многие из них были прилежными работниками, но из-за смены деятельности у них возникли пробелы в глубоком понимании архитектуры этих критичных систем.

Команды OPEX занимаются поддержкой стабильности продакшена. Это выматывающая работа с ротацией дежурств 24/7, быстрым устранением неполадок, анализом постмортемов и исправлением скриптов, что приводит к сильному истощению.

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

В 2018 году Наделла сместил фокус компании на Cloud + AI и сделал главным по этому направлению Скотта Гатри.

Windows была реорганизована под Azure, и за считанные дни уже существовавшие команды Azure стали важнейшим аспектом самой стратегической ставки Microsoft.

Большинство людей на должностях остались теми же, если не считать нескольких высокоуровневых перестановок.

К тому времени, когда я пришёл в команду в 2023 году, примерно половина организации, отвечающей за Compute Node Services, состояла из разработчиков-джунов со всего одним-двумя годами опыта.

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

И теперь этой группе поручили перенести унаследованный ею стек в новое окружение ускорителя Azure Boost; на конференциях Ignite компания Microsoft с 2023 года публично заявляла, что этот проект находится в разработке уже очень давно.

На самом деле, как человек, отвечавший за портирование и модернизацию в слое гипервизора, я знал, что работа, по сути, едва началась.

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

Лишь некоторые разработчики могли надёжным образом собирать ПО локально; отладчиком пользовались крайне редко (в 2024 году я написал для команды первое руководство по ним); покрытие автоматизированными тестами составляло меньше 40%.

Каждый ежемесячный релиз добавлял больше новых дефектов, чем исправлял. Большинство разворачиваний оказывалось откатами под воздействием паники. Каждый месяц происходили миллионы вылетов, происхождение большинства из которых определить не удавалось, потому что команды никогда не указывали владение своими модулями в системе отчётности о сбоях Azure Watson.

В результате этого автоматизированная расстановка приоритетов создавала новые формальные инциденты, что позволяло показывать в ежемесячных рассылках красивые метрики качества, не основанные ни на каких реальных данных.

Часто вину за проблемы, источником которых становилось ПО узлов Azure, взваливали на команду Core OS. Вылеты часто приводили к утечкам ресурсов: файлов, дисков и даже целых VM.

Плохая обработка ошибок приводила к неправильно формируемым VM (например, к отсутствию дисков). Когда пользователи пытались вывести их из эксплуатации, ПО узлов пыталась отсоединить несуществующие диски, вызывая ошибки гипервизора.

Команда Azure обвиняла во всём команду Hyper-V, и эскалации достигли уровня вице-президентов.

Однажды меня пригласили на важное совещание со стейкхолдерами с обеих сторон; лидов Hyper-V явно раздражало то, что на них постоянно перекладывают вину.

Поверх всего этого хаоса действовало указание, охватившее весь Azure: всё новое ПО необходимо было писать на Rust. Некоторые планы по портированию были заброшены, а многих разработчиков-джунов увлёк новый язык.

Критичные модули ядра управления узлами Azure, важнейшая часть флагманской инициативы компании Cloud + AI, иногда проектировались разработчиками с менее чем годом опыта работы на этом месте, под руководством лидов, которым не хватало информации о подробностях.

Ничто из этого не было выпущено.

ПО управления VM продолжало работать и вылетать в Windows, несмотря на многократные публичные заявления с 2023 по 2025 год о том, что ключевые компоненты были перенесены на ускоритель Azure Boost и переписаны на Rust.

Я участвовал во всём этом напрямую, поэтому знаю, что на конец 2024 года эти заявления не соответствовали реальности. Из 64 ключевых пунктов работы, составленных годом ранее для модернизации и переноса стека управления VM, ни один не был завершён, а примерно над шестьюдесятью работа даже не была начата.

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

Ещё хуже то, что ранние прототипы подтягивали почти тысячу сторонних крейтов Rust, многие из которых были транзитивными зависимостями и практически не контролировались, что создавало потенциальные риски цепочки поставок.

Кроме всего этого, организация была твёрдо намерена выпустить и так давно откладываемые bare-metal-устройства для OpenAI, которые обещала уже несколько лет. Эта работа началась в мае 2024 года с дедлайном весной 2025 года, ею руководил ведущий инженер, который, очевидно, никогда не занимался задачами подобного масштаба.

Перенесёмся в 10 марта 2025 года: OpenAI подписала с CoreWeave сделку на $11,9 миллиарда по обучению моделей и сервисам.

CEO OpenAI Сэм Альтман заявил: «Современные ИИ-системы требуют надёжных compute-ресурсов, и мы с радостью продолжим масштабирование вместе с CoreWeave, чтобы получить возможность обучать ещё более мощные модели и предоставлять отличный сервис ещё большему количеству пользователей». Похоже, эти слова стали целенаправленным комментарием о надёжности и масштабируемости Azure.

Это стало важным моментом, потому что всего за несколько недель до этого на Всемирном экономическом форуме в Давосе Сатья Наделла подчеркнул существование соглашения ROFR между Microsoft и OpenAI, в котором говорится, что OpenAI сначала должна обратиться к Microsoft и искать другие варианты, только если Microsoft не сможет соответствовать её требованиям.

В сентябре 2025 года OpenAI (строго говоря, всё ещё находясь под действием ROFR Microsoft) расширила своё соглашение с CoreWeave ещё на $6,5 миллиарда. Примерно в то же самое время OpenAI заключила масштабную сделку с Oracle, оценивающуюся в $300 миллиардов.

Тем временем, Microsoft проводила масштабные увольнения: примерно 15 тысяч рабочих мест волнами с мая по июль 2025 года; скорее всего это было сделано, чтобы компенсировать прямые потери из-за CoreWeave перед следующей видеоконференцией о доходах.

Можно вполне разумно заключить, что Microsoft испытывала трудности с удовлетворением потребностей OpenAI во время и в нужных масштабах. После прочтения моей статьи подобное не должно вызывать удивления.

Если вернуться к первоосновам Azure, Катлер намеревался создать систему, обладающую тем же уровнем качества, надёжности и внимания к деталям, благодаря которому Дэйва прославила его работа над VMS и NT.

В интервью 2009 года он заявил, что предназначение [Azure Fabric Controller] заключается в «управлении размещением, предоставлением, обновлением, патчингом, обеспечением ёмкости, балансировки нагрузки и масштабов из узлов в облако без какого-либо оперативного вмешательства». (Выделение добавлено мной).

За годы работы с одним из первых контрибьюторов в Fabric я узнал, что ручное управление узлами было строго запрещено: изначально архитектура задумывалась так, чтобы Azure работал без вмешательства человека.

В разговоре о крайне осмотрительных обещаниях касательно Azure Катлер сказал: «Группа исследований и разработок попросту очень консервативна, мы ещё не близки к завершению».

Также он добавил, что «[они] делают каждый шаг очень медленно и пытаются добиться стопроцентной работы фич и их надёжной отладки, прежде чем сообщать о них».

Это было произнесено 24 февраля 2009. Всего 48 недель спустя Azure был выпущен для широкого пользования.

Перенесёмся в лето 2025 года, когда Министр войны США Пит Хегсет публично объявил о «нарушении доверия» со стороны Microsoft. Заявление последовало за статьёй ProPublica, описывающей «цифровые сессии сопровождения» проводившиеся на компьютерах Azure.

В статье говорится о том, что в рамках цифровых сессий сопровождения сотрудники со ставкой $18 в час копипастили и исполняли команды в правительственных облачных узлах под руководством персонала техподдержки Microsoft, часто находящегося в других странах, включая Китай.

Однако прямой доступ к узлам и ручное вмешательство — это повседневные практики, распространившиеся намного шире правительственных облаков.

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

Судя по информации из статьи, эта программа была придумана на самых высоких уровнях руководства компании; её участники заявляли, что «стратегия цифрового сопровождения позволила компании „быстрее выйти на рынок“ с целью получения крупных федеральных облачных контрактов».

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

Маркетинг и давление конкурентов часто влияют загадочным образом; однако в статье не объяснялось, почему узлам требовалась ручная починка.

Теперь ответ становится очевидным: ПО работало не так хорошо, как надеялись, во многом из-за того, что вследствие давления конкурентов систему выпустили слишком поспешно.

Если сюда добавить исход из проекта его основателей, замену разработчиков на людей с очень разным уровнем опыта, то мы получим систему, которая слишком много обещает и слишком мало даёт, утонувшую в неразрешимых проблемах.

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

Работая в команде Overlake и Compute Node Services, я наблюдал с самого первого дня ту же самую внутреннюю хрупкость: хронические вылеты, утечки ресурсов, неправильно сформированные VM и раздутая экосистема агентов, которую никто не может объяснить полностью. Всё это создавало нестабильность, требующую постоянно тушения пожаров, в том числе и в конфиденциальных правительственных облаках.

То, что я видел в 2023–2024 годах, было не случайными пограничными случаями, а постоянным потоком симптомов системы, которая никогда не стабилизируется, несмотря на надёжность своего фундамента, а именно гипервизора и Windows.

Ручные сессии сопровождения во многих смыслах были наглядным симптомом более глубокого архитектурного и организационного долга.

Я начал поднимать эти вопросы внутри организации, в том числе через официальные уведомления, которые доходили до наивысших уровней руководства компании.

В одном из случаев фича, предназначенная для обмена секретными ключами шифрования между каким-то актором в гостевой VM и операционной системе хоста, которую писали одиннадцать месяцев, за несколько часов после развёртывания в продакшен сгенерировала два инцидента уровня критичности Sev-2.

Оказалось, что один из агентов вызывал другого через неизвестную конечную точку, генерируя ошибки, которые записывались в логи с обеих сторон.

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

Этот инцидент демонстрирует отсутствие глубокой ответственности за код, чрезмерно усложнённые взаимодействия между агентами, пробелы в техническом руководстве и тестировании, позволившие этим серьёзным дефектам попасть в продакшен.

Я чётко помню, как попросил у менеджера разработки разрешение прекратить всемирное развёртывание; командам понадобились все выходные и половина следующей недели, чтобы откатить систему к предыдущей версии.

В другом случае потребовалось три месяца (с января по март 2024 года) для запуска скрипта удаления файлов утёкших файлов, которые в некоторых узлах превысили предел временных файлов в 100 ГБ.

Из-за систематических сбоев и ограничений автоматизированных систем, внутри организации известные под названиями «OaaS» и «Geneva Actions», пугающими становились даже простые задачи.

Эти инциденты были показательными для повседневной реальности команд Azure OPEX: постоянный поток проблем, возникающих вследствие нестабильности ПО узлов и окружающих систем поддержки.

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

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

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

Утечки ресурсов, вылеты, неуправляемые VM, VM-«зомби» и проблемы со здоровьем узлов — обычно всё это разрешалось параллельно с обычной работой, потому что у Azure было пространство для манёвра и персонал, круглосуточно помогающий с восстановлением.

Однако можно только догадываться, как будет справляться система на грани своего потенциала, например, в случае кризиса. Ситуация, в которой большому количеству пользователей внезапно потребуются повышенные мощности, скорее всего, приведёт к катастрофе.

В процессе накопления этих проблем я начал официально поднимать их наверх через цепочку руководства, в том числе через структурированные уведомления, которые в конечном итоге достигли старшего руководства и поднялись выше.

Также я говорил в них о потенциальных проблемах с безопасностью, которые обнаруживал в процессе.

Спектр ответов варьировался от признания проблем до попыток защититься; это показало, насколько глубоко внутрь проникла культура работы в режиме постоянного тушения пожаров вместо устранения первопричин.

Напряжённость обострилась из-за требования перехода на Rust во всём проекте Azure, противоречивых планов по портированию и параллельных требований реализации таких находящихся под особым вниманием проектов, как надолго выпуск задержавшихся устройств bare-metal для OpenAI.

То, что начиналось, как технические разногласия, быстро вскрыло масштабный стратегический и культурный разлом в организации.

Часть вторая