顺丰私有云团队的DevOps之旅

白凡

分享：周辉-顺丰科技云团队
编辑：白凡

讲师介绍：首先感谢赵班长暖这个场，我自我介绍一下，我叫周辉，在这个行业做了18年，在2000年参加工作，2002年正式做运维，现在顺丰工作，顺丰这家公司IT是大集中模式，除了有特别监管的区域以外，比方航空、金融，其他的IT都是顺丰科技承接。

今天我跟大家分享一个内容，我近三年每年只分享一次，为什么呢？因为觉得时间太短积累太少，分享内容有限，所以我坚持每年给大家分享一次。

1. 我们的团队

首先介绍一下我们的团队，实际上这次讲的内容，可能不会涉及到某个具体工具、某个方法，如果是关注这方面的同学们可能会失望，我们要讲的实际上是运维团队在一定规模之下，当它遇到自己的瓶颈决定把自己整个基础设施和服务进行云化自动化的时候，你要展开自己的研发工作，你该如何展开？你会遇到哪些问题。整个过程是我们自己团队的经验，每家公司情况可能不一样。我们团队负责整个顺丰集团基础设施、规划、设计、实现、运维公司，我们系统的运营也在我们的大团队里面。

当然我前三年也就是2016年之前个人比较偏向在基础设施这块，也就是机房、网络、存储、数据库等方面的管理和运维工作，后三年在做顺丰私有云以及自动化的研发工作，我这次分享后三年我们曾经做过的事情和遇到的问题。

2. Only Ops

最开始我们第一个形态只有运维，2014年上半年的时候，完成整个配置管理的监控的建设，这样的一个点，你把你的运维工作知道你运维哪些东西，用途怎么样，你的配置监控有没有起来，整个IT运维工作才可以进入到一个比较有序正规的状态，我不知道在座的同学们你们当前所在团队所负责的这些系统在怎样的状态。

在2014年下半年的时候，刚刚完成整个架构的标准，因为以前我在2016年的时候曾经分享过一个PPT，那个时候我就讲了我们刚刚做完整个架构的标准化。

在2015年上半年刚刚做完技术全部开源，把所有软件在我们整个组件剔除掉。今天我要讲的故事就是从这个点开始，整个OS之前的所有技术里面都是开源组件，之下的基本上我们开始除了网络以外，不管存储还是服务器，我们开始把以前的中高端存储慢慢开始做。

为什么要做这样的事情？我相信在座的同学们你们的团队或者你们所在的公司到一定规模的时候都会遇到这个问题，就是运维的规模会快速增长，第二个就是你所服务的对象也会快速增长，用户规模是指你所用的所有对象和组件都会飞速增加，你服务的对象是你所服务的人群，比方说研发，实际上顺丰的研发从我们之前的600多人到现在的快6000人了，如果不改变的话，日常各种操作带来的失误会越来多，同时你对外的服务质量会快速的下降。

大家都在讲运维压力很大，你要各种压力都要面对，工作不能靠人来堆，人永远犯错，而且越忙越错，所以我们开始自动化，不能靠人。

3. OPS + Dev

所以未来做这样一个事情，我们就做了一些事情，是什么状态呢？大家看一下，实际上最开始的自动化是很原始状态的，有能力有意识的同学会写一些脚本，来把自己手头上的工作做自动化执行：

• 第一他是自发的，也就是说有这种能力的人开始自己玩
• 第二是零散的，他没有规划，自己熟什么就做什么
• 第三是他不受控的，同样一个自动化脚本，可能在其中几十台机器顾了，另外几十台机器是没有顾的。然后就是只解放自己的，先让自己轻松一点
• 第四就是偏末端执行的，相对完整工作流而言，最开始的自动化是我去做数据库的创建是自动化掉，是非常末端的，没有效果。

企业业务端不停增加，你要运维的对象规模也在飞速增长，当时我们的增长速度每年50%以上，所以这个时候并没有解决规模化的问题。

还有一个大的问题，那么多运维对象，那么多人开始做自己自动化的东西，实际上存在很多问题，第一容易出状况，第一今天写一个脚本，第二天发现这个变更做完了，结果过了几天又发现这个错误出现了。第二就是团队大了，人多手杂，这个脚本传来传去会产生当初不是预期的效果。这种自动化很容易爆各种雷出来，我们从最初的工作到最后就是身受其害的。

