微信扫描登录
或者
请输入您的邮件地址来登录或者创建帐号
提 交取 消
GITBOOK.CN需要您的浏览器打开cookies设置以支持登录功能

云上的运维

本篇文章整理自胡莱游戏运维总监谭志宇5月25日在『ITA1024运维技术精英群』里的分享实录:云上的运维。

enter image description here

干运维的朋友都知道,做运维的又苦又累,薪水还低,而且工作成绩得不到认可,为什么会出现这样的情况呢?我们要从运维的价值来说起。

从技术本质来讲,它是不具有价值的,那么技术的价值在哪儿?

要把它转化成产品,只有通过技术转化出来的产品,在市场上流通交易才具有价值。 技术服务,用技术手段来提供服务,也是一种交易,这也是技术的价值。

然而运维的价值在哪儿?

在2000年以后互联网迅速发展,网站承载的用户量和信息量越来越大,技术、产品环境越来越复杂,这时候研发主要是研发产品,但是维系平台的基础工作还是需要有人来做,公司就会分出一部分对运维感兴趣的研发做这个事情,后来也有一些网管、系统管理人员也开始维护一些运维底层的东西,所以这就是运维的由来。

运维不是一 门开发语言,不是某一个技能的体现,看看目前哪所学校有开过运维这门课程?貌似没有。它是一个对从事保障网站正常运行的技术人员的综合素质的概括,包括你对计算机软硬件的了解,对计算机网络的了解,乃至于你对整个业务的了解等。

然后把这些所有的东西综合在一起才能在大用户量、大业务量的情况下给网站业务的 正常运行带来稳定性,这就是运维真正的价值。

下面进入今天分享的主要内容:

今天我要演讲的主题是“云上的运维”,大家看到标题就应该想到这不是一篇基础技术优化类的、也不是高大上的架构类话题。今天我要讲的内容我相信在座的各位都能听的懂,男女老少皆宜。这是一个以运维思想、用户角度的使用经验分享。

在2012年的时候我们就开始转向云部署(严格意义上说,那时候就是虚拟机),在那个国内云计算技术还极为不成熟的时期,我们为什么要做这样的选择?这当然与我们的业务有关。

我将分几个主题来说:

  • 为什么要用云
  • 在云上我们做了什么
  • 如何选择云
  • 曾经踩过的坑
  • 要达到的效果
  • 简洁式运维的思想

    enter image description here

1、为什么要用云

俗话说:干柴烈火,一碰即着。同样,运维遇到云计算,也会有这样的化学反应。尤其是游戏运维,两者的融合犹如武侠小说的里“干柴烈火掌”, 威力大增,不仅大大的提升了运维的工作效率,还对运维人员的能力提出了更高的要求。

但是一个新事物的出现肯定有好的一面,也有不好的一面。因为一个技术,一个平台,甚至一个产业从萌芽状态发展到成熟需要一个很漫长的过程,像各个公司产品上线也是一样,不可能把产品做到百分之百完美的时候上线,都是在不断的 改进、修复当中去完善的。

因此在使用云平台提升效率享受便利的时候,也不要忘了它的不成熟性还暗藏着的一把“情意绵绵刀”,就是各种坑。

enter image description here

俗话说:上帝给你关上一扇门,必定给你打开另一扇门。同样云计算给我们带来了高效率的同时,必定会抛弃以往运维过程中的一部分基础性的工作,这是一场运维人的变革,带给运维人员的是思想上的转变,技能的提高,从操作性质转变到创新性质。

我们看看到底在云上舍弃了哪些具体的东西,将会更加关注什么东西。

enter image description here

在我们使用云平台以后,我们放弃的是安装、选择、上架、网络、调试、配置、评估等等的基础类工作。需要关注和提升的则是服务能力、平台、自动化、报警、流程、功能、成本等,甚至是将来的智能化运维。

enter image description here

为什么做游戏会考虑优先选择云平台?

在这里我做了一组对比图来说明游戏和非游戏行业的业务类型的不同特性。

enter image description here

非游戏包括门户、社交、视频、电商等等,产品特点就是单一性,比如说社交网站,门户网站,视频网站,因为是有核心的业务,所以比较单一。

持续性一般是指业务稳定持续上涨的特性;稳定性就是说在公司资金能够支撑的情况下,增长相对游戏来说比较稳定;环式衍生是说其他的产品都是根据核心产品衍生出来的,那么这种特性给运维带来的是什么?

  • 易标准化
  • 容易统一架构
  • 技术可持续深入
  • 稳定性相对来说比较高

对游戏项目来讲,比如说像端游、手游、页游,它的产品特点多种多样。

周期性,是指目前快餐式的游戏项目都是具有周期性的,像各类APP游 戏,但像这种游戏的热度持续时间一般超不过两年,有的一年时间都很难达到,这就是游戏的周期性。

多变性,是指游戏项目从开发到上线的过程中会产生很多问题,比如说我们确定要做一个游戏,做了两三个月发现什么问题呢?市场有竞品出来,那么我们还做不做?这是个值得商榷的问题,如果不做的话花了很长时间做的 运维架构,突然用不到了,相信每个运维都会觉得很憋屈。

这种业务特性给运维带来的是什么呢?

  • 不易标准化
  • 不易统一架构
  • 技术结构变化
  • 稳定性相对较低
  • 数据复杂度高

下图是一个业务需求表

enter image description here

大家思考一下,如果拿了这个需求怎么处理问题?

我知道咱们很多运维的朋友在创业公司,没有那么多的人手,有的运维还不具备开发能力,很多人可能还是通过excel来管理。那么咱们换个场景,如果说某天领导跟你说:嗨,帅哥/美女,这周有项目紧急上线,这两天大家配置800台服务器出来,然后把管理表更新一下;再增加一个需求,下午有其他几个项目退退还几十台服务器,把管理的表格更新一下吧等等。我想大家这时候内心一定是崩溃的。

如果大家使用托管的IDC这种方式,或者是私建云的方式,你们想想三天能搞定这个事吗?似乎很难。如果要满足上面所有的需求,靠人工,靠Excel是 完全不可能的,且不说人员成本、管理成本,像这样复杂多变的需求时间长了肯定会引起很多其他方面的问题。

我相信很多没有做过游戏运维的朋友会有这种想法,认为游戏运维就是玩玩游戏、写写脚本、上线、更新,日常维护之类的,但是真正的问题只有亲历后才知道有多复杂,那么怎么解决呢?

考虑再三,我需要做一个平 台,能自动管理上面这些需求的平台。

2、在云上我们做了什么

这是目前的运维管理平台

enter image description here

我们将平台分了三层:

第一层是CMDB层,CMDB只搜集静态的资源,比如说软硬件,项目、第三方、还有人,人是什么?就是要操作这个平台的账号,因为我们以后要给他定一个权限。

第二层管理平台,我们要把操作层的东西放在第二层管理平台,主要做的是权限(申请、变更、删除)、API接入、自动化部署,代码管理、运维成本管理(成本有时候需要对账,比如说CDN月底给你的账单有出入,所以我们有时候会修改账单,包括账单的汇总)、故障管理系统(会统计影响业务的故障)、私有云、公有云的操作等等。

第三层是业务平台,比如说产品管理、商务管理、财务对账等等。包括所有的游戏项目和非游戏项目的业务操作层面的整合。

HOPS历经三次改版, 目前这套系统的使用运维人员极少参与,几乎全部是运营、产品和财务的同事在使用,运维只是维护代码和流程。

大家通过这个平台来看,未来的运维模式一定是以运维/研发/业务/产品整合一体的平台化管理模式。绝不仅仅是只做CMDB基础管理平台,这个体现不出运维本身的价值,所以希望大家以后在设计运维系统的时候一定要考虑到业务层面的东西。

设计框架都是自顶向下和由面到点的设计方法;实施过程则是由点到面,从下向上的一点一滴的积累模式。

