JezHumble，《持续交付》和《精益企业》两本书的作者，作为持续交付领域的顶级专家，在他的众多分享中有很多感悟。本文整理了他的观点，分享给大家：1.DevOps不是一个目标，而是一个没有终点的持续改进过程。这个想法是建立一种持续改进的文化，让每个人都参与到改进的文化中来。2.IT性能指标不能等同于IT性能因素根据PuppetLabs2014年的DevOps报告，IT有四个指标：Leadtimeforchanges（变更提前期）Releasefrequency（发布频率）TimetoRestoreservice（故障）recoverytime)Changefailrate（变更失败率）影响IT绩效指标背后的TOP5因素：Peer-reviewedchangeapprovalprocess（pairingchangeapprovalprocess）Versioncontroleverything（版本控制一切）Proactivemonitoring（主动监控）High-trustorganizationalculture(highlytrustedorganizationalculture)Awin-winrelationshipbetweendevandops(Awin-winrelationshipbetweenDevandOps)3.IndicatorsmustbecontinuouslyoptimizedandimprovedDevOpsshouldavoidusingthesameindicatorsalwaystomeasure,Jez说“你应该不断改进你的指标”，因为“每次你衡量它，它都会改变你的行为”。这一点很重要，人们总是为了达到目标而想方设法，这就是所谓的metric/metricdriven。可悲的是，通常管理者将指标视为一种僵化的管理工具，将其与绩效考核放在一起，使指标失去了意义。如果是这样，人们总能想办法让这些指标看起来不错，在这种情况下，并不能真正帮助企业实现目标。《精益数据分析》一书中也详细给出了对数据分析的看法，不同的指标带来的行为和结果是不一样的。4.你可以在吞吐量和稳定性之间取得平衡Jez表示，2014年PuppetLabsDevOps报告将IT质量分解为两个维度：吞吐量（包括变更和发布的前置时间）和稳定性（包括故障恢复时间和变更失败率）.这两个方面之间，不存在零和关系。“如果你做对了，”他说，“它们是可以协调的，”事实上，高性能IT组织在这两个方面都优于低绩效IT组织。当然，这背后涉及到很多因素，比如结构、平台、组织、文化、基础设施的敏捷性等等。吞吐率这个指标大家非常容易理解，和我们平时压力测试衡量的指标类似。稳定性代表业务服务的状态。在很多情况下，人们通过降低变更频率来确保稳定性，甚至引入负责任的变更审批流程来实现稳定性。在当今高度敏捷的IT环境中，这种做法显然违背了IT作为核心能力的支撑作用，其次，也降低了企业应对外部需求变化的能力。5、不使用外部变更审批流程（涉外情况）Jez将外部审批流程比作“风险管理中心”。由于外部代码审阅者不了解代码，因此这种审阅会降低可交付性并且不会提高稳定性。相比之下，成对的批准流程可以提高吞吐量而不影响稳定性，Jez说，因为开发人员最了解他们代码的输出和输入。6.紧急变更过程是一个糟糕的想法显然，紧急变更过程是试图绕过测试过程，这是一个非常糟糕的想法，Jez说。事实上，您已经在线上遇到问题，或者您没有通过紧急流程修复它，并且想在没有测试的情况下启动更改，这只会让事情变得更糟，而不是更好。“你应该用正常流程代替紧急情况，”杰斯说，“这是正确的解决方案。”在【持续交付】的原则中，有一句话是“只有流水线才能改变生产环境，防止配置漂移”。这更多是为了变更的安全性，不宜直接变更生产环境。而在这种“紧急”情况下的快速发布，必须要通过平台来解决，才能真正避免突发事件。7.持续交付要求开发人员每天提交代码（一天两次***）“DevOps是一种实践，而不是一种工具，”Jez说。持续交付的关键是重构过去的做法。在提交到主干之前，所有代码都必须是可独立部署和经过良好测试的。这种集成功能应该不会很昂贵。“这并不是说需要一种工具，而是一种思维，它保证了软件是可用的。”这就需要开发者把大的特性做小，实现增量的改变。另一方面，如果大家都在特性分支上开发，最后还要集成分支，这对测试提出了很高的要求，使得系统集成测试的复杂度变得异常复杂。“从主干开发，从主干发布”，这是一种高效的模式。一般来说，这种方式实现起来比较困难，这与系统架构和需求的拆分有很大关系。一方面需要把大系统做小（微服务系统），同时需要把Usestory拆解成小的需求，从而实现骨干开发模式。8.在主线上留下损坏的代码是一种自私的行为。如果你不能让这部分代码在短时间内工作，那么你应该回滚到更改前的状态。任何更改都需要版本控制。如果代码运行异常（分为编译异常、打包异常、审核异常、测试异常），此时开发者应该了解并修复。9.质量不仅仅是软件测试人员的责任每个人都应该对质量负责。测试人员只是让质量问题透明化以确保软件正常工作，但测试本身并不能增加质量。这意味着测试不应在研发完成后才开始，而是开发过程中的关键部分，在每个阶段和任何时候。请记住，这些测试用例只是为了确保代码可以部署而设计的。“如果在大量测试之后，你仍然对接下来的部署深感焦虑，”杰斯说，“那说明你的测试工作还没有做得足够好。”内在品质也是一种思维方式。戴明还说，“不要靠大量的检验手段来提高质量，而是从一开始就把质量意识和要求植入到产品中。”这意味着从项目一开始，就应该考虑影响质量的方方面面，比如良好的代码习惯、规范的代码结构、规范的服务访问协议、使用标准的服务组件等，并在这个过程中，引入高效的自动化测试工具，以提高质量。10.少即是多研究表明，通常有1/3的手段和方法用于实现一个关键的成功指标是有效的，其余的则不那么明显。这让我想起了腾讯性能小哥分享的自动化测试案例，“一个庞大的系统，有几万个测试用例。如果每一次修改都引发全面回归，一方面成本高不说，就效果而言，其实也不是很高。通常采用用例收敛的方式，用少量的用例返回变化。”尤其是在企业中，如果要实施DevOps，此时“少做”是最好的策略。凡事不要贪，逐步改进。“用户不知道自己想要什么，而你一旦提供给他们，用户就知道他们不想要什么。”此时，基于最小可行产品，需要迭代改进，才能确保最终的商业目标达成。【本文为专栏作家“王金银”原创稿件，转载请注明出处】点此阅读更多本作者好文
