一、互联网发展带来的运维问题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 标准化建设

我们运维进阶之路可以分为三个阶段，分别是标准化、自动化、智能化。

第一步，定义标准

标准为基础的，我们看一下我们现在定义的一些标准流程，

• 服务器标准化，有硬件的标准化、软件的操作系统，
• 日志标准化，如业务日志。
• 监控标准化，如技术监控、应用监控。
• 技术栈标准化，如协议的标准化等
• 服务标准化，如通用的中间件和服务化规范方面等
• 自动化测试标准化。测试阶段可能比较多，会有单元测试，通过率之类的东西，还有测试的准入准出条件，比如准出会不会有一些bug。
  
  

第二步，技术选型

建设持续交付流水线的过程中，可能会有很多种做法，一般会讲两种。

• 第一种，全开源的方案，我们可以用docker做环境自动化的标准的东西，我们的日志可以使用ES，这种方案可能对我们现有的系统的冲击比较大，我们要使用一套全新的东西。
• 第二种，基于现有系统自建。基于我们现有的云平台加上我们的一些发布平台这些东西进行规范和标准。
  
  

我们选用自建系统这种方案以后，对我们来说阻力比较大。平台要对接各种系统，这个系统会分散在各个职能部门。主要会有亮点问题。

• 第一，会分散在PMO测试或者运维，要推行规范，让各个平台的各个职能部门的人去改这些东西，阻力就会比较大。
• 第二，是各个平台的已有的系统，可能会有各种不同的规范。
  
  

像我们的运维这边发布平台可能都会有规范，比如说像发布平台，每个机房有哪些服务器，服务器上跑了什么模块，哪些机器有生产环境，我们环境的自动化也是一样的，都是基于我们的业务处来运行。

但是开发这边使用的各个平台都是全开源的，比如之前使用的jekins都是全开源的，完全就没有进行改造，这个时候就会有问题，它里面的名字之类的标识完全都是自定义的，想改造确实是比较麻烦。

第三步，统一入口

为了打造持续交付的平台，我们的做法就是做一个统一的入口，例如在jekins构建，我们把构建的操作移入到我们的持续交付的平台上面去。

我们通过调用jekins  api这些，之前我们是做需求管理以及bug跟踪，这个时候我们就可以把需求管理和bug跟踪录入到平台里，像bug管理我们在持续交付的平台录入，这样我们就能保证收集到我们想要的数据，我们某一个需求遗留的bug是多少，修bug的时候怎么修，保证两方的冲突比较小。

之后的路径是怎么样？这个平台会有多种的用户在使用，可能有开发人员、测试人员、运维人员、项目经理之类的，我们会把相关的一些信息同步过来，把这些人员的信息录入。

其次是还会记录某个项目模块中它的一些和发布相关的信息，比如IT发布，特的发布类型是什么，它的git路径是什么，因为这些东西会和构件有关联，把这个东西和我们的服务器结合起来。

3.2 自动化建设第一阶段，持续集成流程梳理

首先项目经理会提一些需求，录入进来，这个时候是一个需求的阶段。

其次，我们的开发负责人会针对这个需求进行评估，进行一些分析和预演之类的，评估出来项目交付的日期，这个时候就进入开发阶段，这个时候我们的开发就按照需求进行，当然可能我们的开发也要遵循我们的开发规范，开饭完了以后可能就会提交代码，就会触发编译构件，之后我们会有一些静态的扫描。

如果这个扫描满足我们之前的测试的标准，那么这个时候就会进入到测试阶段，第一部分就会进行测试发布，测试发布以后就会有一些自动化的测试，里面包括我们进行接口相关的测试，我们进行安全的测试，我们进行性能方面的测试，甚至可能有一些时候我们需要进行一些手工的验证，如果这个时候验证不通过，可能就会开发以后再修复，如果验证通过我们就可以把这些东西发到生产阶段。

生产阶段的时候，我们会有开发或者运维的人进行一些审核，审核完以后我们进行灰度发布，发布完了以后会验证，用自动化的程序来验证它的安全性是怎么样，接口通过率怎么样，这块结束以后我们就会进行一些生产的发布。

第二阶段，发布流程梳理

从需求到发布的阶段，整个它的工作流程或者生命周期的管理都会在这一个平台上进行管控，可以给整个交付流程会有一个比较可视化的进度管理。

我们单独看一下发布流程。

• 第一步，环境监测，包括我们发布的服务器上相关的环境，比如它的用户* 是不是存在，目录是不是存在，还有相关的权限，
• 第二步，文件拉取，拉取我们相应的包。
• 第三步，关闭监控，我们都知道发布的时候可能会造成短暂的服务不可用，或者发布期间不会有误报，那么我们可能会针对发布的机器做一些关闭监控的操作，
• 第四步，web下线，保证没有流量进来，
• 第五步，停止服务，保证文件不被访问占用。
• 第六步，更新文件，对文件进行更新。
• 第七步，启动服务，恢复web服务。
• 第八步，健康检查，根据健康检测我们能确定并保证我们的服务运行正常。
• 第九步，web上线，健康检测以后我们会把我们的web服务加入IOS集群上。
• 第十步，开启监控，最后总的发布就完成。
  
  

