专栏首页DevOps时代的专栏相爱相杀的运维之殤:苏宁消费金融超大规模 IT 系统 DevOps 实践

相爱相杀的运维之殤:苏宁消费金融超大规模 IT 系统 DevOps 实践

作者简介:顾黄亮,十年研发运维经验,涵盖基础架构、应用架构、数据库、DevOps,有互联网,电商,金融从业经历。 专注于 DevOps 在企业中的应用和落地,致力于企业智慧运维体系的打造。参加多个行业、国家标准的编写,《开源许可证使用指南(2018)》作者之一,国标《研发运营一体化(DEVOPS)能力成熟度模型》作者之一,《企业IT运维发展白皮书》作者之一,曾供职于航天晨光、上汽集团云计算中心,现任苏宁消费金融安全运维部负责人。

今天跟大家分享的一个主题,就是苏宁消费金融超大规模IT系统DevOps的落地实践。下面分四个部分:

1、DevOps的年轮记 2、相爱相杀的运维之殇

3、运维生态之旅

4、我们在落地建成中的一些痛点

一、DevOps的年轮记-我眼中的DevOps

其实DevOps这个概念到现在已经有十多年的历史了,这个概念一开始起源于传统行业,后来是被IT行业采纳,把它的先进理念和方法论引用过来。

伴随着DevOps理念在中国多年的推进,我从一开始接触DevOps,到目前DevOps在落地的过程中,我为它总结了一句话,总结叫“倍道而进”。这句话是三国演义里的,它体现出来一个核心的思想,那就是不断的加快,从DevOps的官方的含义当中,它的核心思想就是提高组织级的效率和质量。

经过十年的发展,到了相对而言比较成熟的阶段,准确的说是从三年前到现在,这一个阶段,它整个的发展速度是很快的。很多人都在讲”云计算”引爆了这一切,如果没有云计算技术的加持和助推,其实DevOps的落地推进并不像现在这两年到三年内我们所感觉到的这么快速。

我对它的总结,或者更贴近于这两三年中对DevOps的发展效率来看,那就是非常快。这两年无论是企业的对于DevOps的理解和DevOps在企业当中的落地,其实跟前面七年八年来比,它其实是增加了很多倍的。

我眼中的 DevOps 目前有三个。

第一个是 DevOps 是什么?

“回归 DevOps 的本源,跳出三界外”,这一句话的意思是什么?我们看 DevOps,并不是说我们通过一篇文章,或者说通过 DevOps 在企业当中的落地某一种方式来形成一种理解。从 DevOps 的本质上来说,无非就是达成研发、运维、测试,更往外延伸一点那就是产品、项目各组织之间的协同合作的目标。

从推进到落地的过程中来看,真正能帮你助推,帮你把 DevOps 项目来落地,除了 DevOps 涉及的各个组织体系的配合、受众人群的拥护以外,我们要考虑真正最终效益的人是谁?那就是各个组织体系的上司:老板!

所以,我对第一句回归 DevOps 的本源,跳出三界外,其实最根本的一个表达的方式是什么?你要跳出 DevOps 来看 DevOps,你就会看出你原来对 DevOps 的理解,你会上升到一个新的高度,你就知道在整个的 DevOps 落地的过程中,你需要哪些资源的一种加持。

第二个就是千人千面的 DevOps,本质是人与信息的联姻。千人千面,其实这四个字也是从电商行业出来的,它所表达的是你跟人家谈需求,尤其你跟 DevOps 涉及的各个组织体系部门(简称业务侧部门)谈需求的时候,业务部门跟你说我需要这一个东西,通过交流或者基本的沟通给你进行一个简单的需求画像,你会根据这个需求去简单的理解,画像出来后,你跟业务方进行简单的需求交付,他跟你说你要的这东西根本不是我想要的东西,哪怕你的功能是满足他的需要,但是他总会跟你挑出各种各样的瑕疵或者其他使用体验的问题。

第三个是 DevOps 的投资回报:格局决定了结局。如果我们正在进行 DevOps 项目推进,或者说已经具备组织级 DevOps 项目落地经验的人来看,你做 DevOps 的核心初衷是什么?你肯定会有一个出发点,或者说以这个点作为横向和纵向的一个延伸方式,要看承担 DevOps 项目的这个人的角色是什么?是不是运维、研发或者说测试,也可以是管理项目的项目经理、承担需求设计的产品经理,他是否有清晰的思路,其实我觉得谁做都不要紧,谁做都可以,只要你对 DevOps 方法论有足够清晰的思路。

以运维为例,你肯定是从CI/CD开始,也可能从CI/CD结束。从我的经验来看,如果你的思维仅仅从运维出发,而不从运维延伸,三个月你就做完了,你做完了以后这个项目就结束了,它能代表你的DevOps真正的就结束了吗?错,其实它仅仅是一个开始。

第一个我们继续往下走,回归 DevOps 的本源。

