9.5 Аварийное восстановление и непрерывность бизнеса

Обзор и мотивация

Рано или поздно что-то, чего вы не планировали, обрушит систему: сбой облака во всём регионе, неловко набранный DROP TABLE, наводнение в центре обработки данных, взрыв вируса-вымогателя или поставщик, исчезнувший за ночь. Вопрос никогда не в том, придёт ли сбой, а в том, как быстро вы восстановитесь и сколько потеряете в процессе. Эта глава о готовности к плохому дню до его прихода.

На эту готовность отвечают две дисциплины, и они не одно и то же. Планирование непрерывности бизнеса (BCP) поддерживает работу всей организации через сбой: людей, офисы, коммуникации, расчёт зарплаты и критичные бизнес-процессы, от которых зависят клиенты. Аварийное восстановление (DR) более узкая техническая работа по восстановлению ИТ-систем и данных после их отказа. Непрерывность цель; восстановление одно из средств. Можно восстановить каждый сервер и всё равно подвести клиентов, если никто не знал, кому разрешено объявить катастрофу или как до них дозвониться. Эта глава воспринимает DR как инженерную практику, а BCP как бизнес-рамку, которой она служит.

Для больших команд ставки растут вместе с вами. Корпорация несёт регуляторные обязательства по восстановлению, присутствие в нескольких регионах и риск концентрации в горстке поставщиков. Государство несёт юридический долг поддерживать основные функции для граждан, закодированный как непрерывность операций. Обе работают под пристальным вниманием, где непроверенный план обязательство, которое вы обнаружите в худший момент. Восстановление то место, где надёжность (глава 9.1) и реагирование на инциденты (глава 9.3) встречаются с более трудным вопросом выживания при отказах, которые нельзя исключить проектом.

Ключевые принципы

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

Рекомендации

Задавайте RTO и RPO по анализу влияния на бизнес

Каждое решение о восстановлении происходит от двух чисел, поэтому сначала получите их верными. Целевое время восстановления (RTO) это то, как долго система может быть недоступна, прежде чем вред станет неприемлемым. Целевая точка восстановления (RPO) это то, сколько данных вы можете позволить себе потерять, измеряемое как возраст последней хорошей копии, до которой можно восстановить. Платёжной книге может требоваться RTO в минуты и RPO около нуля; внутренняя аналитическая панель может терпеть день того и другого. Задать это в инженерии нельзя. Выводите их из анализа влияния на бизнес (BIA), ранжирующего бизнес-процессы по цене их сбоя и прослеживающего каждый до систем и данных, которые ему нужны. Более жёсткие цели стоят дороже, поэтому BIA то, что не даёт вам золотить тривиальный сервис и недозащищать критичный.

Делайте резервные копии правильно: правило 3-2-1, неизменяемость и тестирование

Резервные копии пол под каждой стратегией восстановления, и большинство организаций делают их хуже, чем думают. Следуйте дисциплине резервного копирования, известной как правило 3-2-1: держите по меньшей мере три копии данных, на двух разных носителях или системах, с одной копией вне площадки. Современные угрозы добавляют ещё два требования. Держите по меньшей мере одну копию неизменяемой (однократная запись, не удаляемая в течение окна хранения) и в идеале отключённой или с воздушным зазором, потому что вирусы-вымогатели теперь намеренно шифруют или удаляют доступные резервные копии, прежде чем объявят о себе. Прежде всего тестируйте восстановления по расписанию. Непроверенная резервная копия не резервная копия, а непроверенное допущение, и отказы, которые вы находите на учениях (повреждённые архивы, недостающие ключи шифрования, резервные копии не того тома), именно те, что покончили бы с вами в настоящем событии.

Выбирайте стратегию DR по спектру цены против скорости

