Управление рисками сервисных изменений

Сервисное изменение несёт не только проектный риск сроков и бюджета. Оно может создать customer harm, регуляторный риск, операционный разрыв, дефект поддержки, архитектурную деградацию или невозможность восстановить сервис после ошибки.

Что это даёт в реальной работе

• Помогает принимать решения до запуска, а не после инцидента.
• Связывает риски с конкретными этапами SJM.
• Делает mitigation частью требований, тестов, мониторинга и support model.
• Позволяет отличить “мы приняли риск” от “мы забыли его проверить”.

Типы рисков

Тип риска	Пример	Где фиксировать
Customer harm	клиент теряет деньги, статус, доступ или получает неверную инструкцию	SJM, risk register, compliance checkpoint
Операционный риск	ручная очередь не справляется, первая линия не видит данные	support model, SLA, workflow
Архитектурный риск	система не выдерживает latency, интеграция создаёт дубли	architecture view, monitoring
Регуляторный риск	срок ответа или раскрытие информации нарушает требование	compliance checkpoint
Риск качества	не покрыта негативная ветка или regression	test strategy
Риск сопровождения	нет базы знаний, owner или маршрута эскалации	support readiness
Риск изменения	релиз меняет процесс без обновления SJM/KB/SLA	change request, changelog

Как применять в сервисной модели

1. Для каждого критичного этапа SJM спросить: “что будет худшим разумным отказом?”.
2. Разделить угрозы и возможности: риск может быть не только проблемой, но и шансом улучшить контроль.
3. Оценивать риск через impact, likelihood, detectability и recoverability.
4. Для каждого существенного риска указать response: avoid, reduce, transfer, accept или escalate.
5. Привязать mitigation к артефакту: требование, тест, мониторинг, база знаний, fallback, SLA, owner.
6. После инцидента оформить defect/RCA, обновить risk register и SJM.

Справочный слой

Справочный слой усиливает риск-заметку двумя практиками: Risk-based testing и architecture risk analysis у Richards/Ford.

Практика	Как использовать для service change
Risk-based testing	строить test scope от impact и likelihood, а не от удобства тестирования
Test oracle	заранее определить, по какому источнику видно, что сервис ведёт себя правильно
Architecture characteristics	проверить, какие качества изменение может ухудшить: availability, latency, security, observability, recoverability, supportability
Trade-off analysis	явно записать, какой риск принят ради скорости, стоимости, простоты или совместимости
Fitness function	связать mitigation с измеримым контролем: alert, synthetic test, SLA report, regression case, dashboard
ADR	фиксировать спорные решения по retry, fallback, source of truth, privacy и доступам поддержки
Defect report / RCA	превращать повторяющиеся проявления риска в проверяемое исправление первопричины
Test automation	автоматизировать повторяемые risk controls: SLA timers, regression, synthetic checks, reconciliation и monitoring

Риск считается обработанным не тогда, когда он записан в register, а когда у него есть owner, response, тест/контроль, production-сигнал и путь обновления SJM/KB/workflow после evidence.

Связь с SJM

SJM удобна как risk map:

• customer action показывает, где клиент может ошибиться или пострадать;
• frontstage показывает, где сообщение может ввести в заблуждение;
• backstage показывает ручные очереди и проверки;
• systems показывает технические и интеграционные зависимости;
• metrics показывает ранние сигналы деградации;
• service recovery показывает, как вернуть клиента в понятное состояние.

Связь с инструментами поддержки и сопровождения

Риск должен быть виден в инструментах:

• category / priority в системе обращений;
• SLA threshold и breach alert;
• мониторинг технических симптомов;
• база знаний для первой линии;
• шаблон клиентской коммуникации;
• owner эскалации;
• problem record после повторения;
• change request с evidence.

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

• У критичных этапов есть risk note.
• Customer harm проверен отдельно.
• Для каждого риска есть owner.
• Для каждого риска есть response.
• Risk response связан с требованием, тестом или support-control.
• Есть monitoring/alert для раннего обнаружения.
• Есть recovery path.
• Для повторяющихся проблем есть Дефекты сервиса и RCA.
• Для частых или критичных контролей оценена Автоматизация проверок сервиса.
• После инцидента обновляются SJM, KB и risk register.

Ограничения

• PMBOK полезен как общий источник по проектному управлению и рискам, но конкретные банковские риски требуют внутренних политик и профильных функций.
• Не давать юридических выводов без источника и владельца: source_required.
• Не считать risk register заменой реального мониторинга и поддержки.

Источники

• Справочник понятий сервисной модели
• Risk-based testing
• Test oracle
• Architecture characteristics
• Trade-off analysis
• Fitness function
• Architecture decision record
• Дефекты сервиса и RCA
• Автоматизация проверок сервиса
• SJM Source - Куликов Базовый курс 2023
• PMI PMBOK Guide
• ISTQB CTFL v4.0
• ISO/IEC/IEEE 42010:2022
• SJM — privacy, compliance и customer harm