Дефекты сервиса и RCA

Сервисный дефект — это расхождение между ожидаемым и фактическим поведением всей цепочки доставки сервиса. Это может быть баг приложения, неверное требование, неполная KB-статья, сломанная маршрутизация, недоступные данные первой линии, неправильный SLA timer, неотправленное уведомление или неработающий recovery.

Идея из SJM Source - Куликов Базовый курс 2023: хороший defect report помогает быстрее устранить проблему и снизить вероятность повторения. Для сервисной модели это означает, что отчёт должен быть полезен не только разработчику, но и владельцу сервиса, поддержке, операционному менеджеру и команде изменений.

Жизненный цикл сервисного дефекта

stateDiagram-v2
    [*] --> Обнаружен
    Обнаружен --> Назначен: triage
    Назначен --> Исправлен: fix/process update
    Исправлен --> Проверен: verification
    Проверен --> Закрыт: accepted
    Исправлен --> Открыт_заново: reproduced again
    Проверен --> Открыт_заново: regression failed
    Обнаружен --> Отклонён: not a defect/duplicate
    Назначен --> Отложен: deferred
    Отложен --> Назначен: resumed
    Закрыт --> Открыт_заново: повторное проявление

Поля сервисного defect report

Поле	Что писать
Краткое описание	что произошло, где и при каких условиях
Подробное описание	фактический результат, ожидаемый результат, ссылка на требование/oracle
Шаги воспроизведения	минимальная последовательность действий или событий
Воспроизводимость	всегда, часто, редко, один раз, зависит от условий
Важность	customer harm, финансовый, операционный, регуляторный или репутационный impact
Срочность	когда нужно исправить с учётом SLA, релиза, инцидента, клиента
Симптом	как проблема видна клиенту, поддержке, мониторингу или отчёту
Обходной путь	workaround, ручная операция, fallback, компенсация
Evidence	тикет, лог, trace id, SLA report, скрин, запись звонка, мониторинг
Связи	SJM шаг, BPMN задача, требование, test case, incident, change request
Owner	продукт, IT, процесс, поддержка, риск/compliance, vendor

Схема RCA

flowchart TD
    A[Наблюдаемое проявление] --> B[Собрать evidence]
    B --> C[Выдвинуть гипотезу]
    C --> D[Проверить гипотезу]
    D --> E{Подтвердилась?}
    E -->|Нет| C
    E -->|Да| F{Это первопричина?}
    F -->|Нет| C
    F -->|Да| G[Рекомендация по устранению]
    G --> H[Change request]
    H --> I[Обновить SJM/BPMN/KB/tests/monitoring]

Как отличать симптом от причины

Уровень	Пример в сервисе	Что делать
Симптом	клиент видит непонятный статус	зафиксировать, где и когда статус показан
Поверхностная причина	CRM получила статус unknown	найти источник статуса и событие, которое его создало
Глубже	интеграция вернула timeout, workflow не обработал retry	проверить retry/fallback и правила исключений
Первопричина	в требованиях не описана ветка timeout или нет owner для ручного восстановления	изменить модель, требования, workflow, KB и regression
Условия	мониторинг не ловит зависшие заявки, поддержка не видит trace id	добавить observability и support tooling

Шаблон defect report

## Краткое описание

## Фактический результат

## Ожидаемый результат

## Где проявилось
- SJM шаг:
- BPMN задача/статус:
- Система:
- Канал:

## Условия
- Клиент/сегмент:
- Данные:
- Интеграции:
- Время/SLA:

## Шаги воспроизведения
1.
2.
3.

## Evidence
- Тикет:
- Лог / trace id:
- SLA report:
- Скрин / запись:

## Impact
- Клиент:
- Операции:
- Риски/compliance:

## Workaround

## Гипотеза о причине

## Что обновить после исправления
- [ ] SJM
- [ ] BPMN
- [ ] Workflow
- [ ] KB
- [ ] Regression set
- [ ] Monitoring / alert

Практический чек-лист

• В отчёте один дефект, а не набор несвязанных проблем.
• Есть ожидаемый и фактический результат.
• Указан oracle: требование, SLA, KB, регламент, system of record.
• Есть достаточно деталей для воспроизведения.
• Severity и urgency объяснены через impact, а не через эмоцию.
• Перед созданием проверены дубликаты.
• Evidence приложено или указано ссылкой.
• После исправления дефект связан с regression check.
• Повторяющиеся дефекты переведены в problem/RCA и change request.

Советы

• Не описывать только “клиент жалуется”; описывать, какое ожидание сервиса нарушено.
• Не использовать reopen для нового дефекта: новый дефект требует нового отчёта, иначе теряются метрики и история.
• Если дефект не воспроизводится, сохранить условия, evidence и гипотезы: в сервисах редкие дефекты часто зависят от данных, времени, очередей и интеграций.
• Для incident-review полезнее defect report с traceability, чем длинный свободный рассказ.

Источники

• SJM Source - Куликов Базовый курс 2023
• Чек-листы и тест-кейсы сервиса
• Тестирование и качество сервисов
• Справочник понятий сервисной модели