顺丰IT幼功结构运行的焦躁与进步,顺丰运行的上

2020-04-23 作者:亚洲城动态   |   浏览(162)

作者简介:

作者简介:

周辉

自号甲骨君, 2002年OCP。自千禧年以来先后就职于富士康集团、平安科技和顺丰科技,深刻经历制造行业、金融行业和快递物流行业IT运维工作的历史变迁。曾有幸在金融数据大集中的黄金年代负责某金融集团保险、银行、证券、投资、基金、信托数据库运维工作,完成其庞大数据库群标准化规划和改造过程。在快递物流飞速发展的当下主导了顺丰科技基础架构自原生态到标准化、系统化、半自动化的运维模式转型,完成了顺丰集团新数据中心、容灾中心的规划建设和迁移等IT底盘建设工作。现致力于顺丰科技运维转型和变革工作,是DevOps的践行者。

周辉

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

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

一、运维密室1.1、密室的墙壁与锁

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

顺丰的技术运维部门自2007年成立以来,伴随物流行业飞速的发展,其运维的规模也是一路狂奔,到2016年技术运维团队已经衍变成近200人的大队伍。当初为了建立专业技术能力,自2013年伊始经过3年的建设,技术运维团队组织架构和职能逐渐稳定成型:

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

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

前言

2、对外交付由基础架构师团队统筹,工作模式为流程驱动,通过工单系统来进行推进和跟踪。

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

3、部门的制度、流程和质量由运维规划团队负责,来拉通和弥补技术团队管理方面的先天弱点。

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

4、整个技术运维队伍以ITIL体系作为基础指导。

1、顺丰科技介绍

5、基础技术软件在2015年已经实现全开源。

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

通过专业化的组织分工,我们培养很多专业领域人才,具备了一定的技术能力,同时也系统性的形成了适合物流行业业务形态的基础设施建设标准、设备引入和使用标准、基础软件使用标准和架构标准。受益于这些变化,我们的资源使用效率变得更加合理,系统稳定性也逐年出现显著的提升。

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

经历了3年的治理,队伍组织架构、职能和技术栈进入到了相对稳定的状态,但新的问题也逐渐浮出水面:

2010年前,主要是技术起步和积累阶段,通过科技手段将下单、收派、中转、运输等业务流的信息化,实现快件路由跟踪、手持终端收派、自动分拣,并进行大规模的系统整合,支撑并推动业务的高速发展。

1、运维团队都背负系统可用性的KPI,并最终分解到各专业团队,在这种评价模式下逐渐出现了责任氛围。由于变更永远伴随着风险,本着少做少错的想法,团队与团队之间多多少少都存在关节部位工作的推诿现象,全时顺畅无间的协作成为一种奢望。不幸的是,烟囱式的垂直专业分工团队,对于协作的要求是远远高于水平分工团队。

2010-2014年商业快速成长,是新技术新应用的爆发期,期间实现了电子支付业务与客户系统的无缝对接和数据的自动交互;移动端与互联网接轨,改善客户体验;使用大数据提供决策支持、舆情分析、行业分析,培养新的增长点。

2、出于信息安全考虑,各种系统和应用权限被严格切割,很多日常运维工作都出现上层工作人员等待下层依赖团队授权或者代执行场景。

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

3、当初的专业分工,让大家的技术能力栈出现萎缩,形成技术能力热点。稍微综合一点的专业技术问题,研发和运营人员就需要找对应的专业技术人员协助,经常可以看到办公室里面我们的某个DBA或者中间件管理员被一票人围住分析问题。

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

而对于技术运维队伍自身,各团队不约而同步入到一个瓶颈,整体的发展和成长被严重束缚,而大部分人在自己的微观世界中并未觉察。

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

其一:视野天花板,每个团队在工作中接收到的信息都是经过专业分层过滤的,只能在不完整信息的基础上进行分析、判断等工作。其二:能力碎片化,没有一个团队有全栈运维能力,也没有一个团队能够俯瞰完整技术运维领域的工作。1.2、密室外的风暴

3.1 莽荒纪-运维原生态(原生态)

当我们的运维人在密室的微世界中以自有节奏前行,怡然自得时,外面的大世界已经在急剧的变化中,现实是怎么样的呢?

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

业务方面:

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

1、业务流量峰值是一年比一年高,尤其是每年的双十一;

3.2 莽荒纪-运维原生态(被动式)

2、业务形态越来越多,以前更多可能是我们自己企业内部用户在用的各种系统;现在出现各种面向直接的C端和B端的用户;

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

3、为了适应市场的变化,业务的调整也日趋频繁,传递到技术运维端体现为更加频繁的版本和变更。

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

