Инцидент в ServiceDesk: принят, разобран, закрыт — с причиной, а не с перезапуском

42 инцидента за двадцать один день: реестр с отметками времени, расчёт SLA, Pareto причин и разбор дампа по повтору. Нормативы реакции — из регламента, числа кейса помечены.

  • Работает из России: рубли, договор с ИП, без VPN и иностранной карты
  • По умолчанию чтение и черновики: закрытие заявки и смена прав — по вашей команде
  • Нормативы SLA — из вашего регламента; данные кейса помечены как сконструированные

Дело: 42 инцидента, 12 вне SLA и одна повторяющаяся причина

Кто в деле

Офис 68 человек, восемь систем: 1С, СЭД, клиент-банк, почта, файловый и терминальный серверы, сеть, СКУД. Одна точка входа — ServiceDesk, куда заявки приходят письмом, звонком и сообщением.

  • Что не сходится

    Заявки закрываются, а время реакции никто не считает: в реестре нет отметок, по которым видно, когда инцидент принят. Отчёт руководителю — «в основном всё хорошо», а не число.

  • Что показывает расчёт

    Из 42 инцидентов 12 выходят за SLA: 9 — по времени решения, 9 — по времени реакции, 6 — по обоим. И 7 из 9 опаздывают по реакции на одну–четыре минуты.

  • Почему повторяется

    6 отказов 1С за двадцать один день — одно и то же регламентное задание с неограниченной выборкой, и 5 из 10 инцидентов этой системы вне SLA. «Перезапустили» держит до следующего запуска по расписанию.

  • Что сделал агент

    Собрал реестр из писем и заявок, проставил отметки, посчитал MTTA и MTTR по каждой критичности, разобрал дамп, свёл Pareto причин и отдал три правила вместо четвёртого перезапуска.

Задача

Что считается в этой работе

Инцидент — запись с двумя отметками: когда принят и когда решён. Из них MTTA (до реакции), MTTR (до решения) и соблюдение SLA по критичности. Практика управления инцидентами — ГОСТ Р ИСО/МЭК 20000-1, а конкретные нормативы всегда ваши: в расчёт идут числа регламента, не отраслевые средние. Без реестра любой отчёт — мнение.

Путь инцидента

Одна точка закрытия: инцидент не «решается в чате», а закрывается записью с причиной

Сценарий

Путь в системах: что берём на входе и что отдаём

  1. 1

    Вход: заявки и письма

    Из ServiceDesk (при наличии API) или из почты: тема, отправитель, система, текст. Каждой заявке присваивается номер, иначе реестр распадается.

  2. 2

    Отметки времени

    «Принят» — первый ответственный ответ, «решён» — подтверждение пользователя. Без второй отметки инцидент остаётся открытым, даже если работы закончены.

  3. 3

    Классификация

    Критичность ставится по влиянию на работу, а не по громкости заявки: остановка 1С и «не печатает принтер» получают разные нормативы.

  4. 4

    Разбор и причина

    Для повторов — дамп, снимок ресурсов, хронология. Причина формулируется вызовом и настройкой, а не «платформа виновата».

  5. 5

    Выход: реестр, разбор, правила

    Файл реестра с расчётом SLA, разбор по повтору и список правил: порог оповещения, автопродление, ограничение выборки.

Агент делает · человек решает

Собирает заявки в реестриз почты, чата и ServiceDesk; нумерует и находит дубли
Считает SLAMTTA и MTTR по критичности, список просрочек с причиной
Разбирает повтордамп, ресурсы, хронология — до конкретного вызова
Готовит правилапорог, автопродление, ограничение выборки, срок и владелец
человек: закрывает заявкуподтверждение пользователя — не работа агента
человек: меняет настройки 1Сизменение регламентного задания в рабочей базе
человек: решает про деньгипокупка памяти, дисков, нового узла — бюджет

Что получится на выходе

Реестр, расчёт SLA и Pareto причин на одном листе — так это выглядит в работе

Открыть артефакт

Подключения

Что подключим

Сервис · что читаем · что пишем · что нужно от вас · срок

Чего агент не делает

Границы работы

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

Вопросы

У нас нет ServiceDesk, только чат. С чего начнётся?

С журнала: заявки из чата и почты сводятся в реестр, и уже по нему видно время реакции. ServiceDesk подключается позже — без него теряются отметки, но не сама работа.

Как считается SLA, если нормативов у нас нет?

Нормативы берутся из вашего регламента; если его нет, агент предлагает четыре уровня по влиянию на работу и вы их утверждаете. Отраслевые средние в расчёт не подставляются.

Что делать, если причина не находится?

В разборе так и пишется: «причина не установлена», с перечнем проверенного. Это честнее, чем закрыть заявку «перезапуском»: повтор вернётся и попадёт в Pareto.

Откуда берутся данные для расчёта?

Из ваших систем: почта и ServiceDesk — заявки и отметки, 1С — журнал и события заданий, мониторинг — ресурсы. Если API нет, реестр собирается выгрузкой файлом.

Это заменяет дежурного администратора?

Нет. Агент снимает сбор, расчёт и разбор, дежурный принимает решения и делает изменения. Работы по ст. 5 ч. 3 п. 1 ФЗ-38 — замена сотрудника — здесь нет.

Соседние работы

Рядом

Подключения

Роли

Отдайте реестр инцидентов — вернём расчёт SLA и разбор повтора

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

Telegram
MAX
Спросить здесь