---
schema_version: "1"
id: 97566f6754d20fc873fa9b2fc1338d9c255576ba5dcd1eedf41c769b87a71212
title: 持续改进 - 模式
collection: architect
version: current
locale: zh-cn
portal_url: https://docs.salesforce.com/architect/current/zh-cn/well-architected/guides/operational-excellence-continuous-improvement-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/well-architected/guide/operational-excellence-continuous-improvement-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 131793be59b2174a398f45b4ae901955d2e6f199d4c2e3bfb7948d4a5c61a505
products:
  - 架构良好的框架
  - Architect Site Content Repo
---
# 持续改进 - 模式

了解有关架构良好的[卓越运营](/docs/architect/zh-cn/well-architected/guide/operational-excellence.html)的更多信息 → [持续改进](/docs/architect/zh-cn/well-architected/guide/operational-excellence.html#continuous-improvement)

## 操作度量和 DORA

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| DORA | ✅ 跟踪部署频率；移动最快的团队按需部署，通常每天多次 |
| 平台 \| DORA | ✅ 变更的提前期是从代码提交到生产部署来衡量的；子天的提前期表示高性能交付，子小时表示卓越的能力 |
| 平台 \| DORA | ✅ 变更失败率被跟踪为导致需要补救的生产事故的部署百分比，并保持在较低的水平 |
| 平台 \| DORA | ✅ 衡量失败的部署恢复时间；一小时以下的恢复表示交付成熟 |
| 平台 \| DORA | ✅ 部署返工率作为生产事件导致的计划外部署的比率进行跟踪 |
| 平台 \| DORA | ✅ 度量分为吞吐量（提前期、部署频率、失败部署恢复时间）和不稳定（变更失败率、返工率）因素 |
| 平台 \| 度量 | ✅ DORA 度量持续测量并随时间变化趋势，改进轨迹的权重高于绝对值 |
| 平台 \| 仪表板 | ✅ 在整个组织可见的运营仪表板中跟踪度量，实现运营绩效的透明度 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 平台 \| DORA | 低部署频率反映了团队避免的部署难题，并造成了一种恶性循环，即不频繁的部署会使每次部署的风险更高 |
| 平台 \| DORA | ⚏ 较长的提前期反映了过多的流程开销、自动化不足或组织功能失调 |
| 平台 \| DORA | ⚏ 更改失败率高反映了测试不足、部署验证不足或更改仓促而没有适当的质量检查 |
| 平台 \| DORA | 恢复时间长反映了部署验证不足、缺乏自动回滚或生产事件的所有权不明确 |
| 平台 \| DORA | ⚠ 高返工率表明生产事件经常推动紧急部署，表明生产前测试、发布验证或更改管理中存在差距 |
| 平台 \| 度量 | 度量被捕获为时间点快照，而不是随时间变化的趋势，隐藏运营性能是改善还是下降 |

## 回顾和审查

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| 进程 | ✅ 定期进行冲刺回顾（每次冲刺或每月），为反思创造节奏，而不是等待危机 |
| 平台 \| 进程 | ✅ 回顾使用结构化格式（开始/停止/继续、疯狂/悲伤/高兴、时间线），鼓励参与和可操作的结果 |
| 平台 \| 进程 | ✅ 主持人轮换，以防止任何人主导讨论 |
| 平台 \| 进程 | ✅ 回顾性见解转化为具体的操作项目，包括所有者和完成日期，为每个会话带来少量改进 |
| 平台 \| 进程 | ✅ 跨回顾跟踪操作项目的完成情况，使团队对跟进负责 |
| 平台 \| 操作 | ✅ 运营审查每季度或每月评估一次总体运营状况，检查趋势数据并与目标进行比较 |
| 平台 \| 操作 | ✅ 运营审查让领导层参与进来，以确保为与功能开发竞争的运营改进工作提供资源 |
| 平台 \| 操作 | ✅ 审查包括运营度量：按旅程划分的可用性与目标、按百分位数划分的延迟趋势、按严重性划分的事件计数与平均检测和解决时间、部署频率和成功率，以及运营负载，例如随叫随到的页面和工作时间 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 平台 \| 进程 | ⚠ 追溯等待危机的发生，而不是定期发生 |
| 平台 \| 进程 | ⚠ ⸏ 回顾会产生冗长的讨论，但没有行动，浪费时间并滋生犹 ⁇  |
| 平台 \| 进程 | 操作项目的定义没有所有者或完成日期，因此讨论了改进，但从未实施 |
| 平台 \| 进程 | 操作项目完成情况永远不会跨回顾跟踪，导致跟进未知 |
| 平台 \| 操作 | ⚏ 运营被视为仅在危机期间受到关注的不可见后台工作，没有定期的业务审查 |
| 平台 \| 操作 | 运营审核缺乏领导参与，因此改进工作在资源分配时会败给功能开发 |

## 操作就绪审查

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| 操作 | ✅ 运营就绪审查评估新功能或系统在生产发布前是否满足运营要求 |
| 平台 \| 操作 | ✅ 在生产发布新解决方案、主要功能或具有运营影响的架构更改之前进行审查 |
| 平台 \| 操作 | ✅ 审查时间是平衡的，因此实施是足够完整的，可以评估，而不会因为操作问题来得太晚而无法解决 |
| 平台 \| 监控 | ✅ 审核确认有足够的度量，存在失败场景的警报，仪表板显示健康状态 |
| 平台 \| 文档 | ✅ 审核确认常见操作存在运行手册，为响应者记录架构，升级程序清晰 |
| 平台 \| 部署 | ✅ 审核确认部署执行可靠，存在回滚过程，并且部署已在暂存中验证 |
| 平台 \| 性能 | ✅ 审核确认性能目标在现实负载下得到验证，存在增长空间，并评估调控器限制风险 |
| 平台 \| 安全性 | ✅ 审核确认安全审核完成，满足审核要求，访问控制匹配要求 |
| 平台 \| 依赖性 | ✅ 审查确认外部依赖性已识别，集成合作伙伴有服务级别协议，并且存在依赖性失败的后备行为 |
| 平台 \| 治理 | ✅ 生产启动在审核完成时关闭，使运营成为部署要求，而不是尽力而为 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 平台 \| 治理 | ⚏ 新功能在未进行运营就绪评估的情况下发布到生产环境，累积运营债务，使未来实现卓越运营变得越来越困难 |
| 平台 \| 操作 | 审查进行得太晚，因此操作问题就像是部署障碍，并造成跳过修复的压力 |
| 平台 \| 治理 | ⚠ 运营就绪被视为尽力而为，而不是部署要求 |

## 反馈循环和学习文化

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| 文化 | ✅ 心理安全允许诚实地讨论问题、错误和近乎错误，而不必担心受到惩罚 |
| 平台 \| 文化 | ✅ 心理安全是通过无可指责的死后、庆祝问题发现和通过讨论自己的错误来构建领导力建模的脆弱性 |
| 平台 \| 度量 | ✅ 测量通过运营度量、事件趋势、DORA 指标和用户满意度分数使运营状态可见，从而客观地确定改进工作的优先级 |
| 平台 \| 操作 | ✅ 工程能力专为运营改进、技术减债、工具和自动化投资预留 |
| 平台 \| 操作 | ✅ 反馈环路将运营经验与设计决策联系起来，因此事件推动了架构改进，监控驱动器优化，部署失败推动了测试覆盖率的提高 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 平台 \| 文化 | 缺乏心理安全的团队隐藏问题，直到它们变成灾难，阻止早期干预 |
| 平台 \| 操作 | ⚏ 团队将所有容量花在功能上，而没有时间进行运营改进，累积了技术和运营债务，最终导致危机响应 |
| 平台 \| 操作 | ⚏ 运营经验没有反馈到设计中，因此相同的弱点会重复出现，运营会逐渐降级而不是改善 |