Kitabı oku: «ИТ-архитектура от А до Я: Шаблоны документов. Первое издание», sayfa 3

Архитектура Информационных Технологий

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

План Непрерывности Бизнеса

План/Политика Непрерывности Бизнеса (Business Contingency Plan), определяет порядок реагирования на непредвиденные обстоятельства, ведущие к частичному или полному отказу ИТ сервисов, и их влияние на бизнес. Фокусирует свое внимание на сервисах, отказах и сбоях компонентов инфраструктуры. План определяет шаги, необходимые для восстановления одной или нескольких услуг, события, которые являются основанием для его инициации, людей, которые должны быть задействованы, средства коммуникаций и т. п. Деятельность включает в себя взаимодействие ИТ и бизнеса.

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

Данный документ определяет План Непрерывности Бизнеса (Business Contingency Plan BCP) в организации. Документ является стратегическим документом организации. Документ должен соответствовать следующим требованиям:

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

•Нормативной документацией Контролирующего органа;

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

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

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

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

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

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

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

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

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

•Уровень срочности (urgency) – степень, определяющая срочность разрешения инцидента. Является составляющей, определяющей приоритет инцидента.

•Приоритет (priority) – определяет важность инцидента и порядок его разрешения.

•Обходное решение (work around) – действия, позволяющие временно или постоянно устранить инцидент или его причины.

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

•Анализ Бизнес Процессов (Business Environment Analysis, BEA) – анализ функционирования бизнес процессов и их связь с ИТ;

•Анализ Рисков (Risk Analysis, RA) – экспертная оценка возможных угроз, классификация рисков, вероятность их возникновения, уровень воздействия и механизмы реагирования;

•Оценка Воздействия на Бизнес (Business Impact Analysis, BIA) – анализ Информационной Системы или сервиса на предмет воздействия на бизнес процессы организации;

•Анализ Отказа Сервиса (Service Failure Analysis SFA) – Анализ Информационной Системы или услуги на предмет взаимосвязи с другими системами. Включает в себя анализ воздействия на сервис отказ других систем и воздействие на другие сервисы отказ данного;

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

•Уровень состояния сервиса (Service Delivery Objective SDO) – показатель состояния сервиса на текущий момент. Для каждого сервиса имеется собственный набор атрибутов. В общем случае в качестве таких атрибутов выступает: Доступность, целостность и безопасность. Может характеризоваться как «Стандартный», «Приемлемый», «Неудовлетворительный», «Недоступный» и т п;

•Максимально допустимое время сбоя (Maximum Acceptable/Allowable Outage MAO) – Максимально допустимым отключением является время, в течение которого может пройти до того, как неблагоприятное воздействие станет неприемлемым

или невыносимо для предоставления бизнес услуг, продуктов или выполнение бизнес деятельности. Схожие термины: Максимально возможный простой (Maximum Allowable Downtime MAD) или (Maximum Tolerable Downtime MTD).

•Точка Восстановления (Recovery Point Objective RPO) – определяет допустимый уровень потерь;

•Время Восстановления (Recovery Time Objective RTO) – определяет допустимое время на востановление;

•Уровень Восстановления (Recovery Level Objective RLO) – определяет уровень восстановления. Как пример может быть на уровне виртуальной машины, приложения или данных.

ЦЕЛИ ДОКУМЕНТА

Внесения ясность в организацию процесса управления непрерывностью бизнеса. Цели документа:

•Формирование концепции, принципов и организации процесса управления непрерывностью бизнеса в организации;

•Гарантировать непрерывность бизнеса в установленных рамках;

•Повышение эффективности взаимодействия ИТ и бизнеса;

СФЕРА ДЕЙСТВИЯ ДОКУМЕНТА

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

АУДИТОРИЯ

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

ОРГАНИЗАЦИЯ РАБОТЫ С ДОКУМЕНТОМ

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

ЦЕЛИ ПРОЦЕССА УПРАВЛЕНИЯ НЕПРЕРЫВНОСТЬЮ БИЗНЕСА

Основные цели политики управления непрерывностью бизнеса:

•Своевременное реагирование на инциденты и скорейшее восстановление работы бизнеса;

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

•Разработка необходимых процедур, стандартов и метрик;

•Обеспечение прозрачности функционирования ИТ для бизнеса;

•Снижение негативного влияния сбоев на бизнес;

•Рациональное использование ИТ ресурсов;

•Повышения удовлетворенности бизнеса работой ИТ;

•Снижение убытков, связанных со сбоями ИТ;

•Сокращение времени простоя бизнеса;

•Сокращение времени работ по восстановлению бизнеса;

ЗАДАЧИ ПРОЦЕССА УПРАВЛЕНИЯ НЕПРЕРЫВНОСТЬЮ БИЗНЕСА

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

•Организация процесса управления непрерывностью бизнеса;

•Классификация сбоев;

•Классификация воздействия, срочности и приоритета;

•Классификация метрик и показателей работы процесса;

•Определение ролей и уровня вовлеченности сотрудников;

•Организации деятельности по своевременному обнаружению;

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

•Формирование Плана Непрерывности Бизнеса;

•Формирование сценариев сбоев;

•Организации деятельности по устранению сбоев;

•Организация деятельности по восстановлению бизнеса;

•Организации деятельности по расследованию причин сбоя;

•Организации деятельности по коммуникации;

•Организации деятельности по регистрации сбоев;

•Организации взаимодействия с другими ИТ процессами;

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

•Организация сценариев тестирования;

