Критичные задачи не теряются
События задач классифицируются, маршрутизируются и доставляются с контролем SLA и журналом повторной отправки.
Сделал: Интеграционный анализ, правила маршрутизации, контроль доставки
ВопросКак событие доходит до человека и где его проверяют?
Событие проходит 3 проверки между 2 источниками и 1 каналом
Критичные задачи получили отдельный SLA-маршрут с логом доставки и повторной отправкой.
Источники событий
- Bitrix24 webhooks
- user mapping file
Приём и правила
- Flask endpoint
- event parser
Состояние и журнал
- mapping JSON
- service logs
Каналы и экраны
- Telegram notifications
Контрольные точки
- Проверка тестовых событий OnTaskAdd/OnTaskUpdate.
- Проверка фильтра important + leader + urgency.
- Проверка доставки Telegram для mapped users.
В заявку попадёт тема Критичные задачи не теряются: как событие доходит до человека и где его проверяют
.
Ситуация
С чего всё начиналось
Сервис слушает события задач, проверяет автора, важность, дедлайн, маршрут эскалации и отправляет targeted Telegram-сообщение.
Критичные задачи терялись в общем потоке уведомлений: не было понятного правила срочности, владельца доставки и диагностики сбоев.
Что изменено
Что я сделал
Описал правила классификации событий, маппинг пользователей, pipeline доставки, диагностику ошибок и деплой через gunicorn.
- Событие должно относиться к важной задаче.
- Создатель задачи должен быть в списке руководителей.
- Задача считается urgent по приоритету или близкому дедлайну.
Что получилось
Результат
Критичные задачи получили отдельный SLA-маршрут с логом доставки и повторной отправкой
- Медианный SLA доставки в demo-контуре показан как 18 секунд.
- Доля доставленных срочных уведомлений контролируется как отдельный KPI.
- Команда получает диагностику пропущенного уведомления по event id, а не ищет его вручную.
Как это проверено
Проверка и границы
- Проверка тестовых событий OnTaskAdd/OnTaskUpdate.
- Проверка фильтра important + leader + urgency.
- Проверка доставки Telegram для mapped users.
интеграционный кейс описан без закрытых токенов, пользователей и задач. не раскрываются реальные workflow клиента и каналы уведомлений.
Техническое приложение
Как устроено внутри
Для тех, кто проверяет решение по существу: источники, слои данных, правила расчёта и артефакты передачи.
Архитектура, данные и методология
Архитектура
| Источники | Bitrix24 webhooks · user mapping file |
|---|---|
| Загрузка | Flask endpoint · event parser |
| Хранение | mapping JSON · service logs |
| Представление | Telegram notifications |
Модель данных
| Объект | Слой | Назначение |
|---|---|---|
| leaders | config | список пользователей, чьи задачи эскалируются |
| telegram_chats | config | сопоставление пользователя и Telegram chat |
Методология и правила
- Спроектировал поток как операционный SLA-контур: событие, классификация, routing, доставка, retry, диагностика.
- Правила срочности вынесены из кода в явные критерии, чтобы их можно было проверять и менять без хаоса.
- Ошибки mapping и доставки стали отдельным сигналом экрана решения, а не скрытым техническим логом.
- Классификация urgency использует автора, приоритет, дедлайн и тип события.
- SLA рассчитывается как время от входящего события до подтверждённой доставки.
- Ошибки группируются по причине: mapping, Telegram response, parsing, retry exhausted.
Артефакты и стек
Integration · Runbook · UAT
Что бы сделал иначе
- Правила эскалации надо делать явными, иначе webhook быстро становится шумным.
- Mapping пользователей лучше отделять от кода.
- Логи важны для разбора пропущенных уведомлений.
Похожая задача?
Расскажите, где у вас расходятся цифры или не хватает картины. Отвечу, чем это лечится и с чего начать.