什么是DevOps

DevOps(Development 和 Operations 组合)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。一些国际组织对其定义如下:

DevOps 强调对应用进行快速、小规模、可迭代的开发和部署,以更好地应对和满足客户的需求。它要求进行文化的转变,即将开发和运维只能作为一个合作的整体来看待,注重提高业务价值,旨在精简整个 IT 价值链。

从定义来看,其实 devops 就是为了让开发、运维和 QA 可以高效协作的流程。(可以把 DevOps 看作开发、技术运营和质量保障(QA)三者的交集)。

36_devops.png

DevOps 是一套实践框架,包含了精益、敏捷的理念,各种持续集成和持续交付的职能,以及构建流水线的工具。它着眼于项目的实践,在实践中强调以业务价值来统一所有工作目标,这个目标是不同的团队打破原有的组织考核壁垒,进行合作和沟通的基础。

它的核心思想是把所有的 IT 交付和运维服务团队统一起来,围绕一个统一的业务价值目标及业务交付范围加强沟通,通过频繁、快速地迭代交付和反馈,达到加快交付速度和提高交付质量的目的。

如果将 IT 系统提供的业务服务作为一个交付的产品来看,就存在一条在 IT 软件开发和交付领域等形成的流水线。为了建设这样一条流水线,需要弄清楚以下问题:

  • 流水线的内容是什么?它的起点在哪?终点在哪?
  • 如何搭建这条流水线?
  • 如何管理这条流水线?

DevOps核心理念

DevOps 的生命周期如下图所示:

37_devops.png

在其生命周期中,包含以下几个核心理念:

38_devops.png

实现组织目标

技术人员所做的软件系统是为业务部门的业务发展服务的,此是将所有 IT 交付团队统一起来的共同目标和原始驱动力。只要对比一下自己团队的 KPI 和业务目标的关系,就能发现传统的分隔式项目交付管理是多么官僚和浪费。所以,DevOps 流水线包含开发、测试、部署和运维等整个项目过程,这些直接关系到最终的业务价值的实现,因此必须作为一个整体进行管理。

流程标准化

俗话说,无规矩不成方圆。在践行 DevOps 的时候也需要标准化的交付流程,且这个流程不是简单的管理规范,而是要用持续交付的流水线来取代冗长的开发运维流程,实现高效,高质。

除了开发测试交付部分,从运维的角度来看,在 DevOps 里强调的是轻量化的 ITSM 流程和架构,即根据保证业务运行连续性的需要来裁减流程,并形成标准化的流程。所谓标准化指的是在需求、开发、测试、维护的过程中将流程最小化。流程过于复杂是造成 IT 资源浪费的最重要原因,所以应该将流程最小化,同时将更多的精力、劳动、资源投入真正创造业务价值的生产中。

工作自动化

开发运维流程标准化是自动化的前提,如果流程不是标准化,那么自动化也是没有根基的。只有将流程标准化,自动化才能有定义的标准。

自动化能提升效率,还能使效率和质量透明化,让整个交付过程更加可控。

DevOps文化

DevOps 是一种文化,它提倡团队成员围绕共同的业务目标,进行互相理解、信任、沟通和协作,在交付过程出现问题后,从中分析原因和吸取教训,而不是互相指责和推卸责任。

总的来说,DevOps 涵盖 CALMS(自动化、精益、可衡量和分享)文化,如下图:

39_devops.png

从项目实践来看,DevOps 是指导软件系统交付的一系列实践方法,贯穿于项目的计划、需求、设计、开发、部署、运维及终止的整套过程中。

40_devops.png

从传统的IT项目交付的角度来看,DevOps实践框架包括:敏捷管理、持续集成、持续交付和自动化测试。

敏捷管理

指将需求以用户故事的方式进行拆解,然后以最小化、快速迭代的方式进行开发管理。

持续集成

指针对开发人员的代码提交过程,以单件流的方式进行流水线式的自动化管理。

持续交付

预先定义、规划从代码生成到产品产出的流水线,并以自动化、模板化方式进行交付。

自动化测试

根据测试流程,以模板化、自动化的方式实现测试的手段。

DevOps相关工具

41_devops.png

监控工具

比较老牌的就是 Zabbix,Nagios,用 Zabbix 的感觉是最多的。国内的有小米开源的 OpenFalcon。这类监控工具一般是对服务器、服务(中间件,数据库)做一些常用指标的监控。

性能分析/APM工具

APM 很多时候被认为是监控的一个细分领域。但在现代复杂分布式系统架构下,APM 工具往往更能准确、直接的帮助用户定位到性能瓶颈,比如哪一个 URL 访问慢、哪一个方法执行慢、哪一个 SQL 执行慢。在以往要想拿到这些数据,往往得需要比较资深的架构师、DBA 一起合作才能拿到这些数据,而定位瓶颈的效率往往还不太高。

现在通过 APM 工具能让普通技能的运维人员,也很高效的定位到这些深层的问题。现在商用的 APM 工具不少,国外的有 Newrelic,国内知名的就有听云、Oneapm、透视宝这些。开源的也有 Pinpoint(naver 开源)、Zipkin(twitter 开源)、CAT(大众点评开源)。

批量+自动化运维工具

这里就比较多了,知名的有 Puppet、Ansible、Chef、Saltstack 这些。这些在网上的资料也比较多,找比较新版本的官方文档看就行了。Puppet 和 chef 是比较早期的工具,受众面也很大,不过这两个工具基于 ruby 实现,现在要找到熟悉 ruby 的人来做这块的二次开发可不容易。而 ansible 和 saltstack 则相对新生代一些,目前用户基数增长很快,基于 python 实现,要找做二次开发的人也相对容易的多。

集中日志分析工具

在一个服务器比较多的环境下,如何集中的管理和分析、查询日志,已经变成一个比较强的需求了。想象一下,如果发生了某个错误,你还得一台台机器去翻日志文件,是不是很蛋疼。在这个需求驱动下,就诞生了一些集中日志分析工具。在开源领域,比较知名的就是 ELK 这一套工具了,涵盖了日志采集、上报、搜索、展现这一类基本需求,现在比较多的上规模的企业都用这个,网上资料也大把。

核心实现机制都是通过一些日志采集代理(类似 Filebeat)去爬日志文件,将最新的部分提交到采集服务端,后端再对接搜索引擎,能支持很快速、准确的搜索即可。有一个国内不怎么知名的 Sentry 日志收集服务,比较轻量级,本身是 Python 做的,与各种语言的日志框架做了非常好的集成,可以很方便的集中收集异常日志,并分配给对应的开发人员。它在 github 上有 10000 多个 star 了,这在 DevOps 相关的软件里,都是排名非常靠前的了。

持续集成/发布工具

我接触的人都是用 Jenkins 的,没有用其他的,可能跟我所在的技术圈子有关。集成打包的过程其实一般都比较简单,配好版本库和打包脚本就行。但发布的过程就比较复杂,有些是全量发布,但也有非常多的IT团队采用增量发布。这个方面如果想用工具,还是得先分析清楚现有的发布流程,手工情况下怎么做,哪些能通过自动化工具来完成。

IaaS集成

最近两年的公有云推广比较迅速,很多新的服务器采购都被导入到云上去了。现在主流的公有云都提供了比较完备的 API,基于这些 API 也可以做一些针对基础资源的自动化操作,比如游戏行业的快速开服。