其实根本上来说 DevOps 它是究竟是什么,我相信在运维这个行业里,对 DevOps 的理解有一种理解上的偏差,很多人对组织级的 DevOps 理解都是我开发一个系统,它具备一个 DevOps 的功能,那我把它命名叫 DevOps 系统,或者 DevOps 平台,可以吗?其实也不是不可以,但是根据 DevOps 的精神,我觉得并不是很合适。

因为从 DevOps 方法论来说,它其实是一种方法,它是一种理念,它是一种实现,它并不是一个系统,并不是一个平台,它不是一类的技术,也没有相应的一个产品。但是你可以根据 DevOps 的方法论,开发出具备 DevOps 方法实现的工具,这样是可以的。

第二个 DevOps 最直接的价值,在于它可度量的价值、可延伸的价值、可迭代的价值,是基于流水线驱动的交付输出、基于数据驱动的价值输出。

我昨天跟牛晓玲老师聊,DevOps 在企业中的落地,它最后体现出来什么?流程驱动,其实这一个过程是很好做的,尤其对于传统企业来说,是一种天然的优势,因为对于传统企业来说,它更讲究是整个流程在企业当中的贯穿。所以说你通过流程来驱动的 DevOps 是流水线,最终也是为了达到一种交付,它是我们狭义上理解的流水线的概念,整个的流程到最后,必须要有相应的技术的加持,所以很多人正在讲我目前基于DevOps 的流水线实现,我的落地过程是不是已经快结束了?我下一步是不是到了AIOps?可以这么说,还早呢。

其实 AIOps 是什么?我个人对它的理解,AIOps,当你的组织级 DevOps 已经完成落地,发现 DevOps 并不能完全覆盖我的需求,或者说运营、研发、测试一体化的需求,我需要对 DevOps 做一些延伸,那做的这些延伸,就是我们现在所讲的 AIOps,它是需要有 DevOps 作为基础,从流程驱动的基础上实现数据驱动的价值,通过对海量数据的分析、汇聚、处理、统计、计算来覆盖 DevOps 的短板。

想要达到这一个阶段,需要什么?数据!我需要的是海量的数据,所以又回到上面所说的,我们在整个的流程驱动的过程中,必然需要数据中台的支撑,在业务的框架下,让所有的运维数据流动起来。

通过数据的采集,我的每一个节点,每个环节,都保留很多的数据,这些数据也会反推我在 DevOps 整个的落地过程的核心效益产生,基于一些数据的加工、聚合、统计、计算,乃至后面的数据的预测,DevOps 就有了延伸,会很直接的、很自然的演变为最后的 AIOps。所以说没有数据的加持,DevOps和AIOps它中间始终是一个鸿沟,你是完全是跨不过去的。

我们继续再回到前面价值这一块,终究这个价值是什么?这个价值是交付,是数据的交付,是过程的交付,是服务的交付。

下一个是千人千面的 DevOps,左边是西游记里面的,师傅跟大师兄、二师兄眼中白骨精其实完全是不一样的。

我想表达的千人千面 DevOps,在领导眼中,他需要提高组织级的效能和质量,其实他不关心这里的细节,我只要有一个工具,有一种方法,能帮我把整个组织级的效能和质量提升,这是领导所需要的。

运维眼中是什么?你不要再跟我对接底层的服务,我将我的能力通过服务输出,提供平台来给你使用,我将一部分可控的权限下发,由你研发和测试来管理。所以对于我运维来说,通过相关的能力域的输出,不再是工程师即服务,我的平台出了问题你过来再找我,我的服务出了问题你也可以过来找我。

其实这一个阶段我感触很深,我也是从研发过来的,在我做研发工程师的时候,我对运维的理解什么?这一块出了问题,我本身环境是好的,我设置的环境是好的,你生产环境出了问题你自己过去查,不关我的事儿,是你运维的事儿,本质上还是价值输出还不够完美,人与人对接,总归是有很多的问题。

通过上面的一些案例,你看到运维那种很茫然的眼神,你是不是产生了一种快感?但是对运维来说,确是很苦恼的。我从研发转到运维以后遇到一件事,研发跟我讲,昨天我有某一个系统 CPU 飙升100%,你赶紧给我查,这是你这边的问题,然后我把整个堆栈杀出来,定位到包、定位到方法,研发傻眼了。

对于互联网行业来说,运维和测试具备代码编写和走读的技能已经比较常见了,在传统行业来说这种案例还是比较少的,其实这种时候运维是扬眉吐气的。

其实咱们刚才只不过讲了一个关于研发和运维的小故事,在研发眼中,他真正想做什么呢?他说我只想做研发,我只想写代码,其它乱七八糟的事儿我没有也没有精力,其实这个是真正的研发的写照,尤其是初中级的研发工程师,从一开始研发所覆盖的职责一直到现在,基于权责和组织架构的关系,一直是有这样的一个问题的,这也是狭义上研发和运维的一些恩怨情仇。

