Вебинар «ИТ-процессы: бодры, мощны и всегда готовы!» http://www.croc.ru/action/detail/24057/ Презентация Георгия Ованесяна, руководителя направления «Управление ИТ-процессами и инфраструктурой» компании КРОК

1. ИТ-процессы: бодры, мощны и всегда готовы!
Георгий Ованесян
Руководитель направления
«Управление ИТ-процессами и инфраструктурой»
Москва, 27.11.2013

2. 2
• Предпосылки к семинару
• Управление доступностью
• Управление мощностями
• Системы автоматизации
СОДЕРЖАНИЕ

3. 1 2 3 4 5 6 7
ПРЕДПОСЫЛКИ

4. 41 2 3 4 5
ТЕКУЩАЯ СИТУАЦИЯ
• Процессники
• Главное – процессы
• Охват знаний по системам –
естественно ограничен
• Рекомендации по процессам
без учета специфики
и возможностей систем
• Построение сложных
процессов затруднено
• Системщики
• Главное – системы
• Охват знаний по процессам
– в рамках «умных книг»
• Построение процессов –
по возможностям системы
• Цели не достигаются,
проблемы заказчика
не решаются
«Построили процесс» «Внедрили систему»

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

6. 1 2 3 4 5
УПРАВЛЕНИЕ ДОСТУПНОСТЬЮ

7. 71 2 3 4 5
ВИДЫ ДЕЯТЕЛЬНОСТИ
• Определение требований бизнеса к доступности
(для новых и существующих услуг)
• Определение ключевых бизнес-функций, транзакций,
компонент ИТ-инфраструктуры
• Разработка способов измерения и отчетности
• Мониторинг и анализ тенденций
• Оценка ИТ-услуг и компонент, выявление неприемлемых
уровней
• Выяснение корневых причин недоступности
• Разработка и поддержкаплана доступности

8. 81 2 3 4 5
ПРЕИМУЩЕСТВА
• Единая точка ответственности по вопросам доступности
• Разработка ИТ-услуг с учетом требований к доступности
• Уровни доступности согласованы и измеряются
для поддержки SLM
• Взгляд на доступность с точки зрения заказчиков
и пользователей
• Переход от исправления ошибок к улучшению качества услуг
(проактивность)
• ИТ-подразделения рассматриваются как «добавленная
ценность» для бизнеса

9. 91 2 3 4 5
ТИПОВОЕ SLA ПО ДОСТУПНОСТИ
• Описание функционала услуги
• Типовые операции
• Время решения
• Время реакции
• Доступность
• Часы поддержки и предоставления
Низкое Среднее Высокое
Низкая 16 8 6
Средняя 8 6 4
Высокая 6 4 2
Влияние
Срочность
Время решения, часов
полное
j
jiполное
i
T
tT
D
∑−
=
∏=
i
iобщая DD
N
iподсистемы DD )1(1 −−=

10. 101 2 3 4 5
ОШИБКИ
• Для Бизнеса (заказчика услуги):
• Несоответствие параметров SLA реальным потребностям
• Непрозрачный параметр «доступность» и значения в %
• Недовольство качеством услуги, несмотря на 100% выполнение
SLA
• Для пользователей:
• Не контролируется быстродействие приложений и услуг
• Недовольство производительностью услуги
• Инциденты обнаруживают сами пользователи

11. 111 2 3 4 5
ХОРОШИЕ ПРАКТИКИ
• Выделение интервалов
• В сутках (рабочее время, нерабочее время, «серое время»)
• В месяце/квартале (пиковое использование, заморозка
изменений, «серое время»)
• В каждом интервале – свои пороги доступности
• Скажем нет «техническим окнам»!
• Суммарная недоступность услуги в месяц (часов или %)
• Максимальный разовый простой услуги (часов), MTTR
• Минимальное время между простоями услуги (часов), MTBF

12. 121 2 3 4 5
ВЕРНЫЙ ПОДХОД
• Для Бизнеса (заказчика услуги):
• Гарантии предоставления услуги в рабочее время
• Гарантии корректности функционирования
• Гарантии высокой производительности услуги
• Для пользователей:
• Контроль времени выполнения привычных операций
• Однозначное определение производительности с точки зрения
потребителей
• Инциденты обнаруживаются проактивно

13. 131 2 3 4 5
КАК ИЗМЕРЯТЬ ДОСТУПНОСТЬ
• Только транзакции
• Пользовательские
• Реальные
• Синтетические
• Технические
• Глубокий анализ производительности

14. 141 2 3 4 5
ПАРАМЕТРЫ ПРОИЗВОДИТЕЛЬНОСТИ
• Время выполнения пользовательских транзакций
(мониторинг задержек на сетевом уровне)
• Время выполнения синтетических транзакций
(по заранее записанному сценарию)
• Время выполнения реальных/технических транзакций
(транзакции внутри приложения)
• Привязка соответствующих метрик к бизнес-функциям
и бизнес-процессам
• Паттерны поведения системы в пиковые периоды
Необходимы системы APM (Application Performance Monitoring)

15. 1 2 3 4 5 6 7
УПРАВЛЕНИЕ МОЩНОСТЯМИ

16. 161 2 3 4 5
ВИДЫ ДЕЯТЕЛЬНОСТИ
• Управление спросом
• Моделирование
• Масштабирование приложений
• Контроль мощностей и производительности
• Разработка и поддержкаплана мощностей

17. 171 2 3 4 5
ПРЕИМУЩЕСТВА
• Прогнозирование объемов потребления услуги
• Готовность ИТ-инфраструктуры своевременно поддержать
планы по развитию бизнеса
• Соответствие стоимости затрат требованиям бизнеса
• Вклад в обоснование стоимости ИТ-услуг
• Удовлетворенность заказчика и пользователей благодаря
контролю производительности

18. 181 2 3 4 5
ОШИБКИ
• «Простая» экстраполяция
• Учет пиковых нагрузок
• Отсутствие попыток управления спросом (где возможно)
• Не управлять мощностями вообще 

19. 1 2 3 4 5
СИСТЕМЫ АВТОМАТИЗАЦИИ

20. 201 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. 211 2 3 4 5
ГДЕ КАКАЯ СИСТЕМА
Процесс Система Примеры
Доступность APM, NPM Precise, Riverbed, HP
Мощность CM TeamQuest, BMC
Производительность APM, NPM Precise, Riverbed
BSM – красивая аббревиатура, не более того

22. 221 2 3 4 5
ПРЕИМУЩЕСТВА APM
Минимизация рисковпотерь, связанных с отказами
или отклонениями в работе прикладных систем
Контроль качества работы приложений
Контроль SLA
Быстрое и эффективное определение причин деградации
производительности
Встроенные рекомендации для устранения выявленных проблем
(на основе лучших практик)

23. 231 2 3 4 5
СПАСИБО ЗА ВНИМАНИЕ!
Георгий Ованесян
Руководитель направления
«Управление ИТ-процессами и инфраструктурой»
111033,Москва,ул. Волочаевская,д.5,корп.1
+7 495 9742274доб. 6942,+7 495974 2277(факс)
govanesyan@croc.ru
www.croc.ru