Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

Метрики здоровья ИТ-инфраструктуры, пороговые значения и пользователи ИТ-сервисов

 

image

Тема этой статьи – определение пороговых значений метрик здоровья ИТ-инфраструктуры, соответствующих комфортной работе пользователей ИТ-сервисов. Я рассмотрю, как сделать так, чтобы пороговые значения метрик здоровья (производительности, доступности и т.п.) ИТ-инфраструктуры соответствовали тому, что пользователи считают комфортной работой с ИТ-сервисом, а также зачем всё это нужно.
Статья предназначена для провайдеров ИТ-сервисов и всех, кто хочет настроить мониторинг ИТ-инфраструктуры и/или производительности и доступности ИТ-сервисов, но не знает, как это сделать.

Введение

Цель любого мониторинга – узнавать о сбое до того, как он скажется на работе пользователей, клиентов и т.п. Для того чтобы система мониторинга вовремя обнаружила сбой и оповестила о нём системного администратора или службу поддержки, необходимо:

  1. Знать, какие метрики необходимо контролировать.
  2. Правильно установить пороговые значения контролируемых метрик.

Ответы на эти вопросы могут быть как простыми, так и сложными, и зависят от того, что ИТ-служба понимает под сбоем.

Некоторое время назад компания HP предложила классифицировать ИТ-службы по уровню зрелости: поставщик ИТ-инфраструктуры, провайдер ИТ-сервисов, бизнес-партнёр. Воспользуемся предложенной классификацией и рассмотрим, что является сбоем для первых двух случаев – поставщика ИТ-инфраструктуры и провайдера ИТ-сервисов, а также как в этих случаях определяются метрики и устанавливаются пороговые значения. Третий случай (бизнес-партнёрство) по причине его сложности и глобальности рассмотрим в одной из следующих статей.

Уровень ИТ-службы Что такое сбой
Поставщик ИТ-инфраструктуры В ИТ-инфраструктуре что-то неисправно
Провайдер ИТ-сервисов Пользователи не могут использовать ИТ-сервис для выполнения своих обязанностей
Бизнес-партнёр Остановился или тормозит бизнес-процесс

Сбой для поставщика ИТ-инфраструктуры: В ИТ-инфраструктуре что-то неисправно

В простейшем случае сбой – это неисправность в ИТ-инфраструктуре. Информация о метриках в этом случае содержится в MIB (Management Information Base). Пороговые значения устанавливаются тремя способами:

  1. Если метрика измеряется в процентах (утилизация, доступность и т.п.), то методом здравого смысла.
  2. Для большинства значимых метрик есть референтные значения, содержащиеся в рекомендациях производителей ПО и железа. Значительную часть этой информации мы систематизировали и результаты можно найти на сайте http://www.you-expert.ru, раздел «Экспертизы».
  3. Если п.1 и п.2 невозможны, то используется Метод Базовых Линий.

Метод Базовых Линий

Базовая Линия – это метрика или набор метрик, характеризующих нормальную (обычную) работу ИТ-инфраструктуры. Чтобы построить Базовую Линию, нужно статистически обработать результаты измерений, полученные за длительный период времени, например, за месяц, и получить усреднённое значение, которое принимается за норму. Значение, превышающее (по модулю) норму, например, на 10%, 30% или 50% (определяется интуитивно) — принимается в качестве порогового значения, соответствующего оценке «плохо».

Существует много способов вычисления и видов представления Базовых Линий. В простейших системах мониторинга это может быть среднее значение метрики, отображаемое в виде прямой линии, пересекающей график измеряемой метрики. В профессиональных системах это несколько статистических оценок (как правило, перцентиль), привязанных ко времени. Это означает, что значения Базовой Линии, например, в 7-00 и в 11-00 – это два разных значения. На Рисунках 2 и 3 показаны примеры Базовых Линий, автоматически вычисляемых продуктами ProLAN. Базовая Линия 20 оценивает метрики в 20-минутных интервалах и имеет вид таблицы. Базовая Линия 60 оценивает метрики в 60-минутных интервалах и имеет вид трёх графиков: среднее значение, перцентиль 75 (отбрасывается 25% худших значений), перцентиль 90 (отбрасывается 10% худших значений).

