OVH 2017: независимость резервирования как проверка подотчётности

Резюме

Границы события узкие:В этой статье рассматривается только отказ оптической сети в Рубе 9 ноября 2017 года. Одновременное отключение электроэнергии в Страсбурге было самостоятельным инцидентом с иным механизмом и цепочкой управляющих воздействий.
Видимый отказ был масштабным, но не всеобщим:В современных описаниях сообщалось о потере связности Рубе с шестью точками присутствия сети OVH. Это не доказывает, что все маршруты, клиенты или рабочие нагрузки OVH вышли из строя одинаково.
Номинальное резервирование не обеспечило операционной независимости:OVH описывала резервные оптические соединения, однако каналы Рубе оказались недоступны все одновременно после потери конфигурации, и их пришлось восстанавливать из сохранённой конфигурации.
Публично объявленная первопричина имеет два уровня:OVH отнесла непосредственную причину к дефекту программного обеспечения и потере конфигурации оптического оборудования. Одновременная потеря также вскрыла общий домен отказа по конфигурированию или управлению, который не был устранён физическим разнесением трактов.
Сохранённая конфигурация не является независимой системой восстановления:Сохранённая конфигурация позволила восстановить службу, но сам факт её наличия не сохранил работоспособность оптической системы. Доступность резервной копии, полномочия на её применение и проверенная восстанавливаемость должны оцениваться отдельно.
Ответственность следует за контролем:OVH контролировала архитектуру, развёртывание, защиту конфигурации, мониторинг, восстановление и коммуникацию с клиентами. Производитель оборудования отвечал за расследование дефекта продукта и исправление ПО. Пиринговые партнёры, транзитные сети и клиенты контролировали собственное внешнее резервирование, но не внутреннее состояние оптики OVH.
Объявленный план восстановления корректно разделил две проблемы:OVH запланировала обновление ПО совместно с производителем и разделение оптической мультиплексирующей системы на две системы. Первое было нацелено на устранение дефекта; второе — на ограничение радиуса поражения при повторении.
Устранение не доказывается одним объявлением:Достоверное завершение требует свидетельств о топологии и конфигурации, тестов с внесением отказов, независимых измерений достижимости и доказательств того, что единый управляющий отказ больше не способен вывести из строя все внешние тракты Рубе.

Зафиксируйте событие в Рубе, прежде чем распределять ответственность

В один день OVH пережила два серьёзных отказа. Отключение электроэнергии затронуло площадку в Страсбурге, а отказ оптической сети — Рубе. Позднее заявление OVH прямо описало эти инциденты как одновременные, но не связанные между собой. Это различие является отправной точкой для подотчётности, а не деталью, которую следует сворачивать в более общую историю. [1]

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

Поэтому данная статья начинается с оптического отказа в Рубе и заканчивается, когда соответствующие каналы и связность площадки хостинга были восстановлены, после чего последовало специфическое устранение, объявленное OVH для Рубе. Она исключает инцидент с электропитанием в Страсбурге, инцидент с хранением данных в июле 2017 года, более поздний сетевой инцидент в декабре 2017 года, пожар в Страсбурге в 2021 году и отдельный маршрутизационный инцидент 2021 года. Эти события могут дать более широкую историю OVH, но не могут использоваться как доказательства причины или устранения оптического отказа в Рубе.

Публичная хронология имеет два полезных уровня. Официальное заявление OVH гласило, что площадка в Рубе вернулась к работе менее чем через два с половиной часа. Пострадавший поставщик услуг отдельно зафиксировал видимую клиентам недоступность в то же утро и описал восстановление после возврата оптической конфигурации. [1][4]

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

Та же дисциплина относится к началу инцидента. Пострадавший поставщик услуг описал доступность из одних сетей, но не из других во время утреннего нарушения, тогда как OVH описала отказ оптики на стороне провайдера и последующее восстановление. Эти точки зрения не обязательно противоречивы. Одна фиксирует наблюдаемый внешним клиентом эффект; другая — событие в оптической системе провайдера. Разные наблюдатели, часы и сетевые пути могут видеть разные границы. [4]

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

