DevOps 的最大难题就是，DevOps 是永无止境的。并不存在一个（确切的）DevOps指南，也没有什么最终标志能够证明一个组织完成了 DevOps 的漫长旅途。
如果有人恰巧觉得，本人/组织当前的 DevOps 实践已经达到了自身应用发布过程的终极需要，那么可能一年以后，这一环境就可能变成了新版本的瀑布。以不变应万变，是难以应对各种来自客户、来自基础设施以及部署方式的更迭的。所以我们要说，没有持续改进的持续交付，是没有前途的。
下面详细的解释一下我们的看法。
主动改进
自动化工具链是 DevOps 团队的制胜法宝，这一点毋庸置疑。然而这一切通常都是事出有因的，有时是有新技术发布，有时是组织机构改革等等。不管是什么在主导着变化，其实都不是主动发生的。变化只会在有条件的时候被触发，每一两年，都会出现这种机会。
持续改进则正好相反。持续改进意味着一种对改进的主动投入。这是一种对现状的改进意愿（和不满）。金无足赤，环境也是始终会有其弱点。DevOps 团队应避免故步自封，对现有的大好形势保持怀疑，不错过其中出现的任何微小缺陷。
但是文化和改进方面的管理焦点是很难贯彻始终的。一个 DevOps 工程师所实现的改进工作是很难量化的。一种文化究竟做出了什么贡献，也不是非常容易分辨的。有些组织认为自己是持续改进的牺牲品，但技术人员应该注意的是，一些看上去很美的新玩具，往往都会引入很多的额外问题，因此应该慎重考虑，而不是想上就上。
管线即应用
时至今日，CI 已经成为应用交付的内在需要，因此 Pipeline 理应得到跟其他应用一样的重视程度。应用开发过程是围绕 Backlog 进行的，所有的任务都是向其中添加功能或者修复其中的问题。那么如果将 Pipeline 视为应用的话，那么就有了持续改进的基础。为了达成这一目标，所有工作都应该进行脚本化，所有重复工作都应该自动化，Backlog 中随时反应了我们对交付链条的优化努力。Pipeline 应用也应该有自己的功能和 Bug。Pipeline 的客户就是开发人员和生产环境。在这样的视角之下，就能对 Pipeline 的变更和改进了然于心。
这里有个潜在的要求就是，要有专职人员负责 Pipeline 的开发，并在生产环境上进行维护。要实施这一方法的组织，必须做好这种准备。
重在结果
第三个问题是，如何判断当前的做法是正确的？必须做点什么来体现结果和指标。跟生产环境上的其他应用一样，我们的 Pipeline 也应该有各种 KPI。持续改进需要反映出随着时间的推移，各种指标的变化。例如：
- 本年度开始之后，发布过程变快了多少？
- 发布过程需要多少步骤？精简掉了多少？
- 有多少应用是 100% 自动部署的？
- 跟去年相比，发布活动多了多少？
有时候，改进是一种直觉。团队成员应该大致了解，Pipeline 是否减轻了压力并提高了部署能力。但是对持续改进的审慎态度，要求我们必须对过程中的得失进行量化，并作出汇报。
持续交付现在已经是开发活动的重要组成部分，但是如果不持续作出改进，那么整个环境都会逐渐变得过时。通过上面讲述的三个原则，来确保当下和未来的 DevOps 过程能够一以贯之的持续下去。
