Посмотрим на происходящее с точки зрения управления непрерывностью бизнеса.  Сотрудники не могут добраться до работы. Ситуация в Лондоне еще относительно хороша тем, что о забастовке было известно заблаговременно. Гораздо чаще проблемы с транспортной доступностью возникают неожиданно, как результат серьезных аварий, терактов, или природных явлений (встречаем грядущий снегопад ).  Итак, что делать организациям?

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

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

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

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

Во-первых, это Recovery Workflow.

Кстати, объявляется конкурс на лучший перевод термина workflow. Победителю – всеобщее признание и моя личная благодарность .

Если раньше план непрерывности или аварийного восстановления мог содержать в себе только «плоские» списки задач, то начиная с 10.7 в LDRPS появилась возможность определять деревья принятия решений, зависимости, и альтернативные сценарии.

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

Выглядит это все примерно вот так.

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

Вторая полезная функция – это возможность использования внутри полей Rich Text Formatting.  Благодаря этому результирующий план может приобрести гораздо более аккуратный и современный вид.

Остальные нововведения относятся к интеграции между собой компонентов CMS. Добавился интегрированный вход в систему оповещения NotiFind, раcширились возможности по обмену данными между LDRPS и Incident Manager.

Продукт доступен для заказа – можно успеть до конца года

С декабря прошлого года линейка SunGard CMS заметно расширилась, и про все решения  в комплексе мы  еще ни разу не рассказывали.

Из новых решений речь пройдет про три  продукта, дополнивших BIA Professional:

• Risk Assessment
• Vendor Assessment
• Work Force Assesment

Кроме того, будет рассказано и про функциональность, появившуюся в новых версиях продуктов LDRPS и BIA Professional.

Как всегда, Вебинар проходит на русском языке и абсолютно бесплатен

Update 1: Запись Вебинара доступна здесь.

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

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

Сценариев ЧС, при которых может понадобиться экстренное восстановление рабочих мест, несколько.

1. Самый простой сценарий – сотрудники целы, офис цел, но сотрудники не могут попасть в офис. Например, в городе случился теракт и метро не работает.  Или наводнение. Или эпидемия.
2. Более сложный сценарий – люди целы, а вот офис – не совсем.  Если ИТ-инфраструктура и связь сохранилась, то задача сводится к п.1. Если же офис [частично] разрушен/обесточен/аппаратура конфискована, но – есть резервный ЦОД, задача тоже имеет решение.
3. Совсем тяжелый случай – когда часть людей по тем или иным причинам не может выполнять свои функции или участвовать в восстановительных работах. Это может быть вызвано как непосредственно проблемами (болезнь, повреждения или даже смерть), так и проблемами родных и близких, которые требуют неотложного участия.

Итак, как же быть?

На самом деле, задача (на верхнем уровне) сводится к двум подзадачам:

1. Тем, кто есть – дать возможность работать либо удаленно, либо на рабочих местах других сотрудников [в других,  не попавших под воздействие ЧС офисах].
2. Тех, кто не может выполнять свои функции – заменить другими, либо перераспределить их обязанности между теми, кто остался «в строю».

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

У задачи обеспечения альтернативных рабочих мест есть большая ИТ-составляющая. Если ваша ИТ-инфраструктура позволяет обеспечить удаленную работу, то 80% задачи решено. При этом важно убедиться в том, какое количество сотрудников может одновременно пользоваться удаленным доступом. Это ограничение может быть обусловлено пропускной способностью каналов к ЦОД организации, лицензионными ограничениями, либо мощностью оборудования. Подразумевается, что необходимая для этого инфраструктура зарезервирована и доступна даже в случае потери основного ЦОДа. С другой стороны, необходимо проверить, что у сотрудников есть доступ в Интернет и компьютер, удовлетворяющий требованиям для удаленной работы.

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

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

Случится то происшествие, которого вы не ждете.

