•Для каждого бизнес процесса по возможности должны быть разработаны «резервный» и «аварийный» планы;

•Процедуры восстановления должны быть прописаны в архитектуре сервиса;

•Метрики должны быть прописаны в архитектуре сервиса;

•Ответственные ИТ сотрудники обязаны незамедлительно реагировать для обеспечения непрерывности сервисов;

•Выборочно, не реже одного раза в год, должно проводиться тестирование плана непрерывности;

Процесс управления непрерывностью бизнеса может включать в себя следующие под-процессы:

•Обнаружение и регистрация

•Классификация и первоначальный анализ

•Расследование и диагностика

•Устранение

•Закрытие

Для построения эффективного процесса управления непрерывностью бизнеса необходимо наличие следующих входных данных:

•Наличие каталога предоставляемых ИТ сервисов;

•Детальная архитектура ИТ сервисов;

•Процедуры по сопровождению ИТ Сервисов;

•Каналы поступления информации;

•Соглашения по уровню предоставлению услуг и метрики;

•Определены группы поддержки;

•Определены каналы обратной связи и коммуникации;

•Наличие компонентной базы ИТ инфраструктуры;

При функционировании процесса управления непрерывностью бизнеса формируются следующие выходных данные:

•Запросы на обслуживание;

•Запросы на изменения;

•Регистрация проблем;

•Записи по инцидентам;

•База знаний;

•Отчеты;

•Сообщения;

•«Резервные» и «Аварийные» планы;

•Инициализация проектов по оптимизации ИТ и бизнеса;

Необходимы следующие инструменты:

•Инструменты для диагностики;

•Инструменты по устранению;

•Инструменты для регистрации;

ИНИЦИАЛИЗАЦИЯ И РЕГИСТРАЦИЯ

Под-процесс обнаружения и регистрации является триггером для запуска процесса. В качестве источников поступления информации о сбое могут выступать:

•Процесс управления событиями;

•Процесс управления инцидентами;

•Автоматизированные средства мониторинга инфраструктуры;

•Информация от сотрудников организации;

•Информация от поставщиков услуг;

•Информация от партнеров;

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

•Анализ Бизнес Процессов (Business Environment Analysis, BEA);

•Анализ Рисков (Risk Analysis, RA);

•Оценка Воздействия на Бизнес (Business Impact Analysis, BIA);

•Анализ Отказа Сервиса (Service Failure Analysis SFA);

•Анализ Отказа Компонентов (Component Failure Impact Analysis CFIA);

•Оценка влияния на целевую систему;

•Уровень состояния сервиса (SDO);

•Максимально допустимое время сбоя (MAO, MAD или MTD);

•Точка Восстановления (RPO);

•Время Восстановления (RTO);

•Уровень Восстановления (RLO);

•Последовательность действий по восстановлению;

РАССЛЕДОВАНИЕ И ДИАГНОСТИКА

Расследование и диагностика может включать в себя расследование причин сбоя и определение наиболее оптимальных вариантов восстановления.

ОПРЕДИЛЕНИЕ ДЕЙСТВИЙ И МЕХАНИЗМОВ

Механизмы и план действий может быть следующий:

•Если не происходит деградация качества, восстановление выполняется в штатном режиме;

•Если деградация качества в пределах норм, восстановление выполняется в штатном режиме;

•Если деградация качества ниже норм, необходимо проинформировать владельца сервиса. Восстановление сервиса начать в как можно быстрее;

•в случае полного отказа, необходимо проинформировать владельцев текущего и зависимых сервисов. Восстановление начать немедленно. На время восстановления, перейти на «резервный» или «аварийный» план работы бизнеса;

УСТРАНЕНИЕ

В качестве механизмов устранения неисправностей, можно использовать следующие:

•Перезапуск службы или сервиса;

•Перезагрузка сервера;