从测试的眼中,那我终于拿质量作为抓手,其实准确来说,现在很多的企业现在都没有把质量安全以数据作为可度量的方式,大家注意,还是以那种比较偏原始的或者说半自动化的。从一开始功能性的测试,再到安全测试再到各个环节的测试覆盖率、成功率,跟现在自动化测试来说,它仅仅是达到了半自动化,只是覆盖到案例的部分,它并没有相对全面的数据来落地,以整个度量的方式作为一种抓手,来提升整个的项目或者说版本的质量。

在项目眼里,其实项目经理最关心的是这个项目全生命周期的管理,只要我把这个环节控好,映射到整个研发的环节、运维的环节、需求的环节和测试的环节,只要大的问题没有,小问题无伤大雅,基于项目的管理来说相对而言还是比较简单的。

所以,在整个 DevOps 的加持下,把整个全生命周期,各个环节的数据来落地下来,这是项目经理最喜欢看到的。

产品眼中,产品更关心的是什么?其实产品经理只想把这些需求梳理好、设计好,那下面就是编码阶段。但是你发现在这个过程当中,我的需求有多少个?我涉及到提需求的一些干系部门,哪些需求是正常的,哪些是属于加塞的,哪些是需要调整的,哪些是还是不确定的,方便后面考量,针对项目后评价阶段针对需求的一些度量。

这些需求跟我的组织,跟我现有研发组织、团队,研发的人员,更涉及到研发团队工程师所分配的任务,我的需求所拆分的关联系统,通过数据上关联来串联数据链,其实在很多的组织或者在很多企业是不具备这样的情况,所以这种情况下就需要靠人治,而不是靠系统来治理。

在 DevOps 的负责人眼中,他的感觉是什么?其实领导、测试、运维、研发或者说项目经理、产品经理,都是需求方,我是整个需求来转化到服务,进而推广、使用、落地。但是你这么多,也不能量化的需求,需要形成以项目维度的流水线,有需要足够的数据支撑来分析决策,让我来怎么做?我也不知道怎么做。

所以说领导讲的都是对的,但是我好难。虽说难还得往下做,所以我就讲一开始在整个 DevOps 落地的过程当中,要找准一个点,肯定要 get 到一个最急迫的点,如何选择这个点,第一,你考虑到需求提炼,第二领导是否对你的点感兴趣。

如果领导说这个事儿你要做,那我就是以领导为准,但是领导一般讲的东西都是很泛,他会告诉你他需要什么,但是他不会帮你分解,需要你自己来分解,你只能通过研发、运维、测试、产品、项目当中的一个大家都比较关注的一个点,比如提升效率,提高质量,打通团队的墙,才能继续以它为开始,通过横向、纵向的方式进行扩张。

千人一面还是千人千面呢?这个图对于研发来说有很深的感触,当用户跟你要一瓶水的时候,他是真的跟要一瓶水吗?不是,他要的是西瓜,但是他只会跟你说他渴了,其实在我们做DevOps的过程当中,我相信大家也会有相关的一些体会。

现在我们就回到下一个问题,格局决定结局。

我们做 DevOps 之前需要思考一些问题,潜在用户是谁?DevOps 的项目推广之后,我的 DevOps 的用户是谁?第二个,他在哪里,他平常的喜好是什么?他讨厌什么?他想要什么?一般他对我的 DevOps 的产品哪些功能、模块感兴趣,我现在做的产品是不是满足他的需求?

我对接的这些用户,比如ABCDE,我这五大类的用户,他每天的工作是什么,他的理想工作是什么?我跟他的交集一般是什么?接下来梳理清楚之后,我需要怎么做,我要什么资源,我的资源从哪来?它里面其实最核心的一个东西,我要找准我的用户,我不可能把我所有的用户纳入到我整个的服务体系当中,那我就要在整个的项目进行到一半的时候,选择项目推广裂变的方式的时候,把我核心的用户的需求找准落地,以他作为延伸,向四周去拓展。

我们又回到了他是谁,基于整个的用户体验的方法论来说,找准这个他,真的是很不容易,所以我们在找他的时候,尽可能在我们的周围找这个他,而且一定要找准正确的他。对于我们整个的 DevOps 在落地开始,或者 DevOps 项目在我们的需求整理,在即将进入开发,或者说在我找准整个用户群,整个用户覆盖面这些问题之前,那我们要思考一下这个他是否能够对DevOps推广过程中能够加持。

第一个就是很厉害的,英明神武的领导,这个是他是推广中最重要的。第二个就是测试路人甲,头发稀疏的写JAVA的,还有一个就是通宵的运维背锅工程师、得罪不起的项目经理,漂亮的产品经理。所以你只要把这些他全部覆盖到你整个DevOps的受众人群里去,那你才有可能通过这些他,映射到相应的环节,在这些环节中落地了关于他的各种各样的数据,才能贯穿整个全生命周期,而这些数据的整合和处理最终是推动整个环节的优化和提升。

二、相爱相杀的运营之殇

我在做这一页的PPT之前,我跟萧帮主讨论一下,我说能不能这样,我把我的想法跟你说一下,通过短信的方式,然后你按照我的想法你把这个罗列给我,我要截个图,做到PPT里。然后萧帮主跟我说,说他的角色是什么,我说你有两个角色,你第一个角色是研发,第二个角色是运维,萧帮主说好吧,那就这么干吧。

