Вчера вечером  четвертый раз с августа текущего года лондонское метро закрылось на сутки на забастовку. Закрылось, правда, не полностью (утверждается, что 80% станций открыто, и 45% поездов вышли на маршрут), но достаточно, чтобы создать в городе качественный транспортный коллапс (красные точки на картинке обозначают закрытые станции метро). Для понимания масштаба бедствия — в городах масштаба Москвы или Лондона метро в сутки перевозит порядка 4 миллионов человек (как правило, туда и обратно 🙂  ).

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

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

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

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

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

Реклама

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

Любая информация о событиях, не вошедших в список, приветствуется, пишите комментарии или напрямую мне.

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

Более подробно почитать про эту историю можно здесь.

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

Недавно мне попалась на глаза  книга человека, посвятившего свою жизнь вопросам выживания после чрезвычайных ситуаций, James Wesley, Rawles — How to Survive the End of the World as We Know It: Tactics, Techniques, and Technologies for Uncertain Times. Книга достаточно занятна хотя бы тем, что позволяет приоткрыть окно в мир людей, которые реально тратят серьезные деньги и время, существенно меняют образ жизни для того, чтобы создать себе убежище, которое возможно поможет им выжить после «конца света». Чтобы составить себе общее впечатление о масштабе бедствия, загляните на сайт автора, Survival Blog, и вы найдете там массу интересных вещей, о которых вы, возможно, даже не задумывались.  Индустрия поставщиков ресурсов для выживания в Штатах развита изрядно — вы можете купить себе все — от зерна в бочках в наборе с ручной мукомолкой до б/у подземного бункера с запасами воды и продовольствия.  По сравнению с этим, российские 3-4 бункера в год выглядят просто детским лепетом.

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

Как водится, к концу года вендоры стараются отметиться чем-то интересным. Не остался в стороне и SunGard, выпустивший новую версию Continuity Management Solution 10.7, расширив ее возможностями, которых реально не хватало в проектах.

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

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

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

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

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

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

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

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

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

В этом году прошел ЧМ по футболу в ЮАР. Он запомнился нам тем, что туда не попала наша команда, новым для нашего лексикона словом (и звуком) «вувузела», рядом краж в отелях, задевших гостей ЧМ разного уровня. Тем не менее, серьезных проблем, результатом которых могли бы стать человеческие жертвы, разрушения, и т.п. —  не было. Благодаря чему — тщательной подготовке или удачному стечению обстоятельств? На эту тему наши южноафриканские коллеги опубликовали целый отчет, посвященный  организации непрерывности бизнеса на ЧМ по футболу 2010.

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

  1. Информация. Крайне важно наличие механизмов сбора, верификации, распространения информации с минимальными искажениями. Для последующего разбора полетов важно также качественное протоколирование происходящего.
  2. Простота. Когда горит нефтяная вышка или происходит ЧП в местах массового скопления народа, сложные решения не работают. Все процессы и инструменты должны быть настолько просты (и надежны), насколько это возможно.
  3. Подготовка. В момент ЧП люди плохо делают даже то, к чему они привыкли. То, чего они никогда не делали (не репетировали, не отрабатывали хотя бы в режиме учений) — они сделать не смогут.

Похожий подход я встретил и у коллег из ЮАР. Возможно, южноафриканский опыт покажется полезным и организаторам нашей Олимпиады-2014.

VEEAM опубликовал результаты опроса 500 крупных компаний по миру, касающегося защиты данных в виртуальных средах. Можно посмотреть на общемировые тренды, на практику использования специализированных/стандартных решений по резервному копированию и т.п. В общем, учитывая бесплатность отчета — проще пробежать своими глазами 🙂

%d такие блоггеры, как: