服务设计是什么
服务设计以用户与业务成果为出发点，目标是让服务从设计阶段就具备可运营性：体验路径、可支持性、可监控性与成本在设计中被确定，而不是上线后补救。设计要求功能完整，也要求值班模型、失败模式与度量方式在同一份方案里被讨论清楚。
基本信息
| 输入 | 业务需求、用户旅程、技术约束与合规要求 |
|---|---|
| 核心关注 | 可运营性（监控、值班、支持）、成本与合规 |
| 常用工具 | 服务蓝图、原型、设计评审、失败模式分析 |
| 参与角色 | 产品、研发、运维、安全、支持共同评审 |
| 输出 | 设计说明书、运营模型、度量指标与验证方案 |
典型使用场景
- 新服务立项时把运维与安全拉进设计，避免上线后补监控与权限
- 改造用户高频路径，需要同时设计失败提示与人工兜底流程
- 为低频高价值业务设计服务等级，避免过度设计抬高维护成本
- 跨系统流程设计时明确异常分支与人工干预入口
- 自助化服务设计时同步设计引导与知识支持，防止人工量不降
设计评审检查项
设计评审检查项
# 检查项要能给出是或否的结论，避免成为开放式讨论
[ ] 用户旅程关键节点是否清晰，含成功与失败分支？
[ ] 值班与支持模型是否设计（谁来接、怎么升级）？
[ ] 失败模式与回退是否定义（含不可回退操作）？
[ ] 监控与验证指标是否确定（业务指标与技术指标）？
[ ] 数据与权限是否满足最小化与合规要求？可运营性设计项
| 设计项 | 设计要求 | 常见缺失 |
|---|---|---|
| 可监控性 | 核心链路有指标与告警，阈值可解释 | 只接日志指标，无业务指标 |
| 可支持性 | Runbook、自助工具与升级路径齐备 | 上线后才发现只能由开发者处理 |
| 可恢复性 | 备份、回退与降级方案明确 | 无降级方案，故障时只能全停 |
| 成本 | 资源规格与容量预估有依据 | 无容量模型，靠事后扩容 |
设计阶段决定大部分生命周期成本：评审时把运维与安全拉进来，代价是一次会议时间，收益是上线后数月的返工与故障处置成本。