亿级广告交易平台的自动化部署实践之路

雅虎广告交易平台是一个日访问量上亿级别的广告系统，运行在雅虎全球多个数据中心的一万多台服务器之上。在这样的规模下，手动进行部署维护已经变成了一项不可能的任务。一年多前，该平台的系统工程师们开始推动这套平台的自动化运维实现，并成功将原本需要一个月的部署周期缩短至一天。

本文基于 InfoQ 中文站在 Velocity China 2014 大会上对雅虎北京全球研发中心高级系统运维工程师黄俊意的采访整理而成，主要介绍他们在雅虎广告交易平台上推动自动化部署的经验心得。

受访嘉宾简介

黄俊意，雅虎北京全球研发中心高级系统运维工程师，毕业于西安电子科技大学，硕士，7 年多基于 Linux 的大型 Web 互联网应用系统运维经验，曾就职阿里巴巴中国应用运维团队，现供职雅虎北京全球研发中心，高级系统运维工程师，负责占雅虎收入三分之一的雅虎全球搜索广告产品的系统运维，专注于持续部署交付，监控和故障管理的自动化。

团队与服务概述

雅虎北京全球研发中心的 Service Engineer 大团队有 20 多人，主要对移动、云计算、广告这三个方向提供支持。广告这个方向有多条产品线，如搜索广告、图片广告、视频广告等，广告交易平台是其中的一条产品线。

雅虎广告交易平台服务全球市场，维护团队分别在中国和美国，中国北京团队这边目前有 2 位运维工程师负责该平台维护部署的工作。运维团队与产品、研发、测试团队紧密配合，对产品交付部署和线上服务的稳定性负责。

团队的目标主要有两个方向：稳定性方面，保障线上 4 个 9 的可用性，降低级别为 S0 的故障数量，整体故障时间比之前一个季度降低 20%；交付方面，主要是能够按时交付在产品路线图规划上面的发布计划。

为什么要做自动化部署

自动化部署作为一个项目启动于一年前，由运维团队发起。当时的情况是，研发团队的敏捷开发实践已经相当成熟，每两周做一次 sprint，每一个 sprint 都会发布几个 release。但当时每一次部署的实施周期在一个星期，因为服务器有上万台，部署之前需要详细的计划、审批，每天只能做 20% 的量。当时平均每次发布前，产品设计做一周，研发一周，测试一周，部署一周，一次发布就需要一个月的时间，导致新的 release 都要排期，已经不能满足产品的需求，运维这边压力很大。

所以这是我们业务上的直接需求。另一方面，自动化运维也已经是行业的大趋势，公司高层也看到了这个趋势。所以我们提出要实现自动化部署，研发非常支持，测试和产品也有共识，公司也认可，就启动了这个项目。

项目实现的流程

在雅虎，当成立一个项目之后，会有专门的项目经理来跟进管理这个项目，包括制定时间计划、制定目标、推动项目、检查实施情况、写报告等工作，这样运维团队可以专注在实现的工作上。

按照运维团队最初的设定，这个项目需要达到的效果就是让部署变得很简单：指定好目标部署环境和要部署的版本，点一下鼠标就能自动完成部署。

当时最大的难点在于两个地方：

1. 不同组件的部署方式不统一
2. 跟周边系统的集成很多

要解决这两个问题，需要争取研发、测试、产品部门的支持。整个过程不是一下子就能做出来的，需要长期的开发、实验、验证，逐步的实现。自动化是一整套流程，研发有 CI 自动化，测试有测试自动化，运维有部署自动化，上下游之间有依赖，都需要打通。这包括：

• 提交编译
• 打包安装
• 单元测试
• 性能测试
• 部署更新
• 检查反馈

要明确的一点是，自动化并不是用了“自动化工具”就行：自动化的核心目的在于让本来让人做的事情变成让程序做，“做的事情”是不变的，但工具并不知道我们做的事情是什么，需要我们去告诉它。比如 Jenkins，它能做的事情无非是你给它设定一些触发条件，让它在某些情况下去做某些事情（如下载、更新、检查）。它只是一个集成、交付的管理工具，本身是死的，只有我们将我们的逻辑输入到这个系统里面，它才能够为我们所用。

首先，为了让每个组件的部署能够统一在一个框架之下，我们需要跟每一个组件的研发沟通，让他们按照我们的规则提供接口（即 RESTful API）。后面做新功能的时候最好是在产品设计的时候就跟产品人员做好沟通，在功能设计的时候就将接口放进去。其实部署在所有服务器上都是一个流程：下载包；服务器从当前服务下线；安装更新；检查更新；通过检查后放回到线上。所以如果新模块一开始就遵循我们的接口，那它只要简单改改配置注册一下，很容易就可以进入这套体系。

然后是包管理机制的统一。在自动化部署实施之前，每个模块自己打一个包，包管理机制各自不同。比如你用 yum，有的包可能会需要去跨网获取依赖，依赖的包可能还有依赖。你在单机上用 yum 没问题，但是一万台呢？中间如果有依赖获取失败的情况，你连服务器处于什么版本、什么状态都不知道，这样就没法儿维护了。所以在自动化部署的过程当中，我们将所有模块的更新包和它们所有的依赖都压成一个包，上万台服务器都获取这一个包，就大大简化了。

跟周边系统的集成也是一点一点做的。比如工单系统，部署一个版本要能够自动新建一个工单，部署完成后自动发送通知给后面要检查的人，检查的人需要能看到部署是什么时候开始的，现在做到了第几步，处于什么状态等。还是那句话，自动化部署要能够把原有的流程重现，而不是说做了自动化所以流程就不同了。

效果

目前我们的部署频率平均在一周 10 次。每周五我们做一个最新版本，上一个 1% 的 bucket，周末观察两日；周一升级到 5% 的 bucket，同时再上几个新的版本到不同的 1% bucket；周二再上几个 bucket，然后选择一个稳定版本，到周三全部推送。

所以以前一个月部署一次 release，现在可以做到一个月 40 多次，每次部署 5 小时内可以完成，需要的运维也从 6 人减少到 2 人。我认为现在基本上实现了我们去年想要达到的目标。未来的话，我们现在正在研究类似 Docker 这样的技术，看看如何用虚拟化的方式实现大规模的部署，这样一套系统的监控如何去做，这会是我们下一阶段的一个工作重点。