DevOps理念

DevOps理念

12.2  DevOps理念

DevOps（Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

12.2.1  Development和Operations的组合

可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集。

传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。在这种环境下如何采用新的开发方法（如敏捷软件开发）是一个重要的课题。按照从前的工作方式，开发和部署不需要IT支持或者QA深入的、跨部门的支持，却需要极其紧密的多部门协作。然而DevOps考虑的不止是软件部署，它是一套针对这几个部门间沟通与协作问题的流程和方法。

DevOps的引入能对产品交付、测试、功能开发和维护起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”。例如，运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出现问题的地方。

以下几个因素可能促使一个组织引入DevOps：

（1）使用敏捷或其他软件开发过程与方法。

（2）业务负责人要求加快产品交付的速率。

（3）虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍。

（4）数据中心自动化技术和配置管理工具的普及。

有一种观点认为，占主导地位的“传统”美国式管理风格（斯隆模型VS丰田模型）会导致“烟囱式自动化”，从而造成开发与运营之间的鸿沟，因此需要DevOps来克服由此引发的问题。

DevOps经常被描述为“开发团队与运营团队之间更具协作性、更高效的关系”。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低。

12.2.2  对应用程序发布的影响

在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下。

1．减少变更范围

与传统的瀑布式开发模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此，每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。

2．加强发布协调

靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电话会议、即时消息、企业门户（如Wiki、SharePoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。

3．自动化

强大的部署自动化手段可以确保部署任务的可重复性、减少部署出错的可能性。

12.2.3  遇到的问题

很多组织将开发和系统管理划分成不同的部门。开发部门的驱动力通常是“频繁交付新特性”，而运营部门则更关注IT服务的可靠性和IT成本投入的效率。二者目标的不匹配，就在开发与运营部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度。

更小、更频繁的变更意味着更少的风险，让开发人员更多地控制生产环境，更多地以应用程序为中心来理解基础设施，定义简洁明了的流程，尽可能地自动化，促成开发与运营的协作。

一般而言，当企业希望将原本笨重的开发与运营之间的工作移交过程变得流畅无碍时，他们通常会遇到以下三类问题。

（1）发布管理问题：很多企业都有发布管理问题。他们需要更好的发布计划，而不止是一份共享的电子数据表。他们需要清晰了解发布的风险、依赖、各阶段的入口条件，并确保各个角色遵守既定流程行事。

（2）发布/部署协调问题：有发布/部署协调问题的团队需要关注发布/部署过程中的执行。他们需要更好地跟踪发布状态，更快地将问题上升，严格执行流程控制和细粒度的报表。

（3）发布/部署自动化问题：这些企业通常有一些自动化工具，但他们还需要以更灵活的方式来管理和驱动自动化工作，而不必将所有手工操作都在命令行中加以自动化。理想情况下，自动化工具应该能够在非生产环境下由非运营人员使用。

要开始优化发布流程，可以从问题识别开始：看看上面提到的哪种问题在你的团队中具有最高的优先级。

12.2.4  协调人

这是企业级IT组织中一个新出现的角色，其主要任务就是协调安排将企业级软件部署到预生产环境。对发布协调人的需求来自以下几方面的原因。

（1）需要弥合开发与运营之间的鸿沟。

（2）基础设施日益变得复杂：为了运营Web应用，需要多层基础设施和多种平台。

（3）发布频率上升（由于敏捷和迭代式开发的引入）。

（4）分布式团队：位于全球多个地点的、包含外包人员的、混合开发/测试/基础设施的团队。

发布协调人的角色（也被称为部署协调人或集成协调人）源自发布管理或发布工程团队。这个角色与航空交通管制有些类似：实时协调不同团队的行动，有效使用共享的资源（空域、航道、跑道、航站门），达到组织的总体目标（安全起降）。

传统意义上的发布管理往往只关注软件变更的计划与管理，而发布协调则需要控制“将特定软件变更发布至生产环境”的整个过程。这项工作需要系统地管理所有与“将代码构建并部署到生产环境”相关的技术任务，也被称为“发布工程”。

变更管理是跟踪企业IT环境中各种变化（不管是应用程序还是基础设施的变化）的基本原则。变更管理是ITIL V3的核心之一。

12.2.5  成功的关键

1．文化冲击

平稳的文化过渡是让DevOps获得长期成功应用和增强发布软件产品的综合能力的关键。第一步是明确DevOps的定义，调动开发和运营部门之间的协作，鼓励运营人员采纳软件开发方法，并利用云计算基础设施来完成真实的测试和代码部署。

在软件开发、测试、质量保证（QA）、集成、预生产和生产部署等方面的任何旧小团队必须打散，因为每个小团队都可能拖延开发周期，并且带来不可预料的问题。

以上策略能更好地整合开发和运营人员，通过整合团队成员来产生效益。例如，在讨论运营解决方案或扰乱事后评估报告时应该邀请开发人员加入。相反，应该邀请运营人员列席开发人员规划会议。让交叉组合的工作模式成为制度，可以让团队之间合作融洽，消除沟通不畅导致的延误或疏忽，使DevOps的推进更加有效。

这种文化上的改革并不容易，它需要公司提供统一的考核标准，以相同的形式衡量开发人员和运维人员的业绩；培养一种团队精神，让大家一起朝着一个共同的目标努力，而不再只是为了从前各自的狭隘的小团体目标。在这里，有时可以运用岗位轮换或者知识共享的方法。

2．齐全的工具箱

想要超越文化的影响，组织还必须依靠各种DevOps工具。例如，开发人员编写代码需要工具，QA测试人员完成新版软件的部署需要工具，环境准备、将新代码在测试系统和生产系统之间迁移也必须用到云资源调度工具。工具本身都不是问题，重要的是能够让各种工具互相配合，在软件的生命周期内提供支持。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。