28 февраля 2017 года сервис хранения Amazon S3 в регионе US-EAST-1 был недоступен около четырёх часов. Вместе с ним легли тысячи сайтов и сервисов – от трекеров задач до IoT-платформ. По официальному отчёту Amazon, причиной стала опечатка в команде при штатной отладке: инженер вывел из строя больше серверов, чем планировал, и подсистемы хранилища пришлось перезапускать с нуля. Урок здесь не про чужую ошибку. Урок – про то, что вы построили поверх чужого облака.

Один регион – это единая точка отказа

Большинство пострадавших держали данные в одном регионе и считали, что «S3 не падает». S3 даёт 99,99% доступности в пределах региона, но регион целиком – это домен отказа. Если ваша архитектура не переживает потерю региона, значит, вы заложили единую точку отказа на уровне всей платформы.

Что это значит на практике:

  • Реплицируйте критичные бакеты в другой регион через Cross-Region Replication. Для РФ-заказчиков с требованиями 152-ФЗ это отдельный разговор – персональные данные должны храниться на территории России, поэтому резервный контур чаще строят на отечественной площадке или в собственном ЦОД.
  • Не храните в одном хранилище и данные, и механизм восстановления. Во время сбоя многие не смогли поднять резерв, потому что плейбуки и образы лежали в том же S3.
  • Проверьте, что статус-страница и мониторинг не зависят от падающего сервиса. Консоль AWS 28 февраля тоже не открывалась – она использовала S3 для иконок.

Деградация важнее полной недоступности

Зрелая система при отказе зависимости не падает целиком, а теряет функции по очереди. Если объектное хранилище недоступно, приложение должно отдавать кэш, заглушку или сообщать об ошибке предсказуемо – а не висеть до таймаута, утягивая за собой остальные сервисы.

Это вопрос границ между компонентами. Чёткий контур интеграции, таймауты и предохранители (circuit breaker) удерживают локальный сбой локальным. Мы подробно разбирали этот подход на примере API-шлюзов перед legacy-системами: тот же принцип изоляции работает и для зависимостей от внешнего облака. Если один вызов к хранилищу зависает, шлюз обязан разорвать цепочку, а не ждать.

Сбой нельзя предотвратить – к нему готовятся

Отказоустойчивость не покупается галочкой в облачной консоли. Её проектируют и регулярно проверяют учениями. Раз в квартал отключайте регион или сервис в тестовом контуре и смотрите, что выживет. Большинство планов аварийного восстановления красивы на бумаге и нерабочи на практике – ровно потому, что их ни разу не запускали.

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

Вывод

Сбой S3 – это не аргумент против облака, а напоминание: ответственность за доступность вашего сервиса лежит на вас, а не на провайдере. Один регион, общее хранилище для данных и восстановления, непротестированный план DR – три типовые ошибки, которые превращают четырёхчасовой инцидент у поставщика в репутационный ущерб у заказчика. Мультирегиональные и гибридные контуры с учётом 152-ФЗ и регулярный аудит отказоустойчивости инфраструктуры – то, что не даёт следующему чужому сбою стать вашим.