Конференция по программным решениям HPE 2016

Конференция по программным
решениям HPE
14 апреля 2016 г.

Стратегия HPE
Андрей Кутуков
Директор департамента программных решений HPE
в России
14 Апреля, 2016

Партнерство
Приверженность действию
Инновации

Новый стиль бизнеса на
основе ИТ

Трансформация
в гибридную
инфраструктуру
Продуктивность
Защита
цифровых активов
Решения
на основе данных
предприятия

7
Устройств на человека
используемых
ежедневно к 2020 г.
Enterprise Agile и DevOps Цифровая революция
Меняющийся мир доставки приложений
Потребность в методологии DevOps
7
30-кратное
увеличение релизов
приложений
42 %
предприятий
автоматизируют
мобильные
развертывания
46%
организаций,
использующих
agile
78%
Считают 2 месяца на
внедрение
слишком долгим
1
триллион
к 2020 г.
100
миллиардов
подключенных
устройств
в 2020 г.
89%
Считают 2 месяца на
доставку обновления
слишком долгим
37%
организаций размещают
приложения
на внешних
хостингах
50%
нового кода
будет облачным

Новый стиль ИТ
Новая реальность ИТ
ИТ как сервис
Повышение гибкости
Фокус на создании
инновационных
продуктов
Мобильность
и новая модель
потребления
Короткий
жизненный цикл
Традиционное ИТ
Фокус на
стабильность и
непрерывность
Стандартные
приложения и
потребление
Длинный
жизненный цикл
Снижение затрат
Gartner называет это
«Bimodal IT»

Продуктивность
Защита
цифровых
активов
Решения
на основе данных
предприятия
Трансформация
в гибридную
инфраструктуру
• Service broker
• Automation
• Agile and DevOps
• Hybrid infrastructure

Автоматизированные ИТ-
услуги как необходимая
составляющая современного
бизнеса
Константин Васильев
Технический консультант
Software EMEA

Какие тренды мы видим сегодня и почему это важно
Быть быстрее Быть эффективнее Быть дешевле
Время
Количество
Ускорить
предоставление
новых услуг
Сегодня
2020
Время
запросов от
бизнеса
Время отклика
Облака или
внешние
провайдеры
Собственные ИТ
Время

Три шага на пути трансформации
Автоматизируйте, «оркестрируйте», трансформируйте
13
Традиционные
ИТ
Цифровое
предприятие
Трансформируйте
предоставление
услуг
«Оркестрируйте»
процессы»
Автоматизируйте
задачи

Программа:
• Автоматизация процесса перевода транспортного сервиса между географически
распределенными площадками, Шибаев Александр, Заместитель директора
Межрегионального центра обработки информации Банка России
• Автоматизация сервисов: быстрее, надежнее и дешевле. Пример банка Societe
Generale, Франция, Васильев Константин, технический консультант, HPE в EMEA
• Тестовые среды как услуга: создание и сопровождение, Шубин Александр, архитектор
решений, компания Техносерв
• Дискуссия
Автоматизированные ИТ-услуги как необходимая
составляющая современного бизнеса

Автоматизация процесса перевода
транспортного сервиса между
географически распределенными
площадками
Александр Шибаев,
Заместитель директора Межрегионального
центра обработки информации Банка России

Транспортная система электронных расчетов
ТСЭР предназначена для
предоставления услуг гарантированной
передачи электронных сообщений
между участникам электронного
обмена
в платежной системе Банка России

Модель ТСЭР
Региональные
узлы
Узлы расчетных
систем
Центральный узел
Клиенты
Банка России
Шлюз
Расчетные системы
ШлюзШлюз
Информационно-аналитические
системы Банка России
ТСЭР

Каталог сервисов ТСЭР
Каталог сервисов ТСЭР:
• одноадресная доставка электронных сообщений (ЭС);
• рассылка ЭС по списку/многоадресная рассылка;
• логическая маршрутизация ЭС на основании адреса прикладного служебного SOAP-
конверта
• On-line контроль прохождения сообщений
• ведение оперативной базы ЭС с возможностью повторной отправки (время жизни ЭС в
оперативной базе – 48 часов);
• ведение базы данных с информацией о переданных ЭС и результатах их обработки на
узлах ТСЭР (время хранения информации об ЭС в архивной базе – в течение 3-х лет);
• криптографическая защита ЭС, передаваемых по каналам ТСЭР

Подключение клиентов
осуществляется через
отдельные АПК СВК ТУ,
функционирующих во всех
ГУ/Отделениях Банка
России
КО
КО
КЦОИ МР
КЦОИ-1
ЦОиР БЭСП
...
ТСЭР
82 СВК ТУ
КО
КО
...
.
.
. .
.
.
.
.
.
Расчетные центры
ТУз ТУ1
ТУз ТУN
СВК ТУN
СВК ТУ1
ЦОС СПФС
ЦС1
ЦС3
ЦС2
Структурная схема взаимодействия программных
комплексов через ТСЭР

ЦТУ ТСЭР – сложная структура
АРМ АДМ ЦТУ ТСЭР
(СУ ТСЭР)
Cisco MDS9124
рез. (ЛВС СХД)
Накопитель ленточный
IBM TotalStorage Tape 3100
Управляющая станция HMC
Cisco MDS9124
осн. (ЛВС СХД)
Eth1 (осн)
Eth2 (рез)
System p5
АРМ АДМ ТСЭР
(СУ ТСЭР)
FC1_1
FC1_2
FC2_1
FC2_2
p5
АРМ АДМ ЦТУ ТСЭР
(СУ ТСЭР)
упр (осн)
ЦС1_2 (AIX)
Cisco MDS9124
рез. (ЛВС СХД)
Eth1-Eth4 (осн)
объект 1
p5
Управляющая станция HMC
ЦС1_1 (AIX) Cisco MDS9124
осн. (ЛВС СХД)
МТБС МР
HBA2 (рез) – 4 шт
HBA1 (осн)– 4 штEth5-Eth8 (рез)
Cisco Catalyst
3750 осн.
(ЛВС СХД)
Eth1 (осн)
Eth2 (рез)
System p5
System p5
АРМ АДМ ТСЭР
(СУ ТСЭР)
FC1_1
FC1_2
FC2_1
FC2_2
СХ 1 (осн)
IBM TotalStorage DS3950
System p5
объект 2ЦТУ ТСЭР (ЦС1)
ГУ БР по Нижегородской области
System p5
TotalStorageDS4100
1 2 3 4 5 6 7 8 9 10 11 12 13 14
System p5
Eth1 (осн)
Eth2 (рез)
Eth1 (осн)
Eth2 (рез)
Eth2 (рез)
Eth1 (осн)
Eth2 (рез)
Eth1 (осн)
SSPC
Накопитель ленточный
IBM TotalStorage Tape 3100
КЛМ
IBM DataPower XI50
КЛМ
IBM DataPower XI50
Eth1-Eth4 (осн)
Eth5-Eth8 (рез)
Eth1-Eth2 (осн)
Eth3-Eth4 (рез)
Eth1-Eth2 (осн)
Eth3-Eth4 (рез)
КС ПТС
ЦТУ ТСЭР и ТУз
КЦОИ-1/БЭСП
HBA2 (рез) – 4 шт
HBA2 (осн) – 4 шт HBA (осн) – 2 шт
HBA (рез) – 2 шт
HBA (осн) – 2 шт
HBA1
p5
HBA2
SVC1
SVC2
Eth2 (рез)
Eth1 (осн)HBA (осн) – 2 шт
SSPC
HBA1
HBA2
p5
SVC1
SVC2
Eth1 (осн)
Eth2 (рез)
ЦС2_1 (AIX)
ЦС2_2 (AIX)
Cisco Catalyst
3750 рез.
(ЛВС СХД)
Cisco Catalyst
3750 осн.
(ЛВС СХД)
Cisco Catalyst
3750 рез.
(ЛВС СХД)
ТЕЛЕКОМ
TotalStorageDS4100
1 2 3 4 5 6 7 8 9 10 11 12 13 14
упр (осн)
Eth1 (осн)
Eth2 (рез)
СХ (рез)
IBM Storwize V7000
FC2_2
FC2_1
TotalStorageDS4100
1 2 3 4 5 6 7 8 9 10 11 12 13 14
FC1_2
FC1_1
СХ (рез)
IBM Storwize V7000
Eth2 (рез)
Eth1 (осн)
FC2_2
FC2_1
FC1_2
FC1_1
СХ 2 (осн)
IBM TotalStorage DS3950
TotalStorage DS4100
1234567891011121314
TotalStorage DS4100
1234567891011121314
ЦС3
ЦТУ ТСЭР (ЦС2)
КС ПТС

