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

Влияние сбоев на ИТ-услуги

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

  • время поддержки
  • время решения инцидентов

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

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

Приведу пару примеров:

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

2. Отключилось электропитание на одной из площадок. Т.е. не просто ИТ-сервисы перестали предоставляться, а жизнь полностью встала. Пользователи не могут даже чайник вскипятить. Возможно они будут звонить в ИТ со словами "мы не можем работать в программе ABCDE", но это вряд ли. И допустим, что питания нет, т.к. перерубили кабель, который будут восстанавливать пару дней. Что будет в отчетах по ИТ-сервисам? По-идее все прекрасно, пользователи не звонят, инцидентов нет. ИТ-сервис как предоставлялся, так и предоставляется. Фактически же картина другая. 

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

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

Остается только понять, какие сервисы перестанут предоставляться, если площадка оказалась без электричества или каналов связи. Но это уже дело техники 🙂

«VAP: Управление уровнем услуг и каталогом услуг»
Разработка каталога, SLA, метрик качества, расчёт доступности

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

  • “Для того чтобы отражать фактическое состояние дел надо включать в условия соглашения возможные перерывы в предоставлении ИТ-сервиса”

    Ну да, так и есть. Деятельность по эксплуатации можно принципиально описать тремя KPI – по обработке обращений пользователей, по доступности VBF, по удовлетворённости заказчиков / ключевых потребителей услуг (давным-давно такую схему предлагал Гартнер). Учёт и анализ инфраструктурных инцидентов как раз позволяет выйти на второй KPI – по доступности (в отличие от индивидуальных обращений пользователей, которые годятся только для первого KPI). Классика жанра.

    “в соглашении можно описать тремя параметрами, понятными бизнесу”

    Зачем три? Достаточно два:

    1. максимальная продолжительность одного простоя;
    2. суммарная длительность простоев за период.

    Частота не нужна (да и договориться о частоте простоев, вероятно, будет не просто).

    • Георгий

      Учёт и анализ инфраструктурных инцидентов как раз позволяет выйти на второй KPI — по доступности
      Не согласен. Вернее, с тем, что это лучше чем учет индивидуальных обращений, то конечно, только вот просто мониторить инфтраструктурные инциденты, это не самый лучший способ определения доступности. Все-таки транзакционный мониторинг в этом плане более показателен, хотя мониторинг отдельных компонент тоже нужен конечно, для более детального анализа

      Для договоренностей в SLA действительно очень хорошо действует просто максимальное время простоя за период (неважно чем оно вызвано) + максимальное время единичного простоя. Частота простоев, полностью согласен с Димой, крайне сложный для согласования и контроля потом вариант, плюс при наличии двух первых он кажется еще и излишним

      А вообще опять таки +1 к Диме, это довольно тривиальная вещь, хотя не лишне иногда и такие повторять ) только жаль тут особо нечего обсуждать)

      • “Все-таки транзакционный мониторинг в этом плане более показателен, хотя мониторинг отдельных компонент тоже нужен конечно, для более детального анализа”

        А это смотря что мониторить и смотря когда регистрировать инфраструктурный инцидент. У меня как раз есть примеры ровно того, про что ты говоришь – инфраструктурный инцидент регистрируется при недоступности VBF, а не какой-нибудь очередной железки. И эта информация напрямую используется при оценке доступности за период.

        • Георгий

          я немного о другом, но это детали реализации уже, смысл точно таков да

    • > Частота не нужна
      Дима, как ни странно, есть и другое мнение на этот счет. Допустим договорились, что максимальная длительность 20 минут. И суммарная длительность не более 8 часов. Если система несколько дней подряд каждый час будет умирать на 20 минут, наверное не все обрадуются.

      Частоту можно заменить временем между простоями, что по сути одно и то же.

    • Grigory Kornilov

      Комментарии:
      1. Бизнес дал денег на Site Recovery? Если нет, лучше внести в SLA, что нарушением SLA не являются аварии в датацентре. Или вписать это как риски.
      2. Максимальная продолжительность одного простоя … звучит не понятно, один простой может иметь разную продолжительность? А если между 2-мя простоями было 5 минутное восстановление функциональности? А если функциональность восстанавливалась в автоматическом режиме и так же падала в течении всех суток, а пользователю фактически из-за этого работать не получалось?

      KPI – стоятся к привязке к пунктам SLA, ведь мы хотим именно SLA гарантировать и его соблюдение оценивать, верно?
      Предлагаю : опишите в примере согласованные SLA и тогда предлагайте KPI по ним.

      • Григорий, мне кажется, что бизнес не в восторге будет от обсуждения исключений по принципу условия соглашения зависят от того, что сломалось. Хотя конечно такой вариант возможен, но он не очень бизнес-ориентирован.

        • Grigory Kornilov

          Бизнес ориентирован на получения достоверной информации о решении и возможных рисках.

          Предлагаю :
          1. опишите в примере согласованные SLA.
          2. опишите методику оценки KPI по пунктам SLA.
          3. несколько кейсов отказов\нейункциональности и влияния этого на показатели KPI и соответствия к SLA.

          Тогда можно будет добавить несколько своих кейсов к п3 и обсудить.


Добавить комментарий

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM