1.4 Ansible与DevOps

本节简要介绍下DevOps（Development和Operations的组合）。DevOps是一组过程、方法与系统的统称，用于促进软件开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合，如图1-6所示。

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

需要频繁交付的单位更需要具有DevOps能力，大量互联网在线移动应用随时根据用户的反馈进行迭代开发，持续改进用户体验，这需要能够支撑业务部门每天可能都有几次、几十次部署的需求。这种能力也称为持续部署，并且经常与精益创业方法联系起来。下面几个因素促使引入DevOps：

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

·业务负责人要求加快产品交付的速度。

·虚拟化和云计算基础设施日益普遍。

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

DevOps将使开发团队与运营团队之间更具协作性、更高效的关系。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低。团队之间相互融合，运维从开发流程的计划阶段就参与进来，运维团队就能了解将要开发的产品，同时可以在让产品开发设计初期就考虑后期运维的需求。

DevOps成功的关键有如下因素：

·文化建设。首先要调动开发和运营部门之间的协作，鼓励运营人员采纳软件开发方法，利用云计算基础设施来完成测试和代码部署。其次在软件开发、测试、质量保障、集成、预生产和生产部署等方面必须打散小团队，更好地整合开发和运营人员。例如，在讨论运营解决方案或扰乱事后评估报告时应该邀请开发人员加入。相反地，应该邀请运营人员列席开发人员规划会议。让交叉组合的工作模式成为制度，可以让团队之间合作融洽，消除沟通不畅导致的延误或疏忽，使DevOps的推进更加有效。有时可以运用岗位轮换或者知识共享的方法。

·自动化工具支撑。要超越文化的影响，组织还必须依靠各种DevOps工具。例如，开发人员编写代码需要工具，QA测试人员需要用工具完成新版软件的部署，环境准备、将新代码在测试系统和生产系统之间迁移也必须用到云资源调度工具。

现在已经有了大量的自动化工具，但都是在某些领域或某个领域做得好。运营工具厂商有BMC、CA和ⅩebiaLabs等公司，软件开发工具厂家有IBM、Electric Cloud、Serena Software等公司，工作流程、架构设计和软件发布工具的专业供应商包括Atlassian、CollabNet、Rally Software、ThoughtWorks、OpenMake等公司。评估供应商时，除了对基本功能考察之外，还需要考虑这些公司随时可能会被并购，其产品可用性和未来发展也会因此受影响。

尽管企业IT环境中的应用各种各样，但其操作系统、基础组件还是有很多共性的。手动安装操作系统的过程通常需要小时级才能交付。并且安装系统的可靠性完全依赖于管理人员的工作经验、技术能力、对复杂过程操作的精确程度。然后管理员需要对这些系统一遍又一遍地重复同样的过程，如图1-7所示。

也可能让其他团队一起参与进来搭建系统，在应用交付团队能够工作之前，信息安全团队需要验证是否达到安全基线。需要接触系统的团队越多，实现的时间就越长，也就更加可能延时和增加错误方式。

服务器和系统还比较好理解、容易自动化。尽管你当前OS搭建过程有很多需要与基础环境交互，自动化搭建和配置过程将按照需要能够重复部署OS镜像、合适的工具，管理这些建好的系统将与创建一个新的一样简单，这样这些系统就会总是看起来差不多。

一旦操作系统的搭建和管理自动化之后，把这些自动化推广到其他团队就相对容易了。通常客户搭建一个OS，如研发、测试、QA团队运行他们的应用时，能够确保总是运行在配置合适的OS之上。

但是，仅仅搭建系统，就忽略了更困难部分的问题了：如何保持它们整个生命周期中处于更新状态，如何保证当前的基本需求是正确的？这再一次需要采用自动化工具来管理它们之间的差异。

过去传统虚拟机（ⅤM）生命周期管理方法是一个主要问题，需要独立的流程来维护存在的虚拟机，许多交付工具都对在线运行系统的更新、变更缺乏有效手段。

幸运的是，借助服务器自动化搭建和维护过程，可大大减少或完全消除服务器手工交付的过程，使用Ansible作为自动化工具，使用相同的playbook来搭建系统，就能够保证创建出来的系统是一样的。

甚至在基础架构层应用，也可以自动创建、交付、管理，将节省大量的时间，为单位的扩展团队提供额外的好处。