第一个,从研发的角度来说,当你的团队刚刚纳入整个 DevOps 体系的时候,你肯定是被约束的,因为刚开始进入 DevOps 阶段你还是属于以流程为驱动的工作方式,在这个环境当中,我的工作总是被流程所左右,我除了写代码我还要关注质量测试和发布环境。

在流程中我要身兼多职,这样让我的技术反而不精。其实这一句话是什么意思?当 DevOps 在落地的过程中,最刚开始刚落地,或者涉及到整个的研发侧的时候,研发的工作量真的是少了吗?不是,是多了,因为那个时候研发也不知道怎么办。

所以,在这一个阶段,刚才贤杰老师也讲了,在刚开始刚推的时候,作为一个研发,第一我要写我的代码,第二我还要按照你的规则来做各种各样的事儿,在这期间出了各种各样的问题,或者我在某一个环节卡住的时候还要需要其他团队或组织的帮助。

第二个,我的价值在于代码,我还要不断的充电,我还要跟上 DevOps 庞大的知识领域,我需要在我的流程框架内活动。

其实这一段的话它是上一段话整个的延伸,其实研发的理想化的对于普通的研发工程师来说,对于业务研发,编码是研发工程师的本职工作,具备一个成熟的编码环境,具备代码仓库,具备相关必须要有的权限,我在我的权限框架之内来活动,而最终的需求仅仅是在编码的相关权责内,包括编码、联调和基本的测试,因此代码出了问题研发承担,那其它的问题的归属是值得商榷的,这应该是研发工程师最简单的一种想法。但是出了问题总要有人来承担。基于运维的出发点,仅仅只提供了资源的输出,我的资源没有问题,理论上讲我也不会背这些锅,那最后的锅应该由谁来背呢?

这一点真的是很关键,里面它有一个词我们需要关注一下,就是流程的框架,理论上讲流程的框架分为两块,第一种是我的流程的流动,我走到哪一步,哪一个节点出了问题,那这就是谁的责任。

第二个节点的边界,脱离了我的节点,或者即将进入到你的节点,那这一部分出了问题那怎么办呢?其实我觉得这一部分问题是共担的,大家都有责任,所以说我们的 DevOps 在推进的进程当中,是责任要共享,问题要共享,而KPI是不需要共享的,这个是相关团队的负责人最需要考虑的一个问题。

接下来,回到运维这个角色。在截这个图之前,我说萧老板,咱们到了运维环节,有点伤感,你先发一个红包,然后萧老板还比较给面子,发了一个红包。

第一句话先不看,我们再看第二句话,这种情况我觉得绝大多数的人都会遇到这样的一个问题。接到产品以后,或者从整个的交付周期来看,交付的环节到了运维的环节,整个的运维部门每个人的心中都充满了恐惧,对于项目或者软件,根本不了解即将出现什么问题,我只负责部署,出了问题我也不知道。

所以这个情况该怎么办,对于项目的整个情况,项目背景是什么,开发过程有没有问题,具体架构是什么,具备高可靠高可用吗,都是疑问。对于开发部门来说,需要开发这个新的产品,而这款产品需要很新、很炫的一个技术来保证客户所有的需求,从而给公司带来百万美元的利润,而这个产品要求采用最新的技术和运行的平台,还得马上进行交付。

其实这种情况我相信很多公司都遇到了,老板说我这个项目半个月就要交付,我不管IT部门是什么样的情况,你赶紧给我开发出来,赶紧上线。所以,对于研发的团队来说,这个项目需要我学习新的的框架、平台,那我就赶紧学。我学完以后,以代码的方式来实现,不考虑除了业务以外的需求,比如高可用高可靠的设计,测了没有问题以后,赶紧交付上线。

所以,经过一段时间以后,如愿完成了任务,他们把自己的交付物一股脑的甩给运维部门,后者还没有完全接手,研发部门已经迫不及待的进行了庆功宴,到最后运维人员心中充满了恐惧。只能祈祷这个项目到最后,给公司带来一定的利润以后,我这个产品不会出问题,完全在赌运气,一旦出了问题运维完全是很懵的,又回到救火队员KPI的日常。

敏捷的开发,频繁的交付,在这一个阶段很多人就说了,你有自动化的回归和自动化的交付,这个阶段处在我们没有DevOps的时候,或者说还处在自动化和平台化实现之前。

前段时间我们跟信通院晓玲老师编写企业IT运维发展白皮书过程中,讨论过这个问题,根据国家统计局的相关数据分析统计,工商注册的除了小微企业以外的其它企业,互联网行业和信息化水平较高的企业占比不到8%,在这8%的企业当中还有一部分才进入的脚本化运维的阶段,更多的企业并没有达到自动化回归和自动化交付的这一个阶段。

