Jez Humble，【持续交付】和【精益企业】两本书的作者，作为持续交付方面的***专家，在其多次分享中有很多的真知灼见。本文对他的观点做一个整理，和大家分享之：
1. DevOps不是一个目标，而是一个没有终点的持续改进过程
这个想法是想建立一种持续改进的文化，让所有人参与改进的文化。
2. IT性能指标不能等同于IT性能因素
根据2014年Puppet Labs所做的DevOps 报告所阐述的那样，IT有四个指标：
- Lead time for changes(变更前置期)
- Release frequency(发布频率)
- Time to restore service(故障恢复时长)
- Change fail rate(变更失败率)
影响IT性能指标背后的TOP5的因素有：
- Peer-reviewed change approval process(结对变更审批过程)
- Version control everything(版本控制一切)
- Proactive monitoring(主动式监控)
- High-trust organizational culture(高度信任的组织文化)
- A win-win relationship between dev and ops(Dev和Ops之间的双赢关系)
3. 指标必须持续优化和改进
DevOps应该避免一直使用相同的指标来度量，Jez说“你应该不断改进你的指标体系”，因为“每次你如何度量它，这个会改变你的行为”。这点非常重要，人们总是找到方式和方法以便达到指标，这就是所谓的度量/指标驱动。然后可悲的是，通常管理者把指标作为一个硬性管理工具，把它与业绩考核放在了一起，这样指标就失去了意义。如若这样，人们总是能找到方法让这些指标看起来很好看，而这样的话，则不是真正的帮助企业达成目标了。
在《精益数据分析》这本书中，也详细给出了关于数据分析的观点，不同的指标带来的行为以及结果是不同的。
4. 你可以在吞吐率和稳定性之间取得平衡
Jez讲到，2014年Puppet Labs DevOps 报告把IT质量分解成两个维度：吞吐率(包含变更和发布的前置期)和稳定性(包含故障恢复时间和变更失败率)。
在这两个方面之间，不是零和关系。“如果你的方式正确”，他说，“他们是可协调的”，事实上，高性能IT组织，在这两个方面都表现得比低性能IT组织要好。当然这背后又涉及到很多因素，有架构的、有平台、有组织、有文化、有基础设施的敏捷性等等因素。
吞吐率这个指标，大家都非常容易理解，和我们平时在压力测试中衡量的指标类似。稳定性代表的是一种业务服务的状态，许多时候大家通过降低变更的频率来确保稳定性，更甚至于是引入负责的变更审批流程来获得稳定性。这点在高度敏捷IT的今天，显然这种做法违背了IT作为核心能力的支撑作用，其次也降低了企业应对外界需求变化的能力。
5. 不要采用外部变更审批流(和国外情况相关)
Jez把外部审批流程比着是“风险管理中心”。因为外部的代码审查者根部不了解代码的情况，这种类型的Review降低了交付能力，并且也不能提高稳定性。
相反，一个结对审批过程提高吞吐率，且不影响稳定性，Jez说到，因为开发者最了解其代码的输出和输入。
6. 紧急变更流程是一个可怕的想法
显然，紧急变更流程是想绕过测试过程，这是一个非常可怕的想法，Jez说到。你已经有线上的问题或者你没有用紧急流程修复它，而是想在没有测试的情况下发起变更，这点只会让情况变得更糟，而不是更好。“你应该用正常的流程取代紧急情况”Jez说到“这才是正确的解决方式”。
在【持续交付】的原则中，有一句话提到“只有流水线才可以变更生产环境，防止配置漂移”，这一点更多是为了变更的安全考虑，不希望直接对生产环境变更。而这个“紧急”情况下的快速发布，必须要通过平台来解决，这样才能真正避免紧急发生。
7. 持续交付需要开发者每日的提交代码(***每天两次)
“DevOps是一种实践，而非工具，”Jez说到。持续交付的关键是要重构过去的做法，所有的代码必须可以独立部署，并且在提交主干之前被很好的测试，该集成能力且不应该付出高昂的代价。“这不是说需要一个工具，而恰恰是一种思维，确保软件一种可用的思维”。这就要求开发者必须把大的特性做小，增量变更来达成。
另一方面，如果每个人都在特性分支上开发，到***，他们必须去对分支进行集成，这对测试提出了非常高的要求，让系统集成测试的复杂变得异常复杂。
“从主干开发，从主干发布”，这是 一种高效的模式。通常来说，这种方式很难达成，这个和系统架构和需求的拆分有很大的关系。一方面我们需要把大的系统做小(微服务系统)，同时把Usestory也要拆小，变成一个个小的需求，这样才能达到主干开发的模式。
8. 在主干中遗留坏的代码是一种自私行为
如果你不能够在很短的时间内让这部分代码工作，那么你就应该回滚到变更前的状态。任何变更需要版本控制，如果代码运行异常(分为编译、打包、审查、测试异常)，此时研发者都应该需要理解修复他。
9. 质量不仅仅是软件测试者的责任
每个人都应该为质量负责。测试者只是让质量问题透明化，以确保软件可以工作，但测试本身并不能增加质量。
这就意味着测试不是应该在研发完成之后开始，而是一个开发过程的关键部分，在每一个阶段、任何时候。记住，这些测试用例的设计仅仅是为了确保代码是否可以部署，“如果经过大量的测试，你仍然对接下来的部署还深感焦虑，”Jez说，“那就意味着你的测试工作并没有做得足够好”。
内建质量同样是一种思维模式，Deming也讲过“不要依赖大量的检查手段来提升质量，而是在一开始就要把质量的意识和要求内建到产品中”。这就意味着从项目一开始，你应该去考虑影响质量的方方面面，如良好的代码习惯、标准化的代码结构、标准化的服务访问协议、使用标准的服务组件等等，同时在这个过程中，引入高效的自动化测试工具来提升质量。
10. 少即是多
研究表明，为了成功一个关键指标，而采用的种种手段和方法，通常其中的1/3才是有效的，余下的则没有那么明显。这让我想起腾讯性能哥分享的自动测试的案例，“对于一个庞大的系统来说，有几万个测试用例。如果每次修改都触发全回归，一方面代价高昂且不说，论效果来说，其实并不是很高。通常采用的是用例收敛的方法，用小部分的用例来回归变更”。
特别进入到一个企业中，如果要实施DevOps，此时“doing less”是***的策略。一定不要贪大求全，逐步改进。
“用户不知道他们想要什么，而一旦你为了他们提供了什么，用户就知道他们不想要什么”,在这个点上，需要基于最小可行产品，迭代式改进，确保商业目标的最终达成。
【本文是51CTO专栏作者“王津银”的原创稿件，转载请注明出处】
