Диспетчеризация аварий 24/7: приоритеты, дежурства и SLA

Что такое диспетчеризация и где она ломается на практике

Диспетчеризация аварий 24/7 - это единый порядок, по которому сигнал об аварии быстро превращается в понятную задачу для конкретного дежурного, со сроками реакции и восстановления. Цель простая: убрать хаос, когда все одновременно звонят всем подряд, а критичная проблема теряется среди «обычных» обращений.

Сначала важно развести три типа работ.

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

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

Работу диспетчеризации измеряют цифрами, а не ощущениями. Обычно смотрят:

• время реакции (до первого подтвержденного контакта)
• время восстановления (до возврата сервиса)
• долю повторных инцидентов (одна и та же причина)
• точность классификации (сколько раз «перекидывали» между группами)
• соблюдение SLA по приоритетам

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

Типы аварий и границы ответственности

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

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

Категории аварий (пример)

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

• ИТ: недоступность сети, серверов, рабочих мест, критичных приложений
• Инженерия здания: электропитание, отопление, вентиляция, кондиционирование, водоснабжение
• Связь: телефония, радиосвязь, каналы между площадками, интернет-провайдер
• Безопасность: СКУД, видеонаблюдение, пожарная и охранная сигнализация
• Бизнес-сервисы: кассы, платежи, медицинские системы, учебные платформы и другие процессы, которые нельзя останавливать

Заранее закрепите триггеры, по которым диспетчер (без глубокой экспертизы) понимает, что это именно авария. Например: сработало оповещение мониторинга, пришло 3 одинаковых обращения за 10 минут, пропало питание на этаже, не открываются турникеты, остановилась приемка пациентов.

Границы ответственности лучше оформлять не «по ощущениям», а по тому, кто реально чинит. Внутренние службы обычно закрывают первичную диагностику и типовые работы, а подрядчики - узкие зоны (лифты, пожарка, провайдер, вендор ПО). Для каждого домена нужна лестница эскалации: основной исполнитель, резерв и контакт подрядчика с условиями выезда.

Минимум данных для классификации при регистрации

Чтобы выбрать категорию и применить правильный SLA, диспетчеру обычно достаточно:

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

Пример: «Не открываются турникеты на входе, 20 человек не могут пройти, началось 08:10, охрана на месте, ручной режим не включается». Это сразу попадает в безопасность, с понятной ответственностью и быстрым вызовом дежурного.

Приоритеты: понятные правила вместо споров

Когда приоритеты не закреплены, диспетчер тратит время на обсуждения вместо реакции. В диспетчеризации аварий 24/7 лучше всего работает простая матрица: влияние x срочность. Она дает одинаковый ответ для всех смен.

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

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

Уровни P1-P4

Четырех уровней обычно достаточно:

• P1: критично, бизнес остановлен или есть риск безопасности
• P2: сильно мешает работе ключевых групп; обходной путь есть, но с потерями
• P3: локальная проблема; обходной путь есть, сроки терпят
• P4: запросы и мелкие дефекты без срочности

Когда приоритет можно менять

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

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

Эскалация должна быть привязана к минутам. Например: P1 - уведомить дежурного инженера и руководителя в течение 5 минут, P2 - в течение 15 минут, P3 - в течение 60 минут, P4 - по расписанию работ.

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

SLA по типам аварий: что закрепить в регламенте

SLA нужен не для отчета, а чтобы в момент стресса не спорить, что делать первым и когда «уже поздно». В диспетчеризации аварий 24/7 SLA обычно распадается на три части: время реакции, время восстановления и частота обновления статуса.

Три таймера вместо одного

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

Зафиксируйте минимум:

• реакция: когда дежурный обязан принять в работу и подтвердить, что авария в обработке
• восстановление: когда сервис снова доступен пользователям (или действует временное решение)
• обновления: как часто вы даете статус и кому (даже если «новостей нет»)
• часы действия: 24/7 или только рабочее время для части систем
• критерии закрытия: что именно проверяем и кто подтверждает результат

Разные SLA для разных типов аварий

Одинаковые цифры для всех случаев рождают «подгонку» и конфликты. Разделите хотя бы по типам и критичности, а внутри дайте несколько примеров.

Пример простого набора (цифры подставьте свои):

• сеть/канал связи для критичного объекта: реакция 10 мин, восстановление 2 ч, статус каждые 30 мин
• сервер/виртуализация: реакция 15 мин, восстановление 4 ч, статус каждый час
• рабочие места (единичный ПК): реакция 1 ч, восстановление 1 рабочий день, статус 1 раз в день
• печать/периферия: реакция 2 ч, восстановление 2 рабочих дня, статус по запросу
• бизнес-система (почта, ЭДО, МИС): реакция 15 мин, восстановление по уровню влияния (частично/полный простой)

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

Отдельной строкой назначьте владельца коммуникаций: кто пишет пользователям, кто информирует руководство, какой канал считается официальным. Нарушение SLA фиксируйте как факт в карточке (таймлайн, причина, что помешало, что изменим) без поиска виноватых. Тогда SLA начинает улучшать процесс, а не прятать проблемы.

Дежурства 24/7: роли, графики и резерв

Чтобы диспетчеризация аварий 24/7 работала без срывов, ответственность нужно разложить по ролям и сделать так, чтобы любой звонок упирался не в одного человека, а в понятную цепочку.

На смене обычно достаточно пяти ролей, даже если часть людей совмещает функции:

• диспетчер: принимает сигнал, фиксирует данные, запускает маршрутизацию и таймеры
• L1: первичная диагностика и простые действия по чек-листу
• L2: глубокая диагностика, сложные изменения, координация с подрядчиками
• on-call: узкие специалисты, которых поднимают только по условиям
• руководитель смены: решения по рискам и эскалациям, если спорят приоритеты

График выбирайте от нагрузки и «времени подъема» специалистов. Для диспетчера чаще подходят 2/2 или неделя через неделю. Для узких специалистов удобнее 1/3 (on-call) с обязательным резервом. В любом варианте нужен резервный дежурный, который заранее знает, что он резерв, и на каких условиях его поднимают.

Контакт-лист держите в одном формате: ФИО, роль, направления, основной телефон, резервный телефон, мессенджер, время доступности, замены на отпуск. Минимум раз в месяц делайте короткую проверку доступности: тестовый звонок или сообщение и отметка «доступен».

Правило двух контактов: по каждому направлению (сети, серверы, рабочие места, бизнес-приложения) всегда есть основной и резервный. Если основной не отвечает, это не «проблема диспетчера», а заранее описанный сценарий. Например: 5 минут - повторный вызов и сообщение; 10 минут - подъем резервного; 15 минут - эскалация руководителю смены; дальше - действие по регламенту и фиксация причины недоступности для разбора.

Пример: ночью пропадает доступ к серверу. Диспетчер поднимает L1, параллельно ставит таймер на on-call по серверам, а при молчании основного on-call через 10 минут поднимает резервного. Так авария не «висит» на одном номере и меньше зависит от человеческого фактора.

Маршрутизация: как заявки попадают к нужному человеку

Маршрутизация держится на принципе «одна дверь»: у инцидента есть единая точка входа, а дальше он идет по понятным рельсам. Когда входов много (телефон, почта, чат, портал, мониторинг), люди начинают дублировать обращения, а дежурные теряют время на уточнения. В диспетчеризации 24/7 лучше закрепить так: все каналы допустимы, но регистрация всегда идет в одной системе и по одному правилу.

Правила маршрутизации

Сделайте так, чтобы диспетчер не выбирал «на глаз», а следовал матрице. Часто хватает четырех параметров: тип, локация, время, приоритет.

Тип - сеть, рабочее место, сервер, прикладная система, инженерия (если в зоне ответственности). Локация - объект, этаж, кабинет, стойка/шкаф, филиал. Время - рабочее/нерабочее, ночная смена, выходные и праздники. Приоритет - P1-P4 с привязкой к влиянию.

После выбора ветки матрица должна выдавать конкретного исполнителя (или группу), резерв и способ связи. Если ветка не определена, правило одно: назначить на «дежурного координатора» и в течение 10 минут уточнить владельца.

Прием обращения: короткий шаблон вопросов

Чтобы не терять ключевые данные, держите у диспетчера пять обязательных вопросов:

• что именно не работает и для кого (1 человек, отдел, весь филиал)
• где это происходит (адрес/объект, кабинет, оборудование)
• когда началось и что менялось перед сбоем
• есть ли обходной путь и насколько срочно восстановление
• контакт для обратной связи и кто может подтвердить восстановление

Если инцидент приходит из мониторинга, часть полей лучше заполнять автоматически: источник, имя узла, метрика/алерт, время, локация, предполагаемый сервис, первичный приоритет, вложение (скрин/лог). Иначе диспетчер тратит время на «расшифровку» алерта.

Для P1 заранее определите список оповещения: дежурный инженер, руководитель смены, владелец сервиса, ИБ (если влияет) и представитель бизнеса. Обновления статуса задайте ритмом (например, каждые 15 минут) до стабилизации, даже если прогресса нет: «идет диагностика, следующее обновление в 10:15».

Пошаговый процесс: от сигнала до закрытия инцидента

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

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

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

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

Во время диагностики цель номер один - вернуть сервис, даже временно. Например, при падении стойки с сервером можно поднять сервис на резервном узле, переключить пользователей на альтернативный канал или ограничить функциональность. Если нужен вендор или смежники, их подключают по заранее заданной лестнице.

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

После восстановления нужна проверка и закрытие с кратким итогом: что было, что сделали, что осталось. Для P1-P2 обязателен разбор и 1-2 меры, которые реально снижают повторение (например, корректировка мониторинга, замена узла, правка инструкций, обучение дежурных).

Шаблон карточки инцидента: поля и формулировки

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

Обязательные поля (минимум)

Набор держите коротким, но достаточным, чтобы можно было работать без лишних звонков:

• идентификатор и время: номер, время создания, канал (мониторинг, звонок, почта), кто зарегистрировал
• контакт и место: инициатор, телефон, локация (город, объект, кабинет/стойка), затронутые пользователи/подразделение
• что не работает: сервис/система, краткий симптом, точное время начала (или «обнаружено в 02:15»)
• классификация: тип аварии (сеть/сервер/приложение/рабочее место), приоритет (P1-P4), критичность сервиса
• SLA и контроль времени: дедлайны реакции/обновлений/восстановления, время первого ответа, время назначения исполнителя

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

Чтобы карточка не заканчивалась фразой «вроде работает», заполняйте финал: причина (если известна), временное решение (workaround), постоянное решение (как предотвратить повтор) и 1-2 урока (например, «не хватало контакта владельца сервиса» или «порог алерта был слишком высоким»).

Пример формулировок статуса (коротко и без двусмысленности)

Единый стиль снижает споры и количество уточняющих звонков:

• «P1. Нет доступа к сервису X в локации Y с 02:15. Назначен: Иванов. Следующее обновление в 02:40.»
• «Причина уточняется. Выполнено: перезапуск службы, без эффекта. Запрошены логи у дежурного по площадке.»
• «Обходной путь: перевели пользователей на резервный канал. Сервис частично восстановлен.»
• «ETA восстановления: 40 минут (оценка). Риск: возможны повторные разрывы соединения.»
• «Инцидент закрыт в 04:05. Постоянное решение: замена SFP, проверка линии. Предотвращение: добавить контроль ошибок порта.»

Передача смены: правила, журнал и контрольные вопросы

Передача смены должна быть предсказуемой. Лучше всего работает фиксированное время (например, 08:00 и 20:00) и правило 15 минут: сдающая смена готовит сводку заранее и остается на связи еще 15 минут после начала следующей смены, чтобы закрыть вопросы без спешки.

Ключевой принцип: ответственность за инциденты переходит только после понятного подтверждения. Если принимающая смена не сказала «принял», значит инцидент остается на сдающей.

По каждому открытому инциденту P1-P4 передайте одинаковый минимум:

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

Журнал смены ведется в одном месте и обновляется по факту изменений, а не «в конце». За актуальность отвечает диспетчер текущей смены; принимающая смена отвечает за то, что запись понятна и достаточна.

Статусы лучше договорить заранее и использовать одинаково. «В работе» - есть назначенный исполнитель и идет активное действие. «Ждем подрядчика» - запрос отправлен, есть контакт и обещанное время ответа. «Наблюдение» - сервис восстановлен, но идет контроль по метрикам/повторяемости и задан срок наблюдения.

Контрольные вопросы принимающей смены помогают поймать пробелы: какой самый критичный инцидент и почему; что должно измениться в ближайшие 30-60 минут; у каких инцидентов жесткий SLA-таймер или окно работ; где нет подтверждения от подрядчика или владельца сервиса; что делаем, если ситуация ухудшится (план Б и кому звонить).

Типовые ошибки и как их избежать

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

Приоритет по эмоциям

Если приоритет ставят по громкости звонка, а не по правилам, спор начинается сразу, а время уходит. Исправление простое: закрепите 3-4 приоритета и критерии в одном месте (влияние, масштаб, риск, наличие обходного решения) и требуйте указывать причину выбора приоритета одной фразой в карточке.

Нет единой точки входа

Когда обращения приходят одновременно в мессенджер, на почту и «просто позвонили инженеру», они дублируются или пропадают. Назначьте один обязательный вход (диспетчер/единый номер/единый ящик), а остальные каналы оставьте для уведомлений. Все обращения без регистрации возвращайте в точку входа.

Слишком много ручных пересылок

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

SLA без таймеров и статусов

SLA на бумаге не работает, если нет статусов и контрольных точек. Введите минимум: «Принято», «В работе», «Ожидание клиента/подрядчика», «Восстановлено», «Закрыто». Таймеры должны измерять реакцию и восстановление, а паузы учитываться отдельно.

Закрывают без подтверждения и причины

Если закрывать «чтобы очистить очередь», повторы растут. Закрывайте только после подтверждения (или истечения оговоренного окна) и с краткой причиной: что сломалось, что сделали, как предотвратить.

Дежурные недоступны

Недоступность дежурного - нормальный риск, а не форс-мажор. Проверьте, что у вас есть резерв на каждую роль, правило эскалации через фиксированное время, проверка доступности в начале смены, актуальные контакты и зоны ответственности, короткий «план Б» для критичных сервисов.

Пример: ночью падает сервер в больнице. Диспетчер ставит P1 по критерию «остановка ключевой услуги», запускает таймер реакции, назначает основную группу, и если нет ответа за 10 минут - уходит на резерв и руководителю смены. Инцидент не зависает на одном человеке.

Быстрые проверки и следующие шаги

Запуск диспетчеризации аварий 24/7 часто ломается не на «сложных» местах, а на мелочах: не тот номер, нет резервного, спорят о приоритете, забыли зафиксировать передачу смены. Начните с быстрых проверок, которые реально сделать за 1-2 часа.

Для старта хватит короткого чеклиста:

• каналы связи: единый телефон, чат, почта, мониторинг и понятные правила, что считается «официальным» обращением
• роли: диспетчер, дежурный инженер, руководитель смены, владелец сервиса и резерв на случай недоступности
• приоритеты: 3-4 уровня (например, P1-P4) и 2-3 признака для каждого
• SLA: время реакции и время восстановления по типам аварий, плюс что делать при нехватке данных от заявителя
• журнал смены: где фиксируются открытые инциденты, риски, работы и кому что передано

Дальше раз в неделю проверяйте 3-5 цифр: долю просрочек по SLA (отдельно по P1 и по остальным), медианное время реакции и 90-й процентиль (чтобы видеть «хвост»), повторные инциденты по одной причине за 7 дней, сколько раз срабатывала эскалация из-за недоступности дежурного.

Мини-сценарий для тренировки смены: в 02:10 приходит P1 (упал ключевой сервис), а в 02:20 и 02:40 приходят два P3 (частичная деградация у разных пользователей). Проверьте, что диспетчер фиксирует P1, запускает оповещение и эскалацию, назначает ответственного, ставит контрольные точки по времени и параллельно «паркует» P3 с понятным временем первого ответа. К концу смены должно быть ясно: что сделано, что не сделано и почему, какие риски остались.

Если вы только настраиваете процесс, начните с пилота на одном объекте или одном сервисе. За 2-4 недели вы соберете реальные данные по нагрузке, уточните приоритеты, отточите маршрутизацию инцидентов и правила передачи смены. После этого переносите модель на остальные площадки, не меняя основы: роли, SLA, журнал, эскалации.

Следующие шаги часто упираются в инфраструктуру под 24/7: рабочее место диспетчера, надежные ПК и мониторы, гарнитуры, резервное питание и связь, а также серверы и хранение для систем мониторинга и учета. Если нужна помощь с проектированием и внедрением процесса вместе с инфраструктурой, эту часть логично делать вместе с системным интегратором, который закрывает и оборудование, и поддержку. Например, GSE.kz (gse.kz) работает как производитель компьютерной техники в Казахстане и системный интегратор, поэтому может помочь с подбором рабочих станций и серверов под круглосуточные службы, а также с организацией поддержки и регламентов под вашу сеть объектов.