ИТ-процессы: бодры, мощны и всегда готовы!

Георгий Ованесян Руководитель направления

«Управление ИТ-процессами и инфраструктурой»

Москва, 27.11.2013

2

• Предпосылки к семинару • Управление доступностью

• Управление мощностями • Системы автоматизации

СОДЕРЖАНИЕ

1 2 3 4 5 6 7

ПРЕДПОСЫЛКИ

4 1 2 3 4 5

ТЕКУЩАЯ СИТУАЦИЯ

• Процессники • Главное – процессы • Охват знаний по системам –

естественно ограничен • Рекомендации по процессам

без учета специфики и возможностей систем

• Построение сложных процессов затруднено

• Системщики • Главное – системы • Охват знаний по процессам

– в рамках «умных книг» • Построение процессов –

по возможностям системы • Цели не достигаются,

проблемы заказчика не решаются «Построили процесс» «Внедрили систему»

5 1 2 3 4 5

ОТВЕТ

• Не «процесс» и не «система» • Управление ИТ – это всегда баланс между тремя факторами • Главное – цели и задачи конкретного случая • В проекте должен строиться процесс • В проекте необходима автоматизация

Забудьте о системах без процесса Забудьте о процессе без автоматизации

1 2 3 4 5

УПРАВЛЕНИЕ ДОСТУПНОСТЬЮ

7 1 2 3 4 5

ВИДЫ ДЕЯТЕЛЬНОСТИ

• Определение требований бизнеса к доступности (для новых и существующих услуг)

• Определение ключевых бизнес-функций, транзакций, компонент ИТ-инфраструктуры

• Разработка способов измерения и отчетности • Мониторинг и анализ тенденций • Оценка ИТ-услуг и компонент, выявление неприемлемых

уровней • Выяснение корневых причин недоступности

• Разработка и поддержка плана доступности

8 1 2 3 4 5

ПРЕИМУЩЕСТВА

• Единая точка ответственности по вопросам доступности • Разработка ИТ-услуг с учетом требований к доступности

• Уровни доступности согласованы и измеряются для поддержки SLM

• Взгляд на доступность с точки зрения заказчиков и пользователей

• Переход от исправления ошибок к улучшению качества услуг (проактивность)

• ИТ-подразделения рассматриваются как «добавленная ценность» для бизнеса

9 1 2 3 4 5

ТИПОВОЕ SLA ПО ДОСТУПНОСТИ

• Описание функционала услуги • Типовые операции

• Время решения • Время реакции

• Доступность • Часы поддержки и предоставления

Низкое Среднее ВысокоеНизкая 16 8 6

Средняя 8 6 4

Высокая 6 4 2

Влияние

Сроч

ност

ь

Время решения, часов

полное

jjiполное

i T

tTD

∑−=

∏=i

iобщая DD

Niподсистемы DD )1(1 −−=

10 1 2 3 4 5

ОШИБКИ

• Для Бизнеса (заказчика услуги): • Несоответствие параметров SLA реальным потребностям • Непрозрачный параметр «доступность» и значения в % • Недовольство качеством услуги, несмотря на 100% выполнение

SLA

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

11 1 2 3 4 5

ХОРОШИЕ ПРАКТИКИ

• Выделение интервалов • В сутках (рабочее время, нерабочее время, «серое время») • В месяце/квартале (пиковое использование, заморозка

изменений, «серое время») • В каждом интервале – свои пороги доступности

• Скажем нет «техническим окнам»!

• Суммарная недоступность услуги в месяц (часов или %) • Максимальный разовый простой услуги (часов), MTTR • Минимальное время между простоями услуги (часов), MTBF

12 1 2 3 4 5

ВЕРНЫЙ ПОДХОД

• Для Бизнеса (заказчика услуги): • Гарантии предоставления услуги в рабочее время • Гарантии корректности функционирования • Гарантии высокой производительности услуги

• Для пользователей: • Контроль времени выполнения привычных операций • Однозначное определение производительности с точки зрения

потребителей • Инциденты обнаруживаются проактивно

13 1 2 3 4 5

КАК ИЗМЕРЯТЬ ДОСТУПНОСТЬ

• Только транзакции • Пользовательские • Реальные • Синтетические • Технические • Глубокий анализ производительности

14 1 2 3 4 5

ПАРАМЕТРЫ ПРОИЗВОДИТЕЛЬНОСТИ

• Время выполнения пользовательских транзакций (мониторинг задержек на сетевом уровне)

• Время выполнения синтетических транзакций (по заранее записанному сценарию)

• Время выполнения реальных/технических транзакций (транзакции внутри приложения)

• Привязка соответствующих метрик к бизнес-функциям и бизнес-процессам

• Паттерны поведения системы в пиковые периоды

Необходимы системы APM (Application Performance Monitoring)

1 2 3 4 5 6 7

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

16 1 2 3 4 5

ВИДЫ ДЕЯТЕЛЬНОСТИ

• Управление спросом • Моделирование

• Масштабирование приложений • Контроль мощностей и производительности

• Разработка и поддержка плана мощностей

17 1 2 3 4 5

ПРЕИМУЩЕСТВА

• Прогнозирование объемов потребления услуги • Готовность ИТ-инфраструктуры своевременно поддержать

планы по развитию бизнеса • Соответствие стоимости затрат требованиям бизнеса

• Вклад в обоснование стоимости ИТ-услуг • Удовлетворенность заказчика и пользователей благодаря

контролю производительности

18 1 2 3 4 5

ОШИБКИ

• «Простая» экстраполяция • Учет пиковых нагрузок

• Отсутствие попыток управления спросом (где возможно) • Не управлять мощностями вообще

1 2 3 4 5

СИСТЕМЫ АВТОМАТИЗАЦИИ

20 1 2 3 4 5

КЛАССЫ СИСТЕМ НА РЫНКЕ

• APM – Application Performance Monitoring (Management) • CM – Capacity Management

• NPM – Network Performance Monitoring • BSM – Business Service Management (Monitoring)

• Cloud Management System

21 1 2 3 4 5

ГДЕ КАКАЯ СИСТЕМА

Процесс Система Примеры

Доступность APM, NPM Precise, Riverbed, HP

Мощность CM TeamQuest, BMC

Производительность APM, NPM Precise, Riverbed

BSM – красивая аббревиатура, не более того

22 1 2 3 4 5

ПРЕИМУЩЕСТВА APM

Минимизация рисков потерь, связанных с отказами или отклонениями в работе прикладных систем

Контроль качества работы приложений

Контроль SLA

Быстрое и эффективное определение причин деградации производительности

Встроенные рекомендации для устранения выявленных проблем (на основе лучших практик)

23 1 2 3 4 5

СПАСИБО ЗА ВНИМАНИЕ!

Георгий Ованесян Руководитель направления

«Управление ИТ-процессами и инфраструктурой» 111033, Москва, ул. Волочаевская, д.5, корп.1

+7 495 974 2274 доб. 6942, +7 495 974 2277 (факс) govanesyan@croc.ru

www.croc.ru