Что показала действующая сеть

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

Эти детали важны, потому что показывают, что событие не было представлено как обычный одиночный обрыв волокна. Напротив, OVH и современные сообщения описали программный и конфигурационный отказ, затрагивающий оптическую систему, за которым последовала работа по восстановлению с производителем оборудования. Доступные источники не раскрывают полную диагностическую последовательность или внутреннее состояние плоскости управления. [1][4]

Публичное описание первопричины указало на потерю конфигурации в оптическом оборудовании. OVH восстановила сохранённую конфигурацию и восстановила затронутую связность. Компания отнесла непосредственное событие к дефекту программного обеспечения, тогда как коррелированная потеря путей обнажила более широкий вопрос об общем конфигурировании и зависимостях в управлении. [1][4]

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

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

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

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

Физическое разнообразие — это не независимость доменов управления

Распространённая наглядная модель отказоустойчивого транспорта — две линии между двумя точками. Если одно волокно перерезано, трафик идёт по другому. Эта модель полезна для узкого физического риска. Она неполна, когда оба пути разделяют программное обеспечение, полномочия на конфигурирование, контрольное оборудование, синхронизацию, питание, доступ к управлению, логику активации или общую процедуру восстановления.

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

Отчёт OVH — конкретный пример этого различия. Провайдер описал резервные оптические соединения, однако каналы Рубе оказались недоступны одновременно при потере конфигурации. Средства управления, призванные сохранить связность, не сдержали фактически произошедший общий конфигурационно-зависимый отказ. [1][4]

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

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

Конструкция может пройти первые три и провалить шестой или седьмой. Называть результат «резервированным» без указания защищённого класса отказов — значит скрывать самый важный вопрос.

RFC 3439 предупреждает, в общих архитектурных терминах, что сложность имеет реальную цену и что системы часто отказывают при неожиданных взаимодействиях. Этот документ не был написан об инциденте OVH и не доказывает внутреннюю архитектуру провайдера. Он предлагает полезную аналитическую дисциплину: добавление компонентов, копий и автоматизации может создавать разделяемое состояние и дополнительные виды отказов, если их поведение не ограничено и не наблюдаемо. [14]

Руководство NIST по киберустойчивым системам аналогично рассматривает устойчивость как спроектированную способность предвидеть, выдерживать, восстанавливаться и адаптироваться. Это более поздняя концепция, а не свидетельство того, что OVH внедрила в 2017 году. При аккуратном применении она предполагает, что сеть следует оценивать не только по заявлениям о предотвращении, но и по границам деградации, полномочиям на восстановление, сохранению доказательств и адаптации после отказа. [17]

Архитектура оптического транспорта, описанная в рекомендациях ITU, предоставляет словарь для уровней, отношений трактов и защиты. На её основе нельзя восстановить частную топологию OVH по публичным данным. Её ценность здесь в усилении общего положения: оптический транспорт — это управляемая сеть с функциями контроля, супервизии и восстановления, а не просто пассивное стекло. [18]

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

Сохранённая конфигурация не означала операционной доступности

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

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

Изложение событий в Рубе указывает, что инженеры в конечном счёте восстановили сохранённую конфигурацию. Это было успешное действие по восстановлению. Но оно также показывает, что работающая система не сохранила доступность лишь потому, что существовала восстанавливаемая конфигурация. [1][4]

Таким образом, релевантные средства контроля точнее, чем «резервная копия существовала»:

Какой именно объект копировался: полная база данных, сгенерированная конфигурация, состояние устройства или журнал транзакций?
Какой процесс записывал каждую копию и мог ли один дефект ПО испортить их все?
Были ли копии неизменяемыми или независимо версионированными?
Хранились ли они на физически и логически отдельных системах?
Какое правило согласованности определяло, пригодна ли копия к использованию?
Можно ли было выбрать заведомо исправную версию без отказавшего компонента управления?
Было ли восстановление автоматическим, требовало одобрения оператора или зависело от локального доступа?
Сколько времени заняло полное восстановление при последнем тестировании?
Восстановило ли оно предполагаемое состояние или лишь последнее реплицированное состояние?
Какие доказательства подтвердили, что каждый оптический узел и стык с маршрутизатором корректно вернулись в строй?

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

