DevOps落地方案可以用三张表承载：方案要素表定义目标、范围、角色与交付物，阶段推进表按现状评估、试点、推广、固化四阶段列出动作与完成标准，度量看板表约定交付周期、部署频率、变更失败率、恢复时长等指标的采集口径与复盘节奏。本文提供可直接复制的空白表、逐字段填写说明、必填与选填判断，以及一份完整填写示例，方案表也可放在ONES文档与工作项中承载和流转。
要点总览（TL;DR）
- DevOps落地方案用三张表承载：方案要素表定目标、范围、角色与交付物，阶段推进表按现状评估、试点、推广、固化四阶段拆动作，度量看板表约定指标口径与复盘节奏。
- 填写顺序为方案要素表→阶段推进表→度量看板表，阶段动作依赖目标与范围，指标依赖试点范围与基线。
- 必填字段集中在业务目标、覆盖范围、关键角色与职责、核心交付物、成功标准、方案负责人，以及各阶段的阶段目标、关键动作、责任人、完成标准；缺失会导致边界不清或无法验收。
- 示例表展示了成功标准、阶段完成标准与度量目标值之间的交叉引用，填写时保持这种联动，三张表才不会互相脱节。
- 方案表需约定更新触发条件、评审确认角色与版本记录方式，可放在ONES文档与工作项中承载，让填写、评审与执行状态保持同步。
DevOps落地方案空白模板（可直接复制）
三张表分别回答三个问题：做什么（方案要素）、怎么推进（阶段推进）、怎么判断有效（度量看板）。建议按“方案要素表→阶段推进表→度量看板表”的顺序填写，因为阶段动作依赖方案要素中的目标与范围，度量指标又依赖阶段推进中确定的试点范围与基线。先填方案要素表定方向，再拆阶段动作，最后为每个阶段配上可观测的指标。
表一：方案要素表（空白）
| 字段 | 填写内容 |
|---|---|
| 方案名称 | |
| 业务目标 | |
| 覆盖范围 | |
| 不覆盖范围 | |
| 关键角色与职责 | |
| 核心交付物 | |
| 关键依赖 | |
| 约束与风险 | |
| 成功标准 | |
| 方案负责人 | |
| 评审与确认方式 |
表二：阶段推进表（空白）
| 阶段 | 阶段目标 | 关键动作 | 责任人 | 协作方 | 完成标准 | 计划起止 | 状态 |
|---|---|---|---|---|---|---|---|
| 现状评估 | |||||||
| 试点 | |||||||
| 推广 | |||||||
| 固化 |
表三：度量看板表（空白）
| 指标 | 定义与采集口径 | 数据来源 | 基线值 | 目标值 | 统计周期 | 复盘节奏 | 责任人 |
|---|---|---|---|---|---|---|---|
| 交付周期 | |||||||
| 部署频率 | |||||||
| 变更失败率 | |||||||
| 恢复时长 | |||||||
| （自定义指标） |
字段说明：每列填什么、怎么判断填对了
字段说明的作用是让不同人填同一张表时口径一致。判断填对的标准不是文字漂亮，而是换一个人读完后能做出同样的判断或动作。
方案要素表字段含义
- 业务目标：写清方案要改善的业务结果，例如缩短某产品线的需求交付周期。填对的标准是能对应到一个可观测的结果，避免写成“提升研发效能”这类无法验证的表述。
- 覆盖范围：明确涉及的团队、产品线、交付环节。填对的标准是边界清晰，读者能判断某个团队或环节是否在方案内。
- 不覆盖范围：主动列出本期不处理的对象，防止后续争议。它与覆盖范围互为补充，两者合起来才构成完整边界。
- 关键角色与职责：列出方案负责人、各阶段责任人、评审人及其决策权限。填对的标准是每个角色都能对应到具体的人或岗位。
- 核心交付物：方案推进过程中要产出的文档、流程、看板或工具配置。填对的标准是交付物可被验收，而非抽象承诺。
- 关键依赖：方案推进依赖的外部条件，例如环境权限、工具链就绪、其他团队配合。
- 约束与风险：资源、时间、合规等限制，以及可能影响推进的风险点。
- 成功标准：与业务目标对应的验收条件，通常引用度量看板表中的目标值。
阶段推进表字段含义
- 阶段目标：该阶段结束时要达成的状态，例如“完成两个团队的试点并形成可复用流程”。
- 关键动作：为达成阶段目标要执行的具体事项，按动作而非按部门描述。
- 责任人：对该阶段结果负责的人，一个阶段只设一名主责人。
- 协作方：提供输入或配合执行的团队与角色。
- 完成标准：判断阶段结束的客观依据，例如试点团队按新流程完成若干次交付并通过复盘。
- 状态：建议统一为未开始、进行中、已完成、阻塞四种取值，便于汇总。
度量看板表字段含义
- 定义与采集口径：指标从哪个时间点算到哪个时间点、包含哪些环节。交付周期通常从需求进入开发算到上线，具体起止点需团队统一。
- 数据来源：指标取自哪个系统或记录，例如工作项状态流转、发布记录、故障单。
- 基线值：方案启动前的实际水平，用于对比改进效果。
- 目标值：阶段结束时希望达到的水平，应与成功标准一致。
- 统计周期与复盘节奏：多久统计一次、多久复盘一次，两者可以不同，例如按周统计、按双周复盘。
易混淆字段的区分
| 易混字段 | 区分要点 |
|---|---|
| 业务目标 vs 成功标准 | 业务目标描述要改善什么，成功标准描述达到什么程度算完成，后者应可量化并引用度量目标值。 |
| 覆盖范围 vs 不覆盖范围 | 前者是本期纳入的对象，后者是本期明确排除的对象，两者共同界定边界。 |
| 阶段目标 vs 完成标准 | 阶段目标是期望状态，完成标准是验证该状态是否达成的客观依据。 |
| 责任人 vs 协作方 | 责任人对结果负责并可做决定，协作方提供输入与配合，不承担该阶段结果责任。 |
| 基线值 vs 目标值 | 基线值是启动前的现状，目标值是改进后的期望，缺少基线时目标值难以判断是否合理。 |
必填与选填：哪些字段缺失会导致方案无法推进
必填字段的共同特征是：缺失后无法判断方案是否完成、由谁负责或如何验收。选填字段则影响方案的精细度，不影响基本推进。
| 表 | 必填字段 | 缺失后果 | 选填字段 |
|---|---|---|---|
| 方案要素表 | 业务目标、覆盖范围、关键角色与职责、核心交付物、成功标准、方案负责人 | 无法判断方案边界与验收条件，推进中容易出现责任真空和范围争议 | 不覆盖范围、关键依赖、约束与风险、评审与确认方式 |
| 阶段推进表 | 阶段目标、关键动作、责任人、完成标准 | 阶段无法启动或无法判断何时结束，进度汇总失去依据 | 协作方、计划起止、状态 |
| 度量看板表 | 指标、定义与采集口径、数据来源、复盘节奏 | 指标口径不一致会导致数据无法比较，复盘缺少可信输入 | 基线值、目标值、统计周期、责任人 |
按团队规模与阶段裁剪时，可参考以下原则：小团队首次落地可先保留必填字段，度量表只保留两到三个核心指标，待流程稳定后再补充基线值与目标值；跨团队推广阶段应补齐协作方与关键依赖，避免接口不清；进入固化阶段后，评审与确认方式、约束与风险等字段的价值上升，应一并补全。裁剪的对象是字段数量，必填字段本身不建议省略。
填写示例：一份完整的DevOps落地方案表
以下示例为演示情景，团队与数据均为虚构，用于说明字段之间如何联动，不代表任何真实组织的情况。
方案要素表示例
| 字段 | 填写内容 |
|---|---|
| 方案名称 | 订单服务交付流程改进方案 |
| 业务目标 | 缩短订单服务从需求确认到上线的交付周期，降低发布引发的线上故障 |
| 覆盖范围 | 订单服务研发与测试团队，需求评审至生产发布环节 |
| 不覆盖范围 | 基础设施迁移、其他业务线团队 |
| 关键角色与职责 | 方案负责人：研发经理；试点责任人：订单服务技术负责人；度量责任人：测试负责人；评审人：研发总监 |
| 核心交付物 | 统一的需求流转规则、发布检查清单、交付度量看板 |
| 关键依赖 | 测试环境权限、发布记录可追溯 |
| 约束与风险 | 季度内不能增加人力；试点期间业务需求高峰可能影响节奏 |
| 成功标准 | 试点团队交付周期较基线缩短，变更失败率不高于基线 |
| 方案负责人 | 研发经理 |
| 评审与确认方式 | 每阶段结束提交阶段报告，由研发总监确认后进入下一阶段 |
阶段推进表示例
| 阶段 | 阶段目标 | 关键动作 | 责任人 | 协作方 | 完成标准 | 计划起止 | 状态 |
|---|---|---|---|---|---|---|---|
| 现状评估 | 摸清当前交付流程与基线数据 | 梳理需求流转环节；采集近三个月交付数据；访谈研发与测试 | 研发经理 | 测试团队 | 形成现状说明与基线数据表 | 第1–2周 | 已完成 |
| 试点 | 在订单服务团队跑通新流程 | 落地需求流转规则；启用发布检查清单；按周统计指标 | 订单服务技术负责人 | 测试团队、运维 | 试点团队按新流程完成若干次发布并通过复盘 | 第3–8周 | 进行中 |
| 推广 | 将验证过的流程扩展到相邻团队 | 输出流程说明；培训新团队；收集反馈并修订 | 研发经理 | 相邻团队负责人 | 新团队按流程运行并纳入度量看板 | 第9–14周 | 未开始 |
| 固化 | 流程进入日常运行并有稳定度量 | 将规则写入团队规范；固定复盘节奏；明确指标维护人 | 研发经理 | 各团队负责人 | 连续多个统计周期指标稳定，复盘按节奏执行 | 第15周起 | 未开始 |
度量看板表示例
| 指标 | 定义与采集口径 | 数据来源 | 基线值 | 目标值 | 统计周期 | 复盘节奏 | 责任人 |
|---|---|---|---|---|---|---|---|
| 交付周期 | 需求进入开发到生产上线的时间 | 工作项状态流转记录 | 现状评估阶段采集 | 较基线缩短 | 按周 | 双周复盘 | 测试负责人 |
| 部署频率 | 单位时间内生产发布次数 | 发布记录 | 现状评估阶段采集 | 不低于基线 | 按周 | 双周复盘 | 测试负责人 |
| 变更失败率 | 发布后需回滚或紧急修复的比例 | 发布记录、故障单 | 现状评估阶段采集 | 不高于基线 | 按月 | 月度复盘 | 测试负责人 |
| 恢复时长 | 线上故障从发现到恢复的时间 | 故障单 | 现状评估阶段采集 | 较基线缩短 | 按月 | 月度复盘 | 运维负责人 |
示例与字段说明保持一致：成功标准引用了度量看板中的交付周期与变更失败率；阶段推进表的完成标准对应方案要素表中的核心交付物；度量责任人同时出现在方案要素表的角色栏与度量看板表中。填写时保持这种交叉引用，方案表之间才不会互相脱节。
调整与维护：方案表如何随迭代更新
方案表在首次填写后并非一成不变。阶段推进、指标口径和范围都会随实际执行变化，维护规则要提前约定，否则表格会逐渐失真。
更新触发条件
- 阶段状态变化：某阶段完成或阻塞时，更新阶段推进表的状态与完成说明。
- 范围调整：覆盖范围或团队发生变化时，同步修订方案要素表与度量看板表。
- 指标口径变更：数据来源或统计方式调整时，记录变更原因与生效时间。
- 复盘结论：双周或月度复盘产生改进行动时，将行动写入阶段推进表或新增阶段。
评审与确认角色
方案负责人负责日常更新，阶段完成与范围调整需经评审人确认；度量口径变更应由度量责任人提出并说明影响，避免历史数据失去可比性。评审节奏建议与度量复盘节奏对齐，减少重复会议。
版本与变更记录方式
| 记录项 | 填写内容 |
|---|---|
| 版本号 | |
| 变更日期 | |
| 变更内容 | |
| 变更原因 | |
| 提出人 | |
| 确认人 | |
| 影响范围 |
与协作工具的承载方式
方案表需要有人填写、有人评审、有人按表执行，放在文档中承载比分散在个人文件里更容易保持一致。ONES Wiki 支持文档关联项目任务，页面树可组织项目文档；页面模板库可一键创建制式化文档模板，适合把三张表做成固定模板；文档实时同步并记录页面版本，支持查看与回滚，便于追溯方案表的历次调整；还可为方案负责人、评审人等角色配置不同的读写权限。阶段推进表中的动作可以对应到工作项，文档支持嵌入任务进度与报表，使方案表与执行状态保持同步。度量看板表的口径确定后，ONES DevOps 解决方案支持多种数据报表，可追溯团队在 DevOps 工具链的操作并集中度量分析，用于支撑复盘时的数据核对。
常见问题
团队第一次落地DevOps，三张表要不要一次全部填完？
建议三张表都建，但填写深度可以分步推进。首次落地时，方案要素表先填必填字段，把业务目标、覆盖范围、关键角色、核心交付物和成功标准定下来；阶段推进表先写清现状评估与试点两个阶段；度量看板表先保留两到三个核心指标，基线值可以在现状评估阶段采集后再补。等试点跑通、流程稳定，再补齐目标值、协作方和风险字段。这样既保证方案可推进，也避免一开始就陷入填表工作。
基线数据拿不到，度量看板表还能用吗？
可以先用，但要标注清楚。基线值缺失时，目标值缺少参照，容易定得过高或过低。可行的做法是在现状评估阶段用一段固定周期采集一次实际数据作为临时基线，并在表中注明采集时间与口径；如果历史数据确实无法回溯，就把目标值写成相对表述，例如“较首次采集值缩短”，并在复盘中持续修正。需要避免的是基线空着却直接写绝对目标值，后续无法判断改进是否发生。
阶段推进表里的完成标准和方案要素表的成功标准有什么区别？
成功标准面向整个方案，回答“方案做成什么样算达成”，通常引用度量看板表中的目标值；完成标准面向单个阶段，回答“这个阶段什么时候可以结束”，依据是该阶段产出的交付物或验证动作。例如试点阶段的完成标准可以是试点团队按新流程完成若干次发布并通过复盘，而方案的成功标准是交付周期缩短、变更失败率不高于基线。两者层级不同，填写时不要互相替代。
方案表放在文档里，怎么保证执行状态和表格内容一致？
关键是让表格中的动作有对应的执行载体。阶段推进表的关键动作可以拆成工作项，由责任人推进状态；文档中嵌入任务进度与报表，复盘时直接对照表格与执行记录。ONES Wiki 支持文档关联项目任务，文档支持嵌入任务进度与各类报表，页面版本可查看与回滚，便于追溯方案表的历次调整。约定固定的更新触发条件，例如阶段状态变化或范围调整时同步修订，比依赖个人记忆更可靠。
方案推广到多个团队后，度量口径被各团队自行修改怎么办？
度量口径变更应有统一入口。建议在维护规则中明确：口径调整由度量责任人提出，说明变更原因、生效时间与对历史数据可比性的影响，经评审人确认后统一更新，并在变更记录表中留痕。各团队可以补充自己的观察指标，但核心指标的定义与采集口径保持全局一致，否则跨团队数据无法比较，复盘也失去共同语言。
