Кратко

  • Пожар начался в энергозалах первого этажа SBG2, где размещались аккумуляторные батареи и источники бесперебойного питания; по заключению BEA-RI, в этих помещениях была пожарная сигнализация, но не было автоматической системы пожаротушения.
  • Две опубликованные хронологии расходятся примерно на двенадцать минут в начале события: 00:35 у следователей против 00:47 в первом сообщении OVHcloud.
  • Независимые интернет-измерения Netcraft зафиксировали около 3,6 млн сайтов и примерно 464 000 доменов недоступными в пике 10 марта 2021 года.
  • Коммерческий суд Лилльской метрополии обязал OVHcloud выплатить 250 000 евро двум клиентам, чьи платные резервные копии хранились в том же здании SBG2, что и рабочие данные.
  • Устойчивость заявленной реконструкции до сих пор не подтверждена ни одним независимо опубликованным аудитом, а часть юридических последствий остаётся неразрешённой.

Залы энергии: обнаружение без тушения

Пожар в страсбургском кампусе OVHcloud вспыхнул в первые часы 10 марта 2021 года. Отчёт французского органа по расследованию промышленных аварий BEA-RI, входящего в структуру министерства экологического перехода, был опубликован под номером MTE-BEARI-2022-005 24 мая 2022 года (официальный отчёт, зеркальная копия; сопутствующее освещение — Reuters).

Ключевой механизм описан в самом отчёте: возгорание возникло в помещениях, где размещены батареи и источники бесперебойного питания — так называемых энергозалах. В этих залах, сказано в тексте отчёта, имелась пожарная сигнализация, но отсутствовала автоматическая система пожаротушения. Очаги возгорания появились почти одновременно на батареях и на инверторе (отчёт BEA-RI, зеркало, освещение находки о влажности).

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

Последовательность, зафиксированная следователями

Хронология BEA-RI выстроена по минутам. Первая тревога в помещении охраны площадки — в 00:35. Охранник достиг энергозала 2 на первом этаже SBG2 в 00:37 и увидел густой чёрный дым. В 00:39 здание было эвакуировано. В 00:42 вызвали пожарную службу (SIS). Первые расчёты прибыли в 00:59. Аварийное электропитание SBG2 отключили в 01:13, питание SBG1, SBG3 и SBG4 — в 01:28. Пожар был потушен в 10:02, работы завершились в 18:13. Было использовано около 4 000 литров пены (отчёт BEA-RI, зеркало).

Из этой же последовательности видно, почему изоляция питания оказалась отдельной проблемой. По собственному сообщению компании, борьба с огнём могла начаться только после отключения электропитания всей площадки, включая все четыре дата-центра (сообщение OVHcloud в сообществе). То есть время между обнаружением и началом активного тушения определялось не только прибытием расчётов, но и процедурой отключения. Отсюда и промежуток между 00:59 (прибытие) и 01:13/01:28 (отключение питания): интервал, в котором пожар продолжал развиваться внутри здания, где не было автоматического подавления.

Две хронологии, которые не совпадают

Публичные сообщения OVHcloud первых суток дают другую картину начала события. По ним возгорание возникло в 00:47, системы обнаружения сработали мгновенно, а реакция шла по протоколу в энергозалах, где был зафиксирован дым (сообщение компании в сообществе, новостная страница OVHcloud).

Расхождение с отчётом BEA-RI составляет около двенадцати минут. Для задачи accountability это не мелочь: в первые часы именно сообщения оператора формируют публичное представление о том, как быстро была замечена опасность. Две версии — 00:35 и 00:47 — не согласуются между собой, и ни одна из них не отменяет другую. Более того, компания тогда же заявляла, что власти и страховщики продолжают устанавливать хронологию, очаг и распространение огня (сообщение в сообществе, новостная страница). Материал фиксирует обе версии, не примиряя их искусственно.

Наблюдение влажности, которое осталось необъяснённым

В отчёте BEA-RI отмечено наблюдение влажности или воды рядом с силовыми инверторами. Профильное издание, разбирая находку, сообщило об этом наблюдении, однако сам отчёт не установил, были ли показания влажности ошибкой измерения (Data Center Dynamics о находке, отчёт BEA-RI).

Это принципиально: наблюдение — не причина. Ни один публичный документ не преобразует эту запись в объяснение возгорания. Отчёт прямо отказался устанавливать окончательную причину, указав, что она остаётся предметом судебной экспертизы, и ограничился уроками безопасности: автоматическое пожаротушение, обслуживание батарей, проектирование зданий и планирование действий на случай аварии, включая отключение электроэнергии (отчёт BEA-RI, зеркало, освещение).

Отчёт также зафиксировал материальную картину: SBG2 уничтожен полностью, SBG1 повреждён частично — четыре помещения из двенадцати, — пострадала перемычка с SBG3. Пострадавших и раненых не было (отчёт BEA-RI, зеркало). В первые часы компания сообщала, что площадка не классифицирована как объект Seveso, что с 02:54 пожарные изолировали площадку и её периметр, что к 04:09 SBG2 был уничтожен и сохранялась угроза соседним дата-центрам, а с 05:30 доступ на площадку для команд OVHcloud был закрыт по указанию префектуры (сообщение в сообществе, освещение, отчёт Data Center Knowledge).

Масштаб отключения по независимым измерениям

Оценивать масштаб только по сообщениям оператора недостаточно. Независимые интернет-измерения Netcraft показали, что в пике недоступными оказались примерно 3,6 млн сайтов на приблизительно 464 000 различных доменов; более 18% IP-адресов, отнесённых к OVH, не отвечали в интервале 06:00–07:15 UTC 10 марта 2021 года. Среди затронутых ресурсов были интернет-банки, веб-почта, новостные сайты, интернет-магазины и несколько правительственных сайтов (анализ Netcraft, освещение Reuters).

Здесь важно различать типы свидетельств. Число затронутых доменов — результат внешнего измерения, а не отчёт компании о собственных клиентах. Именно такое независимое число показывает, насколько широкой была фактическая зависимость от одного кампуса, и объясняет, почему последствия вышли далеко за пределы коммерческих контрактов между OVHcloud и её прямыми заказчиками. Далее по цепочке уже нельзя было увидеть, кто именно потерял данные, а кто лишь временно утратил доступ.

Восстановление и компенсации по данным компании

OVHcloud сообщила об ориентировочно 120 000 сервисов, полностью или частично затронутых аварией, из которых, по её данным, около 113 000 были полностью восстановлены на момент публикации обновления. Компания заявила о предоставлении 14 472 выделенных серверов как альтернативного решения в других дата-центрах и о восстановлении 30 775 виртуальных частных серверов, при остатке примерно 5 900. Оплата затронутых сервисов SBG была остановлена, а для пострадавших клиентов введены меры бесплатного пользования (новостная страница OVHcloud).

Компенсационная схема была ступенчатой. Для уничтоженных виртуальных частных серверов без аварийного восстановления предусматривалась компенсация за шесть месяцев; там, где аварийное восстановление существовало, предлагались либо перестройка, либо полный возврат средств, а при невозможности перестройки — возврат плюс три года бесплатного обслуживания (освещение плана компенсаций).

Все эти цифры — отчётность компании, а не итоговый проверенный подсчёт. Момент обновления не указан точно, и приведённые показатели отражают состояние на конкретную дату, а не окончательный аудированный результат. Читателю стоит держать это различие в уме: масштаб подтверждается независимым измерением доступности, а детализация по восстановлению и деньгам опирается на заявления оператора.

Лилль: резервные копии в том же здании

Наиболее содержательная юридическая проверка обещания пришла позже и лишь частично. Коммерческий суд Лилльской метрополии обязал OVHcloud выплатить компании Bati Courtage 100 000 евро (решение от 3 февраля 2023 года) и компании Bluepad 150 000 евро (решение от 16 марта 2023 года) — в сумме 250 000 евро. Основанием стало то, что оплаченные услуги резервного копирования, приобретённые этими клиентами, хранили копии в том же здании SBG2, что и рабочие данные, поэтому обе версии погибли в одном пожаре. Суд установил, что обещанная услуга резервного копирования не была предоставлена, при этом отклонив часть требований о небрежности в области пожарной безопасности (Data Center Dynamics, Blocks & Files).

Обе публикации основаны на освещении решений, а не на непосредственном изучении судебных текстов. Это надо назвать прямо: суммы, мотивировка и статус обжалования приписываются именно этим сообщениям. Кроме того, сообщалось о намерении OVHcloud обжаловать решение по делу Bluepad, и любой исход апелляции остаётся неразрешённым, пока не появится первичный документ (Blocks & Files).

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

Чего не хватает, чтобы считать ремонт доказанным

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

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

Заявления компании сами по себе проверкой не являются: они описывают намерение и ход работ, но не доказывают изменение поведения в следующей аварии.

Практический вывод для заказчика прост и неудобен. Обещание «резервная копия» стоит проверять по трём вопросам: где физически находится копия относительно рабочей нагрузки, что именно происходит с питанием и пожаротушением в зале, где стоит оборудование, и какие документы — независимые, а не маркетинговые — подтверждают, что первое и второе действительно изменились после 10 марта 2021 года.

Подробнее о предмете: OVHcloud в справочнике BTW.