关于作者：

周慧

自数甲骨文王，2002 OCP。千禧年以来先后任职于富士康集团、平安科技、顺丰速运，经★历了制造业、金融业、快递物流▓业IT运维的历】史变迁。有幸在金融数据△集中的黄金时代负责了某金融集团的保险、银行、证券、投资、基金、信托等数据库的运维，完成了其庞大数据库的标准化规划和改造过程团体。随着快递物流的快∮速发展，引领顺丰科技基础设施从原生态向标准化、系统化、半自〖动化的运维模式转变，并完成了规︼划、顺丰集团新数据中心和容灾中心的建设和迁移。工作。现致力于顺丰科技运维的转型与改革it运维技术，是一名实践者。

总有一个理想，如果实现☉了，理想能〓走多远，我们才能一起走多远。在【实现理想自由的道路上，我们绘制蓝图，踏出探索之路的第一步。未来不是梦，即使是梦，也要用一生去完成这个梦。

一、运维密室1.1、密◥室的墙和锁

自2007年顺丰技术运维部成立以来，随着物流行业的快∴速发展，其运维规模◢也一直在疯狂运行。到2016年，技术运维团队已成长为近200人的大型团队。为建立专业技术能力，自2013年初以来，经过三年的建设，技术运维团队的◆组织架构和职能已逐步形成：

1、从底层基础设施到网络、存储、服务器、操作系统、数↑据库和中间件，每个专业领域都有专业的一线团队负责，其工作职能包括规划、设计、建设、实施和日√常日常运营。

2、外部交付由基础架构架构师团队协调，工作模式为流程驱动，通过工单系统进行推广和跟踪。

3、部门的制〒度、流程和质量由运维策划团队负责，以弥补和弥补技术团队管理上的先天不足。

4、整个技※术运维团队以ITIL系统为指导♂。

5、基础技术软件已于2015年全面开源。

通过专业的组织和分工，我们培养了多个专业领域的人才◥，获得了一定的技术能力。同时，我们还系统地形成了基础设施建▆设标准、设备引进和使∏用标准、基础软件使用标准和适合物流行业业■态的标准。建筑标准。受益于这些变化，我们的资源使用效率变得更加合理，系统稳定性也逐年显着提升。

经过三年的治理，团队的组织架构、职能和技术栈都进入了相对稳定→的状态，但新的问题也逐渐浮出水〗面：

1、运维团队都↙背负着系统可用性的KPI，最终分解成各个专业团队。在这种评价模式下，责任感逐渐显现。既然变革总是伴随着风险，本着少做多错的理念，团队之间的接缝工作ω　或多或少有推卸，专职顺∑利协作成为奢望。不幸的是，烟囱式的垂直分工比水平分工需】要更多的协作。

2、为了信息】安全，严格划分各种系统和应用权限，很多日常运维工作都有上层人员等待下层依赖团队授权或代为执行。

3、原来的职业分工导致大家的技√术能力栈收缩，形成技术能力热点。对于更全面的专业技术问题，研发和运营◎人员需要寻找相应的专业技术人员进行协助㊣　㊣　。经常看到我们办公室的一位DBA或中间件管理员被很多人围着分析问题。

至于技术运维团队本身，各个团队同时进入瓶颈期，整体发展壮大受到严重制约，大多数︾人在自己的微观世界里都没有意识到。

1.2、密室外的风↓暴

当我们的运维人员在密室的微观世界里按〗照自己的节奏前进，感到舒服的时候，外面的大世界已经在发生快速的变化。现实是什么样的？

商业：

1、业务流量高峰逐年增加，尤其是每々年双十一；

2、业务形式越来越多。过去，更有可能是我们自己内部用户々使用的各种∞系统；现在有各种直接的C端和B端用户；

3、为了适应市场的变化，业务的调整越来越频繁，随着版本和变化越来越频繁，传递到技术运维端。

技术方面：

1、云技术的成█熟，降低了企☉业对自建技术运维团队的需求。市场需求的池塘逐渐枯竭，池塘里的许多鱼还没有感觉到变化；

2、全面的开源和技术的快速演进，让很多传统的商业技术专业变得无用武之地。工程师要靠自己的本事吃到最后基本上是不可能的。在池塘◥干涸之前来不及完成进化的，可能会被提前淘汰；

3、的火爆为运维开辟ㄨ了另一条更有效的途径，进而对※现有运维人员提出了新的素质要求。运维人员需要具备研发能力，并能够运用这种能力来提高运营效率和质量。

