Представьте, что однажды утром ваша система мониторинга молчит, биллинг пуст, а сайт недоступен — не потому что упал сервер (и даже не потому, что опять упал Kubernetes), а потому что ваш облачный провайдер просто растворился в воздухе, прихватив с собой все ваши бэкапы. Звучит как параноидальный сценарий для ночного совещания DevOps-отдела, но для команды Nine PBS это превратилось в суровую реальность, когда на кону внезапно оказались 70 лет истории и 50 терабайт уникальных архивов.

Введение: когда облако превращается в черный ящик

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

Именно в такой кошмарный сценарий попала аффилированная станция общественной телерадиовещательной сети PBS в Сент-Луисе — Nine PBS. На кону стоят 50 терабайт уникальных исторических материалов, охватывающих 70 лет работы архива. Эта история поднимает острые вопросы для системных администраторов, DevOps-инженеров и CTO по всему миру: от рисков непрямых контрактов до отсутствия адекватных стратегий резервного копирования и восстановления данных при внезапном исчезновении вендоров.

Анатомия инцидента: хроника пропажи 50 терабайт истории

Масштаб катастрофы, с которой столкнулась Nine PBS, трудно переоценить. В зоне риска оказались более 11 000 уникальных медиафайлов общим объемом около 50 ТБ. Этот массив информации представляет собой культурное достояние региона: видеоматериалы о Великом наводнении 1993 года, хроники пандемии COVID-19, репортажи и документальные свидетельства семидесятилетней истории вещания.

Схема взаимодействия вещателя с IT-инфраструктурой имела классический для многих организаций изъян:

  • Nine PBS арендовала облачное хранилище у компании Open Source Storage (OSS).
  • Сама компания OSS не владела собственными дата-центрами, а размещала серверное оборудование на физических мощностях крупного игрока — Iron Mountain Data Centers в Денвере.

Проблемы начались, когда провайдер OSS прекратил свою деятельность и фактически „исчез с радаров“, перестав отвечать на запросы клиентов. Когда инженеры и юристы Nine PBS попытались напрямую обратиться в Iron Mountain с требованием вернуть доступ к серверам, они столкнулись с жестким отказом. Оператор дата-центра сослался на корпоративные политики, отсутствие прямого договора между Nine PBS и Iron Mountain, а также на юридические коллизии, связанные с имуществом неплатежеспособного партнера.

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

Технические и юридические ловушки многоуровневой аренды

С точки зрения архитектуры, использование субподрядных облачных решений (Reseller / White-label Cloud) всегда несёт скрытые риски. DevOps-специалисты часто фокусируются на доступности API и пропускной способности канала, забывая про Disaster Recovery Plan на случай банкротства или исчезновения контрагента.

Основные проблемы подобных схем:

  • Юридический вакуум: Прямого SLA между владельцем железа (Iron Mountain) и конечным пользователем (Nine PBS) не существует.
  • Отсутствие изоляции данных: На арендованных серверах могут храниться данные разных клиентов OSS, что делает невозможным простую выдачу „физического диска“ без риска нарушения конфиденциальности.
  • Зависимость от одного провайдера (Vendor Lock-in): Отсутствие гео