Кратко

  • DigitalOcean предупреждала об ошибках создания кластеров Managed Databases через Cloud Control Panel и API; публичная запись не описывает общий отказ уже работающих баз данных.
  • От начала до наблюдения прошло 6 часов 18 минут 57,959 секунды, до решения — 9 часов 21 минута 54,719 секунды; заявленная география менялась от Global и нескольких регионов до NYC1 и NYC3.

Операционный регламент становится опасно грубым, если в нём есть только два состояния: «база работает» и «база не работает». Инцидент DigitalOcean «Managed Databases Creation» показывает как минимум четыре контрольные точки. Запрос может быть отклонён, принятый ресурс может остаться в creating, готовый кластер должен перейти в online, а ранее созданные базы имеют собственное состояние.

Запись началась 23 августа в 05:11:37 UTC. DigitalOcean расследовала проблему с продуктом Managed Database и сообщила, что пользователи могут видеть ошибки при создании кластеров как через Cloud Control Panel, так и через API-запросы. Компонент Managed Databases - Global был переведён из operational в degraded_performance.

В 07:06:56 компания уточнила, что проблема создания затрагивает несколько регионов. Инженеры внедряли меру для восстановления нормального предоставления ресурсов. В обновлении не было списка регионов, количества клиентов, доли неудачных запросов или сравнения поведения панели и API.

В 11:30:34 DigitalOcean объявила о необходимых исправлениях для создания кластеров в NYC3 и NYC1. По словам провайдера, пользователи уже должны были снова создавать новые кластеры; команда перешла к наблюдению за стабильностью. В 14:33:31 инцидент был закрыт как решённый.

Между началом записи и переходом к наблюдению прошло 6 часов 18 минут 57,959 секунды. Наблюдение продолжалось 3 часа 2 минуты 56,760 секунды. Полный публичный интервал до решения составил 9 часов 21 минуту 54,719 секунды.

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

География тоже менялась. Сначала использовался компонент Global, затем говорилось о нескольких регионах, а исправление и решение были связаны с NYC1 и NYC3. Из записи нельзя установить, сузило ли расследование область, восстановились ли другие регионы раньше или начальная категория была просто широкой.

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

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

Документация DigitalOcean позволяет построить нормальную последовательность. Клиент может создать кластер через панель, doctl или API. Для API описан вызов POST /v2/databases, где среди обязательных параметров задаются движок, регион и размер.

Успешно принятый вызов ещё не означает готовность. В документации Python-клиента новый объект базы сначала имеет статус creating. Он становится online, когда готов принимать трафик. Руководство по PostgreSQL отмечает, что обычное предоставление ресурсов занимает пять минут или больше.

Следовательно, сообщение в 11:30 о восстановлении создания прежде всего относится ко входу в процесс. Новый запрос мог быть принят, но его ресурс всё ещё проходил штатную асинхронную подготовку. Момент появления объекта, переход в online и первая успешная связь — отдельные точки восстановления.

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

Последние строки компонентов дают ещё один повод не сводить всё к цвету. NYC1 и NYC3 записаны как operational до и после обновления, хотя текст описывает исправление и решение проблемы создания. Агрегированное состояние региона не является проверкой конкретной транзакции плоскости управления.

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

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

В публичной системе инцидент решён. Его корректный смысл уже, чем «базы DigitalOcean не работали девять часов»: провайдер нарушил возможность создавать новые управляемые кластеры, сначала описал широкий многорегиональный охват, затем назвал NYC1 и NYC3 и не опубликовал внутреннюю причину.

Источники