可以这么说,今天参加这个大会的与会者,更多的来自处在信息化水平比较高阶段的企业,我们接触 DevOps 时间比较长,或者已经进入这个领域。研发、运维、测试相应的水平都处在比较高的水平,其实你发现还有一大半的兄弟尚处于救火的状态,也时常遇到交付过程中那种茫然、不自信和恐惧的情况。

第二个,上线的失败,快速的回滚。问题来了,你整个的回滚的方案你测过吗?快速的扩容、快速的响应,你在架构设计的过程中是否有考虑过服务发现吗?其实这块全部是问题。系统的高可用,你的优雅的降级有吗?整个快速故障的告警,其实目前对于现在的绝大多数企业来说,系统层面的告警有,但是我的接口和业务层面的告警怎么来实现?

按照我所在的行业来举例,通常会遇到很多的问题,整个业务方过来跟我说你目前的系统有没有问题?我看了一个我一个告警没有,整个系统都是很正常的,但是在业务端,成功率已经下滑到一个比较高的水位了,可能的原因是业务侧的人员他配错了一个参数锁导致的。但是对于IT来说,我又想到 IT 的价值这个话题,对于业务驱动的企业来说,IT 的价值仅仅是支撑企业业务的发展。

回到问题本身,我认为我已经做的很好了,我觉得这个既不是研发的代码出了问题,也不是系统宕机导致的问题,我都已经交付给你了,业务方在使用过程中出了问题。对于IT来说你这个问题跟我有关系吗?完全是你自己的问题,但是对于业务方和BOSS来说,基于问题的告警是否覆盖到业务这个环节,因为监控的责任部门是IT部门,出了问题你就得承担。这个问题就来了,这一块到底应该怎么来做呢?确实是很难的一个东西。

接下来是快速故障的定位,其实现在很多的公司已经实现了全链路的监控,通过同一个框架和同一个协议,将一个唯一的标识打到请求报文中,从上游到下游,顺序的往下走,所以这一块我们做到了基于全链路的贯穿。我跟很多人沟通交流,说你们在整个的日志平台当中,你采集所有日志吗?你不对日志进行分析吗?基于链路的日志分析怎么做?他们都说我也不知道怎么分析,这些零零碎碎的日志不能有效的贯穿。

当一个系统内部的接口调用或者跨系统的调用,乃至微服务的架构,那需要做很多准备工作,需要做服务调用治理,需要做链路的治理,根据梳理的步骤,才能基本达到调用链路大概是什么样子的,而且在一个很长的调用链路中体现核心的调用节点更加困难。所以这个也是目前我们在整个的 DevOps 推进过程当中来遇到的一个很严重的问题,耗费了很多的时间。

快速的进行故障的恢复,这一步其实跟运维又是强相关了。根据墨菲定律,当我要做出一个决定的时候,往往是错的,其实最根本的、最好的一种解决的方式是重启。我觉得这一段话很多人也通常都遇到了,第一个角色是运维,第二个角色是研发,这款优秀的产品在目前底层的平台上无法运行,因为这个平台太老了,研发说这不是我的错,我的代码非常完美,那是你的事儿。

第二个,这款产品的体系结构跟我们的模型不匹配,研发说你们运维部门比较笨,你们不懂技术,你们为什么不能及时的更新技术,为什么你们这么落伍,因为对于研发来说,他的职业发展的规划与运维是很少有关联的,比如说研发团队的leader,抑或是架构师,也可以转型成为某个业务线的产品经理,很少有研发转型做运维。所以很多的研发考虑问题相对而言比较片面,我的理解是南辕北辙,不是殊途同归。

而对于运维来说,我转研发很难,我要干的还是运维,那问题就来了,研发他懂运维吗?他其实不一定对,但是你运维你要懂研发吗?你要必须懂,你要是不懂那你就继续背锅,当好背锅侠。

说到这里 DevOps 终于来了,它重新定义了组织、流程和技术的关系,它重新定义了谁跟谁一起工作,和谁如何共同的工作,它致力于把不同的部门召集到一起来共同解决问题,这样的工作环境其实是我们最梦寐以求的,或者说打破组织和组织之间的墙最佳方式,它就是从组织级来做这些事,而不是从人、从项目或者说从一个阶段来开展,它是一种全局解决方案的体现。

三、运维生态之旅

下面一个欢迎进入运维生态之旅,其实刚才讲了这么多跟大家都没有讲技术,更多的是对DevOps理念的一些梳理,在第三大类跟大家讲一下,DevOps在我们企业的整个的落地过程中,我们是怎么做的,其实构建运维生态的有几种办法:

第一:以整个项目的生命周期的数据为基准来构造整个的运维生态。 第二:以资源数据为基础,其实这一块应该变现的一目了然,就以CMDB为基准。 第三:以交付数据为基准,通俗来说,是以CICD为出发点。 第四:以监控数据为基准,基于监控数据的落地、分析、关联,横向关联系统、业务、基础架构,纵向关联团队、组织、人员、项目。一般来说监控有两种方式,一个NPM,一个是APM,一个是从报文的方式,一个从日志的方式,一个是从前往后顺,一个是从后往前推。

