План аварийного восстановления: как бизнесу подготовиться к потере данных заранее

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

Чем план аварийного восстановления отличается от резервного копирования?

Бэкап — это просто копия данных, лежащая где-то отдельно. А план аварийного восстановления, или DRP (Disaster Recovery Plan), — это инструкция, как этой копией воспользоваться, чтобы вернуть бизнес в рабочее состояние. Можно иметь идеальные резервные копии и всё равно потерять сутки на восстановление, потому что никто заранее не продумал порядок действий.

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

Каким компаниям это действительно нужно?

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

Малому бизнесу план не обязательно оформлять как толстый документ на сто страниц. Иногда достаточно одной таблицы на пару листов с чёткими шагами и ответственными.

Из каких частей состоит такой план?

Обычно в план включают несколько обязательных блоков:

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

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

Как понять, какие системы критичны, а какие можно восстановить позже?

Здесь помогает простой вопрос: сколько компания потеряет денег и репутации, если эта система не будет работать час, день, неделю? Сайт интернет-магазина, через который идут заказы, обычно критичен максимально — простой напрямую бьёт по выручке. А, например, внутренняя база с архивными документами пятилетней давности может подождать восстановления и подольше.

Такое разделение систем на уровни важности называют приоритизацией. Именно она позволяет не распыляться и в первую очередь чинить то, что действительно останавливает бизнес, а не тратить время на второстепенное.

Кто должен участвовать в составлении плана?

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

Нужно ли проверять план на практике?

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

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

Что делать бизнесу, у которого нет своего айти-отдела?

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

Например, платформа «Клауд АйСи» предоставляет облачные серверы, базы данных и сервисы резервного копирования, где восстановление данных — это часть стандартного процесса, а не разовая импровизация в критической ситуации. Это снимает с бизнеса часть нагрузки по самостоятельной разработке и тестированию собственного плана: инфраструктура строится так, что копии данных и порядок их восстановления уже продуманы заранее.

Как часто нужно обновлять план?

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

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