| 编辑推荐: |
| 本文来源高效运维，在快递物流飞速发展的当下主导了顺丰科技基础架构自原生态到标准化、系统化半自动化的运维模式转型，完成了顺丰集团新数据中心、容灾中心的规划建设和迁移等IT底盘建设工作。 |
|
一、运维密室
1.1、密室的墙壁与锁
顺丰的技术运维部门自2007年成立以来，伴随物流行业飞速的发展，其运维的规模也是一路狂奔，到2016年技术运维团队已经衍变成近200人的大队伍。当初为了建立专业技术能力，自2013年伊始经过3年的建设，技术运维团队组织架构和职能逐渐稳定成型：
1、从底层基础设施到网络、存储、服务器、操作系统、数据库以及中间件，每个专业领域都由专业条线团队负责，其工作职能包括专业条线的规划、设计、建设、实施以及日常运维。
2、对外交付由基础架构师团队统筹，工作模式为流程驱动，通过工单系统来进行推进和跟踪。
3、部门的制度、流程和质量由运维规划团队负责，来拉通和弥补技术团队管理方面的先天弱点。
4、整个技术运维队伍以ITIL体系作为基础指导。
5、基础技术软件在2015年已经实现全开源。
通过专业化的组织分工，我们培养很多专业领域人才，具备了一定的技术能力，同时也系统性的形成了适合物流行业业务形态的基础设施建设标准、设备引入和使用标准、基础软件使用标准和架构标准。受益于这些变化，我们的资源使用效率变得更加合理，系统稳定性也逐年出现显著的提升。
经历了3年的治理，队伍组织架构、职能和技术栈进入到了相对稳定的状态，但新的问题也逐渐浮出水面：
1、运维团队都背负系统可用性的KPI，并最终分解到各专业团队，在这种评价模式下逐渐出现了责任氛围。由于变更永远伴随着风险，本着少做少错的想法，团队与团队之间多多少少都存在关节部位工作的推诿现象，全时顺畅无间的协作成为一种奢望。不幸的是，烟囱式的垂直专业分工团队，对于协作的要求是远远高于水平分工团队。
2、出于信息安全考虑，各种系统和应用权限被严格切割，很多日常运维工作都出现上层工作人员等待下层依赖团队授权或者代执行场景。
3、当初的专业分工，让大家的技术能力栈出现萎缩，形成技术能力热点。稍微综合一点的专业技术问题，研发和运营人员就需要找对应的专业技术人员协助，经常可以看到办公室里面我们的某个DBA或者中间件管理员被一票人围住分析问题。
而对于技术运维队伍自身，各团队不约而同步入到一个瓶颈，整体的发展和成长被严重束缚，而大部分人在自己的微观世界中并未觉察。
其一：视野天花板，每个团队在工作中接收到的信息都是经过专业分层过滤的，只能在不完整信息的基础上进行分析、判断等工作。
其二：能力碎片化，没有一个团队有全栈运维能力，也没有一个团队能够俯瞰完整技术运维领域的工作。
1.2、密室外的风暴
当我们的运维人在密室的微世界中以自有节奏前行，怡然自得时，外面的大世界已经在急剧的变化中，现实是怎么样的呢？
业务方面：
1、业务流量峰值是一年比一年高，尤其是每年的双十一；
2、业务形态越来越多，以前更多可能是我们自己企业内部用户在用的各种系统；现在出现各种面向直接的C端和B端的用户；
3、为了适应市场的变化，业务的调整也日趋频繁，传递到技术运维端体现为更加频繁的版本和变更。
技术方面：
1、云技术的成熟减少了企业对于自建技术运维团队的需求，市场需求这个池塘在逐渐干涸，而池塘中的很多鱼儿还没有感应到变化；
2、技术的全面开源和快速的演进让很多传统商用技术专业成为鸡肋，工程师挟一技之长吃到底基本不可能，来不及在池塘干涸前完成进化的职场鱼儿们可能会被提前淘汰；
3、DevOps的风行为运维开辟了另外一条更有效地路线，反过来也对现有运维人提出了新的素质要求，运维人需要有研发能力且能够应用这种能力来提高运维的效率和质量。
密室之内斜风细雨，密室之外风暴已至，不能做风干的鱼，顺丰运维人再一次的将自己置于审判席上。
二、运维审判日
我们对IT运维工作做了四象限分解（如下图所示），从价值角度来看，理想情况是技术运维队伍需要将更多的资源投入在右边的象限上，而实际的情况是我们近七成精力都消耗在左边象限内的基础日常工作上，不停的做各类布朗运动。
基于对运维工作的四象限分解后的反思，我们总结了运维五宗罪：
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、持久化内容存储必须是可编程的，可扁平技术架构，降低工作依赖层级，同时也可进一步让IT设备统一X86化。
经过全面的考量之后，我们启动了下面五个任务：
1.丰箱： 容器自动自助的可视化管理平台，实现容器在顺丰技术架构标准规则下的自动创建和扩容即日常维护，同时实现和应用发布流程的无缝对接。
2.丰云： KVM集群自动自助的可视化管理平台，优先实现KVM虚机在顺丰技术架构标准规则下的自动创建和扩容即日常维护，最终实现和应用发布流程的无缝对接。
3.维石： 顺丰技术自动化运维的大脑，是运维信息流通和运维规则自动应用的核心，是最终面对用户的终端自助工作台提供方。
4.ThinkDB： 基于X86的高可用的数据库池管理系统，其承担了解除高容量高性能DB对SAN存储依赖的使命，同时进一步提高DB的可用性和数据库运维工作的简易性。
5.OSS： 文件型对象可编程存储系统，目的是对文件型存储可编程化，解除对NAS的需求，让这类型的所有运维规则和数据能够回归线上。
对于其中的主干任务维石，任务组在年初制订了非常完美的计划（如下图所示），计划在2017年4月初把资源交付做到自助，到7月份就转入优化阶段。
五、碰壁
在美好愿景的驱动下，我们从原有专业组抽调了部分力量组成需求团队，研发实现团队主要是没有做过运维工作的Java工程师，然后大家热火朝天的开干了，不想刚迈开步子即踏入炼狱，进入到为期两个月的无尽循环。
需求泛滥，每个专业组需求很多，即使这些需求不在任务主目标的关键路径之上，也都想把自己的痛点扔给项目团队并被优先解决。
需求理解偏差大，运维不懂研发，研发不知运维，需求和实现团队始终无法就需求规格说明达成一致以展开工作。
任务管理方法运用不当，邯郸学步，一开始就希望用我们本来就不太熟练的产品和敏捷方法来进行管理，结果成了东施效颦、徒具形式而已。
越俎代庖和用力过度，由于之前没有做个综合型研发项目，基础的职责没有厘清，大家凭热情和喜好做事，工作无法有效展开。。
纸上谈兵，大家会议上讲的内容和计划的完全不一样；会后反应的也不一样，言行背离。
如此种种不顺，两个月下来，参与这个任务的同事们，不管是做需求的还是做架构的，大家天天指责对方而没有结果，疲惫且痛苦着。传统运维转运维研发的艰辛，远远超出了当初的预期。
陆陆续续的，有成员开始放弃，平台和前端研发有人离开了，产品经理也不玩了，架构师也跑路了。
六、面壁
痛定思痛，关键人员集体面壁，对任务进行回顾和反思，最终制定了如下的五条规则：
第一条：规范需求，坚持价值导向。需求很多没有问题，但需要排队，优先级看还要看这些需求本身的价值和在关键路径上是否核心依赖；
第二条：拉近认知，让运维的需求方和研发一起背靠背做研发；
第三条：看清事情本质，不玩时髦概念，放下包袱，相关工作以更轻更高效的形势来做；
第四条：言行一致，规范我们的计划和过程管理，保障说的和实际做的，以及对外公布的信息保持一致；
第五条：职责回顾，大家各自重新把自己的职责厘清并遵守。
七、破壁
客观和理性再次成为行事的主流，大家停止了相爱相杀式的争执，运维大脑Vishnu（维石）的设计理念终于出炉。
1、以KVM、Docker、OSS、ThinkDB提供的标准接口为基础，实现底层资源的可编程；原有SAN、NAS、LB硬件设备以封装原子服务的形式实现资源分配的可编程；
2、包括DB、MW、MQ在内的OS之上的软件服务以封装原子服务的形式实现；
3、以编排框架实现完整工作流的编辑和管理；辅以任务管理的能力做时间排程；
4、具体的架构和运维规则逻辑在上层功能模块实现；
5、通过权限认证模块实现登陆和鉴权的处理；
6、面对用户主体功能模块包括自助交付服务、自服务、自适应和管理视图模块。
按照这种理念，维石（Vishnu）的雏形如下：
经过六个月坚持不懈地努力，我们已经迭代到了1.5版本，实现了容器管理平台、KVM、维石自助交付模块和自服务以及ThinkDB这四大块的阶段性目标，1.6的迭代已经开始切入管理视图部分的容量管理功能。随着功能的逐步上线，运维团队的工作模式和内容也开始相应的出现变化：
1、专业组充当好资源的供给方即可，只需做好在线资源的库存管理；
2、需求方也无需在通过工单系统进行拆单派单，直接在维石工作平台上获取资源即可，而且最终也给出了良性的反馈：“终于可以优雅的工作了”。交付效率更是较之前整体提高了１到２个数量级；
3、大量常规变更无需由于担心误操作风险，而集中到晚间人手最紧缺的时候执行，人和可工作时间的逆向差瓶颈被打破；
4、专业能力依赖解耦，之前由于专业能力和安全权所限需要排队找专业组同事提供的服务可以在工作台上获取，这部分还在进一步的优化中。
维石（Vishnu）和ＶＭ
八、现在和未来
走到今天，我们仍然在加强运维研发能力的建设：
1.更有效的需求发现和管理。
2.系统代码质量的提升。
3.建设自动化测试框架，提高测试效率和质量。
4.更适合运维的技术框架和平台架构。
5.更简洁有效的任务组织形式。
我们体会到以前认为不可能的事情经历摸爬滚打下来，只要努力去做，是可以实现的。可以预期的是，再过一年，还可以达到部分自适应和自愈的运维程度。
九、运维的自由
最后，希望广大运维人是自由的。心的自由，无需时刻诚惶诚恐、如履薄冰，担心无法按时交付误事，担心系统出故障。这个梦想，希望广大运维同路人一起来实现！
|