当你在推进的过程中,你涉及到各种数据的聚合、数据的延伸,所以说从监控出发也是构成运维生态的方法之一。我们公司是选择采用以项目周期为基准的一个流水线,通过运维行业多次的讨论和沟通,从CICD的角度来推进,从软件的交付延伸到有价值的项目交付,这个是运维所希望的。

还有一种出发点是基于整个的项目的管理,基于项目数据流动的顶层设计方法,从最开始的需求的管理到最后项目的上线。还有一种方法,如果是研发很迫切,你从哪开始推?那就是环境的准备、代码的托管,如果是测试很迫切,你肯定是从整个的测试的自动化进行推进。针对苏宁消费金融来说,我们的出发点有两个需求,一是提升组织级的效能和质量,而是以项目的维度,贯穿项目的交付环节,不断的优化和提升。从项目的开始、项目的立项、从需求的管理,基础架构整体资源的输出,然后再到编码过程,联调后进入CICD阶段,再同步到测试的阶段,这几个过程可能会有先后顺序,也可能并行,一切以项目的需要,可以某一个团队先行,也可以齐头并进,都是可以的。

我前面梳理了很多的一些流程跟组织跟人的关系,上线以后,通过监控的数据,关联到业务的场景和经营层面的数据,再反推到项目,或反推到某个需求投入的资源,可以判定项目上线以后,成功还是失败,或者说项目过程中的管控、项目结果的判断,有没有优化的一个空间。靠什么数据来度量?靠整个基于系统覆盖业务的监控,涉及到很多系统级的、业务级的监控,我可以跟项目的需求关联到一起。

其实这张图看的也比较多,从整个的以流程的驱动方式转到以数据驱动的方式,让整个的数据流动起来。其实这一块不光是运维的数据,涉及到很多应用的数据、整个资产的数据、整个监控的数据。驱动的模式变得越来越有说服力,数据落地和流动,关联性越来越多,覆盖率和受众人群也不断的在增加,数据使用已经从IT推广到这个公司,这与DevOps的组织级的定位是不谋而合的。

在我们的整个的技术运营范畴中,二级到三级它有一个最根本性的区别,那就是数据的订阅方式,如果我是单一消费的模式,始终停留在二级,如果一份数据我被多个系统订阅进行数据消费,就跨越到三级,真是一个题外话,对技术运营评估的企业有一定的参考意义。就是我们对全局数据、数据流动的设计。

下面我们再讲一个更关键的东西,我们在整个的 DevOps 进程中,或者平台化之前,中间有一个很关键的一个步骤,这个步骤被很多人所疏忽了,我就是工具化一切,一切工具化。没有人把 DevOps 的工具链是从底层写到顶层的,一些技术特别牛的大厂除外。

基于工具化的一些思考,我这边总结了大概有四个,第一是工具的选择,第二是工具的价值,第三是工具的赋能,第四是工具的本质。

在当中,有一些心得跟大家分享。一、尽量不要做到工具的二次开发,以我的经验来看,二次开发投入的人力和物力过于庞大,而且工具的作者也有相应的优化迭代计划。

对于工具的使用,只需使用工具的相应功能,如jenkins的交付、Ansible的配置管理、sonar的静态扫描。采取接口的方式,把每个工具抛出的数据集中、聚合、分析,形成链式报表。二、做到工具集群的解耦,比如说某些工具具备高可用集群方案,或者强关联的一些功能。贸然使用,会导致工具内部出现问题不能快速的解决,需要扩容,需要做更多的配置,不能快速上线。我们的做法是工具的解耦,工具的使用永远的最干净的。

我选择工具的时候,第一个,当我的技术没有完全hold住它的时候,你选择一个,哪怕短期能给你带来一些比较高的收益,一旦它出问题或者你用得很重的时候,你能hold住吗?其实你hold不住,到那个时候你受到的影响更大。我们再举一个很典型的一个例子,Jenkins 里面它自身有一个集群概念,我看到很多人全部在用,如果 Jenkins 它的本身的原生的集群出了问题以后,你能搞定吗?我觉得处理这些问题都是比较费劲的。

苏宁消金这一块是这么做的,我既然搞不定,我又不想研究它折腾它,那我就不用它,我自己写了一个调度的工具,让我的整个工具进行池化,工具池有别于资源池,其实我更愿意将工具当成是资源的一部分。我把工具池化以后,我在使用工具方面,当我的资源一样过来使用,当我需要扩容的时候,我把一个工具扔到里面去,发布的任务就自动分发到这个新工具上面了,这个是我们对工具的一些思考。

其实工具对于我们来说在整个的自动化到平台化这一个阶段,或者说我们在DevOps进行到一个比较深入阶段的时候,平台化更多的思考是平台对我们更多是一种赋能。

下面到我们工具链的结构,其实工具链完整以后,这一块跟很多的厂商或者大厂的DevOps 产品相比,都是大同小异,殊途同归。我们唯一不一样的是我的客户有老板,他们的客户不一定有老板。

