Портал №1 по управлению цифровыми
и информационными технологиями

Зачем доступность услуг считать в процентах?

Последнее время я все больше укрепляюсь в давно блуждающей в моей голове и довольно еретической мысли: классический показатель доступности малопригоден для измерения и оценки доступности ИТ-услуг в реальном мире. И в ряде случаев от него можно легко отказаться. Эти случаи касаются в первую очередь измерения доступности услуг типа «ИТ-обеспечение бизнес-процессов» (фактически речь идет об ИТ-доступности бизнес-процессов). Попробую обосновать и буду рад услышать возражения.

Полагаю, всем читателям портала знакома формула:

Availability = (AST – DT)/AST,

где AST – согласованное время предоставления услуги, DT – сумма простоев за период.

А также, вероятно, знакомы сложности ее применения:

Первая сложность связана с обсуждением показателя. Доступность определена как 99,9%. Вроде неплохо. Но 0,1% в год равен почти 9 часам. А в месяц – это почти 45 минут. А в неделю – чуть более 10 минут. Так какие 99,9% имел в виду заказчик? А сервис-провайдер?

Однако значительно более существенен следующий нюанс: показатель довольно неточно отражает негативное влияние на бизнес. Что если все без малого 9 часов за год случились разом? Или услуга становилась недоступна потребителям по две минуты, но 15 раз за один день? Как это будет выражено в процентах?.. Поэтому, например, ITIL вводит такие показатели, как MTRS, MTBF, MTBSI.

Однако предлагаю вернуться в начало координат и задаться вопросом, а зачем мы вообще вводим показатели доступности? Почему бизнес предъявляет требования к доступности услуг? Почему сервис-провайдер должен обеспечивать высокую доступность и отчитываться по ее фактическим значениям? Ответ прост: бизнес несет потери вследствие простоев ИТ-услуг. Значит, идеальным для бизнеса показателем доступности, вероятно, была бы метрика «Потери вследствие простоев ИТ-услуг»?

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

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

Но, конечно, произвести расчет такой метрики сложно, порой невозможно. Таким образом, мы должны определить другие показатели, не забывая о том, что в совокупности они должны нести информацию о бизнес-влиянии (фактическом или потенциальном).

От чего зависят потери бизнеса вследствие простоев?

  1. Чем меньше за отчетный период услуга была в uptime, тем больше потери. Введем показатель «Суммарное время простоев».
  2. Чем дольше разовый простой, тем больше потери. Нередко потери не являются постоянной во времени величиной и зависят от длительности прерывания экспоненциально. В первый отрезок времени ущерб складывается из несовершенных транзакций, потерь продуктивности персонала и затрат на восстановление, но с определенного момента длительный простой угрожает бизнесу штрафами, санкциями, уроном репутации и так далее. Введем показатель «Максимальный разовый простой».
  3. Ряд бизнес-процессов, напротив, «чувствительны» не к единичным длительным простоям, а к частым прерываниям. Это особенно важный фактор для процессов, в рамках которых происходят длительные вычисления, которые в случае прерывания требуется перезапускать. Таким образом, должно быть обеспечено как можно меньшее количество прерываний за период. Введем показатель «Количество нарушений».

Альтернативной (или дополнительной) метрикой, отражающей тот же аспект, но с акцентом на периоде спокойной работы пользователей, может быть показатель «Минимальная (или средняя) продолжительность работы без нарушений».

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

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

От представленных метрик можно легко перейти к известным MTRS, MTBF, MTBSI и, конечно, классическому показателю доступности. Но, на мой взгляд, предложенный набор скажет заказчику и сервис-провайдеру несколько больше о бизнес-влиянии нарушений ИТ-доступности. Или нет?

Отчаянно нуждаюсь в возражениях. Почему от классического показателя доступности услуги, выраженной в процентах, ни в коем случае нельзя отказываться? Есть ли такой показатель в ваших отчетах? О чем и кому он говорит?

«VAP: Построение системы KPI для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

