Комплекс мер по обеспечению непрерывности функционирования и доступности ИСПодход к разработке

Содержание
Требования бизнеса к ИТ-сервисам
Как связать бизнес и ИТ?
Описание состава и последовательности выполнения работ
Анализ воздействия простоев на бизнес (BIA)
Анализ технологических рисков
Обзор организационных и технических мер защиты

ИТ в контексте интересов бизнеса
Оптимизация расходов на инженерную инфраструктуру ЦОД, ИТ-инфраструктуру (серверы, системы хранения, сети) а также эксплуатацию ИТ, что предусматривает повышение эффективности данных компонентов
Снижение рисков через повышение доступности ИТ сервисов, соблюдение SLA, а также упрощение инфраструктуры для минимизации влияния человеческого фактора
Адаптация к изменениям через возможность масштабирования ИТ для запуска новых направлений деятельности организации, обеспечения роста бизнеса и повышения гибкости ИТ при реагировании на меняющиеся запросы

Связываем бизнес и ИТ
При разработке и/или трансформации ИС и ИТ-инфраструктуры необходимо
учитывать планы по развитию бизнеса, а также требования и характеристики
ключевых поддерживаемых ими бизнес-процессов с тем, чтобы:
Не допустить неоправданно высоких затрат на отказоустойчивые решения,
которые, может быть, и не нужны;
Реализовать решения, направленные на снижение действительно существенных
рисков в отношении непрерывности существующих или проектируемых
бизнес-процессов.

Состав и последовательность выполнения работ

Анализ влияния простев на бизнес
(Business Impact Analysis – BIA)
Цель
Выявить прямое и косвенное влияние на бизнес в результате утраты критически важных бизнес-процессов и функций
Разработать согласованные с бизнес-требованиями цели по восстановлению работоспособности бизнес-процессов и ИТ-сервисов после сбоя.
Результат
Разработка категорий восстановления, отнесение бизнес-процессов к соответствующим категориям;
Определение и документирование RTO и RPO для каждой бизнес-функции/процесса;
Выяснение взаимосвязей между наиболее критичными бизнес-функциями;
Установление соответствий между бизнес-процессами, ИТ-сервисами, ИС и элементами ИТ инфраструктуры.

Терминология
Ключевой бизнес-процесс (бизнес-функция)
Процесс, жизненно необходимый для функционирования компании. Простой ключевого бизнес процесса ведет к недопустимым для компании последствиям (причем негативный эффект может быть отложенным).
Допустимый диапазон потери данных
Recovery Point Objective, RPO
Отрезок времени, предшествующий срыву бизнес-процесса, за который допускается невосполнимая потеря введенных данных, результатов работы и пр. Данный параметр является одним из важнейших результатов формализованного анализа влияния простоев ИТ систем на бизнес-процессы.
Целевое время восстановления
Recovery Time Objective, RTO
Время, за которое должно быть восстановлено функционирование ключевого процесса и/или процесса, от которого он зависит. Причиной сбоя в данном контексте может являться кризисная ситуация, чрезвычайное происшествие или инцидент.

Анализ ключевых бизнес-процессов
Проводится анализ влияния простоев бизнес-процессов на Организацию, на базе чего в дальнейшем формулируются требования к времени восстановления (RTO) ИС, поддерживающих эти бизнес-процессы.

Зависимость бизнес-процессов от ИТ-сервисов (1/2)
Клиенты
RTO ИТх = min ( RTO ИТх ? Б1 ; RTO ИТх ? Б2 ;… RTO ИТх ? Бy )

Зависимость бизнес-процессов от ИТ-сервисов (2/2)
Определяется роль информационных систем и сервисов в функционировании бизнес-процессов.
Какие бизнес-функции зависят от данного информационного сервиса?
Как скоро после сбоя информационного сервиса бизнес ощутит негативное влияние?
Есть ли обходные пути, позволяющие работать при недоступном информационном сервисе?
Как нагнать отставание?
Каковы затраты на преодоление отставания?
Можно ли вообще компенсировать потерянное время?

Классификация ИС по степени критичности