下面是我们的总体架构的分层设计,这一块我觉得大家也就是看看而已,可以作为参考,因为大家做的也都是大同小异,殊途同归。

我们开始做这个事了,我们有一个原则,我们要做正确的事。其实这也是把大家召集到一起来进行这个项目,或者说大家一起来分享一起交流的根本原因。这个事大家都在做,或者我这个项目来开始,我在整个的项目开始的时候,我首先要考虑的什么?除了我的设计规划和以后的整个的任务分配以外,我第一个要想到的我这条路我不能走歪,我要想我要做正确的事,那我得要有一个任务,所以说我要有一个目标。

做一个比较好的规划,第一个就是完成了我的自动化。在推 DevOps 项目的过程中,首先要在组织内部完成标准化。在有数据支撑的情况下,完成可视化、数字化一些实现,相应的在整个的中台的数据层往下,我要完成我的工具化,并形成数据的逻辑整合。

基于一些考量更多的是体现在整个的平衡上,它平衡了整个速度、成本、质量和风险,以及提升了整个创新的能力,其实这个就回到了运维需不需要跑得更快一点。其实有了相应的方法论和技术的加持,其实我们就能跑的快一点。既然我们要做正确的事,我们下一步干什么?我们要正确地做事,所以说我们得要有方法。在整个的落地的过程当中,我们要从具体到抽象。

在我们这边,是准确的将这件事的落地过程分成几层,以我的服务对象,受众人群,包括我们以整个的阶段性来衡量它的最终效益的实现方式,划分了如下几个方面。

第一个,我们就找准点。第二个是根据最急迫的或者最紧急的一个需求,来找准整个的落地的基点,来逐步的延伸。

第二个,就是如何控制,我们是打造了端到端的交付能力、可持续可迭代的流水线,从前面的整个需求到架构、到资源、到开发、到构建、到测试、到部署、到交付,其实运维在项目交付中的地位是特殊的,我是贯穿全流程的,但是我在前面只是配合,不显山不漏水,到了最后方知谁是英雄。

运维是交付后的第一责任团队,交付后的相关工作都归我主导,交付之前的我是配合参与,有些事情你主导,有些事我主导。回过头来看,大家做了这么多是为了是什么?

对于项目来说,交付后有没有收益,花了多少资源,用了多少人来开发,我是不是得要考虑?所以说这也是很多的IT部门一直纠结的事,有没有通过一些方法,通过一些数据来佐证这个项目到底有没有达到预期,IT的成本投入能不能带来一些客观的利润增长,这也是我们的流水线以项目的后评价结束,也是跟其他公司的持续交付流水线不一样的地方。

落了这么多环节数据,又回到一开始的数据驱动的环节,这个项目中老板是最大的数据输出受益者。所以说问题来了,老板想要看看什么东西?你研发看到的东西、测试看到的东西、运维看到的东西,其实跟你的老板看的东西不一样。比如我是老板,我首先看我这个项目从开始到最后我花了多长时间,我经过了哪些重要的节点,我每个节点当中我用了多少的时间,我节点跟节点之间有没有优化,花了多少资源,带来了多少收益。

打个比方来说,我在需求阶段花了多长时间,有多少需求,这个需求从哪些部门过来的?在研发阶段,研发团队有多少人,每个人分配了有多少任务,他干了什么事?整个的编码过程到联调阶段,花了多长时间?一直到最后。所以从这一方面过来看,基于全局度量的一些指标,跟有价值的交付指标是息息相关的,包括我们的整个质量,跟我们的组织,跟我们的人全部都串联到一起了。

相比于流程驱动而言,以任何一个点,以任何一个数据作为枚举值,横向纵向的往前推,往后推,你都能推到版本、需求、人、组织、团队、任务、质量、资源,所谓的资源不是你用了我多少服务器,或者用了我多少带宽,这一块是资源,人员投入本身它他是一种资源,你相应的产出不是我的一个系统的产出,每一个工作量其实也是一种考量的方式。

四、落地实践中的一些痛

第一个问题,我们在某个阶段性完成整体项目的50%的时候,其实我们只完了 30%。第二个我们在某个阶段完成 50% 人员推广,实际只完成了 30%,所以说很多人就说我做 DevOps,做出来以后我开始推了,往研发、往测试、往运维或者往其他的组织、往其他团队在推,我发现推不动,问题在哪里?

回头看可能是想的过于复杂了,简单、聚焦、关注,因为你简单,你才能体现出问题的本质,你做 DevOps 你不要把它做得太重,你找准一个点,你发现难推动那肯定是你找的点有问题,或者说你找的这个对象有问题。

第二个,聚焦,你难推动的时候发现问题在哪里,你聚焦的可度量的指标是不对的。或者对于研发来来说,你不要先把他的人天的贡献度先实现,这是研发很反感的,这种单一的评估方式是值得怀疑的,所以说找的点一定要对。

第三个关注,关注哪些数据,哪些数据才有改善,你一定要关注核心的数据,你的核心的数据在哪里,那就要看老板更关注哪些,老板更愿意看到这个项目质量更高一点,能逐步产生效益,还是这个项目要尽快上线,人天效率更快一些,对于质量可以稍微包容一点。这是做 DevOps 落地的人需要衡量的,或者说 DevOps 推进过程中必然会遇到一些数据矛盾的地方,不会那么十全十美。

第二个问题,其实当初进行PPT审核的时候,大家对这一句话是非常的赞赏的。就表达一个观点,你目前的来看,其实缺 DevOps 的人吗?其实不缺,他缺的是对 DevOps 的有规划和体系建设的人,这也我本次分享最想表达的意思,全局的思考,有序的规划,可持续的体系建设非常重要,做任何一件事,要正确的做事,找到正确的方法,找到正确的对象。

第三个我们谈了一些体系和理念,我们再谈谈一个跟方法论相关的,有几个图,第一个图,应该玩的人很少,是一种网页文字的游戏。下面的是一个很漂亮的游戏,最右边是一个脚本。那我的问题来了。你觉得这个脚本是DevOps方法吗?有人知道吗?其实是。为什么不是?按照DevOps的方法论来说能够提升效率和质量,但是并不是最佳实践方式。

回到最后的问题,我们聊一下,DevOps技术的管理,它其实是两块,我个人进行了总结,纵向能力的加强,横向能力的打通。

纵向能力的加强,就是研发过程中各阶段的一种管理能力,包括需求、开发、测试、发布和整个技术能力,包括构建自动化、性能、部署、灰度环境和代码托管的流水线。其实我们目前做的最多的,或者说我们在整个DevOps所达到的效益,它体现在哪里?其实就体现在整个的纵向能力的服务输出。而我们的横向能力的打造,其实说起来是比较虚的,根本的精髓在哪里?有价值的进行交付,所以说交付没有问题,是可以可度量的,但是你的价值如何来衡量?

其实这个是我们所思考的,当IT技术变成很核心的生产力的时候,这些非功能性的需求,对于系统来说就变成功能性需求。监控、可用性、可靠性等,这是功能性需求。不能说一个服务只要上线就好了。能监控吗?生产能看到吗?可用性能保证吗?有没有考虑失败的时候对业务的影响?它的可靠性怎么样?对别人服务的承诺、契约在极端的情况下会改变吗?这是苏宁消费金融,也是所有IT团队要去考虑和处理的一个问题。所以,横向打通更关注的是什么?有价值的监控,有价值的交付,有价值的度量,有价值的反馈,和有价值的优化。

说明:以上为苏宁消费金融顾黄亮老师在 GOPS 全球运维大会 2019 · 上海站的分享。

本文分享自微信公众号 - DevOps时代(DevOpsTimes),作者:顾黄亮

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-11-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 你所不了解的 DevOps

    DevOps时代
  • 以标准的名义!DevOps 国际峰会 2018 · 深圳站精彩实录(附大会PPT)

    是的!为期两天,1600余人签到的 DevOps 国际峰会(DOIS)2018 · 深圳站圆满结束!

    DevOps时代
  • C位出道!DevOps 中国力量海外首秀(美国·硅谷)

    硅谷(Silicon Valley),位于美国加利福尼亚州北部,是高科技事业云集的圣塔克拉拉谷(Santa Clara Valley)的别称。硅谷最早是研究和生...

    DevOps时代
  • 你所不了解的 DevOps

    DevOps时代
  • 8个让DevOps转型取得成功的关键步骤

    在数字化时代,企业需要更快更灵活的交付来支持业务运营,这种迫切的需求促成了DevOps的高速发展,成为了企业获得竞争优势的关键。尽管大家都知道DevOps给业务...

    嘉为科技
  • DevOps的前世今生

    DevOps一词的来自于Development和Operations的组合,突出重视软件开发人员和运维人员的沟通合作,通过自动化流程来使得软件构建、测试、发布更...

    Peter Shen
  • 从优秀到卓越,2020,DevOps 路在何方

    DevOps 的历史要从一个比利时的独立IT咨询师说起。这位咨询师的名字叫做Patrick Debois,他喜欢从各个角度研究IT组织。2007年,Patric...

    DevOps时代
  • DevOps改变IT部门运作方式的8种优势

    企业IT部门试图通过实施DevOps来实现技术创新,随着DevOps趋势的持续流行,敏捷开发以及诸多容器编排平台工具已经屡见不鲜。

    APICloud
  • 这 7 种常见的操作陷阱,是落地 DevOps 的绊脚石

    DevOps 不仅仅是一种实践、特定的概念,它是开发人员和IT专业人员之间的一种智能协作,DevOps 的成功以及它的目标愿景需要革命性的思维和全新的视角,将 ...

    DevOps时代
  • 将DevOps视为哲学——实施DevOps的绝佳方式

    经过此前的文章介绍,相信大家都对DevOps有了简单的了解。(回顾DevOps是什么、生命周期点这里:《DevOps生命周期,你想知道的全都在这里了!》)Dev...

    陈琦聊测试

扫码关注云+社区

领取腾讯云代金券