作者：周辉

顺丰科技 基础架构规划副总监

自名甲骨君， 2002年OCP。曾有幸在金融数据大集中的黄金年代负责某金融集团保险、银行、证券、投资、基金、信托数据库运维工作，完成其庞大数据库群标准化规划和改造过程。

在快递物流飞速发展的当下主导了顺丰科技基础架构自原生态到标准化、系统化、半自动化的运维模式转型，完成了顺丰集团新数据中心、容灾中心的规划建设和迁移等IT底盘建设工作。现致力于顺丰科技运维基础软件研发和智能化运维平台领域工作，是 DevOps 的践行者。

前言

顺丰的数据中心工作内容可能和其他公司的基础架构部门不一样，基础设施、网络、存储、服务器、数据库、中间件等基础组件规划、设计、建设和运维全部都在其工作范畴。

接下来的谈及的内容不会涉及太多具体的技术细节内容，更多的是顺丰在基础架构方面的治理和演进的过程，包括了组织结构和团队组建的过程以及流程管理的内容。

1、顺丰科技介绍

顺丰科技服务于顺丰集团，主要专注于物流行业信息技术研究、开发和运维，以及信息技术引领业务创新。

2、 顺丰科技的创新与发展演进

2010年前，主要是技术起步和积累阶段，通过科技手段将下单、收派、中转、运输等业务流的信息化，实现快件路由跟踪、手持终端收派、自动分拣，并进行大规模的系统整合，支撑并推动业务的高速发展。
2010-2014年商业快速成长，是新技术新应用的爆发期，期间实现了电子支付业务与客户系统的无缝对接和数据的自动交互；移动端与互联网接轨，改善客户体验；使用大数据提供决策支持、舆情分析、行业分析，培养新的增长点。

2015年以来，为了使人们的生活更加便利，顺丰科技一直没有停下技术创新的脚步。

3、科技重塑业务流程，让人们变得更便捷

在快递的下单、收件、中转、运输、派送、支付等各业务环节，科技成为优化和重塑业务流程的重要力量，让人们的生活变得更加便捷。

3.1 莽荒纪-运维原生态（原生态）

在运维原生态这个阶段，新上IT系统、用什么基础软件和何种设备、用多少等事项，都是研发在规划和设计，运维按照研发的要求安装就可以了，基本上业内有些名气的基础软件，都会出现在需求清单上。

而怎么用运维也没有发言权，往往是运维按照研发的要求拿一个安装包，安装上去能起来用就行，其实完全没有来得及掌握这些软件的使用和最佳实践。而且的系统是没有容灾，也没有备份的，数据安全性很脆弱。相信很多企业经历过这个阶段，也有一些企业还在这个阶段。

3.2 莽荒纪-运维原生态（被动式）

在原生态的运维模式下，没有良好的规划能力、计划能力、专业能力和有效的工作流。这种情况让运维非常被动，资源永远不够用，只要起新项目、新系统必须买设备，而且新设备的采购周期很长，严重影响交付时效。

同时，缺乏计划能力时，需求总在不经意间冒出来，需要资源的时候，往往是项目要上线的时候，基础架构只能东拼西凑到处找设备，甚至找厂商借设备。专业战线太长，运维人员根本来不及形成专业能力，系统故障的出现频率不低。

3.3 莽荒纪-运维原生态（焦虑之源）

近五年快递业务增长很快，系统数在增长，业务量也在持续增加。快递行业业务工作系统化，自动化程度变得更高，对IT系统的可用性要求越来越高，大概五年前，很多快递企业没有自动化。

当年开始试行半自动化和自动化分拣的时候，区别很明显，IT系统的问题往往导致整个中专场分拣作业的停摆，最终影响到派送时效和用途体验。而这时基础架构还停留在“搬运工”阶段，且异常多，运维很多人里都陷在异常处理的泥潭，这时候整个运维团队压力都很大，处于无限焦虑的状态。

4、出发-集中填坑和还债

4.1 建立标准，完成标准化改造

我们大概花了6个月时间完成基础加过运维的各种标准。到底该使用什么软件，要不要百花齐放，如果人力资源有限、时间有限，如何让运维人员做到熟练的掌握所采用的基础软件？答案是明显的，基础软件需要在考虑适用性、适应性的基础上标准化，兼顾研发能力成熟情况。

定了软件的使用标准以后，从接入层开始至数据存储层，每个组件都需要考虑高可用和弹性的设计，故软件架构标准是在软件好用标准明确后接着需要完成的作业。我们大概用了1年多的时间完成绝大部分业务系统的标准化改造。

同样的道理，当初我们的设备类型非常多，包含存储、小机等，市面上主流厂商有的设备我们都有，无法有效形成这些设备的运维经验和能力积累，硬件的异常频率也不低，在设备的引入和使用标准制定并执行了一年多以后，基本上没有再由于硬件原因导致的重大故障出现。基于同样的原因，我们制定并执行了基础设施建设标准。

4.2 培养专业，术业专攻，服务统筹

基础架构标准解决了，专业能力怎么办？我们进行了专业分工，按照专业条线组建运维团队，在专业方向上进行深耕，收效比较明显，半年左右可以形成各基础架构专业领域的战斗力。

但这种组织形式在技术架构和技术方案的整体合理性方面比较弱，大家各行其是，没有一个团队能够站在系统整体层面进行设计和思考；另外专业团队在运维的管理方面初期会比较弱，如何进行统筹和拉通？首先成立基础架构师团队，扛起技术和架构标准的制定和更新并应用工作，进行整体的把关和设计。而运维管理相关制度流程规和执行可以成立精干的运维规划团队来护航。

2012年以前，我们没有变更管理，所有的变更都是专业人员根据自己的判断来做。所以经常会有些异常场景出现在业务高峰时段，系统突然宕了，原来是某个运维的兄弟在做停机维护或者下版本。

痛定思痛，我们提出变更的要求，成立 CAB 组织来保障执行，至少做到变更有固定时间窗、方案和风险评估，执行起来一段时间后，由于随意变更引起的人为故障出现了大幅度的下降。

4.3 建设工具，培养主动预防的运维能力

有了标准和专业能力还不够，从基础设施一直到中间件组件，基础架构大团队手上有很多内容需要运维，人多事多，可以说是纷纷扰扰。我们到底有多少组件和设备？它们有各做什么用途？这些组件和设备运行的情况怎么样？这些是所有基础架构运维人必须解决的问题，没有捷径可走。

经过大量的整理、梳理、配置、观测、调校工作，我们的运维团队花了半年多的时间完成了配置管理和监控系统的建设工作，完成之后，大家有了心清目明的感觉，心里也踏实多了，在此之后，我们的系统可用性比之前有了持续、大幅度的提升。经过一年多的努力，我们故障量下降到上一年故障量的一半左右，到目前，故障率可能只有之前的十分之一。

每年的双十一对资源的需求是喜马拉雅山形式的，突然飙上去，资源容量怎么办？我们根据监控系统采集到的数据推入容量预测平台，利用R语言结合历史数据和业务量建模，得到和业务量相关的系统容量模型，再代入当年双十一业务方对于业务量预测的结果即可得到双十一每个系统的资源容量要求体检进行准备。而真正进入双十一的时候，基础架构团队会相对轻松，公司的业务系统也可以做到平平稳稳度过双十一了。

4.4 新的焦虑

快递行业风云变幻，总体来讲近两三年快递行业服务单价都在下降，逆向对IT运营成本有增加了的压力。随着互联网的发展，业务形态更加多元化，而且业务的要求也越来越快， IT交付难度愈来愈高。初期的版本需求是一个月下一个版本，或者两周，而今我们部分系统已经是每周一个迭代。这些变化都要求基础架构需要更加轻和快。

而实际情况是基础架构是重资产单位，在整个IT运营成本中占比较高，另外之前采取专业分工的组织模式，也开始出现副作用，专业团队只站在自己的角度考虑问题，协同弱，沟通环节太多，效率低。专业壁垒已经形成，变成一个无法回避和逾越的问题，运维团队再一次陷入焦虑的循环。

5、加速-注重效率和成本

5.1 基础软件去商业化

全面拥抱开源，经过半年左右时间的预研、测试、研发框架实现，2015年开始，我们所有的基础软件实现了全开源，其中包括中间件、消息件和数据库等。开源以后，在软件许可和厂商服务方面的投入可以忽略不计了。

由于行业的特殊性，有些公司主要还是使用商业软件，而且需要使用大量的厂商服务资源，这种和厂商背靠背的运维模式，这种模式投入相对高，对厂商有一定的依赖。

开源以后，失去厂商背靠背的支持做运维，在开源软件的稳定性和性能方面必须掌握把控力，要深入掌握体系结构、功能、性能，部分和部件之间的关系，最好能够做到对 Bug 能够进行快速修复和性能优化，所以全面规模化的开源，需要形成自己的运维研发能力。

我们在导入 MySQL 的时候，本着“简单用”的原则，对不适合 MySQL 最佳实践的用法直接在数据库开发规范中进行明确约束。试点选择公司重点系统项目，我们的 DBA 团队和项目研发团队一起并肩作战，陪着研发一起走完了分析、规划、设计、代码、测试、调优、试运行一整套完整的过程，这个过程既是研发逐渐接受 MySQL 的过程，也是 MySQL 业界的最佳实践调校为顺丰的 MySQL 最佳实践的过程。从最终的结果来看，MySQL 更多的承担这数据容器的角色，业务逻辑绝大多的剥离到了数据库之外。

5.2 完善服务体系

全开源部分缓解了IT运营成本的压力，IT资源交付效率怎么办？最初我们新需求出来，只能做到15天后交付给需求方。后来经过架构师团队的努力，到一站式交付，通过流程梳理优化、工单系统导入，可以做到2~3天的交付，需求量较大的，最晚5天内交付。

之前做软件架构标准化改造和全开源，是自上而下的运动式的大跃进，运维和研发由于关注点的不同，目的也不完全一致，相互支持自然少不了，但相互理解方面到不得而知。为了增进理解，形成科技合力，基础架构运维团队提供了架构和 DB 设计服务，基础架构师和 DBA 直接驻点研发重点项目团队，和研发兄弟一起工作，提供专业能力的支持和问题的解决，实实在在的合作，几个项目下来，研发对运维的专业性的开始认可。

每次运维质量出现逆向波动的时候，回头看看 ITIL，检视管控点的缺失或松懈，多半都是执行的问题。ITIL作为一套成熟的运维治理法则，活学活用还是很有帮助。

5.3 日常工作自动化

受限于人类只能串行的脑和手，工程师无论工作多熟练，其日常工作产出有限。2015年下半年正在开始，我们的基础架构团队开始系统性的对待运维自动化，经过近半年多的努力，我们已经可以做到用户提一个创建型需求，经过运维专业组的线上评估，点一个按钮，自动生成变更，在系统上设定一个时间执行该变更。非创建型日常变更更多是是半自动式实现，还处在路上的阶段。

运维日常工作中，沟通多半是邮件、IM 或者会议，时间都消耗在了沟通和等待中，其本质是一个信息传递和确认的过程。处理好信息的准确行和流通有效性，将工作流和信息流放在线上，通过系统可以有很大的效率提升，工单系统是一个典型的例子。

5.4 仍然焦虑

IT运营成本已经不是一个大问题了，服务交付的效率貌似也能够跟上节奏，是否可以停下来休息了？当然不行，互联网形态的系统一直在增加，其使用行为和用量的波动区间远超企业内部系统，对系统的健壮性和架构弹性提出了更高要求。“双11”峰值一年比一年高，如何更快、更有效的进行高峰应对，而不是靠人来堆？

更轻更快是一个扑面而来的要求，而当时的实际情况则让人焦虑不已。

一是流程重，以 ITIL 理念设计的流程更看重质量，效率不能很好的兼顾，人和事被流程牵着走；

二是自动化，把整个流程拉开来看，从需求的发生到结束，自动化只是替代了末端执行环节的手工作业而已；

三是架构弹性弱，高峰应对的扩容评估、压力测试、扩容执行周期长，是“人肉”祭场。

四是技术架构纵深层次多，部分重要数据要在 SAN 集中存储，数据存储单点如鯁在喉，是运维人心头上的一根刺，急待解决。

6、狂奔-重定义架构和专业

6.1 基础运维十字架

基础架构很多种工作，我们将其分为价值四象限。从外部来看，右上角为价值区间，即我们能够为业务单位、研发单位等上游部门提供怎样的科技能力助力公司战略目标的实现。

左下角完全是为了系统稳定而进行的日常运维工作，重复性非常高，而且只要不出问题，外界基本无感知。整体来判断，纵轴右面的工作价值高于左边，正常理解的话，运维团队的资源应该更多的投入到右边的工作中。

很可惜，实际情况正好相反，彼时运维团队75%时间在做各种琐事，25%做进阶工作而已。结果本应右手解决左手的问题，但是右手腾不出来，左手也一直在忙。

6.2 重新定义专业和能力