自动化的工作是一种研发工作，它必须要推算起来，必须受控，不然它会有规模性的破坏，自动化的东西反面是一旦有问题，它比人干坏事干的还快，比人干坏事的规模还大，我曾经就遇到过。第二它可能带来一个安全的问题，可能是信息安全、运维安全的问题。

4. OPS << >> Dev

这种情况之下，我们怎么办？我们说不能这样玩，我们要找一个真正的玩法，我们在2015年年中成立研发团队，研发团队没有人，我们就招，不管研发主管还是工程师都是外面招的。第一就是外面来的团队，这些人从外面来之后想要做一些新的东西。

第三是玩产品，这个东西我们实际上后来发现他们在这方面不是很擅长，只不过想用想学，借这个过程积累新的经验，这种团队很坚持，他们跟其他团队沟通的时候非常坚持自己的想法，所以这样的结果就出来了，我们研发同事以为我们是来帮助你们的，我们是来解放你们的，他们讲的东西，以前运维团队没有进入研发的工作，对他们的用语根据听不懂，运维团队来讲，研发团队是独立在外的，你做的事情跟我有什么关系呢？

我当年的KPI都是我自己的，你做的事情只不过是我帮你锦上添花而已，第二个你们不懂运维，你们只会研发，你们知道我们要什么吗？你们能遵循底层的研发工作吗？当时的气氛是非常诡异的。我们当时研发团队有一个任务，说我们要做自动化工作，所以不得已运维团队必须进来，所以许多我们运维同事学这ruby语言，前台用Chef做，后台用Java做。

Java实际上在整个行业存在几十年了，但是我们同事学这个东西难度也非常大，做运维的同事们习惯做操作性的东西，真正写系统性编程的时候，当时遇到很大困难，所以整个进展非常慢。

搞了半年，没办法，有任务，有目标，有时间，有工作项，也有职责，结果就是这样情况。原来期望正规研发团队进来，与运维团队进行互动，但是没有很好的效果。这半年大家的气势都非常低落。我们当时在整个组织的模式上、方式上、能力上、技术上、方法上，看起来没有形成自己一套完整的有序的研发团队的能力。

5. OPS + DEV + Project + EPG

实际上到第二年过完年之后，我们就决定进行改变，进一步召集大家一起头脑风暴分析这个问题，当时人会讲真话.

• 第一个问题责任问题，责任没有分清，甚至会出现相互之间踩踏
• 第二权力实际上没有分配好，人员有冗余，不管开多少次会都没有结果
• 第三利益的问题，这个问题俗一点，但是在职场中是非常核心的问题。运维和研发要做自动化必然会导致工作内容的转移。
• 然后就是成长期待，有的同事很精明，他们从中看到了期望，所以希望自己多做一点，希望能得到学习机会，但是就有问题出现，你想做这个，技术方面没有交叉经验，双方没有对方的经验。在方法上，也不得当，赤膊上阵是源于三国曹操和马超对战的时候，大家没有方法往上冲，所以前者中箭。

最后我们对所有东西进行厘清，首先要把要做的事情搞清楚，如果你要做企业规模的运维自动化有点类似于说私有云这种模式，首先你要做到整个交付工作至少能够全流程自动化。

• 首先我们做拆解，在底层基础设施方面，你的计算资源、存储资源、网络资源以服务方式提供出来。
• 第二如果你要做全流程工作打通，如果大家在座的有的做运维，你们曾经帮别人搭过环境，首先公司大，要有分工，整个工作是非常漫长的，你会发现在这种规模团队中手工作业要等半个月，所以编排解决全流程的问题，你资源的部分已经变得可编程，上游能够把全流程进行衔接贯通自动化的东西，这是一部分工作。

上面对于最终的交付部分而言，如果要做到终端用户能自主进行资源提取的话，你的各种组建你必须有一个件给对方。所有做了这样的划分，第一基础设施可编程，有关计算、存储网络资源、系统组计算资源、存储组存储资源、网络组网络资源，必须以服务方式提供，让上级进行调取。

这个时候运维团队必须有自己研发能力把这部分借口以服务方式提供出来。第二是编排部分，交给研发团队，涉及到更复杂的编排和设计工作。研发团队做上面两部分，运维团队做这部分。这样来讲，我们讲责任分清楚了，技术部分来讲的话，技术用Java团队做，方法部分来讲的话不要强求一模一样，运维团队自己传统定一个目标，把范围圈进来，制定一个计划跟踪就可以。

研发团队可能是之前是专业做研发的，他们习惯用敏捷，那自己用就得了，但是他们任务衔接性非常强，私有云涉及所有组建的话，顺丰有八九个团队，再加上我们平台研发可能有八九个团队，这样必须有项目组进行协调，做目标统一管理，当时我们在起初的时候有一个项目，同时对项目管理方法而言在整个团队做了一个把责任定下来，试这个方法行不行，这样来做，所以我们平台研发团队当时有30人，各个专业组的研发团队都在5-8个人，甚至有的有3个人。

同时也做了更细的职责分工，项目设了项目经理和项目助理。第二整个系统的设计，尤其是平台部分，包含编排、工作译服务界面，我们交给系统SA，项目管理交给PM，平台研发在研发团队，原子服务研发交给OPS，以服务形式提供，必须由运维团队做。

分析下来之后实际上大家到五一之后我们第一个版本就出来了，3月下旬把需求确认清楚，4月初设计和研发，4月底交付测试，5月上旬用户验证，5月下旬做了第一个生产发布。第一个生产发布达到初步效果，基本上都可以做到用户自己，当时我们的架构是研发资源的，他们可以自助式来工作台上进行资源获取，这种获取模式可能很多很多企业最开始的第一步。

但是还有问题，刚才讲的进展部分，实际上从三月份到五月份实际上有三个月，你一个迭代做三个月的话，实际上整个迭代周期比较长，上线之后小毛病比较多，这个时候又回去看问题，看到更多的问题还是运维和研发在沟通用语以及对方工作方法、工作内容的理解上有偏差，我们坐在一起进一步厘清这个目标，每一个迭代每个工人要做什么，需求方、运维、架构师有没有和我们达成一致，沟通过程中存在不存在讲同一个用词，对方想的是另外一个意思，用语是不是互通的。第二就是方法科不科学，真正一直做研发的同事对这个不模式，刚开始做研发运维同学们那个是很痛苦的，搞不清楚，也不知道该怎么表达，还有问题要透明，当时整个问题管理存在蛮多点对点需求，没有把整个透明给项目组。

这个时候我们又做了一件事情，这个事情当然了就是第一个我们请到做了DevOps培训，当时是赵班长给我们做的培训，我们正规研发团队有软件工程团队专门帮大家做流程和敏捷的团队智能顾问式的。当时的目的是希望我们研发工作能够更高效，第二希望我们的运维同事能够有科学的研发工作观和理念。

这个事情做下来之后，我们的顾问和导师给我们做诊断和分析，最后看出我们对标一下整个DevOps而言，我们还有哪些差距，我们看运维，第一是组织文化这部分，实际上我们看我们自己的话，实际上我们整个团队是没有理解这个架构标准的，第二就是团队合作这部分，整个团队合作的沟通是否足够顺畅，协同是否足够好，我们是不够好的。第三是研发过程中构建与集成部分有没有让系统做，实际上很多都是我们全手工。还有交付与部属、测试是全手工的，还有周期质量管理这部分，大家忙于交付，不出大的问题，能用就行。

我们做了一个计划，这个计划就是说首先承认我们这个组织刚起步，你就是这么差，那怎么提高呢？所以我们分了三个部分，第一在组织文化团队合作部分让一个组织进来给我们做敏捷导入，到今天为止已经跟了我们一年半了。第二在项目部分，我们引入研发工作自动流水线，在构建机制测试部分希望以更好的工作方法。在质量方法我们希望运营工作做的好一些。

我们抱着非常美好的愿望做了这么一个规划，起了支线任务，这条任务在私有云研发之外的，有另外一个小团队专门辅助大家，慢慢的听大家很多声音出来，第一个声音是大家都这么玩的，你为什么要搞一个新的东西出来，我们想去看这个东西，大家都这样玩就是好的吗？第二就是有的同学不止一个，说现在的方法已经很熟练了，你搞一个新的出来，又要花时间和代价学，但是问题的是熟练就是真的高效吗，实际上不能画等号，然后就是我都很忙了，还要搞新的要学，实际上很多都是这样的，有的同学就行而上学，搞得这么形式。这些同学没有清楚这种形式背后到底代表什么，可能会给大家带来什么好处。

