苏宁消费金融超大规模IT系统的DevOps落地实践

彭小阳

作者简介：顾黄亮，十年研发运维经验，涵盖基础架构、数据库、DEVOPS。四年的运维管理经验，有互联网，电商，金融从业经历。 参加多个行业、国家标准的编写，《开源许可证使用指南（2018）》作者之一，国标《研发运营一体化（DEVOPS）能力成熟度模型》作者之一。

今天跟大家分享的一个主题，就是苏宁消费金融超大规模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的这个人是谁？你是不是运维或者研发或者说测试，或者说管理项目的一个项目经理。他有这个想法，其实我觉得谁做都不要紧，谁做都可以，只要你具备这个能力，你肯定是从完善一个点。

对于运维过来说，你肯定是从CACD开始，但是你CACD，经过我的经验来看，如果你能力足够的话，三个月你就做完了，你做完了以后这个项目就结束了，它能代表你的DevOps真正的就结束了吗？错，其实它仅仅是一个开始。

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

其实根本的来说DevOps它是什么东西，我相信可能在我们运维这个行业里，对DevOps的理解其实存在有一种偏差，很多人对企业里面对这个DevOps理解都是我开发一个系统，它具备一个DevOps的功能，那我把它命名叫DevOps系统，或者DevOps平台，可以吗？

其实也可以，但是你觉得根据DevOps的精神，你觉得这样子来合适吗？我觉得并不是很合适。因为DevOps从本质上来说，它其实是一种方法，它是一种理念，它是一种实现，它并不是一个系统，并不是一个平台，它不是一类的技术，其实它也没有相应的一个产出过。

但是你可以根据DevOps的一个方法，你来设计出一个具备DevOps这样的一个效能的工具，这样子它是可以的。

第二个DevOps最根本的一个价值，它其实是一个可度量的价值。可延伸的价值、可迭代的价值、可赋能的价值，其实它的根本的意义是度量。

我昨天跟牛小玲跟他在那边聊，我说目前很多我们参DevOps的一种赋能组织里面的企业，我们的这种企业对DevOps在企业当中的一个落地，它最后体现出什么？我从一开始的整个的流程驱动，其实这一个过程我是很好做的，尤其对于传统企业来说，它是一种天然的优势，因为对于传统企业来说，它更讲究是它的整个流程在企业当中的一个贯穿。

所以说你通过流程来驱动的DevOps，它是什么？它是我们狭义上面所理解的叫流水线的一个概念，你整个的流程到最后，我再怎么来做，所以说我就必须要有整个的深层技术的加持，所以很多人正在讲我目前是DevOps的，我的过程是不是已经快结束了？我下一步是不是到了AROps？我可以这么说，早呢。

其实ArOps是什么？我个人对它的理解，ArOps，当你是DevOp在企业当中，我可能已经落地落完了，我发现DevOps并不能完全覆盖我的目前企业当中的一个需求，或者说运营、研发、测试它整个一体化的一个需求，我需要对DevOps做一些延伸，那做的这些延伸，它就是我们现在所讲的ArOps，其实ArOps它是有根脚的。

我真正的要达到这一个阶段，或者说我达到这一步，我需要什么？数据，我需要的是海量的数据，所以说又来了，我们在整个的流程驱动后面，我们将要进行的是由数据来驱动。

数据来驱动以后，我的每一个节点，每个环节，我会保留了很多的数据，这些数据也会反推我在DevOps整个的落地过程和整个的效益产生，我会具备，比如说我有度量的价值，我有赋能的价值。

我基于一些数据的加工、聚合、统计、计算，或者说乃至后面的数据的预测，DevOps我就有了延伸，它会很直接的、很顺沿的，从我的DevOps到我最后的ArOps。所以说没有数据的加持，DevOps和ArOps它中间始终是一个鸿沟，你是完全是跨不过去的。

我们继续再回到前面价值这一块，终究这个价值是什么？这个价值是交付，是数据的交付，是过程的交付，是服务的交付，其实针对一个服务的交付，我这两年我又听到了一个关于整个的服务上面，对这一块新的理解。

我们之前讲的AaaS、PaaS、SaaS，但是到了这一步，你真正的根源，你技术终究跟个人要结合，其实到了这边，你随着整个DevOps进程的一种发展，你到最后你的团队他难道就不是一个服务吗？其实你的团队到后面它本质来说，以团队的输出，它也是一个很关键的服务。

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

我想表达它千人千面DevOps它所理解的或者说DevOps在每个人的眼中它是什么样子的。

其实在领导眼中，它从全局来出发，这又回归到整个的DevOps，它是提高组织级的效能和效率，它其实不关心这里的细节，我只要有一个工具，有一种方法，能帮我把整个组织级的效能和效率提升，这是领导所需要的。

运维眼中是什么？你不要再烦我了，我提供我的服务，提供平台来给你使用，这也是上一次演讲贤杰老师，他们目前已经能具备这样子的，他就是我放权给研发，你整个的CICD的一个过程，整个的代码托管的一种过程。

我所有的放权全部给你研发，由你研发来管理，你整个的研发能力，给你团队的工作，你具备哪一些缺陷，你具备哪一些系统的管理权限，你在哪个合适的时间或者说你在树立整个的上下游耦合这一块方面，赋予你的具备的一些权限。

所以，对于我运维来说，这些事儿我放给你了，那你就不要再来烦我，或者说我的平台出了问题你过来再找我，其实这一个阶段我感触很深，我也是从研发过来的，在我当研发的时候，我对运维是什么？这一块出了问题，我本身环境是好的，我设置的环境是好的，你生产环境出了问题你自己过去查，不关我的事儿，是你运维的事儿。

其实你看到运维那种很茫然的眼神，你是不是产生了一种快感？但是对运维来说，后来我从研发转到运维以后，研发跟我讲，说昨天我有某一个系统我CPU调到100%，你赶紧给我查，这是你这边的问题，然后我把它整个打了出来，定位到包、定位到方法，我一个邮件回了，我说你自己查，这是你的问题，跟我没有关系，问题我都帮你找了出来了。

然后研发傻眼了，研发说你这个人，那怎么弄呢？那后面就很难查了，我后面锅就不能让你背了，其实那个时候运维是扬眉吐气的。

在研发眼中，其实咱们刚才只是讲了一个小故事，其实真正的在研发眼中，他真正想做什么呢？他说我只想做研发，我只想写代码，其它乱七八糟的事儿我真不是很想干，其实这个是真正的研发的写照，从一开始研发所有覆盖的职责一直到现在，其实其中一直是有这样的一个问题的。

从测试的眼中，那我终于可以以质量作为一个抓手，其实准确来说，现在很多的企业现在都没有把质量安全以这种数据可度量的方式，大家注意，还是以那种比较偏原始的或者说半自动化的。

从一开始功能性的测试，而安全和度量它各个环节的一种覆盖率、成功率，这一块还是跟现在自动化这一块来说，它仅仅是达到了自动化，它并没有相应的数据来抓到我手里面，以整个度量的方式作为一种抓手，来提升我整个的项目或者说版本的质量。

在项目眼里，其实项目经理最关心的是这个项目全生命周期的管理，只要我把这个环节控好，我在整个研发的环节、运维的环节、需求的环节和测试的环节，只要大的问题没有，那这些小的问题解决下来，基本上相对而言还是比较简单的。

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

产品眼中，产品更关心的是什么？其实产品经理我只想把这些需求罗列好、设计好了，那下面就是由你开发过来来做一个相应的编码。但是你发现在这个过程当中，我的需求有多少个？我涉及到提需求的一些部门这一方面或者我的需求是正常的，属于是加塞的，需要要调整的，还是不确定的。

这些需求跟我的组织，跟我现有一些研发组织、研发的团队，研发的人，更涉及到研发团队工程师所分配的任务，我的需求所拆分的任务，这一块是关联的，其实在很多的时候或者在很多企业是不具备这样的情况，所以就需要靠人治，而不是靠系统来治理。

