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

Героизм в ITIL V3: борьба с инцидентами

На недавнем курсе слушатели, работающие в крупном системном интеграторе, смогли найти в ITIL V3 очередное противоречие. Их находкой хочу поделиться с вами. Итак: два понятия.

Первое – это SLA: соглашение между поставщиком ИТ-услуг и заказчиком. Соглашение об уровне услуг описывает ИТ-услугу, документирует целевые показатели уровня услуги, указывает зоны ответственности сторон – поставщика ИТ-услуг и заказчика.

А второе – это часть определения инцидента из книги Service Operation: …Сбой конфигурационной единицы, который еще не повлиял на услугу, также является инцидентом, как, например, сбой одного диска из массива зеркалирования… (отличное слово, кстати: женщины перед походом в театр зеркалируют часами).

Для моих слушателей SLA – очень понятная штука, ведь это обязательства, которые их организация юридически берёт на себя. И "целевые показатели уровня услуги", такие как сроки устранения инцидентов и доступность, для них не абстрактные слова, а именно то, за что они получают деньги.

И вдруг, ITIL, всё про SLA хорошо объяснив и подтвердив практический опыт, огорошил их: несмотря на то, что устранение инцидентов может предоставляться дискретно (например, только днём, с 9 до 18), инцидент, обнаруженный в «нерабочее» время, следует устранять немедленно. Или, если взять "зеркалирование" – то придётся восстанавливать диск за свой счёт, а пользователи и заказчик вообще ничего об этом не узнают.

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

«А город подумал – ученья идут…». Но геройствовать, вслед за лучшими практиками, мои слушатели не хотят.

Как быть? Кто прав?

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

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

  • Anton Lykov

    Константин, давайте пытаться искать логику.

    SLA – документ, определяющий уровень и условия предоставления услуг по согласованию заказчика и ИТ-организации.

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

    В SLA вам ITIL не запрещает написать что угодно. В т.ч. “мы устраняем только те инциденты, которые привели к недоступности услуги для пользователя”. В таком случае пользователи наступают на грабли, вы честно всё чините.

    Есть ли в этом польза? Счастливы ли пользователи? Движется ли бизнес в такой модели поведения, помогаете ли вы ему?

    ITIL много говорит о проактивности и об управлении рисками. Если у вас случился инцидент, который может повлиять на снижение качества услуг (например, упала резервная нода в кластере), разве ж ваш реальный заказчик не будет её чинить? Безотносительно существования каких бы то ни было SLA и т.д. – Ведь будет же. Здесь в процессе управления инцидентами есть определенная проактивность, на мой взгляд, хотя ITIL явным образом не разделяет этот процесс на реактивную и проактивную составляющую.

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

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

    • Антон, про проактивность-то и труднее всего рассказывать. Особенно технарям, выдвигая аргументы по поводу “ведь ломается часто” 😉
      “Проактивные процессы – это для мира с неограниченными ресурсами”, говорят они. Ну сломалась резервная эээ нода, её заменим, когда забюджетируем. Условно планово, в следующем году. А за исправление главной ноды – заплатит заказчик, в рамках своего SLA. Так ведь?

      • Pavel Solopov

        По хорошем, если у нас реально ИТ-услуга, а не услуга по обслуживанию систем заказчика. Ну то есть, что-то типа SaaS-а.
        То решение о том как быстро устранять инцидент должно приниматься исходя из двух факторов:
        1. Как повлияет данный инцидент на SLA, когда он наконец скажется на услуге. Если его влияние впишется в SLA, то действительно можно не рыпаться (если наша бизнесс-концепция: получите SLA и не граммом больше, конечно же).
        2. Не выйдет ли устранение этого инцидента потом себе дороже. А то ведь ситуацию можно запустить так, что потом на её **** потратишь сил и времени ещё больше, чем потери от всяких нарушений SLA.

        Ну а поскольку, чаще всего, ответить на оба вопроса можно лишь с большой неопределённостью, то лучше решать по мере обнаружения, как можно быстрее. Правда тут надо понимать, что “как можно быстрее” это тоже относительное понятие. Ибо поспешишь- людей посмешишь.

        • Pavel Solopov

          Какой испорченный у вас робот, коллеги. У него на слово у_с_т_р_а_н_е_н_и_е возникают какие-то нездоровые ассоциации. Даже не могу себе представить какие, это ж даже не вебинар.
          Вы, кстати, какими-то лучшими практиками, поди регулярно обновляете?

          • Странно. Слово “устранение” в Вашем же посте присутствует в чистом виде, не забаненное (пункт 2, строка 1). Может быть появившиеся звёздочки есть результат какой-то нелепой опечатки? Хотя я тоже сходу не придумал подходящий вариант… Видимо, слабо у нас с лучшими практиками 🙂

    • Я, пожалуй, согласен с Антоном. То есть есть и другие аргументы, но результат будет тот же. Так что +1.

    • “никакой проактивности, лишь бы оно почаще ломалось, а мы доблестно с этими поломками боролись”

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

      Учитывая, что управление инцидентами как правило наиболее зрелый процесс управления ИТ, а отчётность по этому процессу – практически единственная отчётность по операционной деятельности ДИТ, приходим к любопытному выводу. А именно: проактивность не нужна тем компаниям, которые не научились ей управлять. Если бы научились, смогли бы демонстрировать заказчикам свою ценность не только потоком решённых инцидентов, а тем, как удалось инцидентов избежать, прекратить их повторение, то есть на операционном уровне помочь бизнесу работать непрерывно.

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

      • Pavel Solopov

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

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

        • “Позвольте, Дмитрий, с вами не согласиться.”

          Конечно, не соглашайтесь со мной, так гораздо интереснее.

          Если бы проактивность достигалась только внедрением оборудования или ПО, то Ваш тезис про разовые инвестиции был бы оправдан. Но процессы, которые обеспечивают проактивность (управление проблемами, мощностями), а также отдельные виды деятельности, направленные на улучшение (PIR в управлении изменениями, развитие базы знаний) требуют сил на исполнение, а также управленческих ресурсов на контроль, оценку и совершенствование. Это и есть управленческие расходы.

          Теперь про эффект объёма. Это очень спорные ожидания сразу по двум причинам. Смотрите сами: чтобы получить объём на другом качестве услуг необходимо, чтобы а) рынок узнал о вашем другом качестве и б) рынок узнал, что оно – только у вас. Первая проблема – качество не является фактором дифференциации (см., например ISBN 978-5-94807-024-7, это очень давняя и ставшая классической работа по маркетингу). Вторая проблема – чтобы продвигать своё новое качество услуг, Вам придётся “громко кричать”. Разумеется, вас услышат не только заказчики, но и конкуренты, которые довольно быстро скопируют вашу идею. По нашей практике могу сказать уверенно – копируют быстро.

          Паша, честно говоря, я буду рад, если Вы меня переубедите. Но если бы Вы были правы, мы уже давно жили бы в другой экономической реальности. Ведь согласитесь, тема, которую мы с Вами обсуждаем, имеет очень мало ИТ-специфики. В той ли иной степени она применима к любой деятельности возмездного оказания услуг. Посмотрите на услуги авиаперевозок и на статистику авиакатастроф. Чем достигается хоть какая-то проактивность? Жёстким государственным регулированием. Посмотрите на услуги такси. От Вас часто требуют пристёгиваться ремнём безопасности (а уж здесь-то, казалось бы, вообще доп. расходы не нужны)? Ну и так далее (c) Сергей Шнуров.

          • Grigory Kornilov

            Позиция Дмитрия мне ближе.

            Мы как-то проводили ‘тендер’ на оказание IT услуг.
            Все провайдеры давали хороший SLA и штрафы по при его не соблюдении.
            В итоге разделение предложений произошло на 2 части :
            1. Дешевле – архитектурно есть риски в неработоспособности на сутки в месяц и 2 недели раз в год.
            2. Дороже в 2 раза, но архитектурно есть риски в неработоспособности на 2 суток раз в год.

            Если риски срабатывают, сервис провайдер платит штраф, а наша компания несет убытки из-за простоя.
            Когда начали считать возможные убытки поняли, что платить в 2 раза больше за неубиваемую инфраструктуру нет желания.
            Но описанная ситуация немного другая – деньги в кластер уже вложены.

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

            • Григорий, считать – это исключительная ситуация, по-моему. Если бы все считали (управляли рисками, кстати), как у вас – не было бы этого поста =)

          • Pavel Solopov

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

            К тому же подходы, как правило, экстенсивные: нанять больше людей, зарезервировать всё по три раза и т.д. Конечно же за счёт клиента…

            P.S. Про такси не понял. Это же они вам сервис такой предоставляют – не лезут к вам в душу со своими рекомендациями. 🙂 Другое дело, что ремней может и не оказаться. 🙂

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

    • Владимир, так это ж Gamification в чистом виде! Представьте себе азарт бригады: например побить рекорд длительности потока или устранить аварию меньше чем за час, чтобы “поток” косяка вообще не заметил=)

    • Pavel Solopov

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

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

  • Леонид Пшеничный

    Какие инциденты регистрировать наверное должны решать те кто занимаеться их устранением.

    Им это важно для оченки своих затрат на предоставление сервисов.

    А вот что показывать заказчику это уже вопрос интересный.

    С одной стороны заказчика будут интересовать только те инциденты которые повлияли на качество предоставляемых услуг. То есть из-за чего он потеряд деньги. 

    А сдругой стороны  исполнителю хочется показать себя героем и продемонстрировать, что все у заказчика замечательно благодаря нашим усилиям.

    Но во втором случае заказчик как раз за это уже заплатил и больше денег не отвалит.

     И на репутацию сервисной компании показ всех инцидентов может повлиять весьма не однозначно.

    Так что регистрируйте все инциденты, а заказчику показывайте только те которые "не влезли в SLA"

     

  • Игорь

    А заказчик не имеет право видеть _все_ инциденты?


Добавить комментарий для Леонид ПшеничныйОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM