实战：阿里巴巴 DevOps 转型后的运维平台建设

《实战：阿里巴巴 DevOps 转型后的运维平台建设》要点：
本文介绍了实战：阿里巴巴 DevOps 转型后的运维平台建设，希望对您有用。如果有疑问，可以联系我们。

本文转载自公众号「DevOps 时代」,高效运维社区致力于陪伴您的职业生涯,与您一起愉快的成长.

作者简介：

陈喻(亚松)
阿里巴巴 高级技术专家
2014年入职阿里负责 Aone(持续集成,持续交付平台)研发团队,2015年调入运维团队,负责交易运维、无线运维2个团队,带领团队保障日常运维及双11大促运维.2016年负责中间件的 DevOps 平台团队,团队主要业务方包括淘宝、天猫和聚划算等.个人获得2016年双11卓越贡献奖.

前言

本文根据 DevOpsDays 北京站演讲记录整理而成,重点是关于阿里巴巴DevOps 转型之后,运维平台如何建设的.

首先讲一下转型,以前的 PE 人员可以去做运维平台,有一个很大的原因是转型里非常重要的策略—“我是这个应用的 Owner.”

当时,我们 CTO 跟所有研发同学说：

从转型开始的时候,所有的应用要自己去做运维,我是这个应用的 Owner.

运维有这一个策略以后,PE大量的日常工作就可以释放出来,就有更多的时间去做思考,去做沉淀,去做编码,去做我们以前不曾做的事情.

本文主要分为两大块内容：

第一,怎么去思考我们这个运维平台,有一些结合运维自身的理解,结合业务场景的分析,包括业界的方法论的一些思考,结合我们自身的问题,得出来的一些最佳的实践.

第二,介绍一下我们整体运维平台主要的功能.希望大家听我第一块的时候就知道你怎么建设你的运维平台,我后面做的,场景问题你没有必要按照我们这样去设计.

运维的三个阶段

• 第一阶段,黑屏,三角形我的意思是代表整个运维给用户的一些体感或者给研发的体感,人工运维,其实很多企业里面有可能还是这样.
• 第二阶段,白屏,我们自助运维,以前把脚本做成工具去弄,有什么特征,人push机器去干活,自助运维.
• 第三阶段,用户对运维体感很少,但是运维这个领域是不变的.最重要的是人机交互变少了,无屏虽说是不可能的,非常极端,但是是一个趋势,少量的人机交互,它有自决策、自驱动.

自动化运维基础

我们做自动化运维,我认为有四大基础.做这个事情不做,它一直会让你痛.

第一,运维标准与规范

我们的标准有什么好处,让研发 follow 这个标准,标准会在工具里固化.

第二,泛监控,运行时,静态,数据化,可视化

泛监控,不是说传统的监控,是把线上想知道的一切都数据化,最终数据不是给人看的,是给机器去消费的,数据是我们的生产资料,不是可视化,那不是我们的目标.

第三,CMDB

今天说得太多了,非常重要,我想回答两个问题：

第一,CMDB 应该放什么,一般放服务器相关的、网络相关的、应用相关的这三个维度的相关信息.

第二,经常有人会说 CMDB 不准,数据不准是因为你没有把数据生产和数据的消费形成闭环,如果你形成了闭环,数据不准,只是你不敢用,很多人就是这样的,因为你数据不准,所以我不敢用.这不是理由,你用,出了问题,是谁就搞谁,CMDB 就这么搞,其实方法很土,你不用这个数据永远不准.

第四,高效的CI/CD/CD

最后一个,我们一定要具备快速的交付能力,主要体现这两个方面,第一个新开发的能力能不能快速上线,第二是想扩容一台机器能不能快速扩出来.这两个能力我抽象出来是三个东西.

• 持续集成(CI),很多人说持续集成工具不好用,效率低,其实持续集成的本质里面是要自动化测试.如果研发部不具备自动化测试的这个 sense,你持续集成怎么做都是失败的.

  持续集成里最重要的一点就是要推行我们的测试单测、集成测试还有系统测试,单测是保证自己没问题,集成测试是保证跟上游下游没问题,系统测试是保证整个系统没问题.

• 持续交付(CD),现在有很多人说持续交付本质是一个 Pipeline,CI的目标是什么,快速正确去打一个包出来,CD的目标是什么?我能够快速把一个包在不同的环境验证它是ok的可以放到线上去,这就是持续交付要干的事.

  持续交付里面很关键的一点,我们要去解决掉,就是它的环境一致性、配置一致性.环境一致性可以用Docker去解决,Docker 其实本身就是一种标准化的东西.

  所以说第一条用 Docker,肯定是标准化的,另外一个问题,配置是不是一致性,是不是动静分离.

• 持续部署(CD),是一种能力,这种能力非常重要,把一个包快速部署在你想要的地方.

PS：持续部署的几个痛点.

第一个,对你包的文件的分发,大家可以看看我们阿里自己做的,是一个同学做的一个叫蜻蜓的产品,他是做了 SP2P,在 P2P 的基础上加了一个 Super,

第二个,我的应用启动,这个说是挑战,其实是我以前做这个产品对别人的挑战,很多应用启动的时候要两三分钟,这是很有问题的.

第三个,我们部署起来以后这个业务是不是正确的,大家一定要做一个 HealthCheck,不是我们运维来做,是PE来做,一定要把这个要求说出来,执行 HealthCheck 这个脚本.

运维系统的重要特性

我们的中间件研发关注稳定性,其二是效率,其三是易扩展,什么是中间件,大家应该都知道,运维研发里面我说的这六个东西,其实每一个都是非常重要的,如果你没做好,真的可以引起灾难性的问题,但是还是强调几个我感触比较深的.

• 第一,高可用

  我们在做同城容灾演练的时候,我把网一切,结果发现运维系统挂了,救命的东西没有了,怎么搞,当然这种情况我们没有发生过.所以说我们的运维系统一定要是高可用,不一定是高并发.

• 第二,幂等性

  幂等性是分布式系统设计中十分重要的概念,这个也非常重要.

• 第三,可回滚

  这个是我们做运维最基本的一个 sense,你做的任何操作是不是可控的,大家最近知道很多故障,包括亚马逊的,其实都是一个小的误操作.我们如果真正做可回滚,其实事情没有这么复杂.

• 第四,高效率

  如果你的企业发展非常快速,你的规模性效应已经来了,你的运维系统一定要具备很高效率,主要体现在什么地方,其实运维很多地方不一定要求效率非常高,但是有几个地方要求非常高,快速扩容、快速部署这个效率我们要追求极致.

研发定义运维,配置驱动变更

其实我们有时候做决策最困难的是信息不对称,如果我去炒股,旁边坐个专家跟我炒,如果我知道内幕消息,他死活炒不赢我.

因为我知道内幕,就知道明天要收购,这就是信息不对称,我们今天的企业,信息不对称,部门与部门之间,子公司之间,包括系统与系统之间,信息大部分不对称,这么多不对称,你又不知道你的现状,你又不知道你的目标.

这个是2015年11月4号,那个时候双十一刚刚搞完,我去思考,就是我想做一种能力,这个倒下的让它举起来,这个能力把它搞起来,就是不倒翁原理,我想到这样的架构.

从最下面讲,这是我们基础设施,提供三种能力,集散、存储、网络、无论你是怎么样搞,就是提供这三种能力.从右下角的位置上,我先画的是一个泛监控,它会知道系统、应用等等,我把它旁边标了一个字,现状,我要通过这个现状把线上的系统全部数据化,然后我放到决策中心.

左上角有 CMDB,我们现在很多变更系统,很多强调流程,说实在的,其实我本人是做研发出身的,我非常抵触流程,流程不是一个效率工具,它是阻碍效率的.

我指的流程就是说,我们故障搞完以后就是一堆的流程,流程非常阻碍效率,是质量控制的一个工具.流程不是不要,是把流程做到系统里面去,让系统去帮人做决策,而不是人在那里点,天天打个电话让你去点,然后我们还要做到事后审计.

CMDB 定义了我刚才说的目标,我的现状通过监控拿到了,目标也知道了,这个时候你觉得这个事情很复杂吗,我认为这看你怎么去做,如果你想做成人工还是做成自动还是做成智能,都取决于这个地方.

所以我们智能里一定要具有数据的,你知不知道你的目标是什么,所以智能对大家来说就是我说的决策中心里该干的事情,把目标的数据拿到了,就能快速进行决策.

说个最简单的例子,通过智能分析出目标状态是使这个应用有100个VM,但是现在状态只有80个,一看这两个不一样,要扩容20台,如果系统做得更智能一点,通过图上左边的事件中心提示我20台负载较轻的放在哪,就可以调度过去,然后去做执行变更.

我基于这些东西得出来两个结论,“研发定义运维”,“配置驱动变更”.

为什么是研发定义运维?

我在2015年11月时说研发定义运维,我取了个名字,DDO,为什么是研发定义运维,研发最贴近业务,最应该清楚这个业务应该具备什么样的能力,所以说只有研发才能够知道这个业务KPS应该是多少,我后面还会讲去做容量预测等等这些事情,但是一般来说,它的目标状态是研发会去说的,这是我这个服务上来提供多少的服务能力.

为什么是配置驱动变更?

配置就把目标改变一下,你随便跟我说一个运维场景,我可以给你在这个图里面 run 起来,我们配置只需要改你的目标状态,我把你的状态10VM 变成15个VM.这就是我说的研发定义运维,配置驱动变更,前因后果的思考就是这样的.

2.3 运维工具与方法论

精益发现价值

我看到的最大的感触是价值,价值来源于用户的需求,我们价值很多时候是来源于自己的YY,我们的价值来源于用户.

精益对我最大的感触就是我们要发现价值.我发现了价值,我们做的目标,很多人在定 KPI 的时候跟我讲我做了 A、B、C、D 功能,我说三个字,然后呢?

为什么要引入 Docker、kubernetes、Jenkins?你知道现在的痛点是什么吗?如果你不能就不要做这些东西,我们往往看别人是看得最清楚的,看自己看得不清楚.

今天也有人问我,DevOps 团队是该拆还是该合,我说你面对什么样的问题你知不知道,你思考过没有,你的问题优先级是什么,如果只给你解决一个问题是哪个,也许并不是 DevOps 团队拆不拆的问题.

精益思想,什么东西是有价值的,能够对用户带来物质上的或者身体上的愉悦的东西就是有价值的.

敏捷交付价值

敏捷也是对我影响很多的,很多人谈敏捷,我团队里也搞敏捷,敏捷这种运动这种方法是非常靠谱的,它是一系列的方法论.但是在你引入的时候,千万要注意,别人行的东西你不一定行,你需要的东西并不一定是敏捷.

敏捷里面,我们快速去交付价值,在引入敏捷的时候,一定要看,因团队而异,跟团队的成熟度不一样,它的方法也不一样,如果一个非常成熟的团队,任何跟他讲都是影响他效率的.

如果一个不成熟的团队,你就要告诉他,一开始启动会议,然后站会,严格按着这个动作来.武功最高境界有两种,一共是天下武功唯快不破,还有一种是无招胜有招,别人做这个事情蹲马步了几十年,你上来就说无招胜有招.敏捷里我们要形成一个环,持续反馈.

OODA环

OODA 环,一定要形成环.我看了这些东西,我所看到的东西是什么,就是形成闭环,让价值快速流动.

应用运维平台ATOM

这是架构图,因为你的企业可能不一样,我们这个系统每一个小块可能就是一个系统.

我们的基础设施是一层,二层是运维中台,最上面一块是要做的 PaaS 平台,这个平台我分了几步.

• 第一块,预算、容量、资源、弹性
  这些东西加在一起是干什么,其实就是要让资源快速流动起来,流向正确的方向来产   生价值,你的资源如果常年不增不减,这是有问题的.这个在我的 PaaS 平台是非常重要的一块,目的就是让你的资源快速流动起来.
• 第二块,应用管理
  我们要做日常的操作,这个东西全部是让研发去做,就不去做了.这是规模化,阿里的场景很大,要快速对一个单元建站、扩容、缩容.
• 第三块,数据化运营
  一定要讲数据,数据一定不是可视化出来一些报表,一定要给结论,告诉用户你这个数据完了以后应该是什么.规则中心是什么,就是我们所有运维同学日常的运维经验的沉淀,你在线上希望是什么样子的,应该把你的经验全部固化到规则中心去.

批量腾挪工具

这个工具不定所有人都需要,可以解决什么问题,机房的搬迁,凑框迁移.

我们还做了单机闭环,这是腾挪工具的关键,如果企业发生了一定规模,这个东西一定是会需要的.

弹性伸缩工具

然后是弹性伸缩,就是我们的决策中心,解决什么痛点,让你的资源流动起来的决策,它决定你的资源怎么去流,往哪个地方流,这个东西非常关键.

最后它也是说运维领域里面技术含量最深的一个地方,要搞机器学习、深度学习、强化学习等等,算法一堆的东西,我们在这里去弄.

弹性平台主要解决什么问题,这是我们的架构,这个平台不一定很多企业都需要,但是我想讲个应用场景就是在双十一的时候是怎么用的.

我们建一个站点起来只有5000的交易能力,可以通过10分钟时间让它具有30000万的能力,快速决策,快速调动起来.弹性里面就是一个 OODA 环,拿他的数据,跟应用极限做比较,得出来一个策略中心.

弹性一般有水平伸缩、垂直伸缩,对线上去做管理,当然我们有额度,这是比较精细化的管理,今天可能没那么多时间分享.弹性有观察者模式还有自动化执行,每次弹性完以后有一个控制台,因为双十一做全年压测的时候一般情况下不看这个东西.

我刚才讲的很多东西,没有说怎么做成本,怎么做效率,等等这些东西,但是我们做了这些事情,的确是为公司省了钱,带来一些收益.

我们的展望,PE 转型以后,我们是希望让研发来使用我们的运维,降低他运维的复杂度,降低运维的门槛,我们是通过系统化的方式来做,研发只需要把他的目标写出来,让运维这个东西像山一样沉下去,感知不到.

然后是资源的闭环.规模化,现在PE做两大块,第一是规模化运维,然后是单应有运维,很多人理解把线上系统发布到线上去,扩容几台,这就是单应用运维.其实我们应用的蓝海是规模化运维,这会涉及到方方面面的事情.

小结

本文讲的四条,希望大家真的能够理解：

首先：为什么 CMDB 很重要,为什么监控很重要,为什么标准很重要；

第二：研发定义运维,配置驱动变更,这是我们做这个系统的一个最基础的理念；

第三：基于目标管理,你产品有没有理念,如果没有,我认为这只是功能的堆砌；

第四：形成闭环,让资源流动起来,让你的 CMDB 里的数据流动起来,让你的资源流动起来.

转载请注明本页网址：
http://www.vephp.com/jiaocheng/2214.html