Конференция по программным решениям 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

Cпасибо!

10

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


Какие тренды мы видим сегодня и почему это важно

Быть быстрее Быть эффективнее Быть дешевле

Время

КоличествоУскорить

предоставление новых услуг

Сегодня

2020

Время

Количество

запросов от

бизнесаВремя отклика


Облака или

внешние

провайдеры

Собственные ИТ

Время


Три шага на пути трансформацииАвтоматизируйте, «оркестрируйте», трансформируйте

13

Традиционные

ИТ

Цифровое

предприятие

Трансформируйте

предоставление

услуг

«Оркестрируйте»

процессы»

Автоматизируйте

задачи

Программа:

• Автоматизация процесса перевода транспортного сервиса между географически

распределенными площадками, Шибаев Александр, Заместитель директора

Межрегионального центра обработки информации Банка России

• Автоматизация сервисов: быстрее, надежнее и дешевле. Пример банка Societe

Generale, Франция, Васильев Константин, технический консультант, HPE в EMEA

• Тестовые среды как услуга: создание и сопровождение, Шубин Александр, архитектор

решений, компания Техносерв

• Дискуссия

Автоматизированные ИТ-услуги как необходимая составляющая современного бизнеса

Спасибо!

15

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


Транспортная система электронных расчетов

ТСЭР предназначена для

предоставления услуг гарантированной

передачи электронных сообщений

между участникам электронного

обмена

в платежной системе Банка России

Модель ТСЭР

Региональные

узлы

Узлы расчетных

систем

Центральный узел

Клиенты

Банка России

Шлюз

Расчетные системы


ШлюзШлюз

Информационно-аналитические

системы Банка РоссииТ

СЭ

Р

Каталог сервисов ТСЭР

Каталог сервисов ТСЭР:• одноадресная доставка электронных сообщений (ЭС);

• рассылка ЭС по списку/многоадресная рассылка;

• логическая маршрутизация ЭС на основании адреса прикладного служебного 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 \\

CTU01\start.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

55

Сдвиг приоритетов бизнеса требует 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)

Эксплу-атация

Выпуск

Пр

оц

есс

Ре

ше

ни

яH

PE

So

ftw

are

3P

To

ols

/

Op

en

So

urc

e

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)




Выпуск

Решения в области 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)




Выпуск


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)




Выпуск

Cпасибо!

Андрей Косыгин – [email protected]

65

mailto:[email protected]

Управление ИТ-активами

Александр Павловтехнический консультант


Вызов и основные драйверы

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

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

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

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

Оптимизация ПО

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

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

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

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

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

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


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

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

АО «Райффайзенбанк»

является дочерним банком Райффайзен Банк Интернациональ АГ

работает в России с 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

Oracle iP

rocu

remen

t Integratio

nH

P C

on

nect-IT Scen

ario

Map

pin

g Ru

lesA

MC

on

necto

rD

atabase

Co

nn

ector

ODBC

ODBC

Atlassian

JIRA

Integratio

nH

P C

on

nect-IT Scen

ario

Map

pin

g Ru

lesA

MC

on

necto

rD

atabase

Co

nn

ector

ODBC

ДИ

Ц «

Тур

бо

9 М

акс

» Integratio

nH

P C

on

nect-IT Scen

ario

Map

pin

g Ru

lesA

MC

on

necto

rD

atabase

Co

nn

ector

MS SC

CM

Integratio

nH

P C

on

nect-IT Scen

ario

Map

pin

g Ru

lesA

MC

on

necto

rSC

CM

C

on

necto

r

Wyse D

esktop

Man

ager Integratio

nH

P C

on

nect-IT Scen

ario

Map

pin

g Ru

lesA

MC

on

necto

rD

atabase

Co

nn

ector

ODBC

OD

BC ODBC

JIRA-ConfluenceIBM Lotus Domino

Mail Server

ODBC

Turbo Accountant

ODBC

Wyse Desktop Manger

ODBC

MS SCCM

ODBC

AM Push-adapter

HP

UC

MD

BSC

CM

Federatio

n ad

apter

UD

for O

LMS

Microsoft ForefrontIdentity Manager

FIMExtensible-connector

OracleInstances

Citrix

HP Asset Manager

Windows-clientODBC

SMTP


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

http://www.gartner.com/document/2854418

Основные требования

• Умение разбираться в большом объеме

информации, быстро находить корень проблемы

• «Чувствовать и понимать пользователя»

• Оперативно разрешать проблемы, прикладывая

минимум усилий

• Уметь четко и ясно выразить свою мысль

Навыки успешной работы

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

Analy

tics &

Auto

mation

Network Management

Systems Management




Service Modeling

Process Automation

Active

Auto

mation

Network Management

Systems Management

Event Management (Consolidated)



Passiv

e A

uto

mation

Network Management

Systems Management




Service Modeling

Integrated Process

Automation

Service Level Management

Capacity Management

Service Analytics

Lig

hts

Out

IT

УнификацияСтандартизация Предсказание

Мониторинг сервисов «сверху-вниз»

Управление доступностью и производительностью приложений

Мониторинг ОС / инфраструктуры

Мониторинг СУБД / серверов приложений

Мониторингинфраструктурного ПО

ARIBA ORACLE SIEBEL

SAP BroadVision PeopleSoft BlackBerry

ORACLEMS SQL

ServerInformix DB2

Internet Info

Server 3.0Portal

MS Exchange

ServerLotus

IBM Check Point TIBCOInternet 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

http://www.hp.com/sbso/serverstorage/disk-based-backup.html






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

104

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

105

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

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

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

Визуализация

http://www.hp.com/go/bvd

http://www.hp.com/go/bvd

Визуализация

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

Централизованная

система мониторинга

ИС ПАО МТС

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

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 включая кластеры LAN\WAN, 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

BSMvirt.GW

ПМСП (агентский, HP OM)

ITOM

ПСХД (HP SE)

ITSE

БД Oracle (BSMDB)With StandBy

HP BSM БэкендBSMDP1

0600hpbsm0600hpbsmapp

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

Агент

Уровень

приложений

Уровень

бизнес - задач

Событийный

Статистический



БЕЗ агентно



Система

HP

Op

era

tio

ns

HP

Site

Sco

pe

HP

OV

PM

HP

Dia

gn

ostics

HP

RU

M

IBM

Tiv

oli

Whats

Up

Utils

HP

BP

M

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

Благодарю за внимание.

[email protected]

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

Data & Analytics