Кратко

  • DigitalOcean перевёл инцидент с подключением томов Volumes в пяти локациях в режим мониторинга 19 июля в 14:52 UTC, сообщив, что его инженерная команда установила первопричину и успешно применила исправление.
  • Компания сообщает, что подключение теперь должно работать вNYC1,NYC3,SGP1,SYD1иBLR1, но не раскрыла, в чём состояла первопричина и связывала ли все пять локаций одна и та же техническая зависимость.
  • Мониторинг — это не устранение проблемы. Клиентам всё равно нужно проверить собственный путь подключения, подтвердить итоговое состояние ресурса и точку монтирования и сохранить ошибки и метки времени, а не считать общее уведомление провайдера доказательством восстановления аккаунта.

DigitalOcean сообщил, что устранил сбой, из-за которого часть клиентов не могла подключать сетевое блочное хранилище к Droplet в пяти локациях. Его обновление полезно с операционной точки зрения, но информационно неполно.

19 июля в 14:52 UTC компания заявила, что её инженерная команда установила первопричину и успешно применила исправление. Клиенты «снова смогут» подключать тома Volumes без ошибок и проблем, говорится в сообщении. Инцидент перешёл из статуса «расследование» в статус «мониторинг» и охватываетNYC1,NYC3,SGP1,SYD1иBLR1.

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

Восстановление начинается с операции управления

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

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

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

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

«Установлена» — не значит «раскрыта»

Фраза «первопричина установлена» закрывает внутренний инженерный вопрос. Она не закрывает архитектурный вопрос клиента.

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

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

Зелёный статус — не проверка аккаунта

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

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

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

SLA по-прежнему требует свидетельств от клиента

SLA DigitalOcean на тома Volumes предусматривает обязательство по ежемесячной доступности 99,99 %. SLA определяет недоступность как отказ всех запросов к ресурсу в течение более пяти минут и требует, чтобы клиент подал заявку, которую DigitalOcean затем проверяет.

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

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

Источники