Сбой AWS DynamoDB: Предупреждение о том, что архитектурные пробелы страшнее состояния гонки

В октябре 2025 года сердце облачного мира — регион AWS US-EAST-1 — остановилось. EC2 перестали создаваться, а Lambda начали отклонять запросы. В конце каждой цепочки падающих домино стояла DynamoDB. В официальном отчете AWS назвала это потенциальным состоянием гонки (race condition). Но было ли это просто вопросом неудачного тайминга? Глазами старшего инженера это событие выглядит как катастрофа, вызванная логическими дефектами распределенной системы и отсутствием механизмов восстановления.

Изнанка сложной системы распределения трафика

Для обеспечения высокой доступности DynamoDB использует древовидную структуру DNS и записи на основе весов. Трафик управляется тремя ключевыми компонентами:

Компонент	Роль	Принцип работы
DNS Planner	Расчет пропорций распределения трафика	Создание планов оптимизации на уровне региона
DNS Enactor	Обновление записей Route 53	Независимое выполнение в 3-х AZ
DWFM	Координация всего рабочего процесса	Оркестрация распространения обновлений

Система спроектирована так, что при возникновении проблем на определенном участке вес становится равным 0, тем самым блокируя трафик. Теория была безупречна, но в реальной эксплуатации сработала непредвиденная переменная.

Худший сценарий: когда перезапись встречается с удалением

В день инцидента из-за резкого скачка нагрузки обработка в Enactor 1 замедлилась. Тем временем Enactor 2 применил последнюю версию — План 102. В этот момент запустилась фатальная цепная реакция.

Сначала «проснувшийся» с опозданием Enactor 1 перезаписал актуальные данные устаревшим Планом 100 поверх свежей информации. На последующем этапе очистки Enactor 2 начал удалять старые записи, которые не входили в текущий (по его мнению) План 102. Данные, которые только что восстановил Enactor 1, с точки зрения Enactor 2 были лишь мусором под удаление. В итоге DNS-запись основного эндпоинта DynamoDB просто испарилась.

Настоящая проблема — отсутствие логики восстановления

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

Как только эндпоинт исчез, системы, отвечающие за восстановление, по цепочке начали выдавать исключения во время выполнения (runtime exceptions). Код Enactor не предполагал состояния, в котором запись отсутствует вовсе. Подобно ошибке управления памятью Use-after-free, система пыталась сослаться на уже исчезнувший объект и рухнула.

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

Уроки за рамками официального отчета

AWS заявила о внедрении функций ограничения скорости (rate limiting). Это лишь облегчает симптомы, но не является фундаментальным лечением. Пока система не обретет способность распознавать аномальные состояния и исцелять себя, подобные трагедии будут повторяться.

Категория	Официальное объяснение	Инсайт эксперта
Причина сбоя	Конфликт одновременных обновлений	Отсутствие валидации в момент записи (CAS)
Проявление сбоя	Остановка автоматизации	Недоработка дизайна безопасного отказа (Safe Default)
Меры противодействия	Ограничение скорости обновлений	Обеспечение идемпотентности логики восстановления

Проектируйте системы, которые умеют «падать достойно»

Этот инцидент 2025 года доказывает вес одной строчки кода. Инфраструктуру стоимостью в миллиарды долларов обрушил не масштабный взлом, а крошечная недоработка в обработке исключений — отсутствие определения того, как действовать при пустой DNS-записи.

Суть инженерии не в создании сложных функций. Это способность спроектировать систему так, чтобы в случае непредвиденного сбоя она «падала достойно» (graceful degradation) и гарантированно восстанавливалась.

Обязательный чеклист для обеспечения стабильности:

• Проверка отката: работает ли система с безопасными значениями по умолчанию, когда данные для ссылки отсутствуют?
• Гарантия атомарности: защищен ли разрыв между проверкой (Check) и использованием (Use) с помощью CAS или аналогичных механизмов?
• Управление зависимостями: существует ли стратегия сохранения минимальной функциональности при разрыве соединения с основной БД?

Настоящий профессионал — это тот, кто неустанно спрашивает не только о том, как система упала, но и почему она не восстановилась. Готова ли ваша система к безопасному отказу прямо сейчас?