技术方面:

3.3 莽荒纪-运维原生态(焦虑之源)

1、云技术的成熟减少了企业对于自建技术运维团队的需求,市场需求这个池塘在逐渐干涸,而池塘中的很多鱼儿还没有感应到变化;

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

2、技术的全面开源和快速的演进让很多传统商用技术专业成为鸡肋,工程师挟一技之长吃到底基本不可能,来不及在池塘干涸前完成进化的职场鱼儿们可能会被提前淘汰;

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

3、DevOps的风行为运维开辟了另外一条更有效地路线,反过来也对现有运维人提出了新的素质要求,运维人需要有研发能力且能够应用这种能力来提高运维的效率和质量。

4、出发-集中填坑和还债4.1 建立标准,完成标准化改造

密室之内斜风细雨,密室之外风暴已至,不能做风干的鱼,顺丰运维人再一次的将自己置于审判席上。

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

二、运维审判日

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

我们对IT运维工作做了四象限分解,从价值角度来看,理想情况是技术运维队伍需要将更多的资源投入在右边的象限上,而实际的情况是我们近七成精力都消耗在左边象限内的基础日常工作上,不停的做各类布朗运动。

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

基于对运维工作的四象限分解后的反思,我们总结了运维五宗罪:

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

2.1、笨重的熟练

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

三年的专业化和标准化道路走下来,我们的工程师对于平时常规的工作已经非常娴熟,新一天的工作变成n 1的重复而已;工程师敲键盘的手越来越快,脑袋却逐渐麻木,逐渐失去在工作中独立思考的能力。

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

2.2、被降维的工作效率

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

很多日常IT运维交付工作真正完成只需要几分钟,但是从用户需求提出到层层审核,一直到交到用户手中可能需要好几天。低效这种大团队的通病在烟囱式的垂直专业分工团队会随着依赖团队个数进一步放大,留下用户在一旁苦不堪言。透过现象看本质,事实是时间都花在了沟通和等待上。

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

2.3、内视的黑洞

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

在企业IT团队中,从技术的维度看,技术运维团队往往有专业的技术能力,但从业务价值链看,技术运维团队又处于价值链的末端;从完整工作流来看,技术运维团队往往是最后一环,并不是站在IT大军的最前线。在价值认知的错位,信息隔离的情况下,如果没有完全的理性和足够的前线信息,技术运维人会形成种种负面自我,聚集成内视的黑洞。

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

2.4、自制的锁链

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

当初伴随公司的成长,部门为了管理系统化、正规化而建立了KPI、规范、流程、标准、预算、成本、编制等各种制度,它们的出现就是为了让运维工作变得有序、有计划、有规划,而且初期都起到了较好的效果。但是在某些情况下,这些制度将会展现暗黑的一面,成为组织的枷锁和束缚,例如:

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

1、制度和流程被过度执行,无视人的能动性,所有的人都被制度和流程牵着走,团队的创造性被阉割。

4.4 新的焦虑

2、制度和流程所指导和约束的事物本身一直在变化中,但制度和流程跟不上变化的节奏,最终变成工作的负担和腐朽的锁链。

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

3、重视管理者的需求,忽视用户和前线的呼声,遗忘制度和流程建立的初衷,制度和流程最终变成皇帝的新衣。

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

2.5、自动化短板

5、加速-注重效率和成本5.1 基础软件去商业化

IT运维队伍走到一定的能力水平和规模,都会开启运维工作自动化建设的阶段,且开始都会被赋予解决种种问题的美好预期。而往往IT运维队伍发起的自动化工作更优先解决的是运维团队自身的问题,不一定优先站在用户的角度考虑。

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

我们在2015年下半年到2016年上半年开始运维自动化;本来预期可以节省人力并提高效率和质量,但是结果却不尽人意。自动化的任务结束了,整体交付效率并未出现质的变化,用户也没有变得满意。回顾原因的时候终于明白我们都是做的执行末端的自动化,即将以前手工执行工作自动化了,解决了运维执行人员自己的问题,但并没有解决这个交付工作流效率低下的问题。因为一个用户需求提出从评审,到变更,最终反馈给用户,这个过程非常漫长。很多人做的自动化只是把自己的执行工作自动化了,用户感觉不到任何改善。

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

三、运维的梦想

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

经过一系列的反思和自我审判,我们看到技术运维团队肌体未老先衰,总结如下:

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

1、失去创造力,所做工作限于维持现有技术和架构特征类型系统的可用性,未能系统性展开前瞻性整体技术能力建设工作以支撑公司未来发展对于IT底盘技术的要求。

5.2 完善服务体系

