Когда даже 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 - напоминание: никакая масштабность и зрелость процессов не спасает от мелких, но критичных ошибок в инфраструктуре. А наша задача, как менеджеров - уметь проектировать так, чтобы даже при падении системы не падали люди: ни по моральному духу, ни по довериям к процессам, ни по коммуникации.
