Планы обеспечения непрерывности и восстановления (BCP, DRP)

Планы обеспечения непрерывности и восстановления (BCP, DRP)

Разрабатываем планы непрерывности бизнеса и аварийного восстановления: определяем допустимое время простоя и допустимую потерю данных, описываем сценарии отказов и порядок действий, проводим учения и оформляем протоколы. План, который ни разу не проверяли, не работает, поэтому испытания входят в услугу.

Коротко о задаче

Вопрос звучит одинаково у регулятора и у здравого смысла: что произойдёт, если система станет недоступна, и через сколько вы вернётесь к работе.

Ответ «у нас есть резервные копии» неполон. Копии есть почти у всех. Дальше выясняются детали. Куда восстанавливать, если отказало само оборудование. Сколько часов займёт разворачивание. Кто это делает, если единственный человек, который умеет, в отпуске. Данные за какой период потеряются. Как работает бизнес эти часы. Кого и в каком порядке уведомляют.

Второй слой проблемы — план существует, но его не проверяли. Резервные копии пишутся, а восстановление никто не пробовал; выясняется, что архив неполон или разворачивается не восемь часов, а трое суток. Инструкция описывает сервер, который заменили год назад. В списке контактов половина уволившихся.

Мы делаем план, который проверен на практике, и оставляем вам процедуру, по которой его проверяют дальше.

Что входит в услугу

• Анализ влияния на бизнес

Определяем, какие процессы критичны и в каком порядке их восстанавливать. Для каждой системы устанавливаем допустимое время восстановления и допустимый объём потери данных. Эти два показателя определяют всю дальнейшую архитектуру: требование вернуться за час и требование вернуться за сутки стоят разных денег.

• Сценарии отказов

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

• Архитектура резервирования

Проектируем или проверяем существующую схему: резервирование узлов, репликация, распределение копий по площадкам, защита архивов от изменения и удаления. Отдельно смотрим на защиту от шифровальщика: копия, доступная из скомпрометированной сети, копией не является.

• Регламенты восстановления

Пошаговые инструкции, написанные так, чтобы по ним мог работать дежурный инженер, а не только автор. С командами, путями, реквизитами доступа, ожидаемым временем каждого шага и точками проверки.

• Роли, оповещение и эскалация

Кто принимает решение об объявлении аварии, кто руководит восстановлением, кто общается с бизнесом и клиентами, кто с регулятором. Списки контактов с резервными каналами связи на случай, когда почта тоже недоступна.

• Учения и протоколы

Проводим восстановление на тестовом контуре, замеряем фактическое время, сравниваем с целевым, находим расхождения. Протокол учений — документ, который на аудите закрывает вопрос лучше любого плана.

• Порядок актуализации

Определяем, при каких событиях план пересматривается, и назначаем периодичность плановых учений.

Что это даёт заказчику

• Известное время возврата. Вместо «постараемся быстро» у вас есть цифра, подтверждённая испытанием.
• Действия без импровизации. В момент аварии никто не вспоминает, что делать: есть инструкция и распределённые роли.
• Проверенные резервные копии. Учения регулярно выявляют, что часть данных не попадала в архив. Лучше узнать это на учениях.
• Закрытое требование регулятора. Наличие и проверка планов непрерывности входит в перечень вопросов при инспекции регулируемых компаний.
• Обоснование бюджета. Анализ влияния переводит разговор о резервировании из технической плоскости в денежную: столько стоит час простоя, столько стоит его сократить.

Как мы работаем

Начинаем с бизнеса, а не с оборудования. Пока не понятно, что происходит с работой компании при недоступности системы, обсуждать схему резервирования рано.

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

Учения проводим обязательно. Без них документ остаётся намерением.

Смежные направления: {{ссылка: Системы резервного копирования и восстановления}}, {{ссылка: Отказоустойчивые кластеры и высокая доступность}}, {{ссылка: Квалификация IT-инфраструктуры}}.

Наш опыт

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

Отдельный проект — серверный кластер с резервированием узлов и хранилища, построенный под требование непрерывной работы регулируемых систем.

Расскажите, какие системы у вас критичны и сколько стоит час их простоя. С этого начнём.