理想总是需要的，如果实现了，理想有多远，我们就能一起走多远。在实现理想自由的道路上，我们描绘蓝图，踏出探索之路的第一步。未来不是梦，就算是梦，我们也要用一生去完成这个梦。运维密室的墙壁和锁具。自2007年成立以来，顺丰技术运维部随着物流行业的快速发展而迅速壮大。到2016年，技术运维团队发展到近200人。大团队。为建立专业的技术能力，自2013年起经过三年建设，技术运维团队的组织架构和职能逐渐形成：从底层基础设施到网络、存储、服务器、操作系统、数据库、和中间件，每个专业领域都有专业线团队负责，其工作职能包括专业线规划、设计、建设、实施、日常运维。外部交付由基础架构师团队统筹，工作模式为流程驱动，通过工单系统进行推进和跟踪。运维规划团队负责本部门的制度、流程和质量，以弥补技术团队管理的先天短板。整个技术运维团队以ITIL体系为基本指导。基础技术软件已于2015年全面开源，通过专业组织和分工，培养了众多专业领域人才，具备了一定的技术能力。同时，我们还系统形成了适合物流业业态的基础设施建设标准、设备引进和使用标准、软件基础使用标准。和建筑标准。受益于这些变化，我们的资源使用效率变得更加合理，系统稳定性也逐年显着提升。经过三年的治理，团队的组织架构、职能、技术栈都进入了相对稳定的状态，但新的问题也逐渐浮出水面：运维团队背负着系统可用性的KPI，最终分解为各种专业团队。在这种评价模式中，责任氛围逐渐显现。因为变化总是伴随着风险，本着少做少犯的理念，团队之间的联动工作或多或少存在推卸责任的现象，全职顺畅协作成为一种奢望.不幸的是，烟囱式垂直专业分工团队对协作的要求远高于水平分工团队。出于信息安全的考虑，各种系统和应用权限被严格隔离。在很多日常运维任务中，上层人员等待下层依赖团队授权或代执行的场景。原有的专业分工导致大家的技术能力栈收缩，形成技术能力热点。对于稍微复杂一点的专业技术问题，研发和运营人员需要找相应的专业技术人员协助。经常看到我们的一个DBA或者中间件管理员在办公室围着一群人分析问题。至于技术运维团队本身，每个团队都同时遇到了瓶颈，整体的发展壮大受到严重制约，大多数人在自身的缩影中意识不到。视野的天花板，每个团队在工作中接收到的信息都是经过专业层层筛选的，只能根据不完整的信息进行分析判断。能力碎片化，没有团队具备全栈运维能力，也没有团队可以忽视完整技术运维领域的工作。密室外的风雨当我们的运维人员在密室的微观世界里按照自己的节奏前行时，外面的大世界已经在瞬息万变。现实情况如何？业务方面：业务流量的高峰期一年比一年高，尤其是每年的双十一。业务形式越来越多。以前更多的是我们自己内部用户使用的各种系统；现在有各种直接的C端和B端用户。为了适应市场的变化，业务调整也越来越频繁，体现在技术运维端更频繁的版本和变更。技术方面：云技术的成熟，降低了企业自建技术运维团队的必要性。市场需求的池塘正在逐渐干涸，池塘里的很多鱼还没有感觉到变化。技术的全面开源和快速演进，让很多传统的商业技术专业变得无用武之地。工程师想要靠自己的技术活下去，基本上是不可能的。没有时间在池塘干涸之前完成进化的职业鱼可能会被提前淘汰。DevOps的普及为运维开辟了另一条更有效的路径，进而对现有运维人员提出了新的素质要求。运维人员需要具备研发能力，并能够应用这种能力来提高运维效率和质量。密室里斜风细雨，密室外风雨已至，鱼干做不成。顺丰运维人员再次将自己摆上了评判席。运维审判日我们对IT运维工作做了四象限分解（如下图）。从价值的角度来看，理想的情况是技术运维团队需要在右象限投入更多的资源。但实际情况是，我们将近70%的精力都消耗在了左象限的基本日常工作中，不停地做着各种布朗运动。基于对运维工作四象限分解的反思，我们总结出了运维的五宗罪：繁琐和精通。经过三年的专业化和标准化，我们的工程师在平时的日常工作中已经非常熟练。新的一天工作变成n+1次重复；工程师在键盘上的手越来越快，脑袋却渐渐麻木，在工作中逐渐失去了独立思考的能力。降维工作效率很多日常的IT运维交付任务只需要几分钟就可以完成，但从用户需求到层层审核，直到交到用户手上，可能需要几天的时间。效率低下是大团队的通病，烟囱式的垂直专业分工会随着依赖团队的数量进一步扩大，让用户苦不堪言。透过现象看本质，其实是时间花在了沟通和等待上。内部愿景的黑洞在企业IT团队。从技术的角度来看，技术运维团队往往具备专业的技术能力，但从业务价值链的角度来看，技术运维团队处于价值链的末端。从完整的工作流程来看，技术运维团队往往是最后一环，而不是IT大军的最前沿。在价值认知错位和信息隔离的情况下，如果没有完全的理性和充足的一线信息，技术运维人员就会形成各种消极的自我，汇聚成内部视觉的黑洞。自制链本来就伴随着公司的成长，部门建立了KPI、定额、流程、标准、预算、成本、编制等各项制度，使管理制度化、规范化。它们的出现是为了让运维工作有条不紊、有计划、有计划，在初期取得了不错的效果。但在某些情况下，这些制度会显示出它们的阴暗面，成为组织的枷锁和制约因素，例如：制度和流程执行过度，忽视人的主动性，所有人都被制度和流程牵着走，而团队创造力被阉割了。制度和流程所引导和约束的东西总是在变化，而制度和流程却跟不上变化的步伐，最终成为工作的累赘和烂链条。关注管理者的需求，忽视用户和一线的声音，忘记了建立制度和流程的初衷，制度和流程终将成为皇帝的新衣。自动化的短板当IT运维团队达到一定的能力和规模时，就会开始运维工作的自动化建设阶段，并会在一开始就被赋予解决各种问题的美好期望。往往由IT运维团队发起的自动化工作，优先解决运维团队自身的问题，不一定站在用户的角度。我们从2015年下半年到2016年上半年开始自动化运维；希望节省人力，提高效率和质量，但效果并不理想。自动化任务结束了，整体交付效率没有发生质的变化，用户也没有变得满意。当我回顾原因的时候，我终于明白，我们都是在做执行端的自动化，也就是把之前人工执行的工作自动化，解决了运维主管自己的问题，但是没有解决交付工作流程效率低下的问题。因为一个用户需求从提出、审核、变更，最后反馈给用户，这个过程是很漫长的。很多人做的自动化，就是把自己的执行工作自动化，用户感觉不到任何提升。运维之梦经过一系列的反思和自我判断，我们看到技术运维团队的身体正在过早老化。总结如下：失去创造力，所做的工作仅限于保持现有技术和架构特征类型系统的可用性，未能系统地开展前瞻性的整体技术能力建设工作来支持公司未来的发展需求IT机箱技术。视野缩小，规划设计工作围绕自身痛点，无法从公司业务发展出发，有效拓展IT底盘能力的广度和深度。日趋官僚化、程序化等规章制度成为盾牌和隔音墙，队伍充满滞胀感，无法在需要技术炮火的时候为前线提供有效支援。坐以待毙，只关注技术本身而忽视了价值贡献，无法对公司的技术战略进行衔接和跟进。综上所述，感觉技术运维团队已是深夜寒山雨，黄昏千山雪。如何打破身心的牢笼，实现自我救赎？经过多轮思考和头脑碰撞，我们认为技术运维工作的理想状态应该是：工作信息必须是流通和共享的，信息是在考虑安全和工作的基础上对原始数据进行过滤的结果职责，技术运维人员可以看到工作所需的所有信息，技术运维和服务对象在同一个信息平面上进行沟通和协作。交付工作应该基于整个过程端到端的自动化，即自助服务。用户所需要的交付不再需要提前沟通启动流程，而是直接在终端工作界面上即可获取。系统内嵌的规则引擎保证了其自助获取资源各方面的合规性。服务化关键专业技术能力，实现跨部门工作能力解耦。涉及依赖专业技术细分的工作，由技术运维方以终端工作台的形式提供，需求方自行使用，无需需求方提及服务流程和排队等候。常规事件和异常实现自我反应和自我修复，使运维工作相对智能化，在提高系统可用性的同时达到减轻工作负担、降低成本的目的。规划方向已经很明确，目标就在彼岸。如果我们达到了怎么办？更审慎的执行、更负责任的态度、更细粒度的管理并不能解决问题。唯一的出路就是突破现有的思维模式，立足现状，不拘泥于现状。我们决定在以下六个方面取得突破：重新定义对专业技术能力的要求，技术运维人员需要精通或精通基础软件应用，需要具备研究和引进新技术的能力或能力运营和维护研发。专业的技术支持团队有责任系统地提供便捷的自助通道，实现关联和依赖团队的能力解耦。生意是第一要务。在工具平台开放前，调动现有专业团队，组建全栈技术能力运维团队，支撑敏捷产品团队的运维支撑工作。在不降低运维质量要求的前提下，将原有的ITIL管控环节抽象为规则逻辑，嵌入到工具平台中。所有的自动化工作都坚持端到端的用户思维，让用户以自助的方式享受服务。原有流程环节通过规则引擎植入运维系统，对用户透明。持久化内容存储必须是可编程的，可以扁平化技术架构，降低工作依赖级别，进一步统一IT设备的X86。综合考虑后，我们推出了以下五项工作：风箱：集装箱自动化自助服务可视化管理平台，在顺丰速运技术架构的标准规则下实现集装箱的自动创建和扩容，即日常维护，同时实现了应用发布流程的无缝集成。风云：KVM集群自动化自助可视化管理平台，优先在顺丰速运技术架构标准规则下自动创建和扩展KVM虚拟机，即日常维护，最终实现与应用发布的无缝对接过程。魏士：顺丰自动化运维的大脑是运维信息流转和运维规则自动应用的核心，是最终面向用户的终端自助服务工作台的提供者。ThinkDB：??基于X86的高可用数据库池管理系统，承担着解除大容量、高性能DB对SAN存储依赖的使命，同时进一步提高DB的可用性和数据库运维的易用性。OSS：File-typeobjectprogrammablestoragesystem，目的是将文件类型的存储程序化，不需要NAS，让该类型的所有运维规则和数据回归线上。对于其中一个主线任务微视，任务组在年初就制定了非常完善的计划（如下图），计划在2017年4月上旬交付资源自救，并转向优化七月阶段。在美好愿景的驱使下，我们调动了部分原有的专业团队，组成了需求团队。研发和实施团队主要是从未做过运维工作的Java工程师。即踏入炼狱，进入两个月的无尽轮回。需求泛滥，每个专业群体都有大量的需求。这些需求即使不在任务主要目标的关键路径上，也都想把自己的痛点抛给项目组，优先解决。需求理解偏差较大，运维不知道研发，研发不知道运维，需求和实施团队还无法就需求规范达成一致，开始工作。任务管理方法使用不当，邯郸学步，一开始希望用我们不是很精通的产品和敏捷方法来管理，结果流于形式。由于之前没有全面的研发项目，没有明确基本职责，大家做事都热情洋溢、偏爱做事，工作无法有效开展。纸上谈兵，大家在会上说的和计划的完全不一样；会后反应亦不一，言行不一。两个月下来，参与这个任务的同事，不管是做需求还是做架构，每天都互相埋怨，没有结果，又累又痛苦。传统运维和研发的艰辛已经远远超出了最初的预期。陆续有人开始放弃，有人离开平台和前端研发，产品经理不玩了，架构师也跑了。顶着墙痛定思痛，骨干人员集体顶着墙，对各项任务进行回顾反思，最终制定了以下五项规定：规范要求，坚持价值导向。需求很多没有问题，但是需要排队。优先级取决于这些需求本身的价值，以及它们是否是关键路径上的核心依赖。更贴近认知，让运维和研发的需求方一起做背靠背的研发。看清事物的本质，不要玩弄时髦的概念，放下包袱，以更轻松、更高效的方式做好相关工作。言行一致，规范计划和流程管理，确保言行一致，对外发布的信息一致。责任回顾，大家明确责任，恪守职责。破壁的客观性和理性再次成为行为的主流。大家已经不再争论相爱相杀的事了。运维大脑Vishnu（weishi）的设计理念终于出炉了。设计理念如下：基于KVM、Docker、OSS、ThinkDB提供的标准接口，可以对底层资源进行编程；原有的SAN、NAS、LB硬件设备可以通过封装原子服务的形式进行编程。OS上的DB、MW、MQ等软件服务都是以封装的原子服务的形式实现的。完整工作流的编辑和管理由编排框架实现；时间调度辅以任务管理能力。具体架构和运维规则逻辑在上层功能模块中实现。通过权限认证模块实现登录和认证的处理。面向用户的功能模块包括自助配送服务、自助服务、自适应和管理视图模块。根据这个理念，Vishnu的原型如下：经过六个月的不懈努力，我们迭代到1.5版本，实现了容器管理平台、KVM、Vishnu自助交付模块和自助服务、ThinkDB。一个大的阶段性目标，1.6的迭代已经开始切入管理视图部分的容量管理功能。随着功能的逐步上线，运维团队的工作模式和工作内容也开始相应改变：专业的团队可以充当好资源的提供者，只需要做好线上的库存管理资源。需求方不需要通过工单系统进行拆单和派单，而是可以直接在微视工作平台上获取资源，最后给出良性反馈：“终于可以优雅地工作了”。交付效率较之前提升了1~2个数量级。由于担心误操作风险，无需在人力最稀缺的夜间进行大量例行变更，打破了人力与工时逆差的瓶颈。专业能力取决于脱钩。此前，由于专业能力和安全权限的限制，需要排队的专业组同事提供的服务才能在工作台上获取。这部分还在进一步优化中。Vishnu和VM现在和未来，我们还在加强运维研发能力的建设：更有效的需求发现和管理。系统代码质量提升。构建自动化测试框架，提高测试效率和质量。更适合运维的技术框架和平台架构。更简洁有效的任务组织形式。我们已经意识到，以前认为不可能的事情，只要我们努力，是可以实现的。可以期待再过一年，就可以达到部分自适应、自愈的运维水平。运维自由最后希望广大运维人员自由。心的自由，不用时时提心吊胆，如履薄冰，担心不能按时交货，担心系统故障。这个梦想，希望广大运维和路人一起圆梦！周辉，自号甲骨文君，2002年OCP。千禧年以来先后在富士康集团、平安科技、顺丰科技工作，深刻体验了IT运维的历史变迁。制造业、金融业、快递物流业。有幸在金融数据大集中的黄金时代负责某金融集团的保险、银行、证券、投资、基金、信托等数据库的运维工作，完成了其庞大的数据库群的标准化规划和改造过程.随着快递物流的快速发展，引领顺丰科技基础设施从原生态向标准化、系统化、半自动化的运维模式转型，完成了顺丰新数据中心和灾备的规划建设中心，以及IT底盘的迁移。工作。现致力于顺丰科技运维转型改革，是DevOps的践行者。