怎么办呢？不可能把大家头按在那里一定要搞，搞IT不能那样搞，当时做了一个决定，就是找一个懂的团队，把这一切做起来，再通过数据和事实说话，告诉他们这个懂的团队在做之前、做之后的改变到底是什么样子的，当时我们就找了平台组的组织团队，他们有基础一些，就把它给做下来，做的过程也是蛮坎坷的，因为基础比较差，做完之后慢慢看到一些改变，第一迭代变得更有节奏了，最开始两个星期，后来觉得两个星期对我们这种形式的研发来讲还是紧凑一点，所以调整三个星期了，基本上每次迭代进入的需求都能够按时完成，交付质量也有提高，上线之后你的BUG是否有下降。第四沟通成本下降了，尤其是我们的顾问和整个需求的结构化、需求的环节做的顺畅之后，这块的效率提升是比较明显的。

我们是怎么做的呢？基本上我就不细讲，今天大家会听到按照很多，在自动化工作流会有这样的事情，实际上这个东西做起来应该是很简单的，对于一个真正的研发团队不管去到他些公司把这些部属起来不难，我们发现跟运维兄弟推这个东西很难，一个最奇葩的现象让他们做，他们去做了，做完之后就放在一边，问他为什么，他就担心，他就说这玩意靠谱不靠谱，会不会存在问题，运维的思维相对来讲关注风险，更关注是否有问题，而在效率这边可能还不会考虑风险，做运维的人风险意识太严重。

实际上我们当时遇到了很多状况，大家做这么多事情又很忙，压力很大，有时候同学们压力比较大的时候就会情绪也不太好，所以后来我们的顾问就跟我们讲说可以很忙可以很紧张，但是大家整个思想之上不能压力太大，所以我们整个团队也在内部做了沟通之后，决定让氛围轻松一点，所以给大家宣导DevOps文化，第一不要责怪人任何人，帮大家分析问题，解决问题。第二领导也有领导，真的有问题，万一达不到预期，一起担当。第三就是同受益，也就是说在整个工作当中你会遇到利益分人，我们刚才讲过会发生工作内容的转移，从整体来看要一起来，每个团队都能够有利益可想。

经过这一轮调整之后，我们的变化就这样了，黄色线是我们种子团队的变化，整体来看是效率提升的优势。测试部分，我们转测以及通过率实际上都有提高。实际上经过了这轮整理之后，又过了半年，也就到了2017年年底，我们回头看基本上我们在2017年年初定的目标都已经实现了，这个实现的直接效果就是说以前你承诺给用户的整个交付，我们以前只敢承诺5天，最快5天是我们的极限了，所以资源的交付5天，现在不一样了，以前要N多团队进行协同辗转和相互移交，做这个事情之后我们用户可以自己在工作平台上无障碍进行资源提取，这就是当年的价值的兑现，也就是我们大团队对这个工作的价值兑现部分。

工作一定会有的，事情如果真的没有了，工作也没有了，我们就失业了。实际上到第二年的时候，问题又出来了，刚刚讲了之后，大家觉得还不错，搞这个事情能让工作变得更简单，不管用户还是自己运维团队都觉得还不错，所以大家疯狂提需求，大家可以看到右边这两个图，上面是需求的增量，从最开始的没有，因为以前不知道还可以这样，大家发现还可以这样的时候，各种需求来了，我们可以看到二月开年一直到现在需求一直持续增加。需求来了之后就要人，我们的团队实际上从最初的几个人到后面几十个人到现在，实际上整个顺丰私有云团队如果把专业组研发团队和平台团队人员算上接近100人，队伍大了之后，协同、交付、质量重复的工作会做的越来多。

我们又做了一件事情，组织能力要进行重构，我们发现项目很难达到组织和协同的目的，第二就是引入产品经理负责制，我们希望增加每个小团队作战能力，地三是统一需求管理，消除重复性作业，第四测试资源和能够服务化，很多专业组做底层开发的时候，整个研发质量会出现状况。