Казалось бы, ничего нового, про это говорится от раза к разу, но, несмотря ни на что, зачастую готовимся мы именно к тому, с чем уже сталкивались в обозримом прошлом. Типичный пример тому – меры, принимаемые TSA по обеспечению безопасности полетов после очередных [попыток] терактов, когда защитные меры почему то выстраиваются исходя из предположения, что следующая попытка теракта произойдет в точности по сценарию предыдущей. Мораль – планы обеспечения непрерывности деятельности должны быть:
а) достаточно гибкими
б) рассчитывать на самые худшие сценарии развития ситуации

Не рассчитывайте на работоспособность коммунальных служб

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

• У вас не будет электричества. Его может не быть вообще, его могут ограничить предприятиям, его могут «веерно» отключать. В любом случае, если ваш бизнес – это не детский сад или больница, то с большой вероятностью при дефиците энергоснабжения вам может «не хватить».
• Дизель-генераторы могут не помочь. Например, если не будет достаточного запаса солярки, а дороги засыплет снегом. Или заправки не будут работать, потому что там не будет электричества, и насосы не будут работать.
• У вас не будет связи. Бесконечно трагичный, но очень яркий пример – недавнее землетрясение на Гаити. Точнее, не будет привычных видов связи – фиксированной и мобильной. Спутниковая, до определенного масштаба ЧС, будет продолжать работать.
• Воды тоже может какое-то время не быть. Кроме того запаса к кулерам, который есть у вас в офисе, если он есть.
• Транспорт работать не будет. Потому что (см.выше) – не будет топлива, электричества, дорог.

Мораль – определяя свою стратегию, учитывайте возможные изменения окружающего вас мира. Одно из направлений для размышлений – если все ядро вашего бизнеса расположено в одной точке пространства (включая ИТ) – серьезно подумайте о том, чтобы разместить резервную площадку на значительном отдалении.

После ЧС – проведите переоценку RTO

Отличный совет, Чарли. BIA – это компромисс между амбициями подразделений, и ценой обеспечения высоких показателей восстановления. Далеко не всегда в процессе BIA удается сделать четкую количественную оценку потерь в случае ЧС и доли в ней от простоя отдельных бизнес-процессов. Однако реальная чрезвычайная ситуация отлично расставляет все по местам, и вы можете реально посмотреть, что произошло, если показатели RTO не были достигнуты.

Внутри своей компании мы уже обсуждали возможность сделать типовое решение для банков, которое позволит провести анализ воздействия на бизнес, оценку рисков и на основе собранной информации сформировать типовой план ОНиВД. В США такое решение достаточно успешно функционирует – система PlaNET, разработанная SunGard Availability Solutions на основе продуктов LDRPS и BIA Professional с ограниченной функциональностью. Основные ограничения, внесенные в продукт  -  это невозможность изменения шаблонов планов, опросных листов и т.п. Взамен этого заказчик получает встроенную в продукт методологию проведения анализа  воздействия на бизнес, оценки рисков и типовые планы, учитывающие специфику банковской деятельности.

Со своей стороны, мы (Алмитек) готовы сделать типовое решение по созданию планов ОНиВД на движке Continuity Management Solution, включающем в себя BIA Professional, Risk Assessment и LDRPS. Но для того, чтобы этот проект был успешен, нам необходимо две вещи:

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

Если вы представляете банк, которому может быть интересно либо использовать готовый сервис, либо принять участие в его создании, я буду признателен за короткое письмо на адрес bcp@almitech.ru, в котором вы обозначите ваш интерес к решению.

Для тех читателей, которые не знакомы с функциональностью предыдущих версий, несколько слов о том, для чего предназначен BIA Professional. Продукт позволяет автоматизировать рутинную часть работы по проведению анализа воздействия на бизнес, а именно - подготовку анкет/опросных листов, рассылку их анкетируемым сотрудникам, сбор, консолидацию и последующий анализ информации. Что немаловажно, продукт позволяет обеспечить повторное использование информации – при регулярном обновлении результатов BIA, пользователям не надо заново отвечать на те же самые вопросы,  а достаточно только проглядеть сохраненные старые ответы, и, при необходимости, внести корректировки.

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