ПРОЦЕСС УПРАВЛЕНИЯ НЕПРЕРЫВНОСТЬЮ БИЗНЕСА

Основные принципы можно охарактеризовать как:

•Для каждого ИТ сервиса на этапе проектирования должен быть определен механизм непрерывности сервиса;

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

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

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

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

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

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

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

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

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

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

•Устранение

•Закрытие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•Отчеты;

•Сообщения;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•Анализ Бизнес Процессов (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);

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

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

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

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

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

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

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

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

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

УСТРАНЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЗАКРЫТИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

План Восстановления после сбоя

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•Уровень срочности (urgency) – степень, определяющая срочность разрешения инцидента. Является составляющей, определяющей приоритет инцидента.

•Приоритет (priority) – определяет важность инцидента и порядок его разрешения.

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

ЦЕЛИ ДОКУМЕНТА

Внесения ясность в организацию процесса управления непрерывностью бизнеса и ИТ сервисов при воздействии внешних факторов. Цели документа:

•Формирование концепции, принципов и организации процесса реагирования на сбой и аварии для обеспечения непрерывности бизнеса в организации;

•Повышение эффективности взаимодействия ИТ и бизнеса;

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

СФЕРА ДЕЙСТВИЯ ДОКУМЕНТА

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

АУДИТОРИЯ

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

ОРГАНИЗАЦИЯ РАБОТЫ С ДОКУМЕНТОМ

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

ЦЕЛИ ПРОЦЕССА

Основные цели можно определить, как:

•Своевременное реагирование;

•Скорейшее восстановление;

•Формирование процесса реагирования на катастрофы;

•Определение процедур, стандартов и метрик;

•Обеспечение прозрачности функционирования ИТ;

•Снижение негативного влияния сбоев на бизнес;

•Рациональное использование ИТ ресурсов

•Повышения удовлетворенности бизнеса и сотрудников;

•Снижение убытков, связанных со сбоями;

•Сокращение времени простоя бизнеса;

•Сокращение времени восстановления бизнеса;

ЗАДАЧИ ПРОЦЕССА

Можно определить следующие задачи :

•Организация процесса;

•Классификация воздействий и сбоев;

•Определение метрик и показателей;

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

•Организации деятельности по своевременному обнаружению;

•Формирование Плана Восстановления после сбоя;

•Формирование сценариев чрезвычайных ситуаций;

•Организации деятельности по устранению сбоев;

•Организации деятельности по устранению последствий;

•Организация деятельности по восстановлению бизнеса;

•Организации деятельности по расследованию причин сбоя;

•Организации деятельности по коммуникации;

•Организации деятельности по реагированию;

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

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

•Организация сценариев тестирования;

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

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

Атрибуты и метрики сценариев

Основные принципы можно охарактеризовать как:

•Для каждого ИТ сервиса на этапе проектирования должен быть определен механизм непрерывности сервиса;

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

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

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

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

•Должно проводиться тестирование плана;

СЦЕНАРИЙ №1 «Воздействие стихийных бедствий»

•Описание Риска: Потеря здания головного офиса;

•Вероятность события: Низкая;

•Вероятный причины: Пожар, землетрясение, наводнение и т п;

•Влияние: Очень высокое;

•Затронутые функции: Вся деятельность бизнеса;

•Оценка рисков: Высокая;

•Место сбора: Сотрудники головной офис собираются в филиале «Филиал №1»;

•Смягчение последствий: Предопределенные и испытанные политики, процедуры и план действий на местах;

•Команда восстановления: Комитет по реагированию на Чрезвычайные Ситуации (Кризисный Комитет), Группы реагирования от каждой бизнес функции, ИТ, Безопасности;

Цели команд восстановления:

•Этап восстановления №1 т.е. восстановить минимальный уровень обслуживания в течении 24 часов;

•Этап восстановления №2 – восстановление полного уровня обслуживание всех бизнес функций в течении 72 часов;

Функции и обязанности групп восстановления:

•Кризисный Комитет – Принятие решения по переходу на резервный план, выполнение плана восстановления, и принятие решений по дальнейшему управлению, в полоть до полного восстановления;

Группы реагирования от каждой бизнес функции – выполнение работ по переходу на резервный план и восстановлению операций.

План действий: <детальное описание>

Заключение и рекомендации: <детальное описание>

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

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

•Получение подтверждений работоспособности планов;

•Проверка достаточности методического и технического обеспечения;

•Получение необходимых навыков и знаний;

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

•Настольная проверка (Tabletop);

•Имитация (Imitation);

•Полное тестирование (Full business continuity testing);

После проведения тестирования составляются отчеты, в которых указываются сценарии и результаты тестирования, а также предложения по улучшению планов непрерывности деятельности.

Обслуживание и обновление планов

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

•Изменение ИТ инфраструктуры;

•Изменение организационной структуры компании;

•Изменения в законодательстве;

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

Чтобы сохранить актуальность планов, необходимо выполнять следующие действия:

•Проводить внутренние аудиты, включающие проверку восстановления после аварий, документации по обеспечению непрерывности и соответствующих процедур;

•Проводить регулярные теоретические и практические тренинги для сотрудников организации, по выполнению плана;

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

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

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

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

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

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

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

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

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

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

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

•Отсутствие прозрачности функционирования ИТ и бизнеса;

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

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

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

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

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

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

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

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

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

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

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

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

Ключевые факторы успеха:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•Политика и план «Управления Непрерывностью Бизнеса»;

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

•Рекомендации стандарта ISO 20000 «IT Service Management»;

•Рекомендации стандартов ISO 27000 «Information Security»;

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

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