Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
В октябре 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) и гарантированно восстанавливалась.
Обязательный чеклист для обеспечения стабильности:
Настоящий профессионал — это тот, кто неустанно спрашивает не только о том, как система упала, но и почему она не восстановилась. Готова ли ваша система к безопасному отказу прямо сейчас?
