顺丰IT运维转型最初的一公里（IT运维的救赎--顺丰运维的理想践行）

wt

理想总是要有的，万一实现了呢，理想有多大，我们就能一起走多远。在实现理想自由的道路上，我们描绘蓝图踏出探索道路的第一步，未来不是梦即使是梦我们也要穷极一身作完这场梦。

顺丰科技简介

顺丰科技是顺丰集团IT业务的支撑单位；为顺丰速运的定向IT服务商，专注于物流行业信息技术的研究、开发和运维，以信息技术引领业务创新。目前的团队及业务规模如下：

1. 专业技术团队：2000人；
2. 数据中心：3个；
3. 大中型系统：230个；
4. 海量交易数据：PB级；
5. 网络分支节点：12000个；

顺丰科技发展与演进

顺丰科技发展经历了三个阶段：

• 阶段一： 2010年之前，是技术的起步与积累；将关键业务线上化，实现路由跟踪和呼叫中的下单。通过业务的线上化来了解业务环节的质量、时效；从而提高用户体验。

• 阶段二：
  2010到2014之间，是业务快速成长时期。主要是新技术与“新应用”的爆发。

• 阶段三：
  2015到现在，是共享经济下的技术创新。更多的是通过互联网技术的发展、云以及AI的运用来支撑业务；进而让物流使生活变得更便捷。

破壁之旅

快递行业的业务流是用户下单、快递员收件、物流中转、运输、派件和支付等多个部分组成。一个快件成功投递背后是无数系统来提供服务支撑的。而这些系统构建过程则是一个很有趣的故事。下面我们将分为如下七个部分为大家娓娓道来。

一、运维密室

我所在的部门是基础架构，有的也叫数据架构。从分工来讲是严格的专业分工。从底层基础设施；机房到网络、到存储、服务器、操作系统、数据库以及中间件，每个专业领域都有个专业团队负责运维工作。这样每个运维工作都包括规划、设计、建设、实施以及日常运维。长此以往，结果就是责任氛围浓厚；这样一来就是大家都往往怕多做事情。

我们培养很多专业人士；专业网络规划师、专业系统管理员。但是问题发生了；我们IT有两千多人，而网络管理员不足二十人。这个时候你发现研发需要专业支持和服务时；你的人力是不够的。壁垒也就这样形成了；同时也带来了两个问题。

• 其一：视野天花板，所有团队在整个过程中接收到的信息都是碎片的；它只能在这个信息的基础上进行工作和判断决定。

• 其二：能力碎片化，没有一个团队有全栈能力；也没有一个团队能够俯瞰整个中心或者部门的工作。

密室之外

现实是什么样？我们面临的整个业务形态不断在发展。第一，流量峰值是一年比一年高；尤其是双十一。第二，业务形态越来越多。以前更多可能是我们自己企业内部用户在用的各种系统；现在出现各种面向直接的终端用户。

在技术方面，云的出现会颠覆很多人认为的自己专业和价值。其次是技术的开源化会让很多现有的技术专业成为鸡肋。例如，2002年的时候甲骨文的OCP认证基本上是个铁饭碗了。但是现在来看继续采用甲骨文的公司会越来越少了。技术开源会让原有使用商业软件吃饭的专家感到危机感越来越重。

二、运维审判日

我们对运维做了四象限分解，如下图所示。从四象限图可以看出右象限是我们可以给外界提供的专业服务；同时右象限也是外界最认可的工作。而实际上我们运维团队七分时间都在左边的工作；右边的工作只有三分时间来做。
基于运维工作的四象限分解，我们总结了五宗罪：

笨重的熟练

对于建数据库我们工程师非常娴熟；但是这些工作非常多，所以它很重。我们都在做这种类型的工作；基本上一个工程师做两年就麻木了，不太会独立思考了。

被降维的效率

实际上很多工作真正做只需要5分钟；但是从用户需求提出到层层审核，一直到交到用户手中可能是15天。稍有点规模的企业都会有自己相关的流程、制度，这样下来一定是以天来计的；实际上用户非常抓狂。透过现象看本质，大家更多的是沟通和等待；实际工作的时间只有五分钟。

内视的黑洞

我们运维人员大部分属于这种情况，非常自负。他们认为研发不专业，他才是最专业的；别人是错的，他永远是对的。其次是我很牛，我能搞定问题。当然，有时候没有办法也会自嘲，我是背锅侠。很多时候，大家的底限就是只要不出事就行，不再做更多尝试和进取的事情。

自制的锁链

各种各样的所谓KPI制度、规范、流程、标准、预算、成本、编制等等都是把大家约束住了。本来这些东西是好的，它们的出现就是为了让所有的事情变得有序、有计划、有规划。

但是这些东西自我优化、自我调整的速度太慢，甚至没有变化；导致这些东西从开始好的一面变成黑暗的一面，最后变成大家身上各种各样的蜘蛛网。

所以这些东西就不好了吗？这要看你怎么用；但一定不要给他束缚住，自己思维要开阔一点。

10

自动化短板

自动化应该怎样的状态是最好的？例如，建库，一天建一个库；盯着它，不要出问题，顺利完成。现在我搁一个脚本，五分钟跑完；这也是自动化。但这是不是最好的自动化和终极形态的自动化呢？

我们在2015年下半年到2016年上半年做的自动化；本来预期可以节省人力并提高效率。但是实际生产中并不是如此。因为一个用户需求提出从评审，到变更，最终反馈给用户；这个过程是非常漫长的。很多人做的自动化只是把自己工作自动化了；而执行阶段没有自动化，对于用户而言是没有改变的。所以这种自动化是有短板的；不是端到端的自动化，只是替代自己的操作执行而已。

三、运维的梦想

运维存在的那么多的问题，那怎么才是好的运维？至少要做到如下的四点：

• 第一点：信息必须是流通和共享的。在安全范围允许内，让绝大部分的人能够看到；这样大家都在同一个信息平面下工作。
• 第二点：资源交付不应该是自动的；而是自助的，端到端的。所谓端到端自助就是用户不必再提需求了；他在自己的工作环节点一个按钮就可以了，一分钟后告诉他OK了。
• 第三点：关键能力服务化。因为除了我们在底层运维以外，上面所有研发和运维同事也需要部分专业能力。很多时候他们都围着我们专业同事帮忙查看问题。如果将这些问题处理做成逻辑、做成平台；直接交给用户来用，而不用他来找你。
• 第四点：系统具备自恢复能力。

四、筹谋

为了实现梦想，我们必须敢于承认我们这个组织存在的问题。

• 首先，我们需要重新认识我们专业的价值。因为我们专业能力不能仅仅是熟悉一款软件把它用好；更多是我们要具备研发能力。
• 其次是专业能力赋能。
• 第三就是我们要将团队分成全栈团队和专业分工团队。
• 第四个方面，ITIL它本身的精神是好的，就是太慢了；那怎么让它更块更轻呢，这是我们期望的。
• 第五个方面就是让交付自助，端到端自动化。最后就是可编程的存储。

经过全面的考量之后，我们启动了下面五个项目：

• 丰箱： 将容器做成自动管理平台。平台可实现容器的创建、扩容。
• 丰云： KVM集群管理系统；该系统功能类似于丰箱，可实现虚机创建、删除等操作。
• 维石： 运维数据流通、共享的自助服务系统。将所有运维逻辑全部放入其中；让ITIL飞起来。
• ThinkDB： 高可用的数据库池管理系统。
• OSS： 对象存储系统。对于对象存储系统我们希望是可编程的；不需要每个机器多一根网线，挂载的时候还需要分传线路。

我们针对上述的项目制订了我们认为非常完美的计划，如下图所示。计划在2017年4月初把资源交付做到自助；到7月份就转入优化阶段。我们就这样想当然地开始干了。

五、碰壁

在完美计划的指导下，实际上我们刚开始的头两个月是没有什么进展可言的；主要暴露出了如下一些问题。

• 需求泛滥：每个专业需求非常之多，都想把自己的需求扔给项目团队去解决。谁也不让谁，清单无穷无尽。
• 邯郸学步：我们讲产品、讲敏捷用一些工具手法解决问题；结果成了邯郸学步，非常麻烦、达不到效果。
• 用力过度：有的人非常热情，热情的不是该他做的工作他也抢过来坐；但又做不好。该做的事情却被放在一边做冷板凳，很混乱。
• 纸上谈兵：大家会议上讲的内容和计划的完全不一样；会后反应的也不一样，言行背离。

一起做这件事情的人，不管是做需求的还是做架构的等等；大家都非常疲惫，天天吵架指责对方、非常痛苦。

这种情况导致的直接结果就是离职。我们的前端研发有人离开了，产品经理也跑路了，架构师也不玩了。

六、面壁

经过了两个月的纠结和痛苦；痛定思痛，我们直接深入介入项目一起来分析问题。制定了如下的五条规则：

• 第一条：规范需求，坚持价值导向。需求很多没有问题；但需要排队，关键还要看这些需求本身的价值。
• 第二条：拉近认知。让非常熟悉运维的同事和研发一起做这件事情，背靠背做研发。
• 第三条：看清事情本质，不玩时髦概念。不管是产品也好还是研发也好要把时髦的概念扔到一边；怎么更高效就怎么来做。
• 第四条：言行一致。通过规范我们的计划让我们讲的和做的，以及对外公布的是保持一致的。
• 第五条：职责回顾。大家各自重新把自己的职责理清楚。

七、破壁

经过痛定思痛的面壁我们大家基本上都知道自己该做什么了，也大概清楚该怎么干了。我们的设计理念就出来了；将底层的物理资源一直层层往上进行封装。用户最终能看到的是四个部分：

• 第一：自助交付；
• 第二：对外专业能力赋给别人；
• 第三：系统可以自适应；
• 第四：依据线上数据做决策变更；

按照这样的理念并调研、梳理，我们在一个半月之后交付第一个迭代。我们实现了自助交付的最常用的工作场景，下图维石的雏形。

经过三个月坚持不懈地努力，我们的自助交付迭代到了1.0版本。至此除了OSS，我们实现了容器管理平台、KVM、维石以及ThinkDB这四大块的阶段性目标。

展望未来

顺丰科技运维走到今天，我们以前认为不可能的事情现在做到；现在我们要考虑未来。以前我们主要是手工的、半自动的。现在我们将很多事情做成自助的。

我认为我们现有的交付工作在2017年80%以上的场景都可以做到自助交付。未来希望我们的系统有很强的自适应能力；我们的专业管理只需要做好资源池的管理就可以了。我们终极目标是实现运维的自由。