Это различие должно влиять на отчётность перед клиентами и советом директоров. «Конфигурация была зарезервирована» — это инвентаризационное утверждение. «Известно-исправная конфигурация может быть восстановлена по независимому каналу управления за проверенное время с сохранением доказательств и предотвращением повторного внесения неисправного состояния» — это утверждение об операционном контроле.

Оптический транспорт был частью хостинговой услуги

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

Публичные материалы OVH о пиринге и текущие записи PeeringDB и RIPE идентифицируют AS16276 и значительный объём межсоединений. Эти записи полезны для сетевой идентичности и атрибуции оператора. Они помогают клиенту или исследователю отличить сеть OVH от другого провайдера и определить точки возможного межсоединения. Они не доказывают операционное состояние конкретного канала в Рубе в 2017 году, путь, который использовал конкретный пакет, или независимость любых двух клиентских сервисов. [8][9][10][11]

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

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

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

Отчёт Actility даёт поучительный внешний взгляд. В нём говорится, что некоторые сервисы были недоступны, тогда как SaaS-предложение, размещённое в другом дата-центре, не пострадало. В нём также описана достижимость из одних точек или сетей, но не из других. [4] Эта картина согласуется с зависимостью и диверсификацией путей, хотя публичных данных недостаточно, чтобы картировать каждый маршрут или сервис.

Урок для клиента не сводится просто к «используйте двух провайдеров». Многопровайдерная архитектура может снизить концентрацию, но создаёт собственную сложность в DNS, маршрутизации, согласованности данных, безопасности и эксплуатации. Более сильное требование — документировать границы зависимостей и тестировать тот отказ, который действительно важен.

Ущерб должен оставаться привязанным к наблюдаемым свидетельствам

OVH признала прямые последствия для других услуг и сообщила, что получение клиентской электронной почты было особенно затруднено. Компания принесла извинения и заявила, что её команды остаются мобилизованными. [1] Современные публикации описывали значительное влияние на клиентов в среде Рубе. [5][6][7]

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

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

Корректное утверждение об ущербе имеет три слоя:

Ущерб инфраструктуре по данным провайдера:площадка в Рубе потеряла внешние оптические каналы, описанные в отчёте OVH.
Наблюдаемый извне ущерб сервисам:клиенты и как минимум один размещённый провайдер сообщили о частичной или широкой недоступности и конкретных нарушениях обслуживания.
Неизвестный полный ущерб:публичные данные не перечисляют каждого пострадавшего клиента, каждый поток, маршрут, сервис или финансовые последствия.

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

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

Распределение контроля: распределённая ответственность — не отсутствие ответственности

Сетевая инфраструктура пересекает организационные границы. Это может приводить к туманному выводу, что ответственность была «общей». Лучший метод — распределять ответственность в соответствии с контролем.

OVH

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

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

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

Производитель оборудования

Производитель оборудования контролировал разработку продукта, анализ дефекта, исправленное ПО, диагностику поставщика и информацию, доступную OVH. Публичная запись гласит, что OVH проводила расследование совместно с производителем и планировала обновить затронутое ПО. [1][4]

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

Пиринговые и транзитные партнёры

Внешние сетевые операторы контролировали собственные каналы, BGP-сессии, предпочтения маршрутов, мониторинг и эскалацию. Они могли наблюдать потерю достижимости OVH и адаптироваться там, где существовали альтернативные межсоединения. Они не могли восстановить внутреннюю оптическую конфигурацию OVH.

Операционные практики BGP, такие как явные политики импорта и экспорта, важны на междоменных границах. RFC 7454 и RFC 8212 предоставляют более поздние или общие меры защиты маршрутизации, а не диагноз данного оптического инцидента. Они важны потому, что восстановление света само по себе не доказывает корректный обмен маршрутами. После возврата интерфейсов явные политики маршрутизации помогают удержать восстановление путей контролируемым. [15][16]

Клиенты

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

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

Регуляторы, справочники и наблюдатели

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

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

Обнаружение и диагностика — часть поверхности контроля

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

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

Отказы общих элементов управления могут также скомпрометировать мониторинг. Если карта мониторинга, сеть управления или сервис конфигурации разделяют тот же домен отказа, система может потерять и сервис, и объясняющую телеметрию. Инженеры тогда сталкиваются с «тёмным отказом»: широкие симптомы, неполный удалённый доступ и давление перезагрузить оборудование до того, как энергозависимые свидетельства будут сохранены.

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

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

История Рубе показывает, что восстановление оптической системы потребовало больше, чем просто констатации наличия резервной копии. [4] Это превращает время восстановления в архитектурный параметр. Если восстановление зависит от перезагрузки и упорядочения множества компонентов, эти зависимости должны присутствовать в тестах на устойчивость и целевых показателях обслуживания.

Объявленное устранение отделило исправление дефекта от контроля радиуса поражения

Официальный план действий OVH для Рубе состоял из двух частей. Компания планировала расследовать и исправить дефект ПО совместно с производителем путём обновления. Она также ускорила проект по распределению оптической мультиплексирующей системы между двумя отдельными системами, чтобы ограничить масштаб сбоя. [1]

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

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

Следовательно, сильная программа устранения должна тестировать оба измерения.

Исправление дефекта

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

Разделение доменов отказа

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

Доказательства восстановления

Восстановить заведомо исправную конфигурацию без опоры на отказавший компонент управления.
Измерить время обнаружения, принятия решения, восстановления, возврата канала и сходимости маршрутизации.
Сохранить контрольные суммы «до» и «после» и состояние топологии.
Сравнить внутреннее состояние канала с независимыми внешними пробами.
Зарегистрировать остаточные ошибки, а не объявлять полное восстановление после первого успешного ping.

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

Как тестировать независимость резервирования

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

Матрица должна отвечать на простой вопрос для каждой пары «резервированных» путей: какие компоненты всё ещё могут вывести из строя оба?

Такой анализ часто вскрывает зависимости, скрытые топологическими схемами. Отдельные волокна могут входить в одно здание. Разные шасси могут использовать один контроллер. Разные контроллеры могут разделять один кластер баз данных. Разные экземпляры ПО могут получить одну плохую конфигурацию из общего конвейера автоматизации. Разные дата-центры могут зависеть от одного сервиса DNS, идентификации или управления сетью.

Матрица — лишь гипотеза, пока не проверена. Полезные тесты включают:

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

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

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

Независимая работа не требует, чтобы каждый компонент был различным. Полная гетерогенность может увеличить сложность и количество ошибок. Она требует, чтобы общие зависимости были явными, ограниченными и сопоставленными с проверенным восстановлением. Цель — не театр разнообразия. Это доказательство того, что один возможный отказ не может бесшумно поразить каждый путь, заявленный как резервированный.

Контрфактические средства контроля проясняют первые упущенные возможности

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

Если бы дефект ПО был выловлен до развёртывания

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

Если бы оптические системы имели независимое состояние управления

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

Если бы восстановление конфигурации имело независимый путь

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

Если бы клиенты имели независимые пути хостинга

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

Если бы доказательства внешней достижимости были интегрированы

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

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

Доказательства, которые изменили бы вывод

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

Журналы устройств и контроллеров могли бы показать, что потеря конфигурации была следствием, а не причиной. Отчёт поставщика мог бы идентифицировать конкретное аппаратное или программное состояние. Записи топологии могли бы показать, что оптические пути были более независимыми, чем подразумевает публичный отчёт, или что другой общий компонент вывел их из строя. Истории конфигураций могли бы показать, что человеческое изменение, задание автоматизации или переход состояния спровоцировали событие.

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

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

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

Вывод

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

У провайдера были резервные оптические соединения и сохранённая конфигурация. Эти средства контроля адресовали реальные риски. Они не предотвратили того, что общий оптико-управляющий отказ лишил Рубе связности, и восстановление всё равно зависело от возврата конфигурации.

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

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

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

Отказ оптической сети OVH в 2017 году превратил независимость резервирования в проверку подотчётности