2、视野萎缩,所做规划和设计工作关注于自身痛点,无法从公司业务发展对IT底盘能力的广度和纵深进行有效展开。

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

3、日渐官僚,流程等规则制度成为挡箭牌和隔音墙,团队暮气重重,不再能够为前线需要技术炮火的时候提供有效支撑。

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

4、坐而论道,关注技术本身而疏于价值贡献,无法挂钩和跟进公司技术战略。

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

总结至此,感觉技术运维团队已是寒山夜雨,千山暮雪,如何打破身与心的牢笼,实现自我救赎?经过多轮的思索和头脑碰撞之后,我们认为技术运维工作的理想情形当为:

5.3 日常工作自动化

第一:工作信息必须是流通和共享的,信息是在考虑了安全和工作职责的基础上对原始数据过滤后的结果,技术运维人员能够看到工作所需的所有信息,技术运维和被服务对象都在同一个信息平面上沟通和协同。第二:交付类工作应该是基于全流程端到端自动化的,即自助的。用户需要什么交付不再需要提前沟通后发起流程,而是直接在终端工作界面上即可获取。其自助获取资源在各方面的合规性由系统植入规则引擎来保障。第三:关键专业技术能力服务化,实现跨部门工作能力依赖解耦。涉及对专业技术细分领域的依赖型工作,由技术运维方以终端工作台的形式提供,需求方可以自助使用,无须需求方提服务流程和排队等待。第四:常规事件和异常实现自反应和自愈,让运维工作变得相对智能,在提高系统可用性的同时达成工作减负、降低成本的目的。四、筹谋

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

方向已经清晰,目标就在彼岸,如果到达呢?更谨慎的执行、更负责任的态度、更细颗粒度的管理都解决不了问题,唯有突破现有思维模式,基于现状而不限于现状才有出路。我们决定从如下六个方面进行突破:

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

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

5.4 仍然焦虑

2、专业技术支撑团队有责任通过系统化的方式提供便捷的自助渠道,实现和关联依赖团队的能力解耦。

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

3、业务为先,在工具平台打通之前,从现有专业团队抽调精干力量,组成全栈技术能力运维团队,支持敏捷产品团队的运维支持工作。

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

4、不降低运维质量的要求,原有ITIL的管控环节抽象成规则逻辑,植入工具平台。

一是流程重,以 ITIL 理念设计的流程更看重质量,效率不能很好的兼顾,人和事被流程牵着走;二是自动化,把整个流程拉开来看,从需求的发生到结束,自动化只是替代了末端执行环节的手工作业而已;三是架构弹性弱,高峰应对的扩容评估、压力测试、扩容执行周期长,是“人肉”祭场。四是技术架构纵深层次多,部分重要数据要在 SAN 集中存储,数据存储单点如鯁在喉,是运维人心头上的一根刺,急待解决。6、狂奔重定义架构和专业6.1 基础运维十字架

5、所有自动化工作秉承端到端的用户思维,让用户能够自助式的享受服务,原有流程环节,通过规则引擎植入运维系统,对用户透明。

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

6、持久化内容存储必须是可编程的,可扁平技术架构,降低工作依赖层级,同时也可进一步让IT设备统一X86化。

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

经过全面的考量之后,我们启动了下面五个任务:

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

丰箱: 容器自动自助的可视化管理平台,实现容器在顺丰技术架构标准规则下的自动创建和扩容即日常维护,同时实现和应用发布流程的无缝对接。丰云: KVM集群自动自助的可视化管理平台,优先实现KVM虚机在顺丰技术架构标准规则下的自动创建和扩容即日常维护,最终实现和应用发布流程的无缝对接。维石: 顺丰技术自动化运维的大脑,是运维信息流通和运维规则自动应用的核心,是最终面对用户的终端自助工作台提供方。ThinkDB: 基于X86的高可用的数据库池管理系统,其承担了解除高容量高性能DB对SAN存储依赖的使命,同时进一步提高DB的可用性和数据库运维工作的简易性。OSS: 文件型对象可编程存储系统,目的是对文件型存储可编程化,解除对NAS的需求,让这类型的所有运维规则和数据能够回归线上。

6.2 重新定义专业和能力6.2.1 专业重定义

对于其中的主干任务维石,任务组在年初制订了非常完美的计划,计划在2017年4月初把资源交付做到自助,到7月份就转入优化阶段。

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

五、碰壁

再一次,我们需要重新组织队伍:

在美好愿景的驱动下,我们从原有专业组抽调了部分力量组成需求团队,研发实现团队主要是没有做过运维工作的Java工程师,然后大家热火朝天的开干了,不想刚迈开步子即踏入炼狱,进入到为期两个月的无尽循环。

一是技术团队不能只做日常工作,一定要沉下心做专业领域的研究;二是运维团队上浮,日常基础架构运维团队聚焦应用,基础架构运维人很多时候根本不了解应用系统,也不关心主机、存储和网络上跑什么系统,每次出现问题处理的要求时,大家都各讲各话;三是研发团队聚焦,聚焦在打通专业壁垒,做到更彻底的运维自动化。6.2.2 去掉中间环节

需求泛滥,每个专业组需求很多,即使这些需求不在任务主目标的关键路径之上,也都想把自己的痛点扔给项目团队并被优先解决。需求理解偏差大,运维不懂研发,研发不知运维,需求和实现团队始终无法就需求规格说明达成一致以展开工作。任务管理方法运用不当,邯郸学步,一开始就希望用我们本来就不太熟练的产品和敏捷方法来进行管理,结果成了东施效颦、徒具形式而已。越俎代庖和用力过度,由于之前没有做个综合型研发项目,基础的职责没有厘清,大家凭热情和喜好做事,工作无法有效展开。。纸上谈兵,大家会议上讲的内容和计划的完全不一样;会后反应的也不一样,言行背离。

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

如此种种不顺,两个月下来,参与这个任务的同事们,不管是做需求的还是做架构的,大家天天指责对方而没有结果,疲惫且痛苦着。传统运维转运维研发的艰辛,远远超出了当初的预期。

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

陆陆续续的,有成员开始放弃,平台和前端研发有人离开了,产品经理也不玩了,架构师也跑路了。

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

六、面壁

6.2.3 优化技术架构

痛定思痛,关键人员集体面壁,对任务进行回顾和反思,最终制定了如下的五条规则:

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

第一条:规范需求,坚持价值导向。需求很多没有问题,但需要排队,优先级看还要看这些需求本身的价值和在关键路径上是否核心依赖;第二条:拉近认知,让运维的需求方和研发一起背靠背做研发;第三条:看清事情本质,不玩时髦概念,放下包袱,相关工作以更轻更高效的形势来做;第四条:言行一致,规范我们的计划和过程管理,保障说的和实际做的,以及对外公布的信息保持一致;第五条:职责回顾,大家各自重新把自己的职责厘清并遵守。七、破壁

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

客观和理性再次成为行事的主流,大家停止了相爱相杀式的争执,运维大脑Vishnu的设计理念终于出炉。

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

1、以KVM、Docker、OSS、ThinkDB提供的标准接口为基础,实现底层资源的可编程;原有SAN、NAS、LB硬件设备以封装原子服务的形式实现资源分配的可编程;

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

2、包括DB、MW、MQ在内的OS之上的软件服务以封装原子服务的形式实现;

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

3、以编排框架实现完整工作流的编辑和管理;辅以任务管理的能力做时间排程;

7、新故事-维X

4、具体的架构和运维规则逻辑在上层功能模块实现;

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

5、通过权限认证模块实现登陆和鉴权的处理;

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

6、面对用户主体功能模块包括自助交付服务、自服务、自适应和管理视图模块。

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

按照这种理念,维石的雏形如下:

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

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

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

1、专业组充当好资源的供给方即可,只需做好在线资源的库存管理;

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

2、需求方也无需在通过工单系统进行拆单派单,直接在维石工作平台上获取资源即可,而且最终也给出了良性的反馈:“终于可以优雅的工作了”。交付效率更是较之前整体提高了1到2个数量级;

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

3、大量常规变更无需由于担心误操作风险,而集中到晚间人手最紧缺的时候执行,人和可工作时间的逆向差瓶颈被打破;

文章来自微信公众号:高效运维

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

维石和VM

八、现在和未来

走到今天,我们仍然在加强运维研发能力的建设:

更有效的需求发现和管理。系统代码质量的提升。建设自动化测试框架,提高测试效率和质量。更适合运维的技术框架和平台架构。更简洁有效的任务组织形式。

我们体会到以前认为不可能的事情经历摸爬滚打下来,只要努力去做,是可以实现的。可以预期的是,再过一年,还可以达到部分自适应和自愈的运维程度。

九、运维的自由

最后,希望广大运维人是自由的。心的自由,无需时刻诚惶诚恐、如履薄冰,担心无法按时交付误事,担心系统出故障。这个梦想,希望广大运维同路人一起来实现!

原文来自微信公众号:高效运维

本文由yzc216亚洲城发布于亚洲城动态,转载请注明出处:顺丰IT幼功结构运行的焦躁与进步,顺丰运行的上

关键词: 亚洲城官网 yzc216亚洲城