Основной экран системы теперь выглядит таким образом:

На сегодняшний день в CMS интегрировано 3 продукта - BIA, Risk Assessment и LDRPS. Оставшиеся Incident Manager и Notifind обладают механизмами интеграции, но пока функционируют на другой платформе.

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

Итак, первый шаг – создание анкет. В разделе «Question Manager» мы получаем возможность создавать «кирпичики», из которых впоследствии будут строиться анкеты. Как это принято у SunGard, серьезным достоинством продуктов является не только механизм, позволяющий создавать анкеты «с чистого листа», но и богатый набор уже существующих шаблонов. Символичным является факт, что на первом месте в списке этих «кирпичиков» находится шаблон «CEO Risk Tolerance» – как бы призывающий проводить BIA, начиная с самого верха организации.

Для каждого из элементов анкеты BIA Professional предоставляет мощный инструмент для визуального дизайна, который позволяет не только формировать экранные формы, но и определять логику внутри этой формы – рассчитывать вычисляемые поля, задавать условия валидации, и т.п. Для создания внутренней логики используется собственный C#-подобный язык, а для общения с СУБД – механизмы маппинга полей форм на поля таблиц СУБД, и несколько способов определения критериев, по которым будут отбираться записи для каждого конкретного пользователя. В качестве примера – можно дать пользователю возможность видеть только те бизнес-процессы, которые относятся к его подразделению, и для них дать право определять целевые показатели восстановления.

В отличие от предыдущей версии, здесь мы можем полностью ощутить все прелести интеграции с LDRPS – названия таблиц и полей БД мы видим в бизнес-терминах, и все, что уже наработано в планах внутри LDRPS, доступно при исходном заполнении форм данными. Справедливо и обратное – данные, введенные сотрудниками в процессе проведения BIA могут быть помещены в соответствующие сущности LDRPS, и на их основе впоследствии и будут создаваться планы непрерывности бизнеса и аварийного восстановления.

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

Выглядит все это примерно так:

Разработав отдельные экраны анкет, можно переходить к их компоновке. BIA Professional позволяет делать как последовательный перечень форм, так и условные ветвления в зависимости от значений полей/формул. Например, в зависимости от должности анкетируемого, какие-то экраны могут быть пропущены, а другие, наоборот, добавлены.

Завершив формирование анкеты, на следующем этапе мы определяем пользователей, которые должны ее заполнить (опять же, используется единый с LDRPS список пользователей). На этом подготовительная работа завершена, и, нажатием одной кнопки всем пользователям рассылаются письма с URL-ссылкой и реквизитами доступа к анкете.  Далее, пользователи в комфортном для себя режиме заполняют свои анкеты, при этом администратор имеет возможность отслеживать статус заполнения анкет сотрудниками.

Как видно из скриншота, пользователь имеет возможность перемещаться между различными экранами анкеты в произвольном порядке (за исключением тех экранов, которые зависят от условий ветвления).

После того, как все сотрудники завершат заполнение своих анкет, администратор системы инициирует  два основных события:

1. Генерация отчета с результатами анализа воздействия на бизнес.
2. Заполнение таблиц LDRPS данными, необходимыми для планов аварийного восстановления/непрерывности бизнеса.

Для проектирования итоговых отчетов используется, как и в LDRPS, генератор отчетов Crystal Reports, так что, если вас не устраивают отчеты, предлагаемые по умолчанию, то вы можете легко их поправить, либо разработать свои собственные.

Напоследок – немного о лицензировании решения.

