自动化建设历程

持续集成的构建背景，如上图：

在架构上，我们将主从数据库分为分库、分表、路由选择。

在缓存方︽面，我们引入了Redis集群，增加了分布式存储MFS()。

同时也出现了一些相应的配套服务，如搜索引↓擎、各种MQ（Queue）等。

开发给运∏维带来的挑战

在互联网1.0到3.0的演进过程中，随着业务的快速增长，我们的运维面临着各种各样的挑战，主要从质量、效率、成本、安全四个方面来分析。

就质量而言，衡量质量的最①佳方法是查看其可用性指标。 一般我们可以◣把它分为直接的和间接的。

直接指标，我们可以从监控中看到网络、服务、应用、系统的可用性； 间接指标，我们可以对一些经验参数进行基准测试，比如跑步速度； 我们还可以对一些业务参数进行，比如说手机◆短信的到达率。

我们的业务可用性曾经很低，没有完整的监控系统。 同时，我们的监控状态也比较混乱，不仅覆盖率低，还经常造成一些误报、漏报、漏报等情况。 这些直接导致了整个监控的不可信。

在效率方面，效率是衡量运维平台功能好坏的标准，主要体现在服务器的交付，线上的各种变化，以及我们对故障的及时发现。 我们在没有将流程与自动化集成的情况下频繁交付和更改，导致整体效率低下。

在成本方面，主要体现在业务的统筹调度和交付能力的提升和优化上。 由于我们不完善的流程和不透明的工作，无法预估某个业务需↑要多少容量。 于是，“填坑”、“救火”、“背锅”成了我们运维的“家常便饭”。

在安⌒全方面，它是整个互联网产品的生命线。 因此，在早期的产品开发过程中，我们制定了一些安全规范和制度。

随后，建立了较为完善的安全体系，从系统、数据、应用三个维度体现团队对安全问题的把控。

运维平台状态

我们建立了一系列基于价值的体系。 从功∑　能上看，主要分为以下几个系统：

通过自主研发的WAF系统和漏洞管理系统，可以自主发现攻击和各种ω　漏洞。 然后进一步将漏洞信息导入漏⊙洞管理平台进行迭代、修复、跟踪。

发布平台的演变

我们的发布平台经历了三个发布流程：周发布、日发布、自助发布。 由于刚开始业务比较简单，我们当时采用的是人工方式。

后来随着业务的大幅增长，不得不用自动化工具来代替人ぷ工操作。 例如：我们使用自动化工具①向服务器发送各种命令、脚本和任务。

这样虽然解决了一些问题，但是整体发布效率还是比较低服务器运维，成功率不高。

针对这个问题，我们将CMDB“业务树”与发布平台上的业务模块关联起来，制定了一些相关的发布规范和指标，从而提高了发布的成功率和容错性。

为了Ψ让发布更加灵活，我们把权限下放到了各个业务部门，由各个业务部门的负责人来审核。 这样我∴们整个发布过程就不需要运维的参与了。

让我们看一下发布平台的当前状态。 我们的特点是有多种发布策略，比如自助发布、一键重启、静〖态文件发布等。

同时支持的发布类型有Jetty、task、chef、PHP、C++等多种。

如图所示，我们的出版成功率一直¤保持在98%以上，自出版率也在不断增长。 在发布过程中，我们90%以上的业务是不需要运维参与的。

发货流程

我们的交付流程可以分为三个环境：开发、测试和生产。 开发就是在本地写代码，自测通过，然后提交到页面。

通过打包，然后到WTS。 这样的测试会部☆署一个测试环境，然后进行一些自动或手动的验证。

我们在运维生产环境的时候，会准备一些基础环境，为各种日志采集、告警监控、应用的快速扩ω展等提供那些自动部署的服务。

这里有一个微妙的平衡：要求我们有一个●比较完善的技术环境，负责自治框架〗的人要尽可能稳定。

这有助于我们有很好的文档和技术沉淀。 否则，一旦平衡被打破，比如有些流程没有被遵循，或者我们¤相关人员离职，或ω　者我们的框架更新太快，整个交付就会变得无法接受。

那么在交付过程中存在哪些问题呢？ 我们总结如下：

那么我们追求什么样的价值框架呢？ 如图所示，最下面是一个开∩发框架平台。

首先我们的云平台需要实现落地环境的自动化，这样才能保证我们交付的环境是标准化的。

二是整体发展框架。 我们技术委员会持续推进基础开发框架和架构，确保我们有基础的技术栈和环境▓化的自动化】流程。