Стратегии DR меняют деньги на скорость восстановления, и вам следует выбирать для каждой системы по её RTO и RPO, а не покупать один ярус для всего. Спектр опирается на четыре шаблона. Резервное копирование и восстановление самое дешёвое и медленное: вы перестраиваете из резервных копий, когда приходит катастрофа, с RTO от часов до дней. Pilot light держит минимальное ядро (базы данных реплицируются, основная конфигурация на месте) тёплым, но уменьшенным, готовым расшириться. Тёплый резерв ведёт меньшую всегда включённую копию полного стека, которую вы наращиваете при переключении, сокращая RTO до минут. Многоплощадочный active-active ведёт полную мощность в двух или более местах, обслуживающих живой трафик, давая почти нулевое RTO по высочайшей цене и сложности. Подбирайте ярус под число, которое подписал бизнес, и не платите цены active-active за систему, терпящую pilot light.

Реплицируйте данные с учётом компромисса согласованности

Скорость восстановления зависит от того, насколько актуальны данные вашего резерва, и здесь вы наследуете трудные проблемы распределённых систем (глава 3.3). Синхронная репликация подтверждает каждую запись во втором месте перед её подтверждением, давая RPO около нуля ценой добавленной задержки записи и жёсткого предела расстояния. Асинхронная репликация подтверждает локально и отправляет изменения после, поэтому она быстра и географически гибка, но оставляет окно отставания репликации, которое вы потеряете при переключении. Бесплатного выбора нет: более сильная согласованность стоит задержки, более слабая стоит данных. Решайте для каждого хранилища данных по его RPO и знайте ваше типичное отставание репликации, потому что это отставание ваше реальное RPO в плохой день, а не число в проектном документе.

Перестраивайте из кода с инфраструктурой как кодом

Вы не можете надёжно восстановить среду, подготовленную вручную, потому что никто не помнит каждый щелчок. Определите свои среды как инфраструктуру как код (глава 8.2), чтобы весь стек можно было воссоздать из исходников под контролем версий в заведомо хорошем состоянии. Это превращает восстановление из археологического проекта в повторяемый запуск конвейера, держит ваш резервный регион честным (он меньше дрейфует, когда оба построены из одного кода) и даёт чистый способ поднять инфраструктуру восстановления в свежей учётной записи или регионе после компрометации. Храните код, ссылки на секреты и ранбуки там, где они переживут потерю вашей основной среды.

Картируйте зависимости до того, как они понадобятся

Системы отказывают сетями, а не изолированно, и восстановление застревает на зависимости, которую вы забыли. Картируйте то, что нужно каждой критичной системе для работы: вышестоящие сервисы, DNS, идентификацию и аутентификацию, центры сертификации, очереди сообщений и сторонние API и поставщиков SaaS. Отметьте порядок восстановления, потому что подъём приложения раньше его базы данных или поставщика идентификации просто производит второй сбой. Уделите особое внимание внешним поставщикам, поскольку ваше восстановление ограничено их восстановлением, а видимости в него у вас может не быть. Это картирование напрямую связано с устойчивостью и изящной деградацией (глава 3.5): чем меньше жёстких зависимостей у системы, тем быстрее она возвращается.

Тестируйте восстановление как практику, а не событие

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

Планируйте кибервосстановление как отдельный сценарий

Вирусы-вымогатели и разрушительные кибератаки ломают допущения обычного DR, поэтому воспринимайте их отдельно. При стихийном бедствии ваши данные целы в другом месте; при событии вируса-вымогателя ваши данные и нередко резервные копии оружие, а ваша среда восстановления сама может быть скомпрометирована. Планируйте восстановление в чистой комнате: изолированную доверенную среду, где вы восстанавливаете из неизменяемых копий, сканируете на вторжение и перестраиваете идентичность и учётные данные, прежде чем что-либо подключить обратно. Знайте, какая резервная копия ваша последняя заведомо чистая точка, и ожидайте, что её поиск потребует судебного времени, которое ваше обычное RTO никогда не закладывало. Здесь неизменяемые отключённые копии отрабатывают свою цену, и это тесно связано с управлением инцидентами (глава 9.3) и обязательствами соответствия и управления при обработке взломов (глава 4.6).

