В очередной раз об инцидентах и сервисных запросах

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

Дискуссии на эту тему стары, как все вместе взятые методологии управления IT, тем не менее, давайте обратимся к первоисточникам.

Что нам говорит ITIL (официальный перевод глоссария по третьей версии):

Запрос на обслуживание — запрос пользователя на информацию, или консультацию, или на стандартное изменение, доступ к ИТ-услуге.

Инцидент — незапланированное прерывание ИТ-услуги или снижение качества ИТ-услуги.

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

1) Христоматийный звонок пользователя с просьбой сбросить пароль — как его классифицировать, как запрос на обслуживание или как инцидент? Или, может быть, как инцидент информационной безопасности?

2) Звонок от пользователя, у которого не работает корпоративная почта. Беглый анализ обращения говорит о том, что пользователю необходимо провести первичную настройку почтового клиента. Тем не менее с его точки зрения это инцидент, т.к. сервис не доступен, а его никто не уведомил, что «сама почта не полетит»

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

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

Инцидент — это, в большинстве случаев, прерывание или частичное прерывание ИТ-услуги, которая ранее предоставлялась пользователю в утвержденном режиме (сервис доступен 24/7, либо 5/8).

Пример: у главного бухгалтера компании внезапно пропал доступ к системе финансовой отчетности. С одной стороны предоставление доступа это классический сервисный запрос, но в данном случае на лицо явное прерывание сервиса и, как следствие, частичная деградация бизнес-процесса.

Запрос на обслуживание — это обращение от пользователя, который заинтересован в подключении дополнительной услуги, либо доработке функционала существующих услуг.

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

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

Поделитесь своими соображениями на данную тему.

Ссылки:
1. Официальный перевод глоссария ITIL v.3

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

    +1
    Вы взорвали мой ридер своей картинкой
      +1
      Ваши примеры вырваны из окружения: если для описанных ситуаций в компании предусмотрен порядок действий — это запрос, если нет — инцидент, ключевое слово здесь — незапланированное в определении инцидента.
        0
        Не соглашусь, т.к. у вас может быть четкий порядок действий по устранению инцидентов, особенно это касается т.н. аварий или кризисных ситуаций, когда подобные действия зачастую регламентированы и они, фактически, направлены на устранение инцидента.
          0
          Я для себя условно когда-то разделил по источнику возникновения события. Грубо, если источник — человек (субъект воздействующий на систему) (в примере — человек забыл), то это сервис-реквест. Если источник система (объект воздействия) (система аутентификации недоступна) — инциндент.

          В грубом приближении для сортировки хватает.
            0
            Схема неверная. А что если пришел алерт: заканчивается место на жестком диске, с предполагаемыми действиями — надо архивировать старое и чистить диск пока не возникли никакие проблемы? Это вполне себе «сервис-реквест», хотя конкретный человек тут может быть и не причем. Или, сотрудник сделал «что-то не то» и удалил файл, который был базой отдела — это инцидент, хотя источник человек. Я оставляю за скобками разумность настройки системы, и какие слова надо сказать конкретному админу, примеры просто так, для иллюстрации схемы.
              0
              Неверно полагать, что схема неверная, основываясь на домыслах:) В первом случае источник — субъект просто ваша система мониторинга создает уведомление за клиента. А во втором, если это один из вариантов развития событий, это тоже СР. А инцидент — сбой системы авторизации, если такой имел место.
                0
                По первому: ну в таком случае все вокруг нас создано руками человека.
                По второму: ни разу нет.
                  0
                  Соглашусь с тем, что по первому примеру это типичный сервисный запрос, просто сгенерированный за пользователя, т.к. по факту ему ничего не мешало самостоятельно проверить место на диске и сделать такой же запрос. По второму — это однозначный инцидент, причем вполне себе массовый, т.к. сервис не предоставляется и в принципе не важно, кто сломал систему: пользователь или любые другие внешние факторы. С т.з. бизнес-процесса — это инцидент.
                    0
                    Я вам в нижнем ответ писал, да телефон завис :( В ¨моей¨ классификации, это всеж СР€ восстановить работу…, а инцидент в данном случае — сбой системы, которая не давала удалять, а тут хлоп — и дала непонятно почему.
                      0
                      Тогда резонный вопрос, кто будет заниматься анализом причин неполадок в системе? Работа по СР это не подразумевает, т.к. там все прямо — надо восстановить работу, как только задача выполнена — СР закрывается. При этом причины возникновения этой ситуации не анализируются и никто не гарантирует повторения в будущем. А из инцидента мог бы лего возникнуть problem record :)
                        0
                        Я вам на конкретном примере приведу, с вашего позволения.

                        Обращение от клиента:
                        «не работает электронная почта»

                        — агент выпытывает из клиента: почтовый клиент выдает «какое-то» сообщение, «я ввел свой пароль, а оно говорит неправильное имя или пароль»

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

                        — проблема не устранена, проблема переквалифицируется в инцидент и пушается дальше

                        — агент 2 видит, что завис saslauthd. Он устраняет проблему и сообщает клиенту о дальнейших действиях или (возвращает тикет первому агенту). В общем случае это может быть и один человек.

                        — Проблема решена.

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

                        — В вашем примере (клиент удалил файл, доступ к которому для него ограничен) конечно, двояко.

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

                        А насчет анализирования — дело в том, что действия агентов стоят денег. И если даже какой-то СР приходится выполнять по сто раз на дню, это тратит ресурс, т.е. деньги. Значит требуется доп. анализ для выявления того, что можно еще автоматихировать.

                        Я еще раз повторюсь, что мой вариант — не панацея, и, возможно, чьи-то практики более вразумительные. Просто вариант, который предложил и использую я меня устраивает в настоящий момент :)
                          0
                          Cпасибо за развернутый ответ, убедили :) Согласен, много точек зрения имеют право на жизнь.
                    0
                    Не пойму, что вы мне доказать пытаетесь :) трактуйте итил так, как вам нравится, это, благо, не возбороняется.
                    Это Игорю, веточкой промахнулся.
                0
                А как тогда быть с проблемами «кривых рук» когда пользователи сами себе ломают/удаляют/перенастраивают? По факту это же недоступность сервиса, а соответственно инцидент. При этом вся работа специалиста ИТ сводится к перенастройке, что очень напоминает предусмотренный в сервисном запросе порядок действий, о котором говорилось выше.
            +1
            Если ссылаетесь на Глоссарий ITIL то, пожалуйста, соблюдайте принятую в нем терминологию: service request = запрос на обслуживание.
              0
              Спасибо за комментарий, поправил
              0
              1) Христоматийный звонок пользователя с просьбой сбросить пароль — как его классифицировать, как запрос на обслуживание или как инцидент? Или, может быть, как инцидент информационной безопасности?

              2) Звонок от пользователя, у которого не работает корпоративная почта. Беглый анализ обращения говорит о том, что пользователю необходимо провести первичную настройку почтового клиента. Тем не менее с его точки зрения это инцидент, т.к. сервис не доступен, а его никто не уведомил, что «сама почта не полетит»

              Мне кажется тут совершенно очевидно, где запрос на обслуживание, где инцидент. В первом случае какой сервис (услуга) прерывался или снижалось качество? Память пользователя? Если ИТ не ответственен за это, значит это запрос на обслуживание. Во втором, тоже самое — сервис не предоставляли ранее, надо сначала проверить, может пользователю вообще неположено к почте доступ иметь =) А вот если по какой-нибудь процедуре, например, ввода рабочего места в эксплуатацию и т.п., ИТ-служба должна была настроить почту, но забыли — то это вполне себе инцидент, нарушение установленных регламентов.
                0
                ITIL это конечно хорошо, но удобств в нём маловато, конкретики нет например. Лично мне больше нравиться MOF и 3 и 4 версии обе удобны. Вот согласно ему оба пункта и 1) и 2) классифицируются как запрос на информацию.
                Вообще там расписано примерно следующее:
                SD обрабатывает следующие запросы:
                — запрос на устранение инцидентов (техобслуживание, устранение проблем, сглаживание проблем, нахождение обходных решений)
                — запрос на изменение (модернизация КЕ, изменение условий работы, улучшение качества)
                — запрос на информацию (предоставление доступа, поиск, отчётность)
                Опять же это в рамках только SD, под HD это не совсем подходит (но ведь MOF и не для этого создан :)
                  0
                  В понятие «запрос на информацию» входит и пароли сбросить/предоставить и порты открыть и доступ на сайты разблокировать и помочь найти что-нибудь запрятанное в недрах интернета, БД и прочего контента. А также клиента почтового настроить если уж на то пошло. И не важно чья вина, просто это запрос не на обслуживание изначально.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое