DevOps 从这里开始

DevOps

DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运营工作必须紧密合作。[百度百科]
DevOps (a clipped compound of “development” and “operations”) is a software development and delivery process that emphasizes communication and collaboration between product management, software development, and operations professionals.[1][2][3] It supports this by automating and monitoring the process of software integration, testing, deployment, and infrastructure changes by establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.[Wikipedia]

DevOps的由来

在传统的模式中,将开发和运维的分离是为了职能单一,但是开发和运维之间必然会存在着配置、功能、业务等诸多的耦合,所以将开发和运维“抽象”并不是一个很好的选择,过渡的分离就会造成下面这样的情况
开发和运维中间的一堵墙
DevOps概念早先升温于2009年的欧洲,因传统模式的运维之痛而生,是为了填补开发端和运维端之间的信息鸿沟,改善团队之间的协作关系。不过需要澄清的一点是,从开发到运维,中间还有测试环节。DevOps其实包含了三个部分:开发、测试和运维。
这里写图片描述

DevOps引入的几个必要因素

  • 使用敏捷或其他软件开发过程与方法
  • 业务负责人要求加快产品交付的速率
  • 虚拟化和云计算基础设施(可能来自内部或外部供应商)日益普遍
  • 数据中心自动化技术和配置管理工具的普及
  • 有一种观点认为,目前占主导地位的“传统”美国式管理风格(“斯隆模型 vs 丰田模型”)会导致“烟囱式自动化”,从而造成开发与运营之间的鸿沟,因此需要DevOps能力来克服由此引发的问题。

DevOps的好处

说了这么久的DevOps,那么DevOps有什么好处呢?能够现有传统的方式带来哪些改变?
正如上文,传统的方式会出现一堵不透风的墙(鸿沟),最好的方式当然是拆除它,踏平它了,DevOps正式这样的一个目的,让开发、测试、部署“打成一片”,这也和极限编程(XP)的思想有一些相似,减少文档以及不良沟通带来的理解偏差,对目标,每个人都一致,对产品、需求每个人都了解。
DevOps的一个巨大好处就是可以高效交付,这也正好是它的初衷。Puppet和DevOps Research and Assessment (DORA) 主办了2016年DevOps调查报告,根据全球4600位各IT公司的技术工作者的提交数据统计,得出高效公司平均每年可以完成1460次部署。

与低效组织相比,高效组织的部署频繁200倍,产品投入使用速度快2555倍,服务恢复速度快24倍。在工作内容的时间分配上,低效者要多花22%的时间用在为规划好或者重复工作上,而高效者却可以多花29%的时间用在新的工作上。所以这里的高效不仅仅指公司产出的效率提高,还指员工的工作质量得到提升。

DevOps另外一个好处就是会改善公司组织文化、提高员工的参与感。员工们变得更高效,也更有满足和成就感;调查显示高效员工的雇员净推荐值(eNPS:employee Net Promoter Score)更高,即对公司更加认同。

DevOps 小步快跑

DevOps建立快速部署的机制,可以快速发现问题,快速调整,避免偏差过大,这正式TDD中倡导的模块化。采取小环路的快速迭代方式,可以满足敏捷开发的交付周期,也为敏捷开发的交付部署提供了一套有效的交付方法。

DevOps的3D原则

  • 一键式部署(Automatic Deploy):部署过程中,标准化部署过程,实现一键式部署
  • 一次构建打包(Automatic Delivery):在测试环境、UAT环境和生产环境的流转过程中,只打包一次,软件包按顺序自动交付到各个环境,最终发布到生产环境
  • 一次配置分发(Automatic Distribution):在生产环境发布过程,建立统一的配置分发管理,将繁琐的分布式环境配置一次分发到各个数据中心,简化发布过程。

DevOps 工具

  • 监控工具 Zabbix,Nagios
  • 性能分析工具 APM
  • 自动化运维工具 Puppet、Ansible、Chef、Saltstack
  • 自动部署:Capistrano、CodeDeploy
  • 容器:Docker、LXC、第三方厂商如AWS

写在最后

软性需求:文化和人

DevOps成功与否,公司组织是否利于协作是关键。开发人员和运维人员可以良好沟通互相学习,从而拥有高生产力。并且协作也存在于业务人员与开发人员之间。

出席了2016年伦敦企业级DevOps峰会的ITV公司在2012年就开始落地DevOps,其通用平台主管Clark在接受了InfoQ的采访,在谈及成功时表示,业务人员非常清楚他们希望在最小化可行产品中实现什么,工程师们就按需交付,不做多余工作。

这样,工程师们使用通用的平台(即打通的工具链)得到更好的一致性和更高的质量。此外,DevOps对工程师个人的要求也提高了,很多专家也认为招募到优秀的人才也是一个挑战。