Задача номер один в планировании мер обеспечения устойчивости бизнеса (business continuity planning, BCP) — это защитить самые ценные активы организации: здоровье и безопасность служащих. Вторая по важности задача — быстрое восстановление и запуск в работу критически важных для бизнеса систем. В данной статье перечислены девять шагов, которые следует предпринять, чтобы план аварийного восстановления был успешным.

Шаг №1. Подготовка

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

Шаг №2. Правильно сформулируйте план

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

Шаг №3. Знайте типичные ошибки и то, как их избежать

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

После каждого обновления системы или запуска процесса контроля изменений следует вновь протестировать BCP, чтобы убедиться, что ничто не нарушено и всё работает как надо. Не пренебрегайте полной проверкой вашего плана только потому, что “не подвернулся” простой. В этом деле может очень помочь использование платформы виртуализации (например, Microsoft Hyper-V), где вы можете создать виртуальную базу для аварийного восстановления и провести проверку, никак не затрагивая работу самой системы. Это достигается с помощью технологии виртуализации, которая позволяет сегментировать машины в действующей сети и создать виртуальный “испытательный стенд” аварийного восстановления.

Шаг №4. Имейте на всякий случай запасной план действий

За последние девять лет я участвовал, прямо или косвенно, более чем в 1600 внедрениях плана обеспечения устойчивости бизнеса, и в каждом случае было что-то, чему можно поучиться. Один из таких уроков — всегда планировать резерв для резерва. Во время внедрения аварийного восстановления в сети, насчитывавшей более 70 виртуальных серверов, батареи ИБП, служившего резервным источником питания для ЦОДа, вдруг взорвались. Поскольку главная линия питания проходила через ИБП, отключилось питание всего ЦОДа и около 40 серверов. К счастью, мы только что закончили всю установку и не завершили лишь пробный запуск, так что у нас получилось тестирование “в живую”.

Благодаря блестящим инженерам, с которыми я работаю, и тому, что мы внедряли эти решения уже сотни раз, мы смогли вновь запустить все критически важные бизнес-системы в ЦОДе уже через 15 мин. Был вызван HazMat, чтобы начать уборку остатков взорвавшихся батарей, и мы смогли восстановить все операции в главном ЦОДе примерно пять дней спустя. Это показывает, что даже наличие резервного плана не всегда означает 100%-ную гарантию.

Шаг №5. Правильно выберите приоритеты

При первоначальном анализе последствий аварии для деятельности компании (business impact analysis, BIA) команда BCP определит и назначит требуемый уровень защиты и восстановления для каждой из нужных бизнес-систем. Я наблюдал, как некоторые организации пренебрегают этим анализом и просто применяют одно и то же решение ко всем серверам; это не всегда оправданно и может увеличить общую стоимость проекта. Не для всех серверов требуется высокий уровень готовности с очень малым директивным временем восстановления (RTO) и директивным сроком восстановления (RPO), а только для тех, которые определены как критически важные для бизнеса и требуют немедленного и полного восстановления операций.

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

Шаг №6. Узнайте стоимость простоя

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

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

Шаг №7. Запланируйте худший сценарий

Еще одна типичная ошибка, которую часто допускают, заключается в том, что данные и бизнес-системы существующего ЦОДа не дублируются в другом месте, из которого их можно будет восстановить. Слишком часто организации внедряют отказоустойчивую систему, полагая, что она обеспечит высокую готовность, но не принимают в расчет случай, когда у них может отключиться электроснабжение всего здания (или, еще хуже, возникнет пожар или случится стихийное бедствие). Конечно, это ситуация исключительная, но ваш план BCP нельзя назвать полноценным, если вы предусмотрели лишь несколько сценариев. Нужно продумать самый худший из них, иначе вы оказываете своей организации медвежью услугу и подвергаете ее риску.

Шаг №8. Не только лента

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

Шаг №9. Убедитесь, что ваш план работает

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

С приходом технологии виртуализации в последние несколько лет это вообще перестало быть проблемой. В платформы виртуализации, в частности Microsoft Hyper-V, встроена функциональность, позволяющая провести такого рода проверку устойчивости бизнеса, выделив для этого виртуальную инфраструктуру, как если бы это был ваш центр аварийного восстановления, — и в сущности он таковым и является.

Проверка работоспособности плана BCP — единственный способ гарантировать, что он сработает, когда это будет нужно больше всего.