相爱相杀的运维之殤：苏宁消费金融超大规模 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时代”公众号诚邀广大技术人员投稿。

投稿邮箱：jiachen@greatops.net 或 添加联系人微信：135 2116 9787（同微信）。