本文整理自 GOPS2017.北京站演讲《魅族持续交付平台建设》，高效运维社区致力于陪伴您共同成长。
主动应对变化和风险是做好运维的一个重要能力，魅族运维团队通过构建持续集成平台提高应对变化的能力，实现主动应对变化提高效益的价值目标，向用户以及产品团队提供最高效最好的交付体验。通过这段自研历程希望能给大家带来些的启示。运维能交付的价值不是背锅，填坑和救火。我们能交付更多的价值，价值不在别人眼里而在自己手里。
作者介绍：
李恒
2009~2015 就职于金山软件，任职猎豹移动开发经理。参与金山云云存储开发和维护，目前就职于魅族，任运维架构师，负责魅族云平台虚拟化及基础设施监控等研发。
一、互联网发展带来的运维问题
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 魅族运维平台介绍
-
资源管理系统
首先，魅族运维团队在资源管理系统上建立了业务树，通过KVM和Docker建立了云平台，组成了以基础的虚拟化计算网络和存储构成的计算机资源管理系统。并通过CMDB进行管控。
-
配置管理系统
配置管理上魅族运维团队建设了IOS的管理系统，CDN的管理系统，DNS的管理系统，并提供了相应的API。
-
自动化系统
在自动化系统方面，魅族运维团队建设了工单系统、日志系统、发布系统、应用管理系统、自研运维通道、自动巡检系统，帮助运维解决了交付和变更以及相关的效率。
-
监控系统与容量管理
监控与容量方面，我们首先建立了基础监控，制订监控业务监控等一系列监控设施，建立了容量体系，对服务器的容量和内存利用率以及带宽利用率，机房的每个业务的带宽使用的情况怎么样，这样就可以精确的衡量每个业务使用了多少资源，资源的利用率如何。
-
安全系统
在安全维度上魅族运维团队建立了堡垒机，运维所有的登陆都会经过它，通过堡垒机进行管控和审计用户的操作，我们还建设了WAF系统和漏洞管理系统，这个系统可以主动的发现和攻击漏洞，把漏洞转化成我们自有的漏洞管理系统进行迭代修复，并且根据漏洞做积分，对业务进行考核。
二、魅族持续发布平台
2.1 发布平台演进历程
魅族发布平台经历了周发布、日发布、自助发布的发展历程。最早的发布肯定是经过人肉的发布，对于当时的情况业务只是简单的进行发布，因为他没有任何流程的限制，但是当业务增多的时候，人肉肯定扛不住了，这个时候运维发布平台自然而然的出现了。
我们前期的架构比较简单，我们对每台有服务端的机器下发命令和任务，解决了一部分问题。但是它的发布效率和成功率比较差，可能会做一些误操作之类的，基于这种情况我们构建了一些和发布相关的指标，打通了业务的模块进行关联，保证提升我们的发布效率和比较好的容错性。
为了让发布做得更灵活，我们就会把我们发布的审核权限下放给各个业务，由业务的负责人进行审核，发布流程就不需要运维进行参与。
发布平台的现状，我们现在有一些特点，比如我们的发布策略比较多，有自助发布、组发布、一键重启、静态文件发布等等，我们支持比较多的类型，比如jetty、task、static等等。右图的就是比较直观的展示，首先看我们的发布成功率，始终保持在98%以上，我们的自助发布率是逐步上升的，我们是有90%的业务迭代发布是不需要运维进行操作的。
我们看一下现在整个的交付流程，分为三个环境，比如我们有开发的环境，有测试环境，有生态环境，开发人员拿到需求以后，可能会在本地写代码，写完代码以后可能会进行一些测试，比如说在本地测试或者在服务器上验证，验证以后触发了构件，就会在平台上填写单，测试人员就会手动或者自动的进行发布，运维人员准备基础环境，提供自动部署服务，并进行日志收集、报警监控应用快速扩容。
2.2 发布平台交付流程
这是一个微妙的平衡，这种平衡在我们有一套完善的技术战和环境自动化的流程上，我们的团队技术框架尽可能的稳定，有良好的技术文档和技术积累，团队成员比较稳定的情况下，这是没有什么问题的，但是如果这个平衡被打破了，比如有一些流程没有被遵守，或者说有一些无关的员工离职，我们的架构变化的比较快，这个时候整个平衡就会被打破，变成了交付不可完成。
2.3 交付流程存在的问题
看一下我们现有的交付存在什么问题。
-
在质量上
，我们的代码单元这次有没有通过，覆盖率怎么样，有没有遗留bug，接口测试覆盖率怎么样，能不能通过。
-
在效率上
，自动化部署，自动化测试，自动化构建，这些分散在各个智能部门，没有和流程打通，这就造成一些浪费，我们没有办法做到精细化的运营，
-
在成本方面上
，就造成我们的沟通成本比较高，交付变得比较复杂。
-
在安全方面上
，如开发代码有没有安全问题，有没有进行安全测试。
2.4追求价值交付发布需求
首先在最底层是一些开发框架，云平台能保证我们环境的落地标准化的流程，保证交付所有的系统都是标准化的，在那之上，就是开发框架，本来就是我们的技术委员会推广的各种服务和框架，保证我们的技术比较统一，架构比较稳定，有比较丰富的技术文档和技术沉淀之类。
之后建设持续交付的流水线，持续交付的流水线核心原则就是标准化流程化自动化，里面会定义比较多的流程和规范，比如开发代码质量的规范以及开发的代码发布的一些流程。基于这个核心原则，我们建设了一些子系统，比如配置管理的，持续集成的，环境自动化的一些集成自动化的东西，能达到一个可靠可重复的持续发布的流水线。
可能包括用户提交测试阶段的并行研发，编译构建，单元测试，测试与验证阶段的环境部署，系统测试，以及集成测试，发布会的生产交付以及生产质量相关的东西，都是在这一个平台上进行运行的，我们还可以建立起来项目管理的一些子系统，获取到开发的一些效率，开发的一些其他数据，一些质量的数据，这个平台上会有不同的用户在使用，比如有开发测试运维，有项目经理，能打破各个团队的一些职能壁垒，能对得到进行相互促进的作用。
三、持续交付平台演进之路
3.1 标准化建设
我们运维进阶之路可以分为三个阶段，分别是标准化、自动化、智能化。
第一步，定义标准
标准为基础的，我们看一下我们现在定义的一些标准流程，
第二步，技术选型
建设持续交付流水线的过程中，可能会有很多种做法，一般会讲两种。