СУ ТСЭР предназначена для автоматизации процедур управления и контроля
состояния Транспортной системой электронных расчетов Банка России (ТСЭР).
Задачи СУ ТСЭР:
• Автоматизация деятельности эксплуатирующего персонала по контролю и
управлению ТСЭР;
• Обеспечение оперативного обнаружения, диагностирования и устранения
нештатных ситуаций при эксплуатации ТСЭР в целом и отдельных ее подсистем;
• Обеспечение централизованного управления ресурсами ТСЭР;
• Автоматизация контроля состояния и эффективности функционирования ТСЭР;
• Контроль процесса доставки сообщений
• Предоставление информации о работе ТСЭР внешним системам
Система управления ТСЭР (СУ ТСЭР)

Одна из задач СУ ТСЭР – автоматизация эксплуатации
• Автоматизация процесса перевода функционирования транспортного сервиса на резервную
площадку при возникновении сбоев для обеспечения непрерывности бизнес-процессов и быстрого
восстановления их работоспособности
• Формулировка из ТЗ:
• Подсистема автоматизации процедуры перевода обработки ЭС между центральными серверами ЦТУ ТСЭР должна
обеспечить автоматизацию процедуры перевода обработки ЭС между центральными серверами ЦТУ ТСЭР. При этом
должно быть обеспечено:
• Минимизация неконтролируемого участия эксплуатирующего ТСЭР персонала в процедуре перевода обработки ЭС
между центральными серверами ЦТУ ТСЭР;
• Визуализация хода выполнения данной автоматизируемой процедуры

Основные работы
Анализ и формализация существующего процесса
Выбор программной платформы для автоматизации
перевода обработки – HPE Operations Orchestration
Реализация - создана специализированная подсистема
СУ ТСЭР

Предоставлять сервис – значит контролировать время на
всех этапах
Чтобы нести ответственность
за качество предоставляемого
сервиса, необходимо его
контролировать.
ПК УОС КЦОИ
ТСЭР
ЕТКБС
SLA
SLA

Мониторинг доставки ЭС
– Входная точка обработки – СВК
– Конечная точка обработки – Транспортный узел КЦОИ
КБР
Сервер
доступа
СВК
Сервер
авторизации
ПСВА
Сегмент управления ЛВС
МСЭ
МСЭ с
сенсором
атак
ПМ СВКСеть администраторов
ТУз ТСЭР
ЛВС ДМЗ WMQ
ЦТУ ТУз КЦОИ/БЭСП
КЦОИ /
ЦОиР БЭСП/
СПФС
WMQ
Агент
ПМДЭС
ТШ
WebSphere
MQ
BizTalkEventLog
ТСЭР
Серверный
комплекс
БД
Агент
ПМДЭС
WMQ
АПКШ
«Континент»
АПКШ
WMQ Over VPN
WMQ
АПКШ
АПКШ
WMQ Over VPN
WMQ
Агент
ПМДЭС
Агент
ПМДЭС
ТСЭР
КБР
ПМДЭС
Системы
Банка
России

Контроль транзакций
Новая консоль

ЦТУ
ТУз ТУ (КЦОИ 1)
ТУз КЦОИ МР
ТУз КЦОИ 1
.
.
.
ТУз ПБР
ТУз ПБР
ТУз МЦОИ
.
.
.
ТУз ПБР
.
.
.
ТУз ПБР
ТУз ТУ (КЦОИ МР)
.
.
.
ТУз ПБР
.
.
.
ЦС3 (Н. Новгород)
Тушино Нудоль
ТУз ЦА,
ГУ ЦФО
ЦС1 (Тушино)
ЦС2 (Нудоль)
Передача электронных сообщений
При выходе из строя
центрального сервера
ЦТУ...
... второй ЦС
принимает на себя все
функции вышедшего
из строя

Подсистема автоматизации процедуры перевода обработки
ЭС между центральными серверами
ЦТУ ТСЭР (ПАПО)
ПАПО решает следующие
задачи:
– Автоматизация критичных процедур;
– Визуализация хода выполнения
автоматизируемой процедуры;
– Автоматизация отслеживания ошибок
при выполнении процедуры;
– Автоматизация диагностирования
ошибок;
– Автоматизация устранения ошибок.
Достигнутые цели:
• За счет автоматизации большого количества
рутинных операций при переводе обработки ЭС
между центральными серверами ЦТУ ТСЭР
принципиально уменьшено время перевода
обработки;
• За счет снижения влияния человеческого
фактора при большом количестве рутинных
операций резко снизились риски потери сервиса
ТСЭР для части ТУ;
• Снизились требования к квалификации
персонала – перевод проводит оператор.

Архитектура ПАПО
– Созданы операционные потоки которые
включили в себя действия
администраторов в процессе перевода
обработки ЭС между ЦС ТСЭР с учетом
возможных вариантов
– Оператор в едином интерфейсе может
выполнить перевод в режиме достаточно
простого интерактивного интерфейса

Консоль администратора ПАПО
Остановка RDF на CTU01
Подготовка RDF На ЦС2
Настройка RDF на ЦС2
Запуск RDF на ЦС2
Стоп менеджера
CTU01 на ЦС1
Настройка RDF
Старт менеджера
CTU01 на ЦС2
Переключение и сброс
счетчиков каналов в
ТУ и КЦОИ-22
Сброс счетчиков и
старт каналов менеджера
CTU01 на ЦС2
Stopmq1_1.ttl
Rdf.html
stoprdf1.ttl
newrdf1_2.ttl
newrdf2_2.ttl
startrdf2.ttl
prestart1r.ttl
MZ.TO.CTU02
!switch.bat
CTU01
reset.bat ' +
m_CTU01R
CTU01start.bat '
+ m_CTU01R
RDF Скрипты
Диаграмма перехода CTU01 на ЦС2

Описание шагов процедуры перевода обработки
1. Определение текущего состояния
HP OO опрашивает серверы и сетевые устройства (по протоколам telnet, ssh), функционирующие на каждой из географически распределенных площадок и
выводит полученную информацию дежурному инженеру в диалоговом окне. На основании данной информации дежурный инженер принимает решение о том,
на какую площадку необходимо осуществить перевод функционирования сервиса в случае сбоя.
2. Остановка обработчиков на устройстве IBM DataPower
Процесс HP OO останавливает обработчики на устройстве IBM DataPower, размещенном на площадке, с которой осуществляется перевод. В случае
недоступности устройства – дежурному инженеру предоставляется возможность повторить или пропустить этот шаг процесса.
Перевод ресурсных групп кластера на резервную площадку:
3. Остановка ресурсных групп кластера
Останавливаются ресурсные группы кластера на площадке, с которой осуществляется перевод. *)
4. Перенаправление репликации
Выполняется перенаправление репликации между дисковыми массивами, размещенными на площадках. *)
5. Запуск ресурсных групп кластера
Ресурсные группы кластера запускаются на резервной площадке. *)
6. Запуск обработчиков на устройстве IBM DataPower
Процесс HP OO запускает обработчики на устройстве IBM DataPower, размещенном на резервной площадке, на которую осуществляется перевод. *)
7. Переключение каналов WebSphere MQ
Запускаются скрипты, выполняющие соответствующие изменения в каналах WebSphere MQ, необходимые для возобновления взаимодействия с сервисом,
функционирование которого было переведено на резервную площадку.
8. Завершение - вывод журнала процесса перевода в диалоговом окне
После завершения всех шагов процесса – дежурному инженеру в диалоговом окне выводится подробный отчет, содержащий информацию обо всех
выполненных командах на устройствах и о результатах их выполнения.
*) В случае недоступности серверов, к которым происходит обращение на данном шаге – дежурному инженеру предоставляется возможность пропустить этот
шаг, повторить или остановить процесс перевода (выбор действия необходим для возможности продолжения процесса перевода, даже в случае сбоя
компонентов, расположенных на площадке, на которую осуществляется переход).

ЦТУ
ТУз ТУ (КЦОИ2)
ТУз КЦОИ2
.
.
.
ТС УБР
ТС УБР
СТС МР
.
.
.
ТС УБР
.
.
.
ТУз КЦОИ1
ТС УБР
ТУз ТУ (КЦОИ1)
.
.
.
ТС УБР
.
.
.
ЦС3 (Н. Новгород)
Тушино Нудоль
ТС ЦА,
МГТУ
ЦС1 (Тушино)
ЦС2 (Нудоль)
Схема планового перевода обработки электронных
сообщений
• Перевод
осуществляется
администратором
ТСЭР без
привлечения ТУ
• Контур репликации
между ЦС1 и ЦС2
сохраняется

