disaster recovery plans

План восстановления после катастрофы описывает, как организация будет действовать при разрушительных событиях, которые делают невозможным нормальное предоставление ИТ-услуги: от серьёзного сбоя ИТ-инфраструктуры до недоступности площадки, потери критичных данных или недоступности ключевого поставщика. На практике это не один документ, а согласованный набор планов и процедур, охватывающий подготовку, реагирование, восстановление и возврат к штатной конфигурации, с учётом людей и компетенций, процессов и потоков создания ценности, информации и технологий, а также партнёров и поставщиков. Такой план обычно опирается на BIA и оценку риска, чтобы определить приоритеты восстановления, целевое время восстановления (RTO) и целевую точку восстановления (RPO) для разных ИТ-услуг и компонентов. Он также задаёт требования к резервному копированию, восстановлению, альтернативным средам, коммуникациям, ролям и полномочиям, тестированию и обучению. Вне охвата плана восстановления после катастрофы находятся повседневые инциденты и стандартные сбои, решаемые управлением инцидентами без переключения на аварийные режимы, а также любые инициативы по улучшению, не связанные напрямую с восстановлением после катастрофы.

План восстановления после катастрофы часто ошибочно приравнивают к управлению непрерывностью услуг. Управление непрерывностью услуг шире: оно определяет стратегию устойчивости и набор мер для обеспечения приемлемого уровня услуги в разных сценариях, тогда как план восстановления после катастрофы концентрируется на конкретных шагах восстановления после катастрофы и возврата к состоянию до катастрофы. Ещё одна типичная путаница — смешение плана с резервным копированием: наличие бэкапов не гарантирует восстановление, если не определены процедуры, ответственные, доступы, зависимости КЕ и порядок восстановления. Частая ошибка — считать, что RTO и RPO задаются «по умолчанию» ИТ; на деле это обязательства, выводимые из BIA и согласуемые с заказчиком, а затем обеспечиваемые ресурсами и архитектурой. Также недооценивают измерение «партнёры и поставщики»: даже идеально выстроенные внутренние процедуры не помогут, если у третьей стороны нет совместимых обязательств, каналов эскалации и возможностей восстановления. Наконец, план нередко существует только «на бумаге»: без регулярных тестов, актуализации после изменений и проверки в рабочей среде он быстро теряет применимость из‑за дрейфа конфигурации, изменений в потоках создания ценности и ролях команд.