Жизненный цикл сервиса

Жизненный цикл сервиса — это последовательность состояний, через которые проходит сервис: идея, проектирование, проверка, запуск, сопровождение, улучшение и вывод из эксплуатации. Для сервисной модели важно видеть не только проектирование, но и production-жизнь: поддержку, инциденты, обновления и устаревание документации.

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

Помогает не терять сервис после запуска.
Связывает SJM, требования, тесты, инструменты поддержки и change requests.
Показывает, какие артефакты нужны на каждом этапе.
Делает сопровождение частью модели, а не “последующей эксплуатационной проблемой”.

Типовой lifecycle

flowchart LR
    A[Идея] --> B[Discovery]
    B --> C[As-is]
    C --> D[Target-state]
    D --> E[Требования]
    E --> F[Архитектура и процесс]
    F --> G[Тестирование]
    G --> H[Запуск]
    H --> I[Поддержка]
    I --> J[Улучшение]
    J --> C

Этапы

Этап	Что проверить	Артефакты	Риск
Идея	есть ли ценность и владелец	value proposition, scope	сервис решает не ту проблему
Discovery	что происходит сейчас	интервью, данные, жалобы	карта строится на мнениях
As-is	как сервис работает фактически	SJM as-is, BPMN, метрики	скрыты ручные обходы
Target-state	как должен работать сервис	SJM target-state, backlog	целевое состояние не исполнимо
Требования	что нужно изменить	BRD, user stories, NFR	требования не тестируемы
Архитектура	какие системы и интеграции участвуют	architecture view, ADR	не учтены качества сервиса
Тестирование	как доказать готовность	UAT, regression, test report	проверен только happy path
Запуск	готова ли поддержка	runbook, KB, SLA, comms	первая линия не умеет обслуживать
Поддержка	что происходит после запуска	обращения, SLA, monitoring	проблемы копятся без owner
Улучшение	что менять по evidence	change request, problem analysis	изменения не доходят до модели

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

Для каждой SJM-карты указывать режим: as-is, target-state, incident-review.
Перед запуском проверять не только продуктовую готовность, но и поддержку: база знаний, маршрутизация, SLA, мониторинг, escalation path.
После запуска смотреть evidence: повторные обращения, дефекты, инциденты, жалобы, просрочки.
При изменении сервиса обновлять SJM, BPMN, требования, тесты и knowledge base вместе.

Lifecycle controls

Из локального корпуса полезно взять не отдельные “учебные темы”, а контрольные механизмы lifecycle:

Контроль	На каком этапе нужен	Смысл для сервиса
Static testing	требования, SJM, BPMN, KB до разработки	найти противоречия в модели до того, как они станут дефектами production
Risk-based testing	test strategy, запуск, изменения	глубже проверять сценарии с высоким customer harm и плохой recoverability
Regression testing	change request, релиз, hotfix	защитить критичные статусы, SLA, интеграции и маршрутизацию поддержки
Architecture decision record	архитектура, интеграции, спорные решения	сохранить контекст выбора и последствия для сопровождения
Fitness function	запуск и сопровождение	превратить архитектурные качества в мониторинг, тесты, отчёты или checklist
Defect / incident evidence	production-жизнь	обновлять SJM, workflow, KB и risk register по фактам, а не по ожиданиям

Цикл проверки качества

Из SJM Source - Куликов Базовый курс 2023 удобно взять логику тестового цикла и переложить её на сервис:

flowchart LR
    A[Планирование и анализ требований] --> B[Критерии приёмки]
    B --> C[Стратегия проверки]
    C --> D[Чек-листы и тест-кейсы]
    D --> E[Выполнение проверок]
    E --> F[Фиксация дефектов]
    F --> G[Анализ результатов]
    G --> H[Отчётность]
    H --> A

Для сервисной модели это означает:

на этапе требований использовать Тест-анализ требований сервиса;
на этапе подготовки запуска создавать Чек-листы и тест-кейсы сервиса;
на этапе проверки фиксировать не только баги приложения, но и дефекты процесса, KB, workflow, SLA и мониторинга;
на этапе анализа результатов переводить повторяющиеся проблемы в Дефекты сервиса и RCA;
после отчётности обновлять SJM, BPMN, regression set и support model.

Связь с SJM

SJM живёт внутри lifecycle. Одна и та же карта может использоваться:

на discovery — чтобы понять фактический путь;
в target-state — чтобы согласовать изменение;
в тестировании — чтобы покрыть ветки и исключения;
в support — чтобы объяснить маршрутизацию;
в incident-review — чтобы найти отклонение от ожидаемого поведения.

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

На этапе запуска должны быть готовы:

карточка сервиса в базе знаний;
категории и маршрутизация в системе обращений;
workflow-статусы и SLA;
доступы первой линии к безопасному набору данных;
мониторинг технических ошибок и задержек;
правила эскалации;
шаблоны клиентских коммуникаций;
владелец change request после повторяющихся проблем.

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

Есть владелец lifecycle сервиса.
Указано текущее состояние карты.
Для запуска описан support readiness.
Есть путь от инцидента к изменению процесса.
Есть правило пересмотра карты после изменения продукта, канала, SLA, интеграции или владельца.

Ограничения

Lifecycle не должен превращаться в формальную бюрократию.
Если организация использует ITIL/COBIT/внутреннюю модель сопровождения, нужна отдельная сверка: source_required.
Без реальных данных support и monitoring lifecycle останется гипотезой.