顺丰运维平台建设之路

毕宏飞

作者简介

李杨

顺丰科技

前言

今天分享的主题是顺丰运维平台建设，以及如何带领我们的组织转型。先基本介绍一下顺丰科技，我在的部门是顺丰科技中心，负责顺丰整体基础架构领域规划建设，以及对应的运维工作。谈到顺丰科技，感觉是肌肉感蛮强的企业，很多负责任的快递小哥。对顺丰科技来说，现在的大中型物流公司，我们具备天网、地网、人网的信息化系统建设，先在这里讲两个比较有意思东西：

第一，顺丰科技自研物流的这个故事。今年四五月份频繁在顺丰优选买江西赣州运过来的土鸡，我和无人机团队聊了一下，每天4点钟的时候江西赣州深山老林里的大妈会把鸡屠宰掉，6点钟拿无人机送到我们的对应机场，我们在深圳每天下午4点拿到对应的鸡和鸡蛋。

第二，无论是设计研究还是生产都是在自己公司体系里面。全国做这块的有两个公司：第一个是京东，第二个是我们，我们现在运营指标的综合成本比已经低于了我们普通的。顺丰应该是全国第一个把智能手持终端引入的物流行业的一个公司吧。

我今天分享的主题是运维平台建设和运维转型，主要讲我们的思路，更重要是想分享其中的经验，以及我们踩过的坑。今天的分享主要有以下五个方面：

• 1、背景
• 2、起步的思考
• 3、平台的建设
• 4、背后的故事
• 5、进行中的未来

一、背景

我是2015年左右加入顺丰，站在2017年端口去看过去3年以来的发展。

2014年以前不用提了，IT系统建设没有什么可谈的，全部在2014年左右起步。当时顺丰内部系统有400多套，做400多套系统标准架构改造，对应的架构改造带来我们基础架构领域，包括其他资源池建设，以及对应的监控、容量、变更都是在这个时候开始起步的。

在2015年时候，我相信大多数运维人都会经历，但是都不想经历的事情，那就是我们数据中心搬迁。以及2015年真正完成了基于问题、事件、变更的管理流程。

2016年，我们逐步尝试做自动化运维工具，当时做了自动化运维平台。另外，基于其他这边我们开始逐步做自己的开源组件自研，初步建立我们运维研发能力。

其实站在这个端口，我们运维人蛮惶恐，本来很多数据想分享出来，很遗憾我们信息安全管控不能写在PPT上。大家对于顺丰的印象，第一是快，第二是顺丰物流服务靠谱，基于这两点，整个业务对我们运维人员很苛刻。今年顺丰有720套各类业务系统，业务给我们具体的故障指标，一年允许有20次业务系统故障，故障是怎么定义？15分钟以上业务中断就叫业务故障，可喜的是今年已经最长175天零故障，我相信在业内算是比较优秀。

外部压力有什么呢？阿里、腾讯或者京东对我们行业降维打击。另外，这个行业变化比较快，顺丰基本上能够做到与时俱进。比如去年各公司推自己的隐私电子化运单，顺丰也是第一个推出来的。很可惜人员增长20%左右，对运维压力也是蛮大。

针对这些压力和上面对我们的考核，运维人员是迷失的。手上事非常多，重复性工作非常多，搭建、迁移、扩容、批量变更、异常 处理占用过多人力。随着组织扩大，我们数据中心截止到目前为止有250人左右，分为很多专业组，这些专业组之间为了完成同一件工作沟通成本会非常高，我们是沟通人员，还是技术人员？

随着我们IT组建，层级关系往往非常复杂。双活、集群、负载均衡比较好做，但大量非持久化，基于数据库、缓存、消息队列、存储，这类型它的双活和集群管理是比较难做的，万一它的集群非多活机构，你去切换备机是否可靠有效，我相信这是全部运维人员的痛。有两方面对运维不够满意：一方面是我们研发，研发在2017年初告诉我们已经在一个云的时代的，所有的资源要求所见即所得，凭什么告诉我测试生产走流程，两三天以后才给我；另一个方面，公司对我们说每年基础架构拥有成本，你必须保持一个持续某某比值下降，这是双重的压力。

我们自己也总结出了运维人走向，当时总结也参考了谷歌、腾讯。作为运维人员我们背负一个十字架，这个十字架是什么，分左右和上下两个象限。

左边是运维去做的重复性工作，右边是运维人员往往想要做的高价值输出，往上是更像应用运维，需要更加贴近业务，往下则对应的就是数据中心，严格意义上算是云计算部门。应该更往下沉，往存储计算网络里面沉，来提供更快、更安全的基础架构资源。核心是把自己的琐事释放掉，体现我们运维的价值。

