标准执行制造类名词
本文档对19个标准制造/执行类名词，按”是什么 → 为什么 → 怎么做 → 使用用例 → 模板”五维结构进行系统梳理，可作为团队培训、流程建设、规范落地的参考手册。
一、核心作业规范类
1. SOP（标准作业程序）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
| SOP
├── 是什么：为重复性工作制定的标准化操作准则，完整规定作业步骤、动作要求、
│ 判定标准与注意事项，是标准化作业的基础载体。
│
├── 为什么
│ ├── 统一作业质量：不同人做同一件事，结果一致
│ ├── 降低操作误差：减少因经验差异导致的失误
│ ├── 降低培训成本：新人按SOP即可上手，不依赖口传心授
│ ├── 合规审计支撑：为内外部审计提供可追溯的执行证据
│ └── 持续改进基线：SOP是优化的起点，有了标准才能度量偏差
│
├── 怎么做
│ ├── 1. 识别需标准化的关键作业（高频、高风险、多人员参与）
│ ├── 2. 观察并记录当前最优实践（跟岗、访谈、数据回溯）
│ ├── 3. 编写SOP文档：步骤编号 → 动作描述 → 判定标准 → 注意事项
│ ├── 4. 评审验证：让执行者试走一遍，收集反馈并修订
│ ├── 5. 正式发布 + 培训 + 考核
│ ├── 6. 定期回顾（建议每季度/半年），根据变更和优化持续迭代
│ └── 7. 版本管理：每次修改记录变更原因、审批人、生效日期
│
├── 使用用例
│ ├── 用例1：生产线换模 — 将换模过程拆解为38个标准步骤，换模时间从45分钟降至22分钟
│ ├── 用例2：服务器巡检 — 值班人员按SOP逐项检查CPU/内存/磁盘/日志，杜绝漏检
│ ├── 用例3：新员工入职 — HR按SOP完成账号开通、设备发放、培训安排，7天内到岗
│ ├── 用例4：客户退款处理 — 客服按SOP判断退款条件、审批层级、退款渠道，避免纠纷
│ └── 用例5：数据库备份 — DBA按SOP执行全量/增量备份、校验、异地存储，保证可恢复
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ SOP-编号：SOP-OPS-001 │
│ 标题：XXX标准作业程序 │
│ 版本：V2.1 生效日期：YYYY-MM-DD 审批人：XXX │
│ 适用范围：[部门/岗位/场景] │
│ 前置条件：[工具/权限/信息] │
│ │
│ 步骤 | 操作动作 | 判定标准 | 注意事项 │
│ 1 | 登录系统，进入 | 页面正常加载， | 如遇503错误， │
│ | XX管理后台 | 显示当前版本号 | 联系运维重启 │
│ 2 | 核对待处理列表 | 数量与交接记录 | 发现差异立即 │
│ | | 一致 | 上报主管 │
│ ... | ... | ... | ... │
│ │
│ 异常处理：[常见异常场景 + 处置方法 + 升级路径] │
│ 关联文档：[WI-xxx / Runbook-xxx / Checklist-xxx] │
│ 变更记录：V2.1 2025-03-15 增加步骤3的异常分支 — 张三 │
└──────────────────────────────────────────────────────────┘
|
2. Runbook（运行手册）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
| Runbook
├── 是什么：针对特定技术操作场景的分步执行指引，细化操作流程、参数配置、
│ 异常处理与风险提示。比SOP更贴近具体技术系统，比WI更宏观。
│
├── 为什么
│ ├── 降低操作门槛：即使非资深人员也能按手册完成复杂技术操作
│ ├── 缩短故障恢复时间（MTTR）：异常场景有现成的处理步骤，不用临时分析
│ ├── 避免"只有一个人会"：消除关键人单点依赖（Bus Factor）
│ └── 操作可审计：每次高危操作有据可查，满足合规要求
│
├── 怎么做
│ ├── 1. 确定Runbook覆盖的技术场景（部署、扩容、迁移、故障恢复等）
│ ├── 2. 由最熟悉该系统的工程师主笔，另一人验证
│ ├── 3. 编写结构：前置检查 → 执行步骤 → 验证步骤 → 回滚步骤 → 异常分支
│ ├── 4. 在测试/预发布环境完整走一遍，确认每一步都可复现
│ ├── 5. 纳入值班手册，确保7×24可获取（推荐在线文档/Wiki，避免本地文件）
│ └── 6. 每次操作后复盘更新，至少每季度评审一次有效性
│
├── 使用用例
│ ├── 用例1：数据库主从切换 — Runbook列出停写→等待同步→切换VIP→验证→恢复写，5分钟完成
│ ├── 用例2：SSL证书轮换 — 按Runbook申请→部署→验证→吊销旧证书，零 downtime
│ ├── 用例3：K8s集群节点扩容 — 从前置资源检查到新节点Ready，全程17步，30分钟完成
│ ├── 用例4：日志磁盘清理 — 按Runbook定位大文件→停写→归档→清理→恢复，避免误删
│ └── 用例5：第三方API密钥轮换 — Runbook覆盖新旧密钥并存期、验证方式、回退条件
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ Runbook：MySQL主从切换 │
│ 版本：V3.0 负责人：张三 最后更新：YYYY-MM-DD │
│ 适用系统：order-db-prod (主) / order-db-prod-ro (从) │
│ 预计耗时：8分钟 风险等级：高 回滚方式：切回原主 │
│ │
│ ▷ 前置检查（5项，全部通过才可执行） │
│ [ ] 从库复制延迟 < 1s → SHOW SLAVE STATUS\G │
│ [ ] 业务低峰期确认 → 当前QPS < 1000 │
│ [ ] 变更窗口已审批 → 审批单号：CR-2025-xxxx │
│ [ ] 监控告警已静默 → 静默ID：xxxx │
│ [ ] 回滚脚本已就绪 → /scripts/rollback_swap_master.sh │
│ │
│ ▷ 执行步骤 │
│ Step 1: 应用层停写 │
│ 命令：kubectl scale deploy order-svc --replicas=0 │
│ 预期：Pod数归零，无新连接 │
│ 异常：60s未归零 → 执行 kubectl delete pod --force │
│ Step 2: 等待从库追平 │
│ 命令：mysql -h slave -e "SHOW SLAVE STATUS\G" │
│ 预期：Seconds_Behind_Master = 0 │
│ 异常：>0持续30s → 等待至120s，仍>0则终止并回滚 │
│ Step 3: 切换VIP │
│ ... │
│ │
│ ▷ 验证步骤（全部通过才算成功） │
│ [ ] 新主库可写：INSERT测试写入 + 查询确认 │
│ [ ] 应用连接正常：健康检查端点返回200 │
│ [ ] 业务指标恢复：QPS恢复至切换前水平 │
│ │
│ ▷ 回滚步骤（如任一验证失败） │
│ 1. kubectl scale deploy order-svc --replicas=N │
│ 2. 切回原VIP → /scripts/rollback_swap_master.sh │
│ 3. 验证原主库读写正常 │
│ │
│ ▷ 异常场景速查表 │
│ Slave延迟不归零 → 终止操作，联系DBA排查 │
│ VIP切换失败 → 回滚+联系网络组 │
│ 应用启动失败 → 检查ConfigMap中的数据库连接串 │
└──────────────────────────────────────────────────────────┘
|
3. Playbook（处置手册/战术手册）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
| Playbook
├── 是什么：面向特定场景的标准化应对框架，明确角色分工、决策节点、处置路径
│ 与升级规则。相比SOP更侧重多角色协同与策略判断，而非单一步骤序列。
│
├── 为什么
│ ├── 应急场景下降低认知负荷：不用"想该怎么做"，而是"按Playbook执行"
│ ├── 角色分工明确：每个人知道自己在大局中的位置和职责，减少混乱
│ ├── 决策节点前置：把压力下的判断提前到冷静时做，现场只需匹配条件
│ └── 可演练可复盘：结构化框架便于桌面推演和事后复盘改进
│
├── 怎么做
│ ├── 1. 确定Playbook覆盖的场景（P0故障、安全事件、大促保障、灾备切换等）
│ ├── 2. 定义角色与职责：总指挥/执行者/沟通者/记录员，每角色明确权责
│ ├── 3. 梳理处置流程：触发条件 → 响应分级 → 处置路径 → 决策树 → 升级规则
│ ├── 4. 设定时间节点：5分钟/15分钟/30分钟/1小时分别应完成什么
│ ├── 5. 设计沟通模板：对内通报、对外公告、客户通知的标准话术
│ ├── 6. 定期演练（建议每季度），根据演练结果和真实事件复盘迭代
│ └── 7. 与Runbook/SOP联动：Playbook负责"组织和决策"，Runbook负责"执行细节"
│
├── 使用用例
│ ├── 用例1：P0线上故障应急 — Playbook定义：总指挥→5分钟内拉群+建War Room→每15分钟通报进展→1小时无进展升级VP
│ ├── 用例2：安全入侵响应 — Playbook定义：发现→隔离→取证→根除→恢复→复盘，各阶段责任人和决策条件
│ ├── 用例3：双11大促保障 — Playbook定义：预热→压测→限流→降级→扩容的决策链路和触发阈值
│ ├── 用例4：数据中心切换 — Playbook定义：切换决策条件、切换步骤、验证指标、回切条件
│ └── 用例5：公关危机应对 — Playbook定义：信息收集→事实核实→统一口径→分级响应→后续跟进
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ Playbook：P0线上故障应急响应 │
│ 版本：V2.0 负责人：oncall轮值 演练周期：每季度 │
│ 适用场景：核心业务不可用 > 5分钟 或 影响用户 > 10% │
│ │
│ ▷ 角色分工 │
│ 总指挥(Incident Commander) ：决策+协调+对外沟通 │
│ 技术负责人(Tech Lead) ：定位+修复+验证 │
│ 沟通负责人(Comms Lead) ：内部通报+客户通知+状态页更新 │
│ 记录员(Scribe) ：时间线记录+关键决策存档 │
│ │
│ ▷ 响应阶段与时间线 │
│ T+0~5min 检测与宣告 │
│ • 监控告警触发 / 用户反馈确认 │
│ • 总指挥判断是否达到P0标准并宣告 │
│ • 创建War Room（专用群/会议室） │
│ T+5~15min 集结与分工 │
│ • 相关人员进入War Room │
│ • 总指挥分配角色，明确各角色负责人 │
│ • 技术负责人给出初步判断（"已知问题/未知问题"） │
│ T+15~30min 定位与止损 │
│ • 技术负责人输出故障定位初步结论 │
│ • 总指挥决策：回滚 / 限流 / 降级 / 扩容 │
│ • 沟通负责人发第一轮通报（内部+客户） │
│ T+30~60min 修复与恢复 │
│ • 执行修复方案 │
│ • 每15分钟通报进展 │
│ • 如60分钟无实质进展 → 升级至VP/CTO │
│ T+60min~ 恢复验证与复盘 │
│ • 业务指标恢复确认 │
│ • 总指挥宣告故障结束 │
│ • 沟通负责人发恢复通告 │
│ • 24h内输出故障复盘报告 │
│ │
│ ▷ 决策树 │
│ 能定位到具体变更? │
│ ├── 是 → 直接回滚变更 → 验证 → 恢复 │
│ └── 否 → 有降级/限流方案? │
│ ├── 是 → 执行降级 → 止损 → 从容定位修复 │
│ └── 否 → 扩容 + 全量排查 → 提升优先级至CTO │
│ │
│ ▷ 升级路径 │
│ L1: 当值oncall → L2: 团队TL → L3: 部门负责人 │
│ → L4: VP Engineering → L5: CTO │
│ 触发条件：L1 30min无结论 / L2 60min无恢复 / L3 90min无恢复 │
│ │
│ ▷ 沟通模板 │
│ 内部通报：[时间] 确认[服务名]发生[现象]，影响[范围]， │
│ 当前[定位进展]，下一步[行动]，预计恢复[时间] │
│ 客户通知：[时间] 我们注意到[现象]正在影响您的使用， │
│ 技术团队已介入处理，预计[X]分钟内恢复 │
└──────────────────────────────────────────────────────────┘
|
4. WI（作业指导书）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
| WI（Work Instruction）
├── 是什么：粒度最细的岗位操作细则，精确到单工位、单步骤的操作动作、工具规范、
│ 质量判定标准。是一线作业人员的直接执行依据，比SOP更"接地气"。
│
├── 为什么
│ ├── 消除操作歧义：每一步"用左手还是右手""拧几圈"都明确规定
│ ├── 新员工极速上岗：按WI照做即可产出合格品，培训从"教经验"变成"教识字"
│ ├── 质量问题可追溯：哪一步谁做的、用什么工具、是否符合标准，全部可查
│ └── 为自动化和数字化打基础：WI是数字化工位终端的核心内容
│
├── 怎么做
│ ├── 1. 选定目标工位/工序，由该工位最熟练的操作者演示一遍
│ ├── 2. 分解动作到最小单元（拿起 → 对准 → 插入 → 拧紧 → 检查）
│ ├── 3. 每个动作用图文并茂方式记录（照片/简图 + 文字说明）
│ ├── 4. 明确工具（型号/规格/扭矩）、物料（料号/规格）、判定标准（公差/外观）
│ ├── 5. 让新人按WI操作一遍，记录所有卡点和疑问
│ ├── 6. 修订 → 培训 → 考核 → 上岗
│ └── 7. 张贴在工位可见位置（物理或数字终端），版本号醒目
│
├── 使用用例
│ ├── 用例1：电子厂焊接工位 — WI规定烙铁温度350±10℃、焊点直径0.5-0.8mm、焊接时间2-3秒
│ ├── 用例2：仓库拣货 — WI规定扫描枪操作顺序：扫货架码→扫商品码→确认数量→放入周转箱→扫箱码
│ ├── 用例3：客服话术 — WI规定问候语→身份核实→问题分类→解决方案→满意度引导→结束语，每环节标准话术
│ ├── 用例4：机房上架 — WI规定服务器上架：导轨安装位置(U数) → 螺丝规格(M6×16) → 扭矩(3N·m) → 理线走向
│ └── 用例5：数据标注 — WI规定标注框边缘贴合规则、遮挡处理、模糊图片判定标准、验收合格率≥98%
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ WI-ASM-042：后盖锁螺丝工位 │
│ 工位编号：ASM-042 岗位：组装工 版本：V1.3 │
│ 上级SOP：SOP-ASM-12（整机组装标准作业程序） │
│ │
│ ▷ 物料清单 │
│ 后盖组件：PN# COVER-REAR-X1 ×1 │
│ M2×6螺丝：PN# SCR-M2X6-BLK ×4 │
│ │
│ ▷ 工具清单 │
│ 电动螺丝刀：品牌XX，型号YY，扭矩设定 0.8±0.05 N·m │
│ 防静电手环：接地电阻 < 1MΩ，每日上班前测试 │
│ │
│ ▷ 操作步骤（配图） │
│ │
│ Step 1: 取料 │
│ [图：从料盒取后盖] │
│ 从料盒A-3取后盖组件1件，目视检查无划痕/变形 │
│ 判定标准：表面无 > 0.5mm划痕，卡扣无断裂 │
│ ❌ 不合格 → 放入不良品盒，贴黄色标签注明缺陷类型 │
│ │
│ Step 2: 定位 │
│ [图：后盖与机身对齐] │
│ 将后盖对准机身，卡扣对齐槽位，听到"咔嗒"声确认到位 │
│ 判定标准：四周缝隙均匀，间隙 ≤ 0.3mm │
│ ❌ 缝隙不均 → 重新定位，3次仍不行 → 标记不良品 │
│ │
│ Step 3: 锁螺丝 │
│ [图：4颗螺丝位置及锁紧顺序] │
│ 按 左上→右下→右上→左下 顺序锁紧4颗M2×6螺丝 │
│ 判定标准：螺丝头与后盖齐平，无凸起/凹陷 │
│ ❌ 滑牙 → 标记工单号，隔离该机台，通知线长 │
│ │
│ Step 4: 自检 │
│ [图：自检项示意图] │
│ 检查螺丝是否齐全（4颗）、是否齐平、后盖是否晃动 │
│ 全部合格 → 扫码确认 → 流入下一工位 │
│ │
│ ▷ 常见异常速查 │
│ 螺丝打滑 → 停止操作，标记机台，通知线长换丝攻 │
│ 后盖卡扣断裂 → 整机隔离，通知QE判定 │
│ 电动螺丝刀扭矩报警 → 停用该工具，换备用工具 │
└──────────────────────────────────────────────────────────┘
|
5. Checklist（检查清单）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
| Checklist
├── 是什么：关键作业节点的逐项校验清单，用于核对核心步骤与必查项，防止遗漏
│ 高风险环节。是SOP的精简校验工具，不是替代品。
│
├── 为什么
│ ├── 防止"以为自己做了"：人在重复性工作中容易跳步，Checklist强制逐项确认
│ ├── 应对复杂操作：即使专家也会遗漏步骤（参考《清单革命》中的外科手术案例）
│ ├── 低认知负担：不需要重新思考每一步，只做"是/否"判断
│ └── 审计留痕：打勾的Checklist就是最简单的合规证据
│
├── 怎么做
│ ├── 1. 识别高风险、多步骤、易遗漏的关键节点（发布、验收、交接、巡检等）
│ ├── 2. 提取SOP中的核心必查项（不是所有步骤，5-9项为佳，不超过15项）
│ ├── 3. 每项设计为"是/否/不适用"二元判断，避免主观评分
│ ├── 4. 设定检查顺序：按逻辑流或物理流排列，而非重要性排序
│ ├── 5. 每项注明判定标准和异常处理方式
│ ├── 6. 设定"暂停线"：哪些项不通过必须暂停整个流程
│ └── 7. 每月回顾完成率和不通过项分布，优化清单内容
│
├── 使用用例
│ ├── 用例1：生产发布Checklist — 代码冻结、回归通过、DB迁移已演练、回滚方案就绪、监控已配置、值班已安排
│ ├── 用例2：手术安全Checklist — 患者身份确认、手术部位标记、过敏史核实、器械清点、抗生素已给
│ ├── 用例3：航班起飞前Checklist — 燃油量、襟翼位置、导航设定、舱门关闭、除冰完成
│ ├── 用例4：新人入职Checklist — 账号开通、设备发放、权限配置、导师分配、入职培训、首周计划
│ └── 用例5：合同审批Checklist — 金额在预算内、法务已审、税务条款确认、数据合规条款、双方签字完整
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ Checklist：生产环境发布校验 │
│ 关联SOP：SOP-REL-01（生产发布标准作业程序） │
│ 发布单号：REL-2025-089 执行人：______ 日期：______ │
│ │
│ ⛔ 暂停线：标记 ⛔ 的项目若不通过，发布必须终止 │
│ │
│ 阶段 检查项 结果 备注 │
│ ──────────────────────────────────────────────────────── │
│ 发布前 ⛔ 1. 所有测试用例通过(含回归) [ ]是 [ ]否 │
│ ⛔ 2. 性能测试结果不低于基线 [ ]是 [ ]否 │
│ ⛔ 3. DB迁移脚本已在预发布环境验证 [ ]是 [ ]否 │
│ 4. 配置变更已登记 [ ]是 [ ]否 [ ]N/A│
│ 5. 回滚方案已就绪+演练通过 [ ]是 [ ]否 │
│ 6. 发布窗口已审批 [ ]是 [ ]否 │
│ 7. 值班人员已通知 [ ]是 [ ]否 │
│ │
│ 发布中 8. 灰度发布第一批(5%)指标正常 [ ]是 [ ]否 │
│ 9. 灰度发布第二批(50%)指标正常 [ ]是 [ ]否 │
│ 10. 全量发布完成 [ ]是 [ ]否 │
│ │
│ 发布后 11. 核心API成功率 ≥ 99.9% [ ]是 [ ]否 │
│ 12. P99延迟 ≤ 基线+20% [ ]是 [ ]否 │
│ 13. 无新增P0/P1告警 [ ]是 [ ]否 │
│ 14. 功能烟雾测试通过 [ ]是 [ ]否 │
│ 15. 发布结果已同步相关方 [ ]是 [ ]否 │
│ │
│ 复核人签字：____________ 日期：____________ │
└──────────────────────────────────────────────────────────┘
|
二、生产交付执行类
6. 工单（Work Order）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
| 工单（Work Order）
├── 是什么：生产作业的最小执行单元，承载任务内容、责任人、交付标准、完成时限
│ 等核心信息，是任务派发、进度跟踪、成果交付的基础载体。
│
├── 为什么
│ ├── 任务"显式化"：口头交代容易遗漏和扯皮，工单把任务信息结构化、可追溯
│ ├── 进度可度量：每个工单有生命周期（待分配→进行中→待验收→已完成），整体进度一目了然
│ ├── 权责清晰：谁、做什么、什么时候交付、交付标准是什么，白纸黑字
│ └── 数据积累：工单数据可分析人效、瓶颈工序、常见问题类型
│
├── 怎么做
│ ├── 1. 定义工单模板（见下方模板），确保信息完整
│ ├── 2. 明确工单创建规则：什么条件下需要开工单？谁可以开？
│ ├── 3. 建立工单生命周期管理：创建→分配→开始→完成→验收→关闭，每阶段有触发条件
│ ├── 4. 设定SLA/时效要求：紧急/普通/低优先级分别的响应和完成时限
│ ├── 5. 工单与工艺路线关联：自动流转到下一工序
│ ├── 6. 定期统计工单数据：完成率、逾期率、平均处理时长、返工率
│ └── 7. 选型工具：Jira / ServiceNow / 禅道 / 自研工单系统
│
├── 使用用例
│ ├── 用例1：IT运维工单 — "财务部张经理的VPN无法连接"，SLA 2小时，分配到网络组
│ ├── 用例2：工厂维修工单 — "3号线注塑机异响"，优先级紧急，派单给维修班组，附带设备编号和故障现象
│ ├── 用例3：设计需求工单 — "APP首页Banner更新双11活动素材"，需求描述+设计稿链接+交付时间
│ ├── 用例4：质检工单 — "批次B2025-0715成品抽检"，抽样数量200，AQL标准，质检员接收并回传结果
│ └── 用例5：HR入职工单 — "新员工李四 7月20日入职"，子任务自动生成：IT开账号、行政备工位、HR安排培训
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ 工单编号：WO-2025-0891 │
│ 工单类型：[维修/需求/质检/变更/...] │
│ 优先级：[紧急/高/中/低] SLA时限：4小时 │
│ │
│ 标题：[简明描述任务内容，如"3号线注塑机异响排查维修"] │
│ │
│ ▷ 基本信息 │
│ 发起人：李四 发起时间：2025-07-20 09:15 │
│ 责任人：王五（维修组） 截止时间：2025-07-20 13:15 │
│ 关联项目/产线：[项目名/产线编号] │
│ 关联资产：[设备编号/系统名/IP] │
│ │
│ ▷ 任务描述 │
│ [详细描述问题/需求：现象、复现条件、影响范围、期望结果] │
│ │
│ ▷ 交付标准 │
│ [ ] 异响消除，设备正常运行30分钟无异常 │
│ [ ] 填写维修记录（原因+处理方式+更换的零件） │
│ │
│ ▷ 前置依赖 │
│ [ ] 生产计划确认停机窗口（已确认：12:00-13:00） │
│ [ ] 备件M2轴承已在库（料号：BRG-M2-056） │
│ │
│ ▷ 处理记录 │
│ 时间 操作人 动作 结果 │
│ 09:20 王五 接单 确认可以处理 │
│ 11:50 王五 现场排查 定位为轴承磨损 │
│ 12:15 王五 更换轴承 异响消除 │
│ 12:45 王五 试运行30分钟 正常 │
│ │
│ ▷ 验收 │
│ 验收人：赵六（线长） 验收时间：12:50 │
│ 验收结论：[通过/不通过] 不通过原因：________ │
└──────────────────────────────────────────────────────────┘
|
7. 工艺路线（Routing）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
| 工艺路线（Routing）
├── 是什么：产品或任务从启动到最终交付的标准化流转路径，明确各工序节点、先后
│ 顺序、交接规则与输入输出要求，是生产流程的主干框架。
│
├── 为什么
│ ├── 全局视角：一张图看清从原材料到成品要经过哪些工序
│ ├── 消除流转混乱："下一步该去哪"不再依赖口头通知
│ ├── 瓶颈识别：哪个工序堆积最多WIP，一目了然
│ └── 自动化基础：工单系统按工艺路线自动流转，减少人工派单
│
├── 怎么做
│ ├── 1. 梳理完整的端到端流程，从接收到交付的所有节点
│ ├── 2. 识别各节点的：输入→加工动作→输出→判定标准→下一节点
│ ├── 3. 标注并行分支、汇聚节点、条件分支（如质检不通过→返工回路）
│ ├── 4. 每个节点指定责任角色和标准工时
│ ├── 5. 用流程图或价值流图（VSM）可视化
│ ├── 6. 在工单系统中配置自动化流转规则
│ └── 7. 定期分析各节点的WIP堆积、通过率、周期时间，持续优化
│
├── 使用用例
│ ├── 用例1：PCB板生产工艺路线 — SMT贴片→回流焊→AOI检测→DIP插件→波峰焊→ICT测试→功能测试→老化→包装
│ ├── 用例2：软件需求交付路线 — 需求评审→技术设计→开发→代码评审→测试→UAT→发布→验收
│ ├── 用例3：采购订单路线 — 需求审批→询价→比价→下单→供应商确认→发货→收货→质检→入库→付款
│ ├── 用例4：客户投诉处理路线 — 受理→分类→调查→方案拟定→客户确认→执行→回访→关闭
│ └── 用例5：员工入职路线 — Offer→背调→账号开通→设备准备→入职培训→试用期考核→转正
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ 工艺路线：RT-SOFT-REL-001（软件需求交付） │
│ 适用产品/服务类型：后端API需求 │
│ 版本：V2.3 总标准工时：8-12天 │
│ │
│ 节点 工序 责任角色 输入→输出 标准工时 判定 │
│ ───────────────────────────────────────────────────────── │
│ 1 需求评审 PM+TL 需求文档→评审通过PRD 1天 DoR │
│ 2 技术设计 TL+Dev PRD→技术方案文档 1-2天 评审 │
│ 3 开发实现 Dev 技术方案→代码+单测 3-5天 Code │
│ Review│
│ 4 代码评审 TL 代码→评审意见 0.5天 通过 │
│ 5 测试 QA 代码→测试报告 1-2天 通过 │
│ 6 UAT PM 测试报告→验收确认 0.5天 签字 │
│ 7 发布 DevOps 验收确认→线上运行 0.5天 监控 │
│ 8 验收关闭 PM 线上运行→验收报告 1天 DoD │
│ │
│ ▷ 分支路径 │
│ 节点4 不通过 → 返回节点3 │
│ 节点5 不通过 → 返回节点3（附带Bug清单） │
│ 节点6 不通过 → 返回节点3或5（视问题类型） │
│ │
│ ▷ 交接规则 │
│ 每次流转：上游更新工单状态 + 通知下游责任人 + 附件齐全 │
│ 停留超时：超标准工时1.5倍 → 系统自动告警 → PM跟进 │
└──────────────────────────────────────────────────────────┘
|
8. WIP（在制品）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
| WIP（Work In Progress）
├── 是什么：已启动但尚未完成全部工序的任务或产品，即生产过程中处于流转、加工
│ 状态的中间产物，是衡量生产负荷与流转效率的核心指标。
│
├── 为什么
│ ├── 利特尔法则：WIP = 吞吐率 × 周期时间，WIP过高直接拉长交付周期
│ ├── 隐藏问题：WIP堆积掩盖瓶颈、质量问题、依赖阻塞，让问题"看不见"
│ ├── 资金占用：每个WIP都占用资金（原材料、人力、存储），制造成本上升
│ └── 管理杠杆：控制WIP上限比催促进度更能提升整体产出
│
├── 怎么做
│ ├── 1. 梳理当前所有在制品的数量和状态（在哪个工序、卡了多久）
│ ├── 2. 设定WIP上限（WIP Cap）：每个工序/每个人员最多同时进行的任务数
│ ├── 3. 可视化：看板/Kanban，每个泳道设WIP限制
│ ├── 4. 建立WIP异常告警：超过上限自动预警，触发"为什么堆积"的分析
│ ├── 5. Push → Pull：不是"上游做完就往下推"，而是"下游有空才向上拉"
│ ├── 6. 定期WIP回顾（建议每周）：哪些卡住了？为什么？该怎么解？
│ └── 7. 指标监控：WIP数量、WIP老化（超过N天的在制品占比）、瓶颈工序WIP
│
├── 使用用例
│ ├── 用例1：软件团队Kanban — 开发列WIP上限=3，超过3就不能再开新任务，必须先完成在手的
│ ├── 用例2：工厂组装线 — 每个工位之间只允许堆积2件WIP，超过则前序工位暂停
│ ├── 用例3：设计团队 — 每个设计师同时进行的项目 ≤ 2，避免多项目切换损耗
│ ├── 用例4：维修车间 — WIP看板显示待修设备数、已修待取数、等待备件数，超24h标红
│ └── 用例5：客服工单 — 每个客服同时处理工单上限=5，新工单进入队列而非直接派发
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ WIP管理看板（Kanban） │
│ 团队：后端开发组 更新日期：2025-07-20 │
│ │
│ 待开始(∞) 设计中(3) 开发中(5) 测试中(4) 完成(∞) │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ │T-12│ │T-08│ │T-05│ │T-03│ │T-01│ │
│ │T-13│ │T-09│ │T-06│ │T-04│ │T-02│ │
│ │T-14│ │T-10│ │T-07│ │T-11│ │ │ │
│ │T-15│ └────┘ │ │ │ │ └────┘ │
│ │... │ ← 满 → └────┘ └────┘ │
│ └────┘ ⚠ 满 ⚠ 快满 │
│ │
│ ▷ WIP上限规则 │
│ 设计中 ≤ 3（ = TL同时指导的设计数上限） │
│ 开发中 ≤ 5（ = 开发人数 × 1.5） │
│ 测试中 ≤ 4（ = QA人数 × 2） │
│ │
│ ▷ WIP异常分析表 │
│ ID 工序 停留天数 阻塞原因 解决措施 │
│ T-07 开发中 8天 依赖第三方API未就绪 升级PM推动 │
│ T-04 测试中 5天 环境不稳定频繁断开 申请独占环境 │
│ │
│ ▷ 本周WIP指标 │
│ 总WIP：14 目标值：≤ 12 │
│ 平均周期：6.2天 目标值：≤ 5天 │
│ WIP老化(>7天)：3件 目标值：0 │
└──────────────────────────────────────────────────────────┘
|
9. CI/CD（持续集成/持续交付）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
| CI/CD
├── 是什么：软件研发场景下的自动化生产流水线，实现代码从提交、构建、测试到部署
│ 上线的全流程自动化执行。CI（持续集成）= 高频合并+自动验证，CD（持续
│ 交付/部署）= 自动发布到各环境。
│
├── 为什么
│ ├── 缩短反馈周期：提交代码几分钟后就知道是否通过，而非等几天后的"集成日"
│ ├── 降低发布风险：小批量频繁发布，每次变更小，出问题定位快
│ ├── 消除手工操作：构建、测试、部署全部自动化，消除"在我机器上能跑"
│ ├── 加速价值交付：从代码提交到用户可用从周级缩短到小时级
│ └── 质量内建：每次提交都经过全套自动化校验，缺陷在流水线中被拦截
│
├── 怎么做
│ ├── 1. 代码托管 + 分支策略（Git + Trunk-based / GitFlow）
│ ├── 2. CI：提交触发自动构建+单元测试+代码扫描（SonarQube/ESLint）
│ ├── 3. 构建产物管理：Docker镜像推送到镜像仓库（Harbor/ECR）
│ ├── 4. CD：自动部署到开发→测试→预发布环境，每个环境自动跑对应测试集
│ ├── 5. 生产发布：灰度/金丝雀发布→自动健康检查→自动回滚条件
│ ├── 6. 监控可观测性：日志/指标/追踪 + 告警接入流水线
│ ├── 7. Pipeline as Code：用Jenkinsfile/GitLab CI/GitHub Actions定义流水线
│ └── 8. 度量：部署频率、变更前置时间、变更失败率、故障恢复时间（DORA指标）
│
├── 使用用例
│ ├── 用例1：微服务CI/CD — 提交→编译→单测→镜像构建→部署到Dev→集成测试→部署到Staging→E2E测试→生产灰度
│ ├── 用例2：前端CI/CD — 提交→ESLint+Prettier→单测→构建→部署到CDN→自动化截图对比→发布
│ ├── 用例3：移动App CI/CD — 提交→构建iOS/Android→单元测试→上传TestFlight/内部测试→自动化UI测试→App Store发布
│ ├── 用例4：数据管道CI/CD — 提交→SQL Lint→数据质量测试→部署到Airflow→回填验证→生产调度
│ └── 用例5：基础设施CI/CD — Terraform提交→Plan→安全扫描→Apply→合规检查→状态存储
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ CI/CD 流水线定义（GitLab CI 示例） │
│ │
│ stages: │
│ - build # 编译 & 单测 │
│ - quality # 代码质量 & 安全扫描 │
│ - artifact # 构建制品 & 推送镜像 │
│ - deploy-dev # 部署开发环境 │
│ - test-dev # 开发环境自动化测试 │
│ - deploy-staging # 部署预发布环境 │
│ - test-staging # 预发布环境E2E测试 │
│ - deploy-prod # 生产灰度发布 │
│ │
│ ▷ 各阶段关键检查 │
│ build: │
│ ✅ 编译通过 │
│ ✅ 单元测试覆盖率 ≥ 80% │
│ quality: │
│ ✅ SonarQube Quality Gate 通过 │
│ ✅ 无 Critical/High 漏洞 │
│ ✅ 依赖库无已知CVE │
│ test-staging: │
│ ✅ E2E测试全部通过 │
│ ✅ 性能测试P99 ≤ 基线+20% │
│ deploy-prod: │
│ ✅ 金丝雀发布：10%流量 观察15分钟 → 自动扩至100% │
│ ✅ 错误率 <0.1%、P99延迟正常 → 全量 │
│ ❌ 任一异常 → 自动回滚 │
│ │
│ ▷ 流水线度量仪表盘 │
│ 部署频率：5次/天 变更前置时间：4小时 │
│ 变更失败率：2% 故障恢复时间：15分钟 │
└──────────────────────────────────────────────────────────┘
|
10. Sprint（迭代周期）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
| Sprint
├── 是什么：敏捷生产模式下固定时长的生产批次（通常1-4周），团队在固定周期内完成
│ 一批约定范围的交付任务，对应传统制造的生产批次周期。
│
├── 为什么
│ ├── 固定节奏：团队和干系人都知道"什么时候能拿到什么"，预期明确
│ ├── 快速反馈：每1-2周一次演示，尽早暴露理解偏差
│ ├── 限制WIP：Sprint容量限制迫使团队聚焦，减少并行任务
│ ├── 持续改进：每个Sprint结束的回顾会议是制度化的改进机制
│ └── 适应变化：Sprint之间可以调整优先级，而非死守半年前的计划
│
├── 怎么做
│ ├── 1. 确定Sprint时长（2周最通用，1周适合成熟团队，4周适合硬件/复杂项目）
│ ├── 2. Sprint Planning：从Product Backlog拉取优先级最高的任务，估算并承诺交付范围
│ ├── 3. Daily Standup（15分钟）：昨天做了什么、今天做什么、有什么阻塞
│ ├── 4. 执行期间：每日更新任务板，发现偏离及时调整（而非等到Sprint结束才发现）
│ ├── 5. Sprint Review（演示会）：向干系人演示完成的功能，收集反馈
│ ├── 6. Sprint Retrospective（回顾会）：讨论"哪些做得好/哪些需要改进/下个Sprint试什么"
│ ├── 7. 度量：Velocity（速率）、Sprint达成率、Scope Creep比例
│ └── 8. 工具：Jira / Linear / Trello / 物理看板
│
├── 使用用例
│ ├── 用例1：软件团队2周Sprint — Planning 2h → 每日站会15min → Review 1h → Retro 1h，交付5-8个Story
│ ├── 用例2：硬件团队4周Sprint — 第1-3周原型+测试，第4周设计冻结+Review，输出可制造的设计文件
│ ├── 用例3：内容团队1周Sprint — 周一定题→周二三写稿→周四审校→周五发布+Review
│ ├── 用例4：数据团队2周Sprint — 第1周数据探查+模型开发，第2周验证+部署+文档
│ └── 用例5：市场团队2周Sprint — Planning确定campaign目标→执行投放/内容/活动→Review数据→Retro优化策略
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ Sprint #23：2025年7月21日 - 8月1日（10个工作日） │
│ 团队：订单系统组 Scrum Master：张三 │
│ │
│ ▷ Sprint Goal │
│ 用户可在30秒内完成下单（含优惠券选择+地址填写），下单成功率≥99% │
│ │
│ ▷ Sprint Backlog（承诺交付 = Story Points 28） │
│ ID Story Points 优先级 状态 │
│ ORD-201 一键下单(记住常用地址+默认支付) 8 P0 ████ │
│ ORD-202 优惠券智能推荐 5 P0 ██░░ │
│ ORD-203 下单页加载速度优化(<1.5s) 5 P1 ░░░░ │
│ ORD-204 订单状态实时推送 5 P1 ░░░░ │
│ ORD-205 发票信息自动填充 3 P2 ░░░░ │
│ ORD-206 Bug修复(积压Top3) 2 P2 ░░░░ │
│ │
│ ▷ 风险登记 │
│ 1. 支付网关接口文档未更新 → 已预约7/22对齐会议 │
│ 2. 前端主力下周请假2天 → PM已知，Story 204可能受影响 │
│ │
│ ▷ Sprint日历 │
│ 7/21(一) 10:00 Sprint Planning (2h) │
│ 每日 09:30 Daily Standup (15min) │
│ 7/25(五) 16:00 Backlog Refinement (1h) │
│ 8/1(五) 14:00 Sprint Review (1h) │
│ 8/1(五) 15:00 Sprint Retro (1h) │
│ │
│ ▷ Sprint度量 │
│ 承诺点数：28 完成点数：__ 达成率：__% │
│ Scope Creep：+__ / -__ 点 │
│ Velocity(近3次均值)：31点 │
└──────────────────────────────────────────────────────────┘
|
三、质量管控门禁类
11. DoD（完成定义）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
| DoD（Definition of Done）
├── 是什么：判定任务或产品是否达到完工标准的统一验收准则，明确交付物要求、质量
│ 指标、合规条件。是工序交接与最终交付的质量标尺，不是"差不多就行"。
│
├── 为什么
│ ├── 消除歧义：团队内对"做完"的理解统一——代码写完≠做完，测试通过+文档更新+Code Review才算
│ ├── 防止技术债：DoD强制要求测试、文档、代码评审，跳过这些就是"假完成"积累技术债
│ ├── 可预测性：真实Done vs 假Done直接影响后续计划的可靠性
│ └── 信任基础：干系人看到"Done"就知道达到了什么质量标准
│
├── 怎么做
│ ├── 1. 列出"做完"必须满足的所有条件（从代码、测试、文档到部署）
│ ├── 2. 团队全员参与制定，达成共识（不是TL一个人拍板）
│ ├── 3. DoD分层：Story级 / Sprint级 / Release级，粒度不同
│ ├── 4. 随着团队成熟度提升，DoD应该越来越严格（加入性能、安全、可观测性等）
│ ├── 5. 把DoD打印出来贴在团队区域，或嵌入工单/Jira的完成校验中
│ ├── 6. 每个Sprint结束时抽查DoD执行情况
│ └── 7. Sprint Retro中回顾DoD是否过时或过于宽松
│
├── 使用用例
│ ├── 用例1：软件Story DoD — 代码合并到主分支 + 单元测试通过 + Code Review通过 + 验收标准全部满足 + 相关文档更新
│ ├── 用例2：硬件设计DoD — 原理图评审通过 + BOM完整 + DFM检查无Critical问题 + 设计文件归档PLM
│ ├── 用例3：Sprint DoD — 所有Story达到Story DoD + 无P0/P1 Bug残留 + Sprint Demo完成
│ ├── 用例4：文章发布DoD — 内容审校通过 + 配图完备 + SEO检查 + 预览验证 + 排期确认
│ └── 用例5：Release DoD — 所有功能E2E通过 + 性能不低于基线 + 安全扫描通过 + 发布Runbook已更新 + 回滚方案就绪
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ DoD 分层定义（软件团队示例） │
│ 团队：订单系统组 版本：V2.1 生效日期：2025-06-01 │
│ │
│ ▷ Story 级 DoD（每个User Story必须满足） │
│ [ ] 代码已合并到主干分支 │
│ [ ] 单元测试通过，覆盖率 ≥ 80% │
│ [ ] 新人也能看懂的代码（Code Review至少1人Approve） │
│ [ ] 验收标准（AC）全部满足 │
│ [ ] API文档已更新（如有接口变更） │
│ [ ] 数据库变更脚本已纳入版本管理（如有） │
│ [ ] 无新增 SonarQube Blocker/Critical 问题 │
│ [ ] 已在预发布环境通过功能验证 │
│ │
│ ▷ Sprint 级 DoD（每个Sprint结束时） │
│ [ ] 所有承诺Story达到Story DoD │
│ [ ] 无未关闭的 P0/P1 Bug │
│ [ ] Sprint Demo 已完成（PPT + 录屏） │
│ [ ] 技术债登记项已更新（新增/消除） │
│ │
│ ▷ Release 级 DoD（每个版本发布时） │
│ [ ] 所有Story达到Story DoD │
│ [ ] E2E测试集全部通过 │
│ [ ] 性能测试：P99延迟 ≤ 基线+20%，QPS不低于基线 │
│ [ ] 安全扫描无Critical/High漏洞 │
│ [ ] 发布Runbook已更新 + 回滚方案已演练 │
│ [ ] 监控大盘和告警规则已配置 │
│ [ ] 发布记录已起草（变更内容+影响范围+回滚方案） │
│ │
│ ▷ 不满足DoD时的处理规则 │
│ Story不满足Story DoD → 不能标记为Done，顺延至下个Sprint │
│ Sprint不满足Sprint DoD → Retro中复盘，不扣绩效但必须改进 │
│ Release不满足Release DoD → 不能发布，升级至PM+TL联合决策 │
└──────────────────────────────────────────────────────────┘
|
12. DoR（就绪定义）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
| DoR（Definition of Ready）
├── 是什么：任务进入下一工序的准入标准，明确前置条件、输入物要求、资源准备情况。
│ 保障工序衔接顺畅，避免"开工了才发现条件不满足"的无效开工。
│
├── 为什么
│ ├── 减少返工：需求不清晰就开发 → 做出来不是想要的 → 返工，DoR从源头拦截
│ ├── 提升效率：开发/测试不需要反复打断PM问"这个是什么意思"
│ ├── 防止"假开始"：表面上开工了，实际上在等依赖、在猜需求、在磨洋工
│ └── 团队自律：倒逼上游（PM/设计/架构）把功课做在前面
│
├── 怎么做
│ ├── 1. 定义每个工序的"就绪条件"——开发就绪、测试就绪、发布就绪各不同
│ ├── 2. 用 INVEST 原则检查 Story 是否就绪：Independent / Negotiable / Valuable / Estimable / Small / Testable
│ ├── 3. DoR检查在Planning或工序开始时进行，不通过 → 不下拉 → 不开始
│ ├── 4. 与上游角色（PM/UX/架构）共创DoR，让供给方明白"你要给我什么我才好干活"
│ ├── 5. DoR不满足时不是"拒绝"，而是"还差XX，请补充后再来"
│ └── 6. 定期回顾DoR通过率，发现上游供给质量问题
│
├── 使用用例
│ ├── 用例1：Story开发就绪 — 需求描述清晰 + UI设计稿已定稿 + 接口协议已对齐 + 依赖服务可用 + 有明确的验收标准
│ ├── 用例2：测试就绪 — 测试环境可用 + 测试数据准备完成 + 需求理解无歧义 + 自动化测试框架就绪
│ ├── 用例3：Sprint就绪 — Backlog已排优先级 + 前5个Story达到开发DoR + 团队容量已确认 + Sprint Goal清晰
│ ├── 用例4：生产发布就绪 — 测试全部通过 + 回滚方案就绪 + 发布窗口已审批 + 值班人员到位 + 监控已配置
│ └── 用例5：硬件打样就绪 — 设计冻结 + BOM物料齐套 + 供应商产能确认 + 模具准备完成 + 打样计划里程碑确认
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ DoR 检查清单（Story开发就绪） │
│ 团队：订单系统组 版本：V1.2 │
│ │
│ ▷ 内容就绪 │
│ [ ] 用户故事已按"作为...我希望...以便..."格式编写 │
│ [ ] 验收标准（AC）明确且可测试（每条AC可写成一个测试用例） │
│ [ ] UI/UX设计稿已定稿并通过评审（如有前端变更） │
│ [ ] 业务流程边界条件和异常分支已说明（不仅是Happy Path） │
│ │
│ ▷ 技术就绪 │
│ [ ] 技术方案已评审通过（如涉及架构变更） │
│ [ ] 外部依赖已确认（API协议已对齐 / 第三方SDK可用） │
│ [ ] 数据库变更方案已定（表结构/索引/迁移步骤） │
│ [ ] 性能要求和安全要求已明确（如"P99<200ms"或"PII数据加密"） │
│ │
│ ▷ 资源就绪 │
│ [ ] 所需权限/环境/工具已就绪 │
│ [ ] 关键人员（评审者/领域专家）在Sprint期间无长假 │
│ [ ] 无阻塞依赖（或被依赖方已承诺交付时间） │
│ │
│ ▷ INVEST检查 │
│ [ ] Independent — 可以独立开发、测试、交付 │
│ [ ] Negotiable — 实现方式可协商，不是写死的方案 │
│ [ ] Valuable — 对用户/业务有明确价值 │
│ [ ] Estimable — 团队能估算工作量（相对估算即可） │
│ [ ] Small — 可以在一个Sprint内完成 │
│ [ ] Testable — 有客观的通过/不通过标准 │
│ │
│ ▷ 判定结果 │
│ ☐ 全部通过 → Ready，可进入Sprint Backlog │
│ ☐ 1-2项未通过 → 标记未通过项，48h内补齐后可Ready │
│ ☐ 3项以上未通过 → Not Ready，退回Product Backlog等待Grooming │
└──────────────────────────────────────────────────────────┘
|
13. 质量门禁（Quality Gate）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
| 质量门禁（Quality Gate）
├── 是什么：生产流程中设置的强制校验卡点，未通过质量校验的任务无法进入下一环节。
│ 用于在过程中拦截质量风险，避免缺陷向下游传递——越早发现，修复成本越低。
│
├── 为什么
│ ├── 成本杠杆：缺陷发现阶段每推后一步，修复成本涨10倍（需求阶段$1 → 开发$10 → 测试$100 → 生产$1000+）
│ ├── 防止"带病流转"：上一个环节的缺陷不拦截，下游将基于错误的前提继续加工
│ ├── 数据驱动决策：不是"我觉得可以了"，而是"指标达到了所以可以通过"
│ └── 合规要求：如ISO 9001 / SOC2 / 医疗器械等对过程质量门禁有明确要求
│
├── 怎么做
│ ├── 1. 在工艺路线上标记强制校验点（至少设3个：设计完成/开发完成/发布前）
│ ├── 2. 每个门禁定义量化通过标准（如：测试覆盖率≥80%，Critical Bug=0）
│ ├── 3. 门禁刚性执行：不通过 = 不能流转，无例外（例外需逐级审批到指定层级）
│ ├── 4. 自动化优先：能用工具判断的不用人工（如CI SonarQube扫描自动拦截）
│ ├── 5. 门禁不通过时给出明确信息：差多少、怎么改、谁可以帮忙
│ ├── 6. 定期审计门禁执行情况：是否有绕过、是否有门禁本身需要调整
│ └── 7. 门禁不是终点——通过门禁 ≠ 完美，是"达到了可接受的残存风险水平"
│
├── 使用用例
│ ├── 用例1：设计→开发门禁 — 技术方案评审通过 + 接口协议已Review + 安全设计评审通过（如涉及PII）
│ ├── 用例2：开发→测试门禁 — CI全部通过 + Code Review完成 + 单测覆盖率≥80% + SonarQube通过
│ ├── 用例3：测试→发布门禁 — 所有用例通过 + P0/P1 Bug=0 + 性能达标 + 安全扫描无Critical + 发布Checklist全部打勾
│ ├── 用例4：供应商准入门禁 — 资质审核通过 + 样品检验合格 + 产能评估达标 + 社会责任审核通过
│ └── 用例5：内容发布门禁 — 原创度检查通过 + 敏感词审核通过 + 法律合规审核通过 + 排版质检通过
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ 质量门禁配置表 │
│ 产品线：订单系统 版本：V3.0 │
│ │
│ ▷ 门禁点位总览 │
│ │
│ G1: 需求评审完成 → 进入开发 │
│ ────────────────────────────────────────────────────────│
│ 通过标准 │
│ ✅ PRD经过PM+TL+QA三方评审 │
│ ✅ 验收标准明确（每条可测试） │
│ ✅ DoR全部通过 │
│ 不通过处理 │
│ → 退回需求方修正，标注缺失项，安排复审时间 │
│ │
│ G2: 开发完成 → 进入测试 │
│ ────────────────────────────────────────────────────────│
│ 通过标准（全自动） │
│ ✅ CI Pipeline 全部通过 │
│ ✅ 代码覆盖率 ≥ 80% │
│ ✅ SonarQube Quality Gate 通过（0 Blocker, 0 Critical） │
│ ✅ Code Review 至少1人Approve │
│ ✅ 安全扫描无Critical/High漏洞 │
│ 不通过处理 │
│ → CI自动标红，Jira自动打回"In Progress"，企微/钉钉通知开发 │
│ │
│ G3: 测试完成 → 进入发布 │
│ ────────────────────────────────────────────────────────│
│ 通过标准 │
│ ✅ P0/P1 Bug = 0 P2 Bug ≤ 3 (且有规避方案) │
│ ✅ 性能测试：P99 ≤ 基线+15% QPS ≥ 基线×0.95 │
│ ✅ E2E自动化测试全部通过 │
│ ✅ 发布Checklist全部打勾 │
│ ✅ 安全渗透测试通过（如涉及资金/隐私变更） │
│ 不通过处理 │
│ → 发布冻结，Bug修复后重新走G2→G3，性能不达标需架构评审 │
│ │
│ ▷ 例外放行规则 │
│ 仅限：安全补丁 / 合规强需求 / 已确认低风险 │
│ 审批链：TL → PM → 部门负责人（缺一不可） │
│ 放行记录需存档，Release Retro中回顾 │
│ │
│ ▷ 门禁度量 │
│ 本月G1通过率：92% G2一次通过率：78% G3一次通过率：85% │
│ 门禁拦截缺陷数：G1=3 / G2=12 / G3=5 │
│ 放行后逃逸至生产的缺陷数：1（P2，已修复） │
└──────────────────────────────────────────────────────────┘
|
14. SLA（服务水平协议）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
| SLA（Service Level Agreement）
├── 是什么：服务提供方与需求方之间约定的服务质量标准，明确可用性、响应时效、
│ 故障率等核心指标，是服务交付的正式质量承诺，通常附带违约责任。
│
├── 为什么
│ ├── 明确预期：双方对"好服务"有统一的、量化的定义，减少扯皮
│ ├── 责任边界：SLA划定了服务提供方的责任边界（如"只保证到API网关层"）
│ ├── 资源分配依据：不同SLA等级匹配不同的架构冗余、监控强度、响应投入
│ └── 商业契约：SLA违约通常有赔偿机制（如云厂商的Service Credit）
│
├── 怎么做
│ ├── 1. 识别核心服务指标：可用性(Availability)、响应时间(Latency)、吞吐量(Throughput)、错误率
│ ├── 2. 基于历史数据和业务需求设定目标（如 99.9% vs 99.99%，成本差10倍）
│ ├── 3. 明确定义测量方法：什么算"可用"？从哪测？采样频率？排除哪些因素？
│ ├── 4. 分级SLA：不同客户/场景不同等级（如 Gold/Silver/Bronze）
│ ├── 5. 建立监控→告警→报告→复盘闭环，月度SLA报告自动生成
│ ├── 6. SLA与OLA/SLO/Error Budget配套使用
│ └── 7. 定期（至少每年）与需求方评审SLA是否调整
│
├── 使用用例
│ ├── 用例1：云服务SLA — AWS EC2承诺99.99%可用性，低于此值赔付Service Credit
│ ├── 用例2：API服务SLA — 第三方支付API承诺99.95%可用 + P99响应<500ms + 技术支持响应<30min
│ ├── 用例3：IT Helpdesk SLA — P1故障15分钟响应+4小时解决，P2故障1小时响应+8小时解决
│ ├── 用例4：物流SLA — 同城当日达（18点前下单，22点前送达），超时免运费
│ └── 用例5：客服SLA — 在线客服30秒内响应 + 电话客服90%在20秒内接听 + 首次解决率≥85%
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ SLA 协议书 │
│ 服务名称：订单核心API │
│ 提供方：订单系统团队 使用方：各业务线 + 外部合作伙伴 │
│ 版本：V2.0 生效日期：2025-07-01 评审周期：半年 │
│ │
│ ▷ 服务指标 │
│ │
│ 指标 目标值 测量方式 测量窗口 │
│ ──────────────────────────────────────────────────── │
│ 可用性 ≥ 99.95% 健康检查+真实请求 自然月 │
│ 创建订单P99延迟 ≤ 200ms APM采样全部请求 自然周 │
│ 查询订单P99延迟 ≤ 100ms APM采样全部请求 自然周 │
│ 成功率 ≥ 99.9% 非5xx/非超时 自然周 │
│ 故障响应时间 ≤ 15分钟 告警→响应确认 单次 │
│ 故障恢复时间 ≤ 60分钟 响应→业务恢复 单次 │
│ │
│ ▷ 测量细则 │
│ · 可用性 = 1 - (不可用时长 / 总时长) │
│ · "不可用"定义：成功率 < 95% 持续 ≥ 5分钟 │
│ · 测量点：3个独立拨测节点 + 真实用户请求聚合 │
│ · 排除：客户端网络问题、第三方依赖故障、计划内维护窗口 │
│ · 计划内维护：每周四凌晨2-4点，提前3天通知，每月不超过2次 │
│ │
│ ▷ 服务降级与补偿 │
│ 月度可用性 < 99.95% → Service Credit 10% │
│ 月度可用性 < 99.0% → Service Credit 25% │
│ 月度可用性 < 95.0% → Service Credit 50% + 免费技术支持 │
│ │
│ ▷ 月度SLA报告（自动生成） │
│ 2025年6月 │
│ 可用性：99.97% ✅ 创建P99：187ms ✅ 查询P99：92ms ✅ │
│ 成功率：99.95% ✅ 故障次数：1 故障恢复：42分钟 ✅ │
│ 结论：全部达标，无赔付触发 │
└──────────────────────────────────────────────────────────┘
|
15. OLA（运营级别协议）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
| OLA（Operational Level Agreement）
├── 是什么：内部团队之间约定的服务协作标准，明确跨团队配合的响应时效、交付要求
│ 与责任边界。OLA是SLA的内部支撑——多个OLA撑起一个对外的SLA。
│
├── 为什么
│ ├── SLA需要内部保障：对外承诺99.95%可用性，需要网络、DB、K8s等多个内部团队的配合
│ ├── 消除"你以为他们在做"：团队A依赖团队B的API，B不知道A的SLA要求是什么
│ ├── 减少跨团队扯皮：出了故障先各自查自己的OLA是否达标，而非互相甩锅
│ └── 协作效率：明确"我能期望你多快响应"，不需要每次紧急时都走特批
│
├── 怎么做
│ ├── 1. 从SLA倒推：每个对外SLA指标对应哪些内部团队和环节？
│ ├── 2. 与每个依赖的内部团队签订OLA，明确接口、响应时效、升级路径
│ ├── 3. OLA指标应比SLA更严格（如SLA要求99.95%，内部OLA设99.99%留Buffer）
│ ├── 4. 建立联合监控：双方可见的Dashboard，数据透明
│ ├── 5. 跨团队OLA定期（至少每季度）回顾，双向评估是否达标
│ ├── 6. OLA也要有升级和违约处理机制（通常是向上级汇报，而非财务赔偿）
│ └── 7. 工具：ServiceNow / OpsGenie / PagerDuty 的跨团队升级链路
│
├── 使用用例
│ ├── 用例1：订单团队OLA→支付网关团队 — 支付接口P99<100ms、可用性≥99.99%、故障响应<10min
│ ├── 用例2：应用团队OLA→DBA团队 — DB查询优化响应<4h、紧急DDL审批<1h、备份恢复演练配合
│ ├── 用例3：开发团队OLA→安全团队 — 代码安全扫描反馈<24h、紧急漏洞修复响应<4h、渗透测试排期<2周
│ ├── 用例4：SRE→网络团队OLA — VIP切换<5min、DNS变更生效<10min、带宽扩容响应<30min
│ └── 用例5：HR OLA→IT部门 — 新员工账号开通<4h、离职权限回收<1h、设备故障替换<2h
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ OLA 协议书 │
│ │
│ 需求方：订单系统团队（Team A） │
│ 提供方：支付网关团队（Team B） │
│ 版本：V1.0 生效日期：2025-07-01 评审周期：每季度 │
│ │
│ ▷ 服务范围 │
│ Team B 提供以下API供 Team A 调用： │
│ · POST /v2/payment/create — 创建支付 │
│ · GET /v2/payment/{id} — 查询支付状态 │
│ · POST /v2/refund — 退款 │
│ │
│ ▷ OLA指标 │
│ 指标 目标值 依赖的外部SLA指标 │
│ ────────────────────────────────────────────────── │
│ 支付API可用性 ≥ 99.99% 订单API可用性≥99.95% │
│ P99响应时间 ≤ 100ms │
│ 故障响应确认 ≤ 10分钟 订单故障响应≤15分钟 │
│ 故障恢复时间 ≤ 30分钟 订单恢复时间≤60分钟 │
│ API变更通知 提前5工作日 │
│ 新需求评审响应 ≤ 3工作日 │
│ │
│ ▷ 升级路径 │
│ L1：双方oncall直接对接 → L2：双方TL → L3：双方部门负责人 │
│ 10分钟无响应 → 自动升级至L2 │
│ 30分钟无进展 → 自动升级至L3 │
│ │
│ ▷ 沟通渠道 │
│ 日常协作：双方企业微信群 │
│ 紧急故障：PagerDuty双向建单 + 电话备用 │
│ 例行对齐：每月第一个周三 16:00-16:30 │
│ │
│ ▷ 季度评分（双方互评） │
│ Q2 2025 Team A 对 Team B 评分：95/100 │
│ 扣分项：6月15日支付API变更未提前通知 → 已改进，变更将走OA审批 │
│ │
│ Q2 2025 Team B 对 Team A 评分：92/100 │
│ 扣分项：两次非紧急需求打标为"紧急" → 已沟通，明确紧急定义 │
└──────────────────────────────────────────────────────────┘
|
四、变更与异常处置类
16. 变更管理（Change Management）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
| 变更管理（Change Management）
├── 是什么：对生产系统、工艺流程的调整进行全流程管控的规范体系，涵盖申请、审批、
│ 执行、验证、回滚等环节。核心目标是控制变更风险，保障生产稳定。
│
├── 为什么
│ ├── 数据说话：70%以上的生产故障由变更引入——管住变更就管住了大部分风险
│ ├── 可追溯："谁在什么时候改了什么、为什么改"有完整记录
│ ├── 风险前置：变更前的审批和评审把风险拦截在执行之前
│ └── 合规要求：SOC2 / ISO 27001 / ITIL 等均要求正式的变更管理流程
│
├── 怎么做
│ ├── 1. 定义变更分类：标准变更（低风险/预授权）、正常变更（需审批）、紧急变更（事后补审）
│ ├── 2. 建立变更申请模板：变更内容、影响范围、风险等级、验证方案、回滚方案
│ ├── 3. 设立变更日历和变更窗口（如"每周二四六晚8-10点非紧急变更窗口"）
│ ├── 4. 组建CAB（变更顾问委员会）或轻量审批链：不同风险等级的变更走不同审批路径
│ ├── 5. 变更执行：按Runbook执行 → 灰度验证 → 全量推进 → 持续监控 → 关单
│ ├── 6. 变更后评审（Post-Change Review）：成功的也要复盘，不成功必须复盘
│ └── 7. 指标追踪：变更次数、变更成功率、变更引入的故障数、紧急变更占比
│
├── 使用用例
│ ├── 用例1：配置变更 — 修改Nginx超时参数，标准变更→自动审批→灰度→监控→完成
│ ├── 用例2：代码发布变更 — 新版本上线，正常变更→CAB审批→指定发布窗口→执行→验证→关单
│ ├── 用例3：数据库Schema变更 — 新增字段+索引，正常变更→DBA审批→在维护窗口执行→验证性能→关单
│ ├── 用例4：紧急安全补丁 — Log4j漏洞修复，紧急变更→TL即时审批→执行→24h内补全变更记录
│ └── 用例5：工厂工艺变更 — 换用新供应商的原料，正常变更→质量验证→小批量试产→评审→正式切换
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ 变更申请单（RFC - Request for Change） │
│ 变更编号：CHG-2025-0731 状态：审批中 │
│ │
│ ▷ 基本信息 │
│ 变更标题：订单服务数据库连接池参数优化 │
│ 变更类型：[标准/正常/紧急] ← 正常 │
│ 申请人：张三（订单系统组） 申请时间：2025-07-20 10:00 │
│ 影响系统：order-db-prod │
│ 风险等级：[低/中/高/极高] ← 中 │
│ │
│ ▷ 变更说明 │
│ 变更内容：将连接池max-size从50调整为80，min-idle从10调整为20 │
│ 变更原因：近期高峰时段偶发连接等待超时，分析后确认连接池不足 │
│ 影响范围：仅影响order-db连接建立策略，不影响数据和接口协议 │
│ 预期效果：消除连接等待超时，P99延迟降低10% │
│ │
│ ▷ 实施方案 │
│ 执行时间：2025-07-22 22:00（变更窗口内） │
│ 执行人：张三 复核人：李四 │
│ 执行步骤： │
│ 1. 22:00 修改配置中心参数（ConfigMap热更新） → 预计2分钟 │
│ 2. 22:02 应用Pod滚动重启 → 预计5分钟 │
│ 3. 22:07 监控关键指标：连接等待数、P99延迟、错误率 → 观察15分钟│
│ 4. 22:22 指标正常 → 变更成功 │
│ │
│ ▷ 回滚方案 │
│ 将max-size和min-idle改回原值，再次滚动重启（5分钟可完成） │
│ 回滚触发条件：P99延迟不降反升 / 连接数异常 / 错误率>0.1% │
│ │
│ ▷ 审批（按风险等级） │
│ [✓] TL审批 — 李四 — 2025-07-20 10:30 │
│ [✓] DBA审批 — 王五 — 2025-07-20 14:00 │
│ [ ] CAB审批 — 非必需（风险≤中） │
│ │
│ ▷ 执行结果（执行后填写） │
│ 执行时间：____ 实际耗时：____ 结果：[成功/失败/部分] │
│ 关键指标对比：变更前____ vs 变更后____ │
│ 异常记录：____ │
└──────────────────────────────────────────────────────────┘
|
17. 事件管理（Incident Management）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
| 事件管理（Incident Management）
├── 是什么：针对生产故障、异常事件的标准化处置流程，明确响应分级、上报路径、
│ 处置要求与闭环机制。目标是快速恢复正常生产秩序，降低异常影响。
│
├── 为什么
│ ├── 有序应急：故障时最可怕的是混乱——不知道谁负责、不知道谁在做什么
│ ├── 缩短MTTR：结构化的响应→定位→修复→验证流程比"群魔乱舞"快得多
│ ├── 组织学习：每个事件复盘后产出Action Item，避免同类问题重复发生
│ └── 对外信任：客户/用户看到透明、专业的故障处理过程，而非沉默
│
├── 怎么做
│ ├── 1. 定义事件分级：P0(全站不可用) / P1(核心功能不可用) / P2(部分用户受影响) / P3(轻微影响)
│ ├── 2. 建立Oncall轮值制度 + 告警升级链路（参考Playbook模板）
│ ├── 3. 事件响应流程：Detection(检测) → Declaration(宣告) → Triage(分级) → Mitigation(止损) → Resolution(修复) → Verification(验证) → Closure(关闭)
│ ├── 4. 事件记录（Incident Record）：时间线、关键决策、操作记录、影响评估
│ ├── 5. 事后复盘（Postmortem / RCA）：What / Why / How to prevent / Action Items
│ ├── 6. 告警治理：减少噪音告警，提高信噪比（告警不到位的补、不准确的调、没用的删）
│ └── 7. 度量：MTTD(平均检测时间) / MTTR(平均恢复时间) / 事件数量趋势 / 重复事件占比
│
├── 使用用例
│ ├── 用例1：P0全站502 — 监控告警→自动拉群→按Playbook分配角色→定位到新部署引入Bug→回滚→5分钟内恢复
│ ├── 用例2：P1支付失败 — 用户投诉+监控同时发现→宣告P1→限流保核心→定位第三方通道故障→切换备用通道→30分钟恢复
│ ├── 用例3：安全事件 — 入侵检测告警→安全团队介入→隔离受影响主机→取证分析→漏洞修补→加固→72h复盘
│ ├── 用例4：P2性能劣化 — P99延迟缓慢上升→自动化告警阈值触发→排查慢SQL→添加索引→性能恢复
│ └── 用例5：P3客服反馈 — 3名用户反馈同一问题→客服创建事件单→技术排查→确认是前端缓存问题→修复部署→关闭
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ 事件记录单（Incident Ticket） │
│ 事件编号：INC-2025-0892 宣告时间：2025-07-20 14:35 │
│ 事件等级：P1（核心功能不可用） │
│ │
│ ▷ 事件概要 │
│ 标题：支付接口大量超时，用户无法完成支付 │
│ 影响范围：全部用户，支付成功率从99.5%降至23% │
│ 影响时长：14:35-15:02（共27分钟） │
│ │
│ ▷ 角色分配 │
│ 总指挥：李四（当值oncall） │
│ 技术负责人：张三 │
│ 沟通负责人：赵六 │
│ │
│ ▷ 时间线（自动+手动记录） │
│ 14:32 监控检测到支付API成功率骤降 [自动] │
│ 14:33 PagerDuty告警触发，通知oncall [自动] │
│ 14:35 李四确认告警，宣告P1事件 [人工] │
│ 14:36 创建War Room，拉入支付组+网关组 [人工] │
│ 14:38 张三定位：第三方支付通道A连接超时 [人工] │
│ 14:40 决策：切换至备用通道B [人工] │
│ 14:42 执行通道切换 [人工] │
│ 14:45 支付成功率开始回升 [自动] │
│ 14:50 成功率恢复至99% [自动] │
│ 15:02 李四宣告事件结束 [人工] │
│ │
│ ▷ 关键决策记录 │
│ 14:40 决策：切换备用通道——决策人李四，基于"通道A恢复时间未知" │
│ 14:55 决策：暂不切回通道A——决策人李四，基于"等待通道A厂商确认" │
│ │
│ ▷ 根因分析（RCA - 事件后填写） │
│ What：第三方支付通道A的DNS解析故障 │
│ Why：未配置多DNS解析+健康检查+自动Failover │
│ How to prevent： │
│ Action 1: 实现通道自动Failover（负责人张三，时限2周） │
│ Action 2: 增加通道A可用性监控（负责人赵六，时限1周） │
│ Action 3: 备用通道B的容量评估+压测（负责人李四，时限3周） │
└──────────────────────────────────────────────────────────┘
|
18. 发布管理（Release Management）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
| 发布管理（Release Management）
├── 是什么：对版本或产品从测试到正式投产的全流程进行管控的规范，涵盖发布计划、
│ 灰度验证、全量推进、复盘总结等环节，保障投产过程平稳可控。
│
├── 为什么
│ ├── 发布是最高风险操作之一：从"能跑的版本"到"生产运行的版本"有巨大的环境鸿沟
│ ├── 灰度降低爆炸半径：先5%验证再全量，即使出问题也只影响5%用户
│ ├── 协调多方：发布涉及开发/测试/运维/安全/产品/客服/市场，需要统一节奏
│ └── 可预测性：干系人知道什么时候发布什么，用户知道什么时候有更新
│
├── 怎么做
│ ├── 1. 制定发布日历：固定发布窗口（如每周二/四），紧急发布走快速通道
│ ├── 2. 版本冻结：发布前N天Code Freeze，只接受Bug修复不接受新功能
│ ├── 3. 准备发布包：发布说明(Release Notes) + 部署Runbook + 回滚方案 + 监控配置
│ ├── 4. 灰度发布：Canary(5%→观察) → 分批(25%→50%→100%)，每步有健康检查+自动回滚条件
│ ├── 5. 发布期间：值班人员在岗，监控大盘全开，沟通渠道畅通
│ ├── 6. 发布验证：烟雾测试 + 核心指标对比（发布前后） + 用户反馈监控
│ ├── 7. 发布后：发布报告 + Release Retro + 度量（发布成功率、回滚率、发布耗时）
│ └── 8. 工具：Spinnaker / Argo Rollouts / 自研发布平台
│
├── 使用用例
│ ├── 用例1：微服务版本发布 — 版本V2.3.1，灰度10%→30min观测→50%→30min→100%，全程自动健康检查
│ ├── 用例2：移动App发版 — 上传商店→审核中→灰度发布(部分地区5%)→全量发布→强制更新旧版本
│ ├── 用例3：大促全链路发布 — 压测→限流→降级→扩容→监控的联合发布（涉及10+系统同时变更）
│ ├── 用例4：基础设施变更发布 — Terraform Plan→审批→Apply→验证→状态存储（GitOps流程）
│ └── 用例5：内容/配置发布 — CMS内容发布→CDN刷新→预览验证→全网生效，配置中心灰度→全量→回滚验证
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ 发布计划书 │
│ 发布编号：REL-2025-056 版本：V3.2.0 │
│ 发布类型：[常规/紧急/大版本] 风险等级：中 │
│ │
│ ▷ 发布概览 │
│ 发布内容：订单服务V3.2.0 + 支付服务V2.1.3 + 配置变更×3 │
│ 关联变更单：CHG-2025-0731 / CHG-2025-0735 │
│ 发布时间：2025-08-01 22:00-24:00（变更窗口） │
│ │
│ ▷ 发布角色 │
│ 发布经理(Release Manager)：李四 — 总协调+Go/No-Go决策 │
│ 部署执行人：张三 — 执行部署操作 │
│ 验证人：赵六 — 烟雾测试+指标对比 │
│ 值班oncall：钱七 — 监控+应急响应 │
│ │
│ ▷ 发布前检查（Go/No-Go Check） │
│ [ ] 测试报告：P0/P1=0，性能达标，安全扫描通过 │
│ [ ] 发布Runbook已更新 │
│ [ ] 回滚方案就绪+已演练 │
│ [ ] 监控大盘+告警规则已配置 │
│ [ ] 值班人员已到位（22:00-24:00） │
│ [ ] 客服/市场团队已通知 │
│ [ ] 代码已冻结（8/1 12:00起无新提交） │
│ │
│ ▷ 灰度策略 │
│ 阶段1: 22:00 — 5%流量 → 观察15min → 健康检查 │
│ ✅ 错误率<0.1% ✅ P99延迟正常 ✅ 业务指标无异常 │
│ 阶段2: 22:15 — 25%流量 → 观察15min → 健康检查 │
│ 阶段3: 22:30 — 100%流量 → 观察30min → 最终验证 │
│ ⚠ 任一步骤异常 → 立即回滚 │
│ │
│ ▷ 发布结果（发布后填写） │
│ 发布时间：22:00-22:45 结果：[成功/部分/失败] │
│ 异常记录：阶段3全量后P99延迟+15%→排查为缓存未命中→服务预热后恢复 │
│ 回滚：无 │
└──────────────────────────────────────────────────────────┘
|
19. 回滚方案（Rollback Plan）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
| 回滚方案（Rollback Plan）
├── 是什么：变更或发布失败后，将系统或流程恢复至变更前正常状态的标准化操作步骤。
│ 是风险兜底的核心预案——"如果搞砸了，怎么回到安全状态"。
│
├── 为什么
│ ├── 最后一道防线：前面的检查/灰度/验证都失效时，回滚是保底手段
│ ├── 缩短决策时间：出问题时不用"怎么办"，直接"执行回滚方案"
│ ├── 心理安全感：团队知道有退路，才敢于做必要的变更（而非因害怕风险而不变）
│ └── 强制要求：多数合规框架（ITIL/SOC2/ISO）要求变更必须附带回滚方案
│
├── 怎么做
│ ├── 1. 每次变更都必须有回滚方案（紧急变更至少口头确认回滚路径）
│ ├── 2. 回滚方案包含：触发条件 → 执行步骤 → 验证步骤 → 预计耗时 → 责任人
│ ├── 3. 优先使用自动回滚（如K8s自动回滚到上一个健康版本）
│ ├── 4. 回滚方案必须在预发布/测试环境验证过——"理论上能回滚"=不存在的方案
│ ├── 5. 区分技术回滚和数据回滚（代码回去了，数据要不要回？怎么回？）
│ ├── 6. 执行回滚后必须验证：切回去≠正常，必须检查核心指标
│ └── 7. 记录"回滚窗口"最晚时间——过了某个时间点，回滚比修复更危险时就不能回滚了
│
├── 使用用例
│ ├── 用例1：K8s部署回滚 — kubectl rollout undo deployment/order-svc，30秒完成+自动健康检查
│ ├── 用例2：数据库Schema变更回滚 — 执行反向DDL脚本（DROP新增列/索引），需额外注意数据丢失风险
│ ├── 用例3：配置变更回滚 — 配置中心一键回滚到上一版本，热更新不需要重启
│ ├── 用例4：多云流量切换回滚 — 切回旧集群VIP，需确认旧集群未缩容/未清理
│ └── 用例5：物理设备变更回滚 — 换回旧零件/模块，需确认旧件还在现场、可复用
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ 回滚方案（附属变更单：CHG-2025-0731） │
│ │
│ ▷ 回滚触发条件（满足任一即启动回滚） │
│ 1. 错误率 > 0.1% 持续 ≥ 5分钟 │
│ 2. P99延迟 > 基线×2 持续 ≥ 10分钟 │
│ 3. 发布经理手动判定（如出现预期外异常） │
│ 4. 灰度阶段自动健康检查失败 │
│ │
│ ▷ 回滚决策 │
│ 决策人：发布经理（李四） │
│ 决策时限：变更开始后60分钟内可执行回滚 │
│ 60分钟后修复优先于回滚（除非数据严重异常） │
│ │
│ ▷ 技术回滚步骤（预计耗时：8分钟） │
│ │
│ Step 1: 切回旧版本（2分钟） │
│ kubectl rollout undo deployment/order-svc │
│ 预期：Pod替换为旧版本镜像 │
│ 验证：kubectl get pods -l app=order-svc → 全部Running │
│ │
│ Step 2: 配置回滚（1分钟） │
│ 配置中心点击"回滚至变更前版本" │
│ 预期：配置立即生效（热更新） │
│ 验证：curl health端点 → 确认使用旧配置 │
│ │
│ Step 3: 数据回滚（如有，3分钟） │
│ [本次变更无数据结构变更，跳过] │
│ 如有：执行反向DDL / 数据修复脚本 / 从快照恢复 │
│ │
│ Step 4: 验证恢复（2分钟） │
│ [ ] 错误率恢复至基线水平 │
│ [ ] P99延迟恢复至基线水平 │
│ [ ] 烟雾测试通过（下单/支付/退款） │
│ [ ] 监控告警自动恢复 │
│ │
│ ▷ 回滚后处理 │
│ · 通知相关方：内部群+客户通知（如影响用户） │
│ · 保持旧版本运行≥24小时，确认完全稳定后才可重新发布 │
│ · 变更单标记"已回滚"，启动RCA分析失败原因 │
│ │
│ ▷ 回滚方案演练记录（执行前确认） │
│ 演练时间：2025-07-21 15:00（预发布环境） │
│ 演练结果：✅ 成功，实际耗时6分钟 │
│ 演练人：张三 / 复核人：李四 │
└──────────────────────────────────────────────────────────┘
|
五、流程效能管理类
20. 标准作业（Standard Work）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
| 标准作业（Standard Work）
├── 是什么：当前条件下经过验证的最优作业方式，明确作业顺序、标准时长(Takt Time/
│ Cycle Time)、在制品定额(Standard WIP)。是流程效率优化的基准，也是
│ SOP持续迭代的目标。
│
├── 为什么
│ ├── 消除浪费：标准作业是基于最优方式制定的，消除了多余的走动、等待、返工
│ ├── 可度量的改进：没有标准就没有"偏差"，不知道现在的效率是80分还是50分
│ ├── 产能规划的依据：基于标准工时可计算人员和设备的产能
│ └── 持续改善的基石：Kaizen(改善)的前提是先有Standard(标准)
│
├── 怎么做
│ ├── 1. 选定目标工序，用秒表/录像观测当前操作，记录每个动作的时间
│ ├── 2. 区分增值动作（切削/组装）与非增值动作（走动/等待/找工具），消除后者
│ ├── 3. 设计最优的作业顺序：最短的动作路径、最少的工具切换
│ ├── 4. 测量标准工时（Cycle Time），设定在制品定额（Standard WIP）
│ ├── 5. 制作标准作业组合票（Standard Work Combination Sheet）
│ ├── 6. 培训操作者 → 执行 → 测量 → 偏差分析 → 改进 → 更新标准
│ └── 7. 标准作业是动态的：每次改进后更新标准，而非一成不变
│
├── 使用用例
│ ├── 用例1：焊接工位标准作业 — 标准工时22秒/件，标准WIP=3，作业顺序6步，消除伸手取料动作(节省3秒)
│ ├── 用例2：客服标准作业 — 标准处理时长4分钟/单，标准话术+知识库检索顺序，减少无效确认
│ ├── 用例3：仓库拣货标准作业 — 标准拣货速度120件/小时，优化拣货路径减少行走距离30%
│ ├── 用例4：代码审查标准作业 — 标准审查时间30分钟/PR，审查清单顺序：安全→逻辑→风格→测试覆盖
│ └── 用例5：餐厅出餐标准作业 — 标准出餐时间8分钟/单，备料前置+并行烹饪+装盘标准化
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ 标准作业组合票（Standard Work Combination Sheet） │
│ 工位：组装工位A3 产品：Type-C充电器 版本：V2.3 │
│ 节拍时间(Takt Time)：30秒/件 日需求：960件 │
│ │
│ ▷ 作业要素分解 │
│ 序号 作业要素 时间 分类(自动/手动/走动/等待) │
│ 1 取外壳+放入夹具 3秒 手动 │
│ 2 取PCB板 2秒 手动 │
│ 3 插入PCB至外壳 4秒 手动 │
│ 4 自动锁螺丝×2 6秒 自动 │
│ 5 外观检查 5秒 手动 │
│ 6 放入传送带 2秒 走动 │
│ ──────────────────────────────────────── │
│ 总周期时间：22秒（< Takt Time 30秒 ✅） │
│ │
│ ▷ 标准WIP：3件（工位前缓冲区2件 + 工位中1件） │
│ │
│ ▷ 改善记录 │
│ V2.2→V2.3：将料盒从工位左侧移至正前方，步骤1时间从5秒降至3秒 │
│ V2.1→V2.2：工具归位标准化（固定每个工具的放置位），步骤6从4秒降至2秒│
│ │
│ ▷ 标准作业遵守率 │
│ 本周：94% 目标：≥ 95% │
│ 偏差Top1：步骤4自动锁螺丝偶尔卡料 → 维护计划：每周清洁导轨 │
└──────────────────────────────────────────────────────────┘
|
21. 流程基线（Process Baseline）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
| 流程基线（Process Baseline）
├── 是什么：流程在稳定运行状态下的基准水平，包含交付周期(Lead Time)、通过率
│ (Throughput Rate)、故障率(Failure Rate)等核心指标。用于衡量流程
│ 优化的实际效果——没有基线就不知道改进了多少。
│
├── 为什么
│ ├── 改进的标尺："优化后交付周期缩短30%"——前提是知道优化前是多少
│ ├── 异常检测：当前指标偏离基线超过阈值 → 可能出了问题
│ ├── 目标设定：改进目标=基线×提升比例，而非拍脑袋的数字
│ └── 流程健康度：通过基线趋势判断流程是在变好、变差还是震荡
│
├── 怎么做
│ ├── 1. 确定要度量的核心流程（端到端或关键环节）
│ ├── 2. 选择关键指标：交付周期(Lead Time/Cycle Time)、吞吐量、通过率、返工率
│ ├── 3. 收集数据：至少3-6个月的稳定运行数据（排除异常时期如大促/故障期）
│ ├── 4. 计算基线：通常取中位数(P50)作为基线，P80/P95作为波动范围
│ ├── 5. 可视化：控制图(SPC Chart)或趋势图，标注基线和上下控制线
│ ├── 6. 定期更新基线：流程改进后重新采集数据更新（但保留历史基线做对比）
│ └── 7. 异常响应：当前指标超出控制线 → 触发根因分析 → 改进或调整基线
│
├── 使用用例
│ ├── 用例1：需求交付基线 — 从需求确认到上线的端到端周期，基线12天(P50)/18天(P95)
│ ├── 用例2：客服工单基线 — 首次响应时间基线3分钟，解决时间基线4小时，满意度基线92%
│ ├── 用例3：生产线基线 — 日产960件，良品率98.5%，设备综合效率OEE 85%
│ ├── 用例4：部署基线 — 部署频率5次/周，部署成功率96%，变更失败率3%
│ └── 用例5：招聘基线 — 从投递到Offer平均28天，简历初筛通过率15%，Offer接受率70%
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ 流程基线卡（Process Baseline Card） │
│ 流程：订单API需求交付（需求确认→生产上线） │
│ 数据周期：2025年1月-6月 样本量：127个需求 │
│ │
│ ▷ 基线指标 │
│ 指标 基线(P50) 波动范围(P25-P75) 警戒线(P95) │
│ ─────────────────────────────────────────────────────── │
│ 交付周期(Lead Time) 10天 7-15天 22天 │
│ 开发周期 5天 3-8天 12天 │
│ 测试周期 2天 1-4天 7天 │
│ 一次通过率 78% 70-85% - │
│ 返工率 15% 10-22% 30% │
│ 需求变更率 8% 3-12% 20% │
│ │
│ ▷ 趋势图（最近6个月） │
│ 交付周期：10→11→9→8→9→8（📉缩短中，8月目标=8天 ✅） │
│ 一次通过率：75→76→78→80→78→82（📈提升中 ✅） │
│ 返工率：18→16→15→14→15→12（📉降低中 ✅） │
│ │
│ ▷ 异常点记录 │
│ 2025-03：交付周期突增至18天 → 原因：核心开发请假2周+需求积压 │
│ 处理：已纳入基线计算时的异常排除 │
│ │
│ ▷ 优化目标（基于基线） │
│ 交付周期：8天（相比基线10天缩短20%） │
│ 一次通过率：85%（相比基线78%提升7pp） │
│ 返工率：10%（相比基线15%降低5pp） │
└──────────────────────────────────────────────────────────┘
|
22. RACI矩阵
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
| RACI矩阵
├── 是什么：流程权责分配工具，明确每个环节的 Responsible(负责者)、Accountable
│ (批准者/最终负责)、Consulted(咨询者/双向沟通)、Informed(告知者/单向
│ 通知)。用于厘清跨角色协作的权责边界，消除"这是谁的事"的困惑。
│
├── 为什么
│ ├── 消除推诿：每个任务都有明确的R和A，出了问题不用猜"该找谁"
│ ├── 防止过度沟通：只通知I类角色，不需要拉所有人开会
│ ├── 发现权责盲区：矩阵中某行全是空白 → 没人负责；某列有多个A → 多主必乱
│ └── 新人快速理解协作关系：一张图知道"我要找谁、谁要找我"
│
├── 怎么做
│ ├── 1. 列出流程中的所有活动/决策（行），列出所有角色/岗位（列）
│ ├── 2. 逐格填写R/A/C/I，每个活动至少1个R、恰好1个A
│ ├── 3. 检验规则：
│ │ · 每行至少1个R（有干活的人）
│ │ · 每行恰好1个A（有最终负责的人，不会多人扯皮）
│ │ · 某人的R太多 → 瓶颈风险，考虑拆分
│ │ · 某人的A太多 → 审批瓶颈，考虑授权
│ │ · A和R可以是同一个人（小型团队常见）
│ ├── 4. 与所有角色确认，特别是有A的角色是否知晓并接受
│ ├── 5. 发布并贴在团队可见位置
│ └── 6. 每次组织/流程调整后及时更新
│
├── 使用用例
│ ├── 用例1：需求开发流程RACI — PM=编写需求(R/A) → TL=技术方案(R) PM=C → Dev=编码(R) TL=评审(A) → QA=测试(R) PM=A
│ ├── 用例2：采购流程RACI — 需求部门=提需求(R/A) → 采购部=询比价(R/A) → 法务=审合同(C/I) → 财务=付款(R/A)
│ ├── 用例3：发布流程RACI — Dev=准备发布包(R) → TL=审批(A) → DevOps=执行部署(R) → PM=验收(A) → Support=已知会(I)
│ ├── 用例4：故障响应RACI — 发现者=告警/建单(R) → oncall=止损(R) → TL=决策(A) → 客服=通知用户(R) → 全员=复盘(C)
│ └── 用例5：员工入职RACI — HR=流程统筹(R/A) → IT=开账号(R) → 行政=备工位(R) → 直属领导=制定首周计划(R/A)
│
└── 模板
┌──────────────────────────────────────────────────────────┐
│ RACI矩阵：软件需求交付流程 │
│ 版本：V1.2 生效日期：2025-07-01 │
│ │
│ R=负责执行(Responsible) A=最终负责/批准(Accountable) │
│ C=需咨询(Consulted)双向 I=需告知(Informed)单向 │
│ │
│ 活动/决策 PM TL Dev QA DevOps UX 客户 │
│ ──────────────────────────────────────────────────────── │
│ 需求调研 R/A C C │
│ 编写PRD R/A C C C │
│ PRD评审 A R C C C │
│ 技术方案设计 R/A C C C │
│ UI/UX设计 C C R/A │
│ 编码实现 C R/A C │
│ 单元测试 C R/A │
│ Code Review A/R C │
│ 功能测试 C C C R/A │
│ UAT验收 A/R C C C │
│ 生产发布 C A C R │
│ 发布后监控 I I I R/A │
│ 需求关闭 R/A I I I I I │
│ │
│ ▷ 角色说明 │
│ PM = 产品经理 │
│ TL = 技术负责人 │
│ Dev = 开发工程师 │
│ QA = 测试工程师 │
│ DevOps = 运维/SRE │
│ UX = 交互设计师 │
│ 客户 = 需求方/业务方 │
│ │
│ ▷ 检验结果 │
│ ✅ 每行都有至少1个R │
│ ✅ 每行都有恰好1个A │
│ ⚠️ PM的A较多(6个)→考虑授权TL分担 │
│ ⚠️ Dev在"生产发布"中没有R→已确认本次不涉及 │
└──────────────────────────────────────────────────────────┘
|
附录：名词关系全景图
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
| ┌─────────────────────────────────────┐
│ 流程效能管理层 │
│ ┌──────────┐ ┌──────────────┐ │
│ │ 标准作业 │ │ 流程基线 │ │
│ │ (最优方式)│ │ (度量基准) │ │
│ └────┬─────┘ └──────┬───────┘ │
│ │ │ │
│ ┌────┴───────────────┴────┐ │
│ │ RACI矩阵 │ │
│ │ (权责分配工具) │ │
│ └─────────────────────────┘ │
└─────────────────────────────────────┘
│
┌─────────────────────────────┼─────────────────────────────┐
│ │ │
┌─────┴──────────┐ ┌──────┴──────┐ ┌───────────┴──────┐
│ 核心作业规范层 │ │ 生产交付执行层│ │ 质量管控门禁层 │
│ │ │ │ │ │
│ SOP(最高层规范) │────────▶│ 工单(执行单元)│────────▶│ DoR(准入标准) │
│ │ │ 派发 │ │ │ 流转 │ ↓ │
│ ├─Runbook │ │ ├─工艺路线 │ │ 质量门禁(校验卡点)│
│ │ (技术操作) │ │ ├─WIP(在制) │ │ ↓ │
│ ├─Playbook │ │ ├─CI/CD │ │ DoD(完成标准) │
│ │ (协同决策) │ │ └─Sprint │ │ ↓ │
│ ├─WI(岗位细则)│ │ │ │ 达成→工序交接 │
│ └─Checklist │ │ │ │ 未达成→返工回路 │
│ (逐项校验) │ │ │ │ │
└────────────────┘ └──────────────┘ └──────────────────┘
│
┌─────────────┴─────────────┐
│ 变更与异常处置层 │
│ │
│ 变更管理 ──▶ 发布管理 │
│ │ │ │
│ ├─回滚方案◀──┘ │
│ │ │
│ 事件管理 │
│ (故障兜底) │
└───────────────────────────┘
│
┌─────────────┴─────────────┐
│ 服务质量承诺层 │
│ │
│ SLA(对外承诺) │
│ └──OLA(内部支撑) │
└───────────────────────────┘
|
层级关系简述
| 层级 |
包含名词 |
功能定位 |
| 流程效能管理层 |
标准作业、流程基线、RACI矩阵 |
设定最优方式、基准和权责，是”方向盘” |
| 核心作业规范层 |
SOP、Runbook、Playbook、WI、Checklist |
把作业方式写成可执行的标准文档，是”说明书” |
| 生产交付执行层 |
工单、工艺路线、WIP、CI/CD、Sprint |
按标准文档实际运转任务，是”发动机” |
| 质量管控门禁层 |
DoR、质量门禁、DoD |
在每个关键节点校验质量，是”刹车和检验” |
| 变更与异常处置层 |
变更管理、事件管理、发布管理、回滚方案 |
应对变化和故障，是”保险杠+备胎” |
| 服务质量承诺层 |
SLA、OLA |
对外和对内的服务质量契约，是”承诺书” |
文档信息
- 原始资料：《标准制造类名词》
- 版本：V1.0
- 编制日期：2025-07-29
- 覆盖名词：22个（5大类）
