Вадим Алджанов - ИТ-архитектура от А до Я: Шаблоны документов. Первое издание

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

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

•Восстановление из резервной копии;

•Переустановка;

•Замена компонентов;

•Восстановление или переустановка может происходить:

•На уровне данных или конфигурации;

•На уровне приложения;

•На уровне операционной системы;

•На уровне виртуальной машины;

После устранения неисправностей необходимо:

•Проверить работоспособность сервиса;

•Проинформировать владельца сервиса;

•Перейти на «штатный» режим работы;

•Обновить информацию;

ЗАКРЫТИЕ

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

МЕТРИКИ ПРОЦЕССА

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

•Количество сбоев;

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

•Время восстановления в рамках регламента;

РОЛИ И ОТВЕТСТВЕННОСТИ

В соответствии с организационной структурой организации и ИТ департамента в частности, определены следующие роли:

•Владелец сервиса. Принятие решений (А);

•Менеджер сервиса. Восстановление сервиса в рамках принятого соглашения. Взаимодействие с владельцем сервиса (R);

ВЛИЯНИЕ ПРИ ОТСУТСТВИИ ПРОЦЕССА

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

•Хаотичный порядок реагирования ИТ при сбоях;

•Хаотичный порядок реагирования сотрудников при сбоях;

•Отсутствие прозрачности по функционированию сервисов;

•Не эффективное использование ИТ ресурсов;

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

РИСКИ ПРИ ВНЕДРЕНИИ И СОПРОВОЖДЕНИИ ПРОЦЕССА

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

•Отсутствие поддержки со стороны руководства организации;

•Недостаточный уровень готовности организации и сотрудников;

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

•Недостатки и ограничения бизнес процессов;

•Нехватка знаний и навыков у специалистов ИТ департамента;

•Недостатки и ограничения информационных системы;

•Недостатки и ограничения сопутствующей ИТ инфраструктуры;

КЛЮЧЕВЫЕ ФАКТОРЫ УСПЕХА ВНЕДРЕНИЯ ПРОЦЕССА

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

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

•Реалистичные цели;

•Оптимальные бизнес процессы;

•Наличие измеряемых метрик и показателей;

•Высокий уровень квалификации сотрудников ИТ;

•Приемлемый уровень осведомленности сотрудников;

ПОКАЗАТЕЛИ ЭФФЕКТИВНОСТИ И КРИТЕРИИ ОЦЕНКИ

Критериями оценки деятельности являются:

•Снижение времени недоступности ИТ для бизнеса;

•Снижение времени восстановления ИТ сервиса;

•Отсутствие претензий со стороны сотрудников;

•Отсутствие претензий со стороны контролирующих органов;

•Удовлетворенность руководства организации;

СВЯЗАННЫЕ ДОКУМЕНТЫ

Действия данного документа дополняется или является основополагающим для следующих ИТ документов:

•Политика, Стандарты и Процедура «Управления Инцидентами»;

•Политика, Стандарты и Процедура «Управления Проблемами»;

•Политика, Стандарты и Процедура «Управления Изменениями»;

•Политика, Стандарты и Процедура «Резервного Копирования»;

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

•Рекомендации стандарта ISO 22301 «Business Continuity»;

Контроль документа:[•Номер документа: •Наименование документа: •Статус документа: •Маркер безопасности: •Дата утверждения: •Дата вступления в силу: •Протокол ИТ комитета: •Заменяет документ: •Документ разработан: •Дата разработки: •Документ одобрен: •Дата одобрения: •Утвержден: •Дата утверждения: ]

Контроль версии документа:[•Версия документа: •Дата внесения изменений: •Автор: • Содержание изменений: ]

Плана Восстановления после Сбоя (Disaster Recovery Plan). Представляет из себя план восстановления инфраструктуры компании после возникновения аварии, частичной или полной потери ИТ сервиса или его компонентов. Фокусирует свое внимание на воздействиях и их влияние на комплексную ИТ инфраструктуру и бизнес процессы организации. План определяет порядок, сценарии и правила реагирования при возникновении чрезвычайных ситуаций, таких как пожар, наводнение, землетрясение и т п. Как правило, содержит наиболее возможные сценарии чрезвычайных ситуаций и реакцию на них. План должен состоять как минимум из четырех компонентов:

•Сценарии – перечень предполагаемых чрезвычайных ситуаций.

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

•Управление инцидентами – определяет методы, необходимые для смягчения или уменьшения размера происшествия.

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

ОБЩИЕ ПОЛОЖЕНИЯ

Данный документ определяет План Восстановления после Сбоев (Disaster Recovery Plan DRP) в организации. Документ является высокоуровневым, стратегическим руководящим документом. Документ должен соответствовать следующим требованиям:

•Действующему законодательству и иными правовыми актам;

•Требованиям контролирующих органов;

•Уставу организации;

•Уставу ИТ департамента;

•Внутренним регламентирующими документами;

•Рекомендациям практик и стандартов принятых в отрасли;

•Рекомендациям практик и стандартов принятых в ИТ сфере;

ПРИНЯТЫЕ СОКРАЩЕНИЯ И ОПРЕДЕЛЕНИЯ

•Владелец сервиса (service owner) – роль или структурное подразделение организации, который занимается постановкой целей, принимает решения и управляет финансированием по сервису.

•Менеджер сервиса (service manager) – роль или структурное подразделение организации, который занимается выполнением целей и задач, поставленных владельцем сервиса, обеспечивает развертывание и сопровождение сервиса.

•Уровень воздействия (impact) – границы воздействия инцидента на функционирование сервиса. Может определяться как степенью отказа сервиса (частичный, полный), так и уровнем охвата пользователей (один сотрудник, группа сотрудников и т п). Является составляющей, определяющей приоритет инцидента.