刚才提到了在2016年末，我们自己做了一个自动化运维平台。做得怎么样呢？

最开始年初规划目标，无论交付场景和对应切换、数据库切换还有其他方面的切换都做了，覆盖率百分之百，成功率也非常高。都说做运维自动化有用，我们遇到困境并没有改变，自己也梳理了一下，更多集中变更作业里面，所有基础架构我们能够实现百分之百覆盖。

更升华一层看我们具体工作流程，运维人员对外的工作其中三分之一是交付。单就交付这个领域，我们真正实现自动化只是变更执行的这一个节点而已，所以刚才讲的沟通协调，上下这种链条长度依旧没有达到一个自动化。基本作业我们还在一个自己所谓非常完善的系统里面跑，运维人员习惯接工单看邮件，这样场景没有改变。我们工作从研发提出需求，到自己架构去承接需求，到专业组处理需求，到最终用户的环节，其实一直没有变，我们只是上工具，没有形成体系和自己平台变革。

二、起步的思考

刚才讲了一个背景，这时候我们应该怎么去做呢？

我们思考了一下，从运维平台或者运维自动化开发来讲， AIOps 我们认为是智能解决阶段，可以逐渐解放运维人员的手，接下来是眼睛和嘴巴，解决我们沟通问题，最后是我们的小脑，小脑把运维规则沉淀到自己运维平里面去。最重要还是建立自己运维体系的规则引擎，最后达到智能运维。

有了这样的想法，我们也遇到了困难。刚才提到今年顺丰内部有720套业务系统，这些业务系统有很新的东西，内部新系统用新组件满足业务需求，还有一些老的系统，虚拟化软件、存储或者其他的设备，这个我们没有办法剔掉。很多公司运维自动化的起步是在新的业务系统里面做，如果我们也采取这样策略，对于运维价值没有带来根本改变，还是把新老系统通过业务逻辑抽象实现。

运维人员要什么呢？以运维角色、运维场景的视角集成现有数据，形成有效信息，将现在靠管理人员分析的运维规则，置入运维平台，驱动运维。我们自己的业务逻辑沉淀没有统一，面对每一种日常运营过程中的场景，需要在不同系统之间去切换，大家感受非常的差。

三、平台的建设

谈到平台建设，首先是建设目标，当时我们运维的几个核心人员通过差不多两个月头脑风暴讨论定义下来目标。往上的宗旨实现可编程基础架构，无论什么组件或者其他很重的，例如服务器上架或者像网络开放工作，又或者最轻的可能是一个网络引流或者DNS都要实现可编程。

往下有四方面业务目标需要实现：

• 第一，效率提升，无论交付还是作为数据中心部门，要向应用运维和研发交付的服务资源，需要提供自助化。
• 第二，质量提升，我们提供出来的一切资源和服务应该是标准化的，逐步拒绝口头沟通和流程上派单。
• 第三，全栈运维，我们自己内部720套系统，让运维人员实现全部运维和数据中心进行解耦，让他们拥有权力完成他的运维，我们基础架构部门变成云计算和云资源提供部门。
• 第四，信息共享，这是运维人员一直的痛点。运维人员核心职责应该是三个：安全、成本、效率。这些信息我们希望通过一个平台逐步提供给研发，以及像我们CTO的部门。

4月份做了一个对应的系统架构设计，这个设计基本上分四个模块。最左边是资源及服务申请窗口，这个地方是我们研发的，通过架构图和表单自由申请资源请求提供服务。中间部分是整个资源分配模块，这个模块只是一个概要图，它可以横向来看，横向来看往上是我们每一种资源分配规则。以往没有做自动化的时候，我们假设一个数据库管理员，由我们业务方提一个单过来需要一个数据库，脑子里面想什么东西呢？它所要的区域有那些集群，哪些集群空闲，落到哪些机器，业务系统什么业务属性，是否与它相近业务系统分到同一个相近的。资源池管理，平时分配这些逻辑看系统数据，你需要看监控、查 CMDB ，查架构图管理系统，对应数据直接抽进来。

资源分配可以竖起来看，中间左边是标准的基于这个基础搭建的资源池，我们自研的虚拟化平台一样，它没有自包含的规则引擎逻辑，我们需要平台侧帮它实现。再往右看，当这些规则引擎通过计算以后，需要统一的编排管理，把所有基于数据中心的存储计算网络资源给编排到一起形成统一服务，再到作业执行端。在前几年自动化平台处于百花齐放时候，我们做过一些纠结，在这些里面来进行选择。

