- Восстановление технической среды
- Резервирование оборудования
- Резервирование программного обеспечения
- Документация
- Люди
- Восстановление пользовательской среды
На данный момент у команды BCP есть схемы критичных бизнес-функций, которые обязательно должны выполняться, определен наилучший для компании вариант альтернативной площадки. Теперь команда должна углубиться в детали, такие как обеспечение резервирования для следующих элементов:
- Сетевое и компьютерное оборудование
- Коммуникационное оборудование для передачи голоса и данных
- Люди
- Средства для транспортировки оборудования и персонала
- Системы вентиляции, отопления и кондиционирования
- Системы обеспечения безопасности персонала и данных
- Различные расходные материалы (бумага, бланки, кабели и т.п.)
- Документация
Поэтому команда BCP должна убедиться, что люди, которые будут восстанавливать сеть в случае ее частичного или полного разрушения, имеют достаточно сведений и знаний, и смогут надлежащим образом восстановить ее.
ПРИМЕЧАНИЕ. Многие компании используют технологии VoIP, а это значит, что при нарушении работы сети, голосовые функции будут также недоступны. Команде следует учесть возможную потребность компании в наличии дополнительной (резервной) голосовой системы.
Команде BCP необходимо принять во внимание многие вещи, в том числе те, о которых часто забывают: например, замену оборудования, обновление программных продуктов, документацию, замену персонала.
Команда должна определить, какое оборудование необходимо для обеспечения работоспособности наиболее важных для компании функций. В состав такого оборудования могут входить серверы, пользовательские рабочие станции, маршрутизаторы, коммутаторы, ленточные накопители для резервного копирования, концентраторы и многое другое. Перечень необходимого оборудования может показаться достаточно простым, пока команда не углубится в детали. Если команда планирует, что при восстановлении серверов и рабочих станций будут использоваться созданные заранее образы их жестких дисков, ей нужно проанализировать вопрос – будут ли работать эти образы на новом оборудовании, приобретенном взамен уничтоженного или вышедшего из строя. Восстановление системы с образа вместо повторной установки и настройки программного обеспечения, может сэкономить массу времени, однако на новом оборудовании эти образы, скорее всего, работать не будут. Поэтому команда BCP должна специально для такого случая разработать запасной план, предусматривающий восстановление каждой из критичных систем «с нуля», без использования образов.
Также, команда BCP должна выяснить, сколько времени займет доставка нового оборудования. Если команда определила, что для восстановления работоспособности компании на удаленной площадке ей понадобится 20 серверов и 50 рабочих станций, она должна узнать у поставщика, с которым работает компания, сколько времени займет у него поставка этого оборудования на удаленную площадку с момента подачи компанией соответствующей заявки. Может оказаться, что поставщик компании сможет выполнить такой заказ только в течение трех недель. Если компания узнает об этом, когда авария уже произойдет, это может стать для нее катастрофой. Чтобы избежать этого, команда должна проанализировать текущие соглашения об уровне услуг (SLA - Service Level Agreement) поставщиков компании и, при необходимости, организовать заключение новых соглашений, чтобы избежать дополнительного ущерба, вызванного задержками поставки оборудования. После того, как параметры SLA стали известны, команда должна сделать выбор между заблаговременным приобретением избыточных резервных систем и зависимостью от поставщика (сроков поставки). Как уже говорилось ранее, в случае выявления потенциальных рисков компании, следует принять превентивные меры для уменьшения потенциального ущерба. После расчета значений MTD, команда будет знать, как долго компания сможет прожить без того или иного устройства. Эти значения должны быть учтены в процессе принятия решения относительно покупки резервных систем для быстрой замены, либо зависимости от SLA с поставщиком. Если ущерб компании от недоступности даже одного сервера составляет $50 000 в час, команде следует принять решение в пользу закупки избыточных резервных систем и оборудования.
В случае если компания использует какое-либо устаревшее оборудование или компьютеры, сможет ли она найти ему замену в случае необходимости? Команда должна выявить устаревшие устройства и определить, какие риски несет компания в случае невозможности их замены. Часто эти риски оказываются стимулом для перехода компании от устаревших систем к более современным, чтобы обеспечить возможность замены.
ПРИМЕЧАНИЕ. На рынке существуют ленточные устройства резервного копирования, в которых используются технологии различных типов (Digital Linear Tape, Digital Audio Tape, Advanced Intelligent Tape). Команда должна уточнить тип технологии, используемой в компании, чтобы определить, у какого поставщика можно будет приобрести ленточный накопитель, в случае, если его потребуется заменить.
В подразделениях ИТ большинства компаний дистрибутивные комплекты программного обеспечения и лицензионные ключи от них хранятся в множестве различных мест, а не централизовано. Как сотрудники ИТ получат доступ к этим дистрибутивным комплектам и лицензионным ключам в случае разрушения здания? Команда BCP должна обязательно оформить перечень программного обеспечения, необходимого для функционирования критически важных функций, организовать хранение копий дистрибутивов и лицензионных ключей на удаленной площадке. Ведь при отсутствии программного обеспечения, оборудование, как правило, окажется бесполезным. Должны быть созданы резервные копии такого программного обеспечения, как, например, бизнес-приложения, утилиты, системы управления базами данных, операционные системы. План непрерывности должен содержать требования по резервному копированию и защите этого программного обеспечения, а не только оборудования и данных.
Команда BCP должна убедиться, что существует, по меньшей мере, две копии операционных систем и критически важных приложений, используемых в компании. Одна копия должна храниться на основной площадке, а другая – в безопасном месте на удаленной площадке. Эти копии следует периодически проверять и создавать новые копии, когда в компании внедряются новые версии этого программного обеспечения.
Нередко компании заказывают у разработчиков индивидуальное специализированное программное обеспечение. Например, крупному банку может потребоваться автоматизированная банковская система, котоая позволит его служащим работать со счетами, хранить информацию клиентов в базах данных, предоставлять функции дистанционного банковского обслуживания, выполнять репликацию данных, а также обеспечит выполнение сотен других видов банковских операций. Это сложное специализированное программное обеспечение, разработкой которого занимаются всего несколько производителей, специализирующихся на банковской отрасли. После покупки такого программного обеспечения банком, оно должно быть доработано и настроено, чтобы учесть его индивидуальные особенности и потребности. Когда это программное обеспечение внедрено, работа банка всецело зависит от его непрерывной работы.
При этом производители такого программного обеспечения в большинстве случаев не предоставляют своим заказчикам исходных кодов, заказчик получает только скомпилированные версии. Но что будет, если производитель прекратит свое существование по той или иной причине? Заказчику, внедрившему это программное обеспечение, потребуется новый производитель, который будет поддерживать и дорабатывать это программное обеспечение, но для выполнения этой работы новому производителю будут необходимы исходные коды.
Механизмом защиты в данном случае является передача исходного кода программного обеспечения на хранение независимой третьей стороне (Software Escrow). Эта третья сторона хранит у себя исходный код, резервную копию скомпилированного программного обеспечения (дистрибутива), комплект инструкций и другие вспомогательные материалы. При этом заключается трехсторонний договор (между производителем программного обеспечения, заказчиком и третьей стороной), который описывает, кто, что и при каких обстоятельствах может делать с исходным кодом. Обычно в этом договоре указывается, что заказчик может получить доступ к исходному коду, только в случае, если производитель прекращает свое существование или по иным причинам не может выполнять свои обязательства перед заказчиком, либо если производитель нарушает условия первоначального договора с заказчиком. Если происходит любое событие из этого перечня, клиент может получить доступ к исходным кодам, обратившись к третьей стороне, а затем заключить договор с новым производителем.
Работа многих компаний была парализована из-за того, что они не использовали Software Escrow. Эти компании платили разработчику за создание специализированного программного обеспечения, а когда фирма разработчика разорялась, они теряли возможность выполнения своих важнейших функций.
Комитет ВСР должен выявить эту проблему (уязвимость) в процессе проведения анализа и реализовать превентивные контрмеры: Software Escrow.
Документирование многим людям кажется просто ужасной задачей, ведь у них много других важных дел, помимо документирования процессов и процедур. Без надлежащей документации, компания не сможет восстановить работу после чрезвычайной ситуации, несмотря на добросовестно выполненную работу по резервированию оборудования и программных средств на альтернативной площадке, качественное сопровождение этого процесса, выполнение ежедневного резервного копирования информации. Просто никто не будет знать, как воспользоваться всем этим, чтобы восстановить работу всех важных процессов и процедур.
Даже восстановление отдельных файлов может вызвать трудности, а восстановление всей инфраструктуры и сети компании, пострадавшей в результате наводнения, может оказаться крайне сложным, или вообще невозможным. Все важные процедуры должны быть хорошо задокументированы, поскольку процесс восстановления, скорее всего, будет происходить в атмосфере хаоса, полной неразберихи и неопределенности. Документация должна содержать подробную информацию о том, как правильно установить образы дисков, настроить операционные системы и серверы, установить утилиты и прикладное программное обеспечение. Другая часть документации должна описывать дерево вызовов (calling tree), которое указывает, кто с кем должен контактировать и в какой последовательности. В документации должна быть указана контактная информация отдельных поставщиков, местных служб по чрезвычайным ситуациям, площадок в удаленных зданиях и любых других людей и компаний, с которыми может потребоваться контактировать в чрезвычайной ситуации.
Большинство сетей используется непрерывно. Одно программное обеспечение устанавливается вместо другого, конфигурации программного обеспечения периодически подстраиваются для учета изменений среды, устанавливаются пакеты обновлений и патчи, предназначенные для исправления ошибок. Ожидать, что один человек (или группа) сможет в критической ситуации по памяти повторить все эти шаги и вернуть работу всей среды в состояние, в котором она находилась до аварии, это просто фантастика.
Поэтому компании все же необходимо обратить внимание на эту страшную задачу – документирование. Документирование – это неотъемлемая часть планирования восстановления после аварий и обеспечения непрерывности бизнеса.
Следует создать роль (одну или несколько), ответственную за подготовку и поддержание актуальности необходимой документации. Документация должна быть разработана, она должна быть понятна, актуальна и надежно защищена. После выявления командой ВСР необходимости выполнения определенных задач, эти задачи должны быть распределены по ответственным сотрудникам, а эти сотрудники должны своевременно отчитаться об их выполнении. Иначе работа команды ВСР может оказаться пустой тратой времени и ресурсов для компании, а компания по-прежнему останется уязвимой.
ПРИМЕЧАНИЕ. Компании может потребоваться организовать взаимодействие с официальными лицами в правительстве и службах реагирования на чрезвычайные ситуации, чтобы иметь возможность заблаговременно получать информацию о возможных чрезвычайных ситуациях и катастрофах в масштабах города или региона. Также, команде следует контактировать с официальными лицами на этапе проведения BIA, чтобы получить достоверную информацию о рисках, существующих в той местности, в которой расположено здание компании, о способах доступа в зоны чрезвычайных ситуаций и т.п. Кроме того, такие контакты следует предусмотреть и для процесса восстановления.
Планы. Как вы думаете, где и в каком количестве должны храниться разработанные планы обеспечения непрерывности бизнеса и восстановления после аварий? Достаточно ли компании хранить только один экземпляр этих планов в сейте руководителя подразделения ИТ? Нет! Должно быть, как минимум, две или три копии этих планов. Одна копия должна находиться на основной площадке, а остальные – на альтернативных площадках на случай, если основное здание будет уничтожено или недоступно. Иногда еще одна копия хранится у ВСР-координатора дома. Хранение копий планов в нескольких удаленных друг от друга местах существенно снижает риск того, что план окажется недоступен в случае необходимости.
Кроме того, эти планы не следует хранить в обычном шкафу, лучше хранить их в огнеупорном сейфе. Если планы хранятся вне зданий, принадлежащих компании, должны быть предприняты меры, обеспечивающие уровень их защиты, аналогичный уровню защиты при хранении в здании компании.
Одним из важнейших ресурсов, о котором часто забывают при планировании непрерывности – это люди. Компания может восстановить функционирование своей сети, установить и запустить критичнные приложения, восстановить данные… и только потом понять, что ответ на вопрос «кто будет пользоваться всем этим?» - неизвестен. Люди являются критическим компонентом для любых процессов восстановления и обеспечения непрерывности, поэтому необходимо, чтобы этот компонент был полностью интегрирован в соответствующие планы.
Что случится, если компания переедет в другое здание, расположенное на расстоянии в 200 километров от основного здания? Нельзя ожидать при этом, что персонал просто так согласится ездить туда-сюда из дома на работу. Может быть следует оплатить необходимым сотрудникам временное проживание в новом месте? Или лучше оплатить их расходы на дорогу? А может компании нанять новых сотрудников в том месте, где находится ее альтернативное здание? Какие навыки от них требуется? Команда ВСР должна получить четкие ответы на весь этот длинный список вопросов.
В случае возникновения широкомасштабной катастрофы, которая окажет воздействие не только на здание компании, но также и на окружающую местность, включая дома, как вы думаете, о чем сотрудники будут больше волноваться – о компании или о своей семье? Некоторые компании считают само собой разумеющимся, что сотрудники будут доступны и готовы помочь восстановить работоспособность компании, а в действительности им нужно будет находиться дома, для выполнения своих обязанностей перед своей семьей.
Как это ни печально, но некоторые сотрудники могут погибнуть в случае катастрофы и команда должна учесть, каким образом их можно будет быстро заменить. Конечно, это не очень приятно, но такова реальность. Команда должна выявить все возможные угрозы, продумать все вопросы и заранее подготовить соответствующие решения.
Компаниям следует спланировать последовательность замены руководителей (executive succession planning). В этом плане должно быть предусмотрено, что если кто-то из высшего руководства недоступен, уволен из компании или погиб, компания должна иметь заранее продуманные шаги, обеспечивающие ее защиту. Потеря даже одного топ-менеджера может создать «дыру» в организации работы компании, вакуум в управленческом составе, который должен быть быстро заполнен правильным человеком. Последовательности в этом плане определяют, кто возьмет на себя обязанности этой должности (роли). Многие компании имеют должности заместителей. Например, в компании может быть заместитель директора по ИТ, заместитель финансового директора и заместитель генерального директора, уже готовые выполнять необходимые задачи, если не доступны руководители, которых они замещают.
Во многих крупных компаниях существует политика, которая запрещает подвергать одновременно одному и тому же риску двух и более топ-менеджеров. Например, генеральный директор и президент компании не могут путешествовать в одном самолете. Если этот самолет упадет, оба этих руководителя могут погибнуть и компания может оказаться в опасности. Именно поэтому вы очень редко можете увидеть Президента США в компании с Вице-президентом.
Ссылки по теме:
Функционирование среды, в которой работают конечные пользователи, должно быть восстановлено максимально быстро после катастрофы. Для этого команда ВСР должна понимать текущее операционное и техническое функционирование среды и исследовать ее критичные части, на предмет возможностей по их дублированию.
Первым вопросом в отношении пользователей является вопрос о порядке их уведомления о катастрофе и об их дальнейших действиях. Для решения этого вопроса, на случай катастрофы может быть разработано дерево вызовов для руководителей: человек на вершине дерева звонит двум руководителям, они звонят трем руководителям и т.д. пока все руководители не будут проинформированы. Каждый руководитель отвечает за уведомление подчиненных ему сотрудников. После этого, один или два человека должны заняться координацией вопросов, относящихся к пользователям. Среди таких вопросов может быть их перемещение в новое здание, проверка наличия у них необходимых для выполнения своих задач ресурсов, восстановление данных, обеспечение взаимодействия между различными группами. Люди, выполняющие работу координаторов, должны быть легко узнаваемы, например, они могут носить «аварийную» кепку и майку, они должны находиться в таких местах, где все их видят. Это упростит работу и снизит панику в это трудное и стрессовое время.
В большинстве случаев, после катастрофы только ключевой персонал возвращается на работу. Для определения этого ключевого персонала, Комитет ВСР на этапе анализа идентифицирует наиболее критичные функции, работа которых должна быть восстановлена в первую очередь, а также сотрудников, выполняющих эти функции, которые должны первыми вернуться к работе. Процесс восстановления пользовательской среды выполняется в несколько этапов. На первом этапе обеспечивается возможность для возвращения к работе наиболее критичных подразделений, на втором этапе – вторых по степени критичности и т.д.
Команда ВСР должна определить потребности пользователей, например, могут ли они работать за локальными компьютерами или они обязательно должны быть подключены к сети для выполнения определенных задач. К примеру, в финансовой компании сотрудники могут использовать локальные компьютеры для выполнения отдельных задач, таких как заполнение бланков документов, обработка текстов, выполнение задач по учету, но для выпонения других операций им может в обязательном порядке требоваться подключение к сети – для работы с базами данных, обмена информацией и т.п.
Команда ВСР должна определить, какие из автоматизированных задач могут выполняться вручную, при необходимости. Если сеть отключилась на 12 часов, какие важные задачи могут быть выполнены с помощью ручки и листа бумаги? Если соединение с Интернетом пропало на пять часов, какую важную информацию можно передать с помощью телефонного звонка? Могут ли курьеры передавать информацию в случае неработоспособности внутренней электронной почты? Сегодня мы полностью зависим от технологий, и часто нам кажется, что они всегда будут доступны нам для использования. Но, увы, это не так. Задачей команды ВСР является минимизация времени недоступности информационных технологий и предоставление решения по организации работы на это время.
Комментариев нет:
Отправить комментарий