Комментариев: 10

  • Алексей

    >>  Почему от классического показателя доступности услуги, выраженной в процентах, ни в коем случае нельзя отказываться?

    Можно. Но этот показатель – "попса". Он повсюду, к нему привыкли.
    Поэтому отказаться можно там, где Бизнес может чётко сформулировать одну (или все три) из предложенных вами метрик. Ну а если SLA носит "статусный" характер, то вполне себе подойдёт. Это даже не вдаваясь в подробности, как считается этот %, это отдельная тема 🙂

    • Но этот показатель — "попса". Он повсюду, к нему привыкли. 

      отказаться можно там, где Бизнес может чётко сформулировать одну (или все три) из предложенных вами метрик

      Алексей, очень метко 🙂 

      Но тогда получается, что отказ от % в пользу чего-то понагляднее — это вопрос времени или зрелости, то есть времени.

    • Чернов Антон

      Зачем бизнесу формулировать MTRS, MTBF для ИТ ? Я не совсем понимаю? 
       

  • Имею несколько наивное мнение, что если посмотреть в корень “нужности” такого показателя как доступность бизнесу, к чему нас подталкивает Павел, то можно говорить о следующем:
    Если у нас, как у поставщика услуги, есть возможность размышлять о том, насколько терпимо будет относиться бизнес к количеству или длительности простоев, то это попросту означает, что данная услуга для бизнеса не очень важна. Этот факт не отменяет потребность как-то эту доступность измерять, но создавать сложные структуры измерения и управления этим параметром может быть избыточным и затратным упражнением.
    В сегодняшний день триумфа виртуализированной инфраструктуры сам факт наличия простоев является показателем некачественной работы сервис-провайдера. Бизнес не заботит сложность услуги, и не должна заботить. Примитивная метрика будет достаточной. IMHO.

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

    • Андрей, мне нравится твой комментарий и я бы поднял обе руки в его поддержку, если бы речь шла о серверах, кластерах, базах данных и других компонентах услуги. Или, например, услугах типа "Предоставление ИТ-ресурса / доступа к ИТ-ресурсу" (доступ к Интранет-порталу, IP-телефония, рабочая станция, доступ в Интернет, печать, или, скажем, "1С: Предприятие"). Понятно, что проценты доступности значат в этом контексте. Понятно, что отклонения начиная с первого знака после запятой, несут вполне понятный сигнал. И незачем усложнять.

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

      Виртуализированная инфраструктура практически исключает недоступность виртуальных серверов – верно, но не исключает задержки в исполнении бизнес-процессов, которые опираются на n-систем, включают работу с общими базами данных, вызов удаленных процедур, парочку веб-сервисов и интеграционную шину. С каждым из этих компонентов могут быть полные 99 и 9 в периоде, что, тем не менее, не гарантирует выполнение всех бизнес-операций. И, как ты сказал, бизнес не заботит сложность услуги.

  • Владимир

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

  • Илья Рунов

    Предпочту согласиться с Андреем Труфановым, что "Примитивная метрика будет достаточной". Если, конечно, не очень интересует некий практический результат (или планирование и отслеживание его улучшения) в виде сокращения затрат.

    Предпочту согласиться с Павлом Дёминымм, что некого практического результата (например в виде сокращения плановых и фактических потерь бизнеса) сложно достичь с использованием %. Правда возникает вопросы

    * Где взять тех представителей бизнеса, которые могут оперировать понятиями математической статистики для расчета плановых\фактических потерь за период.

    * Где взять ресурсы и политическую волю внутри Исполнителя (ДИТ, видимо, или внешнего облачного поставщика), которым расчеты на основе показателей из картинки поста более выгодны, чем туманный %.

    В роли Заказчика (внутреннего или внешнего публичного облака) я бы, конечно предпочёл показатели из списка. Идеальный вариант для выбора поставщика решения (услуги) выглядел бы как форма расчета показателей из списка для указаного мною "календаря". Под календарем здесь можно понимать набор зон, указанных в комментарии Владимира.

    Тогда Заказчик может создать набор сущностей "календарь, плановые показатели, вероятные потери, группа потребителей". Исполнитель может работать над улучшением процедуры восстановления, чтобы ее длительность была максимально прогнозируемой. Исполнитель и Заказчик смогут договариться о приемлемом ценнике на длительность восстановления, применительно к календарю.

    Мне кажется, подобный подход сложнее, но все же перспективнее, чем размышление о %. 

    • Илья, мне кажется, Вы отлично подытожили дискуссию. Добавить нечего, спасибо 🙂

  • Чернов Антон

    Показатель доступности в % – нужный и понятный. Отказываться от него нельзя.
    И вот почему: Показатели доступности меряется за отрезок времени. Например доступность 99,9% в месяц означаете – всего 45 минут простоя. Особенно, если мы считаем простои не 8*5, а 24*7.
    Этого очень нелегко добиться, тк требуется сереьзное резервирование всех систем (серверы, сетевое оборудование, каналы связи, кластеризация приложений), а также ключевого персонала. 
    Я на последних трех местах работы использовал КПЭ % доступности ключевых систем в месяц и этоти показатели были на уровне 99,5-99,8% для различных сервисов. Это менее 3,5 часов простоя в месяц. Для бизнеса, в котором я работал такого уровня доступности было достаточно. Хотя для банковской сферы или телекома достпуность нужна выше. 
    MTBF и MTTR – хорошие показатели для улучшения процесса Управление доступностью в ИТ и анализа прошедших сбоев, а также динамики показателей достпуности в течение года или нескольких.  Но для бизнеса – это сложно и не нужно. Ему достаточно знать, что А) Доступностью в ИТ управляют Б) Есть КПЭ по доступности = макс.допустимой длительности простоя ИТ систем. Например 99,9% = 45 минут в месяц. И этого достаточно. 

  • Чернов Антон

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


Добавить комментарий для Чернов АнтонОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM