Все стандарты рекомендуют разные меры по обеспечению непрерывности бизнеса. Но как крупные, так и небольшие компании убеждены: построение резервного ЦОДа гарантированно избавляет организацию от прерывания нормальной деятельности.
Давайте попытаемся разобраться, почему чисто технологическое по сути решение по созданию резервного ЦОДа почти всегда воспринимается как синоним обеспечения непрерывности ИТ или даже непрерывности бизнеса. А многие вообще считают это единственным способом снизить риски прерывания деятельности ИТ или компании в целом.
На какой бы из перечисленных выше стандартов мы ни посмотрели, обеспечение непрерывности предполагает понимание бизнеса организации (бизнес-процессов, взаимодействия с поставщиками и регуляторами, дистрибуции) и зависимостей этого бизнеса от ИТ, документов, людей, зданий и прочих ресурсов. Понимание бизнеса и его зависимостей позволяет определить риски и ранжировать их по воздействию на бизнес компании в конкретных геополитических, физических и прочих условиях. Как правило, эти риски разделяют на следующие категории:
- социально-политические (например, забастовка или теракт);
- техногенные (авария теплопровода или на электроподстанции);
- природные (ураган, землетрясение и др.);
- человеческие (поджог, умышленная порча данных);
- предпринимательские (слияние, переезд и проч.).
Другими словами, чтобы снизить указанные риски, нужно создать резервные рабочие места и резервный ЦОД. Выяснив причину распространенности резервного ЦОДа как «панацеи от всех бед», не будем забывать об рисках, от которых он спасти не сможет. Точнее определить такого рода риски (а также вероятность их реализации и последствия) можно после анализа каждого конкретного случая.
Давайте предположим, что вероятность их реализации мала. Итак, мы решили, что резервный ЦОД нам поможет практически от всех наших рисков. Решение принято, давайте проектировать. Или нет? Может стоит оценить, какие важные проблемы останутся неразрешенными, если мы сразу же перейдем к проектированию решения по созданию резервного ЦОДа? В первую очередь, это будут такие важные для бизнеса вопросы:
- Какие бизнес-процессы/активности/приложения необходимо восстанавливать в первую очередь, а какие в менее срочном порядке? (Очевидно, что в случае катастрофы трудно, а подчас и неправильно хвататься за все с одинаковым рвением).
- Во сколько обойдется организации простой бизнес-процессов (как правило, поддерживаемых разными приложениями и другими ресурсами)?
- Какие требования со стороны бизнеса ко времени (сутки, час, 5 минут) восстановления тех или иных задач/процессов?
- Каков максимально допустимый объем (за последний час, последние сутки, месяц) потерь данных?
- Что считать катастрофой и после каких событий необходимо переводить приложения в «выживший» датацентр (резервный ЦОД)?
Ответы на эти и другие вопросы, оставшиеся «за кадром», очень важны для определения состава приложений, подлежащих восстановлению в резервном ЦОДе, и оптимальных (с точки зрения поставленных бизнесом задач) технологических решений для их восстановления. Иными словами, ответы на приведённые выше вопросы позволяют максимально снизить риск затрат (на гривну/доллар/евро).
Предположим, в результате проведённого анализа мы выяснили, что в компании Х потери от простоя некоторого приложения растут определённым образом. В настоящий момент приложение можно восстановить за 24 часа, при этом компания потеряет 250 тыс. долл. Бизнес требует восстановить приложение за 4 часа. Чего мы достигнем, снизив простой до 4 часов? Примером может послужить иллюстрация ниже.
Зависимость финансовых потерь от времени простоя бизнеса в компании Х
Давайте рассмотрим упрощённый пример. Итак, мы снизили простой с 24 до 4 часов, потенциальные потери упали с 250 тыс. до 20 тыс. долл. Предположим, что стоимость резервного ЦОДа (пускай это будет одна небольшая комната с одной стойкой), оборудования, программного обеспечения и сопутствующих операционных расходов за 5 лет (срок жизни оборудования) составила 190 тыс. долл. Потенциальные потери снизились на 230 тыс. долл.
Таким образом, зная, как нарастают потери компании при простое, чего требует бизнес и сколько будет стоить решение, после восстановления мы можем принять качественное, хорошо обоснованное решение.
- выбранные технологии не смогут обеспечить восстановление работы бизнес-процессов во временных рамках, приемлемых для организации с точки зрения потерь;
- резервный ЦОД будет потенциально способен обеспечить непрерывность бизнес-процессов, но отсутствие информации о требованиях ко времени восстановления или неверные приоритеты приведут к значительным потерям.
Чтобы избежать таких ситуаций, все мировые стандарты предлагают изучать бизнес-процессы и формировать перечень ресурсов для их работы. И конечно, нужно проанализировать воздействия на бизнес, чтобы получить всю необходимую информацию до начала проектирования.
Готовы ли мы теперь к техническому проектированию решения? Очевидно, что да. Но хочу обратить внимание читателя на то, что проектирование не может быть только техническим. Оно должно учитывать все параметры, необходимые для бизнес-процессов, с целью обеспечения их нормальной работы в условиях резервного ЦОДа. Таким образом, формирование стратегий восстановления (именно так называется в классических моделях эта стадия) является не только техническим проектом, а еще и предполагает изменения в бизнес-процессах организации.
- Технологиям или техническим решениям, которые обеспечивают репликацию информации в резервном ЦОДе в нормальном режиме и возможность продолжения работы в случае катастрофы/чрезвычайной ситуации.
- Техническим специалистам, которые должны поддерживать новую архитектуру решения, и пользователям бизнес-подразделений, которые должны будут твердо знать, что делать и как воспользоваться новыми технологическими возможностями, обеспечивающими бесперебойность бизнес-процессов в случае катастрофы/ЧС;
- Процессам как совокупности процедур и регламентов, описывающих работу ИТ-специалистов и пользователей приложений с учетом внедрения новых решений (и не только технологических). Точно разработанные и формализованные процессы позволят свести риск «человеческого фактора» к минимуму.
Если ничего из вышеперечисленного не было забыто на стадии внедрения, то можно смело говорить о том, что так называемый План обеспечения непрерывности бизнеса (в английской терминологии – Business Continuity Plan) уже создан.
Нерассмотренными, но обязательно входящими в полноценный План, являются следующие вопросы:
- Описана ли в созданном Плане процедура взаимодействия основного ЦОДа – резервного ЦОДа в нормальном режиме?
- Формализованы ли процедуры определения, объявления и реагирования на ЧС?
- Есть ли в плане процедуры, описывающие возврат к нормальному состоянию после ЧС?
- И наконец, то, что часто упускаем, – описано ли в Плане, как поддерживать его актуальность, то есть, как вносить коррективы, отражающие изменения в бизнес-процессах, технических решениях, организационной структуре компании и т.д.?
Пожалуй, мы подошли к логическому концу цикла создания резервного ЦОДа. Решения внедрены и работают, персонал обучен, План создан. Можно ли на этом ставить точку? Нет, нельзя! Как любой механизм, который стареет и ржавеет без регулярной работы и должной профилактики, созданное решение может работать совсем не так, как ожидалось в случае ЧС, если не отслеживать изменения и не проводить регулярных тренировок и репетиций.
Совершенно логично, что в процессе эксплуатации во все системы будут вносить изменения – устанавливать новые версии ПО, добавляться ресурсы SAN и СХД и т.д. Необходимо их учитывать и своевременно актуализировать План.
Одним из таких инструментов является CommandCentral Disaster Recovery Adviser от компании Symantec. Этот продукт предназначен для постоянного мониторинга всей вычислительной инфраструктуры и обнаружения потенциальных угроз аварийному восстановлению. Встроенная база знаний по потенциальным рискам позволяет обнаружить и вовремя устранить большинство возможных угроз восстановлению работоспособности резервного ЦОДа.
Автор статьи — технический директор Symantec в России и СНГ