Компромиссы: плюсы и минусы

Стратегия DR	Плюсы	Минусы
Резервное копирование и восстановление	Дешевле всего; просто; низкая текущая цена	Медленное RTO (от часов до дней); большее RPO
Pilot light	Низкая цена; ядро данных тёплое и готово	Ручное наращивание; восстановление всё равно занимает реальное время
Тёплый резерв	Быстрое RTO (минуты); полный стек проверен	Текущая цена работающей второй среды
Многоплощадочный active-active	Почти нулевое RTO; нет отказа одной площадки	Наивысшая цена и сложность; согласованность трудна
Синхронная репликация	RPO около нуля	Задержка записи; ограничена расстоянием; более тугая связь
Асинхронная репликация	Быстро, гибко, географически свободно	Окно потери данных, равное отставанию репликации

Центральное напряжение в том, что скорость восстановления и свежесть данных обе стоят денег и сложности, и ни одна не бесплатна ни на каком ярусе. Разрешайте это для каждой системы, а не для организации: пусть анализ влияния на бизнес назначит каждой критичной системе RTO и RPO, затем покупайте ровно ту стратегию, что их удовлетворяет. Трата денег active-active на инструмент отчётности морит голодом книгу, которой это было нужно, а обратное небрежность. Дисциплина в соотнесении трат с числом, которым владеет бизнес, и пересмотре этого соответствия по мере изменения важности систем.

Вопросы для обсуждения с командой

