Облако недоступно. А ваш бизнес готов? Пять проверок до аварии

Недавняя история с тремя ЦОДами Яндекса показала: физическая инфраструктура крупного провайдера тоже уязвима. Компания сообщила об остановке площадок в Сасово и Владимире и выходе из строя части инфраструктуры в Калуге.

Мы уже обсуждали физический уровень отказоустойчивости. Теперь — пять проверок своей системы.

Когда облачный провайдер физически теряет доступность дата-центров, архитектурная надёжность вашей системы проверяется не кодом — а тем, где живут ваши резервы, как давно вы их восстанавливали и кто принимает решение о переходе.

Готовность к такой аварии зависит от размещения резервов, проверенного восстановления и порядка переключения.

1. Где физически находятся система и резервные копии?

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

Проверьте, сможете ли забрать резерв без доступа к основному облаку.

2. Какие зависимости общие у основного и резервного контуров?

Уточните, кто фактически предоставляет инфраструктуру. Разные названия компаний не доказывают независимость площадок.

Проверьте также сеть, DNS — службу адресации, учётные записи и доступ к ключам. Второе облако не поможет, если переключение требует недоступного компонента первого.

3. Когда систему действительно восстанавливали?

Поднимите её из копии в отдельном окружении. Проверьте вход, чтение данных и выполнение основной операции — например, создание заявки.

Бэкап, который ни разу не восстанавливали — это гипотеза, а не план.

Зафиксируйте дату проверки, результат и фактическое время восстановления.

4. За какое время нужно вернуть сервис?

Согласуйте RTO — целевое время восстановления. Отдельно оцените максимально допустимый простой бизнеса: целевой срок должен в него укладываться.

Уточните RPO — допустимую потерю последних данных по времени. Восстановить систему быстро, но без заказов за день — отдельный риск.

5. Кто и по какому порядку запускает переход на резерв?

Назначьте ответственного и замещающего. Опишите условия переключения, шаги, необходимые доступы и проверку результата. При автоматическом переходе тоже нужны ответственный и порядок вмешательства.

«Разберёмся на месте» оставляет решение на момент, когда времени уже мало.

Граница надёжности проходит через готовность команды и инфраструктуры к переключению.

Недоступность облака стоит рассматривать как сценарий для подготовки. Практический вопрос — что вы сделаете в этот момент?

Вы когда-нибудь проверяли, получится ли восстановить ваши данные из резервной копии?

Первоначальная публикация: TenChat.