Центр коммуникаций при сбоях

Что это за сервис

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

Без него во время сбоя три команды сидят в трёх разных чатах. Агенты отвечают на входящие, не зная, что разработка уже чинит проблему, и один сбой рождает десятки дублирующих эскалаций. Страница статуса обновляется вручную и отстаёт от реального положения дел, при смене дежурных теряется контекст, а разбор после инцидента собирают по истории чатов.

Первая версия — запись о сбое, хронология и шаблон ответа. Автоматическую привязку обращений и отправку на страницу статуса добавляют после нескольких реальных сбоев.

Что он делает

Держит одну запись о сбое. Статус, затронутые сервисы, влияние на клиентов, ответственный и хронология видны поддержке и разработке одинаково.
Привязывает обращения к сбою. Входящие обращения по затронутому сервису, ключевым словам или времени автоматически отмечаются как связанные, и дубли эскалаций не создаются.
Даёт агентам готовый ответ. Шаблон с текущим статусом и ожидаемым временем следующего обновления подставляется в ответ клиенту.
Обновляет страницу статуса. Смена статуса в записи отправляет обновление на публичную страницу без отдельного ручного шага.
Собирает хронологию для разбора. Смены статуса, владельца и заметки передачи складываются в ленту, по которой пишется разбор после инцидента.

Нюансы и особенности

Без ответственного сбой не двигается. Перевести запись из «Открыт» в «Расследуется» можно только после назначения ответственного. Это правило важнее любого интерфейса.
Это не замена центру управления инцидентами. Техническое расследование, дежурства и связь сервисов ведёт разработка в своём инструменте — например, в центре управления инцидентами. Здесь — сторона клиента: обращения, ответы и внешние сообщения. Запись о сбое связывают с инцидентом разработки по идентификатору, а не дублируют.
Страница статуса остаётся отдельным продуктом. Statuspage, Instatus и аналоги продолжают обслуживать публичную сторону. Панель лишь отправляет им обновления через API, и каждый отправленный текст сохраняется в журнале.
Правила привязки проверяют на истории. Слишком широкое правило по ключевым словам привяжет к сбою посторонние обращения. Правила хранят как настройки сбоя, а автоматическую привязку агент может отменить.
Частичное восстановление. Если сбой затрагивает несколько сервисов, статус ведут для каждого отдельно, и запись не закрывается, пока не восстановлен последний.
Передача дежурства — с заметкой. Смена ответственного невозможна без записи о текущем состоянии и следующем шаге.
Роли и поля. Агент видит влияние на клиентов и шаблоны ответов, разработка — технические детали, руководитель — всё. Ограничение действует на сервере, включая выгрузку для разбора.
Когда хватит готового. Если сбои редки, а help desk умеет связывать обращения с «проблемой» (как Zendesk или Freshdesk), отдельный центр не нужен.

Как сгенерировать через ИИ-агентов

Промпты рассчитаны на AI-агента (Claude Code, Cursor и аналоги) в Laravel-проекте с установленным Filament 4.x. Отправляйте их по одному и проверяйте результат каждого шага.

1. Данные

Создай модели и миграции для центра коммуникаций при сбоях: Outage (название,
статус, влияние на клиентов, ответственный, внешний id инцидента разработки,
начало, окончание), Service (название), связь «многие ко многим» сбоя
и сервисов со статусом по каждому сервису, OutageUpdate (сбой, автор, текст
для клиентов, внутренняя заметка, отправлено на страницу статуса, время),
TicketLink (сбой, внешний id обращения, привязано автоматически да/нет).
Добавь фабрики с демо-данными.

2. Карточка сбоя и хронология

Сгенерируй Filament-ресурс для Outage. В карточке покажи статус по каждому
сервису, ответственного, число связанных обращений и ленту OutageUpdate.
Перевод из «Открыт» в «Расследуется» запрещён без ответственного. Смена
ответственного требует заметки о передаче. Сбой закрывается, только когда
все сервисы восстановлены.

3. Привязка обращений и шаблоны ответов

Добавь к сбою правила привязки: затронутые сервисы, ключевые слова и окно
времени. Сделай фоновую задачу, которая проверяет новые обращения из API
help desk по активным правилам и создаёт TicketLink. Агент может отменить
привязку. Для агентов выведи шаблон ответа клиенту с текущим статусом
и временем следующего обновления.

Проверьте правила на обращениях за прошлый день: посторонние не должны привязаться.

4. Страница статуса

При публикации OutageUpdate с отметкой «для клиентов» отправляй текст на
страницу статуса через её API в фоновой задаче с повторами при ошибке.
Результат отправки сохраняй в записи обновления.

5. Роли и разбор после инцидента

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