Расскажем, что должно быть в этом документе, чтобы IT-инфраструктура после сбоя восстановила работу в короткие сроки.
Отказы и сбои IT-инфраструктуры нельзя исключить полностью. После катастрофы работу сервисов нужно восстановить как можно быстрее — тогда убытки бизнеса будут минимальны. Чтобы сотрудники знали, как действовать, и нужные меры были приняты вовремя, разрабатывают план аварийного восстановления (DRP): выбирают технологии Disaster Recovery с учетом потребностей бизнеса и бюджета, назначают ответственных, прописывают порядок действий для предупреждения катастрофы и устранения ее последствий.
Мы составили руководство по разработке плана аварийного восстановления с общими рекомендациями по восстановлению IT-инфраструктуры.
Что такое план аварийного восстановления
План аварийного восстановления — документ, который содержит шаги по устранению последствий аварии и восстановлению данных; список ответственных сотрудников, их роли и обязанности; последовательность действий по защите и восстановлению IT-инфраструктуры.
Главные цель разработки такого документа — четкая пошаговая инструкция с таймингом для определенных ролей, ее выполнение помогает решить следующие задачи:
- восстановить IT-инфраструктуру бизнеса после аварии в приемлемые сроки;
- обеспечить работу критически важных функций IT-инфраструктуры во время простоя основного ЦОД;
- сохранить данные компании в нужном объеме.
Для реализации плана аварийного восстановления нужна параллельная IT-инфраструктура — она может использоваться для хранения данных и шаблонов виртуальных машин либо быть второй боевой системой, которая возьмет на себя рабочие задачи на время катастрофы.
Чтобы обеспечить катастрофоустойчивость бизнеса и непрерывность его работы, компания может дублировать IT-сервисы в собственный дата-центр или использовать облачные сервисы, когда Disaster Recovery предоставляется провайдером как услуга.
Что должно быть в плане аварийного восстановления
Цели плана аварийного восстановления
В качестве целей DRP могут быть указаны:
- Обучение сотрудников, чтобы они четко понимали порядок действий для быстрого восстановления IT-инфраструктуры — это ключевая цель DRP.
- Восстановление работы IT-инфраструктуры в нужное время, максимальное сохранение данных.
- Необходимость соблюдения корпоративных стандартов организации в ходе мероприятий DR.
- Необходимость финансового контроля, чтобы все принятые меры были рентабельными.
- Взаимодействие с ключевыми клиентами и прессой в момент катастрофы.
- Конкретные цели зависят от целей компании и утверждаются лицами, принимающими решения, то есть руководящим составом.
Факторы риска
В DRP прописывают основные факторы риска для IT-инфраструктуры и те угрозы, что могут возникнуть в процессе аварийного восстановления. Также планируют мероприятия, которые помогут минимизировать риски или исключить их полностью.
Такие мероприятия, как правило, проводят регулярно для оценки состояния IT-инфраструктуры и ее готовности к процедурам аварийного восстановления в случае катастрофы. Это могут быть:
- проверка корректности создания резервных копий;
- проверка качества работы каналов резервной связи;
- контроль наличия нужного оборудования;
- периодическая проверка DRP на соответствие реальному положению дел;
- тестирование резервных инфраструктур.
Отдельно могут быть вынесены распространенные угрозы, которые могут вывести инфраструктуру из строя. Каждую возможную катастрофу оценивают по степени ущерба для бизнеса, также может быть предусмотрен порядок действий для наиболее вероятных угроз.
Список критически важных сервисов
В каждом бизнесе есть список систем и приложений, работа которых будет критически важной для компании. Отказы в их работе приведут к сбою пользовательских сервисов.
Например, в интернет-магазине нельзя потерять данные о заказах, а в банке недопустима потеря данных о транзакциях, также пользователь должен в любой момент получать доступ к своему счету и проводить денежные операции.
Чем критичнее для бизнеса приложение или сервис, тем раньше должно быть начато аварийное восстановление его работы.
Для критически важных сервисов, которые не могут простаивать даже несколько минут, резервная инфраструктура должна сразу же заменить основную. Для тех сервисов, где допускается время простоя, работы по аварийному восстановлению начинают в определенный срок, чтобы система успела заработать до того, как бизнес понесет значительные убытки.
В плане DRP могут быть предусмотрены разные сценарии действия для критических и некритических сервисов, в том числе разное время реагирования на проблему и разные решения резервирования данных.
Система реагирования на сбои
Чтобы работы по аварийному восстановлению системы были начаты вовремя, нужно быстро обнаружить сбой в работе IT-инфраструктуры. Должны быть разработаны процедуры проверки работы пользовательских сервисов. В план может быть внесена периодическая диагностика систем и мониторинг точек отказа важных сервисов и приложений, сообщающий о проблеме раньше пользователей.
В плане аварийного восстановления указывают, что считать катастрофическим событием, какие действия и за какой период времени должны предпринимать сотрудники, если поступил сигнал о сбое. Сотрудников обучают так, чтобы они четко знали порядок действий в тех или иных случаях.
Распределение ролей и обязанностей между сотрудниками
Как правило, реализация плана аварийного восстановления требует участия двух групп: руководящей, то есть людей, которые принимают ключевые решения и контролируют процессы DR, и рабочей — специалистов, разрабатывающих, внедряющих и реализующих планы восстановления.
Для всех сотрудников, которые имеют отношение к работе IT-инфраструктуры, должны быть назначены роли и определены обязанности. Выбирают ответственных, чтобы сотрудники знали, к кому обращаться в момент катастрофы. Также назначают заместителей ответственных на случай, если нужные люди не доступны. Важно прописать в плане конкретные данные конкретных людей, а не только названия должностей.
Процесс реализации плана и реагирования на технический сбой
В плане DRP нужно прописать действия команды для восстановления IT-инфраструктуры после катастрофы. Сотрудники должны заниматься восстановлением работы сервисов, оповестить о случившемся нужных членов команды, добиться запуска системы в нужное время.
Например, системный администратор должен сообщить о сбое группе аварийного восстановления в течение 20 минут. Команда аварийного восстановления обязана восстановить ключевые услуги в течение четырех рабочих часов после инцидента, восстановить обычный режим работы инфраструктуры в течение суток после происшествия.
Также в плане прописывают всю важную дополнительную информацию: где хранится документация; что происходит в случае обновления плана; куда обращаться в страховых случаях; кто и как общается с прессой; что делает юридическая группа компании и когда она подключается; когда нужна оценка финансовых рисков и другое.
Каждая задача должна быть максимально конкретной, то есть состоять из точных команд или действий. Например, не просто позвонить ответственному, а позвонить менеджеру Юлии по телефону 8-965-123-45-64 в течение трех минут.
Тестирование плана
Готовый план аварийного восстановления тестируют, чтобы выяснить, сработает он в реальной ситуации аварии или нет.
Существуют различные типы тестов:
- Проработка действий с командой. Сотрудники устно проходят шаги, указанные в плане, выявляют пробелы и трудные места. Этот вид тестирования помогает команде ознакомиться с планом DR, но его недостаточно для проверки работоспособности плана.
- Моделирование аварийного сбоя. Имитация катастрофы без прерывания работы IT-инфраструктуры. Включает тестирование оборудования и программного обеспечения, работы персонала, коммуникаций, процедур, резервных сервисов. Результаты анализируют, при необходимости план корректируют.
- Тестирование в рабочем режиме. Полное прохождение процедур плана аварийного восстановления с отключением основной IT-инфраструктуры. Может быть дорогостоящим и представлять риск для текущих операций.
План DRP — не статичный документ, его нужно регулярно проверять и приводить в соответствие с реальными потребностями бизнеса. Составить план могут специалисты компании или провайдера, оказывающего услуги по резервированию IT-инфраструктуры в облаке. Если вы разрабатываете план аварийного восстановления самостоятельно, можете воспользоваться нашим шаблоном.
Источник: https://mcs.mail.ru/blog/plan-avariynogo-vosstanovleniya-disaster-recovery-plan/