6.2.1 专业重定义

为了再一次蜕变，摆脱运维十字架的负重，我们决定重新定义专业能力。以往专业团队掌握技术软件，熟练进行各种应用场景和使用方法就够了。现在够不够？明显不够！

再一次，我们需要重新组织队伍：

一是技术团队不能只做日常工作，一定要沉下心做专业领域的研究；

二是运维团队上浮，日常基础架构运维团队聚焦应用，基础架构运维人很多时候根本不了解应用系统，也不关心主机、存储和网络上跑什么系统，每次出现问题处理的要求时，大家都各讲各话；

三是研发团队聚焦，聚焦在打通专业壁垒，做到更彻底的运维自动化。

6.2.2 去掉中间环节

在烟囱垂直专业分工模式下，一个系统颗粒度的完整作业，工作流需要类串行的流经所有的专业团队，中间沟通环节多，慢! 对用户而言，如果能够实现端到端的自助交付或自服务是最快的方式，要做到这一点，需要要做基础架构数据整合和可视，打通专业和安全壁垒。

另外在队伍的组织层面，在整个平台打通工作还未完成前，可以尝试全栈运维，联合作战，在组织层面降维，让大家在一个平面上工作，实现信息和能力的透明共享。

在互联网系统领域，我们把基础架构专业人士抽一部分出来，和应用运营同事放在一起组成完整能力团队。现在效果比较明显，专业都有了，相互影响和学习，整体工作能力和效率都有提升。

6.2.3 优化技术架构

传统架构层次较深，尤其是数据存储层，不但徒增交付工作环节，同事有事数据安全和性能的热点，怎么办？对数据库的用途进行轻量化处理。

数据库只作为数据存储容器，不要把太多逻辑放在数据库处理。应用层要承担更多逻辑的实现，同事对数据库进行分片来拉低数据库主机和存储的需求门槛，一个数据库承载的数据量太大，逻辑太重，对数据库所在主机提出更高的要求，才会出现以前很多企业用小型机或更好的机器和光纤存储。

当然，对于 MySQL 数据存储本地化后，数据库 HA 方案不管是数据的完整性和切换的效率方面都要做好严格的设计和验证，我们的 ThinkDB 就是为解决这个问题而起的任务，从当前的进展来看，是完全可以解决的问题。

在资源和架构的弹性部分，如何更弹性？大家在物理机集群遇到一个问题，扩容要有机房同事把机件上架、拉好、初装，一旦涉及物理设备的操作就会变慢和重，这时我们将物理设备准备工作前置池化，当然，在量方面做好预测工作。逻辑层使用 Docker 和 KVM 虚拟群来做到相对轻量化的快速横向扩展。

谈到这里，开源的好处进一步凸显，开源可以无缝支持可编程的基础架构，投入一些研发资源，除了物理设备本身外，很多逻辑层的工作都可以从手工搬到线上，定时定量都可以处理，而且相关运维标准植入系统后，标准化的工作可以执行的更好。迄今，这些设计已经进入我们的技术架构标准。

7、新故事-维X

虽然我们可以在管理、团队组织进行局部优化，但无法解决一个问题，当一个团队大的时候，当你管理的设备、应用形态、软件技术多了，如何做到所有的人都知道状况？

如何共享信息、流通信息，一旦信息无法共享和流通，所有人都站在知晓的信息范围内工作怎么办？

我们看了业内一系列的解决方案，也和业内同行交流了很多次。他们都是非常优秀的平台和软件，我们发现这件事最后还得自己来。

平台渗入了一定的管理思维，对公司的能力、组织形式、业务形态以及相关的管理理念都有要求，你接受一个软件必须接受那些东西，能否完全接受，接受后的调整和适应需要多长时间？最后评估的结果是还得自己干。

我们希望通过维X，做到基础资源的提供、专业能力的提供，都以原子服务的形式在满足安全的前提下暴露出来，在系统进行集成，让我们的被服务方能够自助的获取，给我们的上游团队赋能，达到价值最大化的效果。

这个平台应该有几个特征：一是数据共享透明；二是交付自主；三是专业服务能够自服务；四是自调整和自适应；

谈智能有点超前，我们短期做不到这种程度，但相信前四点能够解决我们大部分的问题。这条路不易，运维人员开始转型运维研发人员时，思维模式和对研发项目的组织是欠缺的，后面有一定的积累再和大家分享！

本文转自微信公众号：高效运维