Когда даже Amazon падает: что менеджеру стоит понять из недавнего сбоя AWS

Amazon выпустили свой пост Мортем, ну а мы с вами его почитаем.
В ночь на 20 октября у AWS случилось то, что не должно было случиться никогда - легла DynamoDB.
И если вы думаете: «да какая мне разница, я же не в Amazon», - зря. Из таких историй стоит делать выводы.

🚨 Что произошло
Один из внутренних компонентов AWS, который отвечает за автоматическое обновление DNS (по сути, «куда ходят» запросы), внезапно удалил адреса у живого сервиса.
И всё - запросы перестали знать, куда идти.
Сначала упала DynamoDB, потом посыпались EC2, балансировщики, Lambda, EKS, ECS - словом, всё, что от неё зависело.
Классическая история про эффект домино, только в масштабе всей североамериканской инфраструктуры.

Что оказалось в корне
Виновата не халатность и не «людской фактор», а состояние гонки (race condition) - ситуация, когда два автоматических процесса пытаются изменить одно и то же, и старое значение перезаписывает новое.
По сути:
Один автомат обновил DNS-запись,
Второй отработал чуть позже и стер то, что уже было исправлено.
Система посчитала, что адрес не нужен, и удалила его.
Звучит как мелочь, но когда в цепочке миллионы клиентов - это мгновенный обвал.

К чему это привело
Невозможно было запустить новые виртуалки (EC2).
Балансировщики удаляли здоровые узлы, думая, что они мертвы.
Сервисы вроде Lambda и EKS висли из-за потери зависимостей.
Даже внутренние инструменты AWS перестали работать, усложнив восстановление.
Проблемы тянулись почти 15 часов.
Даже для Amazon это больно.

🛠️ Что AWS сделала
Переписала логику обновления DNS и устранила состояние гонки.
Ввела дополнительные проверки и «тормоза» для автоматизации.
Улучшила систему зависимости сервисов (чтобы сбой одного не клал всё подряд).
Пересмотрела лимиты и алгоритмы управления нагрузкой.

Что из этого важно нам, менеджерам
Автоматизация - не панацея.
Даже идеально автоматизированная система способна завалить себя же. Нужен контроль, наблюдаемость и механизмы ручного вмешательства.
Зависимости - главная угроза.
Продукт редко падает сам по себе - его валит зависимый сервис.
Чем больше таких связей, тем выше риск каскадного обрушения.
В своих системах важно знать: кто от кого зависит и что будет, если этот кто-то “ляжет”.
“Blast radius” - новый KPI менеджера.
Задача не только в том, чтобы быстро восстанавливаться, но и в том, чтобы сбой не утащил за собой соседние команды и продукты.
То есть проектировать системы так, чтобы падать «локально».
Коммуникация во время кризиса.
AWS держала всех в курсе. И да, это важнее, чем “пофиксить быстро”.
Люди легче переживают инцидент, когда им понятно, что происходит.

Чем проще инженеру понять, что происходит при сбое, тем быстрее компания восстанавливается.
Хорошие инструменты, дашборды, наблюдаемость - это не “для красоты”, это страховой полис.

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