在整个的做DevOps人的眼中，它的感觉是什么？其实领导、测试、运维、研发或者说项目、产品，它对整个做DevOps相关的人眼里，它是需求方，我是整个把它的需求方来落地的。但是你这么多，也不能量化的需求，让我来怎么做？我也不知道怎么做。

所以说领导讲的都是对的，但是我好难。但是这个咱们还得往下做，这个怎么做呢？所以我就讲了一开始在整个DevOps落地的过程当中，我要找准一个点，我肯定要get到一个点，那我已经拿一个点来get到那儿。

如果领导说这个事儿你要做，那我就是以领导为准，但是领导一般讲的东西都是很泛，他会告诉你他需要什么，但是他不会帮你分解，需要你自己来分解，所以你只能要不研发、要不运维、要不测试、要不产品、要不项目，你找一个点，才能继续以它为开始，在横向、纵向的进行扩张。

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

打个比方说，我在整个的CD过程中，最后验证的那一步，研发只会跟你说你只要验证通过就好了，那什么叫通过呢？我是整个的打开为OK这叫通过吗？还是在我的启动日志里面没有什么问题叫通过吗？还是我的上线以后，我的业务的成功率或者我的系统的成功率达到一个比较高的水线的时候，它叫OK吗？

所以说并不是，它提供给你只是一个很简单的字，但是你需要把这个很简单的字进行一个扩张和延伸。

那我们就回到下一个，格局决定结局。

我们做DevOps之前需要回答一些问题，用户是谁？我做DevOps的项目之前，我的DevOps的用户是谁？第二个，它在哪里，它平常的喜好是什么？它讨厌什么？它想要什么？一般它对我的DevOps的产品哪些功能、模块感兴趣，我现在做的产品是不是满足它的需求？

我对接的这些用户，比如ABCDE，我这五大类的用户，他每天的工作是什么，他的理想工作是什么？我跟他的交集一般是什么？

接下来我这句话梳理清楚之后，我需要怎么做，我要什么资源，我的资源从哪来？它里面其实最核心的一个东西，我要找准我的用户，我不可能把我所有的用户纳入到我整个的服务体系当中，那我就要在整个的项目进行到一半的时候，到一段时间的时候，把我核心的用户的需求找准落地，以它作为延伸，向四周去拓展。

我们又回到了它是谁，基于整个的用户体验的理论来说，找准这个它，真的是很不容易，所以我们在找它的时候，尽可能在我们的周围找这个它，而且一定要找准正确的它。

对于我们整个的DevOps在落地开始，或者DevOps项目在我们的需求整理，在即将进入开发，或者说在我找准整个用户群，整个用户覆盖面这些问题之前，那我们要思考一下这个它是谁。

第一个就是很厉害的，英明神武的领导，这个是他我们最重的他。第二个就是测试路人甲，头发稀疏的写JAVA的，其实也不全是。还有一个就是通宵的运维背锅工程师、得罪不起的项目经理，漂亮的产品经理。

所以你只要把这些他全部覆盖到你整个的DevOps里面去，那你才有可能通过这些他，映射到相应的环节，在这一些环节的节点落地了关于他的各种各样的一个数据，才能贯穿整个的全生命周期的一些交付的数据，而这些数据最终其实是给领导看的。

二、相爱相杀的运营之殇

我在做这一页的PPT之前，我跟萧帮主讨论一下，我说能不能这样，我把我的想法我跟你说一下，我能不能跟你发一个短信，然后你按照我的想法你把这个罗列给我，我要截个图，我要做到PPT里。

然后萧帮主跟我说，说他的角色是什么，我说你有两个角色，你第一个角色是研发，第二个角色是运维，萧帮主说毫巴，那就这么干吧。

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

下面我的留存过程中我发现我要身兼多职，以上让我的技术反而不精。其实这一句话是什么？当DevOps在落地的过程中，最刚开始刚落地，或者涉及到整个的研发这一侧的时候，其实研发它真的是少了吗？不是，它是多了，因为那个时候研发他也不知道怎么办。

所以，在这一个阶段，其实刚才贤杰老师他也讲了，在刚开始他们刚推的时候，作为一个研发过来，第一我要写我的代码，第二我还要按照你的规则来做各种各样的事儿，完了以后，在这各期间出了各种各样的问题，或者我在某一个环节卡住的时候我还要找你研发来跟我来解决。

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

其实这一段的话它是上一段话整个的延伸，其实研发他的理想化的对于普通的研发工程师，我的业务研发我只要开发我的代码就好了，你反正有一个代码的仓库让我过来放，我具备这些权限，我在我的权限框架之内来活动，到最终它想要的是你出了事你不要来找我，我的代码出了问题我自己承担，那其它的问题一看跟我无关，这是他最简单的一种想法。

但是出了问题总要有人来承担，蓝是基于运维过来说我只提供了我的资源，我的资源没有问题，理论上讲我也不会背这些锅，那最后的锅应该由谁来背呢？
这一点真的是很关键，里面它有一个词我们需要关注一下，就是流程的框架，理论上讲流程的框槛它分为两块，第一种是我的流程的横向的框架，我走到哪一步，哪一个节点出了问题，那这就是谁的责任。第二个纵向的框架，那就是跟边界有相关的，脱离了我的节点，或者即将进入到你的节点，那这一部分出了问题那怎么办呢？

其实我觉得这一部分问题，大家都有责任，所以说我们的DevOps在整个的推进的进程当中，我们所想表达的是责任要共享，问题要共享，而KPI是不需要共享的，这个是整个的研发最实际的想法。

第二个，我们真正的回到了我们的这一块，其实这才是我们自己人，这个是整个的运维，在截这个图之前，我说萧老板，咱们到了运维环节，我说你先发一个红包，然后萧老板还比较给面子，发了一个红包节我，然后才说了下面的一句话。
第一句话咱们先不看，我们再看第二句话，这种情况我觉得绝大多数的人都会遇到这样的一个问题。接到产品以后，或者从整个的交付周期来看，我到最后的阶段，交付的环节到了运维这一块，整个的运维部门每个人的心中都充满了恐惧，它根本就不了解你当中是什么问题，我只负责部署，出了问题我也不知道。

所以这个情况该怎么来，他整个情况，前面的背景是什么，开发部门需要开发这个新的产品，而这款产品需要很新、很炫的一个技术来保证客户所有的需求，从而给公司带来百万美元的利润，而这个产品要求采用最新的技术和运行的平台，还得马上进行交互。

其实这种情况我相信很多公司都遇到了，老板说我这个部门马上就要上了，我不管你整个的IT部门是什么样的，你赶紧给我开发出来，赶紧来上线。

所以，对于研发公司过来说，你需要我新的需求、平台，那我就赶紧学，我学完以后，我按照整个网上的教程，我赶紧把这个变化，测了没有问题以后，我就赶紧来上线。

所以，经过一段时间以后，如愿完成了任务，他们把自己的节奏一股脑的甩给运维部门，后面还没有完全接着，研发部门已经迫不及待的进行了庆功宴，到最后运维人员心中充满了恐惧，我只能祈祷我这个跑到最后，给公司带来一定的利润以后，我这个产品不会出问题，我完全在赌运气，一旦出了问题以后，我运维完全不知道怎么办，我还得自己打个电话去找研发说过你过来帮我看这个有什么问题，那个研发工程师说你先看，我怎么看，我也不会。

我们就回到这一块救火队员KPI的日程。

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

我们上一次前面两天我们跟信通院林老师我们在做整个的IT运维发展白皮书编写过程中，我们就讨论过这个问题，其实根据整个国家统计局的统计，在工商当中注册的除了小微企业以外的其它行业，其实互联网行业和信息化水平较高的企业占比不到8%，在这8%的企业当中还有一部分才到整个的脚本化，所以你又抛弃了这一层，其实我们没有达到自动化回归和自动化交付的这一个阶段的企业，我可以这么说，达到了90%，只不过我们目前在这个行业内，或者我们接触DevOps时间比较长，或者已经进入这个领域我们的研发相应的都会比较高，其实你发现还有一大半的兄弟还在处于救火的状态，也是处在我接了项目内心非常挣扎，又非常恐惧的一种状态。

第二个，上线的失败，快速的回管。问题来了，你整个的回管的方案你测过吗？快速的扩容、快速的响应，你在架构设计的过程中有考虑过服务发现吗？其实这一块全部是问题。

第四个系统的高可用，你的优雅的降级有吗？整个快速故障的一种告警，其实目前对于现在的绝大多数企业来说，我的系统的层面，他一块快速的告警有，但是我的结果和业务怎么办？

其实按照我们的行业，我们通常会遇到很多的问题，整个业务方过来跟我说你目前的系统有没有问题？我看了一个我一个告警没有，整个系统都是很正常的，但是在业务端，他整个已经下滑到一个比较高的风险了，但是他最重要的原因是业务的人员他配错了一个参数。

但是对于IT我们又回到了IT的价值，我认为我已经做的很好了，我觉得这个既不是我研发的代码出了问题，也不是我自己运维瞎搞搞出来的问题，我测试了也没有问题，我都已经交付给你了，业务方在使用了，你在整个的配称当中，你自己出了问题。

但是对于IT来说你这个问题跟我有关系吗？完全是你自己的问题，但是对于业务方和整个boss来说，我不管你什么问题，因为监控这一环是你的，除了问题你就得担，这个问题就来了，这一块到底应该怎么来做呢？确实是很难的一个东西。

第二个，快速故障的定位，其实现在很多的公司已经通过了同一个协议或者同一个框架，已经做到了把整个通过我同一个协议，从上游到下游，顺序的往下走。所以这一块我们做到了一个调用，但是没有做到整个调用的链路，这一类企业其实还是很多的。

我跟很多人在沟通、在交流，说你们在整个的平台当中，你只是一个存换日志的嘛？你不对日志进行分析吗？他们都说我也不知道怎么分析，这些零零碎碎的。

我说当一个系统里面我知道怎么来分析，如果是跨系统的，那需要做很多准备工作，我要做很多提前的梳理，根据我梳理的步骤，我才能基本上来达到我的调用链路大概是什么样子的，所以这个也是目前我们在整个的DevOps推进过程当中来遇到的一个很严重的问题。

下面快速的一个故障的恢复，这一步其实跟我们运维又很相关了，当我要做出一个决定的时候，往往是错的，其实最根本的、最好的一种解决的方式是重启。

我觉得这一段话很多人也通常都遇到了，第一个是运维，第二是研发，这款优秀的产品在目前底层的平台上无法运行，因为这个平台太老了，研发上面说这不是我的错，我的代码非常完美，那是你的事儿。

第二个，这款产品的体系结构跟我们的模型不匹配，研发说你们运维部门比较笨，你们不懂技术，你们为什么没法实行更新的技术，为什么你们这么落伍，因为对于研发来说，研发它的整个直接的职业发展的上升，他更多的考虑我要不是当研发团队的领导，我就是转型当架构师，或者再回去我转一个产品经理，谁愿意干你运维啊。

所以说，对于运维来说，我转研发很难，我要干的还是运维，那问题就来了，研发他懂运维吗？他其实不一定对，但是你运维你要懂研发吗？你要必须懂，你要是不懂那你就继续背锅。
下面这款产品，我们搞不懂，它里面有很多报告安全、监控、备份、服务提供，这个我不懂，我没办法把它作为实际的产品，那下面这款怎么来说？其实这一款大家听到有很多了。在我电脑上跑了没有问题，为什么你给我发到产业环节上面就出问题了。第二个就是在测试环境没问题，为什么跑到生产上面就有问题了？其实这一块大家都见到都是比较多的。

所以说DevOps来了，它重新定义了组织、流程和技术的关系，它重新定义了谁跟谁一起工作，和谁如何共同的工作，它致力于把不同的部门召集到一起来共同解决问题，这样的工作环境其实是我们最梦寐以求的，或者说最想得到的，它就是从整个的组织的级别来做这些事，而不是从人、从项目或者说从一个阶段来开展，它是一种全局的。

三、运维生态之旅

下面一个欢迎进入运维生态，其实刚才讲了这么多跟大家都没有讲技术，我们在第三块跟大家讲一下，DevOps在我们的企业的整个的落地过程中，我们是怎么做的。，其实构建运维生态的有几种办法：

第一，以整个项目的生命周期的数据为基准来构造整个的运维生态。
第二以资源数据为基础，其实这一块应该写得一目了然，就以CMDB为基准。
第三，以交付数据为基准，以CFDD为基准。
第四，以监控数据为基准，由监控从后往前推，或者说监控有两种方式，一个IBM，一个是APM，一个是从报文的方式，一个从日志的方式，一个是从前往后算，一个是从后往前推。当你在推进的过程中，你涉及到各种数据的聚合、数据的延伸，所以说它也是构成运维生态的方法之一。
我们公司是选择采用以项目周期为基准的一个流水线，其实我在跟大家的沟通当中，其实我听了各种各样的方方法，有的是以整个的CACD，这个是运维所希望的。

然后一种是基于整个的项目的管理，第一个从我的需求的管理到最后我的项目的上线，这也是一种方法。还有一种方法，如果是研发很迫切，你从哪开始推？那就是代码的托管，如果是测试很迫切，你肯定是从整个的测试的自动化这一块来进行推。

所以说基于我们这边我们从项目的开始、从项目的立项、从需求的管理，需求管理以后，我到整个的一个资源的输出，然后再到我的整个的编码过程，当然从我的编码过程我同步就进行了整个的CSCU，我整个的测试的过程，这几个过程我可能会有先后顺序，我也可能会某一个角色或者说某一个团队他先行，这个都是可以的。

也可以同时并行往后算，所以说一直到最后他中间夹杂了各种各样的，我的质量、我整个的能效，我这一部分的一些数据来落地，其实我最后到了倒数第二个第11点这一块，我所有的到现在作为一个宗旨，那就是我的具备上线的条件。到最后我上线条件以后就结束了吗？我的这一条流水线就结束了吗？其实没有。
我前面梳理了很多的一些流程跟组织跟人的关系，我的上线以后，我的监控的东西，我后面的整个的追责，我判定它的整个的项目上线以后，它的整个的项目成功还是失败，或者说它的成功率速度多少，它整个有没有优化的一个空间，我靠什么来？那我就靠我的整个的运维的监控，因为我运维了有涉及到很多系统级的、业务级的监控，我可以跟它的需求所挂到一起。

其实这张图看的也比较多，我从整个的流程的驱动转到我的数据的驱动，我就要让整个的数据流动起来。其实这一块不光是运维的数据，我有涉及到很多应用的数据、整个资产的数据、整个监控的数据。

在我们的整个的基础运营，就是CEO的这一个阶段，二级到三级它有一个最根本性的区别，那就是第一个我数据的订阅，如果我是单项的来定，始终停留在二级，如果一份数据我被多个系统锁定，也说你才将将跨到三级，这是题了一个题外话，就是我们对整个的数据、数据流的一个设计。

下面我们再讲一个更关键的东西，我们在整个的DevOps或者平台化之前，我中间有一个很关键的一个步骤，这个步骤被很多人所疏忽了，我就是工具化一切，一切工具化，没有人做DevOps是从底层写到顶层的，我包括跟阿里、跟腾讯这些企业来聊天，其实他们在外面看到一些很炫的。

这个是咱们可能不一定做得出来的，但是选择的工具其实跟我们是一样的，所以说基于工具化的一些思考，我们这边总结了大概有四个：
1、工具的驾驭。
2、工具的价值。
3、工具的赋能。
4、工具的本质。

其实回整个的回顾到一个工具，其实你做一件事，比如说整个的发布了一个功能，我用脚本可以吗？可以，你用jekins可以吗？其实它也是可以的。

我选择工具的时候，第一个，当我的技术没有完全hold住它的时候，你选择一个，哪怕短期能给你带来一些比较高的受益，一旦它出问题或者你用得很重的时候，你能hold住吗？其实你hold补助，到那个时候你受到的影响更大。

我们再举一个很典型的一个例子，一个jekes里面它自身有一个集群概念，我看到很多人全部在用，但是我就问一下，如果jekes它的本身的原生的集群出了问题以后，你能搞定吗？我觉得很多人都是搞不定的。

我们这一块怎么来做，我既然搞不定，我又不想来研究它，那我就不用它。我自己写了一个调度的工具，让我的整个的工具池化，我这个叫工具池，它有别于资源池，其实我更愿意的工具是我的资源的一部分。

我把工具池化以后，我在使用工具方面，当我的资源一样过来使用，当我需要扩容的时候，我把一个东西再扔到里面去，我其它理解发布的任务我就顺延到这个上面过来了，这个是我们对工具的一些思考。

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

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

下面那是我们的这一块的一个总体架构的分层，这一块我觉得大家也就是看看而已，这一块的大家做的也都是大同小异。

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

我做到一个比较好的，第一个就是完成了我的自动化。我推DevOps或者说我往前推，或者往后算，我完成了我的标准化。在有我数据支撑的情况下，我完成了可视化、数字化，相应的在我的整个的中台的数据层往下，我要完成我的工具化。

它更多的是体现在整个的平衡上，它平衡了整个速度、成本、质量和风险，以及提升了我们的整个创新的能力，其实这个就回到了运维需不需要跑得更快一点。其实我们有了这样子以后，其实我们就能跑到相应的能跑的快一点。

再往下既然我们要做正确的事，我们下一步干什么？我们要正确地做事，所以说我们得要有方法。在我们的整个的落地的过程当中，我们从具体到抽象。
在我们这边，我们就是准确的分成几层，以我的整个的对象，我的服务对象，包括我们以整个的阶段性来衡量它的效益的，我们划分了几个，这是我们第一个，我们就找准点。第二个是根据最急迫的或者最紧急的一个需求，来找准整个的落地的基点，来逐步的来延伸。

第二个就是如何控制，我们是打造了端到端的交付的、可持续的流水线，从前面的整个需求到架构、到资源、到开发、到构建、到测试、到部署、到交付，其实我运维跟项目一样，我是贯穿全流程的，但是我在前面只是配合，我不显山不漏水，到了最后才到我运维。

我运维到根本的时候，我是交付以后的，都归我，交付之前的我是配合你参与，有些你主导，有些是我督导。但是说我整个的回过头来看，大家做了这么多是为了是什么？难道一个项目对于我企业来说，我的ID我就负责帮你做，但是你这个项目到最后有没有收益，你花了我多少资源，用了我多少人，我是不是得要考虑？

所以说这也是很多的IT部门，我一直是从整个的成本部门，但是我没有想过我有没有想过、我有没有通过一些方法，我通过一些数据来印来印证了我成本部门是不是我转变成利润中心？后面就是整个的项目的一个评价。

我落了这么多数据以后，或者说从一开始讲，这个项目我最大的受益者，或者说对于我整个的资源的一种助推的人是谁，那是老板，所以说他问题来了，老板想要看看什么东西？你研发看到的东西、测试看到的东西、运维看到的东西，其实跟你的老板看的东西不一样。

比如我是老板，我首先看我这个项目从开始到最后我花了多长时间，我经过了哪些重要的节点，我每个节点当中我用了多少的时间，我节点跟节点之间有没有优化。

打个比方来说，我在需求阶段花了多长时间，有多少需求，这个需求从哪些部门过来的？在我的研发阶段，我研发团队有多少人，每个人分配了有多少任务，他干了什么事？从整个的编码的编写到整个一些版本的方法，它花了多长时间？一直到最后。
所以从这一方面过来看，整个的度量的一些指标，基本上跟我们一开始的一个交付，包括我们的整个质量，跟我们的组织，跟我们的人全部都串联到一起了。
你相比于而言，我以任何一个点，以任何一个数据作为枚举值，你横向纵向的往上推，往后推，你都能推到版本、需求、人、组织、团队、任务、质量、资源，所谓的资源不是你用了我多少服务器，或者用了我多少带宽，这一块是资源，我人本身它他是一种资源，你相应的产出不是我的一个系统的产出，我每一个工作量其实相应的它也是一种产出。

