谈DevOps的前世今生，及企业落实的着力点
程序员文章站
2022-05-14 22:37:36
...
DevOps有多火，当下已不用更多的描述，只看看每天的朋友圈就会有一个所以然。与此同时，根据Gartner最新出炉的2015 I&O Automation报告，DevOps同样正处其技术发展曲线的最高点。
然而不可否认的是，这同样也说明DevOps真正落地企业内部实践仍然有很长的路要走，其中就包括了企业日常IT系统的开发、测试和运维，从而显著地提升企业的IT服务能力。也正是因为如此，现在很多人可能对于DevOps的理念任然充满怀疑，然而不断出现的成功案例还是让大家对其充满期待。
为此，由Puppet Labs领导的年度DevOps发展报告也希望能够对此进行更全面地分析和调研，其2014年DevOps发展报告则再次用具体调查数据揭示了组织绩效、IT服务绩效与DevOps实践之间的关系。其中的核心观点包括如下：
拥有强IT服务绩效的企业通常会双倍超过其市场及盈利目标；
企业的IT服务绩效和DevOps推崇的普遍实践（如持续交付等）有非常明显的正相关。例如，调查发现强IT服务绩效的团队比较差IT服务绩效团队的部署频率要快30倍，变更失败率要低50%。
由上可见，DevOps实践对于提升企业IT服务能力是有明显的正面作用，并且从实践中也得到广泛验证，值得企业关注和学习。
一、DevOps从哪里来？
如果希望了解DevOps，就不可避免需要切分这个词中的两个角色：Dev和Ops（注：这里的Dev包括常说的开发和测试人员，Ops则指服务运维人员，更多时候特指生产环境的服务运维人员）。回顾历史，Dev和Ops这两个角色从计算机诞生之日就已经存在，而且在诞生之初它们本身就是一体的。在最早期，计算机的使用范围非常有限。其硬件生产、软件开发和日常运维很多时候都是来自同样人员或者团队。所以，Dev和Ops这两个角色也就自然融合在一块。
随着计算机使用用途的扩展，越来越多行业开始采购计算机来提升效率，其中个人电脑（PC）的出现则让计算机从传统的计算领域向外延伸到各行各业。于是，PC时代其就诞生了许多独立的计算机软硬件供应商。而步入这个阶段后，计算机软硬件研发就会和最终使用者自然分离。当企业普遍开始使用计算机及相关软件来提升日常运营效率时，通常会需要专职的IT系统运维管理人员来保证其正常运行，于是最早期的专职运维人员（也称系统管理员）应运而生。在这个阶段，系统的研发人员（Dev）和运维人员（Ops）其实是处在不同的机构中，他们之间的沟通和交互主要靠产品说明书、操作文档以及付费的Support完成。为保证企业内IT系统的稳定运行，以Ops为中心的运维管理体系（如ITIL）逐步形成。在这个时间段，企业运维管理体系以服务企业内部运营为主，并不直接面对企业最终用户。实际运维过程则以保证系统稳定为核心目标，对于系统自身的迭代速度要求并不高。一个最明显的例证就是这个时期软件及系统的交付周期一般都是以年为单位（甚至那个时候的Windows版本更新甚至以3年记）。同时，由于这个阶段的Dev和Ops完全分离在不同组织中，基本无法形成持续有效的沟通和交互，从而也无法相互了解。通常Ops团队对于软件的设计及实现思路缺乏最基本的了解，而Dev团队对于Ops在实际运维过程中的挑战和问题也知之甚少。
随着互联网和移动互联网的出现，人们终于找到了一种更好的软件及服务交付方式，即在线服务。在这种模式下，用户无需再承担软件及服务的运维工作，而是直接“开箱即用”。系统的开发和运维工作再次回到一个组织内部，即在线服务提供商。但是，由于遗留系统（很多在线服务提供商在早期并没有自研能力，而是采购外部技术来搭建自身服务系统）及传统运维思路的影响，很多在线服务供应商仍然是按照传统模式组建自身的运维团队。于是，很多组织内部的运维团队和研发团队虽然是在一个公司，也服务于同一个产品，但是他们在组织架构上仍然是独立向上汇报。甚至，这种组织架构在很多公司内部还作为一种均衡各方*的法宝。基于这些原因，那些因Dev和Ops相互分离而造成的问题并未由于他们重新回到一个组织内而得到根本改观。同样存在Dev和Ops相互不了解，互不信任，上线流程异常缓慢等众多老问题。于是，人们就会思考一个问题：既然都在一个组织内，而且是服务于同一个产品，为啥不能让两者走向融合，变成一个以给最终用户交付最大价值为目标的团队呢？于是，DevOps思潮开始涌现，并从理论研究逐步成为目前非常主流的软件生产方式。在这其中也诞生了很多非常优秀的DevOps践行者，如Facebook、Amazon、Netflix等。
回顾整个发展过程，我们可以看到随着系统交付及使用方式不断变化，Dev和Ops两者也经历了由合到分，又重新走向融合的过程。从中可以看出，系统的生产方式其实和系统交付及使用方式息息相关。有什么样的交付及使用方式，就会诞生与之匹配的系统生产方式。而现在，以互联网和SaaS为代表的交付及使用方式已经成为主流趋势，与之相对应的软件生产方式也必然会向全新的DevOps方向发展。
二、DevOps包括什么？
尽管DevOps在现在这个阶段重新走向融合，但是这个阶段的融合已经和最早期Dev和Ops来自同一个团队有着本质的差别。无论从系统的复杂程度，面对的用户规模，还是采用软件工程思路都有天壤之别。具体来说，个人认为现在的DevOps应该包括如下三个层面的内容：
1.从组织文化角度上，DevOps应该成为组织文化上的一个内在要求。首先，企业关注的产出应该转向最终交付价值（即交付给最终用户的产品功能、用户体验）以及响应用户和市场变化的能力。其次，企业需要从组织架构上解决遗留下来的Dev和Ops隔离的状态，为他们走向融合提供组织制度上的保障。最后，DevOps文化强调跨部门协作和直接主动沟通，而不是流程导向的流水线模式。总结来说，需要在组织内部树立“you build it, you run it”的行为准则。
2.从方法论角度上，DevOps包括一系列最大化交付价值的最佳实践。例如，持续交付来提高交付的频率，保证Dev的每一个改进能够尽快交付给最终用户，并能够快速得到真实用户的反馈，以便及时调整产品方向。持续构建和自动化测试保证Dev能够尽快得到反馈，发现代码中潜在的问题并及时修复。自动化一切的原则尽可能避免人为失误并且保证整个流程的高效，可重复。
3.从工具角度上，DevOps指一套适应DevOps组织架构需求，能够帮助团队落实DevOps最佳实践的工具。这其中包括代码管理工具、持续构建工具、代码部署工具、系统监控与运维工具等。在工具选型中，用户即可以基于开源软件自己搭建，也可以考虑购买商业软件（如FIT2CLOUD）来快速落地。
总结而言，DevOps团队需要在组织文化层面能够得到保证和支持，团队成员能够接受并实行DevOps各种最佳实践，并配套相应工具帮助落实。只有这样才能比较完整的落实DevOps实践，并最终让团队和业务都从中收益，最大化交付给最终用户的价值，而不是流于形式和炒作概念。
三、DevOps的抓手在哪里？
如果一个组织希望推进DevOps实践的落地，从哪里入手可能是很多组织内一线经理最为困惑的地方。网络上关于DevOps的分享涉及的内容非常多，而每一点似乎实施起来都不是特别容易。那DevOps的抓手到底在哪里？来自Puppet Labs 2015 DevOps发展报告的结论则能够很好地回答这个问题。其报告结论中包括如下观点：
如果需要了解一个团队的DevOps状况，只需要问一个简单的问题，那就是“团队部署一次服务有多痛苦”。这个问题的答案会告诉你很多细节。
同样，DevOps最好的抓手也在于此。提高团队持续交付和部署的能力在绝大部分情况下都是落实DevOps实践最好突破口。在落实这个突破口时，团队需要关注如下几点：
1. 理清并打通团队从代码到服务的整个通道最为关键，例如，下图就是一个典型的从代码到服务的通道。需要提高团队持续交付和部署的能力就体现在是否能够打通这条通道，并让其尽可能高效地运转。
在打通这个通道过程中，团队遇到的常见问题有以下几点：
a. 团队缺少基本的可落实部署规范（包括Artifact打包规范和部署流程规范）。规范是提高团队协作效率的重要一环。同时，这里的规范是必须要能够落实到部署流程并能够自动化实施。如果团队在此没有历史成功经验，建议直接采用已经广泛使用的现有规范（如AWS的CodeDeploy规范）加快落实。
b. 团队缺少统一的制品库管理。现实环境中，团队构建出来的artifacts经常直接存在FTP、共享目录上，组织不规范而且也未集中管理。因此经常出现选择的版本不对，需要回滚时候没有老版本，不同环境版本选择错误等一系列问题。建议团队建立统一的制品库（例如开源的Nexsus，商业软件Artifactory等）并直接对接构建环境和部署系统。构建时候自动把构建结果打包上传到制品库中，部署时从统一制品库取部署包进行部署。
c. 团队缺少保证不同环境一致性的能力。如图所示，系统交付流程需要涉及到开发、测试、验收和生产环境（简称DTAP），如何保证不同环境上一致性并避免系统因环境不一致而导致事故是一个重要挑战。一般来说，使用统一的基础环境（如镜像）加统一的部署流程及工具是保障环境一致性的关键所在。
2. 关注团队部署效率并持续改进是深入提高团队交付和部署能力的法宝。在打通从代码到服务的通道后，团队整个交付能力会有一个质的提升。但是如果需要深入、持续地提升团队交付能力，还需要持续关注团队部署效率，找出影响团队进一步前行的潜在障碍，并有针对性改进。在这个方面，Puppet Labs 2015 DevOps报告提出了一个定量的分析模型非常有帮助。具体来说，这个定量分析模型由如下几个关键指标组成：
● 产出指标：
○ 部署频率（Deployment frequency）：团队代码部署的频率（包括所有环境的部署次数），一般以每天的部署次数计算。
○ 代码上线延时（Deployment lead time）：代码从提交到代码库到其上线运行的时间间隔。
● 稳定性指标：
○ 服务平均恢复时间（Mean time to recover）：服务平均恢复时间。
○ 变更失败率（Change fail rate）：变更失败率。
通过关注上面这些指标的变化趋势，团队可以定量衡量整个应用交付的效率和质量，并能够始终保证对于应用交付的关注。当然，为了更方便统计如上指标，需要记录团队所有的部署操作及结果，不过这应该是一个好的部署系统需要支持的基本功能之一。
四、写在最后
如本文开篇的Gartner技术发展曲线所示，目前DevOps实践已经进入高度关注期，但离全面铺开还有一定时间距离。不过这也恰恰是愿意革新的团队开始尝试的好时机。现如今，企业的IT服务能力已经成为核心竞争力之一，能够快速适应这个变化并积极提升企业IT服务能力的组织必将在激烈的市场竞争中占有优势。所以，企业需要行动起来，积极拥抱这一新型生产方式，让那些由此实践获得的高效IT研发运维效率的事情不再仅仅是“别人家的故事”。
关于作者：
徐桂林，当前在FIT2CLOUD负责公司的技术布道和生态合作。在此之前先后供职于意法半导体、Autodesk和阿里云。徐桂林热衷于云计算（尤其是公有云IaaS平台），有过多年云计算生产环境工作经历，是较早在国内分享云计算实践经验的作者之一。
然而不可否认的是，这同样也说明DevOps真正落地企业内部实践仍然有很长的路要走，其中就包括了企业日常IT系统的开发、测试和运维，从而显著地提升企业的IT服务能力。也正是因为如此，现在很多人可能对于DevOps的理念任然充满怀疑，然而不断出现的成功案例还是让大家对其充满期待。
为此，由Puppet Labs领导的年度DevOps发展报告也希望能够对此进行更全面地分析和调研，其2014年DevOps发展报告则再次用具体调查数据揭示了组织绩效、IT服务绩效与DevOps实践之间的关系。其中的核心观点包括如下：
拥有强IT服务绩效的企业通常会双倍超过其市场及盈利目标；
企业的IT服务绩效和DevOps推崇的普遍实践（如持续交付等）有非常明显的正相关。例如，调查发现强IT服务绩效的团队比较差IT服务绩效团队的部署频率要快30倍，变更失败率要低50%。
由上可见，DevOps实践对于提升企业IT服务能力是有明显的正面作用，并且从实践中也得到广泛验证，值得企业关注和学习。
一、DevOps从哪里来？
如果希望了解DevOps，就不可避免需要切分这个词中的两个角色：Dev和Ops（注：这里的Dev包括常说的开发和测试人员，Ops则指服务运维人员，更多时候特指生产环境的服务运维人员）。回顾历史，Dev和Ops这两个角色从计算机诞生之日就已经存在，而且在诞生之初它们本身就是一体的。在最早期，计算机的使用范围非常有限。其硬件生产、软件开发和日常运维很多时候都是来自同样人员或者团队。所以，Dev和Ops这两个角色也就自然融合在一块。
随着计算机使用用途的扩展，越来越多行业开始采购计算机来提升效率，其中个人电脑（PC）的出现则让计算机从传统的计算领域向外延伸到各行各业。于是，PC时代其就诞生了许多独立的计算机软硬件供应商。而步入这个阶段后，计算机软硬件研发就会和最终使用者自然分离。当企业普遍开始使用计算机及相关软件来提升日常运营效率时，通常会需要专职的IT系统运维管理人员来保证其正常运行，于是最早期的专职运维人员（也称系统管理员）应运而生。在这个阶段，系统的研发人员（Dev）和运维人员（Ops）其实是处在不同的机构中，他们之间的沟通和交互主要靠产品说明书、操作文档以及付费的Support完成。为保证企业内IT系统的稳定运行，以Ops为中心的运维管理体系（如ITIL）逐步形成。在这个时间段，企业运维管理体系以服务企业内部运营为主，并不直接面对企业最终用户。实际运维过程则以保证系统稳定为核心目标，对于系统自身的迭代速度要求并不高。一个最明显的例证就是这个时期软件及系统的交付周期一般都是以年为单位（甚至那个时候的Windows版本更新甚至以3年记）。同时，由于这个阶段的Dev和Ops完全分离在不同组织中，基本无法形成持续有效的沟通和交互，从而也无法相互了解。通常Ops团队对于软件的设计及实现思路缺乏最基本的了解，而Dev团队对于Ops在实际运维过程中的挑战和问题也知之甚少。
随着互联网和移动互联网的出现，人们终于找到了一种更好的软件及服务交付方式，即在线服务。在这种模式下，用户无需再承担软件及服务的运维工作，而是直接“开箱即用”。系统的开发和运维工作再次回到一个组织内部，即在线服务提供商。但是，由于遗留系统（很多在线服务提供商在早期并没有自研能力，而是采购外部技术来搭建自身服务系统）及传统运维思路的影响，很多在线服务供应商仍然是按照传统模式组建自身的运维团队。于是，很多组织内部的运维团队和研发团队虽然是在一个公司，也服务于同一个产品，但是他们在组织架构上仍然是独立向上汇报。甚至，这种组织架构在很多公司内部还作为一种均衡各方*的法宝。基于这些原因，那些因Dev和Ops相互分离而造成的问题并未由于他们重新回到一个组织内而得到根本改观。同样存在Dev和Ops相互不了解，互不信任，上线流程异常缓慢等众多老问题。于是，人们就会思考一个问题：既然都在一个组织内，而且是服务于同一个产品，为啥不能让两者走向融合，变成一个以给最终用户交付最大价值为目标的团队呢？于是，DevOps思潮开始涌现，并从理论研究逐步成为目前非常主流的软件生产方式。在这其中也诞生了很多非常优秀的DevOps践行者，如Facebook、Amazon、Netflix等。
回顾整个发展过程，我们可以看到随着系统交付及使用方式不断变化，Dev和Ops两者也经历了由合到分，又重新走向融合的过程。从中可以看出，系统的生产方式其实和系统交付及使用方式息息相关。有什么样的交付及使用方式，就会诞生与之匹配的系统生产方式。而现在，以互联网和SaaS为代表的交付及使用方式已经成为主流趋势，与之相对应的软件生产方式也必然会向全新的DevOps方向发展。
二、DevOps包括什么？
尽管DevOps在现在这个阶段重新走向融合，但是这个阶段的融合已经和最早期Dev和Ops来自同一个团队有着本质的差别。无论从系统的复杂程度，面对的用户规模，还是采用软件工程思路都有天壤之别。具体来说，个人认为现在的DevOps应该包括如下三个层面的内容：
1.从组织文化角度上，DevOps应该成为组织文化上的一个内在要求。首先，企业关注的产出应该转向最终交付价值（即交付给最终用户的产品功能、用户体验）以及响应用户和市场变化的能力。其次，企业需要从组织架构上解决遗留下来的Dev和Ops隔离的状态，为他们走向融合提供组织制度上的保障。最后，DevOps文化强调跨部门协作和直接主动沟通，而不是流程导向的流水线模式。总结来说，需要在组织内部树立“you build it, you run it”的行为准则。
2.从方法论角度上，DevOps包括一系列最大化交付价值的最佳实践。例如，持续交付来提高交付的频率，保证Dev的每一个改进能够尽快交付给最终用户，并能够快速得到真实用户的反馈，以便及时调整产品方向。持续构建和自动化测试保证Dev能够尽快得到反馈，发现代码中潜在的问题并及时修复。自动化一切的原则尽可能避免人为失误并且保证整个流程的高效，可重复。
3.从工具角度上，DevOps指一套适应DevOps组织架构需求，能够帮助团队落实DevOps最佳实践的工具。这其中包括代码管理工具、持续构建工具、代码部署工具、系统监控与运维工具等。在工具选型中，用户即可以基于开源软件自己搭建，也可以考虑购买商业软件（如FIT2CLOUD）来快速落地。
总结而言，DevOps团队需要在组织文化层面能够得到保证和支持，团队成员能够接受并实行DevOps各种最佳实践，并配套相应工具帮助落实。只有这样才能比较完整的落实DevOps实践，并最终让团队和业务都从中收益，最大化交付给最终用户的价值，而不是流于形式和炒作概念。
三、DevOps的抓手在哪里？
如果一个组织希望推进DevOps实践的落地，从哪里入手可能是很多组织内一线经理最为困惑的地方。网络上关于DevOps的分享涉及的内容非常多，而每一点似乎实施起来都不是特别容易。那DevOps的抓手到底在哪里？来自Puppet Labs 2015 DevOps发展报告的结论则能够很好地回答这个问题。其报告结论中包括如下观点：
如果需要了解一个团队的DevOps状况，只需要问一个简单的问题，那就是“团队部署一次服务有多痛苦”。这个问题的答案会告诉你很多细节。
同样，DevOps最好的抓手也在于此。提高团队持续交付和部署的能力在绝大部分情况下都是落实DevOps实践最好突破口。在落实这个突破口时，团队需要关注如下几点：
1. 理清并打通团队从代码到服务的整个通道最为关键，例如，下图就是一个典型的从代码到服务的通道。需要提高团队持续交付和部署的能力就体现在是否能够打通这条通道，并让其尽可能高效地运转。
在打通这个通道过程中，团队遇到的常见问题有以下几点：
a. 团队缺少基本的可落实部署规范（包括Artifact打包规范和部署流程规范）。规范是提高团队协作效率的重要一环。同时，这里的规范是必须要能够落实到部署流程并能够自动化实施。如果团队在此没有历史成功经验，建议直接采用已经广泛使用的现有规范（如AWS的CodeDeploy规范）加快落实。
b. 团队缺少统一的制品库管理。现实环境中，团队构建出来的artifacts经常直接存在FTP、共享目录上，组织不规范而且也未集中管理。因此经常出现选择的版本不对，需要回滚时候没有老版本，不同环境版本选择错误等一系列问题。建议团队建立统一的制品库（例如开源的Nexsus，商业软件Artifactory等）并直接对接构建环境和部署系统。构建时候自动把构建结果打包上传到制品库中，部署时从统一制品库取部署包进行部署。
c. 团队缺少保证不同环境一致性的能力。如图所示，系统交付流程需要涉及到开发、测试、验收和生产环境（简称DTAP），如何保证不同环境上一致性并避免系统因环境不一致而导致事故是一个重要挑战。一般来说，使用统一的基础环境（如镜像）加统一的部署流程及工具是保障环境一致性的关键所在。
2. 关注团队部署效率并持续改进是深入提高团队交付和部署能力的法宝。在打通从代码到服务的通道后，团队整个交付能力会有一个质的提升。但是如果需要深入、持续地提升团队交付能力，还需要持续关注团队部署效率，找出影响团队进一步前行的潜在障碍，并有针对性改进。在这个方面，Puppet Labs 2015 DevOps报告提出了一个定量的分析模型非常有帮助。具体来说，这个定量分析模型由如下几个关键指标组成：
● 产出指标：
○ 部署频率（Deployment frequency）：团队代码部署的频率（包括所有环境的部署次数），一般以每天的部署次数计算。
○ 代码上线延时（Deployment lead time）：代码从提交到代码库到其上线运行的时间间隔。
● 稳定性指标：
○ 服务平均恢复时间（Mean time to recover）：服务平均恢复时间。
○ 变更失败率（Change fail rate）：变更失败率。
通过关注上面这些指标的变化趋势，团队可以定量衡量整个应用交付的效率和质量，并能够始终保证对于应用交付的关注。当然，为了更方便统计如上指标，需要记录团队所有的部署操作及结果，不过这应该是一个好的部署系统需要支持的基本功能之一。
四、写在最后
如本文开篇的Gartner技术发展曲线所示，目前DevOps实践已经进入高度关注期，但离全面铺开还有一定时间距离。不过这也恰恰是愿意革新的团队开始尝试的好时机。现如今，企业的IT服务能力已经成为核心竞争力之一，能够快速适应这个变化并积极提升企业IT服务能力的组织必将在激烈的市场竞争中占有优势。所以，企业需要行动起来，积极拥抱这一新型生产方式，让那些由此实践获得的高效IT研发运维效率的事情不再仅仅是“别人家的故事”。
关于作者：
徐桂林，当前在FIT2CLOUD负责公司的技术布道和生态合作。在此之前先后供职于意法半导体、Autodesk和阿里云。徐桂林热衷于云计算（尤其是公有云IaaS平台），有过多年云计算生产环境工作经历，是较早在国内分享云计算实践经验的作者之一。
上一篇： php配置文件php.ini 中文版
下一篇： Eclipse开发ionic应用