Начать можно с одного сигнала. Для него нужны условие возникновения, адресат, первое допустимое действие и способ подтвердить восстановление. Если одного из этих звеньев нет, сообщение может дойти до человека, но не привести к решению.
Ниже — учебный пример: заявка принята в кабинете, но не обработана в согласованный для процесса срок. Это не описание реального инцидента или действующей системы мониторинга АИС Сокол.
Сначала — действие пользователя
В этом примере клиент ждёт результат принятой заявки, а сотрудник должен завершить её обработку. Сигнал нужен, когда ожидание вышло за установленную для процесса границу. Сам по себе рост числа технических записей или краткий сбой компонента ещё не объясняет, требуется ли человеку вмешаться.
Порядок реакции зависит от последствий. Одно отклонение требует немедленного решения назначенного ответственного, другое можно разобрать в согласованное рабочее время. Режим и замещение определяют до запуска правила; наличие уведомлений не означает круглосуточного дежурства.
В рекомендациях Prometheus об оповещениях предлагается связывать тревогу с заметным пользователю последствием и давать доступ к сведениям для разбора. Это полезный принцип независимо от выбранного инструмента. Он не определяет порог или режим реакции за вашу команду.
Карточка сигнала: порог, адресат и условие снятия
Порог берут из правил рабочего процесса. Для заявки это превышение согласованного срока обработки, а не произвольный процент ошибок. Условие должно подтверждаться в выбранном окне наблюдения по свежим данным. Продолжительность окна определяют с учётом последствий задержки: оно не должно скрывать ситуацию, по которой уже требуется действие.
В учебной карточке порог описан правилом, без универсального количества минут. В конкретном проекте владелец процесса задаёт срок и окно до включения уведомлений.
| Поле | Содержание учебной карточки |
|---|---|
| Рабочий сценарий | Клиент подал заявку в кабинете; сотрудник должен обработать её и зафиксировать результат. |
| Влияние | Клиент ожидает результат после принятия заявки; обработка не завершена в предусмотренный срок. |
| Показатель и порог | Текущая заявка остаётся незавершённой после расчётного срока обработки по правилам процесса. |
| Окно подтверждения | Просрочка сохраняется в согласованном окне наблюдения. Статус и время получения данных позволяют подтвердить это состояние. |
| Условия применимости | Заявка действительно принята и относится к выбранному процессу. Правила для отменённых заявок и ожидания ответа клиента задаются отдельно. |
| Контекст сообщения | Идентификатор заявки, время принятия, расчётный срок, актуальный статус, время наблюдения и часовой пояс. Без личных данных клиента. |
| Основной адресат и замещение | Назначенный ответственный за обработку заявок. При его недоступности — заместитель по согласованному режиму и порядку передачи. |
| Первое действие | Проверить актуальное состояние заявки по инструкции. Не создавать повторную заявку автоматически. |
| Принятие в работу | Ответственный отмечает, что разобрал сигнал и принял его в работу. Это ещё не подтверждение восстановления. |
| Материалы для разбора | График «Срок обработки принятых заявок» и инструкция «Проверка состояния заявки». Названия учебные; в рабочем уведомлении нужны доступные адресату ссылки. |
| Условие снятия | Есть свежие данные о завершённой обработке либо другом допустимом исходе. Ответственный проверил результат и подтвердил выполнение условия снятия. |
| Если данные перестали поступать | Состояние считается неизвестным, а не восстановленным. Проверка поступления данных выполняется по отдельному правилу. |
Уведомление с такой карточкой отвечает на вопрос «что проверить сейчас». Оно не требует сразу установить первопричину. Сотрудник сначала сверяет актуальное состояние: заявка могла быть обработана, пока сообщение шло, либо по ней мог появиться отдельный согласованный исход.
Если срок зависит от типа заявки, паузы или режима работы, это отражают в расчёте. Иначе одинаковая задержка будет ошибочно считаться одинаковым нарушением для разных процессов. Изменение порога согласует владелец процесса, а не только тот, кто настраивает мониторинг.
Доставка, принятие и восстановление — разные события
Отметка о доставке говорит, что сообщение достигло выбранного канала. Она не показывает, что ответственный его увидел и начал разбор. Поэтому отдельно фиксируют принятие в работу и последующее решение.
В уведомлении нужны контекст и первое разрешённое действие. Ссылка на недоступный график, инструкция без нужной версии или неопределённое «разберитесь» оставляют маршрут незавершённым. Доступ адресата к материалам проверяют вместе с самим правилом уведомления.
Если основной ответственный не принимает сигнал, используют заранее согласованный порядок замещения. Его не следует заменять отправкой всем сотрудникам: у сообщения по-прежнему должен оставаться определённый владелец.
Закрытие связывают с состоянием процесса. Для нашей заявки необходимо подтвердить результат обработки по актуальным сведениям. Исчезновение сообщения, отключение правила или прекращение поступления данных этого не доказывает.
Как объединить повторы и не скрыть разные отказы
Для учебного примера повторные сигналы об одной заявке и одном незавершённом шаге можно вести как один инцидент. В нём сохраняют первое наблюдение, дальнейшие изменения, ответственного и актуальный результат. Повтор не должен создавать новую независимую задачу на разбор того же состояния.
Несколько заявок объединяют только при установленной связи их отклонений. Например, при подтверждённой общей проблеме одного шага обработки. В общей записи остаётся перечень затронутых заявок; восстановление одной не закрывает остальные автоматически.
Близкое время сигналов не доказывает общую причину. Ошибка данных в одной заявке и недоступность сервиса для другой могут требовать разных действий. Их нельзя подавить одним фильтром ради меньшего числа сообщений. После группировки должно оставаться понятно, какие состояния ещё требуют решения.
Как проверить весь маршрут уведомления
Проверку планируют в отдельной согласованной среде. В ней создают синтетическую заявку и воспроизводят выход за заданный для теста срок. Используют контрольного получателя; реальные клиентские рассылки и рабочие уведомления в этот сценарий не включают.
До проверки записывают ожидаемое поведение. Матрица ниже — план учебной проверки, а не отчёт о её выполнении.
| Проверяемый шаг | Ожидаемый результат | Что фиксировать |
|---|---|---|
| Условие сработало | Сигнал возникает после подтверждённого превышения срока. Временное отклонение вне правила не считается инцидентом; пропуск данных не означает восстановление. | Состояние заявки, время наблюдения и условие, которое привело к сигналу. |
| Адресат определён | Сигнал попадает контрольному получателю нужной роли. График и инструкция доступны; путь замещения задан. | Получателя, результат доставки и доступность материалов для этой роли. |
| Принято в работу | Ответственный подтверждает принятие и проверяет состояние по инструкции. Повторный сигнал остаётся связанным с тем же инцидентом. | Кто принял, какое первое действие выполнил и какие вопросы остались открытыми. |
| Результат подтверждён | Свежие данные показывают допустимый итог заявки; ответственный подтверждает условие снятия. Одного исчезновения сигнала недостаточно. | Итоговый статус, время наблюдения и решение о закрытии либо продолжении разбора. |
В эту же проверку включают повтор сигнала, недоступность основного адресата и прекращение поступления данных. Так проверяется не только текст сообщения, но и путь от состояния заявки до решения человека. Настоящие адреса получателей и секреты подключения для учебной статьи не нужны.
Что изменить после разбора инцидента
Для каждого разобранного сигнала полезно записать: он помог действовать, оказался лишним или пришёл поздно. Затем проверить причину этой оценки. Был ли обоснован порог? Правильно ли выбрана роль? Хватило ли контекста? Можно ли подтвердить, что процесс восстановлен?
Лишнее сообщение может оказаться повтором, но может указывать на отдельную проблему. Поздний сигнал иногда связан с окном наблюдения, а иногда — с задержкой доставки или неясным замещением. Менять правило стоит по установленной причине, сохраняя возможность заметить существенный отказ.
Сам поиск технической причины — отдельный разбор: «Как разобрать события одной операции».
По теме: Решение о продолжении или остановке выпуска · Границы работ и передача результата.
Для первого обсуждения выберите одно уведомление: какое действие задерживается, кто должен реагировать и по каким сведениям можно подтвердить результат. Обсуждать всю систему мониторинга сразу не обязательно.