以前运维平台主要工作也是做CMDB部分,主要是收集资源、执行操作、展现给相关的业务人员看,然后日常维护。

现在主要是收集,把展现和操作合并都交给业务人员,然后是日常的维护,然而我希望将来维护也不需要人来做了,慢慢的将维护智能化,这也是将来的一个运维发展趋势。

enter image description here

在这整个平台设计和进化过程中我一直信奉着一个理念:大道至简,简称为:简洁式运维。

简洁是博大精深的升华,是大道至简在博采众长的基础上必须再整合创新,跳出原来的框框,抓住要害和根本,剔除那些无效的、可有可无的、非本质的东西,融合成少而精的东西。

所谓“为学日增,为道日减”就是这个道理。

3、如何选择云

接下来来说一下怎么去选择云平台,估计这是很多朋友都会对此感到困惑,我们选择一样东西必定跟需求或是喜好相关,对于我们运维人员来说,选择一门技术或是一个平台只有两个因素:成本与业务需求。

enter image description here

成本是资源、人力、管理成本。

需求来自两方面,第一个是业务需求,业务需求指什么呢?大家或许都接到公司领导的通知说我们这个业务下半年要达到什么样的量,比如说带宽要跑到几百个G,并发量要达到几十万、上百万、甚至上千万等,这都属于业务需求。而第二个技术需求来自研发方面,一般都是这两种需求来推动你的选择。

选择有什么标准呢?没有标准。因为每个公司的业务环境都不一样,都在不断的变化当中,所以它没有标准性。但是它有一个基准,就是可控。

enter image description here

可控包括两个方面,一个是行为可控,一个是人为可控。

行为可控:是指技术问题自己能搞定。能快速定位问题。

人为可控:是指业务层面的问题,出现问题你一定要能找到相关的接口人解决问题。

4、曾经踩过的坑

下面是我们用云平台这么多年踩过的一些坑。这些坑有的是产品设计的问题,有的是技术本身的问题,还有是人为的问题。

enter image description here

用过云的朋友不知道有没有踩过这些坑,这些坑不是一家云平台的,是多个云平台的。其实每种云平台都有自己优势,而在其发展过程中,肯定也有一些考虑不周或是目前还无法实现的技术问题。

因此,大家就不要私下问我哪个云平台好,哪个云平台差的话题了,否则下个月没有优惠了,运维成本高了,奖金也就没 了,呵呵…….你问我拿了多少优惠?这个嘛,暂时保密。

下面是一个云平台选择的需求模型,基本上是通用的。

enter image description here

最里面是指网络类型选择,是选择公网平台还是私网平台,这个是最好事先确定下来,在这个基础上考虑是否用云主机,负载均衡、然后扩容支持,消息服务等。

最外层就是CDN,是要用单独的第三方CDN还是和云平台结合的CDN,这个根据业务选择,包括安全也是。还有点播直播、图片处理,监控报警等等以及很多未列出来的功能。

要着重提的一点就是管理平台,通过跟运维人员或是云平台的业务人员进行交流沟通时发现他们都潜意识的忽略一个问题,就是平台管理。大部分运维人员更多关注的是云平台的功能和性能,但是这里面有一个问题:

假如公司当前只有百八十台服务器,你还可以管的过来,但是如果你把业务想象X10或是X100,且这些服务器分属各个不同的项目、不同的业务类型、不同的应用类型,如果没有一个良好的、人性化的平台,如何管理?想象都很恐怖啊。

我从一个用户的角度来看,更希望云平台能够提供更加人性化的功能,不光是基础功能要多、要完善,还需要更方便快捷的管理功能。

5、要达到的效果

enter image description here

做了这么多之后,我们要达到什么目的呢,就是上面这九点。

  • 快速接入
  • 低成本
  • 高可用
  • 支持海量用户
  • 资源动态调整
  • 安全性

刚开始只做这六个,从运维层面上来讲这样也可以了。