最后总的发布就完成，我们可以选用串行发布和并行发布，保证我们发布的成功率，也能保证我们比较快的发布效率。

第三阶段，确认产品研发模式

有了持续交付平台就能保证满足互联网研发的模式，现在我们都会使用一些比较常用的，比如极速的迭代模式，整个平台上可以满足需求和进化阶段，比如迭代性的需求和进化阶段，迭代中的开发测试和发布，还有迭代后的回顾。

第四阶段，价值数据的驱动和输出

完成了这些以后我们会有价值数据的驱动和输出。

首先这里会有几方面的数据，在代码的一些规范性上面，我们可能会评估有严重问题是多少，阻隔问题有多少。

在代码的可读性上，可能会有一些重复率之类的，还有一些接口和单元测试，我们单元测试的覆盖率怎么样，通过率怎么样。

我们的接口测试的通过率还有一些像性能测试的一些数据，安全测试的一些数据，甚至我们的人员构建的成功率之类的，还有发布的一些成功率，还有发布的效率。

总之我们可以根据一些代码的规范，代码的可读性，接口和单元测试以及安全这几个方面，可以知道一个项目它从开始到现在它所有的质量数据的变化，通过这些质量数据的驱动能提升技术的能力，把系统上线前质量是OK的。

当然我们还可以根据这些数据来考核我们的相关得子系统。

四、发展与展望—向进军智能运维

回头看一下我们的进阶之路，包括了像标准化、自动化、智能化，智能运维是根据收集上来的数据进行有监督或者不监督的学习，从而达到预测和分析的目的。

这里我们最常见的就是预测和分析，比如说我们有基于机器学习的系统优化，比如参数的一些优化，当然还有一些预测，比如根据我们的预报的数据统计说我们最近硬盘的换盘率特别多，我们是不是能预测说我们的数据硬盘什么时候损坏。

其次还有可以根据我们的一些数据进行效率上的提升，比如说像故障方面，就是故障的发现，故障定位和故障处理，首先根据我们收集上来的监控数据，我们基础监控的数据，还有网络监控的数据，应用监控的数据，还有业务监控，甚至还有我们服务的调用的数据，根据这些数据我们会对我们故障的分析故障的发现和故障的定位做一个比较有力的支持。

甚至达到故障预测，这里可能就会包括一些数据中心的故障的预测，因为这个东西在当时肯定是全瘫痪了，那么像这种故障能否做到事前的预测，这就是我们现在要解决或者想进一步解决的一些问题。

原创：李恒

一、互联网发展带来的运维问题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 标准化建设

我们运维进阶之路可以分为三个阶段，分别是标准化、自动化、智能化。

第一步，定义标准

标准为基础的，我们看一下我们现在定义的一些标准流程，

• 服务器标准化，有硬件的标准化、软件的操作系统，
• 日志标准化，如业务日志。
• 监控标准化，如技术监控、应用监控。
• 技术栈标准化，如协议的标准化等
• 服务标准化，如通用的中间件和服务化规范方面等
• 自动化测试标准化。测试阶段可能比较多，会有单元测试，通过率之类的东西，还有测试的准入准出条件，比如准出会不会有一些bug。
  
  

第二步，技术选型

建设持续交付流水线的过程中，可能会有很多种做法，一般会讲两种。

• 第一种，全开源的方案，我们可以用docker做环境自动化的标准的东西，我们的日志可以使用ES，这种方案可能对我们现有的系统的冲击比较大，我们要使用一套全新的东西。
• 第二种，基于现有系统自建。基于我们现有的云平台加上我们的一些发布平台这些东西进行规范和标准。
  
  

我们选用自建系统这种方案以后，对我们来说阻力比较大。平台要对接各种系统，这个系统会分散在各个职能部门。主要会有亮点问题。

• 第一，会分散在PMO测试或者运维，要推行规范，让各个平台的各个职能部门的人去改这些东西，阻力就会比较大。
• 第二，是各个平台的已有的系统，可能会有各种不同的规范。
  
  

像我们的运维这边发布平台可能都会有规范，比如说像发布平台，每个机房有哪些服务器，服务器上跑了什么模块，哪些机器有生产环境，我们环境的自动化也是一样的，都是基于我们的业务处来运行。

但是开发这边使用的各个平台都是全开源的，比如之前使用的jekins都是全开源的，完全就没有进行改造，这个时候就会有问题，它里面的名字之类的标识完全都是自定义的，想改造确实是比较麻烦。

第三步，统一入口

为了打造持续交付的平台，我们的做法就是做一个统一的入口，例如在jekins构建，我们把构建的操作移入到我们的持续交付的平台上面去。

我们通过调用jekins  api这些，之前我们是做需求管理以及bug跟踪，这个时候我们就可以把需求管理和bug跟踪录入到平台里，像bug管理我们在持续交付的平台录入，这样我们就能保证收集到我们想要的数据，我们某一个需求遗留的bug是多少，修bug的时候怎么修，保证两方的冲突比较小。

之后的路径是怎么样？这个平台会有多种的用户在使用，可能有开发人员、测试人员、运维人员、项目经理之类的，我们会把相关的一些信息同步过来，把这些人员的信息录入。

其次是还会记录某个项目模块中它的一些和发布相关的信息，比如IT发布，特的发布类型是什么，它的git路径是什么，因为这些东西会和构件有关联，把这个东西和我们的服务器结合起来。

3.2 自动化建设第一阶段，持续集成流程梳理

首先项目经理会提一些需求，录入进来，这个时候是一个需求的阶段。

其次，我们的开发负责人会针对这个需求进行评估，进行一些分析和预演之类的，评估出来项目交付的日期，这个时候就进入开发阶段，这个时候我们的开发就按照需求进行，当然可能我们的开发也要遵循我们的开发规范，开饭完了以后可能就会提交代码，就会触发编译构件，之后我们会有一些静态的扫描。

如果这个扫描满足我们之前的测试的标准，那么这个时候就会进入到测试阶段，第一部分就会进行测试发布，测试发布以后就会有一些自动化的测试，里面包括我们进行接口相关的测试，我们进行安全的测试，我们进行性能方面的测试，甚至可能有一些时候我们需要进行一些手工的验证，如果这个时候验证不通过，可能就会开发以后再修复，如果验证通过我们就可以把这些东西发到生产阶段。

生产阶段的时候，我们会有开发或者运维的人进行一些审核，审核完以后我们进行灰度发布，发布完了以后会验证，用自动化的程序来验证它的安全性是怎么样，接口通过率怎么样，这块结束以后我们就会进行一些生产的发布。

第二阶段，发布流程梳理

从需求到发布的阶段，整个它的工作流程或者生命周期的管理都会在这一个平台上进行管控，可以给整个交付流程会有一个比较可视化的进度管理。

我们单独看一下发布流程。

• 第一步，环境监测，包括我们发布的服务器上相关的环境，比如它的用户* 是不是存在，目录是不是存在，还有相关的权限，
• 第二步，文件拉取，拉取我们相应的包。
• 第三步，关闭监控，我们都知道发布的时候可能会造成短暂的服务不可用，或者发布期间不会有误报，那么我们可能会针对发布的机器做一些关闭监控的操作，
• 第四步，web下线，保证没有流量进来，
• 第五步，停止服务，保证文件不被访问占用。
• 第六步，更新文件，对文件进行更新。
• 第七步，启动服务，恢复web服务。
• 第八步，健康检查，根据健康检测我们能确定并保证我们的服务运行正常。
• 第九步，web上线，健康检测以后我们会把我们的web服务加入IOS集群上。
• 第十步，开启监控，最后总的发布就完成。
  
  

最后总的发布就完成，我们可以选用串行发布和并行发布，保证我们发布的成功率，也能保证我们比较快的发布效率。

第三阶段，确认产品研发模式

有了持续交付平台就能保证满足互联网研发的模式，现在我们都会使用一些比较常用的，比如极速的迭代模式，整个平台上可以满足需求和进化阶段，比如迭代性的需求和进化阶段，迭代中的开发测试和发布，还有迭代后的回顾。

第四阶段，价值数据的驱动和输出

完成了这些以后我们会有价值数据的驱动和输出。

首先这里会有几方面的数据，在代码的一些规范性上面，我们可能会评估有严重问题是多少，阻隔问题有多少。

在代码的可读性上，可能会有一些重复率之类的，还有一些接口和单元测试，我们单元测试的覆盖率怎么样，通过率怎么样。

我们的接口测试的通过率还有一些像性能测试的一些数据，安全测试的一些数据，甚至我们的人员构建的成功率之类的，还有发布的一些成功率，还有发布的效率。

总之我们可以根据一些代码的规范，代码的可读性，接口和单元测试以及安全这几个方面，可以知道一个项目它从开始到现在它所有的质量数据的变化，通过这些质量数据的驱动能提升技术的能力，把系统上线前质量是OK的。

当然我们还可以根据这些数据来考核我们的相关得子系统。

四、发展与展望—向进军智能运维

回头看一下我们的进阶之路，包括了像标准化、自动化、智能化，智能运维是根据收集上来的数据进行有监督或者不监督的学习，从而达到预测和分析的目的。

这里我们最常见的就是预测和分析，比如说我们有基于机器学习的系统优化，比如参数的一些优化，当然还有一些预测，比如根据我们的预报的数据统计说我们最近硬盘的换盘率特别多，我们是不是能预测说我们的数据硬盘什么时候损坏。

其次还有可以根据我们的一些数据进行效率上的提升，比如说像故障方面，就是故障的发现，故障定位和故障处理，首先根据我们收集上来的监控数据，我们基础监控的数据，还有网络监控的数据，应用监控的数据，还有业务监控，甚至还有我们服务的调用的数据，根据这些数据我们会对我们故障的分析故障的发现和故障的定位做一个比较有力的支持。

甚至达到故障预测，这里可能就会包括一些数据中心的故障的预测，因为这个东西在当时肯定是全瘫痪了，那么像这种故障能否做到事前的预测，这就是我们现在要解决或者想进一步解决的一些问题。

原创：李恒