Каковы RTO и RPO для каждой из ваших критичных систем и кто в бизнесе их подписал? Если инженерия изобрела эти числа одна, они догадки, а догадки финансируются либо слишком щедро, либо совсем нет. Целевое время и целевая точка восстановления должны вытекать из анализа влияния на бизнес, ранжирующего процессы по цене их сбоя, так что книга получает минуты, а внутренняя вики день. Принесите ваше нынешнее распределение по ярусам и спросите, принял бы ли ответственный за каждый бизнес-процесс потерю данных и простой, под которые вы спроектировали. В большой организации этот разговор предотвращает дорогую ошибку равной защиты всего, которая ничего не защищает хорошо. Если никто вне инженерии не может назвать числа, у вас ещё нет целей, у вас надежды.
Когда вы в последний раз выполняли настоящее восстановление и измеряли ли фактические RTO и RPO, которых достигли? Резервная копия, которую вы никогда не восстанавливали, непроверенное допущение, а режимы отказа, что вас убьют (повреждённые архивы, потерянные ключи шифрования, снимок не того тома, зависимость, которая не поднимается), всплывают, только когда вы пробуете. Принесите дату и результат вашего последнего полного учения по переключению, а не последнего настольного, и разрыв между достигнутым и обещанным восстановлением. Для большой команды одно успешное восстановление одной системы не доказывает остальные, поэтому спросите, какая доля критичных систем была восстановлена от конца до конца за последний год. Измеренный разрыв ваше самое честное число надёжности, и если вы не можете его назвать, ваш план вымысел, пока не доказано обратное.
Если бы вирус-вымогатель зашифровал ваше производство и дошёл до резервных копий сегодня ночью, какая ваша последняя заведомо чистая копия и где вы бы перестраивали? Обычное аварийное восстановление предполагает, что ваши данные в безопасности где-то ещё, а разрушительная кибератака ломает именно это допущение, делая ваши данные и резервные копии оружием. Спросите, неизменяема и отключена ли хотя бы одна копия, как вы определите последнюю чистую точку восстановления и откуда возьмётся доверенная среда чистой комнаты, когда само производство скомпрометировано. Этому сценарию нужно судебное время, которое ваше нормальное RTO никогда не закладывало, поэтому принесите честную оценку, сколько на самом деле занимает поиск чистой точки. Для корпоративных и государственных команд это также событие соответствия (глава 4.6) с параллельно идущими часами уведомления о взломе. Если ответ «мы бы восстановили последнюю резервную копию», вы к этому не планировали вовсе.
Какая из ваших систем платит за ярус восстановления, которого её анализ влияния на бизнес не оправдывает, и какая опасно недозащищена? Скорость восстановления и свежесть данных обе стоят денег на каждом ярусе, поэтому сплошная политика либо тратит бюджет active-active на инструмент отчётности, либо морит голодом книгу, которой он действительно был нужен. Конкурирующее тяготение реально: один стандартный ярус гораздо проще эксплуатировать многим командам, тогда как разбиение по системам соотносит траты со стоимостью, но требует постоянного кураторства по мере сдвигов важности системы. Принесите нынешнюю стратегию DR для каждой критичной системы, RTO и RPO, на которые она нацелена, месячную цену её резерва и репликации и дату, когда разбиение по ярусам последний раз пересматривалось по свежему анализу влияния. В корпоративной или государственной среде несоответствующий ярус умножается по регионам, а аудит спросит, как вы оправдаете и деньги, которые тратите, и риск, который принимаете, поэтому необъяснимый счёт за active-active и незащищённый критичный сервис одинаково трудно защитить.
Знаете ли вы на самом деле порядок восстановления ваших критичных систем и насколько ваше восстановление зависит от поставщиков, которых вы не можете проверить? Системы отказывают сетями, а не изолированно, и восстановление застревает на зависимости, которую никто не картировал: поднимите приложение раньше его базы данных, поставщика идентификации или DNS, и вы просто произведёте второй сбой. Картирование зависимостей утомительно, а карта устаревает, но альтернатива обнаружение порядка восстановления вживую во время переключения, а риск концентрации в горстке поставщиков SaaS остаётся невидимым, пока они не откажут вместе и не ограничат ваше восстановление своим. Принесите нынешнюю карту зависимостей, документированную последовательность восстановления и список внешних поставщиков с их заявленными обязательствами по восстановлению и проверяли ли вы когда-нибудь хоть одно. Для большой или государственной организации непрерывность поставщиков и риск концентрации всё чаще забота закупок и регулирования, поэтому эти обязательства по восстановлению принадлежат контракту в форме, которую можно проверить, а не маркетингу поставщика.
Если бы вы восстановили каждый сервер сегодня ночью, продолжал бы бизнес реально работать и кто уполномочен объявить катастрофу? Аварийное восстановление восстанавливает ИТ, но непрерывность бизнеса держит организацию в работе: людей, коммуникации, расчёт зарплаты и решения, зависящие от того, что у кого-то есть полномочия их принимать. Можно восстановить каждую систему и всё равно подвести клиентов, если никто не знал, кто может объявить катастрофу или как связаться с сотрудниками, когда обычные каналы тоже упали. Инженерия владеет восстановлением, но непрерывность охватывает помещения, кадры, коммуникации и преемственность руководства, и эти швы между отделами как раз то место, где план тихо гниёт. Принесите полномочия объявления и цепочку эскалации, резервный план коммуникации, названных преемников и запасные помещения и дату, когда сторона бизнеса (не только ИТ) последний раз отрабатывала план. Государство несёт юридический долг непрерывности операций с названными преемниками и основными функциями, а корпорации сталкиваются с регуляторными обязательствами непрерывности, поэтому оба оцениваются по тому, переживёт ли бизнес плохой день, а не только серверы.

Взгляд по секторам

Стартап. С крошечной командой и малым запасом вы не можете позволить горячий второй регион, поэтому будьте намеренны в дешёвых частях, которые всё равно вас спасают. Задайте один честный ярус, следуйте правилу 3-2-1 с автоматическими снимками и по меньшей мере одной неизменяемой копией, которую ваши собственные администраторы не могут удалить, и держите всю среду как инфраструктуру как код, чтобы перестраивать из исходников. Пропустите сложный план и вместо этого раз в квартал проводите одно настоящее восстановление в пробную среду, потому что единственные засечённые учения научат вас большему, чем папка, которую никто не читает.

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

