在复杂业务体系中DevOps理论及方法的实践

《在复杂业务体系中DevOps理论及方法的实践》要点：
本文介绍了在复杂业务体系中DevOps理论及方法的实践，希望对您有用。如果有疑问，可以联系我们。

作者简介

胥峰
《Linux运维最佳实践》作者、《DevOps：软件架构师行动指南》译者
2006年毕业于南京大学,2011年加入盛大游戏,十年运维经验,曾参与盛大游戏多款大型端游和手游的上线运维,主导统一运维平台的产品功能设计和实施,拥有工信部认证高级信息系统项目管理师资格.《Linux运维最佳实践》作者、《DevOps：软件架构师行动指南》译者.

前言

本文来自于 GOPS 2017 深圳站的演讲“在复杂业务体系中 DevOps 理论及方法的实践”.分享分为 4 个方面：

• 初识 DevOps；
• 建构组织文化；
• 架构技术体系；
• 案例研究；

1、初识 DevOps

对 DevOps 有这样一个解释：“ DevOps 是一套实践方法,在保证高质量的前提下,缩短从提交对系统的变更到部署到生产环境的时间”,这是引用了我翻译的这本书里的概念.我们看一下这个概念里有哪些值得注意的关键点：

1. 我们在部署系统的时候,质量是非常重要的.我们部署的系统,你不能因为变更的问题导致业务中断,这是不可接受的问题.
2. 要求交付机制也是高质量的,就是你的交付过程.比如说你交付到测试环境,交付到生产环境里面,也应该是一个高质量的.
3. 在里面规划了两个时间周期：一是开发完成的时间；第二是把代码开发完成到部署到线上的时间.
4. 在这个定义里面强调了 DevOps 是一种以目标作为导向的,它并没有强调我们采取什么样的形式的实践,或者使用什么样的工具.
5. 目标并不限于 DevOps 用于测试和部署的实践,它其实是把整个流程都包含在里面.

我们看到在 DevOps 的定义里面,最主要的一点还是讲到从代码开发完成到上线的过程.这也是行业内对 DevOps 理解比较多的一点.

这个图来自企业 DevOps 白皮书,这是对 DevOps 理解的一个扩展.相对于前面说的那个概念,它讲到从开发到部署的过程,但是在这个图里我们可以看到,它其实是把流程进行了前置和延伸.

比如说计划、需求、设计,以及后面的运维过程,它都把它纳入到 DevOps 流程里面去了.这其实是讲一个什么东西呢?一个产品或者一个业务有了想法之后,它就会进行下面这样的流程,从这个图里面我们看到,它强调的是价值交付的过程.

从产品和业务来讲,它开始有些想法在里面,怎么通过技术手段、流程,快速的把这个想法变成一个产品,变成在实际场景中投放给客户的产品,这是一个价值流的过程.

只有当你的想法真正投入到里面去的时候,它才产生价值,你做的计划也好,你做的开发代码也好,在没有投放到生产之前,其实对用户来讲是没有任何意义的.

上面这部分主要是讲这个流程,在下面我们可以看到,其实它核心的理论支撑是精益和丰田生产系统.我们在整个流程中需要非常关注的一点就是持续改进的过程,不管我们现在的流程是什么样的,或者说你已经做到什么地步了,其实都是有一些可以改进的方向,包括这个精益也是告诉我们要持续不断地做一些改进.

2、建构组织文化

在这里面我想强调一点,不管 DevOps 的定义是什么,它都是一个价值流的交付.从产品或者是业务的想法开始,把它快速地、高质量的交付给用户.但是在实现 DevOps 的过程中,很重要的一点是文化.不管组织的类型是什么,大部分组织都是惧怕变化的,所以采用 DevOps 这个新方法论可能是极具挑战的.

在构建组织文化的过程中,需要关注三个主要的原则：沟通、协作、集成.在这里面要强调一点,我们现在各个部门在协作过程中,可能还存在一些部门利益冲突的问题,这也是一个很现实的问题.

另外一个就是我们要倡导一种免责文化,大家都说运维背黑锅,这个其实是不对的,关键的一点是我们是以价值流交付作为一个整体的目标,倡导一种对事不对人的工作态度.

我们在构建组织文化过程中要注意四个方面：

第一是团队内的协作；

第二是团队之间的亲和性；

第三是要使用一定的工具来加速流程的落地；

第四是伸缩性,随着组织规模的扩大,DevOps 流程也要做相应的变化,

大家想想在我们的组织内部,是不是有这样的一些问题,我们在传统的开发、测试、运维过程中是什么样的情况?开发把代码丢给测试去测,测试测好之后,又把这个包丢给运维部署到现场,中间可能有相关的文档,这本身就是一种筒仓思维的表现.

筒仓思维的英文叫 Silo,它就像是在沙漠里面,或者是大型的场地里面有这样一个个存储物品的仓库,每一个都是独立、封闭的个体,它们之间是没有沟通的,它们的利益也都是有冲突的.

这里讲一个小故事,我们原来有一个同事是来自国企的,他是做财务的.有一天他跟他的领导说,我们现在很多的工作还是手动的,我们是不是可以引入一些自动化的计算机系统来做这些事情?领导就问他,这样做有什么好处呢?他说,我们可以节省很多人力.

领导说,节省人力不行,你节省人力了,我这事就没有人管了.大家有没有理解这个意思?就是说在体制内,领导比较关注他的权力的分配,而不是说从整体角度提高工作效率.

还有一个与之类似的例子,在上海有一家基金公司,我有个同事去那里应聘,当然级别也比较高,他发现他们在部署的时候还是手工去部署的,有几个同事专门做部署的工作.

他就想去推动这些自动化部署的工具,但是他的领导说,我们还是要手工去布,这样的话领导才会重视我这一块,你全自动化了,把我隐藏起来了,我这个经理就没用了,这就是很明显的筒仓思维.

包括我们在运营一些产品或者业务的时候会发现,开发和运维之间互相踢皮球的事情,这也是一种筒仓思维.比如说开发肯定是要求快速上线,而运维要求稳定,大家的利益产生了冲突,这必然会对我们的价值流产生负面的作用.大家可以想想我们生活中或者是在工作里面是否也有这样的筒仓思维的表现.

我们在构建 DevOps 的过程中,必须要打破这种筒仓,形成合力,让大家围绕价值流一致的目的共同努力.

3、架构技术体系

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!