Сбои и запросы на обслуживание

[Жилинский Александр]

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

Итак,
а вы разделяете запросы на обслуживание и сообщения о сбоях?
Если да, то какой критерий используется для разделения?

[Алексей Попов]

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

Слишком много нюансов для каждой конкретной компании, в общем и не скажешь.

[Рукамиводитель Службы]

Элементарно.
Критерий прост:
Запрос на обслуживание не содержит информации о неработоспособности предоставляемого сервиса - это вид работ, запрашиваемый у вас, без возникновения ошибки в работе систем, например:заведение учетной записи нового пользователя, добавление в список доступа, установка положенного регламентом оборудования...

[Жилинский Александр]

>не содержит информации о неработоспособности предоставляемого сервиса

Критерий мне понятен Но понятен ли он всем участникам процесса? У вас классификацию делает диспетчер?

Возьмем для обсуждения хрестомайтиный пример. Сервис банкомат. В банкомате кончились сотенные, остались только пятисотки, например. Пользователь желающий 499 рублей обращается с заявкой "ошибка банкомата". Это сбой или запрос на обслуживание? Сервис-то неработоспособен, однако как-такового сбоя инфраструктуры не было.

[Рукамиводитель Службы]

Это запрос на обслуживание, т.к в условии работоспособности сервиса банкомат - выдача денег, а не выдача определенной суммы. Это также точно, как пример с принтером - принтер работает, тонер есть но заканчивается. Пользователь обращается в поддержку с просьбой заменить тонер. т.к собирается распечатать 1000 листов. Это запрос на обслуживание, а не инцидент

[Рукамиводитель Службы]

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

[Сергей Белоус]

Для примера с банкоматом: на первый взгляд такое обращение действительно большое похоже на запрос на обслуживание.
Но возьмем крайний случай - в банкомате закончились все купюры кроме 2000. В результате 50% клиентов не обслуживаются, так как им нужны меньшие суммы. Устроит ли вас, что такое обращение будет обрабатываться как запрос на обслуживание, то есть "не спеша".
Думаю, не устроит.

Я бы сказал, что это инцидент с невысоким влиянием. В этом случае он будет обработан быстрее, да и во тчеты по доступности сервиса может не попасть (если мы настроим их на учет только инцидентов со средней или высокой степенью влияния).

[Жилинский Александр]

Коллеги, мы плавно добрались до зависимости классификации сбой\запрос на обслуживание от того, каким образом определен и построен сервис.
Единственное - не могу согласиться с Сергеем, что запрос на обслуживание всегда выполняется не спеша. Для запросов на обслуживание нужна стандартная схема приоритезации, аналогичная или чуть упрощенная по сравнению со сбоями. Плюс привязка к сервису и sla, разумеется.
Иначе бухгалтер, который ждет забытого или утерянного пароля, будет рвать и метать - и будет прав. Или пользователь, который хочет распечатать 1000 листов. Или получатель в банкомате. Для него и сбой и запрос на обслуживание - это неработоспособный сервис.
Как-то примерно вот так 8)

[АльфаЛаВиста]

Да. Разделяется классификацией инцидентов. Присваивается статус критичности: Критично (3 часа), средняя критичность (!2 часов), плановая работа (24 часа), плановая работа (месяц)
_________________
There is only one success - to be able to spend your life in your own way

[Evgen]

[Odissey]

Предлагаю такую точку зрения:
Если у нас есть SLA, в котором записано как именно сервис должен предоставляться, то сообщение об инциденте (нарушении параметров сервиса) будет считаться началом недоступности.
А сообщение о любом факте, не связанном с нарушением SLA может быть классифицировано как запрос на обслуживание.

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

Так же и с принтером. Какой пользователь пойдет смотреть, хватил ли тонера на его документ из 1000 стр.? Тонера либо хватит, либо не хватит. А вот инженер, в обязанности которого входит контролировать работу принтера, может обнаружить приближение возможного инцидента и зарегистрировать запрос на обслуживание, чтобы выполнить обслуживание...

Как думаете, коллеги?
_________________
Бороться и искать, найти и перепрятать!

[Денис]