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

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

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

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

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

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

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

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

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

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

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

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Дмитрий Исайченко

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

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

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

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

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

    2. суммарная длительность простоев за период.

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

    1. Георгий

      Учёт и анализ инфраструктурных инцидентов как раз позволяет выйти на второй KPI — по доступности

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

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

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

      1. Дмитрий Исайченко

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

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

    2. Евгений Шилов Автор

      > Частота не нужна

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

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

    3. Grigory Kornilov

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

      1. Бизнес дал денег на Site Recovery? Если нет, лучше внести в SLA, что нарушением SLA не являются аварии в датацентре. Или вписать это как риски.

      2. Максимальная продолжительность одного простоя ... звучит не понятно, один простой может иметь разную продолжительность? А если между 2-мя простоями было 5 минутное восстановление функциональности? А если функциональность восстанавливалась в автоматическом режиме и так же падала в течении всех суток, а пользователю фактически из-за этого работать не получалось?

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

      Предлагаю : опишите в примере согласованные SLA и тогда предлагайте KPI по ним.

      1. Евгений Шилов Автор

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

        1. Grigory Kornilov

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

          Предлагаю :

          1. опишите в примере согласованные SLA.

          2. опишите методику оценки KPI по пунктам SLA.

          3. несколько кейсов отказов\нейункциональности и влияния этого на показатели KPI и соответствия к SLA.

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

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

СЕН
27