SLA, календарь и эскалации

Сроки настраивают в разделе «Settings → SLA». Страница сама говорит сверху, когда не действует ни одна политика. У политики три части: название, условия и цели. Новые политики намеренно создаются недействующими, чтобы вы могли закончить настройку до того, как они что-то сделают.

Условия — это «Team», «Priority», «Main category» и «Subcategory». Пусто означает «Any», то есть «относится ко всему», а не «не относится ни к чему». Если подходят несколько политик, побеждает та, у которой наименьшее число в поле «Order»; поэтому узкая политика стоит сверху, а общая под ней.

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

У каждой политики две цели. «Time to first response» кончается первым публичным ответом оператора, а автоматическое подтверждение и внутренняя заметка прямо не считаются. «Time to resolution» кончается, как только заявка достигает статуса, который считается решённым (какой именно, вы задаёте в разделе «Settings → General → Status»). У обеих целей свои минуты, свой календарь и своя реакция на нарушение.

На заявке сроки стоят справа в карточке «Details», а под ними «Show deadline history»: журнал, который записывает каждый шаг — начат, приостановлен, возобновлён, соблюдён, нарушен — с причиной и использованным рабочим временем. Видят его только операторы и администраторы, а клиентам он недоступен.

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

Если при создании заявки не подошла ни одна политика, часы запускаются, когда политика впервые подходит после изменения, например после повышения приоритета. Они считают с этого момента. Часы первого ответа запускаются, только если ещё никто не ответил.

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

Календарь говорит, когда идут часы. У него есть название, свой часовой пояс и любое число окон на день недели, а обеденный перерыв — это просто день с двумя окнами. Окно может уходить за полночь, и тогда рядом появляется «ends next day».

Какой календарь действует для команды, задаётся на команде («Settings → Teams»). На отдельной цели политики его можно перекрыть: «From the team» берёт календарь команды, или вы выбираете другой. Именно так и получается обычный случай: неисправности считаются круглосуточно, всё остальное только в часы работы.

Считается то время, которое действительно проходит внутри окна, а не разница показаний часов. При переходе на летнее время это важно: круглосуточный день в октябре имеет 25 часов, а ночная смена с 22:00 до 06:00 весной семь вместо восьми. Окно с 09:00 до 17:00 это не затрагивает никогда, потому что в ЕС перевод происходит ночью.

Если календаря с открытыми часами найти нельзя, срок не создаётся: лучше никакого, чем угаданный. На заявке вместо даты появляется примечание.

Под каждым календарём стоит список «Closed days». Щелчок по «Import holidays (.ics)» принимает файл календаря и потом сообщает четыре числа: сколько дней принято, сколько заменено, сколько нечитаемых и сколько уже было. Отдельные дни можно вводить и вручную.

Знак ↻ за днём означает «повторяется ежегодно». Он верен только для постоянных дат: 3 октября каждый год приходится на ту же дату, а Страстная пятница и Духов понедельник висят на дате Пасхи и двигаются. Поэтому подвижные праздники стоят в списке со своей конкретной датой на каждый год, и на картинке «Good Friday» стоит без этого знака.

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

Самый частый спор о сроках вот такой: заявка три дня ждёт ответа клиента, а часы всё равно идут. Поэтому у каждой цели есть переключатель «Pause while waiting for the requester», причём отдельный, а не на всю политику.

Ждёте вы или нет, решает статус: в разделе «Settings → General → Status» у каждого статуса есть пометка, считается ли он «ожиданием заявителя». С включённым переключателем срок отдыхает, пока заявка стоит в таком статусе. Настенные часы при этом идут, поэтому список показывает «Paused» вместо оставшегося времени, а история сроков содержит «Paused» и «Resumed» с их временем. Время ожидания не считается и тогда, когда заявку решают прямо из такого статуса.

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

Как только политика действует, в списке заявок появляется столбец «Deadline». Он показывает оставшееся время ближайшего открытого срока («14h 53m»). Как только на заявке не идёт ни один срок, там стоит вердикт: значок «In time» для соблюдённого, красный «Breached» для нарушенного. Заявка без всяких часов получает нейтральный прочерк, и это сделано намеренно: заявка из времени до политики — не провал.

Если не действует ни одна политика, столбца нет вовсе, он не стоит там пустым. То же с фильтром: в разделе «Filter» флажок «Breached only» появляется, только когда сроки вообще есть.

У заявки двое часов, а в столбце только одно место, и он показывает самый срочный ОТКРЫТЫЙ срок. Если первый ответ был просрочен, а решение ещё идёт, столбец показывает оставшееся время решения с красным «!» рядом. Этот знак говорит: на этой заявке уже нарушен один срок, и именно так фильтр «Breached only» её и находит, потому что он спрашивает о любом нарушенном сроке, в том числе давно завершённом. Какой из двух это был, написано в самой заявке.

Сортировать по нему тоже можно: под тем же заголовком «Deadline» стоит поле с «Due soonest first» и «Due latest first». Заявки без идущих часов всегда оказываются последними: они не наименее срочные, они просто не затронуты. Сортировка по сроку важнее сортировки по «Updated at»: ни один список не может удовлетворить два порядка сразу.

Для каждой цели вы задаёте в поле «When breached», что происходит при нарушении: «Record only» только записывает, «Notify assignee and observers» отправляет письмо исполнителю и наблюдателям, а не всей команде, «Hand over to another team» передаёт заявку. Для передачи нужно выбрать целевую команду, а политика без неё при сохранении отклоняется, потому что выглядела бы настроенной и не делала бы ничего.

Действие выполняется ровно один раз на одни часы. Без этого запора перезапуск сервера отправил бы то же письмо ещё раз. Пометка «уже сделано» ставится и тогда, когда отправка не удалась: письмо, которое не пришло, лучше, чем круг, который каждую минуту отправляет новое.

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

Передача сбрасывает статус на «Open». Строки истории об этом внутренние; клиент видит на заявке только новый статус и новую команду.

В разделе «Reports» вы выбираете период и нажимаете «Generate report»: без этого щелчка страница остаётся пустой. Отчёт тогда содержит блок «Service level agreements» с одной строкой на цель: соблюдено, нарушено, ещё идёт, достигнутая доля и среднее использованное время.

Считают по целям, а не по заявкам, и под таблицей об этом тоже написано. Заявка с обеими целями поэтому появляется дважды, по разу в каждой строке.

Достигнутая доля считает только завершённые часы. Идущим в знаменателе не место, иначе каждое только что включённое SLA сначала выглядело бы катастрофой и улучшалось бы само собой. Если ни одних завершённых часов ещё нет, появляется прочерк, а не «0 %».

Если вы работаете с групповыми инцидентами, добавляется строка «Achieved without group incidents»: один групповой инцидент с сотней привязанных заявок иначе искажал бы долю в обе стороны. Она не учитывает ни одной заявки, связанной с групповым инцидентом.

Операторы видят в этом блоке только свои команды. Без Professional блок появляется, только если есть прежние данные о сроках; тогда он остаётся доступным для чтения.