【2018DevOpsDays精彩演讲回顾】数字化DevOps



讲师：付大亮 中国银行软件中心

原载链接地址：http://mp.weixin.qq.com/s?__biz=MzI3NDk5NDk3OQ==&mid=2247483962&idx=2&sn=73b540529d2273dd2147bceecd829d3c&chksm=eb0ac076dc7d496058ef5e3503ebbd32c6c8e01c7fb7107d508ba0dba6068db358c4c2464169&mpshare=1&scene=24&srcid=0609K4fbW1DJkf2iiA2LYJQr#rd 

付大亮：各位来宾大家下午好，我是付大亮，来自于中国银行软件中心。软件中心整体在实施DevOps，我今天讲一讲我所在部门做的那一部分的特点——数字化DevOps以及它的设计与思考。那么什么是数字化呢？举了例子吧，我肤色偏黑。有没有比我更黑的呢？ 肯定有。老子在道德经中说“有无相生、难易相成、长短相形、高下相倾、声音想和、前后相随。”在一个小范围内，特定语境下，高低、大小、长短这些是非常有意义的。但在今天信息信息爆炸时代，样本量很大的时候，这种比较是无法细腻反映情况的。同样在软件开发行业，以前是半年、甚至一年才出一个版本。现在每天都可以有版本。我们需要更为精确的比较，这就是数字化的意义。回到刚才我比较黑这个例子，怎么数字化呢。简单讲就两点，定义一个单位，定义一个测量方法。

今天围绕数字化DevOps这个话题，汇报分四个部分：第一部分介绍我们软件中心开展工作的背景以及设计目标。第二部分是DevOps方案设计过程，按照TOGAF逻辑讲解设计过程。第三部分是实施概要，简单介绍一下当前的实施情况。最后一部分是我们下一步设想。

2013年软件中心成立新技术研究实验室，包括X86技术方面、管理工艺和工具方面。目前已经有很大产品使用敏捷、DevOps和X86技术。

做DevOps最重要的是明确问题、现状、痛点和预期目标，说的有点虚、但非常重要！现实世界存在的事物，可以有很多中观察的视角。所谓“横看成岭侧成峰”，比较理想的是360画像，但受项目周期、成本、技术等因素制约，数字化的方法，内容都是精心挑选的。如果目标不明确事情就有很多做事方法，条条大陆通罗马，你为什么选择这条路呢？企业最重要的就是降本增效，那么多的项目，怎么把项目情况及时、准确的反馈给干系人，这就是要做数字化的主要原因。

有了数据，智能化什么的才能做起来。工业4.0、智慧城市都是在数字化基础上才能做到的。实施数字化之后你可以很好的了解整体状态。是不是什么东西都应该去量化？事实上来说，在大多数中国企业并不是什么都适合量化。所以你的组织架构决定了你的应用架构。你在做数字化也好，做DevOps也好，其实第一个要考虑的是你的组织结构和你组织的目标——这就是著名的康威定律！接下来还要考虑大方向是创新还是改进？提创新的人很多，提改进的人较少。其实在同一个层面，创新和改进有区别，但在不同层面，创新和改进是可以互相转换的，所以创新和改进都应该得到重视。一个员工创新对企业可能是一个小小的改进，但是无数个小小的改进积累起来就是一个很大的创新。我们做DevOps的起点就是整理软件发布过程，一点一点的改进，然后累积到今天，大家看到觉得还可以的东西。

第二部分，方案设计过程，包括概念模型建立、团队工作模型和工具选型和分析这个过程等。我们实际做的时候并不是一帆风顺的，而是逐步的迭代提升。

首先从整体看，要达到目标，从难到简，首先定义我要做什么，做这个事情的方式。刚才讲愿景的适合，说数字化，是要选择视角的。在建立概念模型的适合，也是需要选择视角。需要从总体看，有那些视角，然后选择几个对目标影响最大的视角进行分析。我们选择了工艺、工具、技术、文化几个方向分析。如此设计是否最优？其实这个不重要。如此设计是否能够落地，是否具备可实施条件。在资源允许并且能够看清的情况下，可以做适当提高。有了接入点，我们分布从不同角度分析问题。

从管理视角看： 事情有那些，如何分类。每类事情的优先级、先后次序、彼此关系；每类事情完成的步骤；当前，那些事情属于 垃圾事——事多、钱少、没面子，不容易找到人干。 事少、钱多、有面子。这里需要一个调研。最终你可能选择 大家都说好的；让你很疼的。不仅仅是对公司，也是对你实施这件事的人的正面的反馈，然后是分步怎么一步步的把这个事情完成。

 

对工作分类、分步、分层。理清各部分目标，对一些事分级分类之后，每一件事你应该怎么去理解？包括我们当时最初提出一个观点是全职能团队，真正能全职能吗？不现实。比如业务部门离的就远就来不了，系统团队人家数据安全不参与，测试团队说我有自己的工作方式也不参与，所以全职能团队是一个相对概念。包括全站也是相对的，这样必然存在分工，那么要考虑怎么去分成？让各个角色在其中既能够配合也能发挥最大的价值。所以你的方案要考虑各方在这里有它自己的价值能够实现改进的目标，更直白的是要完成他的绩效目标。

从工具视角，业内有很多工具，而且每种工具都能找到不少的成功案例，关键是什么呢？ 结合企业情况看疗效别看广告。工具使用角色有那些，这些角色分别要达到什么效果。我个人认为整个企业都是人的企业，人的企业无论是DevOps工具也好，包括架构也好，都是为了配合人去工作的。最好的方案不一定是业界最牛的方案，但一定是当前最适合你企业的方案。我在内部曾经推过代码质量检查，按理说我们整个中心和各个部门都制定了自己的代码规范，现在我去检查这个东西，是不是应该很简单的事情。但是实际情况是执行的时候反弹非常大，这种反弹来源于你对员工的心里、工作的安排是否考虑进度压力、是否考虑他所在组织目标，这些事情是综合的。所以一个工具能不能成功，取决于你跟团队互动是不是配合的好，而不是一个工具本身有多牛。

