DevOps 不是一个工具名称，也不是把开发人员叫成运维。它是一套文化、工作方式和工程能力，目标是让开发、测试、安全和运维共同对软件从需求到生产运行的完整生命周期负责。
## 1. DevOps 要解决什么问题
传统交付经常出现这些现象：
- 开发只负责写代码，发布失败后再交给运维处理。
- 测试环境、预发环境和生产环境的构建方式不同。
- 发布依赖个人经验和临时命令，过程无法复现。
- 变更批次很大，几周甚至几个月才上线一次。
- 故障发生后先找责任人，而不是先恢复服务和改进系统。
DevOps 通过跨职能协作、版本控制、持续集成、自动化测试、部署自动化、可观测性和持续改进缩短反馈周期，让变更更小、更频繁、更容易验证和回滚。
## 2. DevOps 首先是一种共同责任
一个高效团队不会把发布当作开发完成后的“交接”。研发、测试、安全、运维和产品需要共同回答：
- 用户真正需要什么结果？
- 代码怎样构建、测试和部署？
- 生产风险怎样评估和控制？
- 出现异常时如何检测、止损和恢复？
- 怎样把事故经验变成自动检查或平台能力？
共同责任不等于每个人做同样的工作，而是目标、信息和反馈透明。专业角色仍然存在，但流程不能依赖部门间排队和口头传递。
## 3. DevOps 的核心能力
### 版本控制
代码、配置、流水线、基础设施和策略尽量进入版本控制。每次生产变更都能关联到提交、评审、构建产物、测试结果和审批记录。
### 持续集成
开发者频繁把小批量变更合入主干，自动执行构建、单元测试、静态检查和安全扫描。失败应快速反馈，并优先恢复主干健康。
### 持续交付
每次通过验证的变更都形成可发布产物，并能够按需部署到生产。持续交付强调“随时可以发布”，不强制每次都自动进入生产。
### 部署自动化
使用统一工具和声明式配置执行部署，避免人工上传包和在服务器上临时修改。自动化还应包括验证、暂停、继续和回滚。
### 可观测性与可靠性
指标、日志、追踪和用户体验信号必须进入交付反馈。发布是否成功不应只看进程启动，而要看错误率、延迟、吞吐、资源和业务指标。
### 持续学习
通过无责复盘、故障演练、改进实验和内部分享，让团队从失败中学习。自动化不是一次性项目，需要根据数据持续调整。
## 4. DevOps 不等于什么
- 不等于购买 Jenkins、GitLab、Kubernetes 或某个云平台。
- 不等于让运维承担所有自动化工作。
- 不等于取消评审、测试和变更控制。
- 不等于为了追求频率而牺牲稳定性。
- 不等于所有服务必须使用完全相同的工具链。
工具只能放大已有流程。职责不清、反馈缓慢和大批量变更没有改善时，增加更多工具往往只会增加复杂度。
## 5. 用 DORA 指标观察交付能力
DORA 当前把软件交付表现归纳为吞吐与不稳定性，并使用五个指标：
- Change lead time：代码提交到成功运行在生产所需时间。
- Deployment frequency：在一定周期内的部署次数或部署间隔。
- Failed deployment recovery time：生产部署失败后恢复服务的时间。
- Change fail rate：需要回滚、热修复或立即干预的部署比例。
- Deployment rework rate：为修复生产缺陷而进行的非计划部署比例。
这些指标应针对一个具体应用或服务观察趋势，而不是用来比较不同团队、给个人排名或制造目标数字。频率提高但失败率和返工率恶化，说明流水线只是在更快地产生风险。
## 6. 从哪里开始
建议选择一个真实但风险可控的服务，完成最小闭环：
1. 所有代码和部署配置进入版本控制。
2. 合并请求必须经过评审和自动测试。
3. CI 构建一个带唯一版本的不可变产物。
4. 同一产物依次部署到测试、预发和生产。
5. 生产发布采用小流量验证和自动健康检查。
6. 能在明确时间内回滚到上一个版本。
7. 记录五个交付指标和用户可靠性指标。
8. 每月选择一个瓶颈持续改进。
## 7. 团队成熟度检查
可以用以下问题进行自查：
- 发布是否依赖某位工程师在线？
- 能否知道生产运行的版本来自哪个提交？
- 同一个提交能否在不同环境得到相同产物？
- 测试失败后多久能反馈到开发者？
- 发布异常能否自动停止扩散？
- 回滚是否经过演练，数据变更是否可逆？
- 事故改进项是否真正进入产品或流水线？
DevOps 的目标不是“上线一套平台”，而是持续提高组织安全、快速交付有价值软件的能力。
## 参考资料
- https://dora.dev/capabilities/continuous-delivery/
- https://dora.dev/guides/dora-metrics/
- https://dora.dev/research/