BIA Professional лицензируется на организацию в целом, без ограничения количества анкетируемых сотрудников. По умолчанию лицензируется одно одновременное подключение (concurrent user) для администратора, занимающегося созданием, распространением и сбором анкет. В случае необходимости параллельной работы нескольких администраторов (что теоретически можно представить в очень большой компании), стоимость лицензии на каждого дополнительного администратора составит 12,5% от исходной цены. Новая версия BIA Professional будет стоить на $5000 дороже предыдущей, но до конца декабря 2009 года существует возможность приобрести предыдущую версию по старой цене, и в рамках техподдержки осуществить бесплатный переход на новую версию.

Дополнительную информацию по продукту, ценам, возможности тестирования и т.п. можно запросить по адресу bcp@almitech.ru.

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

VMware High Availability (HA)

VMware HA позволяет в случае выхода из строя одного из серверов кластера ESX перезапустить все гостевые машины на оставшихся серверах. Решение является аналогом Active-Passive кластера из мира «железных» серверов, за исключением того, что не возникает проблем расхождения конфигураций, которая серьезно осложняет жизнь администраторов, обслуживающих большой парк серверов. Незначительным недостатком данного решения является определенное, хотя и небольшое, время восстановления (RTO), необходимое на перезапуск вирутальной машины.

 VMware Fault Tolerance (FT)

VMware FT отчасти напоминает Active-Active кластер, но при ближайшем рассмотрении фунционирует принципиально по другому. Целью использования FT является обеспечение практически нулевого RTO в случае выхода из строя сервера ESX. Достигается это параллельным выполнением виртуальных машин на двух соседних серверах на уровне параллельного выполнения команд процессора. При этом весь вывод на дублирующей виртуальной машине подавляется на уровне гипервизора. Основным ограничением данной технологии на сегодняшний момент является невозможность использования FT для виртуальных машин с числом процессоров больше одного, а также невозможность создания FT кластера из машин, построенных на процессорах различной архитектуры. Кроме того, естественным ограничением является требование хранения виртуальных машин на разделяемой СХД.

VMware Site Recovery Manager (SRM)

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

• Поддержка vSphere;
• Возможность работать с shared DR сайтами, что позволяет использовать один DR сайт для резервирования нескольких основных сайтов;
• Поддержка переноса машин, работающих в режиме Fault Tolerance;
• Расширенная поддержка СХД – NFS, iSCSI, Fiber Channel.

В 15 выпуске издания «Платежные и расчетные системы» ЦБ опубликовал переводы сразу двух документов в области непрерывности бизнеса в финансовой сфере: «Руководящие принципы обеспечения непрерывности бизнеса» Базельского банковского комитета (Банк по международным расчетам), и «Рекомендации по наблюдению за непрерывностью деятельности для системно значимых платежных систем» Европейского Центробанка.

Первый документ, как известно, послужил основой при выпуске изменений к Инструкции 242-П, поэтому на нем я остановлюсь поподробнее. Второй тоже достаточно любопытно прочитать, среди прочих моментов он дает чуть более широкий взгляд на целевые показатели обеспечения непрерывности деятельности, ставя для ряда участников рынка по главу угла влияние от прерывания деятельности не на их собственный бизнес, а на платежную систему на уровне страны (точнее говоря, Еврозоны). Несмотря на то, что документ ориентирован на финансовые организации стран Еврозоны, прочитать стоит, тем более, что документ небольшой. Единственное, рекомендую читать в оригинале, т.к. перевод этого документа, в отличие от «Руководящих принципов…», сильно оставляет желать лучшего.

Теперь вернемся к «Руководящим принципам…»

Поскольку этот документ во многом лег в основу измений к 242-П, достаточно интересно посмотреть, что из семи принципов вошло в 242-П, и в каком виде. Итак, по порядку.

Принцип 1. Ответственность совета директоров и высшего руководства.
«Советы директоров и высшее руководство организаций несут коллективную ответственность за непрерывность бизнеса организации.»

Принцип безусловно разумный, и, среди прочего, пересекается с рекомендациями BS 25999. Однако, в 242-П по каким-то причинам эти рекомендации не вошли. Тем не менее, основываясь на своем опыте, я бы рекомендовал максимально стараться воплотить его в жизнь – система будет работать горадо эффективнее.

Принцип 2. Крупные операционные нарушения.
«Участники финансового сектора и финансовые органы при формировании подхода к управлению непрерывностью бизнеса должны учитывать риск крупного операционного нарушения. Финансовым органам также следует оценить их собственную реакцию на потенциальные крупные операционные нарушения, которые могут затруднить проведение операций участниками финансового сектора или финансовой системой, за работу которой они несут ответственность.»

Тезис о том, что планы ОНиВД должны предусматривать возможность масштабных ЧС в 242-П вошел, и даже был дополнен ссылками на Российские нормативные документы. А вот рекомендации по поводу альтернативных площадок остались за кадром.

Принцип 3. Цели восстановления
«Участники финансового сектора должны сформулировать для себя цели восстановления, учитывающие потенциальный риск, который они представляют для операций финансовой сферы. Предпочтительно, чтобы формулировки таких целей восстановления были согласованы с соответствующими финансовыми органами или разрабатывались ими.»

Если в «Принципах…» делается упор на возможной влияние на финансовую систему в целом, то 242-П больше сфокусировано на стандартных для анализа воздействия на бизнес аспектах, т.е. влияние на бизнес кредитной органиации, как таковой.

Принцип 4. Обмен информацией.
«Участники финансового сектора и финансовые органы должны включать в свои планы обеспечения непрерывности бизнеса процедуры для обмена информацией во время крупного операционного нарушения внутри организации и с соответствующими внешними сторонами.»

Принцип нашел свое отражение в 242-П (Пункт 7 Приложения 5), хотя и в более общей форме.

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

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

Принцип 6. Проверки (тестирование).
«Участники финансового сектора и финансовые органы должны производить проверку своих планов
обеспечения непрерывности бизнеса, оценивать их эффективность и соответствующим образом совершенствовать управление непрерывностью бизнеса.»

 Здесь 242-П раскрывает вопрос даже более подробно. Единственное, пожалуй, что было исключено – это крупномасштабное тестирование с вовлечением множества кредитных организаций. Наверное, не самое сейчас подходящее время – не все могут выдержать…

Принцип 7. Контроль за управлением непрерывностью бизнеса со стороны финансовых органов
«Финансовые органы должны включать в практику своей работы осуществление контроля за управлением непрерывностью бизнеса для проведения оценки участников финансового сектора, находящихся в сфере их ответственности.»

Этот пункт относится скорее к деятельности самого ЦБ, и появление изменений к 242-П можно считать первым шагом на пути выполнения этого принципа.

Обобщая все вышесказанное, можно рискнуть сделать следующие выводы:

1. В некоторых аспектах «Руководящие принципы…» оказываются более подробными, чем 242-П, соответственно, и в этих вопросах ими можно и нужно пользоваться. Равно как и другими стандартами, такими как BS 25999, BS 25777.
2.  »Руководящие принципы…» дают некоторое представление, в какую сторону, скорее всего, будет развиваться регулирование со стороны ЦБ.

С одной стороны, это стандарт по информационной безопасности СТО БР ИББС-1.0-2008. Невзирая на рекомендательный характер документа, банковское сообщество относится к нему с достаточным уважением, ибо понятно – просто так Банк России чего-то рекомендовать не будет.

Второй документ, выдвигающий гораздо более серьезные требования – положение 242-П «Об организации внутреннего контроля в кредитных организациях и банковских группах». Требования по наличию планов обеспечения непрерывности бизнеса были в нем и раньше, но только с 2009 года в нем появилось подробное описание того, что, собственно, Банк России рассчитывает увидеть. В документе достаточно подробно расписаны требования практически ко всем этапам жизненного цикла СУНБ. Само постановление носит обязательный характер, а вот «Рекомендации по структуре и содержанию плана…», как это следует из их названия - рекомендательный. Появление новой редакции 242-П заставило банки гораздо серьезнее присмотреться к вопросам обеспечения непрерывности бизнеса.