Резервный ЦОД есть. А план восстановления проверен?
После сообщений об атаках на дата-центры Яндекса вопрос резервирования стал особенно практическим: как продолжить работу, если основная площадка недоступна надолго, а часть привычных сервисов — тоже? Для компаний это повод пересмотреть собственные сценарии восстановления. Какие события они учитывают? Какие ресурсы потребуются? Что уже проверено на практике? Фраза «у нас есть резерв» оставляет немало вопросов. → Доступны ли резервные копии независимо от основной площадки? Проверяли ли восстановление из них? → Смогут ли сотрудники получить доступ к системам, если привычный сервис авторизации недоступен? → Хватит ли резерву мощности под рабочей нагрузкой? → Сохранятся ли необходимые сетевые связи и внешние интеграции? → Что делать, если затронута не одна площадка? Даже исправное переключение не поможет, если на резервной стороне отсутствует важная зависимость. Поэтому проверка начинается с бизнес-задач: какие операции нужно восстановить первыми, сколько времени допустим простой и какой объём последних данных допустимо потерять. Дальше — пять практических шагов. Выбрать критичный сервис и разобрать всю цепочку его работы: приложение, данные, сеть, доступы, внешние системы. Проверить независимость резерва. Две площадки могут зависеть от одного канала связи, сервиса управления или хранилища резервных копий. Согласовать сценарии испытаний, условия проведения, критерии остановки и порядок возврата к штатной работе. Отдельно рассмотреть переключение на резерв и восстановление из копий. Провести проверку под согласованной нагрузкой. Зафиксировать время восстановления, состояние данных и возможность завершать ключевые операции — например, оформить заказ или провести платёж. Устранить найденные ограничения, повторить испытания и закрепить процедуру в регламенте. После существенных изменений в инфраструктуре возвращаться к проверкам. Результат — понимание, какие сценарии система выдерживает, сколько занимает восстановление в проверенных условиях и что нужно улучшить. В Performance Lab мы подготовили комплексную услугу проверки резервирования: аудит систем и зависимостей, испытания восстановления, проектирование отказоустойчивой архитектуры, регламент и учения. Начать можно с одного критичного сервиса. Определить его зависимости, согласовать требования к восстановлению и выбрать сценарий первой проверки. Это даст основу для решений о приоритетах и бюджете. Последние события уже изменили ваши планы по резервированию и аварийным учениям? Напишите в комментариях, стала ли эта задача приоритетнее. Если хотите обсудить, с какого сервиса начать проверку, — напишите мне в личные сообщения. #Отказоустойчивость #Резервирование #Тестирование #PerformanceLab
· 21.10
Добавлю шестой шаг с аудиторской стороны. В сценариях восстановления проверяют сервисы и данные, а бухгалтерские документы обычно остаются за кадром. По ст. 29 закона № 402-ФЗ ответственность за их сохранность лежит на самой организации, и недоступность площадки провайдера её не снимает. Отсюда вопрос для испытаний: сможете ли вы предъявить первичку и регистры за любой период срока хранения, если основная площадка недоступна. У вас этот контур входит в аудит систем или идёт отдельно?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 21.10
Татьяна, спасибо за шестой шаг! Действительно, «система восстановлена» и «бухгалтер может достать нужную первичку» разные результаты.
Я бы включал доступность документов в общий сценарий восстановления, а состав проверки согласовывал отдельно с бухгалтерией: какие документы берём, за какие периоды и за какое время должны их получить. При этом проверка правил хранения и полноты архива отдельная задача.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 21.10
Согласна про хранение, это отдельная история
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён