Проектирование SLA-календарей, устойчивых к смене графика и праздникам

В любом внедрении ITSM наступает момент — обычно примерно через шесть недель после запуска, — когда руководитель службы поддержки отправляет директору по ИТ первый квартальный отчёт по SLA и тихо замечает, что цифры не сходятся. Не сильно — процентный пункт тут, подозрительное нарушение там, — но не сходятся. Схема всегда одна и та же: инцидент, открытый в 16:55 в пятницу перед Курбан-байрамом, помечен как нарушение в понедельник утром, хотя на самом деле в эти дни ни один специалист не работал. Политика SLA гласила «с 9 до 17, с понедельника по пятницу», календарь показывал, что Рамазан-байрам выпадает на среду, и где-то между этими двумя фактами заявка провалилась в щель.

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

Наивный вариант по умолчанию: «с 9 до 17, с понедельника по пятницу»

Большинство инструментов ITSM «из коробки» предлагают SLA-календарь рабочих часов, который выглядит так:

• С понедельника по пятницу, с 09:00 до 17:00.
• Выходные исключены.
• Короткий список «государственных праздников», который кто-то должен помнить обновлять каждый декабрь.

Это нормально для небольшой компании, где вся ИТ-команда живёт в одном городе, работает по одному графику и уходит в отпуск в одни и те же дни. Для всех остальных случаев это не работает. В реальном мире как минимум четыре категории сложностей ломают эту модель уже в первый год:

1. Праздники, которые сдвигаются — большинство турецких религиозных праздников привязаны к лунному календарю и смещаются на 10–11 дней раньше каждый год.
2. Модели смен — круглосуточный центр сетевых операций (NOC) вообще не соблюдает «рабочие часы».
3. Отпуска технических специалистов — часы SLA продолжают идти независимо от того, находится ли назначенный специалист на месте.
4. Мультирегиональные операции — Стамбул открывается в 09:00 по Europe/Istanbul; Лондон открывается в 09:00 по Europe/London; заявке уровня P1 нет до этого дела.

Разберём каждую по очереди.

1. Турецкие государственные праздники — не фиксированные даты

В официальном турецком календаре праздников есть два типа дней:

• Фиксированные гражданские праздники. Новый год (1 января), День национального суверенитета и детей (23 апреля), День труда и солидарности (1 мая), День памяти Ататюрка, молодёжи и спорта (19 мая), День демократии и национального единства (15 июля), День победы (30 августа), День республики (29 октября). Это простые правила по датам.
• Подвижные религиозные праздники. Рамазан-байрам (3,5 дня) и Курбан-байрам (4,5 дня) определяются по хиджрийскому лунному календарю и сдвигаются каждый григорианский год. В 2026 году Рамазан-байрам проходит с 20 марта (неполный день) по 23 марта; в 2027 году он начнётся около 10 марта. Курбан-байрам в 2026 году проходит с 27 мая (неполный день) по 31 мая; в 2027 году — около 17 мая.

Правило неполного дня имеет значение. Совет министров регулярно объявляет рабочий день, предшествующий байраму, официальным неполным днём (арефе), когда государственные учреждения закрываются в 13:00. Службы поддержки частного сектора действуют по-разному — одни следуют государственному неполному дню, другие работают полный день, третьи закрываются полностью. Какую бы политику ни принимала ваша организация, SLA-календарь должен кодировать её явно. Неполный день — это не «половина рабочих часов»; это конкретное окно, которое начинается в обычное время открытия и заканчивается в 13:00.

Помимо этого, президентство Турции время от времени объявляет внеплановый выходной — день после победы национальной сборной по футболу, экстренный день траура или «мостик» между фиксированным праздником и выходными. Такие дни невозможно заранее загрузить ни в один календарь. Модель SLA-календаря должна поддерживать добавление разового праздника с предупреждением за 24 часа без пересчёта истории.

Любой SLA-календарь, для добавления праздника в который инженеру требуется повторно развернуть код, откажет уже в первый год эксплуатации. Календарь должен быть данными, а не конфигурацией.

2. Модели смен — это не «рабочие часы»

У круглосуточного центра сетевых операций нет рабочих часов. У него есть смены. SLA-календарь для круглосуточной службы должен полностью отличаться от календаря для службы, работающей с понедельника по пятницу. И в большинстве реальных организаций сосуществуют оба варианта — круглосуточный NOC обрабатывает инфраструктурные инциденты P1, а служба с графиком 09–18 обрабатывает заявки уровня L1. Использовать один календарь для обоих нельзя.

Три паттерна смен, которые мы моделируем чаще всего:

• Стандартная дневная смена. Пн–пт, 09:00–18:00, с часовым окном на обед, которое не приостанавливает часы SLA (специалисты намеренно перекрывают обеденное время друг с другом).
• Расширенный рабочий день. Вс–чт (для служб финансового сектора, чья рабочая неделя идёт с воскресенья по четверг), 07:00–21:00.
• Круглосуточная ротация. Трёхсменный график 24/7 с передачей смены в 08:00, 16:00 и 00:00. Часы SLA идут непрерывно; передача смены невидима для клиента.

Правильная модель календаря привязывается к политике SLA, а не к службе поддержки в целом. Инфраструктурный инцидент P1 измеряется по круглосуточному календарю; заявка P4 «пожалуйста, добавьте меня в групповой почтовый ящик» измеряется по календарю 09–18. Одна и та же организация, два календаря, маршрутизация по каждой отдельной заявке.

3. Отпуска технических специалистов — спор, который никто не хочет вести

Вот вопрос, который рано или поздно всплывёт на совещании по разбору SLA: заявка уровня P2 была назначена на Айше в пятницу днём. Следующий понедельник Айше взяла как ежегодный отпуск. Часы SLA продолжали идти. Она решила заявку во вторник утром, через четыре рабочих часа после своего возвращения, и отчёт показывает нарушение. Справедливо ли это?

Есть две точки зрения:

1. Точка зрения клиента. Клиент не знает и не заботится о том, что Айше была в отпуске. SLA обещает ответ в течение X рабочих часов; ответ пришёл с опозданием; SLA нарушен. Первопричина: маршрутизация должна была переназначить заявку с Айше в момент оформления отпуска.
2. Точка зрения команды. Если отпуск технического специалиста не приостанавливает SLA, службы поддержки с высоким уровнем использования отпусков выглядят искусственно хуже служб, отговаривающих сотрудников от отпусков. Это извращённый стимул.

Наша рекомендация и модель, которую мы строим по умолчанию:

• Отпуск технического специалиста не приостанавливает SLA по назначенной заявке.
• Вместо этого система календаря инициирует переназначение, когда отпуск специалиста начинается при наличии активных заявок в его очереди.
• Переназначенная заявка сохраняет свой исходный SLA и исходные часы.
• Руководитель получает предупреждение в момент запроса отпуска, если у специалиста есть заявки, чья цель по SLA попадает внутрь периода отпуска.

Это вынуждает к правильному поведению: планирование отпусков — управленческая ответственность, а отчёт по SLA отражает опыт клиента, а не внутреннюю расстановку кадров. Стимул команды сохраняется, потому что перемещаются заявки, а не приостанавливаются часы.

4. Тихие часы для каждого пользователя

Отдельное, но смежное понятие: некоторые организации хотят обещать клиенту «ваша заявка получит ответ в течение четырёх рабочих часов», одновременно обещая техническому специалисту «вы не будете получать push-уведомления между 22:00 и 07:00, даже если SLA-календарь активен». Современная ITSM-система должна моделировать это раздельно.

Различие такое:

• SLA-календарь = обещание бизнеса клиенту. Определяет, когда идут часы.
• Календарь уведомлений на пользователя = личное предпочтение технического специалиста по push/email. Определяет, завибрирует ли телефон.

Эти два понятия будут конфликтовать. Инцидент P1, открытый в 03:00 по круглосуточному календарю, — это настоящее нарушение, если его никто не подхватит. Если у всех дежурных специалистов отключены уведомления, заявка простаивает до 07:00, и четырёхчасовые часы клиента истекают. Ответ — не объединять эти два понятия, а моделировать дежурную ротацию как отдельный календарь, который перекрывает личные тихие часы на время дежурства.

5. Мультирегиональность и часовые пояса

Организация с офисами в Стамбуле, Анкаре и Лондоне не имеет одного рабочего дня — у неё их три, накладывающихся друг на друга. Если SLA-календарь хранится в локальном времени сервера, переходы на летнее/зимнее время дважды в год будут незаметно ломать отчётность. Если он хранится в UTC, рабочие часы будут выглядеть смещёнными для пользователей в других часовых поясах, если интерфейс не позаботится об этом.

Наше правило: все записи календаря хранятся в UTC, и у каждого календаря есть собственный часовой пояс отображения. Расчёт SLA выполняется относительно UTC; интерфейс отображает данные относительно часового пояса календаря. Пользователи в другом часовом поясе всё равно видят правильное время открытия для того календаря, на который смотрят.

Заявка P1, поданная в 08:55 по Europe/Istanbul по стамбульскому календарю, находится внутри рабочих часов. Та же заявка, поданная в 08:55 по Europe/London по лондонскому календарю, ещё не находится внутри рабочих часов (Лондон открывается в 09:00 GMT = 11:00 по Europe/Istanbul зимой, 12:00 летом). Именно маршрутизация решает, какой календарь применяется.

6. Окна экстренных изменений

Управление изменениями добавляет ещё одну сложность. Экстренное изменение в производственной системе может потребовать от службы поддержки приостановить SLA по любой заявке, решение которой зависит от этой системы. Это единственный законный случай приостановки SLA, инициированной менеджером.

Правило, которое мы реализуем:

• Экстренное изменение — это полноценный объект с окном начала и окончания.
• Любая заявка, помеченная как зависит от КЕ X, где КЕ X затронута изменением, получает приостановку часов SLA на время окна изменения.
• Пауза регистрируется вместе с идентификатором изменения, чтобы след аудита показывал, какая именно заявка была приостановлена ради какого именно изменения.
• Когда изменение закрывается, все приостановленные заявки возобновляются автоматически.

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

Собираем всё вместе

Полная модель календаря на уровне сущностей выглядит так:

Это отдельные сущности, и взаимодействуют они предсказуемо. Расчёт SLA читает WorkCalendar плюс WorkCalendarHoliday плюс WorkCalendarOverride плюс SlaPauseWindow. Уровень уведомлений читает OnCallRotation плюс UserSilentHours. Отчётность может нарезаться по календарю, по причине паузы или по причине нарушения — потому что каждая единица информации хранится, а не выводится косвенно.

Почему это важно для отчётности

Хорошо спроектированный календарь отвечает на вопрос, который рано или поздно возникает на втором или третьем квартальном обзоре: почему заявка №4728 нарушила SLA? Ответ должен быть чем-то большим, чем «просто нарушила». В идеале, при открытии заявки видна панель SLA, и эта панель показывает, какой именно календарь применялся, какие окна были открыты, какие паузы происходили и сколько рабочих минут прошло до ответа. Если пауза была вызвана изменением, идентификатор изменения связан с ней. Если специалист был в отпуске и заявка была переназначена, переназначение отображается в хронологии.

Смысл правильного моделирования этого — не перфекционизм. Дело в том, что отчёты по SLA подвергаются тщательной проверке. Когда директор по ИТ спрашивает, почему упал показатель соответствия по P2, у операционной команды либо есть обоснованный ответ — с конкретными заявками, календарями и паузами, которые вызвали изменение, — либо его нет, и тогда отчёт по SLA становится предметом сомнений, а не инструментом.

Реализация в LinaDesk, вкратце

LinaDesk моделирует каждую из сущностей в таблице выше как полноценный агрегат домена. WorkCalendar — это якорь; WorkCalendarHoliday и WorkCalendarOverride — дочерние записи; SlaPolicy ссылается на WorkCalendarId. Расчёт SLA — это чистая функция от переходов статуса заявки и сущностей календаря, видимых на момент каждого перехода. Поскольку паузы хранятся как явные записи, повторный расчёт SLA для любой исторической заявки сегодня даёт тот же результат, что и в день её закрытия, — а это именно то, чего хотят команды аудита, и то, что неверно для ITSM-систем, пересчитывающих значения относительно текущего календаря.

Заявка о Рамазан-байраме в начале этой статьи в такой модели — не нарушение. Заявка открывается в 16:55 в последний рабочий день перед байрамом. WorkCalendarHoliday на четыре дня байрама переводит календарь в статус «закрыто». Часы SLA отсчитывают лишь оставшиеся пять рабочих минут до 17:00 той пятницы, а затем возобновляются в 09:00 в первый рабочий день после байрама. Окно ответа сохраняется.

Похожие материалы

• Почему локальные ITSM-системы переживают подъём в 2026 году
• Переход с ManageEngine Service Desk Plus — практическое руководство
• LinaDesk против ServiceNow, ManageEngine, Freshservice — таблица сравнения
• Безопасность и соответствие LinaDesk