Результат
• Оперативность процедуры перевода на резервную площадку была значительно
повышена: процесс перевода занимает около 5 минут вместо 30 и более до
использования HPE OO;
• За счет автоматизации процедуры перевода и связывания воедино решаемых задач
требования к квалификации задействованного в переводе персонала снижены;
• За счет автоматизации рутинных операций уменьшено влияние человеческого
фактора;
• Визуализация процесса и повышение качества обслуживания инфраструктуры;
• Автоматизация обработки ошибок с фиксацией и контролем результатов,
возможность пошагового выполнения перевода.

Техносерв
Автоматизация
процессов
управления
Опыт построения систем автоматизации для сред тестирования на
базе программных продуктов HPE
Александр Шубин, архитектор решений, Техносерв

Техносерв
Предпосылки – почему необходима
автоматизация?
38

Техносерв
При внесении изменений
классическим способом от 3 до 6
месяцев
При внесении изменений в
бизнес за 1 день
39
Предпосылки – почему необходима автоматизация?
Возможность
определена
Возможность
реализована
Сбор
бенефитовTime to
market - 6
месяцев
t t
Возможность определена
и реализована
Сбор
бенефитов
Конкурент
реализовал
возможность

Техносерв
Дешевле подготовка и
поддержка
Сокращение затрат на ИТ
Бизнес и эксплуатация
Техносерв
Бизнес
Экономия
Повысить
управляемость
ИТ
Сокращение time-to-marketСкорость
Больше времени на новые
продукты
Меньшие требования к
квалификации
Уменьшение TCO
Сократить количество
рутины
Уменьшить количество
ошибок
Эффективность
использования
4

Техносерв
Бизнес-кейс системы управления тестовыми средами
41
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
До автоматизации ТС После внедрения
автоматизации ТС
После внедрение
автоматизации и
управление ЖЦ ТС
19%
1% 1%
81% 81%
56%
0%
18%
43%
Стоимостьвладения
Затраты на инфраструктуру ТС
Стоимость вычислительных
ресурсов при развертывании
Стоимость вычислительных
ресурсов при тестировании
Экономия на стоимости
вычислительных ресурсов

Техносерв
Процесс создания тестового контура раньше
Техносерв
Планирование
Регистрация
заявки
Создание Тестирование
Согласование Подготовка Создание среды
Согласование:
• Почта
• Телефон
• Система заявок
Доступность:
• Инфраструктуры
• исполнителей
Ресурсы предоставлены
Ресурсы предоставлены,
но не используются
Удаление
Выполнение
задач
• Сеть
• СХД
• Данные
• Создание серверов
• Установка ППО
• Загрузка данных
Фактическое начало
тестирования
Тестирование
окончено
Ресурсы все
еще не
освобождены
6

Техносерв
Процесс создания тестового контура сейчас
Техносерв
Планирование
Регистрация
заявки
Создание Тестирование
Заявка
Создание
среды
Ресурсы предоставлены
Ресурсы
предоставлены
Автоматизированное:
• Создание серверов
• Установка ППО
• Подготовка и
загрузка данных
Ресурсы
освобождены
Тестирование
окончено
Доступность
ресурсов
контролируется
системой
Выполнение задач
Простота
Сокращение
времени
Сокращение
времени
Больше времени на тестирование
7

Техносерв
Проект по созданию системы управления
тестовыми средами
44

Техносерв
Использование системы управления тестовыми средами
Продуктивная
инфраструктура
Тестовая
инфраструктура
GOLD копия
продуктивной
среды
Платформа
тестовыми
средами
Портал управления
тестовой инфраструктурой
Подсистема
обезличивания и
тестовыми данными
ИТ системы
● ITSM
● Учет дефектов
● Деплоймент и
контроль версий
● Инвентаризация
● Мониторинг
Сотрудники ИТРуководитель Пользователь
9

Техносерв
Архитектура решения
46
Портал TE-Cloud
HP CSA
Управление заявками
Автоматизация сценариев развертывания ТС
Автоматизация операций изменения и
сопровождения ТС
АСУТС
Служба
эксплуатации
тестовых сред
Управление АСУТСУправление ресурсами
Заказчики
X86 (Вирт.инфр.) IBM PowerOracle SPARC СХД
Инфраструктура тестовых сред
Подача заявки на создание/изменение ТС
Контроль статуса заявки
Планирование и управление ТС
и ресурсами
Контроль и управление операциями
Используются продукты
Техносерв
HPE Data Center Automation

Техносерв
Функциональные возможности 1/4
Управление заявками на создание и
изменение тестовых сред:
– Регистрация заявок
– Планирование работ на основе
шаблонов
– Согласование заявок, выявление и
анализ ресурсных конфликтов
– Контроль исполнения работ
– Интеграция с существующими
системами ITSM
Техносерв
Техносерв
11

Техносерв
Управление инфраструктурными
ресурсами:
– Информация о доступных ресурсах
– Плановая загрузка в целом и по каждой
тестовой среде
– Контроль фактического использования
ресурсов
– Выявление ресурсных конфликтов
– Интеграция с существующими
источниками информации
(мониторинга, управления,
оповещения…)
Техносерв
Техносерв
12

Техносерв
Автоматизация операций:
– Развертывание и настройка серверов с
установленными ОС, системным ПО и СУБД
– Настройка SAN и LAN
– Установка и настройка middleware и
прикладного ПО
– Интеграция компонентов в единую тестовую
среду
– Интеграция тестовой среды с другими
системами
– Изменение конфигурации тестовых сред
Техносерв
Автоматизированные
сценарии HPE Operations
Orchestration
HPE Data Center
Automation
13

Техносерв
Управление загрузкой персонала:
– Уровень загрузки персонала
– Структура загрузки по задачам,
тестовым средам
– Контроль плановой и фактической
загрузки персонала
Техносерв
Техносерв
14

Техносерв
Результаты проекта
51

Техносерв
Итоговые показатели
45% сокращение
потребления
инфраструктурных
ресурсов
65% в среднем
уменьшение времени на
создание тестовых сред
70% сокращение
трудозатрат на создание
52

Спасибо!
Техносерв

DevOps
Новые реалии –
новая скорость
Андрей Косыгин
Ведущий архитектор решений

Сдвиг приоритетов бизнеса требует DevOps
Единая команда !
- Единые цели
- Единые задачи
- Единая ответственность
Test
Dev QA
Dev Ops
Dev
QA
Итераци
и Agile 0 1 2 3 4
Dev +Test Ops
До DevOps После DevOps
Dev OpsTest
Prod
Prod

- это подход, который позволяет
подразделениям разработки,
тестирования и эксплуатации
реализовывать текущие
требования бизнеса по
постоянному выпуску ПО и
сервисов путем организации
взаимодействия этих групп

Составляющие DevOps
58
Люди
Требует постоянных усилий
•Совместные усилия
•Это не продукт или должность
•Нет универсальных рецептов
•Нет единого источника
Процессы Технологии

DevOps Continuous Everything
Найдена
проблема. RFC
создан
Код изменен,
развернут и
оттестирован
Билд передан в
тестирование,
Билд
согласован и
развернут в
продуктиве
Continuous Everything
Изменение
спланировано и
согласовано
Билд передан в
препродуктив,
Continuous Assessment
ST – PRDV – QA
Непрерывная интеграция и тестирование
Непрерывный выпуск и
внедрение
Непрерывная доставка
Непрерывная
эксплуатация
Непрерывная оценка
Плани-
рова-
ние
Сборка
Разра-
ботка
Специ-
фика-
ция
Тести-
рова-
ние
Развер-
тывание
(ST, PR)
Тести-
рова-
ние
Развер-
тывание
(Dev, QA)
Эксплу-
атация
Выпуск

ПроцессРешенияHPESoftware
3PTools/
OpenSource
HPE SW DevOps технологический обзор
ST – PRDV – QA
Непрерывная интеграция и тестирование Непрерывный выпуск и внедрение
эксплуатация
Непрерывная оценка
AGM ALM/ALI SM/UCMDB
UFT NA/SA
OO/ SiteScope
SM Sitescope UCMDB
Fortify (SCA)
Fortify WebInspect AppView AppDefender
HPE hellion Development Platform (HDP)
Git*
* Used in Build Phase for Get Code
TFS*
Subversion*
VS
Eclipse
MS WDT
MS Build
Maven
SSH
vCenter
Chef
Nexus
Jenkins
SSH
vCenter
Chef
Nexus
Big Data (ITBA)
CODAR/CSA ALM/PC
UFT
SA NV
OO UFT
CODAR/CSA ALM/PC
OO UFT
SA NV
ALM SV
PPM NV
Current Release
Planned
3P Supported
Legend
Плани-
рова-
ние
Сборка
Разра-
ботка
Специ-
фика-
ция
Тести-
рова-
ние
Развер-
тывание
(ST, PR)
Тести-
рова-
ние
Развер-
тывание
(Dev, QA)
Эксплу-
атация
Выпуск

Решения в
области DevOps
61

Решения и услуги HPE SWS
Услуги по внедрению
• Уникальная методика
внедрения DevOps,
основанная на продуктах
НРE и других решениях
• Услуги по оценке,
тестированию,
интеграции,
развертыванию и
предоставлению
Семинары
• Семинары преобразования
(Transformation Experience
Workshop)
• Семинары разработки
решения (Solution Discovery
Workshops)
• Составление планов
развития
• Оценка зрелости
Процессы и лучшие
практики
• Экспертиза, IP и
методология, основанная
на лучших практиках НРE
• Управление
организационными
изменениями
• Solution Management
Services
• on Premise, Hosted,
Remote
Услуги по управлению

ST – PRDV – QA
эксплуатацияНепрерывная оценка
Непрерывная оценка Непрерывная интеграция
Создание
проекта и
заданий
Создание
кейсов
Создание
CI и RFC
AGM SM/ UCMDBPPM
Написание
кода
Сохране-
ние кода
Сборка
кода
Оценка
безопас-
ности
кода
Выбор
кейсов в
IDE
FortifyGitEclipse Nexus
Jenkins
Непрерывное тестирование Непрерывный выпуск
Уничтоже-
ние среды
Функцио-
нальное
тестиров
ание
Разверты-
вание
среды QA
Chef
CODAR
ALM/PC/SV
UFT CODAR
Chef
Уничтоже-
ние среды
Разверты-
вание на
PRD
Chef
Jenkins
OO/SACODAR
Chef
Обновле-
ние CI,
закрытие
RFC
SM UCMDB
Функцио-
нальное
тестиров
ание
Разверты-
вание
среды STG
Chef
CODAR
ALM/PC/VC
UFT
Непрерывное внедрение
ALM/ALI
Оценка
безопас-
ности
кода
Fortify
Пример интегрированой среды, реализующей концепцию DevOps
Плани-
рова-
ние
Сборка
Разра-
ботка
Специ-
фика-
ция
Тести-
рова-
ние
Развер-
тывание
(ST, PR)
Тести-
рова-
ние
Развер-
тывание
(Dev, QA)
Эксплу-
атация
Выпуск

ST – PRDV – QA
эксплуатацияНепрерывная оценка
Непрерывная интеграция
Написание
кода
Сохране-
ние кода
Создание
контей-
нера DEV
Выбор
кейсов в
IDE
ALM/ALI
GitEclipse Maven
Удаление
контей-
нера DEV
Сохране-
ние
образа
DEV
ALM/PC/SV
UFT Docker
Пример интегрированой среды, реализующей концепцию DevOps, и Docker
Тестиро-
вание
контей-
нера DEV
Nexus
Docker
Jenkins
Docker
Непрерывное тестирование
Создание
контей-
нера QA
Удаление
контей-
нера QA
Сохране-
ние
образа
QA
ALM/PC/SV
UFT Docker
Тестиро-
вание
контей-
нера QA
Nexus
DockerDocker
Непрерывный выпуск
Создание
контей-
нера STG
Удаление
контей-
нера STG
Сохранен
ие
образа
STG
ALM/PC/SV
UFT Docker
Тестиров
ание
контей-
нера STG
Nexus
Docker
Jenkins
Docker
Создание
контей-
нера
PRD
Обновле-
ние CI,
закрытие
RFC
SM UCMDB
Непрерывное внедрение
Docker
Плани-
рова-
ние
Сборка
Разра-
ботка
Специ-
фика-
ция
Тести-
рова-
ние
Развер-
тывание
(ST, PR)
Тести-
рова-
ние
Развер-
тывание
(Dev, QA)
Эксплу-
атация
Выпуск

Cпасибо!
Андрей Косыгин – andrey.kosygin@hpe.com
65

Управление
ИТ-активами
Александр Павлов
технический консультант

Вызов и основные драйверы
Максимизация экономической эффективности ИТ подразделения
• Расчет стоимости владения ИТ услугой/системой
• Биллинг услуг и разнесение общих затрат по потребителям
• Оптимизация и управление лицензионным парком
• Применение лучших практик в вопросе управления активами
• Актуальная отчетность

Расчет стоимости владения ИТ услугой/системой

Учёт виртуальных сред

Биллинг услуг и разнесение общих затрат по потребителям

Консолидация лицензий ПО

Оптимизация поддержки ПО

Обновления лучших практик

Актуальная отчетность

Использование мастеров для настройки

Спасибо за внимание!

Опыт внедрения процесса
управления программными
активами в Райффайзенбанке
Максим Качёлкин, руководитель, вице-президент
Группы централизованного контроля систем и сервисов

АО «Райффайзенбанк»
 является дочерним банком Райффайзен Банк Интернациональ АГ
 работает в России с 1996 года и оказывает полный спектр услуг
частным и корпоративным клиентам
 входит в состав системно значимых кредитных организаций
 на логотипе Райффайзенбанка изображены две перекрещенные
лошадиные головы. Этот символ использовался западноевропейскими
народами с давних времён. Люди прикрепляли этот знак к фронтонам
своих домов, чтобы уберечь семьи от зла и несчастий. В некоторых
отдалённых деревнях Европы традиция до сих пор жива

Software Asset Management (SAM) как решение
 Задача проекта: обеспечить непрерывный контроль за лицензиями внедрив процесс
управления программными активами и средства его автоматизации, модифицировать
существующие процессы для предоставления необходимой информации.
ISO/IEC19770-1
Information Technology -
Software Asset Management
Full ISO/IEC SAM Conformance
Achieving best-in-class strategic SAM
Operational Integration
Improving efficiency and effectiveness
Practical Management
Improving management controls & driving immediate benefits
Trustworthy Data
Knowing what you have so you can manage it
 Контроль лицензионного
соответствия требует
огромной ручной
работы
 Процесс управления
закупками ПО
неэффективен
 Риск приобретения
избыточных лицензий и
необоснованных трат

Техническая архитектура и процесс SAM
Oracle
iProcurement
DataBase Server
HP Asset Manager 9.5
DB on MS SQL 2012
Application Server
Web-Tier
ODBC
SAP Business Object
Enterprise
Citrix Receiver
HP Asset Manager
Windows-client
HP Asset Manager
Web-client
HTTP/HTTPS
Integration Server
HP Automated
Process
Manager
ODBC
OracleiProcurementIntegration
HPConnect-ITScenario
MappingRules
AM
Connector
Database
Connector
ODBC
ODBC
AtlassianJIRAIntegration
MappingRules
AM
Connector
Database
Connector
ODBC
ДИЦ«Турбо9Макс»Integration
MappingRules
AM
Connector
Database
Connector
MSSCCMIntegration
MappingRules
AM
Connector
SCCM
Connector
WyseDesktopManagerIntegration
MappingRules
AM
Connector
Database
Connector
ODBC
ODBC
ODBC
JIRA-Confluence
IBM Lotus Domino
Mail Server
ODBC
Turbo Accountant
ODBC
Wyse Desktop Manger
ODBC
MS SCCM
ODBC
AM Push-
adapter
HPUCMDB
SCCMFederationadapter
UDforOLMS
Microsoft Forefront
Identity Manager
FIM
Extensible-
connector
Oracle
Instances
Citrix
HP Asset Manager
Windows-client
ODBC
SM
TP
Web-service
Web UI
Web UI
BigFix
Server
ILMT
Server
BigFix agent on
server with IBM
Software
UD Inventory
Scanner

Результаты проекта
 HP Asset Manger внедрён как средство автоматизации SAM и интегрирован с
существующими системами банка
 Запущен процесс SAM и люди осваиваются в новых для себя ролях
 Сотрудники ИТ освободились от ручной работы по учёту лицензий и
переключились на творческие задачи
 Планирование будущих расходов на лицензии и поддержку стало прозрачным
для ИТ и бизнес-заказчиков
 Мы можем эффективно управлять имеющимся пулом лицензий в условиях
динамично изменяющегося бизнеса (повторное использование, оптимизация)
 Риск использования нелицензионного ПО поставлен под непрерывный
автоматический контроль

ТСО проектов и задач в
Банк ВТБ (ПАО)
Владислав Плетнев, руководитель службы
поддержки систем отчетности и рисков

Группа ВТБ
Ведущая международная финансовая группа российского происхождения
Группа ВТБ — это банк ВТБ, его дочерние (доля ВТБ — более 50%
голосующих акций/долей) кредитные и финансовые организации
Обладает уникальной для российских банков международной сетью,
которая насчитывает более 30 банков и финансовых компаний более чем в
20 странах мира
Предоставляет своим клиентам комплексное обслуживание в странах СНГ,
Европы, Азии и Африки
На российском банковском рынке группа ВТБ занимает второе место по
всем основным показателям
85

AnyCorp
Программа проектов по управлению ИТ-активами
– Последовательно реализуется в банке с 2012 г.
– Каждая фаза нацелена на получение конкретных
результатов и длится не более 6 месяцев
– Постепенно наращивается функциональный охват и
охват учитываемых элементов
– Основные цели:
1.Получение точной и достоверной информации об ИТ-активах на
протяжении всего жизненного цикла из единой точки в любой
момент времени
2.Определение совокупной стоимости владения ИТ-активами,
программно-аппаратными комплексами, задачами, проектами и
ИТ-услугами банка
– Средство автоматизации: HP Asset Manager 9.x
Фаза 1
Цели:
Формирование единого информационного пространства в рамках жизненного
цикла ИТ-активов
Учет ИТ-активов в качестве ресурсов проектов и объектов договоров
Отслеживание затрат ДИТ в соответствии со статьями бюджета
Накопление статистических данных по ИТ-активам для принятия
управленческих решений
Охват учитываемых элементов:
Серверы, АРМ
Фаза 2
Цели (расширение функционального охвата):
Учет балансовой стоимости и срока амортизации ИТ-активов
Отслеживание ТСО ИТ-активов и проектов ДИТ
Расширение охвата учитываемых элементов
Виртуальные серверы, Сетевое оборудование, Лицензии ПО
Фаза 3
Цели (расширение функционального охвата):
Отслеживание ТСО комплексов (СХД), задач и ИТ-услуг Банка
Оценка эффективности использования лицензий (организация необходимых
процедур SAM)
Расширение охвата учитываемых элементов
СХД, Диски, Экземпляры ПО

AnyCorp
Учет и распределение затрат, методика расчета ТСО
– Разработана политика учета и распределения затрат,
методика расчета ТСО
– Политика и методика согласованы с финансовым
департаментом банка
– Политика описывает виды затрат, единицы учета,
область применения, правила расчета и
автоматической генерации строк затрат и т.д.
– Разработана система связей с финансовым влиянием
между ИТ-активами (финансово-ресурсная модель) в
контексте программно-аппаратных комплексов, задач
и проектов банка

AnyCorp
Финансово-ресурсная модель для задач и направлений банка

AnyCorp
Учет ИТ-активов в качестве ресурсов задач (ФРМ)

AnyCorp
Финансово-ресурсная модель для проектов банка

AnyCorp
Учет ИТ-активов в качестве ресурсов проектов

AnyCorp
Текущее состояние бюджета проекта

AnyCorp
Информация по связанным с проектом договорам

AnyCorp
Единое информационное пространство

95

14 апреля 2016 г.
Мониторинг как ИТ-
искусство
Яков Керанчук, архитектор решений НРЕ

Цель #1 – обеспечение потребностей бизнеса
Связывание
производительности бизнеса и
ИТ
Предсказание проблем
Автоматизация задач и
процессов
Рост прибыли
Исключительный
сервис для клиентов
Улучшенная эффективность,
гибкость и качество
“Перед руководителями Операционного управления ИТ стоит задача показать, как
услуги, которые они предоставляют, связаны с ценностями бизнеса и двигают
организацию вперед.”1
1- Gartner group Special Report – 24th September 2014

Основные
требования
• Умение разбираться в большом объеме
информации, быстро находить корень проблемы
• «Чувствовать и понимать пользователя»
• Оперативно разрешать проблемы, прикладывая
минимум усилий
• Уметь четко и ясно выразить свою мысль
Навыки успешной работы
98
Текущие тренды
• Big Data
• Визуализация
• Управление производительностью приложений
• Автоматизация

Сбор
данных
всего в реальном
времени
• Обнаружение проблем
прежде чем они затронут
сервис
• Корреляция по времени,
топологии и др.
• Расчет шаблонов
поведения и корневых
причин
Анализ
для прогнозирования
и решения
масштабирования
систем
• Ускорение
выполнения задач
процессов
Адаптация
точная и
быстрая
Универсальный подход
• Заказчики, бизнес и
ИТ
• Реальные
пользователи
• Транзакции

Strategic Outcomes
Sustained Benefits
Rapid ROI Benefits
Quick Value Benefits
Модель зрелости
Возможности
Время/зрелость
Базовый Продвинутый Зрелый
Stage 1
Stage 2
Stage 3
Stage 4
Stage 5Stage 1 Stage 2 Stage 3 Stage 4 Stage 5Реактивный Прикладной Управляемый Проактивный Предиктивный1 2 3 4 5
Actions
Network Management
Systems Management
Event Management
Network Management
Systems Management
Event Management (Correlated)
Configuration Management
Application Performance Mgmt
Service Modeling
Integrated Process
Automation
Service Level Management
Capacity Management
Service Analytics
Analytics&Automation
Network Management
Systems Management
Service Modeling
Process Automation
ActiveAutomation
Network Management
Systems Management
Event Management
(Consolidated)
PassiveAutomation
Network Management
Systems Management
Service Modeling
Integrated Process
Automation
Service Level Management
Capacity Management
Service Analytics
LightsOutIT
УнификацияСтандартизация Предсказание

Мониторинг сервисов «сверху-вниз»
Управление
доступностью и
производительностью
Мониторинг ОС /
инфраструктуры
Мониторинг СУБД /
серверов приложений
Мониторинг
инфраструктурного ПО
ARIBA ORACLE SIEBEL
SAP BroadVision PeopleSoft BlackBerry
ORACLE
MS SQL
Server
Informix DB2
Internet Info
Server 3.0
Portal
MS Exchange
Server Lotus
IBM Check Point TIBCO
Internet Security
Systems
webMethods Apache SOAP Sun
MQSeries
Family
MS Windows HP IBM Solaris Linux

3D IMAX
Experience
Управление производительностью приложений
• Мобильные, облачные и
инфраструктурные решения
• Мощные аналитические возможности
и средства диагностики
• Широкое покрытие программных сред
“Мы можем определить проблему за 1-2
часа до того как она повлияет на
производодительность приложения”
Raphael Aquino, Sentara Healthcare

База данных конфигурационных элементов
– Автоматическое обнаружение и представление взаимосвязей объектов управления (КЕ) от сетевого до
прикладного уровня (С-Р Модель)
Серверные платформы
HP-UX Solaris
Бизнес сервис
Системы хранения данных
Сеть
Клиенты
Почта
Unix LinuxWindows

Уровень управления услугами
104

Автоматизация
105

Продвинутая аналитика ИТ HAVEn

Продвинутая аналитика ИТ - прогнозирование HAVEn

Продвинутая аналитика ИТ - корреляция HAVEn

Спасибо!

Централизованная
система мониторинга
ИС ПАО МТС
Департамент оперативного мониторинга ИС
Начальник ОИТО Константин Ризен
14.04.2016

113
Тезисы о мониторинге
Мониторинг — непрерывный процесс наблюдения и регистрации параметров объекта, в
сравнении с заданными критериями.
Цель - выявление возможных не штатных ситуаций в работе ИС до момента возможных
аварий.
Задачи – контроль и предупреждение, оперативное реагирование и устранение, анализ,
донастройка мониторинга
Система мониторинга – представляет собой интеграционное решение, позволяющее
контролировать доступность и качество функционирования бизнес-процессов, сервисов и
систем компании на основе единого поля событий и данных.
Мониторинг
РеагированиеАнализ
Тюнинг
Большинство проблем не возникает мгновенно, а
постепенно накапливаются, либо появляются косвенные
признаки, по которым их можно предсказать и
предотвратить.
Постоянный контроль объектов IT-инфраструктуры и
компонентов ИС системой мониторинга с консолидацией
данных в едином центре позволяет выявлять признаки
проблемы до того, как они скажутся на работе всей системы
или сервиса и затронут конечных пользователей.
Если же инцидент все-таки случился, анализ информации от
системы мониторинга помогает оперативно выявить его
источники и причины, благодаря чему проблема
устраняется в максимально сжатые сроки.

114
Предпосылки внедрения системы
 Необходимость внедрения эффективных средств ранней диагностики событий и предсказания влияния
событий на абонентские сервисы и бизнес процессы компании.
 Необходимость внедрения ресурсно-сервисной модели и механизмов для оперативного выявления
корневых причин влияющих на снижение качества бизнес-процессов оказываемых абонентам и конечным
пользователям.
 Фрагментарный сбор информации с необходимостью анализа дискретных событий специалистами,
необходимость единой базы знаний для такого анализа.
 Необходимость средств автоматического восстановления сервиса при повторяющихся аварийных
ситуациях с использованием запланированных сценариев.
 Необходимость автоматизации выполнения регламентных процедур.
 Необходимость средств фильтрации информации с обслуживаемых систем, необходимость обработки
ложных сообщений об аварийных ситуациях и предпосылок к таковым.
 Ручная регистрация инцидентов, приводящая к задержкам во времени и потере информации.
 Необходимость снижения количества аварий и улучшения качества бизнес-процессов влияющих на
абонентов и конечных пользователей.
 Создание Департамента оперативного мониторинга информационных систем (далее - ДОМИС) который
осуществляет централизованный мониторинг информационных систем ОАО «МТС».
 Система мониторинга устарела и не соответствует современным технологическим требованиям.
 Необходимость оперативного определения корневых причин
при деградации бизнес–процессов необходимо время
на диагностику и их определение.

115
Цели и продукт проекта
Цель проекта - внедрение системы мониторинга ИС класса MISSION и BUSINESS CRITICAL * для повышения качества и
доступности бизнес-сервисов.
Основные критерии успешности проекта:
 Сокращение времени ликвидации неисправностей и сбоев на информационных системах в случае их возникновения за счет
оперативного выявления корневой причины нештатной работы компонентов инфраструктуры ИТ и прикладного ПО с
использованием ресурсно-сервисной модели;
 Улучшение качества сервисов бизнес – заказчику предоставляемых за счет проактивного мониторинга
 Эффективное управление событиями на ИС за счет уменьшения времени на их обработку.
Продукт проекта:
Внедрена промышленная системы мониторинга ИС класса MISSION и BUSINESS CRITICAL
Выполнена интеграция с базой CMDB – ядром системы управления знаниями об ИТ инфраструктуре
Формализован процесс мониторинга и управления событиями: выполнена доработка существующих / создание новых
регламентов процесса мониторинга и управления событиями. Реализованы процедуры управления событиями, проработаны
интерфейсы между процессом мониторинга и процессом управления инцидентами.
Построена ресурсно-сервисная модель (РСМ): разработаны унифицированные правила формирования и управления РСМ,
которая будет являться эталоном для описания всех информационных систем и использоваться для мониторинга и выявления
степени влияния обнаруженных событий на сервисы и бизнес-процессы.
Выработаны механизмы и настроен инструментарий для выявления корневой причины снижения качества бизнес-процессов.
Выполнена интеграция с системой управления инцидентами и графиком дежурств
Внедрен инструментарий автоматизации выполнения регламентных процедур и устранения аварий.
Приведено в соответствие наличие и потребность лицензий программного обеспечения.
Получен инструмент генерации статистической отчетности по событиям на информационных системах класса MISSION и
BUSINESS CRITICAL для использования в улучшении качества их эксплуатации.
Повышена эффективность выполнения регламентных процедур за счет уменьшения времени выполнения и влияния на
сервисы. Выполнена модернизация промышленного решения, позволяющего контролировать доступность и качество
функционирования бизнес-процессов, сервисов ИТ систем компании на основе единого поля событий и данных*.

116
Критерии эффективности проекта
№ Название показателя Значения показателя до
проекта
Значения показателя после реализации проекта
1 Оперативный мониторинг Частично
Только для ТМ определенного типа
 Расширенные возможности
За счет большего количество специализированных агентов и пробников для различных ИТ систем, сред,
ОС, СУБД и приложений.
2 Инженерный мониторинг Частично
Для ТМ с агентами системы.
 Расширенные возможности
Возможность расширения за счет разработки собственных модулей и пробников.
3 Мониторинг качества бизнес-
сервисов предоставляемых
бизнес заказчику
подразделениями ИТ (KPI)
- Отсутствует
Собственная разработка.
 Штатное средство
Обеспечивает требуемый уровень отказоустойчивости, содержит механизмы корреляции с событиями
генерируемых ИТ инфраструктурой, предоставляет наглядные средства представления для сотрудников
любого уровня.
4 Управление событиями (Event
management)
Необходима интеграция с системой
управления инцидентами.
Основа построения процесса управления событиями. Расширенные функции по работе с одиночными и
группами событий, интеграция с системой управления инцидентами. Единая точка сбора и обработки
событий от всех ТМ. Поддержка открытых интересов и протоколов.
5 Управление отказами и
неисправностями (Fault
management)
- Отсутствует  Штатное средство
Основа построения процесса управления отказами и неисправностями.
Возможность группировки, приоритезация и корреляция событий в соответствии с существующим
набором ИТ систем и топологий ИТ инфраструктуры. Создание сервисных окон для проведения работ
на ИТ системах.
6 Наличие Ресурсно – сервисной
модели (РСМ)
- Отсутствует  Штатное средство
Позволяет эффективно выявлять корневую причину снижения бизнес-сервисов предоставляемых
бизнес-заказчику подразделениями ИТ. Предоставляет проактивные средства прогнозирования и
предупреждения возникновения аварий.
7 Подсистема выполнения
регламентных процедур
(Orchestration subsystem)
Частично собственная разработка
Гибко настраиваемый инструмент с возможностью управления многоэтапными процедурами любой
сложности, интегрировано с основной консолью системы.
8 Количество точек мониторинга
(ТМ)
18 000 Свыше 100 000 включая кластеры LANWAN, SAN и СХД.

117
функция мониторинга ИС
Функции Эксплуатации
Foris
Администрирование инфраструктуры
Северо-Запад
Центр
Поволжье
Урал
Сибирь
Дальний восток
Москва
Урал
Сибирь
Юг
Поволжье
Дальний восток
ДОМИС
Северо-Запад
Москва
Функция выполнения РП и
Контроля выполнения RFC
Функции ДОМИС

118
Централизованная система мониторинга с
модульной архитектурой
Централизация мониторинга позволяет решать задачи:
• Обеспечить контроль системы силами небольшой дежурной смены.
• Благодаря контролю объектов любых типов ускоряется процесс выявления причин
возможных аварий и соответственно ускорение восстановления работоспособности
системы.
Для обеспечения возможности масштабирования под любую сложность ИС,
используется принцип модульности. ЦСМИС представлен рядом таких модулей:
• Ядра (HP BSM) - цель которого выполнение функций централизации мониторинга.
• Модули мониторинга(SiteScope, NNM, BPM, Integ) – цель которых осуществлять не
посредственно мониторинг ТС ИС и отправку контрольных данных в ядро системы
• Модуль управления(OO) – цель автоматизация выполнения регламентных процедур в
ИС

119
ДОМИС, г. Краснодар
Контур ИТ-инфраструктуры одного МР
ПРПр (HP OO)
ITOO
ПУО (HP Reporter + PM)
ITREPPM
Сервер интеграции
ITINTEG
БД ПМСП (SQL)
ITOMSQL
БДКЕ (HP UCMDB)
ITCMDB
ПМСП (безагентский мониторинг, HP SiteScope)
ПМТП (HP BPM)
ITSSBPM
Сетевые устройства
Серверы
111
СХД
Remedy ITSM
fCMDB (Москва)
fcmdb05
HP BSM Фронтенд
BSMGW1
HP BSM Фронтенд
BSMGW2
Cisco Balancer 1
Cisco Balancer 2
ПСМ (HP NNM)
Агент ПРПр (HP OO RAS)
ITNNM
BSM
virt.
GW
ПМСП (агентский, HP OM)
ITOM
ПСХД (HP SE)
ITSE
БД Oracle (BSMDB)
With StandBy
HP BSM Бэкенд
BSMDP1
0600hpbsm
0600hpbsmapp
HP BSM Бэкенд
BSMDP2
ЦСМИС – модульная архитектура

