BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 杨赛 关注 3 他的粉丝 发布于 2014年8月19日. 估计阅读时间: 7 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

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

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

受访嘉宾简介

image

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

团队与服务概述

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

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

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

为什么要做自动化部署

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

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

项目实现的流程

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

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

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

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

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

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

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

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

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

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

效果

image

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

image

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

疑问 by 北 夜人

我们需要跟每一个组件的研发沟通,让他们按照我们的规则提供接口(即RESTful API)
----------
请问这个api具体作用是什么?是可以通过这个api自动下载包吗?

Re: 疑问 by chen xi

同问,包的下载是不是需要有一个程序包管理中心?例如一个制品仓库/软件仓库类的东东?

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT