С начала октября мы принимаем участие в бета-тестировании новой версии продукта для проведения анализа воздействия на бизнес – Business Impact Analysis Professional компании SunGard Availability Services. По нашей оценке, продукт уже достиг достаточного уровня стабильности работы, чтобы о нем было не стыдно рассказывать, и, предваряя примерно на месяц выход коммерческой версии, сегодня я расскажу об основных возможностях продукта.
Для тех читателей, которые не знакомы с функциональностью предыдущих версий, несколько слов о том, для чего предназначен BIA Professional. Продукт позволяет автоматизировать рутинную часть работы по проведению анализа воздействия на бизнес, а именно - подготовку анкет/опросных листов, рассылку их анкетируемым сотрудникам, сбор, консолидацию и последующий анализ информации. Что немаловажно, продукт позволяет обеспечить повторное использование информации – при регулярном обновлении результатов BIA, пользователям не надо заново отвечать на те же самые вопросы, а достаточно только проглядеть сохраненные старые ответы, и, при необходимости, внести корректировки.
Перед тем, как начать описывать возможности продукта, я бы хотел сделать акцент на том, в каких случаях организации действительно нужен BIA Professional, чтобы получить адекватную отдачу от сделанных инвестиций. Давайте рассмотрим три критерия, каждый из которых может послужить достаточным аргументом для приобретения продукта.
- Масштаб организации. Если в процессе проведения анализа воздействия на бизнес вам приходится проводить анкетирование значительного числа сотрудников, то BIA Professional может оказаться существенным подспорьем. По моему опыту, собрать и консолидировать информацию даже из 50 анкет – это уже серьезный труд.
- Динамика организации. Если бизнес-процессы, внутренняя или внешняя среда организации подвержены частым изменениям, то скорее всего вам приходится обновлять результаты BIA 1-2 раза в год. Как следствие, этот процесс будет регулярно требовать отвлечения от основной деятельности большого числа руководителей среднего и высшего звена, и крайне важно минимизировать затраты их времени.
- Методология. Если вы хотите быть уверенным, что весь процесс BIA, начиная со сбора информации, и заканчивая подготовкой финальных отчетов, происходит в строгом соответстии с разработанной вами формальной методикой, средства автоматизации позволят вам добиться этого результата. Более того, вы можете предъявить этот факт при аудите вашей системы обеспечения непрерывности деятельности (будь то аудит Банка России по 242-П, или аудит на соответствие BS 25999).
Основной экран системы теперь выглядит таким образом:
На сегодняшний день в CMS интегрировано 3 продукта - BIA, Risk Assessment и LDRPS. Оставшиеся Incident Manager и Notifind обладают механизмами интеграции, но пока функционируют на другой платформе.
Выбрав BIA Professional, мы «проваливаемся» в основное меню системы. 
То, что мы видим на экране системы, предназначено для администратора, интерфейс для конечного пользователя, анкетируемого сотрудника, значительно проще, до него мы дойдем чуть позже. Прочитать сообщение полностью »
В начале октября компания VMware выпустила новую версию своего продукта для обеспечения послеаварийного восстановления – Site Recovery Manager 4.0.
В честь этого события я решил сделать небольшой обзор 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.
Управление работоспособностью HA/DR решений
18.10.2009
В Storage News №3 (40) за 2009 год вышла моя статья про управление непрерывностью ИТ-сервисов. Точнее говоря, про проблемы, возникающие при эксплуатации HA/DR решений в изменяющейся среде, и про то, как с ними (проблемами) бороться.
Road Show Continuity Software
16.10.2009
С 21 по 27 октября мы совместно с Continuity Software проводим Road Show, представляя потенциальным потребителям продукт RecoverGuard™, которому уже было посвящено несколько предыдущих постов. Первые три дня (21-23 октября) мы с Гилом (Gil Hecht, CEO Continuity Software) проведем в Алматы, после чего вернемся в Москву, где и продолжим общение с российскими компаниями до 27 октября.
Если у вас есть желание встретиться с нами в эти дни – пишите, постараемся найти время в нашем графике.
Infosecurity Russia 2009 – день первый
29.09.2009
Итак, первый день завершился 
Прошел круглый стол по вопросам непрерывности бизнеса. Что порадовало – зал был практически полон, что говорит об интересе аудитории к данной тематике.
Моя презентация по вопросам тестирования системы обеспечения непрерывности бизнеса – здесь.
После этого на презентационной площадке прочитал презентацию про RecoverGuard, о котором уже писал раньше. Презентационная площадка оказалась расположенной в крайне неудобном месте, найти которое оказалось не очень просто 
Тем не менее, презентация состоялась, а те кто, не нашел площадку, или не был сегодня на InfoSecurity, могут посмотреть ее здесь.
В августовском номере Аналитического банковского журнала вышла наша с Павлом Лепешкиным (Банк России, зав. сектором Департамента банковского регулирования и надзора) статья, посвященная Положению Банка России №242-П под названием Обеспечение непрерывности деятельности – Мифы и реальность.
Работая над статьей, мы старались максимально избежать пересказа текста Положеня 242-П, сфокусировавшись на практических рекомендациях по построению системы ОНиВД.
Кроме того, людям, имеющим опыт в управлении непрерывностью бизнеса (или ОНиВД в терминах 242-П), но не знакомых близко с Базельскими документами, возможно будет интересно обратить внимание на достаточно подробно изложенную Павлом трактовку понятий операционного риска.
Infosecurity Moscow 2009
04.09.2009
Меньше месяца осталось до самого крупного мероприятия в области информационной безопасности – InfoSecurity. По складывающейся традиции, не осталась в стороне и тема непрерывности бизнеса.
В первый день (29 сентября), предваряя процедуру официального открытия выставки, с 12:15 до 13:45 пройдет секция «Построение и сохранение непрерывности бизнеса в существующих условиях. Информационная безопасность, как один из элементов непрерывности?» под чутким руководством Димы Кострова из МТС. Как водится, точный состав выступающих и темы выступлений будут еще утрясаться, за себя могу сказать, что говорить буду про тестирование – как лучше проводить тестирование/учения так, чтобы потом не было мучительно больно .
Кроме того, в тот же день сразу после официального открытия, в 14:30 на презентационной площадке расскажем про решение RecoverGuard от Continuity Software, о котором я писал в предыдущем посте.
Будет еще выступление про безопасность в виртуальных средах (на Круглом столе у Емельянникова, в 15:30 30 сентября) , и битва во имя решения Reflex VMC на Львах и Гладиаторах (1 октября в 12:15), но это уже отдельная тема, к данному блогу не относящаяся.
Так что всем добро пожаловать
Задача тестирования HA/DR решений всегда являлась для ИТ-персонала определенной головной болью.
Все сознают, что тестировать надо (не встречал еще ни одного человека, который сказал бы, что тестирование – это зло). Но, когда дело доходит до конкретных действий, креативу на тему «почему мы не можем делать это сейчас» зачастую можно только позавидовать. Среди аргументов присутствует как абсолютно разумное опасение «положить» рабочую систему, так и заявления в духе «все и так будет работать».
Как показывает опыт – само по себе с первого раза практически никогда не заработает, а вот рабочую систему положить можно запросто Особенно если взять, и сразу попробовать протестировать комплексное восстановление.
К чему я все это рассказываю? Несколько месяцев назад нам на глаза попалась компания Continuity Software, и на днях мы подписали с ними партнерское соглашение. Продукт у них всего один – RecoverGuard, зато интересный. Задача, которую помогает решить RecoverGuard - убедиться в том, что ваши HA/DR решения работают. Простая, но нужная. Безусловно, использование RecoverGuard – не замена «боевому» тестированию – но возможность существенно снизить риски сбоев в момент тестирования, а также поддерживать систему в работоспособном состоянии в промежутке между тестированиями.
Давайте посмотрим, что стоит за этими словами.
1. Некорректные конфигурации. RecoverGuard содержит постоянно обновляемую (как инженерами Continuity Software, так и пользователями системы) базу знаний о существующих уязвимостях в архитектуре HA/DR решений от различных производителей. Соответственно, наличие (а точнее, отсутствие) подобных уязвимостей RecoverGuard проверяет в первую очередь. Примерно аналогично проверяется соответствие лучшим практикам, рекомендованным производителями.
2. Расхождение конфигураций. Очень распространенная проблема, когда при внесении изменений (от применения обновлений до апгрейда железа) в продуктивную систему, в резервную систему изменения не вносятся, или вносятся, но не такие. Такого рода расхождения (т.н. configuration drift) RecoverGuard также достаточно легко обнаруживает.
Это две основные функции, которые позволяют предотвратить массу серьезных проблем.
Кроме того, в продукте реализована еще масса приятных возможностей:
- Оценка выполнимости SLA на основе анализа конфигурации решений
- Документирование инфраструктуры
- Механизм alert’ов
- И т.п.
Для того, чтобы убедиться в полезности продукта, Continuity Software (а в России и СНГ – вместе с Алмитек) предлагает сделать короткий пилот. Устанавливается система, выдаются права на доступ к элементам инфраструктуры (агентов ставить никуда не надо, достаточно только прав на чтение), в течение суток проводится анализ, на основании чего делается отчет. Пилот платный, но и результат полезный в любом случае – текущий срез уязвимостей заказчик получает вне зависимости от того, будет ли решение использоваться в дальнейшем. По утверждению производителя – проблемы обнаруживаются всегда.
Непрерывность бизнеса для российских ВУЗов
31.07.2009
На этой неделе Алмитек анонсировал программу содействия ВУЗам, в программе которых есть курсы по непрерывности бизнеса.
Заинтересовавшиеся ВУЗы получают возможность развернуть у себя основной набор продуктов SunGard – Business Impact Professional и LDRPS 10, и обучать студентов создавать систему управления непрерывностью бизнеса с использованием лучших практик и эффективного инструментария.
Основной вопрос, ответ на который, я думаю, будет ясен ближе к сентябрю – как много в России и СНГ ВУЗов, которые в принципе планируют включать в учебный план такую дисциплину, как непрерывность бизнеса. В любом случае, тема становится все более востребованной, и двигаться в этом направлении надо.
ЦБ по прежнему лидирует
27.07.2009
Банк России, который в этом году заметно вырвался вперед по отношению к остальным регуляторам, продолжает поддерживать статус лидера. На этот раз – в части информационной поддержки сообщества.
В 15 выпуске издания «Платежные и расчетные системы» ЦБ опубликовал переводы сразу двух документов в области непрерывности бизнеса в финансовой сфере: «Руководящие принципы обеспечения непрерывности бизнеса» Базельского банковского комитета (Банк по международным расчетам), и «Рекомендации по наблюдению за непрерывностью деятельности для системно значимых платежных систем» Европейского Центробанка.
Первый документ, как известно, послужил основой при выпуске изменений к Инструкции 242-П, поэтому на нем я остановлюсь поподробнее. Второй тоже достаточно любопытно прочитать, среди прочих моментов он дает чуть более широкий взгляд на целевые показатели обеспечения непрерывности деятельности, ставя для ряда участников рынка по главу угла влияние от прерывания деятельности не на их собственный бизнес, а на платежную систему на уровне страны (точнее говоря, Еврозоны). Несмотря на то, что документ ориентирован на финансовые организации стран Еврозоны, прочитать стоит, тем более, что документ небольшой. Единственное, рекомендую читать в оригинале, т.к. перевод этого документа, в отличие от «Руководящих принципов…», сильно оставляет желать лучшего.
Теперь вернемся к «Руководящим принципам…»
Поскольку этот документ во многом лег в основу измений к 242-П, достаточно интересно посмотреть, что из семи принципов вошло в 242-П, и в каком виде. Итак, по порядку.
Принцип 1. Ответственность совета директоров и высшего руководства.
«Советы директоров и высшее руководство организаций несут коллективную ответственность за непрерывность бизнеса организации.»
Принцип безусловно разумный, и, среди прочего, пересекается с рекомендациями BS 25999. Однако, в 242-П по каким-то причинам эти рекомендации не вошли. Тем не менее, основываясь на своем опыте, я бы рекомендовал максимально стараться воплотить его в жизнь – система будет работать горадо эффективнее.
Принцип 2. Крупные операционные нарушения.
«Участники финансового сектора и финансовые органы при формировании подхода к управлению непрерывностью бизнеса должны учитывать риск крупного операционного нарушения. Финансовым органам также следует оценить их собственную реакцию на потенциальные крупные операционные нарушения, которые могут затруднить проведение операций участниками финансового сектора или финансовой системой, за работу которой они несут ответственность.»
Тезис о том, что планы ОНиВД должны предусматривать возможность масштабных ЧС в 242-П вошел, и даже был дополнен ссылками на Российские нормативные документы. А вот рекомендации по поводу альтернативных площадок остались за кадром.
Принцип 3. Цели восстановления
«Участники финансового сектора должны сформулировать для себя цели восстановления, учитывающие потенциальный риск, который они представляют для операций финансовой сферы. Предпочтительно, чтобы формулировки таких целей восстановления были согласованы с соответствующими финансовыми органами или разрабатывались ими.»
Если в «Принципах…» делается упор на возможной влияние на финансовую систему в целом, то 242-П больше сфокусировано на стандартных для анализа воздействия на бизнес аспектах, т.е. влияние на бизнес кредитной органиации, как таковой.
Принцип 4. Обмен информацией.
«Участники финансового сектора и финансовые органы должны включать в свои планы обеспечения непрерывности бизнеса процедуры для обмена информацией во время крупного операционного нарушения внутри организации и с соответствующими внешними сторонами.»
Принцип нашел свое отражение в 242-П (Пункт 7 Приложения 5), хотя и в более общей форме.
Принцип 5. Трансграничный обмен информацией.
«Процедуры обмена информацией для участников финансового сектора и финансовых органов на случай крупных операционных нарушений, затрагивающих несколько стран, должны предусматривать обмен информацией с финансовыми органами, действующими в пределах других юрисдикций.»
Пункт разумный, но учитывая не очень высокий уровень зрелости нашей банковской системы в области непрерывности бизнеса, а также не такой высокий уровень интеграции в мировую банковскую систему – пока не нашел своего отражения в 242-П.
Принцип 6. Проверки (тестирование).
«Участники финансового сектора и финансовые органы должны производить проверку своих планов
обеспечения непрерывности бизнеса, оценивать их эффективность и соответствующим образом совершенствовать управление непрерывностью бизнеса.»
Здесь 242-П раскрывает вопрос даже более подробно. Единственное, пожалуй, что было исключено – это крупномасштабное тестирование с вовлечением множества кредитных организаций. Наверное, не самое сейчас подходящее время – не все могут выдержать…
Принцип 7. Контроль за управлением непрерывностью бизнеса со стороны финансовых органов
«Финансовые органы должны включать в практику своей работы осуществление контроля за управлением непрерывностью бизнеса для проведения оценки участников финансового сектора, находящихся в сфере их ответственности.»
Этот пункт относится скорее к деятельности самого ЦБ, и появление изменений к 242-П можно считать первым шагом на пути выполнения этого принципа.
Обобщая все вышесказанное, можно рискнуть сделать следующие выводы:
- В некоторых аспектах «Руководящие принципы…» оказываются более подробными, чем 242-П, соответственно, и в этих вопросах ими можно и нужно пользоваться. Равно как и другими стандартами, такими как BS 25999, BS 25777.
- »Руководящие принципы…» дают некоторое представление, в какую сторону, скорее всего, будет развиваться регулирование со стороны ЦБ.