我们现在以一个作业编排为核心，建设自己统一作业平台，支持数据中心全部基础架构组件，包括网络、数据库和中间件。我们已经建成顺丰通用的作业标准原子服务库，这个原子服务库基于抽象、不可拆分等一些脚本，与对应输入输出的接口。抽象出来无非对主机管理、原子操作管理，对运维作业和文件的管理。

坦率来讲类似运维平台大家差不多，对于自己业务呈现，我们和其他家不一样。我们采取的方式是以用户有价值的视角来编排我们所有作业。

对于我们来说，以这张图的这种标准为例，对于用户有价值的东西到底是什么？我们做了具体需求分析，对于用户或者研发方有价值，系统程序运行容器的资源，以及像数据库存储。其他组件基于网络、操作系统、防火墙，把它给编排起来，提供他们真正关心的东西，而不要把他们不关心的，像刚才提到的其他组件报给他们。

第一，用户可以自助提需求;
第二，研发方自己的 DevOps 平台，可以跟我们做平台对接。

比如先录入 CMDB 架构图系统，再看资源池使用规则，调度对应组件作业执行平台，再来做它的对应信息反馈。

去年年末，基本上所见即所值，跑出来了给他什么。运维、研发对于基础架构部门要求是什么，申请对应系统的权限等等，在一个平台里面可以给他提供完整的支持。对应这边基于自己研发，基于 KVM、VMware 等资源全部编排进来了。

四、背后的故事

介绍我们平台建设效果，背后东西更值得聊一聊。大多数企业做运维自动化，做运维变革都会踩过不少坑，这些坑往往更值得分享，避免其他人踩下去。

4.1 起步的仿徨

• 第一个，在起步时候是自研还是外购？中国市面上能买到的大多数自动化运维平台感觉都差不多，由于顺丰是传统IT架构和基于互联网形态IT架构并存的企业，我们做过自己分析和对外分析，如果对企业软件进行二次开发，它对我们开放部分代码或者商业协议方面处理会非常麻烦，更别说持续适应性。自研可以快速满足我们的业务需求，如果和其他厂商合作则比较被动，所以最终决定成立自己的研发组织去做这一块。
  

• 第二个，刚才介绍了四个具体业务目标，但是当四个具体业务目标拿到整个运维部门手里面时候，可以很清晰地看到一个现象，最高层像CTO、运维总监，他们关注点可能是运维对外的服务价值输出，需要你的交付和一些基础服务；对于团队组长来说，他可能关注更多是信息流转，获取自己部门内部和其他部门信息；对于基层管理人员来说，给我一个方便和好的作业环境就行。怎么统一运维平台建设优先级和步骤，提炼自己后面通行规则。拿到一个具体业务宗旨时候，看一看可执行业务目标，再看实现这个业务目标需要实现哪些具体业务场景，这个场景拆分每一个业务活动，再把这些活动转化为我们系统功能。统一运维部门认识，可以完成两方面东西：做什么事？怎么做？也方便后面需求和产品人员梳理他的业务系统，他到底要干什么东西。
  

• 第三个，刚才解决了整个团队做什么事情，现在怎么做的问题更棘手。运维部门最不缺的是运维人员，也不缺运维人员提出的运维自动化需求，但是这些需求是没有经过一个抽象分析以及处理，它没有办法直接转化给研发部门。无论基于外招还是内部调配，开发人员在市面上对运维组件有基础了解的是少的，市面上最缺的人才是什么？是技术性运维，有产品经理思维的产品经理角色，但是这种角色，市面上招了很多次也没有招到。运维人员不会提需求，又招不到运维合格的产品经理，只能自己培养。先固化具体业务活动，哪些需求有架构支撑可以直接研发，哪些需求做需求穿刺和固化流程，先把我们每一个职责对应的位置做的事情固化下来。另外，容忍我们的缺陷做一个迭代优化。
  

4.2 途中的挫折

当平台建设解决“做什么”和“怎么去做”问题的时候，平台上线以后发现更加严重的坑。最开始我们在2015年、2016年，自认为已经完成基础环境标准化，但是平台上线以后，发现最高一个服务作业成功率只有80%，这样一个系统平台功能绝对不能给用户使用，只能重新做基础环境标准化领域。

我们用一年时间做这个事情，从三月份做到六月份，当时我们一个组的组长很兴奋跑过来，“李杨，我们OS变化达标率已经达到98%以上，一万机器98%还不够吗？”我告诉他，基于我们标准化给用户最有价值产品理念，一个数据库18步，这18步成功率都是98%，98%的18次方乘一乘知道最终成功率是多少吗？通过一年努力我们踩过的坑可以得出一个结论，没有基线建设标准化都是耍流氓。

从现在来讲，每天14次基线检查，发现不合规就把它修复回来。过程中有很多场景，你的数据库因为硬件服务器损害了等等行为，基线检查被破坏，基线随着运维场景和运维不断发生变化。

4.3 运维模式的变革

解决平台上线和成功率问题之后，逐步带来运维模式变革。突然发现被我们服务了N年研发和运维部门一直在忍受我们，之前每个月差不多会提供给外部的资源是1000多，当我们平台成功率解决后对外输出的时候，人家要我们服务请求快到需要一线机房小哥天天通宵加班，到了这种地步怎么去解决？

工具方面打通运维最后一公里，当时成功率还可以，最终和运维平台做了一次对接，真正形成服务器硬件资源的二次调度，形成了一个二级缓存。当具备二级缓存时候，假如这个资源比较闲，另外一个资源比较忙，就会把数据库平滑切到另外一个集群里面去，把这些集群下线，自动调度一个标准集群提供给用户服务，这是工具层面。另外一个是资源运营层面，例如基本的收费，服务收费。但是我们做了一个有意思的东西是数据管理平台，把一些规则植入进去。发现有一些项目组比较有钱，举个例子，上个月发现预算比较充足项目组，两周之内申请800个对应架构组件很奇怪，通过我们数据平台查看应约的规则，比如这个组件两个星期内有没有登录过，或者应用进程有没有重启，发现分配800个里面，其中260个接近两个月在那里睡觉，我们通过资源运营这种理念解决我们内部的资源需求问题。

通过运维平台建设可以看到，我们在2014年已经整理出来并且完善了顺丰基础架构模板，通过标准化模块进行建设，无论对于基础架构，还是应用架构都是有利的。

到目前为止有30多个标准模板，这种模板推广一次非常差，上线以后可以看到研发领域，他会体会到申请非标准资源和申请标准资源完全不一样，哪怕标准需求满足不了一些业务场景，他们也会跟我们做这样沟通，能否更改一下你们标准，某些参数和某些组件。

还有一个最大的感受是在我进公司第二天拿电脑入职，当时已经被加入群组里了，收到邮件上千封，其中一半各类系统告急，另外一半各个组之间沟通流程。当时基本协作靠这样的体系、靠邮件。

现在的口号是让我们各个专业组老死不相往来，你要找我可以，我给你提供API自己来调。坦率来讲这也变成一个问题，整个运维平台之间，无论业务架构、应用架构，还是我们数据架构，以及我们接口标准变得异常重要，无论基于灰度、测试，还是基于接口等其他东西变得非常重要。其实现在基本上形成了一个中间对外提供服务的平台，以及相对应的数据库，搭建分布式的管理平台。

五、进行中的未来

接下来讲一下我们正在做的事情，顺丰通过类似于AI技术去预测。我们有700多套系统，核心业务系统自己归类，差不多占120个，这120个按现在研发和测试运维能力，没有办法对每一套系统全链路压测。我们对应的做法是建立一个模型容量管理工具，这块可以看到分析全部系统，这个系统它与我们业务量是强相关、弱相关、干脆不相关。基于这套系统，做了相对比较完善的容量管理平台。

现在建设对外集中的作业平台，刚才讲述过程中是对外输出资源和服务，对内我们更多是变更。我们不希望应用管理人员直接登到服务器上做操作，这种操作严格受限。在平台里面封装你所需要的场景工具，这些工具只能牵涉对应的修改和删除工具。我们也是有对应的，第一执行机器数量限制；第二锁定脚本模板和所能提交的变量，这样来做安全管控。

另外，对应甲方公司面临一个问题：容灾。这边用数据平台做了一个容灾管理系统，做到生产容灾和压测环境架构一致性的比对。

之前顺丰 Docker 加马拉松构建，现在也能看得到，让它跑微服务或者标准解体也可以，原生的组件太少，基于这个去构建私有云，对应我们研发体系，有另外研发的运维去负责，我们需要做全流程打通。整个容器目前规划把所有非持久化组件放到里面去，刚才这套编排系统与它构建交付平台。这边三四个层级规划，平台管理层发布所有基础架构组件能力。数据库和存储部门，可以在我们部门挂研发和业务开放给他的组件。应用运维和开发人员，正在建设基于K8S用户侧的平台，这个平台应该今年3月份正式对内部推出。

2014年，我们基于两个维度：第一，底盘资源；第二，基于应用资源维度在80%左右。近几年我们上了自己的数据平台，它本身具备多种算法匹配能力。我们与业务运维人员，把哪些应用场景与CPU、流量、内存，其他资源相关，这些模型进行调试，对应高峰期，评估这边做得比较好。