Приоритеты восстановления ИС
Длительность восстановления – менее 4 часов.
Процесс жизненно и стратегически важен для работы компании.
Существенное нарушение ключевых бизнес-процессов.
Заметное негативное влияние сбоя проявляется немедленно и продолжает сказываться даже после быстрого устранения сбоя.
Серьезные ограничения и правовая ответственность.
Длительность восстановления – от 4 часов до 8 часов.
Процесс необходим для ежедневной работы компании.
Сбой одновременно затрагивает как внешних клиентов, так и несколько департаментов компании.
Заметное негативное влияние сбоя проявляется немедленно.
Длительность восстановления – от 8 до 24 часов.
Процесс необходим для поддержания внутренней оперативной деятельности.
Долговременный сбой окажет заметный негативный эффект.
Класс 1
Mission Critical
Приоритет: неотложный
Класс 3
Business Oper.
Приоритет:
важный
Класс 2
Business Critical
Приоритет:
критичный

Требования к архитектуре ИС (1/2)
Для каждого класса критичности разрабатывается набор требований, в совокупности определяющих целевое состояние, позволяющее уложиться в значения RTO/RPO:
Методы защиты приложения
Методы защиты данных в оперативном доступе
Методы резервного копирования данных
Дублирование персонала
Процессы эксплуатации
Мониторинг
Инфраструктура ЦОД
Уровень внешней технической поддержки

Требования к архитектуре ИС (2/2)

Анализ текущей архитектуры ИС, процессов и практик управления ИТ

Обзор организационно-технических мер (1/3)
Методы защиты приложения
Кластеризация аппаратных платформ, территориальное разнесение компонентов между основным и резервным ЦОД
VmWare Cluster, Hyper-V Cluster, Windows Server Failover Clustering и т.д.
HP Metrocluster, HP Contibentalcluster
Виртуализация и консолидация серверов и приложений
Холодный резерв
Модернизация и апгрейд серверов (увеличение объема ОЗУ, кол-ва процессоров, изоляция и перераспределение аппаратных ресурсов между приложениями – nPartitioning, vPartitioning, оптимизация СХД и т.д.)
Балансировка нагрузки
Реализация отказоустойчивой сетевой топологии, Teaming для сетевых интерфейсов серверов
Обнаружение уязвимостей в исходном коде и web приложениях и защита от сетевых атак
HP Fortify
HP Webinspect
HP Tippingpoint
Методы защиты данных в оперативном доступе
Локальный RAID массив
Репликация данных
High-end СХД
SAN

Обзор организационно-технических мер (2/3)
Методы резервного копирования данных
Разработка и реализация архитектуры резервного копирования: централизованное решение vs локальное решение
HP Dataprotector
Резервное копирование средствами Ignite/UX
Разработка регламента резервного копирования
Организация хранения резервных копий за пределами основной площадки
Регулярное тестирование целостности резервных копий
Дублирование персонала
Дежурная смена 24x7
Дублирование специалистов
Процессы эксплуатации
Разработка планов аварийного восстановления
Проведение учений
Окна регламентного обслуживания оборудования
Внедрение процессов управления изменениями и конфигурациями
Мониторинг сбоев

Обзор организационно-технических мер (3/3)
Мониторинг
Построение централизованной системы мониторинга состояния приложений и инцидентов
HP Operations Manager
HP System Insight Manager
HP ArcSight
Инфраструктура ЦОД
Создание резервного ЦОД, способного выдержать полную или частичную нагрузку в случае выхода из строя основного
Создание резервного запаса комплектующих на складе
Термическое моделирование ЦОД, оптимизация циркуляции воздушных масс в серверном помещении и расположения телекоммуникационных шкафов для недопущения возникновения зон перегрева
Уровень внешней технической поддержки
Mission Critical Partnership и Critical Service, 6 часов Call-to-Repair Hardware Support + proactive maintenance
Critical Service и Proactive 24 + proactive maintenance
Proactive 24 и NBD, fix-hours Call-to-Repair Hardware Support

Организационная структура проекта (сервиса)
Руководитель проекта
Архитектор решения
ITSM консультанты
Технические консультанты Server Infra/Virtualization
Технические консультанты SAN/Storage/Backup
Технические консультанты по Сетям и каналам передачи данных, ВКС, Телефония
Технические консультанты Security
Технические консультанты Client Infrastructure (рабочие станции пользователей)
Технические консультанты Print Infrastructure
Технические консультанты по Инженерной инфраструктуре
Работы могут выполняться как в рамках
самостоятельного проекта, так и в рамках
сервисного контракта