大热的DevOps，你知多少？同时，另一个证据是，在刚刚发布的Gartner2015I&OAutomation报告中，DevOps正处于其技术发展曲线的顶峰（如下图）。 当然，上图也说明，在企业内部实施DevOps还有很长的路要走。需要落实到企业日常IT系统的开发、测试和运维中，有效提升企业的IT服务能力。也正是因为如此，可能很多人对DevOps的概念仍然持怀疑态度。不过，不断涌现的成功案例，依然让大家充满期待。为此，由PuppetLabs牵头的年度DevOps发展报告也希望对此进行更全面的分析和研究。其2014年DevOps发展报告再次以具体调查数据揭示了组织绩效、IT服务绩效与DevOps实践之间的关系。关系。核心观点包括： ◆IT服务能力强的企业，其市场目标和利润目标通常会翻倍。 ◆企业的IT服务绩效与DevOps倡导的普遍做法（如持续交付）之间存在非常明显的正相关关系。例如，调查发现，与IT服务绩效较差的团队相比，IT服务绩效高的团队部署速度快30倍，变更失败率低50%。 由上可见，DevOps实践对于提升企业IT服务能力有着明显的积极作用，也得到了实践的广泛验证，值得企业关注和学习。 1。DevOps从何而来？ 想要理解DevOps，就不可避免地需要对这个词中的两个角色进行拓展：Dev和Ops（注：这里的Dev包括我们常说的开发人员和测试人员，Ops是指服务运维人员，以及更多时候是指生产环境中的服务运维人员）。回顾历史，Dev和Ops这两个角色从计算机诞生之初就已经存在，并且在诞生之初就是一体的。在最早的日子里，计算机的用途非常有限。它的硬件生产、软件开发和日常运维往往来自同一个人或团队。因此，Dev和Ops这两个角色自然而然地融合在一起。 随着电脑使用范围的扩大，越来越多的行业开始使用电脑来提高效率。尤其是个人电脑（PC）的出现，大大扩展了传统计算领域的计算机。于是，PC时代出现了很多独立的计算机软硬件供应商。进入这个阶段后，计算机软硬件的研发自然会与最终用户分离。当企业普遍开始使用计算机及相关软件来提高日常运营效率时，就会需要专职的IT系统运维管理人员来保证其正常运行。因此，最早的专职运维人员（也叫系统管理员）也应运而生。 在这个阶段，系统开发人员（Dev）和运维人员（Ops）实际上是在不同的组织中。它们之间的沟通和交互主要通过产品手册、操作文档和付费Support来完成。为保证企业IT系统的稳定运行，逐渐形成以Ops为核心的运维管理体系（如ITIL）。这段时间，企业运维管理系统主要服务于企业内部运行，并不直接面向企业终端用户。实际运维过程以保证系统稳定为核心目标，对系统本身的迭代速度要求不高。一个最明显的例子就是这个时期的软件和系统的交付周期一般都是以年为单位（甚至Windows更新也是以三年为单位）。同时，由于现阶段的Dev和Ops在不同的组织中完全分离，基本无法形成持续有效的沟通和互动，也就是无法相互理解。通常Ops团队对软件设计和实现思路缺乏最基本的了解，Dev团队对Ops在实际运维过程中面临的挑战和问题也知之甚少。 随着互联网和移动互联网的出现，人们找到了一种更好的交付软件和服务的方式，即在线服务。在这种模式下，用户不再需要承担软件和服务的运维，而是直接“开箱即用”。该系统的开发和运营可以追溯到一个组织，即在线服务提供商。但受遗留系统（很多在线服务商早期不具备自研能力，而是购买外部技术构建自己的服务系统）和传统运维思路的影响，很多在线服务商仍然在构建自己按照传统模式运维团队。所以很多组织内部的运维团队和研发团队虽然在一个公司，但是服务的也是同一个产品。但他们在组织结构方面仍然独立报告。甚至，这种组织架构在很多公司也被作为平衡各方力量的法宝。由于这些原因，所有因Dev和Ops相互分离而导致的问题并没有因为重新整合到一个组织而得到根本改善。还有很多内部Dev和Ops之间相互不了解，不信任，上线过程极其缓慢等老问题。因此，人们会思考一个问题：既然都在同一个组织，服务同一个产品，为什么不能将两者整合起来，成为一个以向终端用户传递最大价值为目标的团队呢？?于是，DevOps思潮开始兴起，从理论研究逐渐成为一种非常主流的软件生产方式。也诞生了很多优秀的DevOps实践者，比如Facebook、Netflix。 回顾发展史，我们可以看到，随着系统交付和使用的不断演进，Dev和Ops也经历了从融合到分裂，再到融合的过程。可见，系统的生产方式与系统的交付使用方式密切相关。有什么样的交付和使用方式，就会产生与之相匹配的系统生产方式。现在，以互联网和SaaS为代表的交付和使用方式已经成为主流趋势，相应的软件生产方式也必然朝着新的DevOps方向发展。2.DevOps包括什么？ 虽然现阶段DevOps在重新整合，但现阶段的整合已经与早期Dev和Ops来自同一个团队的同一个团队有着本质的区别。无论系统的复杂程度、它所面临的用户规模，还是软件工程思想的采用，都有天壤之别。具体来说，我个人认为目前的DevOps应该包括以下三个层次： 1。从组织文化的角度来看，DevOps应该成为组织文化的内在要求。首先，企业关注的输出应该转向最终的交付价值（即交付给最终用户的产品功能和用户体验）和响应用户和市场变化的能力。其次，企业需要从组织架构上解决Dev和Ops的遗留隔离问题，为企业走向融合提供组织体系保障。***、DevOps文化强调跨部门协作和直接主动沟通，而不是面向过程的流水线模型。综上所述，有必要在组织内部建立“你建，你运行”的行为准则。 2。从方法论的角度来看，DevOps包括一系列最大化交付价值的最佳实践。例如，通过持续交付来提高交付频率，确保Dev的每一次改进都能第一时间交付给最终用户，并快速得到真实用户的反馈，及时调整产品方向.持续构建和自动化测试，确保Dev能第一时间得到反馈，发现代码中潜在的问题并及时修复。一切自动化的原则，尽可能避免人为错误，确保整个流程高效、可重复。3、从工具的角度，DevOps指的是一套适应DevOps组织架构需求，能够帮助团队实施DevOps最佳实践的工具。这包括代码管理工具、持续构建工具、代码部署工具、系统监控和运维工具等。在工具选择上，用户可以基于开源软件自行构建，也可以考虑购买商业软件（如FIT2CLOUD）来迅速实施。 综上所述，DevOps团队需要在组织文化层面得到保障和支持，团队成员能够接受和实践DevOps的各种最佳实践，并提供相应的工具帮助实施。只有这样，DevOps实践才能得到充分落地，最终团队和业务都能从中受益，最大限度地交付给最终用户的价值。它不是流于形式和炒作的概念，最终无法在实践中取得成果。 3。DevOps的起点在哪里？ 如果一个组织想要推进DevOps实践的落地，从哪里入手可能是组织内很多一线管理者最困惑的地方。网上关于DevOps的分享涉及的内容非常多。那么DevOps的出发点在哪里呢？PuppetLabs2015DevOps发展报告的结论可以很好地回答这个问题。报告的结论包括以下观点： 如果你需要了解一个团队的DevOps状态，你只需要问一个简单的问题，即“团队部署一次服务有多痛苦”.这个问题的答案会告诉你很多细节。 同样，DevOps的起点也在这里。在大多数情况下，提高团队持续交付和部署的能力是实施DevOps实践的第一个突破口。在实施这一突破时，团队需要注意以下几点： 1。关键是要理清和打通从代码到服务的整个通道。例如，下图是一个典型的代码到服务的管道。需要提升团队的持续交付和部署能力，体现在能否打通这条通道，尽可能高效地运行。 在开通该频道的过程中，团队遇到了以下共性问题： ◆团队缺乏基本的可实施部署规范（包括Artifact打包规范和部署流程规范）。规范是提高团队协作效率的重要一环。同时，这里的规范必须能够实现部署过程，并且是自动化的。如果团队在这方面没有历史成功，建议直接采用已有的已经被广泛使用的规范（比如AWS的CodeDeploy规范）来加速实施。 ◆团队缺乏统一的产品库管理。在真实环境中，团队构建的工件往往直接存储在FTP和共享目录中，组织不规范，没有集中管理。因此，经常会出现版本选择错误、需要回滚时没有旧版本、不同环境版本选择错误等一系列问题。建议团队建立统一的产品库（如开源Nexsus、商业软件Artifactory等），直接对接构建环境和部署系统。构建时，构建结果自动打包上传到产品库，部署时，从统一产品库中取出部署包进行部署。 ◆团队缺乏在不同环境下保证一致性的能力。如上图所示，系统交付流程需要涉及开发、测试、验收和生产环境（简称DTAP）。如何保证不同环境的一致性，避免因环境不一致导致的系统事故是一个重要的挑战。一般来说，使用统一的基础环境（如镜像）加上统一的部署流程和工具是保证环境一致性的关键。 2。关注团队部署效率，持续改进是进一步提升团队交付部署能力的法宝。打通从代码到服务的通道后，团队的整体交付能力会有质的提升。但是，如果要深入和持续提升团队的交付能力，还需要持续关注团队的部署效率，找出影响团队进一步前进的潜在障碍，有针对性地进行改进。在这方面，PuppetLabs2015DevOps报告提出了一个非常有帮助的定量分析模型。具体来说，这个量化分析模型由以下几个关键指标组成： 输出指标： ○部署频率：团队代码部署的频率（包括所有环境的部署次数），一般以部署次数计算每天。 ○代码启动延迟（Deploymentleadtime）：代码提??交到代码库到启动的时间间隔。 ◆稳定性指标： ○服务平均恢复时间（Meantimetorecover）：服务平均恢复时间。 ○改变失败率：改变失败率。 通过关注以上指标的变化趋势，团队可以量化衡量整个应用交付的效率和质量，始终保证对应用交付的专注。当然，为了更方便统计以上指标，需要记录团队所有的部署操作和结果，但这应该是一个好的部署系统需要支持的基本功能之一。 4。写于*** 如本文开头Gartner技术发展曲线所示，DevOps实践进入高度关注期，但距离全面铺开还有一定的时间距离。但这也是愿意创新的团队开始试验的好时机。如今，企业的IT服务能力已经成为企业的核心竞争力之一。能够迅速适应这种变化，积极提升IT服务能力的组织，必将在激烈的市场竞争中占据优势。 讲师简介：许桂林，目前在FIT2CLOUD负责公司技术布道和生态合作。在此之前，他曾就职于意法半导体、欧特克和阿里云。许桂林热衷于云计算（尤其是公有云IaaS平台），拥有多年云计算生产环境经验，是国内较早分享云计算实践经验的作者之一。