Крупная организация. В масштабе проблема управление портфелем по многим командам: анализ влияния на бизнес, назначающий каждому сервису RTO и RPO, стратегии восстановления по ярусам от резервного копирования и восстановления до active-active и центральный вид вышестоящих зависимостей и зависимостей от поставщиков, включая риск концентрации. Бюджетируйте цену резерва, репликации и неизменяемых копий явно, проводите полные переключения при регуляторных свидетелях по ритму и измеряйте фактическое восстановление относительно цели как отслеживаемую метрику надёжности. Ведите кибервосстановление как отдельную программу с неизменяемыми копиями в хранилище и ранбуком чистой комнаты, проверяемую независимо от учений по стихийным бедствиям.

Государственный сектор. Правила закупок, прозрачность и публичная подотчётность определяют каждый выбор, а непрерывность нередко юридический долг, а не предпочтение. Стройте программу непрерывности операций, определяющую основные функции, упорядочивающую их восстановление и называющую преемников и запасные помещения, чтобы решения никогда не застревали из-за отсутствия уполномоченного человека, и выравнивайте её по признанным рекомендациям вроде NIST SP 800-34 в поддержку обязательств FISMA. Держите копии резервных данных с воздушным зазором, определяйте инфраструктуру как код для перестройки в запасном регионе и проводите ежегодное полное упражнение плюс настольные учения по сценарию вируса-вымогателя, измеренные результаты которых вы сообщаете надзорным органам как свидетельство, что основные услуги переживут плохой день.

Примеры

Стартап. SaaS-компания из двенадцати человек не может позволить горячий второй регион, поэтому намеренна в дешёвых частях. Она задаёт один честный ярус: RTO четыре часа, RPO пятнадцать минут для базы данных клиентов. Она следует правилу 3-2-1 с автоматическими снимками, одной копией, реплицируемой во второй облачный регион, и одной неизменяемой копией с заблокированным окном хранения, которую её собственные администраторы не могут удалить. Вся её среда инфраструктура как код (глава 8.2), так что она может поднять свежий стек из исходников. Раз в квартал она проводит настоящее восстановление в пробную среду в пятницу днём, засекает время и подаёт краткую заметку. Первые учения заняли девять часов и нашли пропущенный шаг миграции; исправление и есть причина, почему следующие заняли три.

Крупная организация. Многонациональный банк работает под регуляторными требованиями восстановления, предписывающими проверенную непрерывность критичных услуг. Он ведёт тёплый резерв во втором регионе для своей основной банковской платформы с синхронной репликацией внутри столичной пары для RPO около нуля и асинхронной репликацией в удалённый регион для выживания при региональной катастрофе. Анализ влияния на бизнес назначает каждому сервису RTO и RPO, а центральная команда картирует вышестоящие зависимости, включая двух поставщиков SaaS, помеченных как риск концентрации. Дважды в год он проводит полное переключение при свидетелях регулятора, измеряет фактическое относительно цели и вводит пробелы в следующий цикл. Отдельная программа кибервосстановления поддерживает неизменяемые копии в хранилище и ранбук чистой комнаты, проверяемые независимо от учений по стихийным бедствиям.

Государственный сектор. Национальное ведомство, выплачивающее пособия, ведёт программу непрерывности операций (COOP), построенную для поддержания его основных функций при любом сбое. Следуя практике непрерывности операций и рекомендациям NIST SP 800-34 по планированию на случай непредвиденных обстоятельств, поддерживающим его обязательства FISMA, оно определяет основные функции, упорядочивает их восстановление и называет преемников и запасные помещения, чтобы решения не застревали из-за отсутствия уполномоченного человека. Системы для граждан несут документированные RTO и RPO, резервные копии следуют правилу 3-2-1 с копиями с воздушным зазором, а инфраструктура определена как код для перестройки в запасном регионе. Ежегодное полное упражнение плюс настольные учения по сценарию вируса-вымогателя проверяют план по измеренному восстановлению, а результаты сообщаются надзорным органам как свидетельство, что основные услуги переживают плохой день.

Бизнес-обоснование: мотивы, ROI и TCO

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

Совокупная стоимость владения (TCO) реальна и постоянна: инфраструктура резерва, пропускная способность репликации, хранение резервных копий (умноженное на неизменяемые и отключённые копии) и инженерное время на построение автоматизации и проведение учений. Именно поэтому вы разбиваете по ярусам по RTO и RPO, а не покупаете active-active везде, так что траты следуют ценности каждой системы, а не сплошной политике. Чтобы обосновать перед руководством, переведите план на его язык: вот простой и потеря данных, которые мы переживём сегодня, вот разрыв до наших целей, вот чего стоит его закрытие и вот риск, если не закрыть. Самый убедительный артефакт измеренные учения, потому что продемонстрированное восстановление это число, которому руководство может доверять, а непроверенный план обязательство, замаскированное под актив.

Антипаттерны и ловушки

Непроверенные резервные копии. Восстановление, которого вы никогда не выполняли, надежда; учения то место, где вы находите повреждение, недостающий ключ и не тот том.
Резервные копии, доступные из производства. Если вирус-вымогатель может зашифровать или удалить ваши резервные копии, у вас одна копия, а не три. Держите одну неизменяемой и отключённой.
Одни RTO и RPO для всего. Сплошные ярусы переохраняют тривиальное и недоохраняют критичное; разбивайте по ярусам по анализу влияния на бизнес.
Путаница DR с BCP. Восстановление каждого сервера, пока никто не знает, кто объявляет катастрофу и как связаться с сотрудниками, это восстановленная система и проваленный бизнес.
Среды восстановления, собранные вручную. Инфраструктура, которую нельзя перестроить из кода, дрейфует, а дрейф обнаруживается посреди переключения.
Проигнорированные зависимости. Подъём приложения раньше его базы данных, поставщика идентификации или DNS просто производит второй сбой.
Гниение плана. Папка, написанная раз и никогда не отрабатывавшаяся, описывает систему, которой больше нет.
Слепые пятна поставщиков. Ваше восстановление ограничено восстановлением ваших критичных поставщиков, а риск концентрации невидим, пока они не откажут вместе.

Модель зрелости

Уровень 1, Начальный: Восстановление стихийно и реактивно. Резервные копии могут идти, но восстановления не проверены. Нет согласованных RTO или RPO, анализа влияния на бизнес, а восстановление импровизируется во время инцидента. Серьёзная потеря данных или событие вируса-вымогателя, вероятно, были бы невосстановимы.
Уровень 2, Развитие: Базовые практики существуют, но непоследовательны по командам. У некоторых критичных систем есть резервные копии по правилу 3-2-1 и документированные RTO и RPO для важнейших сервисов, существует базовый план DR, и восстановления проверяются изредка. Покрытие частичное, зависимости не картированы, учения стихийны, а дисциплина одной команды не подразумевает дисциплину следующей.
Уровень 3, Стандартизация: Практика восстановления документирована и принуждается по организации. Анализ влияния на бизнес управляет ярусными RTO и RPO по системам, стратегии восстановления подобраны под эти ярусы, среды заданы как инфраструктура как код, зависимости и порядок восстановления картированы, а плановые учения (настольные, игровые дни и переключения) идут по определённому ритму. План кибервосстановления с неизменяемыми отключёнными копиями документирован и применяется последовательно, а не оставлен отдельным командам.
Уровень 4, Управление: Восстановление измеряется и контролируется относительно базовых значений. Каждые учения фиксируют фактические достигнутые RTO и RPO и отслеживают разрыв до цели, а метрики вроде доли успешных восстановлений, доли критичных систем, восстановленных от конца до конца за последний год, покрытия и неизменяемости резервных копий и мониторимого отставания репликации как реального RPO сообщаются на панелях. Отклонения запускают действие, разбиение по ярусам заново выводится из данных о том, как системы реально используются, а решения «пускать или нет» опираются на свидетельства, а не числа на слайде.
Уровень 5, Оркестрация: Восстановление непрерывно улучшается, интегрировано по организации и адаптивно. Переключения и восстановления в чистой комнате для кибервосстановления репетируются как рутина, риск поставщиков и концентрации активно управляется, а непрерывность интегрирована с надёжностью (глава 9.1) и реагированием на инциденты (глава 9.3), так что организация предсказуемо восстанавливается после отказов, которых никогда не видела, и пересматривает свою позицию восстановления по мере сдвигов ландшафта систем и картины угроз.

Идеи для обсуждения

Какая из ваших критичных систем никогда не восстанавливалась от конца до конца и что потребовалось бы, чтобы доказать, что может?
Если вы потеряете основной облачный регион на целый день, какие бизнес-процессы остановятся и в каком порядке вы вернёте системы?
Насколько ваше восстановление зависит от поставщиков, чьё восстановление вы не можете увидеть или проверить?
Где вы платите за ярус восстановления, которого анализ влияния на бизнес не оправдывает, и где недозащищаете?
Если бы ваши резервные копии были доступны и зашифрованы сегодня ночью, какая ваша подлинная последняя заведомо чистая точка восстановления?
Каков честный разрыв между обещанными RTO и RPO и теми, что достигли ваши последние учения?

Главные выводы

Непрерывность цель; восстановление средство. Планирование непрерывности бизнеса поддерживает работу организации; аварийное восстановление восстанавливает ИТ-системы, от которых она зависит.
RTO и RPO определяют всё, и оба происходят из анализа влияния на бизнес, а не инженерных догадок. Разбивайте системы по ярусам, а не защищайте все одинаково.
Непроверенная резервная копия не резервная копия. Следуйте правилу 3-2-1, держите по меньшей мере одну неизменяемую и отключённую копию против вирусов-вымогателей и тестируйте восстановления по расписанию.
Подбирайте стратегию DR под число: резервное копирование и восстановление, pilot light, тёплый резерв или active-active, выбранные по RTO и RPO каждой системы.
Репликация меняет согласованность на свежесть (глава 3.3); ваше реальное RPO это ваше отставание репликации, а не ваш проектный документ.
Перестраивайте из кода с инфраструктурой как кодом (глава 8.2) и картируйте зависимости до того, как они понадобятся.
Тестируйте настольными упражнениями, игровыми днями и полными учениями по переключению и измеряйте фактические против целевых RTO и RPO.
Планируйте кибервосстановление отдельно с восстановлением в чистой комнате и связывайте всю практику с надёжностью (глава 9.1), реагированием на инциденты (глава 9.3) и соответствием (глава 4.6).

Источники и дополнительное чтение

ISO 22301, Security and resilience: Business continuity management systems: Requirements (the international standard for BCP).
National Institute of Standards and Technology, SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems (RTO, RPO, and recovery strategies for government systems).
National Institute of Standards and Technology, SP 800-61 Rev. 2: Computer Security Incident Handling Guide (incident and cyber-recovery handling).
U.S. Federal Emergency Management Agency, Continuity Guidance Circular and federal COOP guidance (essential functions and continuity of operations).
Federal Financial Institutions Examination Council (FFIEC), Business Continuity Management booklet (regulatory recovery expectations for financial institutions).
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, eds., Site Reliability Engineering: How Google Runs Production Systems (reliability and disaster testing).
Kelly Shortridge and Aaron Rinehart, Security Chaos Engineering (deliberately exercising failure and recovery).
Cybersecurity and Infrastructure Security Agency (CISA), #StopRansomware Guide (ransomware prevention and recovery practice).