Пример SJM — деградация цифрового канала

Учебная карта для incident-review: приложение или веб-канал частично работает, но критичный сценарий завершается ошибкой или зависшим статусом.

Назначение и границы

• Старт: клиент выполняет критичное действие в цифровом канале.
• Завершение: сервис восстановлен, клиент понимает статус операции и доступный fallback.
• За рамками: конкретная инфраструктура, если она не подтверждена evidence.

Incident-review

Этап	Наблюдаемый опыт клиента	Что проверить внутри сервиса	Recovery	Метрики	Tooling
1. Действие	Клиент отправляет запрос	Канал, интеграции, внешние зависимости	Не создавать дубль при повторе	Error rate, latency	мониторинг, trace, source of truth
2. Ошибка	Клиент получает ошибку или долгий spinner	Классификация ошибки, correlation ID, мониторинг	Понятное сообщение и безопасный retry	Доля ошибок, тайм-ауты	error catalog, alert rules
3. Переход	Клиент ищет другой канал	Передаётся ли контекст в поддержку	Fallback без повторного объяснения	Доля переходов, повторные обращения	CRM, система обращений, база знаний
4. Восстановление	Клиент проверяет итог	Сверка фактического статуса	Уведомление и corrective action	Время восстановления, reopen rate	incident record, change request

Monitoring и change management

Incident-review должен завершаться не только восстановлением, но и обновлением сервисной модели:

• добавить или уточнить monitoring-signal;
• обновить error catalog и клиентское сообщение;
• проверить, нужен ли новый fallback;
• обновить базу знаний первой линии;
• добавить regression check для критичного сценария;
• создать change request, если причина системная;
• обновить SJM, если фактический путь отличается от ожидаемого.

Defect / RCA / regression слой

Слой	Что делать после деградации
Defect report	описать симптом, ожидаемый результат, фактический результат, условия, trace id, impact и workaround
RCA	отделить клиентский симптом от первопричины: канал, интеграция, очередь, данные, retry, мониторинг, требование
Regression	добавить проверку, которая воспроизводит критичный отказ или защищает исправленную ветку
Automation	настроить synthetic check, alert, SLA timer check или log query там, где ручная проверка запоздает
SJM update	обновить фактический путь клиента, fallback, KB и escalation path

Вопросы для разбора

• Как отличить неуспешный запрос от запроса с неизвестным результатом?
• Где находится источник истины по статусу?
• Не создаёт ли retry дубль операции?
• Есть ли доступный fallback для клиента?
• Какие third-party dependencies участвовали в деградации?
• Требуется ли обновить SJM после инцидента?
• Есть ли alert, который сработал раньше клиентских обращений?
• Как поддержка связывает обращение клиента с инцидентом?
• Нужен ли новый regression test или synthetic monitoring?

Связанные материалы

• SJM — governance и lifecycle карты
• SJM — Европейский союз
• SJM — accessibility и inclusive design
• Инциденты операционной надежности
• Поддержка сопровождение и инструменты сервиса
• Тестирование и качество сервисов
• Управление рисками сервисных изменений
• Дефекты сервиса и RCA
• Автоматизация проверок сервиса