四、落地实践中的通

第一个问题，我们在某个阶段性完成整体项目的50%的时候，其实我们只完成了30%。第二个我们在某个阶段完成50%人员推广，实际只完成了30%，所以说很多人就说我做DevOps，做出来以后我开始推了，往研发、往测试、往运维或者往其他的组织、往其他团队在推，我发现推不动，问题在哪里？
第一个就是简单、聚焦、关注，因为你简单，你才能体现出问题的本质，你做DevOps你不要把它做得太重，你找准一个点，你发现你难推了那肯定是你找的点有问题，或者说你找的这个对象有问题。
第二个，聚焦，你难推的时候你发现问题在哪里，你聚焦的可控制的指标是不对的。或者对于研发来来说，你不要先把他的每天的人添的贡献度给它弄了的，这是研发很反感的，研发说我难道一天在那边写代码，我不需要跟人家去交流吗？你把这个数据弄出来以后，让我的老板看到以后他对我是什么想法？所以说找的点一定要对。
第三个关注，关注哪些数据，哪些数据才有改善，你一定要关注核心的数据，你的核心的数据在哪里，那就要看老板更关注的意思，你老板更愿意你这个项目质量更高一点，能逐步产生效益，而是我马上就要把这个项目赶紧往上推，我质量可以稍微疏忽一点，所以说这是做DevOps的人需要衡量的，或者说整个的推DevOps的需要衡量的。

第二个问题，其实我当初把PPT发给萧帮主看到了，萧帮主对这一句话是非常的赞赏的，其实它就是一句话，你目前的来看，其实缺DevOps的人吗？其实不缺，他缺的是对DevOps的有规划和体系建设的人，这也就是说我本次讲这一次PPT的一个根本宗旨，就是说你做任何一件事，要正确的做事，要找到正确的方法，甚至要找到正确的对象。

第三个我们谈了一些体系和理念，我们再谈谈涉及到底层的一个技术跟理念相关的，我们有几个图，第一个图，这两个都是我随便截的，它其实是一个游戏上面的，应该玩的人很少，那种文字的游戏。
下面的是一个很漂亮的游戏，最右边是一个脚本。那我的问题来了。你觉得这个脚本是DevOps吗？有人知道吗？其实是。为什么不是？你按照DevOps的方法论来说，但是并不是DevOps工具的一种体现方式。

我们回到最后的问题，最后我们聊一下，DevOps技术的管理，它其实是两块，我个人把它总结了两块，一个是纵向能力的一个加强，和一个横向的打通，纵向能力的加强，就是研发过程中各阶段的一种管理能力，包括需求、开发、测试、发布和整个技术能力，包括构建自动化、性能、部署、灰度环境和代码托管的流水线。
其实我们目前做的最多的，或者说我们在整个DevOps所达到的效益，它体现在哪里？其实就体现在整个的纵向能力。而我们的横向能力的打造，其实它是比较虚的它根本的一个精髓在哪里？自我有价值的进行交互，所以说交互没有问题，你有价值怎么来衡量？
其实这个是我们所关注的，包括整个的监控，持续的监控和反馈，你的监控对象是什么？难道IT只是基于IT之上做监控吗？这个是应用，这个是整个的业务部门所需要的吗？你可以这么说，我的CPU达到多少，我的什么内存，我的超值达到多少，业务人员他看得懂吗？他根本就看不懂。
他关注的是我的业务有没有受到影响，他要的是一个结果，而不是你监控反馈给他的我某一个什么出发系所给你发的一种告警或者一个邮件。
所以，横向打通更关注的是什么？我有价值的监控，有价值的发布，有价值的交互和有价值的评估。