Платформа уведомлений — быстрее реагировать на то, что происходит

7.1 Цель

Уведомления — чтобы важное происходило не только в UI платформы, а там, где команда реально это увидит. Команде нужно быстро узнавать, что происходит с экспериментами, без постоянного ручного мониторинга. Платформа уведомлений должна:

оперативно сообщать о важных событиях (алерты) и информационных апдейтах;
доставлять сообщения в разные мессенджеры/каналы (много форматов);
позволять настраивать “кому/куда/когда” отправлять уведомления.

7.2 События и триггеры

В истории: продакту важно знать про старт/паузы/окончание эксперимента, а Лотти — про срабатывание guardrails и ошибки интеграций.

Жизненный цикл эксперимента
Guardrails (аварийные тормоза)
Данные/качество/производительность

7.3 Каналы доставки

Платформа должна уметь доставлять уведомления в разные каналы — потому что у разных команд разные рабочие привычки и ограничения.

Но делать “все мессенджеры мира” не нужно.

7.3.1 Требование для MVP

Сделать 2–3 канала доставки (минимум 2) по примеру реальных интеграций:

Telegram
Slack
(опционально) Email / Discord / Голубиный протокол

Остальные перечисленные каналы — примеры расширения, их можно добавить позже без переписывания бизнес‑логики.

7.3.2 Архитектурное ожидание

Чтобы новые каналы добавлялись быстро, система должна иметь единый формат сообщения и единый набор обязательных полей для отправки.

Как это выглядит в лоре: когда guardrail срабатывает и эксперимент ставится на паузу, Лотти не хочет узнавать об этом “завтра в дашборде”.
Он хочет, чтобы уведомление сразу прилетело в командный чат — туда, где команда реально живёт.

7.4 Настройка правил уведомлений

В истории: один и тот же триггер может быть важен разным людям по‑разному: продакту — итоговые метрики, инженерам — алерты, аналитикам — качество данных. Платформа должна позволять конфигурировать правила уведомлений:

Каждое правило включает:

источник (эксперимент/флаг/владелец/аккаунт/все эксперименты),
событие/условие (например, сработал guardrail или эксперимент ушёл на ревью),
фильтры (severity, конкретные метрики, окно времени, окружение prod/stage),
получатели (каналы/группы/пользователи),
порог частоты (rate limit) и дедупликация
шаблон сообщения (если нужно кастомизировать).

7.5 Шумоподавление: дедуп, rate limit, группировка

В истории: если платформа заспамит чат, её просто выключат. Поэтому дедуп/группировка — не “хотелка”, а выживание. Важно, чтобы уведомления не превращались в спам.