120
Заказ на мониторинг
Система является эффективным средством взаимодействия бизнес-подразделений и
сервисного подразделения мониторинга.
Заказ на мониторинг IT объекта, созданный в данной системе, является поручением по
настройке монитора, содержит полную информацию для конфигурирования средств
мониторинга, координации событий от системы мониторинга и реакции дежурных на их
поступление.

121
Модуль загрузки объектов мониторинга (МЗОМ)
Система заказов на мониторинг Модуль загрузки объектов мониторинга
(МЗОМ)
Модули мониторинга (SiteScope,
NNM)
МЗОМ на основании данных «Системы заказов на мониторинг» выполняет изменения в конфигурациях
«Модулей мониторинга ЦСМИС» (SiteScope, NNM) и сохраняет текущую конфигурацию в своем хранилище,
из которого могут получать информацию другие системы. Автоматизация процесса позволяет значительно
повысить оперативность настройки мониторинга объектов IT различного типа, исключает возможные при
настройке вручную ошибки описания конфигурации средств мониторинга, поддерживает в согласованном
состоянии централизованное хранилище конфигурации модулей мониторинга для оперативного получения
расширенных данных об их состоянии, на основании данных заказов на мониторинг формирует базу для
обогащения и управления событиями от модулей мониторинга.

122
Управление простоями в HP BSM (DownTime)
Управление простоями в HP
BSM
позволяет временно снять
выбранные
ТМ с мониторинга на время
выполнения
обслуживания как самих ТМ, так
и
оборудования или сервиса,
которые
могут повлиять на корректность
мониторинга данной ТМ
Простои позволяют исключить
возможность регистрации не
качественных инцидентов, по
событиям, полученным в ходе
выполнения технических работ с
оборудованием или сервисом
События, поступившие во время
простоя, скрываются от взора
дежурных. Как следствие:
От дежурных не ускользнут
действительно значимые,
аварийные, события
Не будут зарегистрированы
инциденты по
санкционированным событиям
Простои бывают трех видов:
Созданные на время проведения
работ с использованием
функционала HP BSM
Полученные из настроек
расписания мониторинга ТМ
Созданные во время
регистрации RFC в Remedy
посредством интеграции с CMDB

123
Обогащение и автоматизация обработки событий
Настройка правил
пересылки событий
на подключенные
серверы
Создание правил
сопоставления событий
с индикаторами
производительности
РСМ
обработки событий,
полученных во время
простоя (downtime)
элементов конфигурации
для автоматического
выполнения стандартной
процедуры или
последовательности
стандартных процедур в контекс
те
события
Например: выполнить рестарт
службы при получении события
Мощнейший механизм
настройки обработки
событий на основе
сценария, написанного
на языке
программирования
Groovy, позволяющий
сделать с событием все, что угод
но
подавления событий по
заданным критериям
Настройка способа
обработки событий
во время штормов
событий, позволяющая
увеличить устойчивость HP BSM
к
сильным
внешним воздействиям
Разработка правил
корреляции на
основе поступления,
не поступления или
порядка поступления событ
ий
Настройка
корреляции событий на осн
ове привязки
событий к
конфигурационным
элементам РСМ и
влияния на них
для автоматического
выполнения
действий в контексте событ
ия
через указанное время
Например: отметить событи
я,
не взятые в работу, через 5
мин
Настройка
автоматического
назначения новых
событий для группы
пользователей
Настройка отправки
уведомлений
по почте, SMS или
на пейджер

124
Модуль безагентского мониторинга широкого
назначения SiteScope
Мониторинг самого широкого спектра объектов: различные виды и метрик ОС, СУБД, WEB серверов,
приложений и прикладных метрик, виртуализация, URL и Cert, LanWan, инфраструктурные службы, SNMP,
BigData, универсальные скрипты (Bash, PowerShell, WMI, Java, C++)

125
Управление сетями. Network Node Manager i
Это функции контроля
за ошибками, доступно
стью и производительн
остью.
Позволяют
увеличить период
работоспособности,
а также повысить
производительность
и быстроту решений
задач бизнеса.

126
Контроль качества пользователей.BPM
Это активный мониторинг приложений для выявления проблем с доступностью и производительн
остью, прежде чем они повлияют на работу пользователей. Система имитирует бизнес-транзакции
и фиксирует проблемы независимо от деятельности реальных пользователей.

127
Интеграция с внешними системами. BSM Connector
Выполнена интеграция
с платформами
и оборудованием
различных
производителей.
Порядка 20-ти
коллекторов
обрабатывают
поступающие
аварийные и
сервисные события.

128
Модели здоровья
Модели здоровья (МЗ) – это набор шаблонов сервисов мониторинга для IT объектов различного типа, позволяющих выполнять
опрос контролируемых параметров (метрик) объектов и диагностировать их состояние, сравнивая текущие значения метрики с
пороговыми значениями рекомендованными, как норма здоровья, для объектов данного вида. Нормы здоровья определяются
таким образом, чтоб состояние объекта не влияло на производительность систем и не создавало проблем в работе
пользователей. Информирование от системы мониторинга о выходе метрики за границы этой нормы позволяет своевременно
устранить проблему, что улучшает продуктивность работы и производительность систем в целом.Модуль
мониторинга
Типы объектов Количество
МЗ
метрик
мониторов
BPM
ИТОГО 1 2 140
Бизнес и Web приложения 1 2 140
INTEG
ИТОГО 19 31 790
SAN, СХД 3 5 335
SUPS, SPA, MSCP, OCC,
Nagios, DSA, ЕСПП
9 19 283
Инженерное оборудование 3 3 144
Самомониторинг 4 4 28
MSMQ
ИТОГО 1 1 1120
MSMQ-очереди 1 1 1120
NNM
ИТОГО 3 27 4933
Сервера сеть 1 1 1631
Сетевые устройства 2 26 3302
SiteScope
ИТОГО 181 263 28830
KPI 1 14 39
URL+certificate 11 12 449
VMWare 11 21 1755
Инженерное оборудование 1 1 132
Инфраструктурные сервисы 16 42 477
Сервера прикладная часть 78 92 10222
Сервера сеть 3 3 3153
Сервера системная часть 42 56 11687
СУБД 18 22 916
Общий итог 206 325 35814

129
Ресурсно сервисная модель
Использование РСМ позволяет получить наглядное визуальное представления о влиянии элементов и
нфраструктуры ИС на бизнес сервис предоставляемый этой ИС. Механизм поиска корневой причины
дает возможность сразу получить информацию вплоть до аварийных метрик и немедленно
приступить к решению аварии.
Представление “360 View”
Представление
“Topology Map”
Представление “Top View”

130
Подсистема выполнения регламентных процедур
Регламентные процедуры это
операции по эксплуатации ИС
носящие регулярный характер и
выполняемые в автоматическом
режиме.
Использование для целей
автоматизации HP Operations
Orchestration:
• Уменьшить нагрузку на дежурную
смену, и позволить ей заниматься
более критичными задачами,
• Снизить или исключить
вероятность ошибки при
выполнении РП,
• Увеличить скорость выполнения
РП, без уменьшения качества.

132
Мониторинг показателей качества БИТ МТС Россия
Функциональная схема решения для единой системы мониторинга
Система мониторинга физических и
логических компонент ИТ систем
Без
агентский
модуль
Без агентский
модуль
Система управления
инцидентами Remedy
Система мониторинга
отклика приложений (транзакций)
Мониторинг состояния, оценка событий
Аналитическая обработка,
проактивные события
Оценка влияния событий,
мониторинг бизнес-процесов
CMDB
SNMP Traps
Приоритезация, корреляция, нормализация, группировка
Создание правил обработки Событий
Самообучение, анализ, проактивность
Поиск корневой причины
Сбор данных, метрик
Система управления серверами
и сетевым оборудованием
Подсистема отчетности и отображения
Различные представления для
просмотра событий, включая уровень
сбора данных
Dashboards,
типовые графики и отчеты
Предпологается, что все подсистемы изображенные на схеме имеют специальные средства для их администрирования и настройки
Уровень сбора данных
Бизнес-процессы ИТ-сервисы
Программное
обеспечение
Базы данных Операционные системы
Сервера Сетевая инфраструктура Хранилища
Информационные
системы
Без-
агентский
модуль
Скрипты
Данные
Система администрирования
Хранилище
событий
Адаптеры для получения
событий от внешних систем
Интерфейсы для специалистов,
администраторов, бизнес
пользователей, руководства
Данные
Данные
События События
База Знаний
График дежурств
Система заказа
на мониторинг
Системы MISSION CRITICAL и BUSINESS CRITICAL
Уровень обработки и
Уровень интеграции
Модуль автоматизации
выполнения регламентных
процедур и запуска
исполняемых сценариев

