DevOps必须了解的九大最佳实践

2015年12月，知名调研机构Gartner预测，“到2017年年底，市场对移动应用程序开发服务的需求会以至少比内部IT部门的交付能力快五倍的速度增长。”

由于需求和能力之间的这种不匹配，企业组织在想方设法加快开发速度。而他们日益采用的其中一种方法就是开发运维。据Gartner声称，2015年，企业组织在开发运维工具上花费23亿美元，预计“到2016年，开发运维会从大型云服务提供商采用的一种小众战略，逐渐变成25%的全球2000强企业采用的一种主流战略。”

对于开发运维市场的规模，厂商的估计显得尤为乐观。2016年RightScale报告声称，80%的大企业和70%的中小企业(SMB)在采用开发运维。

遗憾的是，虽然许多公司在竞相采用开发运维，但它们并非总是确信开发运维需要什么。几家不同的企业提出了彼此竞争的概念，IT行业还没有就一种权威的定义达成共识。Gene Kim是最知名的开发运维支持者之一，与人合著有畅销的财经小说《The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win》。他承认：“开发运维饱受诟病的方面之一是，很难描述开发运维是什么。”

尽管缺乏标准定义，但专家们就开发运维的根本原则达成了共识。通常来说，开发运维旨在打造这样一种文化：IT开发团队和运维团队非常紧密地协同工作。开发运维脱胎于敏捷开发和精益开发原则，它需要尽可能地实现流程自动化，以便加快企业组织部署新应用程序的速度。而最终目标不仅仅是提高IT效率，还在于有助于让企业组织更成功。

那些核心原则大有变化和试验的余地，许多企业组织在想：如果自己想要开始使用开发运维实践，到底应该做些什么。为了解答这个问题，我们请教了几位开发运维专家，听听他们在开发运维的最佳实践方面有什么高招和建议。

专家提醒，就开发运维而言，试图一下子做太多的事情势必会招致失败。任何大型IT部门都会有现有的流程和根深蒂固的文化，它们根本不可能一夜之间变化。

他们建议，应该先搞一个得益于开发运维实践的项目或团队，从小处着手。关键在于选择这样一个项目：开发运维的成功几率很大，它能够为未来的开发运维工作充当基础。

Xebia Labs的产品副总裁Tim Buntel说：“可以根据你在哪里获得最大的好处，进行相应的变化。评估什么给如今你的开发和部署流程带来了最大的麻烦，然后优先处理这一步。”

BMC的云管理和数据中心自动化业务部的产品管理副总裁David Cramer赞同这一观点。他说：“一开始成功很重要，那样团队才能树立信心，并且为其他人树立一个榜样。初始团队的成功直接影响着大规模实施变化的难易程度。项目本身也很重要，所以务必要选择对业务来说有意义的方面。如果初始项目不是战略性项目，人们就会轻视结果。”

最重要的一点是，采用开发运维就是改变变化。致力于自动化或购买新工具不足以带来大多数企业组织希望实现的那种变化。

New Relic战略营销团队的开发运维宣传官Stevan Arychuk说：“一个常见的陷阱是一味关注技术，而不是文化要素。开发运维注重各个技术和运营团队之间的信任和合作；工具和技术其实是为实现这个目标而服务的。”

Buntuel说：“大多数技术团队认为，工具可以解决所有问题。虽然工具对开发运维转型来说绝对很重要，但是除非辅以实际而重大的文化变化，否则它们毫无帮助。认真考虑你的业务目标，考虑信任和沟通，考虑原因。只有搞清楚了如何开始文化转型，你才可以往技术解决方案投入时间和精力。”

虽然光有技术还不够，但是说到如何采用开发运维这个问题，工具绝对是答案的一部分。专家们表示，为了鼓励沟通和合作，拥有让每个人都能实时了解IT项目方面的工作进展如何的工具，至关重要。

此外，企业组织需要确保，它们使用的所有不同的团队工具可以整合起来。企业组织购买多款旨在支持开发运维的工具，这很常见。比如说，它们可能有版本控制管理系统、错误跟踪系统、沟通平台、求助平台、运维监控工具等。Buchanen表示，他“见过交付工具链不是很配套，导致许多团队发生碰撞的情况。”因而，他建议“工具整合是支持开发运维方面最有帮助的技术。”

开发运维技术另一个非常重要的部分是自动化。Buntel说：“可帮助你以一种受控制、可扩展的方式，实现流程自动化的任何技术都大有帮助。”

众多厂商目前提供自动化工具，可以简化配置、监控和维护网络基础设施这个过程。这些工具可以帮助企业组织更迅速地部署应用程序，并有助于提高IT的效率。

同样，Docker之类的容器化技术也大有帮助。容器简化了从开发服务器到生产服务器的转变，消除了部署过程中的许多棘手问题。

据Puppet Lab的《2015年开发运维行情报告》声称，“相比表现较为逊色的IT部门，表现出色的IT部门遇到的故障要少60倍，从故障中恢复的速度却要快168倍。它们部署的频次也要高30倍，筹备时间缩短了200倍。”

同样，弗雷斯特研究公司一份题为《新的软件要务：确保质量的同时快速交付》的报告发现，“一向以最快周期交付的开发团队能够在业务用户当中获得最高的满意度。”重要的是，能够以最快的速度交付新应用程序的新团队也在构建质量最高的软件。

对大多数企业来说，加快部署速度是其开发运维项目的一个关键目标。为了实现这个目标，它们常常部署有望加快开发的技术，它们常常实施敏捷开发方法，比如测试驱动的开发、持续开发、持续集成、结对编程和Scrum方法。专家们表示，企业组织牢记这一点很重要：方法和技术本身并不是目标;相反，它们只是实现诸多目标的一种手段，比如加快部署、改善代码质量以及最终为业务部门提供更好的支持。

虽然开发运维的开发方面常常备受关注，但专家们提醒，不忘记运维很重要。如果改善运营部门内部以及运维部门和IT组织其他部门之间的沟通和合作，企业组织常常能够获得显著的效率。

Atlassian的开发宣传官Ian Buchanan说：“在许多情况下，敏捷开发已经促使开发团队优化其交付管道。如果一开始致力于这个概念：简化来自运维团队的反馈，而不是借助更多的交付自动化实现局部最优化，那些团队就能获得更大的成效。”

为什么你在向开发运维转变?你怎么才能知道转型是否成功?专家们表示，在实施开发运维之前问答这些问题是个好主意。理想情况下，开发运维应该对你为公司跟踪的一些关键绩效指标(KPI)有积极的影响。

New Relic战略营销团队的开发运维宣传官Stevan Arychuk认为：“一定要搞清楚你为什么实施开发运维方法，并制定一套清晰的框架来衡量成效。开发运维的真正价值最终意味着，技术能够更好地利用起来，具有更大的灵活性，从而支持业务，所以行之有效的开发运维战略应该是能够使用KPI量化给业务带来的积极影响。”

你改变IT流程后，它同样会影响业务的其他方面。Cramer建议要有“全局观”。他解释：“改变业务流程以便与来自开发运维的新版本发布节奏相一致，这很重要。比如说，营销团队可能落实了流程，专注于传统的年度或半年度产品发布周期，如果发布的版本规模要小得多、频次高得多，它们不知道如何改变流程。另一个例子就是内部治理流程，需要深入了解12个月的发布计划。”

IT领导人需要确保，除了开发团队和运维团队外，他们还在与另外这些部门沟通和合作。实际上，实施了开发运维的许多企业组织表示，这个理念背后的原则有助于另外许多内部团队，而不是仅仅有助于IT部门。

由于那么多的企业在采用开发运维，企业组织不需要“重新发明轮子。”专家们表示，如果公司参与开发运维会议或在线社区，并且与实施类似项目的其他企业组织积极交流，就会大有收获。

Buchanen特别指出：“确保开发运维切实可行的理念、实践和工具在不断改进。你的人员需要利用社区来验证理念、衡量进度，并且找到进一步改进的灵感来源。别害怕讲述自己的故事，不管你在开发运维这条道路上处于什么阶段。总是会有另一家公司会觉得你的故事对它大有助益。”

随着企业组织积极实施这些开发运维的最佳实践，它们应该牢记：采用开发运维是个长期过程。不像ITIL、敏捷开发或精益制造等其他IT管理实践，开发运维与其说是一种具体的框架或一套具体的实践，更不如说是一股潮流和一种理念。

在大多数情况下，企业不会达到可以说自己“实现了开发运维”的状态。相反，它们在不断尝试新工具和新流程，试图找到帮助自己将开发和运维更紧密地整合起来的工具和流程，最终为业务部门改善成效。