完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
摘要:阿里巴巴DevOps转型之后,运维平台是如何建设的?阿里巴巴高级技术专家陈喻结合运维自身的理解,业务场景的分析和业界方法论的一些思考,得出来一些最佳实践分享给大家。
前言 “我是这个应用的 Owner”是阿里巴巴DevOps转型的重要策略,运维有了这个策略以后,PE大量的日常工作就可以释放出来,会有更多的时间去思考沉淀,去做编码,去做以前不曾做的事情。 运维的三个阶段 第一阶段:黑屏,三角形是代表整个运维给用户的一些体感或者给研发的体感,人工运维,目前很多企业可能还是这样。 第二阶段:白屏,自动化运维,以前把脚本做成工具去弄,有什么特征,人push机器去干活,自助运维。 第三阶段:用户对运维体感很少,但是运维这个领域是不变的。最重要的是人机交互变少了,无屏虽说是不可能的,非常极端,但是个趋势,少量的人机交互,它有自决策、自驱动。 自动化运维基础 做自动化运维,我认为有四大基础。 第一:运维标准与规范 我们的标准有什么好处,让研发 follow 这个标准,标准会在工具里固化。 第二:泛监控,运行时,静态,数据化,可视化 泛监控,不是说传统的监控,是把线上想知道的一切都数据化,最终数据不是给人看的,是给机器去消费的,数据是我们的生产资料,不是可视化,那不是我们的目标。 第三:CMDB 1.CMDB 应该放什么,一般放服务器相关的、网络相关的、应用相关的这三个维度的相关信息。 2.经常有人会说 CMDB 不准,数据不准是因为没有把数据生产和数据消费形成闭环,如果形成了闭环数据不准,那是因为你不用这个数据,所以不准。 第四:高效的CI/CD/CD 我们一定要具备快速的交付能力,主要体现这两个方面:第一,新开发的能力能不能快速上线,第二,想扩容一台机器能不能快速扩出来。这两个能力抽象出来是三块。
1.对包的文件的分发,阿里有一个叫蜻蜓的产品,是做了 SP2P,在 P2P 的基础上加了一个 Super。 2.应用启动,很多应用启动的时候要两三分钟,这是很有问题的。 3.部署起来以后这个业务是不是正确的,大家一定要做一个 HealthCheck,不是运维做,是PE做,一定要把这个要求说出来,执行 HealthCheck 这个脚本。 运维系统的重要特性 中间件研发首先关注稳定性,其次是效率,然后是易扩展。运维研发里面的六个重要特征,每一个都非常重要,以下是我感触比较深的几个。 1.高可用 在做同城容灾演练的时候,我把关一切,结果发现运维系统挂了,救命的东西没有了怎么办?所以说运维系统一定要是高可用,不一定是高并发。 2.幂等性 幂等性是分布式系统设计中十分重要的概念,这个也非常重要。 3.可回滚 这个是做运维最基本的一个 sense,你做的任何操作是不是可控的。如果真正做可回滚,其实事情没有这么复杂。 4.高效率 如果你的企业发展非常快速,你的规模性效应已经来了,你的运维系统一定要具备很高效率,快速扩容、快速部署这个效率我们要追求极致。 研发定义运维,配置驱动变更 2015年11月4日设想的架构图 从最下面看,是我们的基础设施,提供三种能力,包括集散、存储、网络。从右下角的位置看,画的是一个泛监控,它会知道系统、应用等,在旁边标了一个字,现状,我要通过这个现状把线上的系统全部数据化,然后放到决策中心。 左上角有 CMDB,现在很多变更系统,很多强调流程。我本人是做研发出身,非常抵触流程,流程不是一个效率工具,它是阻碍效率的。 比如故障搞完以后就是一堆的流程,非常阻碍效率,是质量控制的一个工具。流程不是不要,是把流程做到系统里面去,让系统帮人做决策,而不是人在那里点。 CMDB 定义了我刚才说的目标,现状通过监控拿到了,目标也知道了,这个时候还觉得这个事情很复杂吗?我认为这看你怎么去做。想做成人工还是做成自动或者做成智能,都取决于这个地方。所以智能里一定要有数据。 举个例子,通过智能分析出目标状态是使这个应用有100个VM,但是现在状态只有80个,一看这两个不一样,要扩容20台,如果系统做得更智能一点,通过图上左边的事件中心提示我20台负载较轻的放在哪,可以调度过去,然后去做执行变更。 基于这些东西得出来两个结论,“研发定义运维”,“配置驱动变更”。 为什么是研发定义运维? 研发定义运维(DDO),研发最贴近业务,最应该清楚这个业务应该具备什么样的能力,只有研发才知道这个业务KPS是多少。 为什么是配置驱动变更? 配置就是把目标改变一下,你跟我说一个运维场景,我可以在这个图里面 run 起来,配置只需要改你的目标状态,比如把你的状态10VM 变成15个VM。 这就是“研发定义运维,配置驱动变更”前因后果的思考。 运维工具与方法论 精益发现价值 价值来源于用户的需求,而不是自己的YY,我们的价值来源于用户。 精益对我最大的感触就是要发现价值。精益思想,什么东西是有价值的,能够对用户带来物质上的或者身体上的愉悦的东西就是有价值的。 今天也有人问,DevOps 团队是该拆还是该合,我想他应该首先弄清楚面对的是什么样的问题,问题的优先级是什么?如果只解决一个问题,也许并不是DevOps 团队拆不拆的问题。 敏捷交付价值 敏捷也是对我影响很多的。很多人谈敏捷,我们团队里也搞敏捷,敏捷是要快速交付价值,它是一系列的方法论。但是在引入的时候千万注意,别人行的东西你不一定行,你需要的东西并不一定是敏捷,要因团队而异,形成一个环,持续反馈。 OODA环 OODA 环,就是形成闭环,让价值快速流动。 应用运维平台ATOM 应用运维平台的基础设施是一层,二层是运维中台,最上面一块是要做的 PaaS 平台,这个平台分几步。 第一块,预算、容量、资源、弹性 这个是PaaS 平台上非常重要的一块,目的就是让资源快速流动起来,流向正确的方向来产生价值。资源如果常年不增不减,是有问题的。 第二块,应用管理 这是日常要做的操作,规模化,要快速对一个单元建站、扩容、缩容。 第三块,数据化运营 一定要讲数据,数据不是可视化出来一些报表,是要给结论,告诉用户这个数据完了以后应该是什么,规则中心是什么,是所有运维同学日常的运维经验沉淀。 批量腾挪工具 这个工具不是所有人都需要,可以解决机房的搬迁,凑框迁移。 单机闭环,这是腾挪工具的关键,如果企业有一定规模,这个是需要的。 弹性伸缩工具 弹性伸缩是我们的决策中心。它决定你的资源往哪个地方流,非常关键。 最后,这里是运维领域技术含量最深的一个地方,要搞机器学习、深度学习、强化学习、算法等。 弹性伸缩架构,这个平台不一定很多企业都需要,这里主要介绍在双11的时候是怎么用的。 建一个站点起来只有5000的交易能力,可以通过10分钟时间让它具有30000万的能力,快速决策,快速调动起来。弹性里面是一个 OODA 环,拿它的数据和应用极限做比较,得出来一个策略中心。 弹性一般有水平伸缩、垂直伸缩,对线上做管理,当然我们有额度,这是比较精细化的管理。弹性有观察者模式还有自动化执行,每次弹性完以后有一个控制台,双11做全年压测的时候一般情况下不看这个。 实施效果 原文链接 阅读更多干货好文,请关注扫描以下二维码: |
|
相关推荐 |
|
只有小组成员才能发言,加入小组>>
39个成员聚集在这个小组
加入小组3368 浏览 0 评论
5978 浏览 0 评论
2293 浏览 0 评论
5292 浏览 0 评论
1933 浏览 0 评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-11-5 16:20 , Processed in 0.645733 second(s), Total 65, Slave 47 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号