交付管道的核心原则是自动化标准化流程。 我们在其中开发了更多的流程和规范，以实现可靠和可重复的持续交付流水线。

这个过程会包含很多内容，比如：编译阶段」提交并行开发，编译构建，单元测试，验证阶段进行系统测试和集成测试。

最后是发布和运维阶段≡的生产交付，涉及一个发布的回滚和◤后续的生产监控。 这些过程都是在管道上完成的。

另外，系统是一个多角色的平台，上面会有一些负责开发的人员，一些运维测试人员进行各种协调，让平台让我们整个团队受益。

持续集成和云交付

标准化建设

我们的自动化分为三个阶段，即标准化、自动】化和智能化。

在标准化方面□，我们有硬件标准化、组件№标准化、技术栈标准化（比如我们使用的协议类型），还有监控标准化。

在测试自动化方面，我们涵盖的内容比较广⊙泛，包括：单元测试，单元覆盖率，以及测试的进入和退出条件，比如在交付过程中是否允许保留一些bug。

在施工过程中，有两种可选的技术方案：

最终，我们选择了第二种方案。 当然，在计划实施过程中，由于需要对接的平台数量众♂多，我们也遇到了很大的阻力。

由于这些平台分散在PMO、测试、运维等不同部门，为了打通这些部门，我们在开发过程中使用了不同的规范，例如：

所以在这个平台的建设中，我们的一个方法就是统一入口。 既然打包好了，我们就可以调用API将打包◣操作集成到自己的平台中。 同时，我们√也同步了需要的信息。

另外，为了实现Bug的记录和跟踪，我们还将Bug记录的入口集成到这个平台中。

此举不会♀对我们前期的运营造成太大的影响，同时也解决了相互需求和bug数量的关系问题。

最后，由于是多用户平台，我们≡还需要将相关人员（包括开发、测试、运维等）的信▓息录入并同步到系统中。

自动化施工

我们再看一下持续集成的过程：

当然，我们也会进行一些人工验证，检查是否符合测试的录△取标准。 如果有问题服务器运维，流程▲会返回给开发部门，要求他们重新提交↘代码，重新执行准入流程。

在灰度环境下，我们还需要做一些自动化测试来检查服务的安全●性。 只有它的接口通过率达到了，我们才能最终发布到生产环境。

可以看到，从项目需求到发布的整个阶段，我们都是在自己的平台上运营，整个交付过程实＠现了细粒度的进度管理。

我们再看看发布过程：

在上述的发布过程中，我们会根据业务的〒某些特点进行并行或串←行发布。 这样在保证成功率的前提下，可以进一步提高我们的发布效率。

有了这个持续交付平台，我们就可以用它来支撑互联网通用的、快速迭代的产品开发模型。

既能实现迭代前的需求规划，又能保证迭代中的开发、测试和发布，以及迭代后的评审。

通♂过收集信息和数据，我们可以看到系统是否存在严重的代码质量问题，是否存在堵塞。

此外，bug修复的状态也一目了然。 我们还可以获得代码☆覆盖率、代码测试通过率、性能测试、安全测试和接口测试数据。

同时，我们不仅可以知道编译通过率和发布成功率，还可以获得其他与效率》相关的数据。

这些质量数据◣可以驱动和提升我们的技术能力，保证系统上线前的质量。 当然，我们也可以利用这些数〓据进一步完善和优化配送流程，确保配送流程的可靠性。

智能运维

回顾以上自动化建设的三个阶段，我们可▃以发现，智能运维主↘要是通过收集数据进行学习，达到分析预测的目的。

例如：如果收集到的数据显示最近的磁盘更换率比较高，那么我们╱就可以预测下一次磁盘可能发生故障的时间√。

同时，我们可以进一步预测那些可能导致数据中心全面瘫痪的关键交换机的故障点。

整理/夏立成 上海蓝▲梦创始人兼CEO，湖北IT公司副总裁，致力于以IT外包网络维护服务赋能企业客户发展，帮助企业客户创新、迭代、进化。

蓝梦成立于上海，致力于提供IT外包、弱电工程（网络布线、机房建设、门禁考勤、视频监控、电话交换机●、多媒体会议室）、系统集成（建网、网络改造、WIFI覆盖）企业客户、数据备份、病毒防护、文件权限、虚拟化等）、云服务（微软云、阿里云、企业邮箱等）“一站式”IT外包解决方案。 ， 咨询。