什么是 DevOps？
“Dev”和“Ops”的合并是指取代孤立的开发和运维团队。 其思路是创建多学科团队，这些团队将通过共享的做法、工具，实现对结果负责，共同合作。 重要的 DevOps 做法包括敏捷规划、持续集成、持续交付和对应用程序的全面监视。 DevOps 是不断改进的过程，而不是目标。
DevOps 的业务价值
实施 DevOps 实践的组织通常会在关键作指标中看到可衡量的改进：
- 部署频率：从不频繁的发布增加到常规的可预测部署
- 交付周期：从扩展的开发周期减少到更短的交付时间范围
- 平均恢复时间（MTTR）：更快的事件解决和系统还原
- 变更失败率：由于测试和自动化改进，生产问题减少了
预期的好处包括：
- 缩短新功能上市时间
- 与部署相关的事件减少
- 提高了开发人员的工作效率和满意度
- 通过自动化降低运营成本
了解和计算周期时间
让我们从使用 OODA（观察、调整、决定、行动）循环的软件开发基本概念开始。 OODA循环最初是为了防止战斗机飞行员被击落而设计的，现在成为一个优秀的商业框架，帮助企业领先竞争对手。
实践中的 OODA 循环：
- 观察：监视业务指标、市场趋势、用户行为和遥测数据
- 调整：可能通过试验来分析可交付内容的选项
- 决定：根据数据和业务优先级确定要追求的内容
- 作：将工作软件交付给真实用户并收集反馈
周期时间计算练习： 考虑当前的开发过程。 从
- 代码提交→生产部署？
- 功能请求→客户反馈？
- Bug 报告 → 在生产环境中修复需要多长时间？
示例：如果部署单行配置更改需要 2 周，则周期时间为 2 周。 这将会成为您的速度约束条件。
变为数据引导，而不是数据驱动
建议使用数据来指导下一个周期中的决策，但要避免因分析而陷入瘫痪。 许多组织的经验表明，部署通常具有不同的结果：
- 某些部署 将带来负面的业务结果
- 某些部署 将产生积极结果
- 某些部署 不会产生可度量的差异
关键原则：快速放弃那些不推进业务的计划，并在支持业务目标的结果上加倍投入。 此方法通常称为“转型或坚持”。
实用应用程序：
- 为新功能设置 A/B 测试
- 在部署之前定义成功指标
- 为失败的实验建立回滚机制
- 创建反馈循环以快速度量影响
坚持经过验证的学习路径
快速失败或加倍投入的速度取决于周期时间，即完成反馈循环所需的时间。 您在每个周期中收集的反馈应该是：
- 事实：基于实际用户行为和系统指标
- 可执行的：导致明确的后续步骤和决策
- 及时：足够快地可用以影响下一次迭代
这种基于证据的方法称为 经过验证的学习 - 根据经验证据而不是假设或意见做出决策。
已验证学习的示例指标：
- 用户参与率和功能采用
- 系统性能和错误率
- 客户满意度分数和支持工单
- 业务 KPI（收入、转换率、保留期）
缩短周期时间
采用 DevOps 做法时：
- 可以通过在较小的批次中工作来缩短周期时间。
- 使用更多自动化。
- 强化发布管道。
- 改进遥测。
- 更频繁地部署。
优化经过验证的学习
部署的频率越高，可以试验的频率就越大。 你拥有越多调整方向或坚持不懈的机会，就能在每个周期获得越多经过验证的学习。 这种对经过验证的学习路径的加速获取就是改进的价值所在。 将其视为你实现的进度和避免的失败的总和。