image
Рисунок 2. Базовая Линия 20.

image
Рисунок 3. Базовая Линия 60.

Сбой для провайдера ИТ-сервисов: Пользователи не могут использовать ИТ-сервис для выполнения своих обязанностей

По сравнению с неисправностью в ИТ-инфраструктуре этот случай более сложный и более интересный. Значимость его определяется тем, что доступность ИТ-сервисов – это основная составляющая SLA (Service Level Agreement).

Часто, чтобы упростить себе жизнь, ИТ-служба трактует доступность ИТ-сервиса как доступность всех задействованных компонентов ИТ-инфраструктуры. Такое упрощение простительно небольшому аутсорсеру (de facto поставщику ИТ-инфраструктуры), но не зрелому поставщику ИТ-сервисов, т.к. это объективно неправильно. Классический пример – ip-телефония. Все компоненты ИТ-инфраструктуры, поддерживающие связь между абонентами, могут быть исправны и технически функционировать, но качество связи при этом ужасно настолько, что пользоваться сервисом невозможно (звук булькает, изображение замирает). Поэтому доступность ИТ-сервиса – это не техническая метрика, и для её измерения недостаточно пинговать оборудование.

Нужно либо определить, при каких значениях каких метрик сервис работает хорошо, а при каких – не очень, либо замерять время реакции бизнес-приложений(end-to-end response time).

Рассмотрим оба способа подробнее.

Первый способ – измерять время реакции бизнес-приложений (end-to-end response time). Для того чтобы измерять время реакции бизнес-приложений, нужны специальные метрики и специальных измерительные средства. Можно использовать GUI-роботы (мы используем AutoIT, интегрированный со SLA-ON Probe), анализаторы сетевых протоколов (например, Observer Suite компании Network Instruments), программные агенты, устанавливаемые на клиенте или сервере (например, Пятый Уровень). Пороговые значения устанавливаются либо методом здравого смысла, либо методом базовых линий.

Второй способ – установить соответствие, когда, при каких значениях какой метрики сервис работает хорошо (пользователь может им пользоваться для достижения своих целей, выполнения своих обязанностей), а когда плохо (пользоваться сервисом невозможно). В этом случае контролируется не время реакции бизнес-приложений, а технические метрики, от которых оно зависит. Мониторинг существенно упрощается и удешевляется, т.к. вместо плохо масштабируемых GUI-роботов или дорогих анализаторов можно использовать обычную, даже бесплатную, систему мониторинга.

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

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

Для потоковых приложений (голос, видео) задача приведения в соответствие пороговых значений технических метрик и пользовательского восприятия (или удобства пользования ИТ-сервисом) давно решена. Все, кто работают с оборудованием Cisco (и не только), знают, что данное оборудование позволяет контролировать субъективные метрики MOS (Mean Opinion Score) и ICPIF, которые не измеряются, а вычисляются (в зависимости от типа кодека) из технических метрик: jitter, delay, packet loss (которые собственно и измеряются). Для этого используется модель R-Value. Выдержки из соответствующих стандартов и приказа Мининформсвязи №113 есть в поддерживающих их Экспертизах и другую информацию по теме можно найти на сайте www.you-expert.ru.

Но для транзакционных приложений, работающих поверх TCP, а не UDP, подобных стандартов нет. Это значит, что нам придётся самим устанавливать соответствия между значениями технических метрик и восприятием пользователей. Для этого предлагается использовать методику APDEX (см. ниже) и решения ProLAN.

image
Рисунок 4. Работа бизнес-приложения АЛЬФА.

Предположим, что есть два офиса, разделённых каналом связи. При этом сервер приложений АЛЬФА находится в одном офисе, а сами пользователи приложения АЛЬФА в другом, см. Рисунок 4. Название АЛЬФА, конечно, условное. Допустим также, что у нас есть система мониторинга ProLAN SLA-ON (или какая-то другая), позволяющая измерять технические метрики здоровья маршрутизаторов, сервера приложений, канала связи, в частности, jitter, delay, packet loss.