从软件持续发布角度看，软件规模越大，部署结构越复杂，需要技术架构提供的支持越多。比如说支付系统、结算系统、计费系统，由于自身业务的复杂性，系统一般很庞大。这时架构设计上，要考虑模块化以及模块间的解耦、接口兼容，然后应用才能小布快跑，持续发布。

我们确定目标和愿景，分类分级分步把事情拆成小任务，每个任务大家一定会努力做好，把它做的最漂亮，肯定没错。但是问题是，每个部分最好等于整体最好的吗？现实情况你的资金、人力、时间都是有限的，这时候你就要系统性的思考，从整体去看一下这些改进点，哪些点是优先点，哪些点可以迟一点，这是团队互动的过程，能够让你做出这样平衡的依据有就是这些数据，也是我做数字化DevOps的意义，这些数据能够让你统观全局。你通过这些数据去观察，哪些点是最痛苦的，要改进！哪些点是大家总结出来的，事多钱少的没有愿意做，要改进！还有一个点，哪些是可以为企业竖立标杆的也要改仅！

有那些工作要做，完成每个工作的最佳步骤是什么，谁来做，环境资源有那些。对应就是ppt表格的列名称。“工程名称”“过程目标”“工程参与者” 与环境交互

                                                  

过程是分层级的，有组织级、事业部级别、团队级别。能较好支持devops建设，我建议流程建模要团队各角色工作过程这个级别。这里会遇到一个矛盾，就是流程会不会制约敏捷，首先流程能够让你快速进入状态，当然随着你水平的提高，流程也会表现出它的不足，这是就需要进行流程改进。理想状态是流程与你团队的执行力、知识体系匹配。现实是我们始终朝着这个方向努力，不过始终有些差距。

这里是一些对制定软件流程有帮助的规范。如果工作中有类似的场景，可以参考！

流程建完之后就是工具选型，这块具体工作好做，工具选型的时候要考虑管理因素、人员习惯、成本因素和技术因素。这里特别提人员习惯这个考虑进去你的工具推广才能顺利，如果不考虑人员习惯的话后面做起来会很难。

然后选工具的三原则包括效果、集成和自动化。效果就是让大家用着舒服，集成就是工具要具备集成到现有体系的能力。最后就是自动化，工具要组成发布作业流并具备唯一的正确出口。我们现在有的集成流程如下图所示。

 

在DevOps的架构里，大家说过有些东西工作中发现解决不了，那么系统要高可用容错。从长期来看多快好少是目标，你需要逐渐的把架构进行调整，一个是新系统开发的时候要考虑持续发布的需求。第二个是老系统怎么办？老系统怎么能持续发布，怎么能稳定的部署？对于这种遗产类的系统我们可能只是逐渐的改哪部分提高哪个部分，同时架构上增加负载平衡器这样的设计，这些都是架构上同步演进的过程，好的架构不是一下子设计出来的，它是和你整个企业文化和需求磨合的过程。

DevOps数据梳理：前面说了很多了，我们提到数字化，数字不是凭空来的，不是你造出来的，一定是对现实的刻画，但是刻画有一个问题横看成岭竖成峰，你的成本和时间有限情况下到底哪部分最重要？有两个办法可以参考，一个是按照数据分析思想，找出关键因素，对它进行梳理。第二个就是互联网大数据企业，不管三七二十一先把数据拿来分析看看。

这个图是网络拓扑图，我们从数据管理到测试管理，这些数据分析会给你带来很多意想不到的结果，哪些数据适合公开去讨论？哪些数据适合一对一的讨论？这就是你实施工具的一个艺术，也是碰到很多意想不到的摩擦或者是说不分析原因，在什么情况下怎么用数据，不是你的数据，是你的管理艺术。大家如果玩儿大数据就知道了，大数据不仅仅是量大，还要有多个纬度，只有多个维度才能接近全貌。

第三部分讲一下实施过程的概要，实施效果。

从最初定的三个方面目标，现在工艺方面做的最好，我们把敏捷引入到ISOCMI体系中去，形成了敏捷管理、而且是有规范的敏捷管理，然后就是工具，工具是为管理服务的也是为员工服务的，工具配套就是和中心流程相配套。最后就是X86技术这块，我们现在也有近千台X86服务器跑着一些分布式应用，逐步替换了很多大型级的设施。

主要效果：我们原来大概是半年（当然不这不是我们主观原因国家政策没变我们也没有必要变）左右发布一次，现在是二十多天就发布一次。这个图就是之前没有可视化情况下数据是没有规律的，有好有坏，大家看数据线现在慢慢变好了，这也是实施DevOps的结果。单个探讨一个项目上下波动很大，但是我们管理可视化之后，管理人员逐渐介入、引导，这块逐渐提升，所有的工具用户不仅是程序员还包括管理人员。

    最好，是我们未来打算做的一些事情。标准化、自动化这方面我们做了很多，现在尝试数据化，我是希望能够更深入的去发现一些问题，让我们优先级排列的更好，同时也实现精细化管理，而且在下一步的时候我们想智能化，怎么能智能化，没有数据不可能智能化。所以我们也为下一步打基础。

    谢谢大家！我就讲这么多，有些东西，我写到我的微博上了，请大家关注。谢谢大家！