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

•Постановка задач перед ИТ департаментом;

•Управление ИТ департаментом;

•Контроль исполнения поставленных целей и задач;

•Предоставление отчетов;

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

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

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

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

•Надежная и безотказная работа всех составляющих ИТ;

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

•Отсутствие претензий со стороны контролирующих органов по вопросам, относящимся к компетенции департамента ИТ;

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

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

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

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

План/Политика Непрерывности Бизнеса (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) – определяет уровень восстановления. Как пример может быть на уровне виртуальной машины, приложения или данных.

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

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

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