Потеря дисков Google Cloud в Бельгии: где локальность перестаёт быть устойчивостью

Краткое содержание

• В августе 2015 года диски Google Compute Engine Standard Persistent Disks в зоне europe-west1-b испытывали ошибки чтения после четырёх последовательных ударов молнии, затронувших местную энергосеть, которая питала европейский дата-центр. Google позднее сообщил, что очень небольшая доля выделенного пространства Persistent Disk в зоне потеряла недавние записи без возможности восстановления.
• Вопрос ответственности не в том, был ли процент большим. Вопрос в том, понимали ли клиенты, что зональный Persistent Disk, даже с управляемой провайдером избыточностью внутри зоны, всё ещё находится внутри физической зоны отказа и не заменяет независимые снапшоты, региональную репликацию или резервное копирование на уровне приложения.
• Google контролировал устойчивость физической площадки, восприимчивость оборудования для хранения, обработку сбоев питания, формулировки о долговечности Persistent Disk, отчётность о статусе и ясность рекомендаций по резервному копированию. Клиенты контролировали архитектуру рабочих нагрузок, графики снапшотов, цели восстановления, выбор репликации и то, не путались ли требования к локальности с восстанавливаемостью.
• Практическая запись об устранении должна различать восстановленный сервис, невосстановимые данные, доступный обходной путь через снапшоты, изменения в оборудовании и программном обеспечении, рекомендации по резервному копированию и свидетельства клиентов. При облачном инциденте с потерей данных зелёная страница статуса не может быть единственным доказательством восстановления.

Крошечный процент всё равно может означать жёсткий отказ

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

Публичныйинцидент Compute Engine № 15056компании Google начался 13 августа 2015 года для Persistent Disks в europe-west1-b. Страница статуса сначала сообщила об ошибках чтения у клиентов с машинами в этой зоне, затем объяснила, что менее 1 процента дисков в зоне могут быть подвержены ухудшению производительности, а затем — что менее 0,1 процента испытывают ошибки чтения на некоторых блоках. Запись об инциденте также сообщала пострадавшим клиентам, что восстановление из снапшотов является обходным путём, а создание новых Persistent Disks и восстановление из снапшотов не затронуты.

Сообщения СМИ, зафиксировавшие более позднее объяснение инцидента, включаярепортаж Дата-центр Dynamics об ударах молнии и потере данныхиматериал Silicon UK о причине сбоя, зафиксировали заявление Google о том, что четыре последовательных удара молнии в местную энергосеть привели к кратковременной потере питания систем хранения, обслуживающих дисковые мощности для экземпляров GCE в europe-west1-b. Google сообщил, что почти все данные были записаны в стабильное хранилище, но в очень редких случаях недавние записи оказались невосстановимыми, что привело к безвозвратной потере данных на Persistent Disk.

Широко повторяемая цифра составила менее 0,000001 процента выделенного пространства Persistent Disk в затронутой зоне.

Эта запись поддерживает и сдержанность, и серьёзность. Было бы неверно описывать событие как массовое уничтожение данных в Google Cloud. Затронутым сервисом был Standard Persistent Disk в одной зоне; SSD Persistent Disk, снапшоты и Local SSDs, согласно индексам посмертных отчётов и современным публикациям, не входили в совокупность безвозвратных потерь. Было бы также неверно отмахнуться от инцидента из-за огромного знаменателя. Долговечность данных — бинарный факт для той записи, которая имеет значение. Крошечный невосстановимый процент — всё равно безвозвратная потеря для кого-то.

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

Локальность и долговечность — не одно и то же обещание

Облачная локальность решает реальные задачи. Клиент может выбрать europe-west1 ради задержки для бельгийских или европейских пользователей, по причинам закупок, ради снижения углеродного следа или из-за обязательств по месту размещения данных. Текущаястраница расположений облакаGoogle и документация Compute Engine орегионах и зонахобъясняют, что ресурсы живут в регионах и зонах и что зоны и регионы — логические абстракции физических ресурсов. Эта абстракция полезна, потому что клиентам не нужно управлять зданиями. Она опасна, если клиент делает вывод, что зональный ресурс ушёл из физической зоны отказа.

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

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

Это разные измерения.

Текущиеусловия о месте размещения данныхGoogle и материалы о европейских обязательствах определяют, где могут находиться данные клиента для поддерживаемых сервисов. Они не превращают каждый локальный ресурс в независимую резервную копию. Аналогично страница продукта Persistent Disk описываетдолговечное блочное хранилище, а документация Compute Engine поPersistent Disksутверждает, что Persistent Disk имеет встроенную избыточность для защиты от отказа оборудования и поддержания доступности данных во время событий обслуживания. Это значимые обязательства провайдера.

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

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

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

Физический триггер принадлежит записи об облачной ответственности

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

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

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

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

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

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

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

Рекомендации по снапшотам — где разделённая ответственность становится конкретной

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

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

Согласованность с приложением остаётся заботой клиента. Снапшот диска фиксирует состояние блоков; базе данных может потребоваться завершение транзакций, сброс буферов или скоординированные операции резервного копирования, чтобы восстановленное состояние стало пригодным.Документация Google по согласованным с приложением снапшотам Linuxобъясняет расписания снапшотов с сбросом гостевой ОС. Важна не точная совокупность функций в 2015 году против нынешней. Важен устойчивый принцип контроля: восстанавливаемость требует процесса резервного копирования, согласованного с приложением, а не только обещания провайдера о хранилище.

Небольшие команды особенно подвержены этому разрыву. Стартап или муниципальный проект может выбрать одну облачную зону для снижения задержки и стоимости. Он может запустить базу данных на Persistent Disk и положиться на название продукта и репутацию провайдера как на замену проектированию резервного копирования. У него может не быть выделенного инженера по хранилищам, протестированного процесса восстановления или анализа влияния на бизнес. Инцидент 2015 года показывает, почему документация и значения по умолчанию важны: клиентам с меньшей внутренней экспертизой нужны варианты хранилища и предупреждения, делающие границу зоны отказа очевидной.

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

Ни одна сторона не может полностью выполнить работу другой.

Региональные диски и репликация меняют модель отказа, но не отменяют необходимость мышления о восстановлении

Google теперь предлагает региональные Persistent Disks и варианты высокой доступности Hyperdisk.Документация по региональным дискамобъясняет диски, реплицированные между зонами в регионе для более высокой доступности, аруководство по переключению региональных дисковописывает принудительное подключение при отказе основной зоны. Блог Google орегиональных Persistent Disks для высокодоступных рабочих нагрузокделает сценарий доступности явным.

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

Реплицированный диск — это механизм высокой доступности; он не обязательно является полной программой защиты данных.

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

Текущее соглашение об уровне обслуживанияCompute Engine и историческаяверсия SLA 2015 годапоказывают ещё одно различие. SLA касаются доступности сервиса и кредитов при определённых условиях. Они не являются полным заявлением о восстанавливаемости или бизнес-потере. Кредит может компенсировать часть платы за сервис, пока клиент всё равно должен восстанавливать данные, сверять транзакции, уведомлять пользователей или восстанавливать доверие. Тот факт, что страница статуса велела пострадавшим клиентам восстанавливаться из снапшотов, показывает, что операционное восстановление лежало вне вопроса кредитов по SLA.

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

Доказательства восстановления клиента — часть инцидента

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

Повторные проценты воздействия на странице статуса были полезны, потому что избегали расплывчатых заверений. Менее 1 процента подвержены, менее 0,1 процента с ошибками чтения и менее 0,000001 процента безвозвратных потерь описывают сужающиеся категории. Их не следует сливать в одно заявление. Подверженные диски, активно отказывающие диски и невосстановимые данные — разные состояния. Клиенту в каждом состоянии нужно разное действие.

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

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

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

Закупки не должны покупать регион так, как будто это резервная копия

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

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

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

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

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

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

Аудиторы должны остерегаться ответов из чек-листов. «Данные хранятся в Европе» не отвечает на вопрос, можно ли их восстановить. «Persistent Disk долговечен» не отвечает на вопрос, выдержит ли приложение потерю недавней записи. «Снапшоты доступны» не отвечает на вопрос, были ли они настроены, свежи, полны и протестированы. «У провайдера есть SLA» не отвечает на вопрос, есть ли у клиента пригодная копия. Аудиторские доказательства должны включать результаты тестов восстановления, возраст резервной копии, место резервной копии, доступ к ключам и запись о том, кто принял остаточный риск.

Небольшим командам нужны значения по умолчанию, делающие восстанавливаемость видимой

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

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

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

Если команда не может позволить себе дизайн восстановления, это должно быть осознанным бизнес-решением.

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

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

Потеря данных меняет моральный вес языка статуса

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

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

Точность поэтому не декоративна; она управляет реакцией клиента.

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

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

Решения о локальности должны включать историю выхода

Каждое решение о локальности должно включать историю выхода: если этот выбор зоны, региона или локального хранилища откажет, куда пойдёт рабочая нагрузка и какие данные последуют за ней? Клиенту, выбирающему europe-west1-b в 2015 году, нужно было знать, можно ли восстановить отказавший диск в другой зоне, существует ли снапшот вне отказавшей системы, может ли приложение подключить восстановленный диск и могут ли DNS, учётные данные и операторы вернуть сервис. Эти вопросы остаются актуальными, даже если названия продуктов и функции изменились.

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

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

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

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

Неизвестности и осторожные границы

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

Публичная запись, однако, поддерживает несколько твёрдых выводов. Событие затронуло Persistent Disks в europe-west1-b. Клиенты испытывали ошибки чтения. Google указал пострадавшим клиентам восстанавливаться из снапшотов. Современные отчёты, основанные на заявлении Google, описывали четыре последовательных удара молнии в местную энергосеть, кратковременную потерю питания систем хранения, восприимчивость оборудования в подмножестве хранилища и безвозвратную потерю крошечной доли выделенного пространства Persistent Disk. Google заявил, что проведёт проверку стека и модернизирует оборудование хранения.

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

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

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

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

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

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

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

Этот владелец также должен иметь полномочия финансировать резервное копирование.

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

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

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