Передача смены техподдержки: чек-лист и шаблон записи

Что действительно нужно передавать

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

Разделяйте передачу всей смены и передачу управления крупным инцидентом. Во втором случае особенно важно явное подтверждение нового ответственного — такой принцип описан в Google SRE. Предлагаемый ниже чек-лист переносит его на повседневную работу поддержки.

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

Шаблон одной записи

Заявка / ссылка:
Услуга и текущее влияние:
Что подтверждено:
Что уже проверено и с каким результатом:
Что выполняется сейчас / чего нельзя повторять:
Следующий шаг и условие его запуска:
Кому и к какому времени обещано обновление:
Внешняя сторона / номер её обращения:
Передаёт → принимает, время и часовой пояс:
Подтверждение приёма:

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

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

Пример: зависла выгрузка заказов

Учебный случай: в 17:40 передаётся обращение по выгрузке заказов. В карточке записано: «Новые заказы принимаются, передача на склад задержана с 17:10. Повторный запуск не выполнять: предыдущий ещё работает. Поставщик проверяет задачу EXT-42. В 18:00 запросить статус; до 18:15 сообщить руководителю склада результат, даже если восстановления нет».

Принимающий специалист проверяет доступ к карточке поставщика и уточняет, как распознать завершение выгрузки. Затем пишет: «Принял, следующий контроль в 18:00 МСК». При отсутствии ответа передача не считается завершённой: нужен резервный контакт из графика дежурств.

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

Как встроить передачу в график

1. Заранее обновите карточки и выделите обращения с риском.
2. Оставьте пересечение смен, достаточное для вопросов; длительность определите по реальной нагрузке.
3. Пройдите критичные записи голосом, если письменного контекста недостаточно.
4. Получите подтверждение и обновите владельцев работы.
5. Сообщите участникам активного инцидента, кто теперь координирует действия.

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

Как проверить качество передачи

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

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

Источники и границы рекомендаций

Материал подготовлен 23 сентября 2026 года. Приведённые шаблоны и примеры предлагаются для адаптации под вашу службу поддержки; это не обязательные требования стандарта.

• Google SRE: Managing Incidents — роли, журнал и передача ответственности