Drp тестирование что это
BCP и DRP. Разница иногда не очевидна
Привет, хабр! Это скорее не статья-разъяснение, а статья-рассуждение о непрерывности и самая мякотка, надеюсь, будет в комментариях.
В силу того, что business continuity превратился в модный тренд, что-то вроде нанотехнологий, инноваций и импортозамещения, самое время определиться, что такое BCP и что такое DRP, в чем их разница и почему BCP и DRP как в том анекдоте «не муж и жена, а четыре совершенно разных человека».
BCP (business continuity plan) – план обеспечения непрерывности бизнеса. Содержит детальный план, что необходимо сделать для восстановления бизнес процессов.
DRP (disaster recovery plan) – план восстановления после катастрофы. Содержит детальный план по восстановлению инфраструктуры. Обычно имеется ввиду ИТ инфраструктура, но это могут быть самые разные механизмы, автотранспорт и здания.
Оба плана будут использоваться сразу после возникновения кризисной ситуации или катастрофы. Оба плана содержат набор инструкций и описание людей, которые эти инструкции должны выполнить. Оба плана должны периодически тестироваться, чтобы быть уверенным, что план жизнеспособен. Оба плана должны быть разработаны исходя из требований бизнеса*. Пожалуй, на этом сходство заканчивается и начинаются различия.
DRP – это план про восстановление. Если сгорел склад, то есть запасной склад на такой случай. Если в ЦОД пришли маски-шоу, есть резервный ЦОД. Если сломался автомобиль – есть запасные части для ремонта. Или резервный автомобиль. В зависимости от требований бизнеса, о которых мы поговорим в другой статье.
BCP – это план про непрерывность бизнеса, а точнее, конкретного бизнес процесса. BCP позволяет продолжить бизнес процесс после катастрофы или кризисной ситуации так быстро, как это необходимо для бизнеса.
При выходе из строя офисного здания DRP будет описывать как оперативно запустить новое офисное здание. BCP будет описывать, как организовать удаленную работу сотрудников. В случае, если удаленная работа невозможна, BCP будет включать в себя DRP, но не наоборот. И где-то в этот момент возникнет ощущение, что это одно и то же, но это не так.
В случае выхода из строя ЦОД, например, телекоммуникационной компании, BCP план будет описывать процесс переезда в резервный ЦОД и соответствующие коммуникации. DRP будет описывать переезд каждой системы. Фактически, в этом случае BCP план включает в себя много DRP планов.
BCP создается и тестируется совместно с представителями бизнеса. DRP создается и тестируется внутри ИТ подразделения.
Очень интересует мнение практиков, которые забороли путаницу в терминологии в непрерывности.
— * — требования бизнеса – это именно требования от бизнеса, а не размышления внутри ИТ департамента, как могли бы выглядеть бизнес требования.
План аварийного восстановления — уверенность в завтрашнем дне для всей компании и спокойный сон ИТ-отдела
Знакомая ситуация?
Есть такая штука – непрерывность бизнеcа. Эта сфера уже достаточно развита и подразумевает, что ваш бизнес может продолжить работу без происшествий даже после попадания метеорита в дата-центр или офис.
Интересно, что сейчас в России успешное внедрение планов аварийного восстановления бизнеса обладает побочным эффектом в виде быстрого карьерного роста предложившего и внедрившего.
Будет непросто убедить топ-менеджеров инвестировать большие деньги в защиту от того, что вряд ли когда-то случится. Для этого нужно собрать доказательную базу и с цифрами в руках продемонстрировать, что потери бизнеса будут в разы больше инвестиций в резервы. В этом поможет давно сформированная методика анализа воздействия на бизнес – Business Impact Analysis.
Помимо ИТ, сейчас часто рассматриваются и другие ресурсы, необходимые для работы компании в кризисной ситуации – персонал, офисные помещения, производственные мощности и прочее. В стандарте «В525999-1:2006. Управление непрерывностью бизнеса» кристаллизовалось вот такое определение: «Непрерывность бизнеса — стратегическая и тактическая способность организации планировать свои действия и реагировать на инциденты и нарушения нормального хода бизнеса с целью продолжения деловых операций на определенном приемлемом уровне»
Зачем нужен план DRP или даже BCP?
Вести работу по обеспечению непрерывности деятельности должна любая компания, которой дорог собственный бизнес. Да, нам повезло жить в сейсмически стабильной области, вдалеке от торнадо, селевых потоков и извержений вулканов. Но для деловой репутации компании может быть не менее разрушительной потеря информации о клиентах из-за пожара, затопления серверной, террористической атаки – продолжите сами. Даже банальное отключение электричества и каналов связи может привести к серьезным потерям денег. Например, для банка это может обернуться паникой среди вкладчиков, которые понесутся забирать свои вклады, опасаясь, что их деньги вот-вот пропадут. Это, кстати, страшный сон любого банкира.
Движение в этом направлении поможет повысить отказоустойчивость ИТ-систем в целом. Многие технологические и организационные решения работают не только на катастрофические сбои, но и на часто случающиеся отказы отдельных систем. Следовательно, ваш ночной сон будет более крепким.
Если к тому же вы работаете в банке, то в соответствии с указанием ЦБ № 2194-У, ваш работодатель должен иметь план обеспечения непрерывности и восстановления деятельности (ОНиВД). Очень возможно, что формально этот документ есть, но про ИТ там только общие слова. Конкретизировать и обогатить его будет очень правильным шагом.
Помимо своей основной цели, работа по написанию планов DRP (восстановление ИТ-инфраструктуры) и BCP (всего, что требуется для определенного бизнес-процесса) позволяет разобраться в своих ИТ-системах и бизнес-процессах. Очень часто знания не формализованы и находятся в головах отдельных экспертов, при этом ни у кого нет понимания в целом, тем более в виде документа.
Сегодня для многих эта сфера — возможность быстрого карьерного роста, поскольку реализация таких проектов — не самая сильная часть сформировавшихся ИТ-департаментов. Часто в компаниях тема непрерывности бизнеса начинала расти именно с подачи ИТ-специалистов, а не консультантов, работающих с рисками.
Реализация проекта
В проектах по обеспечению непрерывности выделяют несколько этапов. Для получения лучшего результата лучше пройти их последовательно, хотя возможны вариации.
1. Анализ воздействия на бизнес и анализ рисков. На этом этапе оценивается ущерб от простоя бизнес-процессов (хотя бы на уровне экспертных мнений), определяются зависимости бизнес-процесса от ИТ, ключевых сотрудников, оборудования, коммуникаций и проч. Если ваш проект чисто ИТ-шный, либо если у вас нет описанных бизнес-процессов, можно начинать не от БП, а от ИТ-систем. Также определяется, какие риски мы будем рассматривать. Проводится анализ, как реализация этих рисков будет влиять на наши бизнес-процессы.
Пример: простой любимой социальной сети (или онлайн-игры) вызывает резкую панику и отток пользователей, плюс рост популярности конкурентов. Аналитики определяют возможную сумму ущерба и вероятность – и формируют бюджет на защиту. Может оказаться, что содержание резервной площадки с полным дублированием в разы экономичнее, чем даже регулярные отказы мелких систем, вызывающих 2-3 минутные простои.
2. Аудит текущей защищенности. Очень редко в компаниях есть исчерпывающая информация об инфраструктуре, в том числе информационной, требуемой для повседневной работы. Цель этапа – засучив рукава обследовать все и понять, насколько защищены мы сейчас, где слабые места, и что нужно делать, чтобы минимизировать риски. Какие-то «бутылочные горлышки» возможно устранить сразу и без больших затрат.
3. Третий этап подразумевает разработку стратегии обеспечения непрерывности — технических и организационных мер, повышающих готовность компании к чрезвычайным ситуациям. По его окончании может производиться аренда резервного офиса, закупки оборудования, аренда каналов, заключение договоров с подрядчиками итд.
4. На четвертом этапе собственно пишутся планы обеспечения непрерывности бизнеса (BCP), либо ИТ-систем (DRP). Они включают в себя четкую последовательность шагов — что кому и когда делать при наступлении чрезвычайной ситуации. Это значит, что каждый специалист должен понимать, что и как конкретно делать вместо панического бега по офиса и звонков всем подряд.
5. Следом должны проводиться учения по планам, их корректировка и запуск механизма постоянной актуализации. Поддержание готовности компании к чрезвычайной ситуации — непрерывный процесс. Каждый квартал планы должны актуализироваться, а каждые полгода желательно проводить учения. Только при соблюдении двух этих условий все ваши усилия окупятся, когда проблема случится.
Случается
Как начать и к чему стремиться?
И ещё одно: если у вас были примеры, когда продуманное планирование «чёрного дня» реально помогло, расскажите, пожалуйста, в комментариях.
DRP-план в ИТ-компании и проверка его работоспособности
Проводим проверку работоспособности плана восстановления после аварии.
Все мы хотим надеяться, что ничего подобного никогда не произойдет.
У большинства предприятий есть (ну, или хотя бы должен быть) план восстановления после аварии. Аналогичный план должен быть у оператора дата-центра. Любой из подобных объектов подвержен влиянию внешних факторов — полностью исключить вариант аварии нельзя. Даже, казалось бы, самые защищенные объекты могут все же попасть в очень неприятную ситуацию, о чем мы как-то уже писали.
Соответственно, DRP-план (disaster-recovery plan) должен помочь компании быстро выйти на предшествующий аварии рабочий уровень. Обычно в таком плане описываются действия сотрудников в случае аварии. При составлении такого плана цель обычно — сведение к минимуму последствий аварии с обеспечением возможности вернуть контроль над решением критически важных задач, используя заранее определенные ресурсы. Но план — планом, а будет ли он работать? Для проверки этого стоит провести «учебную тревогу».
Дата-центры содержат массу чувствительного к внешним факторам оборудования, которое, в свою очередь, работает с огромными объемами данных, которые могут быть очень ценными. Недавним примером того, к чему может привести даже небольшая авария, служит отмена большинства рейсов авиакомпании Delta Airlines.
Скорее всего, у такой огромной компании был собственный DRP-план. Возможно, в нем были неучтенные моменты, из-за чего пострадали и сама компания, и ее клиенты. И в самом деле, просто план и возможность его быстрой реализации — это разные вещи.
Любая компания, а тем более, ИТ-компания должна учитывать инфраструктуру, людей и процессы при составлении своего собственного плана восстановления после аварии (будь то землетрясение, пожар или человеческий фактор).
Как часто нужно проводить «учебные тревоги»?
Собственно, ответить здесь сложно — у каждой компании уникальная ситуация, которая не дает возможности унифицировать как DRP-план, так и его выполнения. Тем не менее, в любой момент времени руководитель компании должен быть уверен в том, что план отвечает текущей ситуации и может быть реализован. Пересматривать DRP-план стоит после каждого крупного изменения инфраструктуры. А «тревоги» можно проводить раз в месяц или раз в год — все зависит от того, как часто компания меняется.
Эксперты рекомендуют проводить проверку не реже раза в год.
Готовимся
Прежде, чем компания начнет проверять реалистичность и работоспособность своего плана, нужно быть уверенным в его результатах. Убедитесь в том, что обязанности всех сотрудников распределены рационально и корректно. Нельзя допускать того, чтобы у каких-то сотрудников обязанностей не было вообще, а у кого-то их была бы масса, и этот человек (или люди) были, фактически, незаменимыми.
Катастрофа на то и катастрофа, что кто-то из сотрудников может оказаться недоступным и если это будет ключевой человек, то весь план может пойти под откос. Все инструкции и правила должны быть четкими и понятным. Во время проверки плана нужно внимательно следить за ходом реализации DRP-плана.
Каждая деталь проверяемого плана должна быть зафиксирована, с учетом всех возникших проблем и сложностей. Проверку необходимо проводить с привязкой по времени, отслеживая, сколько времени уйдет на решение той либо иной проблемы и реализацию любого этапа. Руководство компании и отдельные сотрудники должны знать, что произойдет, если оборудование и сервисы ИТ-компании простоят определенное время. Как это повлияет на операции, клиентов и доход?
Как тестировать
1. Проверка плана
Это чисто теоретический этап, который почти никогда не включает в себя полноценные «учения». Пересматривать план на соответствие его текущей ситуации в компании и обстановке вокруг нужно несколько раз в год.
Кстати, у DRP должен быть управляющий комитет. В него обычно входят компетентные сотрудники, часто — топ-менеджеры. Кроме того, для работы необходимо привлекать и экспертов, которые могут очень помочь на пути к планированию спасения от катастрофы.
2. Проверка без тревоги
На этом этапе необходимо проверить знания всех сотрудников, кто, по плану, должен участвовать в процессе ликвидации последствий катастрофы. Каждого из сотрудников необходимо опросить на предмет его обязанностей и их выполнения в случае возникновения той либо иной непредвиденной ситуации.
Если ничего подобного не проводить, то сотрудники не будут слишком серьезно относиться к вашему плану. Кто-то что-то обязательно забудет, не так поймет или и вовсе решит не принимать участия. Чтобы не допустить значительное влияние «человеческого фактор» на последствия катастрофы, и нужно проводить такую проверку плана. Все сложности, недопонимание сотрудников, отсутствие ясности в синхронности действий — все это необходимо фиксировать и исправлять.
3. Полномасштабный тест
Это действительно полевые учения, их нужно максимально приблизить к возможному развитию ситуации в случае катастрофы. Результат должен быть ощутим. Оператор дата-центра должен учитывать то, насколько негативно на работе компании может отразиться значительный вынужденный простой оборудования.
Некоторые компании предпочитают скрывать информацию о том, что «учения» ненастоящие, от рядовых сотрудников. Дело в том, что это позволяет добиться от них скорости реакции и действий, максимально приближенным к реальности.
На этом этапе придется использовать ресурсы компании, включая время, оборудование и средства. Результатом должно быть возвращение во внятные сроки «поврежденного» оборудования с быстрой адаптацией работников компании к ситуации.
Что, если что-то пойдет не так?
Это, скорее всего, произойдет в той либо иной степени. Главное — стоит помнить, что гладко проверка такого уровня на все 100% пройти не может. Какие-то ошибки сотрудников и вмешательство неожиданных факторов обязательно повлияют на реализацию плана.
После завершения тестирования вся информация должна быть распределена между сотрудниками компании. Причем некоторые вещи стоит сообщать только тем, кто с ними связан. В идеале, тестировать DRP стоит тогда, когда в компании что-то сильно меняется.
И уже после теста все полученные результаты нужно использовать во благо собственной компании. В целом, поддержание сотрудников и всей компании в готовности к чрезвычайно ситуации — это критично. Работать с планом (модифицировать и дорабатывать его) нужно каждые несколько месяцев. Специалисты рекомендуют делать это раз или два в квартал. Но, конечно. Все зависит от самой компании и ее сотрудников.
Проверять работу плана нужно с разными сценариями и ситуациями. Только в том случае, если сотрудники готовы к катастрофе, компания сможет быстро восстановить работу после сбоя. В противном случае, бизнес такой компании может очень сильно пострадать.
Кстати, интересно было бы узнать, подготовлена ли ваша компания к подобным проблемам, и если да, то как вы проверяете работоспособность составленного плана, и какие у него есть особенности?
Как избежать убытков от ИТ-сбоя: план по аварийному восстановлению
Об эксперте: Евгений Колбин, вице-президент «Сбера», генеральный директор SberCloud.
Ключевая практика борьбы с последствиями ИТ-сбоев — разработка и внедрение планов по аварийному восстановлению (Disaster Recovery Plan, DR-план), которые являются частью планов непрерывности бизнеса.
Хорошо продуманный DR-план позволяет предусмотреть и снизить последствия большинства ИТ-сбоев, включая:
При разработке DR-плана надо определить цели бизнеса, а затем понять, какие сервисы для каких процессов критичны и в какой последовательности они должны быть восстановлены. Только после проведения такого анализа, который называют Business Impact Analysis, есть смысл выбирать конкретные инструменты для аварийного восстановления.
Расходы на создание плана аварийного восстановления, которые к тому же не подразумевают немедленной финансовой отдачи, нередко вызывают сопротивление со стороны руководства компаний. Как правило, чем меньше бизнес, тем реже он задумывается о DR. Однако ситуация постепенно трансформируется в сторону внедрения DR-планов как общепринятой практики, в том числе благодаря оптимизации ресурсов и времени на Disaster Recovery с помощью облачных технологий.
Как и почему меняется Disaster Recovery сегодня
Основных причин изменения Disaster Recovery в сторону оптимизации самого процесса две:
DR становится дешевле
При формировании DR-плана облака обеспечивают заметную экономическую выгоду. Ресурсы резервной облачной площадки могут использоваться только для резервного копирования, хранения и восстановления. Такая модель реализации DR-плана значительно дешевле содержания собственного физического резервного ЦОДа.
Другой фактор экономии — отказ от лент и дисковых систем хранения данных. У компаний больше нет необходимости использовать эти средства, так как резервное копирование может выполняться в облаке в режиме реального времени. При этом при использовании облачного объектного хранилища можно хранить данные в нескольких местах — невозможный сценарий в случае использования ленточных накопителей.
Экономия не сказывается на вопросах надежности и безопасности: облака обеспечивают более высокий уровень устойчивости ИТ-инфраструктуры и бизнес-приложений, чем корпоративные On-Premise системы.
Публичные облачные провайдеры обязаны подтверждать безопасность своих платформ соответствующими аттестатами, выданными компетентными органами, а также регулярным аудитом в области информационной безопасности. Кроме того, если говорить о клиентах, не работающих в сфере ИТ, то таким компаниям просто невыгодно содержать штат дорогих квалифицированных специалистов по безопасности. Так что и уровень «безопасников», и применяемых ИБ-решений у облачного провайдера всегда будет на порядок выше.
Выбор традиционного DR и облачного DR не является взаимоисключающим. Использовать можно и гибридный подход, если он экономически оправдан и обеспечивает непрерывность бизнес-процессов и надежную защиту ИТ-инфраструктуры бизнеса.
DR становится быстрее
При критических сбоях компаниям необходимо действовать быстро. Сегодня рынок предлагает большое количество сервисов автоматизированного восстановления. Это высвобождает важные ресурсы (например, время сотрудников), которые можно направить на более приоритетные проекты. Облачные DR-системы также увеличивают скорость аварийного восстановления — с помощью облачного резервного ЦОДа можно не только в течение нескольких минут восстановить утерянные данные, но и развернуть на его мощностях резервную ИТ-инфраструктуру.
Такой подход обеспечивает возобновление штатной работы ИТ-систем в разы быстрее, чем восстановление, приобретение или перенос в другой ЦОД серверов и систем хранения данных.
DR становится проще
Еще несколько лет назад российских провайдеров DR-решений можно было пересчитать по пальцам одной руки. При интеграции их продуктов приходилось учитывать сотни нюансов — по сути, рынок только учился полноценно работать с DR. Сегодня Disaster Recovery — это больше не сакральное знание, для реализации которого нужно прочитать десятки книг или пройти специальные курсы. И со стороны провайдеров, и со стороны заказчиков разработаны четкие инструкции реализации надежных DR-решений. Все идет в сторону минимизации набора необходимых действий и сокращения возможности ошибки на каком-либо этапе.
Самая критичная часть реализации DR-решения — это организация сетевого взаимодействия между резервной и основной площадкой.
Если, например, облачный провайдер использует другое, отличное от вашего сетевое оборудование, то три-четыре года назад проработка схем подключения, взаимодействия и маршрутизации могла занимать больше месяца. Сегодня проработка надежного и безопасного сетевого соединения с облаком — все еще непростая задача, но она занимает гораздо меньше времени, потому что вендоры уже проработали десятки сценариев для различных вариантов подключения под разные платформы.
Если говорить о простом резервном копировании, то и этот процесс сегодня максимально облегчен: ресурсы облачного провайдера можно использовать как универсальную корзину для бэкапов. Достаточно определить точку входа для подключения и ввести учетные данные, а дальше облачное хранилище в считанные минуты становится частью системы резервного копирования.
Если сравнивать российские предприятия с западными, то отечественные компании только учатся непрерывности бизнеса. Закон о хранении персональных данных подстегнул российский рынок: сначала — хостинга, затем — облачных провайдеров. Провайдеры, в свою очередь, ринулись разрабатывать и внедрять как можно больше удобных решений и моделей работы для заказчиков. Такая сильная конкуренция за растущий рынок на руку клиентам: они получают разнообразные надежные сервисы по выгодной стоимости. Это касается и решений для Disaster Recovery, которые, будучи важной частью индустрии Cloud, продолжат развиваться и становиться удобнее.
Подписывайтесь также на Telegram-канал РБК Тренды и будьте в курсе актуальных тенденций и прогнозов о будущем технологий, эко-номики, образования и инноваций.
Готовим DRP — не забудьте учесть метеорит
Даже во время катастрофы всегда есть время на чашку чая
DRP (disaster recovery plan) — это штука, которая в идеале никогда не понадобится. Но если вдруг мигрирующие в брачный период бобры перегрызут магистральное оптоволокно или джуниор-админ дропнет продуктивную базу, вы точно хотите быть уверены, что у вас будет заранее составленный план, что с этим всем безобразием делать.
Пока клиенты в панике начинают обрывать телефоны техподдержки, джуниор ищет цианиды, вы с мудрым видом вскрываете красный конверт и начинаете приводить все в порядок.
В этом посте я хочу поделиться рекомендациями, как надо писать DRP и что он должен содержать. А еще мы рассмотрим следующие штуки:
Для каких компаний это может быть полезно
Очень сложно провести границу, когда IT-подразделение начинает нуждаться в подобных вещах. Я бы сказал что DRP вам гарантированно нужно, если:
Документация важна
Начните с документации. Допустим, что ваш сервис работает на базе скрипта на Perl, который был написан три поколения админов назад, а как он работает, никто не знает. Накопленный технический долг и отсутствие документации неизбежно вам прострелит не только колено, но и другие конечности, это скорее вопрос времени.
После того, как у вас на руках есть хорошее описание компонентов сервиса, поднимите статистику по авариям. Почти наверняка они будут совершенно типовые. Например, у вас время от времени переполняется диск, что приводит к отказу ноды до ее ручной очистки. Или становится недоступен клиентский сервис из-за того, что кто-то опять забыл продлить сертификат, а Let’s Encrypt настроить не смог или не захотел.
Мысли как диверсант
Самая сложная часть находится в прогнозировании тех аварий, которых еще ни разу не было, но которые потенциально могут уложить ваш сервис полностью. Тут мы обычно с коллегами играем в злодеев. Берете много кофе и чего-нибудь вкусного и запираетесь в переговорке. Только убедитесь, что в этой же переговорке вы заперли тех инженеров, которые сами поднимали целевой сервис или регулярно с ним работают. Дальше либо на доске, либо на бумаге начинаете рисовать все возможные ужасы, которые могут произойти с вашим сервисом. Не обязательно детализировать вплоть до конкретной уборщицы и выдергивания кабелей, достаточно рассмотреть сценарий «Нарушения целостности локальной сети».
Обычно, большинство типовых аварийных ситуаций укладывается в следующие виды:
После того, как типовые проблемы записаны, наливаем еще кофе и начинаем рассматривать самые странные сценарии, когда какие-то параметры начинают сильно выходить за пределы нормы. Например:
Что такое этот ваш DRP?!
Итак вы определили модель угроз. Учли и местных жителей, которые режут оптоволоконные кабели в поисках меди, и военный радар, который роняет радиорелейную линию строго по пятницам в 16:46. Теперь надо понять, что с этим всем делать.
Ваша задача написать те самые красные конверты, которые будут вскрываться в аварийной ситуации. Сразу рассчитывайте, что когда (не если!) все навернется, рядом окажется только самый неопытный стажер, у которого будут сильно трястись руки от ужаса происходящего. Посмотрите, как реализованы аварийные таблички в медицинских кабинетах. Например, что делать при анафилактическом шоке. Медицинский персонал наизусть знает все протоколы, но когда рядом человек начинает умирать, очень часто все беспомощно хватаются за все подряд. Для этого на стене висит четкая инструкция с пунктами вида «открыть упаковку того-то» и «ввести внутривенно столько-то единиц препарата».
В аварийной ситуации думать сложно! Должны быть простые инструкции для парсинга спинным мозгом.
Хороший DRP состоит из нескольких простых блоков:
Как правильно тестировать
Убедитесь, что любой ответственный сотрудник в состоянии выполнить все пункты. В самый ответственный момент может оказаться, что у инженера нет прав на доступ в нужную систему, отсутствуют пароли от нужной учетки или он понятия не имеет, что значит «Подключитесь к консоли управления сервисом через прокси в головном офисе». Каждый пункт должен быть предельно прост.
Неправильно — «Зайдите на виртуализацию и ребутните мертвую ноду»
Правильно — «Подключитесь через веб-интерфейс к virt.example.com, в разделе ноды выполните перезагрузку ноды, которая вызывает ошибку».
Не допускайте двусмысленностей. Помните про испуганного стажера.
Обязательно тестируйте DRP. Это не просто план для галочки — это то, что позволит вам и вашим клиентам быстро выйти из критической ситуации. Оптимально сделать это несколько раз: