本文整理自 GOPS2017.北京站演讲《魅族持续交付平台建设》,高效运维社区致力于陪伴您共同成长。 主动应对变化和风险是做好运维的一个重要能力,魅族运维团队通过构建持续集成平台提高应对变化的能力,实现主动应对变化提高效益的价值目标,向用户以及产品团队提供最高效最好的交付体验。通过这段自研历程希望能给大家带来些的启示。运维能交付的价值不是背锅,填坑和救火。我们能交付更多的价值,价值不在别人眼里而在自己手里。 一、互联网发展带来的运维问题1.1 魅族发展史 2003年到2008年是互联网1.0时代,2003年魅族成立,当时公司的主营业务是MP3,互联网业务只有官网和BBS。 2009年到2010年是互联网2.0时代,2008年公司推出了领先中国智能时代,公司从MP3业务转型到了手机业务,互联网作为基础的支撑服务,有电商BBS和云端服务,这个时候有了真正的运维和服务端开发和主动复制。 2012年到2013年是互联网2.5时代,MA率先登陆了安卓平台,互联网的主要功能是做手机的固件的更新以及互联网产品的迭代,这个时候的互联网业务有官网电商以及微信微博活动,这个时候架构就比较复杂,出现了数据库的分库分表,存储使用了MFS,前端的调度使用了GSB等等, 2014年以后进入了互联网3.0+时代,主要的互联网业务有游戏中心、应用中心、多媒体、O2O这些,这里有一个重要的标识就是互联网运营成为公司的主营业务之一,一个系统两个平台多个生态,以云平台和大数据为支撑,打造开放共享的生态。 1.2 时代变迁带来的运维挑战互联网从1.0到3.0的变迁给我们运维带来了什么? 首先是从质量上来说,我们遇到了各种坑,有硬件的、架构的、我们的业务可用性比较低,监控覆盖率比较低,可能会造成各种监控的漏报误报,变得监控不可用。 监控的可信度比较低,我们的流程和自动化没有很好的结合起来,成本没有制订比较贯穿的流程,导致流程不完善,工作不透明,没有建立一些容量的体系,就是我们没有办法评估业务使用的容量怎么样,使用的资源怎么样,也没有办法对业务的一些资源进行评估。救火,填坑,背锅成了常态。让人不禁的开始思考运维存在的价值问题以及如何实现价值。 那么如何去实现运维的价值呢?这些价值如何衡量?我们通过:“质量、效率、成本、安全、”这四个维度来衡量。
围绕运维的四个业务就需要有四个团队来支持,比如质量由运维优化团队负责,效率由运维开发团队掌握,基础运维团队可能就会掌握一些成本的东西,还有安全运维相关的建设,以价值为导向我们建立了一些系统。 1.3 魅族运维平台介绍二、魅族持续发布平台2.1 发布平台演进历程 魅族发布平台经历了周发布、日发布、自助发布的发展历程。最早的发布肯定是经过人肉的发布,对于当时的情况业务只是简单的进行发布,因为他没有任何流程的限制,但是当业务增多的时候,人肉肯定扛不住了,这个时候运维发布平台自然而然的出现了。 我们前期的架构比较简单,我们对每台有服务端的机器下发命令和任务,解决了一部分问题。但是它的发布效率和成功率比较差,可能会做一些误操作之类的,基于这种情况我们构建了一些和发布相关的指标,打通了业务的模块进行关联,保证提升我们的发布效率和比较好的容错性。 为了让发布做得更灵活,我们就会把我们发布的审核权限下放给各个业务,由业务的负责人进行审核,发布流程就不需要运维进行参与。 发布平台的现状,我们现在有一些特点,比如我们的发布策略比较多,有自助发布、组发布、一键重启、静态文件发布等等,我们支持比较多的类型,比如jetty、task、static等等。右图的就是比较直观的展示,首先看我们的发布成功率,始终保持在98%以上,我们的自助发布率是逐步上升的,我们是有90%的业务迭代发布是不需要运维进行操作的。 我们看一下现在整个的交付流程,分为三个环境,比如我们有开发的环境,有测试环境,有生态环境,开发人员拿到需求以后,可能会在本地写代码,写完代码以后可能会进行一些测试,比如说在本地测试或者在服务器上验证,验证以后触发了构件,就会在平台上填写单,测试人员就会手动或者自动的进行发布,运维人员准备基础环境,提供自动部署服务,并进行日志收集、报警监控应用快速扩容。 2.2 发布平台交付流程这是一个微妙的平衡,这种平衡在我们有一套完善的技术战和环境自动化的流程上,我们的团队技术框架尽可能的稳定,有良好的技术文档和技术积累,团队成员比较稳定的情况下,这是没有什么问题的,但是如果这个平衡被打破了,比如有一些流程没有被遵守,或者说有一些无关的员工离职,我们的架构变化的比较快,这个时候整个平衡就会被打破,变成了交付不可完成。 2.3 交付流程存在的问题看一下我们现有的交付存在什么问题。 2.4追求价值交付发布需求 首先在最底层是一些开发框架,云平台能保证我们环境的落地标准化的流程,保证交付所有的系统都是标准化的,在那之上,就是开发框架,本来就是我们的技术委员会推广的各种服务和框架,保证我们的技术比较统一,架构比较稳定,有比较丰富的技术文档和技术沉淀之类。 之后建设持续交付的流水线,持续交付的流水线核心原则就是标准化流程化自动化,里面会定义比较多的流程和规范,比如开发代码质量的规范以及开发的代码发布的一些流程。基于这个核心原则,我们建设了一些子系统,比如配置管理的,持续集成的,环境自动化的一些集成自动化的东西,能达到一个可靠可重复的持续发布的流水线。 可能包括用户提交测试阶段的并行研发,编译构建,单元测试,测试与验证阶段的环境部署,系统测试,以及集成测试,发布会的生产交付以及生产质量相关的东西,都是在这一个平台上进行运行的,我们还可以建立起来项目管理的一些子系统,获取到开发的一些效率,开发的一些其他数据,一些质量的数据,这个平台上会有不同的用户在使用,比如有开发测试运维,有项目经理,能打破各个团队的一些职能壁垒,能对得到进行相互促进的作用。 三、持续交付平台演进之路3.1 标准化建设我们运维进阶之路可以分为三个阶段,分别是标准化、自动化、智能化。 第一步,定义标准标准为基础的,我们看一下我们现在定义的一些标准流程, 第二步,技术选型 建设持续交付流水线的过程中,可能会有很多种做法,一般会讲两种。
像我们的运维这边发布平台可能都会有规范,比如说像发布平台,每个机房有哪些服务器,服务器上跑了什么模块,哪些机器有生产环境,我们环境的自动化也是一样的,都是基于我们的业务处来运行。 但是开发这边使用的各个平台都是全开源的,比如之前使用的jekins都是全开源的,完全就没有进行改造,这个时候就会有问题,它里面的名字之类的标识完全都是自定义的,想改造确实是比较麻烦。 第三步,统一入口为了打造持续交付的平台,我们的做法就是做一个统一的入口,例如在jekins构建,我们把构建的操作移入到我们的持续交付的平台上面去。 我们通过调用jekins api这些,之前我们是做需求管理以及bug跟踪,这个时候我们就可以把需求管理和bug跟踪录入到平台里,像bug管理我们在持续交付的平台录入,这样我们就能保证收集到我们想要的数据,我们某一个需求遗留的bug是多少,修bug的时候怎么修,保证两方的冲突比较小。 之后的路径是怎么样?这个平台会有多种的用户在使用,可能有开发人员、测试人员、运维人员、项目经理之类的,我们会把相关的一些信息同步过来,把这些人员的信息录入。 其次是还会记录某个项目模块中它的一些和发布相关的信息,比如IT发布,特的发布类型是什么,它的git路径是什么,因为这些东西会和构件有关联,把这个东西和我们的服务器结合起来。 3.2 自动化建设第一阶段,持续集成流程梳理首先项目经理会提一些需求,录入进来,这个时候是一个需求的阶段。 其次,我们的开发负责人会针对这个需求进行评估,进行一些分析和预演之类的,评估出来项目交付的日期,这个时候就进入开发阶段,这个时候我们的开发就按照需求进行,当然可能我们的开发也要遵循我们的开发规范,开饭完了以后可能就会提交代码,就会触发编译构件,之后我们会有一些静态的扫描。 如果这个扫描满足我们之前的测试的标准,那么这个时候就会进入到测试阶段,第一部分就会进行测试发布,测试发布以后就会有一些自动化的测试,里面包括我们进行接口相关的测试,我们进行安全的测试,我们进行性能方面的测试,甚至可能有一些时候我们需要进行一些手工的验证,如果这个时候验证不通过,可能就会开发以后再修复,如果验证通过我们就可以把这些东西发到生产阶段。 生产阶段的时候,我们会有开发或者运维的人进行一些审核,审核完以后我们进行灰度发布,发布完了以后会验证,用自动化的程序来验证它的安全性是怎么样,接口通过率怎么样,这块结束以后我们就会进行一些生产的发布。 第二阶段,发布流程梳理从需求到发布的阶段,整个它的工作流程或者生命周期的管理都会在这一个平台上进行管控,可以给整个交付流程会有一个比较可视化的进度管理。 我们单独看一下发布流程。
最后总的发布就完成,我们可以选用串行发布和并行发布,保证我们发布的成功率,也能保证我们比较快的发布效率。 第三阶段,确认产品研发模式有了持续交付平台就能保证满足互联网研发的模式,现在我们都会使用一些比较常用的,比如极速的迭代模式,整个平台上可以满足需求和进化阶段,比如迭代性的需求和进化阶段,迭代中的开发测试和发布,还有迭代后的回顾。 第四阶段,价值数据的驱动和输出完成了这些以后我们会有价值数据的驱动和输出。 首先这里会有几方面的数据,在代码的一些规范性上面,我们可能会评估有严重问题是多少,阻隔问题有多少。 在代码的可读性上,可能会有一些重复率之类的,还有一些接口和单元测试,我们单元测试的覆盖率怎么样,通过率怎么样。 我们的接口测试的通过率还有一些像性能测试的一些数据,安全测试的一些数据,甚至我们的人员构建的成功率之类的,还有发布的一些成功率,还有发布的效率。 总之我们可以根据一些代码的规范,代码的可读性,接口和单元测试以及安全这几个方面,可以知道一个项目它从开始到现在它所有的质量数据的变化,通过这些质量数据的驱动能提升技术的能力,把系统上线前质量是OK的。 当然我们还可以根据这些数据来考核我们的相关得子系统。 四、发展与展望—向进军智能运维回头看一下我们的进阶之路,包括了像标准化、自动化、智能化,智能运维是根据收集上来的数据进行有监督或者不监督的学习,从而达到预测和分析的目的。 这里我们最常见的就是预测和分析,比如说我们有基于机器学习的系统优化,比如参数的一些优化,当然还有一些预测,比如根据我们的预报的数据统计说我们最近硬盘的换盘率特别多,我们是不是能预测说我们的数据硬盘什么时候损坏。 其次还有可以根据我们的一些数据进行效率上的提升,比如说像故障方面,就是故障的发现,故障定位和故障处理,首先根据我们收集上来的监控数据,我们基础监控的数据,还有网络监控的数据,应用监控的数据,还有业务监控,甚至还有我们服务的调用的数据,根据这些数据我们会对我们故障的分析故障的发现和故障的定位做一个比较有力的支持。 甚至达到故障预测,这里可能就会包括一些数据中心的故障的预测,因为这个东西在当时肯定是全瘫痪了,那么像这种故障能否做到事前的预测,这就是我们现在要解决或者想进一步解决的一些问题。 END |
|
来自: Bladexu的文库 > 《技术文摘》