«Как близнецы»: 3 пары похожих терминов ITIL

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

    В этой статье мы попытаемся разграничить три пары похожих терминов:

    • Инцидент и проблема
    • Управление инцидентами и управление проблемами
    • Service desk и Help Desk

    На основе примеров покажем, для чего нужен каждый из них.


    / Flickr / Dennis / CC

    Инцидент и проблема


    IT-специалист и автор тренингов по ITIL Майкл Скарборо (Michael Scarborough) подчёркивает, что между терминами установлена следующая зависимость: проблема — причина, инцидент — следствие.

    Второе отличие, по мнению Майкла, заключается в том, что инцидент можно разрешить только на определённое время. Когда мы говорим «разрешили инцидент», это значит, что временно восстановили какую-то услугу (на 10 лет или всего на 1 минуту). То есть очень вероятно, что подобная ситуация повторится в будущем.

    Проблема же, это причина возникновения инцидентов. Эксперт в области ITSM профессор Росс Вайз (P. Ross S. Wise) считает, что первый признак проблемы — вопрос «почему», который вы задаёте себе.

    Посмотрим на примеры, которые приводит директор по маркетингу компании Hornbill Питер Саммерс (Peter Summers).

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

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

    Для наглядности возьмём более приземлённый пример. Вы едете на машине, и у неё лопнуло колесо. Это инцидент, потому что прокол нарушил ваши планы: вам приходится останавливаться, чтобы заменить колесо. В этом случае инцидент считается исчерпанным. Но теперь у вас есть проблема — вы едете на запасном колесе. Чтобы устранить проблему, вам нужно залатать покрышку.

    Другой пример: вы едете на лысой резине — это проблема. Если вы продолжите её игнорировать, вероятность возникновения инцидента будет расти, покрышка, вероятно, лопнет.

    Чтобы упростить вопрос с разграничением значений этих двух терминов, Филип Юсон (Philip Yuson), генеральный директор Concept Solutions Corporation, рекомендует задавать следующие вопросы:

    • Сервис недоступен?
    • Ухудшилось ли качество услуг?
    • Пострадали ли бизнес-процессы?
    • Пострадало ли качество предоставления услуги?

    Если вы ответили «да» на один из этих вопросов, скорее всего, вы столкнулись с инцидентом.

    Incident Management и Problem Management


    Мы уже выяснили, чем отличаются инцидент и проблема, поэтому разграничить эти два процесса будет проще. ITIL определяет эти два термина следующим образом:

    Управление инцидентами — управляет жизненным циклом всех инцидентов. Цель: скорейшее восстановление ИТ-услуги для пользователей.

    Управление проблемами — управляет жизненным циклом всех проблем. Цель: предотвращение инцидентов в будущем.

    Посмотрим на примеры от специалистов Microsoft. Представим сценарий: к специалисту техподдержки обратился пользователь, который не может просмотреть электронное письмо из-за ограничений. Саппорт создаёт новый инцидент с помощью шаблона e-mail incident, чтобы быстро разрешить ситуацию и обрабатывать похожие случаи в будущем.

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

    Для большей ясности приведём пару примеров из жизни. Управление инцидентами похоже на работу пожарных. Они приходят на место происшествия и стараются максимально эффективно погасить огонь. То же самое происходит при управлении инцидентами. Возобновить работу инфраструктуры нужно быстро.

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

    Service desk и Helpdesk


    Для начала вновь заглянем в официальную терминологию ITIL.

    Service Desk — единая точка контакта (SPOC) между поставщиком услуг и клиентами. Функции: управляет инцидентами, запросами на обслуживание.

    Help desk — точка контакта для пользователей. Функции: регистрирует инциденты.

    Термин «служба поддержки» часто употребляется как синоним службы Service Desk, что является главной причиной путаницы в терминах. Крис Коффи (Cris Coffey), менеджер по маркетингу компании BMC Software, который работает на рыке Help Desk уже 20 лет, выделяет следующие различия между двумя этими службами.

    Service Desk: полностью интегрируется с другими ITSM-процессами, помогает организации соответствовать соглашениям об управлении уровнем услуг, интегрируется с базой данных управления конфигурациями и процессом управления активами.

    Help Desk: отслеживает все входящие инциденты, автоматически отслеживает уведомления по электронной почте, предлагает ограниченную интеграцию с другими ITSM-процессами, предоставляет услуги самообслуживания для конечных пользователей.

    Посмотрим, как это выглядит на практике. Пример работы Help Desk: драйвер для принтера Джо сломался, а ему нужно распечатать копии документов до 10 часов. Help Desk поможет Джо восстановить работу принтера или найдёт другой способ получить распечатки вовремя. Задача службы — сделать так, чтобы распечатки были в руках у Джо до 10 часов.

    В той же ситуации Service Desk заметит, что за прошедшую неделю несколько человек с этого этажа обратились в службу с той же проблемой. Это значит, что проблема — глубже, чем кажется. Service Desk отправляет специалиста, чтобы установить корень проблемы с принтером. Задача службы — устранить первопричину.

    Напоследок кратко обобщим все разобранные моменты:

    Инцидент и проблема

    1. Проблема — причина, инцидент — следствие.
    2. Инцидент устраняем сразу же. После него ищем источник проблемы разрешаем её.

    Управление инцидентами и управление проблемами

    1. Управление инцидентами работает быстро, а управление проблемами — тщательно.
    2. Устраняем проблему — предотвращаем инциденты, связанные с ней.
    3. Устраняем инцидент — помогаем пользователю продолжить работу.

    Help Desk и Service Desk

    1. Service Desk — стратегия, Help Desk — тактика.
    2. Service Desk работает для сотрудников и для клиентов, а Helpdesk только для клиентов.
    3. Service Desk концентрируется на процессах и делает всё, чтобы они соответствовали ITIL.
    4. Help Desk концентрируется на помощи. Его главная задача — решить задачи клиента.



    P.S. Еще пара материалов из нашего блога:

    • +15
    • 8.1k
    • 5
    ИТ Гильдия
    56.78
    Российский интегратор ITSM решения ServiceNow
    Share post

    Comments 5

      0
      Можно ли пользоваться услугой?
      Ухудшилось ли качество услуг?
      Пострадали ли бизнес-процессы?
      Пострадало ли качество предоставления услуги?
      Если вы ответили «да» на один из этих вопросов, скорее всего, вы столкнулись с инцидентом.

      Можно ли пользоваться услугой? Да.


      Инцидент?


      В оригинале так:


      Is the service unusable?
      Is there a degradation of the service?
      Is the business process affected greatly?
      Are service levels affected?

      Я бы первый вопрос перевел: Услуга недоступна?

        0
        Вопрос: если решение инцедента приведёт к заметанию следов причин возникновения проблемы — насколько правильно решать его сразу? Вопрос не праздный. Сервис на сервере завис — сервер перезагрузили — инцидент решён. А проблема осталась: никто не знает почему завис сервис — логи при перезагрузке потерялись, объемы занимаемой памяти и активность дисковой подсистемы никто не снял и т.д… В идеале за технической стороной вопроса, конечно, должен смотреть мониторинг. В реальной жизни — неучтённые обстоятельства бывают всегда, как мне кажется.
          0
          >… насколько правильно решать его сразу?

          Зависит от вашего SLA. Если уровень сервиса позволяет дождаться специалиста, который займётся поиском причины на месте — правильно его дождаться. А если у вас по SLA допустимое время простоя — 3 минуты, то перезагружаем сразу, потом делаем снэпшот и на препродуктовой среде пробуем воспроизвести баг для поиска проблемы.

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

          Управление инцидентами — процесс, направленный на оперативное восстановление работы отказавших систем. Управление проектами — процесс, направленный на анализ причин повторяющихся сбоев и устранение этих причин (если это экономически обосновано).

          Как по мне, разница между Helpdesk и ServiceDesk небольшая. В реальности и то и другое в компаниях используется практически одинаково. Ну и да, ни один ServiceDesk не умеет обнаруживать повторяющиеся инциденты в автоматическом режиме и создавать проблему — все же это делает руками человек. Остальные выводы относительно различия Helpdesk и ServiceDesk попахивают булшит.
            0
            Нашёл данную статью весьма интересной. Не могу не высказаться.
            По порядку.

            ❶ Про мнение, цитата: «Второе отличие, по мнению Майкла, заключается в том, что инцидент можно разрешить только на определённое время. …».
            → Инцидент характеризуется временем, местом и сутью, т.е. другими словами когда, где и с чем произошло, о чём не пишет ITIL. На самом деле, изменение одной из 3-х составляющих приведёт к появлению нового инцидента, а не повторению предыдущего. Мера же воздействия инцидента на пользователей, является отдельным аспектом не оказывающим влияния на характеристики самого инцидента (метод обратной связи). Это надо уметь осознать.

            → Проблема. Характеризуется отсутствием алгоритма её устранения, основанной на недостатке имеющихся знаний и технического обеспечения. Это упрощённо.
            Важно: Привлекая ресурсы извне, устраняя недостатки в ресурсах, т.е. нечто обладающее возможностью разрешить проблему, последняя преобразуется в задачу:
            1. Известное начальное состояние (дано).
            2. Известное конечное состояние (найти)
            3. Алгоритм достижения от начального к конечному состоянию (решение).

            Учитывая вышеописанное, лишний раз убеждаешься в том, что мнение присутствует каждый раз, когда отсутствует знание…

            ❷ Про признак проблемы, цитата: ”профессор Росс Вайз (P. Ross S. Wise) считает, что первый признак проблемы — вопрос «почему»…”
            → Техника может быть:
            1. Неисправна, но работоспособна (например, неисправность турбины в дизельном ДВС, что позволяет медленно, но ехать).
            2. Неисправна и не работоспособна (например, заклинивший ДВС).
            3. Исправна, но неработоспособна (например, нет топлива в автомобиле).


            Рассмотрим на примере единственного неисправного и неработоспособного принтера в отделе продаж:
            1. У компании №1 нет тех.персонала имеющего компетентность по ремонту оргтехники – проблема.
            2. У компании №2 есть тех.персонал имеющий компетентность по ремонту оргтехники – инцидент.

            Важно: проблема понятие относительное. Для пользователя, неисправность это проблема, а для техника — инцидент (см. определение п.1).

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

            Да, методическая формулировка сложнее для понимания, в отличие от обывательской формулировки выраженной в виде мнения, но зато позволяет идентифицировать наличие проблемы на основе критерия, а не ощущения. Выяснять же, к какой именно науке относиться звание профессора Росс Вайз, не имеет смысла, поскольку звание, само по себе, не является доказательством. Также может иметь место ошибка репортёра/редактора/ переводчика.

            ❸ Про примеры, цитата: «Вы едете на машине, и у неё лопнуло колесо…». Следствием выбранной автором ошибочной системы ценностей, является ложность приведённых им примеров.

            Исправим заблуждения учитывая мои п.п.1-2.
            Изначально у автора, цитата: «Вы едете на машине, и у неё лопнуло колесо. Это инцидент, потому что прокол нарушил ваши планы: вам приходится останавливаться, чтобы заменить колесо. В этом случае инцидент считается исчерпанным. Но теперь у вас есть проблема — вы едете на запасном колесе. Чтобы устранить проблему, вам нужно залатать покрышку.»

            Рассматривать следует как систему, надсистему, так и подсистему, причём в совокупности прошлое, настоящее и будущее.
            Утверждение автора ложно, поскольку запасное колесо не является частью системы автомобиля до момента установки в него (интеграция), а также перестает быть частью системы после снятия (см. определение терминов). Не являясь частью системы «автомобиль», колесо перестаёт выполнять полезную работу, в результате чего к нему не применимо понятие инцидент или проблема, зато применимы понятия неисправна и работоспособна, что методически верно с тех. т.з…

            Итого, на примерах:
            1. В машине не оказалось запасного колеса – невозможно устранить собственными ресурсами => проблема, т.к. отсутствует тех.обеспечение.
            2. В машине нет запасного колеса, но неисправное колесо RunFlat => инцидент, т.к. тех.система неисправна, но работоспособна.
            3. 3. В машине есть запасное колесо, но водитель девушка и не в состоянии его заменить => проблема в части анатомии (сила), компетентности (частный случай навык) и т.д..
            4. В машине есть запасное колесо, домкрат и у водителя достаточно знаний и умений => инцидент, т.к. оперативно устраняется.
            5. И т.д.


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

            █ Вместо заключения.
            Проблема (см.определение) таких документов как ITIL состоит в их гуманитарном контексте и позиционировании как методологии по техническим вопросам, хотя таковыми они не являются по своему содержанию.
            Проблема пользователей, использующих такие документы, заключается в невозможности осознания.
            Количество не значит качество — массовый выброс подобных статей формирует ложную систему ценностей…

            Из выше описанного следует делать вывод, что первичное значение имеет знание и осознание в совокупности с обоснованием (можно доказательством), а не вера в некое мнение. Следует не только выражаться в виде утверждений, но и трудится присовокуплять к ним подтверждения, что по своему составу уже будет уже обоснованием, хотя и не доказательством.
            Что касается полезной работы Интеграторов, внедряющих автоматизацию по «таким» системам ценностей, в результате будем получать классический «даёшь внедрёж».

            Желаю всем включать мозг и знания, а не «сердце» и мнение, поскольку этим широко пользуются маркетологи.

            PS: Попугая можно научить говорить E=mc^2, однако для него это будет всего лишь совокупность звуков, а не знание как таковое.

            PSS: Не всё заграничное хорошо. В России тоже достаточно накопленных знаний, надо лишь уметь их найти и осознать, а не гонятся за модными маркетинговыми выбросами типа DevOps и т.д…

            Only users with full accounts can post comments. Log in, please.