И вот мы озаботились тем, какие значения jitter, delay, packet loss нам нужно прописать в SLA c оператором связи, чтобы пользователи бизнес-приложения АЛЬФА работали комфортно. Они будут также введены в нашу систему мониторинга как пороговые значения, чтобы системный администратор или служба поддержки при их превышении могли сразу узнавать, что произошёл сбой (т.е. пользователи лишены возможности нормально выполнять свои обязанности, используя предоставляемый сервис – бизнес-приложение АЛЬФА).

image
Рисунок 5. Сбор метрик здоровья ИТ-инфраструктуры, информации о работе пользователей и случаях неудовлетворительной работе приложения АЛЬФА

1. Для решения этой задачи установим на компьютеры наиболее адекватных пользователей приложения АЛЬФА Красную Кнопку (USB-устройство, программу SelfTrace, программу EPM-Agent Plus). Программа SelfTrace будет автоматически измерять, когда пользователи работают с приложением АЛЬФА (именно работают, т.е. нажимают клавиши на клавиатуре и двигают мышью, а не просто приложение открыто, а сотрудник пьёт кофе в другом отделе), и передавать результаты в консолидированную базу данных, см. Рисунок 5.

2. Система мониторинга настраивается на сбор метрик jitter, delay, packet loss, которые также автоматически записываются в консолидированную базу данных, и привязываются к общей временной шкале.

3. Пользователи приложения АЛЬФА инструктируются, что в тот момент, когда, с их точки зрения, они не могут комфортно пользоваться приложением АЛЬФА для выполнения своих обязанностей, они должны нажать «красную кнопку». Результаты нажатия кнопок тоже автоматически передаются в консолидированную базу данных и также привязываются к общей временной шкале. Таким образом, в консолидированной базе данных значения метрик jitter, delay, packet loss, периоды времени использования приложения АЛЬФА и сообщения о неудовлетворительной работы приложения АЛЬФА оказываются привязаны к одной общей временной шкале.

4. Переходим собственно к вычислению пороговых значений. Запускаем специальное приложение (скрипт), которое обращается к консолидированной базе данных и вычисляет средние значения метрик jitter, delay, packet loss:

  1. в те моменты времени, когда пользователи АЛЬФА жаловались на ИТ-сервис (нажимали кнопку);
  2. в те моменты времени, когда, по мнению пользователей, c АЛЬФОЙ было всё нормально.

Примечание. Партнёры, использующие коммерческие продукты ProLAN, могут получить этот скрипт бесплатно.

В результате для каждой метрики jitter, delay, packet loss у нас будет 2 пороговых значения:

  1. jitter_satisfied и jitter_frustrated
  2. delay_satisfied и delay_frustrated
  3. packet loss_satisfied и packet loss_frustrated

В соответствии с методикой APDEX метрики с суффиксом frustrated – это четырёхкратное пороговое значение соответствующей метрики. То есть если значение jitter_frustrated cоставило 200 микросекунд, то пороговое значение метрики jitter, соответствующее комфортной работе пользователей АЛЬФА, составляет 50 микросекунд.

image
Рисунок 6. 2, 7, 11, 12 – значения jitter не учитываются (пользователь в это время не работал в приложении АЛЬФА). 5, 14 – учитываются для вычисления jitter_frustrated. 1, 3, 4, 6, 8, 9, 10, 13, 15 – учитываются для вычисления jitter_satisfied.

Задача решена. Мы получили пороговые значения, превышение которых означает сбой с точки зрения пользователя, а значит и провайдера ИТ-сервиса (нарушение комфортного режима работы для пользователей ИТ-сервиса).

Попутно решается ещё одна важная задача: определяем, какие метрики значимы с точки зрения производительности данного сервиса. Например, если выяснится, что значения jitter_satisfied и jitter_frustrated близки, то метрика jitter для комфорта работы с приложением АЛЬФА (для его производительности) не является значимой. К метрикам, характеризующим работу IP-канала, это не очень применимо. А вот для метрик здоровья маршрутизаторов, серверов приложений – это важно.

Методика APDEX

image
Рисунок 7. Методика APDEX.

В заключение несколько слов о методике APDEX.

APDEX (Application Performance Index) – это стандарт, количественно определяющий удовлетворённость пользователей производительностью приложения. Методика APDEX заключается в следующем. Все результаты измерений (например, результаты измерений времени реакции бизнес-приложения) разделяются на три группы.

В первую группу попадают измерения, значения которых меньше порогового значения T, соответствующего комфортной работе пользователей. (Именно его нам и нужно определить.) Число таких измерений – это значение переменной Satisfied count: пользователи удовлетворены.

Во вторую группу попадают измерения, значения которых больше T, но меньше 4*T. Число таких измерений – это значение переменной Tolerating count: пользователи не очень довольны, но готовы терпеть.

Все остальные измерения заносятся в третью группу – Frustrated: пользователи жалуются. Общее число измерений – это значение переменной Total samples. Значение APDEX вычисляется по формуле, приведённой на Рисунке 7.

Post scriptum

Удивительный факт. Объём продаж систем мониторинга в огромной России почти в 30 раз меньше, чем в маленькой Германии. За цифру 30 не поручусь, но порядок точно такой. Мне долго было не понятно, с чем это связано, пока недавно у меня не состоялся разговор с ИТ-директором очень крупного ритейлера. Я спросил, чем они мониторят ИТ-инфраструктуру. Он назвал один из продуктов Open Source. Я спрашиваю: «Ну и как, устраивает?» «Да, – говорит. – Инженеры довольны. Пользователи только не довольны, периодически жалуются, что у них всё тормозит, и письма иногда не приходят. А по нашим данным всё работает нормально. Не знаешь, что это может быть?»

Комментарии (11)

  • Аватар

    Яковлев Андрей Михайлович [swtws], 09 июня 2013, 09:15

    0
    Много букв. Постскриптум убил. Этот ритейлер до того беден, что на HP не раскошелилося? Просто качество продуктов высоко, но ценник кусается. HP OV  фактически нарицательное слово.
  • Аватар

    Пустовит Андрей [apustovit], 09 июня 2013, 12:43

    0

    Прямо слезы на глаза наворачиваются, когда читаешь как open source не справляется с со работой. Систему назовите, которую ритейл крупный использует. Может и подскажем тамошнему ИТ-директору "что это может быть".

    P.S. Согласен с Андреем Яковлевым -- начали за здравие, а закончили за упокой.

    • Аватар

      Meshkov Aleksandr [ameshkov], 10 июня 2013, 19:02

      0
      Есть ip-канал, соединяющий два офиса. По каналу работают приложение 1С:Предприятие 8.1 (хотите - через терминальный сервер, хотите - нет). Нужно определить, какой максимальный TCP SAA Link Round Trip Latency (задержка на tcp) критичен с точки зрения комфортной работы пользователя приложения 1С. Как будете определять? Если можно, ответьте конкретно и по существу.
      • Аватар

        Пустовит Андрей [apustovit], 10 июня 2013, 19:35

        1

        Zabbix.

        1. Тригеры для мониторинга пропускной сопсобности канала между двумя граничными маршрутизаторами, которые кормят два офиса. Снимаем по SNMP. Что интересует - скорость upload и download, снимаем показания каждые 30 секунд например. (Что такое zabbix, триггер, как они настраиваются я надеюсь ни Вам, ни ИТ-директору ритейла объяснять не надо).

        2. Нас интересует также потребление загрузки канала работающей 1С. Первое, что приходит в голову - разработать типовые синтетические тесты для конкретной компании-клиента. Если база плоская, то как нагружается канал при формировании отчета, остатков и т.д. На одно лицо. Уже есть идеализированная информация по нагрузке. Но. Нас интересует реальная ситуация. Мне интересно, что происходит, когда пользователь говорит, что у него "тормозит 1С". Тогда я тригерую самих пользователей (их аплоад/даунлоад), плюс я могу попросить zabbix показывать мне счетчики производительности, информацию по нужнім мне процессам. Подробнее https://www.zabbix.com/documentation/ru/2.0/manual/config/items/itemtypes/zabbix_agent/win_keys.

        Все это я скормлю zabbix-серверу на стороне пользователей, чтобы не портить данные по загрузке канала. После анализа, я получу искомое значение (как и Вы собственно, вырвав руки мальчику, который качает "Игры престолов", работает в 1С, и жмет красную кнопку когда ему не комфортно).

        Это первое, что пришло на ум. Конкретно?

        • Аватар

          Meshkov Aleksandr [ameshkov], 10 июня 2013, 22:14

          0
          Больше вопросов нет, спасибо.
          • Аватар

            Пустовит Андрей [apustovit], 10 июня 2013, 22:26

            0
            Но Вы не ответили на мой вопрос - какая конкретная опен-сорс система мониторинга была у страдающего ритейла? Мне просто для статистики.
              • Аватар

                Яковлев Андрей Михайлович [swtws], 11 июня 2013, 22:57

                -1

                Это в международной практике именуется /dev/hands. Опен системы куды мощнее имеющих вендорскую заточку под себя, если вендор не "озаботился" влепить специфические "пропиеритарные" (кавычки, так как вендорские "фишки" - свои вумные реализации публичных стандартов, зачастую неудачные) особенности. Некоторые платные системы лихо работают в гетерогенной среде, но тут ценник того.

                Кстати, пару "высеров" помню от MS: MS Kerberos, несовместимый с ISC Kerberos и шифрованный CIFS (SMB) протокол, несовместимым с общепринятым в RFC. Все успешно подохло или просто не используется. Если говорить о качестве ПО, есть два заблуждения:

                1. СПО разрабатывается кучкой энтузиастов, бесплатно и поэтому не может иметь качества как вендорское.

                Большая часть разбработчиков того же ядра Линукс получают за это деньги.  Спонсоры (RedHat,IBM,SuSE,Google и др) торгуют не софтом, а решениями, главным образом своими железочками от планшетика или смартфончика до суперкомпьютеров. Вообще разработчики железок, активно используют СПО, т.к соблюсти лицензии просто - опубликовать свои наработки. От этого Cray XK-7 Titan никто не подделает.

                2. Пропиеритарное ПО качественнее.

                "Ограниченная гарантия" в лицензии лихо защищает от судебных преследований. А так как продукт должен выйти с низкой себестоимостью, нужен таджик или кто там для разработки :) Притом широко ходит принцип "новой, оригинальной упаковки", то есть новая "еще более" содержит порт старых багов и новые.

                 

  • Аватар

    Ланцев Андрей [Sansey], 10 июня 2013, 18:26

    0

    При всей логичности статьи не могу не отметить, что компания ПроЛАН, как обычно, опустила самое интересное, что волнует нас, простых ИТ-аутсорсеров, которые по идее и должны покупать и применять эту и другие системы, а именно - цена и побочные эффекты.

    Ну про цену меня ессно отправят на сайт компании (надо же массу сайта набирать).

    А вот про побочные эффекты я постоянно задаю вопросы:)) Лично меня напрягают такие фразы "метод здравого смысла" (мой опыт общения на смарте показывает, что среди айтишников это очень растяжимое понятие:)), "адекватный пользователь" (ну тут поржал, спасибо:)), "удовлетворенность пользователя" (а если когда он красную, прости господи, кнопку нажал считая, что тормозит приложение Альфа, а на самом деле сам комп тупанул - как тут метрика выстроится?).

    В общем автор правильно заметил в начале статьи, что продукт не для малого ИТ-бизнеса. Но нас тут таковых большинство, так может пора уже зарубить себе на носу, что нецелевая тут аудитория?

  • Аватар

    Дьяков Андрей Владимирович [Dru], 13 июня 2013, 09:47

    0

    Статья интересная и, конечно, жду продолжения про бизнес-партнеров. Безусловно есть над чем задуматься и проанализировать свою ситуацию с позиций автора.

    Но! установим на компьютеры наиболее адекватных пользователей приложения АЛЬФА Красную Кнопку - в наших реалиаях мы получим дидос пользователей.

    Пользователи только не довольны, периодически жалуются, что у них всё тормозит - в большинстве случаев сугубо финансовый вопрос. Смена парка, внедрение терминальных серверов под "типовые" отделы. Но ведь конечник как всегда хочет, чтоб все максимально дешево...

  • Аватар

    Юдицкий Сергей [Sergey.Yuditsky], 13 июня 2013, 15:22

    0
    Относительно дидос пользователей ... . Этот вопрос подробно рассмотрен в описании решения Красная Кнопка (www.911.prolan.ru) в разделе "Защита от дурака" В данной статье речь вообще совершенно  о другом ...