ГЛАВНАЯКОМПАНИЯРЕШЕНИЯТЕХНОЛОГИИПРОДУКТЫПОДДЕРЖКАМЕТОДИКАКЕЙСЫ

Тел: +7 (495) 363-59-15

Зажги персонал. Включи клиентов

Когда экстенсивный путь развития становится невозможен, переходят к интенсивному. Это относится и к ИТ. Если на масштабные инфраструктурные проекты бюджета не хватает, подумайте об улучшении качества работы критически важных бизнес-приложений. Другими словами – внедряйте Application Performance Management, Quality of Experience Management, или в терминах ITIL - Service Level Management. Кризис – хорошее время для наведения порядка и оптимизации затрат.

Чтобы что-то улучшить, нужен критерий, как должно быть (целевая функция). Если для потоковых приложений (передача голоса и видео) в качестве такого критерия обычно используется MOS (Mean Opinion Score), то для транзакционных приложений (работающих по TCP) - APDEX (Application Performance InDEX). Сегодня методика APDEX является стандартом de facto для оценки производительности бизнес-приложений «глазами пользователей».

Измеряем APDEX

Рисунок 1. Как измеряется APDEX

APDEX – это число от 0 до 1, характеризующее степень удовлетворённости пользователей производительностью бизнес-приложения. Если APDEX находится в диапазоне 0.94 -1.0, то считается, что производительность приложения отличная. Диапазон 0.85-0.94 соответствует оценке хорошо; 0.7-0.85 - удовлетворительно, 0.5-0.7 - плохо, менее 0.5 - неприемлемо.

Кратко методика APDEX заключается в следующем:

1. Измеряем значения метрики, характеризующей скорость работы бизнес-приложения. Как правило, это время реакции бизнес-приложения (END-TO-END RESPONSE TIME). Но могут использоваться и другие метрики, в том числе характеризующие QoS и здоровье ИТ-Инфраструктуры.
2. Результаты измерений делим на три группы. В первую группу относим измерения, значения которых меньше порогового значения T, соответствующего комфортной работе пользователей. Число таких измерений – это значение переменной «Satisfied count»: пользователи удовлетворены. Во вторую группу должны попасть измерения, значения которых больше T, но меньше 4*T. Число таких измерений – это значение переменной «Tolerating count»: пользователи не очень довольны, но готовы терпеть. Все остальные измерения должны попасть в третью группу – «Frustrated»: пользователи жалуются. Общее число измерений – это значение переменной «Total samples».
3. По формуле, показанной на рис.1, измеряем значение APDEX.

Таким образом, измерение APDEX сводится к решению двух задач:

• Измерение времени реакции бизнес-приложения (измерению END-TO-END RESPONSE TIME).
• Определение значения Т, соответствующее комфортной работе пользователей.

Измеряем время реакции бизнес-приложения

Существует много способов измерения время реакции бизнес-приложений. Иногда измерения выполняются на сервере. Для этого на сервер устанавливается специальный программный модуль. Это не всегда возможно, но это самый экономичный способ измерения времени реакции. Однако у этого способа есть существенный недостаток - процесс измерения может оказывать негативное влияние на производительность и надежность сервера.

Наиболее распространенным способом является измерение времени реакции приложений методом анализа сетевого трафика. Именно такой способ используется практически во всех продуктах категории Real User Monitoring (RUM). Ведущими игроками на здесь являются HP, Oracle, BMC, CA, IBM. Но это одновременно и самый дорогой способ. Для его реализации необходимо в режиме реального времени из сетевого трафика извлекать информацию о работе прикладного уровня сети. Еще одно ограничение - продукты категории RUM часто «не понимают» отечественных бизнес-приложений.

Еще одним способом измерения времени реакции является использование специальных агентов на клиенте. Этот способ занимает промежуточное положение между измерениями на сервере и анализом сетевого трафика. Он безопаснее, но несколько сложнее, чем измерения на сервере. При этом он существенно более экономичен, чем анализ сетевого трафика. Именно такой подход положен в основу отечественного решения Пятый Уровень. Ключевым элементом Пятого Уровня является EPM-Agent Plus -Windows-служба, устанавливаемая на компьютерах пользователей, которая в автоматическом режиме отслеживает все действия пользователя при работе с бизнес-приложением, запросы бизнес-приложения к MS Windows, возникающие при этом ошибки и т.п. Чтобы лучше понять, как это работает на практике, см. публикацию Пятый Уровень для АБС Diasoft FA#.

Основным ограничением Пятого Уровня является возможность применения только для бизнес-приложений, работающих под управлением MS Windows. Основным достоинством – низкая стоимость и возможность интеграции с любыми системами сетевого управления, поддерживающими SNMP. Дело в том, что измеренное время реакции бизнес-приложения EPM-Agent Plus может отдавать по SNMP.

Определяем значение Т, соответствующее комфортной работе пользователей

Рисунок 2. Определяем пороговое значение Т.

О том, как измерять значение Т, в методике APDEX ничего не сказано. Некоторые отечественные консультанты предлагают не измерять Т, а принимать его волевым решением. Например, CIO говорит, что T должно составлять 2 секунды или 10 секунд. Почему? Никто не знает, CIO видней. На мой взгляд такой подход противоречит как духу, так и букве APDEX, поэтому неприемлем.

Для определения Т предлагаю использовать Кнопку Оценки Производительности ИТ-Сервисов. Кратко идея такого подхода заключается в следующем:

1. Устанавливается система измерения времени реакции бизнес-приложения, работающая в постоянном режиме. Лучше всего для этого использовать имеющуюся систему сетевого управления, дополненную соответствующим инструментарием, например продуктом EPM-Agent Plus (требуется специальная лицензия).
2. Из наиболее адекватных пользователей бизнес-приложения создается фокус группу. Участникам фокус группы устанавливаются "красные кнопки". Как привило, это специальное USB-устройство (см. Рисунок 3), хотя можно использовать и комбинацию клавиш. Участников фокус группы при «зависании» бизнес-приложения сверх допустимого с их точки зрения времени, должны нажать «красную кнопку». Просто нажать и всё. Это не составит большого труда, т.к. они будут нажимать «красную кнопку» только в те моменты времени, когда приложение «висит» и они все равно вынуждены ждать (пока оно «отвиснет»).
3. Фиксируется время реакции бизнес приложения в те моменты времени, когда пользователи нажимают «красную кнопку». По методике APDEX это значение соответствует 4*T (пользователь жалуется). Таким образом, разделив полученное значение на 4, вы узнаете пороговое значение Т, соответствующее комфортной работе пользователей.

Рисунок 3. «Красная кнопка» - USB-Устройство.

Поскольку значение T определяет условия вычисления APDEX, оно должно присутствовать в обозначении индекса. Одним из способов такого присутствия является указание его в квадратных скобках после слова APDEX. Например, выражение APDEX [30] = 0.79 будет означать, что значение 0.79 измерено для Т, которое составляет 30 секунд.

APDEX - основа Service Level Management

Использование методики APDEX обеспечивает ИТ-Службу всем необходимым для управления качеством предоставления ИТ-Услуг в соответствии с ITIL ver.3. Предположим, в компании используется критически важное бизнес-приложение ALFA, ключевой транзакцией которого является Выдача Потребительского Кредита (ВПК). Тогда алгоритм управления качеством предоставления ИТ-Услуг может быть приблизительно следующим:

1. Определяются требования Бизнеса к качеству ИТ-Услуги. В терминологии ITIL - Service Level Requirements (SLR). Например, Бизнес может потребовать, чтобы время выдачи потребительского кредита не превышало 10 минут. В терминах ИТ специалиста - значение метрики «Время Выполнения Транзакции ALFA/ВПК» не должно превышать 10 минут. Назовем это время Transaction Time.
2. На основании SLR определяются пороговые значения метрик, за которые отвечает ИТ-Служба. В терминологии ITIL - Service Level Objectives (SLO). Очевидно, что Transaction Time состоит из двух частей: времени работы системы (System Time), за которое отвечает ИТ-Служба и времени работы пользователя (User Time), за которое отвечает HR-Служба. Поэтому Бизнес, ИТ-Служба и HR-Служба должны прийти к соглашению, какая доля времени Transaction Time должна приходиться на System Time, а какая на User Time. Предположим, они пришли к соглашению, что User Time не должно быть более 9.5 мин, а System Time – 30 сек. Это означает, что SLO=30 сек. В терминах APDEX SLO - это значение T (Threshold) в формуле вычисления APDEX [T].
3. На основе SLO определяется нижняя граница качества услуг, которая будет прописана в SLA. В терминологии ITIL такая граница называется Service Level Targets (SLT). В терминах APDEX - это значение метрики APDEX [T]. Например, Бизнес и ИТ-Служба могут прийти к соглашению, что нижняя граница метрики Apdex system [30] - 0.9.
4. Между Бизнесом и ИТ-Службой заключается соглашение о качестве предоставляемых услуг. В терминологии ITIL - SLA (Service Level Agreement). Например, между ИТ-Службой и Бизнесом может быть заключено соглашению, что по рабочим дням с 9-00 до 18-00 значение метрики Apdex system [30] не должны быть ниже 0.9. Контроль соблюдения такого соглашения – это основа управления качеством предоставления ИТ-Услуг.

Но, наверное, самую большую пользу методика APDEX принесет при оказании услуг ИТ Аудита (аудит здоровья ИТ-Инфраструктуры и производительности бизнес-приложений). Измерить значения метрик , характеризующих здоровья ИТ-Инфраструктуры и производительность бизнес-приложений, обычно, особого труда не составляет. Значительно сложнее адекватно оценить измеренные значения, сделать на основе полученных оценок правильные выводы, и убедительно их обосновать. Для этого сложно придумать что-то лучшее, чем APDEX. Думаю, для этого APDEX и был придуман. Уверен, что использование APDEX при оказании Профессиональных Услуг – это правильно, и поможет пережить кризис. Крепитесь :).