但是整合业务平台就需要增加下面的三点:

  • 业务解耦
  • 可管理性
  • 简洁性

6、简洁式运维的思想

enter image description here

运维人员要有偷懒的精神,但不是真的偷懒,是要学会将复杂的工作简洁化,提高工作效率。要达到以上说的九点非常不容易,需要做很多细致的东西,比如说整体架构的分析、基础架构实施,和上层业务的整合等等,所以说简洁并不简单。

简洁运维一定是一群具有工匠精神的运维人追求极致的工作,如果没有追求极致的结果可能达不到简洁的效果。

最后用一句话作为总结:优秀的运维人员一定是具有工匠精神的设计师。

Q&A

问:胡莱运维是怎么和老板,业务达成上云共识的?

谭志宇:这个问题既简单也复杂,说简单就是一定要取得老板的信任,你就成功了70%,剩下复杂的30%,就得靠自己,把自己要做的东西跟老板说出来,比如这个东西做出来能提升多少工作效率?创造了多大的价值?为公司未来有什么样的影响。强有力的信任是基础,但是需要你尽快做出一版来让老板看到你的成果。后期可以逐步改进和完善。

问:分享中提到云上的坑,我看有监控报警这一项,宇哥能展开说下么? 云上的运维,机器监控和业务监控都是怎么做的?

谭志宇:可以结合一起来做,国内的云这两年才发力,很多地方还不太完善。不能强依靠平台,比如机器的监控可以交给云平台,业务的自己来做。我们目前自己的监控及既监控了基础部分,也监控了业务部分。

问:迁移到云上的服务,日志是怎么收集的?如果我同时有云和IDC机房,怎么保持相同性?

谭志宇:这个问题看实际需求了,但我建议:如果你的业务70%在云平台上,那么在云平台上搞,否则就在IDC搞,毕竟日志量大的话数据传输就是个问题。设备扩容也比较灵活。而且现在云平台的功能越来越完善。

问:选择了某一家云供应商之后,是否有规划/准备迁移到另一家供应商?如果长远来看有这种可能性,除了常规的选择云供应商的方法,还有其他什么是可能需要考虑到的?

谭志宇:这个我是强烈建议你有个备用的,除非某个云平台在多地有IDC,且实现了内网打通。供应商的切换主要是应对大的故障问题或是合作问题。

问:从阿里云迁移到托管机房,这需要注意那些问题啊?

谭志宇:其实硬件从来就不是问题,关键是业务之间的调用,代码的运行是否对系统的参数有优化等,要搞清楚。建议你事先模拟迁移,一定抓每一个细节。

问:你们现在所有业务都在云上还是说idc托管也有?比重各多少?

谭志宇:我们6000个节点,其中约90%在公有云上,还有10%在私有云

问:我所理解胡老师说的备用是签多家供应商,在有需要的时候在备用供应商的平台上进行部署。我其实关注的是云主机在不同供应商之间的迁移。 这个场景可能只是某些极端情况下出现。不过就我个人对目前云平台的观察来看,几乎各家云之间无法很顺畅的迁移,在某个供应商平台上达到一定量级的时候迁移变成了一个成本巨大的工作。从而有了一些被供应商绑架的担忧。。。

谭志宇:是的,这个问题我也注意到了,我们的游戏业务跟非游戏业务不一样。没有项目是独立的,但是你说的这个问题确实存在。如果你在一个平台上发展的很快很大,那么依附的就越多。比如我们有个非游戏项目刚开始的时候只是用云主机,后来开始用DB,redis,集群等。

问:核心服务是放云上还是idc?

谭志宇:我们的主要业务基本都是在云上。非游戏项目的要慎重考虑,结合业务的实际情况来。要分清楚业务和代码跑的环境十分符合你的要求,控制好成本。用云平台有点刷信用卡的感觉,刷的时候不注意,月底算账的时候太苦逼。

问:你们针对不同游戏业务数据的统计分析,hadoop系统等, 是放在公有云上还是自己私有的IDC?

谭志宇:我们目前在私有IDC。