另外一个就是怎么做这些事情呢，我们做一个能力复制，我们之前种子团队所有的经验，开始向专业组推。第二让请我们的顾问协助我们规模敏捷。为了做这种规模敏捷，和我们一起设计了一套工作流：准备、调研、制定方案、培训、实施与优化。整个来讲，专业组同事响应很积极，也参与我们的培训，反馈也很多。你做的东西不是我想要的东西，你要返很多次工才能达到我想要的东西，这是理解和设计的问题，尾端就是你设计的没有错，为什么用着用着老是有问题，这就是交付之后的质量问题会比较多，这个时候出现最多的是一个首一个尾，有关迭代效率的部分反而稍微少一点。

我们做了三种队伍设计，我们的平粜就是我们之前种子团队，他们已经授予敏捷工作的，第二就是A类队伍是指专业组织里面大于5个以上的研发团队的，他们来复制这种能力，还有一类就是团队比较小，相对两三个人，这部分我们不强求做敏捷，但是在整个研发工作是可以进行导入的。

泥沙俱下，你会发现要求研发搞架构标准执行，我们发现运维做的系统绝大部分符合标准，第二组建非标非常多，第三我们没有做运维手段，系统随时挂，这个很有意思，大家可以反思一下，自己做运维的，本应该是我们的强项，但是我们做研发的时候，你可以一切都不管呢，研发同学知道你这样搞，那怎么玩，你不能要求我了，你自己都是这样子的。

实际上这个现象我们发现之后，可以讲通过导入自动化的工作流水线，这些问题可以被一一的翻出来，并且进行整改，并且达到一个标准高效的一个要求。整个过程来讲，实际上我们现在一还在搞，我们从今年年初开始做这个事情，现在还在走，发现一点问题改一点走到今天，虽然难一点，但是我们发现这些点点滴滴的改变还是很有意义的，专业同事有一些感觉，这个快多了，你的监控满满起来之后，你发现别人找你的次数少了，因为你会发现你的系统变得稳定起来。
走完之后，今天讲这个事情，这是我们当前的收获，也就是说我们在各个层面：资源层面、管理层面、安全层面都有新的产品进行交付，而且在整个IT范围之内，你的研发、基础设施、IT服务交付能够形成完整的工作闭环，提高IT团队的作业项目。
右边部分就是我们整个今年交付的一些产品，包含有关容器、虚拟集群、集中作业平台、网络工作自动化、数据库集群，今年也自己研发了APM应用性管理系统，可能晚一点我们可能会开源。
效果部分来讲，做运维看这个事情就是成本，你的成本是否降低了，第二我们看效率，这是不是根本带来了完整的工作流，工作场景和效率的提升。第三就是质量，用户比较关系，这个质量体现你由于做变更带来人为的失误带来的异常会减少，到今天为止，基本上失误率是为0的。安全部分来讲，大家容易理解，以前靠人来做，会有一些错误。
我们复盘，把之前情况对标了以下，组织文化、团队合作、构建与集成、部署与交付、测试、质量管理都有大的提升效果，质量方面，我们当前真的狠抓，一头一尾，尾是我们正在抓的部分，我们发现整个运营体系和运维体制还没有系统性的建立起来，这部分是可以快速来做，这是运维团队强项。
最后来讲，是不是很好呢？实际上我发现永远没那么好，我们当时引入产品负责制一个副作用到今天没有完全消除，我们发现自己的运维人没有产品思维，他们永远只是关心自己的业务，无法进行进一步设计提炼。用户提序曲也是提的越来稀奇古怪，原来主流提完之后，他们的需求更边缘化。很多部分是迫于产品进步压力，不停发布版本，但是质量不能有效进行保证。第四我们的专业团队还是不太好，做运维的同事主业在运维上，屁股点点脑袋，他们做运维的事情，然后做研发的事情，这块的效率和质量达不到我们的预期。这就是当前的一种状态，当然所有的事情不会停止，我们会进行新一轮优化当中。今天就分享这么多内容，因为我讲的东西可能更宏观一点，不一定适合任何工具和方法，但是任何一家公司想做企业级的，这样能力都希望趟一些坑，希望我今天的分享能够帮助你们。谢谢你们。