密室里面是斜风细雨，密室外面又是暴风雨，不可能↓做鱼干。

二、运维←审判日

我们对IT运维工作做了四象限▓分解（如下图）。从价值▲来看，理想的情况是技术运维团队需要在右象限投入更多的资源，但实际情况是我们近70%的精力消耗在左象限的基础日常工作上象限，做各种布朗运动。

基于对运维工作四象限分∩解的反思，我们总』结出运维的五种死法：

2.1、庞大的熟练度

经过→三年的专业化和标准化，我们的工程师对平时的日常工作已经非常熟练了，新的一天的工作只是n+1的重复；工程师们在键盘上打字的手越来越快，但他们的脑袋却逐渐麻木，在工作中逐渐失去了独立思考的能力。

2.2、工作效率降↓低

很多日★常的IT运维交付工作真的只需要几分钟就可以完成，但从用户需求到层层审核再到交付给用户，可能需要几天的时间。大团队普遍存在的效率低下的问题是，烟囱式的垂直专业分工会随着依赖团队数量的增加而进一步放大，让ζ用户苦不堪言。透过现象看本质，其实时间是花在沟通和♀等待上的。

2.3、向内观察黑洞

在企业IT团队中，从技术的角度来看，技术运维团队往往具备专业的技术能力，但从业务价值链的角度来看，技术运维团队处于价值链的末端；从完整的工作流程来看，技术运维团◥队往往是最后一环，而不是IT大ζ　军的第一线。在价值认知错位、信息孤立的情况下，如果没有完全的理性和充足的一线信息，技术运维人员就会形成各种负面的自我，汇聚成内心视觉的黑洞。

2.4、自制链条

起初，随着公司的成长，该部门建』立了KPI、规范、流程、标准、预算、成本等各项制度，为系统化、规范化的管理做准备。它们的出现∮使运维工作有序高效。规划、规划，并在起步阶段起到了很好的作用。但在某些情况下，这些机构会表现出阴暗面，成为组织的桎梏和桎梏，例如：

1、制度和流程执行过度，无视人的主动性，所有人都被制度和流程带走ㄨ，团队的创造力【被阉割。

2、系统和流程所引导和约束的事物是不断变化的，但系统和流程却跟不上变化的步伐，最终成为工作的包袱和烂链。

3、关注管理者的需求，忽略用户和一线的声音，忘记建立「制度和流程的初衷。制度和流程最终成为皇帝的新衣∩。

2.5、自动化缺点◥

当IT运维团队达到一定的能力和规模后，将进入运维工作的自动化构建阶段，并在一开始就给予解决各种问题的良好期望。很多时候，IT运维团队发起的自动化工作，优先解决运维团队自身的问题，不一定站在用户的角度。

我们从 2015 年下半⊙年到 2016 年上半年▆开始自动化运营；本来希望可以节省劳动力，提高效率和质量，但结果却不尽如人意。自动化的任务结束了，整体的交付效率没有发生质的变化，用户也没有变得满意。回顾原因，我终于明白╲╲，我们都是在做执行端的自动化，也就是把之』前的人工执行工作自动化，解决了运维主管自己的问题，但并没有解决效率低下的问题交付工作流程。因为一个用户需求是从审核提出，到修改，最后反馈给用户，这个过程是很长的。许多人所︻做的自动化只是自动化他们自＠ 己的执行，

三、运维梦

经过一系列的反思和自我判断，我们看到了技术运维团队未老先老。总结如下：

1、失去创造力，工作仅限于维护现有技术和架构特征类型系统的可用性，未能系统地进行前瞻性的整体■技术能力建设，以支持公司◆未来对IT机箱技√术的发展需求。

2、愿景在缩小，规划设计工作聚焦自身痛▽点，无法从公司业务发展中有效拓展IT底盘能力的广度和深度。

3、官僚主义越来越官僚化，流程等规章制度成了盾牌和隔音墙。当需要技术炮火时，团队已经筋疲力尽，无法再为前线提供有效≡支持。

4、坐以待毙，只关︾注技术本身，忽视价值贡献，无法链接和跟进公司的技术战略。

综上所述，感觉技术运维团队已经是寒山夜雨，千山暮雪，如何冲破身心的牢笼，实现自我救赎？经过多轮思考〇和头脑风暴，我们认卐为技术运维工作的理想状态应该是：

四、阴谋

方向明确，目标在彼ξ岸。如果我们达到▲它怎么办？更细心的执行、更负责任的态度、更细粒度的管理都解决不了问题。只有突破现有的思维模式，立足现状，不拘泥于现Ψ 状，才有出路。我们决定从以下六个方面进行突破：

1、重新定▂义对专业技术能力的要求。技术运维人员需要在精通或精◤通基础软件应用的基础上，具备研究和引进新技术的能力或运维研发能力。

2、专业的技术支持团队有责任以系统的方式提供便捷的自助服务渠道，实现▲依赖团队的能力解耦。

3、业务是第一要△务。在工◥具平台开放前，将从现有专业团队中招募精英，组成全々栈技术能力运维团队，支持敏捷产品团队的运维支撑工作。

4、在不降低运维质量要求的前提下，将原有ITIL的管控环节抽象为规则逻辑，嵌入工〖具平台。

5、所有自动化工作都坚持端到端的用户思维，让用户以自助的方式享受服务。原有流程环节通过←规则引擎植入运维系统，对用户透明。

6、持久化内容存储必须是可编程的，可以扁平化技术架构，降低工作依赖程度，进一步统㊣一X86 IT设备。

经过深思熟虑，我们启动了♀以下五项工作：

对于主线任务微视，任务组在年初制定了完善◆的计划（如下图），计划在2017年4月上旬交付资源自助，然后转入优化七月的阶段。

五、我撞墙了

在美好愿景的推动下，我们将原有专业团队的部分优势转移○到需求团队。研发和实施团队主要是没◢有做过运维工作的Java工程师。步入炼狱，进入两个月︼的无尽循环。

在这↓一切都出了问题之后，两个月后，参与这项任务的同事，无论是为了需求还是为了结构，每天都在互相指责，没有结果，筋疲力尽，痛苦不堪。传统运维、运维、研发的艰辛已经远远超出了当初的预期。

一个接↑着一个，有∮的成员开始放弃，有的平台和前端研〖发离开，产品经理不玩了，架构师√也跑了。

六、面对墙壁

骨干人员集体对墙，对任务进行回顾和反思，最终制定了以下五项规则：

七、打破围墙

客观和理性再次成为行为的主流。大家停止了※相爱相杀的争吵，运维大脑（微视）的♂设计理念终于出炉。

1、基于KVM、OSS提◢供的标准接口，实现底层资源的◥可编程；原有的SAN、NAS、LB硬件设备以封装原子服务的形式实现资源分配的可编程性；

2、OS上的DB、MW、MQ等软件服务以封装的原子服务的形式实现；

3、用编排框架实现整个工作流的编辑和管理；日程安排辅以任务管理能力☆；

4、具体架构和运维规则逻╱辑在上层功能模块■中实现；

5、通过授权认证模块实现登录和认证的处理；

6、面向用户体的功能模块包括自助配ξ送服务、自助服务、自适应和管理视图模块。

按照这个概念，次元stone()的原型如下：

经过六个月的不懈努力①，我们已经迭※代到1.5版本，实现了容器管理平台、KVM、自交付模块和自助服务四大块的阶段性目标，1.6的迭代已经ㄨ开始切入管理视图部分的容量管理功能。随着功能的逐步上线，运维团队的工作方式和工作内容也开始发生相应的变化：

1、专业的团队可以充当优秀的资源供应商，只需要做好∏线上资源的库存管理；

2、需求方无需通过工单系统进行拆♂单，直接在微视工作平台获取资源，最后给Ψ出良性反馈：“终于可以优雅工作了”。交付效率比以前提高了1到2个数量级；

3、由于存在误操作风险，不需要在人力最紧缺的晚上进行大量例行◎变更it运维技术，打破人员与工时反向差的瓶颈；

4、专业能↘力依赖于解耦。此前，由于专业能力和安全权▂限，需要排队的专业组同事提供的服务可以在工作台上获取。这部分还在进一步优化中。

Stone() 和 VM

八、现在和未来

今天，我们还在加强运维研发能力建●设：

我们意识到过去我们认为不可能∑的事情经历了很多〗艰苦的工作。只要我们努力，我们就能实现「。可以预计，再过一年，可以达到部分自适应、自愈的运维水平。

九、运维自由

最后，希望广大运维人员能够自由自在。内心的自由，不用时々时刻刻害怕，如履薄冰，担心不能按时交付东西，担心系统故障。这个梦想，希望广大＠ 运维同仁一起实现！

结尾