133
Динамика показателей системы 1
100000
150000
200000
250000
300000
350000
Количество объектов мониторинга в uCMDB

134
200
220
240
260
280
300
320
340
360
Количество разработанных шаблонов

135
100
110
120
130
140
150
160
170
180
дек.14 янв.15 фев.15 мар.15 апр.15 май.15 июн.15 июл.15 авг.15 сен.15 окт.15 ноя.15 дек.15 янв.16 фев.16 мар.16 апр.16
Количество пользователей системы

136
20000
25000
30000
35000
40000
45000
Количество подключенных метрик мониторинга

137
50000
100000
150000
200000
250000
300000
Количество событий

138
Возможности SiteScope в ЦСМИСHP SiteScope является одним из множества модулей мониторинга ЦСМИС.
Мониторинг средствами HP SiteScope осуществляется безагентским способ.
HP SiteScope своими средствами покрывает следующие элементы инфраструктуры:
- Сервер Windows по протоколам NetBIOS и WMI в части:
 Счетчиков производительности
 Состояния служб
 Наличия событий в системных журналах
- Сервер Unix по протоколу SSH в части различных ресурсов ОС
- Кроме того, для обоих типов ОС покрывается мониторинг:
 Доступности сервера или порта
 Загруженности CPU, памяти
 Доступности свободного места на дисках или файловых системах
 Информации, содержащейся в лог-файлах, запущенного на серверах, программного
обеспечения
 Наличия на сервере файлов и каталогов, а так же их состояние (дата создания /
изменения, размер и т.д.)
- Сервера баз данных, таких как:
 Microsoft SQL Server
 База данных Oracle
 DB2 JDBC
Кроме того, возможен мониторинг прочих серверов баз данных при условии наличия
JDBC-драйвера, поставляемого с ней, либо доступной для загрузки
Так же возможен мониторинг логической составляющей сервера баз данных, а так же
приложений, посредством SQL-запросов. В том числе, различных KPI приложений и
сервисов
- Веб-сервера и сервера приложений:
Сервер ApacheмHP SiteScope является одним из множества модулей мониторинга ЦСМИС.
Мониторинг средствами HP SiteScope осуществляется безагентским способ.
HP SiteScope своими средствами покрывает следующие элементы инфраструктуры:
- Веб-сервера и сервера приложений:
 Сервер Apache
 Oracle Application Server 10g
 Oracle 9i Application Server
 Сервер Microsoft IIS
 Сервер приложений WebSphere Application Server
 Сервлет производительности WebSphere
 Сервер приложений WebLogic
 Сервер приложений BroadVision
 Веб-сервер SunONE
 UDDI-сервер
- Универсальный
 Составной
 Составной с формулой
 Сценарий
 Настраиваемый
- Приложение
 RADIUS
 Cisco Works
 Сервер ColdFusion
 Check Point
 Прокси-сервер высокой доступности
 Сервер Microsoft ASP
 Citrix
 Почта
 F5 Big-IP
 Статистика Memcached
 Новости
 Запрос к базе данных
 Настраиваемый для базы данных
 JMX (динамический)
 JMX
- Виртуализация и облако
 Хранилище данных VMware
 Производительность VMware
 Состояние хоста VMware
 Сеть хоста VMware
 ЦП хоста VMware
 Хранилище хоста VMware
 Память хоста VMware
 Amazon Web Services
 Microsoft Hyper-V
 KVM
 Универсальный гипервизор
 Зоны Solaris
- Интернет
 URL
 Проверка ссылок
 Список URL-адресов
 Последовательность URL-адресов
 Содержимое URL-адреса
 Транзакция e-Business
- Сеть
 DHCP
 DNS
 LDAP
 FTP
 Пропускная способность сети
 SNMP
 SNMP-ловушка
 SNMP по MIB
-Большие данные
 Hadoop
 HP Vertica JDBC
Отдельно хочется отметить мониторинг с помощью сценария.
Он позволяет выполнять мониторинг объектов с помощью, как скриптов (bash, PowerShell), так и с помощью
скомпилированных программ, написанных на различных языках (C++, Java и т.д.)
Кроме того, запуск сценария возможен, как локально на сервере SiteScope, так и удаленно, на целевом сервере (по
протоколу SSH).

Внедрение HP OA
в Альфа- Банке
Руководитель направления мониторинга ИТ систем
Алексей Голтыхов

Оценка: источники данных
мониторинга ИТ компонент
Логи
Центральная
Система
Мониторинга
Специальный
и уникальный
мониторинг
Тип
Системы мониторинга и их возможности.
Уровень
инфраструктуры
и OS
Агент
Уровень
Уровень
бизнес - задач
Событийный
Статистический
БЕЗ агентно
Система
HPOperations
HPSiteScope
HPOVPM
HPDiagnostics
HPRUM
IBMTivoli
WhatsUp
Utils
HPBPM

AnyCorp
=+ +
Необходимо получить тенденцию изменения параметра нагрузки
ИТ систем за большой период времени и с максимальной
детализацией.
Попытка сбора графиков и данных за разные промежутки
времени «вручную» не дают истинное представление об
изменении параметра.
Почему нужно хранить данные
1. 2.
Оперативный мониторинг хранит данные глубиной
2 суток. Для разбора аварий требуются исторические
данные.

AnyCorp
Использование данных логов
1.
3.
+ +
0. =>
2. 4.
--->

AnyCorp
Цель внедрения HP OA :
• Снижение использования ресурсов серверов ИТ систем высокой
критичности за счет переноса данных мониторинга из локальных файлов,
расположенных на серверах, в удаленную центральную базу.
• Получение доступа к данным мониторинга ИТ систем высокой критичности
в случае аварий дисковых систем, а так же других аварий, сопровождаемых
потерей данных для расследования их причин.
• Увеличение частоты и глубины мониторинга параметров без использования
ресурсов промышленных систем.
• Повышения качества анализа функционирования и прогнозов нагрузки ИТ
систем за счет увеличения объема анализируемых данных.
• Опыт тестирования решения для нескольких разнородных источников
данных (Big Data for IT).
• Опыт получения данных логгирования.

AnyCorp
HP OA. Опыт применения
2.
1.
Промышленная система
Сбор логов Оперативный мониторинг HP Operation Analytics
HP OA
Internet Log
stream
HP OA
SMS
«Информационный шторм», «Память добавили»

AnyCorp
Архитектура HPOA в Альфа-Банке

AnyCorp
Тенденции мониторинга
Сегодня +10 лет Реальность АБ
• Специализированные системы
объединены централизованными
надстройками.
•Каждая система использует
локальный репозиторий для
сбора данных.
•Объединение данных
производится на уровне linked
data или на уровне UI.
•Сбор данных производится с
интервалом в 5-15 минут.
•Требуется установка агентов
локально для сбора расширенных
показателей.
•Сбор расширенных данных
требует ресурсов промышленной
системы.
•Единая шина для обмена данными.
Шина обеспечивает гарантированную
доставку логов, конфигураций и данных
о производительности.
•Отсутствуют жесткие связи –любое
количество производителей и
потребителей данных.
•Специализированные системы
заменяются драйверами,
встраиваемыми в объекты мониторинга.
•Драйверы непрерывно отправляют в
шину данные: логги, показатели. Отказ от
локального хранения данных.
•Нереляционные специализированные
СУБД заменяют традиционные базы в
части хранения истории
•Единая система мониторинга
подсоединяется к шине и анализирует
все данные для мониторинга в
автономном режиме
•Разработчиками предложена схема
хранения логов в шине передачи
данных Kafka + LogStash + DB как
минимум для 3-х ключевых систем
банка.
• Минимум в трех крупных
подразделениях имеется
необходимость сбора и анализа
логов. Средний объем – 5 Gb/день.
• Объективная реальность
потребовала ввести новый KPI –
доступность компонент
мониторинга.
• Начата эксплуатация VERTICA
для сбора логов и хранения истории
событий и статистики ИТ.
• Начат процесс накопления опыта
по сбору и корреляции событий.

AnyCorp
Благодарю за внимание.
agoltykhov@alfabank.ru

Конференция по программным решениям HPE 2016

More Related Content

What's hot

Viewers also liked

Similar to Конференция по программным решениям HPE 2016

More from Andrey Karpov

Конференция по программным решениям HPE 2016