版权声明：如需转载请联系听云College团队成员阮小乙，邮箱：ruanqy#tingyun.com
引言：
对于分享内容的整理，我们尽量还原现场的演讲。但是现场演讲和文章分享毕竟有本质的区别，现场演讲可以根据当时的环境和氛围临时协调加入一些引爆气氛的言论、语气或是肢体动作，但这放在文章内或许不太合适。虽然我们在整理文章的时候尽量采用演讲时口语化的形式来展现，但是为了表达文章上下文的连贯性、流畅性，我们必须对一些文字，语句进行措辞，然而这并不影响演讲内容和演讲者内心的表达。
开场白：
各位朋友，下午好！首先非常感谢听云、AWS、运维帮共同举办了这次的分享，得已让我们坐在这里彼此交流思想。大部分朋友之前可能参加过很多次各种技术大会，听的时候兴趣盎然，激动不已，以为可以拿到了运维的圣经。可实际上回去以后和公司的业务一匹配，发现很多内容用不了，为什么会出现这样的问题？这里我不给出具体的答案，希望大家听完我的分享之后自己思考，我相信每个人都会有自己不同的答案。
干运维的朋友都知道，做运维的又苦又累，薪水还低，而且工作成绩得不到认可，为什么会出现这样的情况呢？我们要从运维的价值来说起。
从技术本质来讲，它是不具有价值的，那么技术的价值在哪儿？
第一，要把它转化成产品，只有通过技术转化出来的产品，在市场上流通交易才具有价值。
第二，技术服务，用技术手段来提供服务，也是一种交易，这也是技术的价值。
然而运维的价值在哪儿？在2000年以后互联网迅速发展，网站承载的用户量和信息量越来越大，技术、产品环境越来越复杂，这时候研发主要是研发产品，但是维系平台的基础工作还是需要有人来做，公司就会分出一部分对运维感兴趣的研发做这个事情，后来也有一些网管、系统管理人员也开始维护一些运维底层的东西，所以这就是运维的由来。运维不是一门开发语言，不是某一个技能的体现，看看目前哪所学校有开过运维这门课程？貌似没有。它是一个对从事保障网站正常运行的技术人员的综合素质的概括，包括你对计算机软硬件的了解，对计算机网络的了解，乃至于你对整个业务的了解等。然后把这些所有的东西综合在一起才能在大用户量、大业务量的情况下给网站业务的正常运行带来稳定性，这就是运维真正的价值。
今天我要演讲的主题是“云上的运维”，大家看到标题就应该想到这不是一篇基础技术优化类的、也不是高大上的架构类话题。今天我要讲的内容我相信在座的各位都能听的懂，男女老少皆宜。这是一个以运维思想、用户角度的使用经验分享。
在2012年的时候我们就开始转向云部署（严格意义上说，那时候就是虚拟机），在那个国内云计算技术还极为不成熟的时期，我们为什么要做这样的选择？这当然与我们的业务有关。我将分几个主题来说：
为什么要用云
在云上我们做了什么
如何选择云
曾经踩过的坑
要达到的效果
简洁式运维的思想
1、为什么要用云
俗话说：干柴烈火，一碰即着。同样，运维遇到云计算，也会有这样的化学反应。尤其是游戏运维，两者的融合犹如武侠小说的里“干柴烈火掌”，威力大增，不仅大大的提升了运维的工作效率，还对运维人员的能力提出了更高的要求。但是一个新事物的出现肯定有好的一面，也有不好的一面。因为一个技术，一个平台，甚至一个产业从萌芽状态发展到成熟需要一个很漫长的过程，像各个公司产品上线也是一样，不可能把产品做到百分之百完美的时候上线，都是在不断的改进、修复当中去完善的。因此在使用云平台提升效率享受便利的时候，也不要忘了它的不成熟性还暗藏着的一把“情意绵绵刀”，就是各种坑。
俗话说：上帝给你关上一扇门，必定给你打开另一扇门。同样云计算给我们带来了高效率的同时，必定会抛弃以往运维过程中的一部分基础性的工作，这是一场运维人的变革，带给运维人员的是思想上的转变，技能的提高，从操作性质转变到创新性质。我们看看到底在云上舍弃了哪些具体的东西，将会更加关注什么东西。
在我们使用云平台以后，我们放弃的是安装、选择、上架、网络、调试、配置、评估等等的基础类工作。需要关注和提升的则是服务能力、平台、自动化、报警、流程、功能、成本等，甚至是将来的智能化运维。
为什么做游戏会考虑优先选择云平台？在这里我做了一组对比图来说明游戏和非游戏行业的业务类型的不同特性。
非游戏包括门户、社交、视频、电商等等，产品特点就是单一性，比如说社交网站，门户网站，视频网站，因为是有核心的业务，所以比较单一。持续性一般是指业务稳定持续上涨的特性；稳定性就是说在公司资金能够支撑的情况下，增长相对游戏来说比较稳定；环式衍生是说其他的产品都是根据核心产品衍生出来的，那么这种特性给运维带来的是什么？
易标准化
容易统一架构
技术可持续深入
稳定性相对来说比较高
对游戏项目来讲，比如说像端游、手游、页游，它的产品特点多种多样。周期性是指目前快餐式的游戏项目都是具有周期性的，像各类APP游戏，但像这种游戏的热度持续时间一般超不过两年，有的一年时间都很难达到，这就是游戏的周期性。多变性，是指游戏项目从开发到上线的过程中会产生很多问题，比如说我们确定要做一个游戏，做了两三个月发现什么问题呢？市场有竞品出来，那么我们还做不做？这是个值得商榷的问题，如果不做的话花了很长时间做的运维架构，突然用不到了，相信每个运维都会觉得很憋屈。这种业务特性给运维带来的是什么呢？
不易标准化
不易统一架构
技术结构变化
稳定性相对较低
数据复杂度高
下图是一个业务需求表
大家思考一下，如果拿了这个需求怎么处理问题？我知道咱们很多运维的朋友在创业公司，没有那么多的人手，有的运维还不具备开发能力，很多人可能还是通过excel来管理。那么咱们换个场景，如果说某天领导跟你说：嗨，帅哥/美女，这周有项目紧急上线，这两天大家配置800台服务器出来，然后把管理表更新一下；再增加一个需求，下午有其他几个项目退退还几十台服务器，把管理的表格更新一下吧等等。我想大家这时候内心一定是崩溃的。如果大家使用托管的IDC这种方式，或者是私建云的方式，你们想想三天能搞定这个事吗？似乎很难。如果要满足上面所有的需求，靠人工，靠Excel是完全不可能的，且不说人员成本、管理成本，像这样复杂多变的需求时间长了肯定会引起很多其他方面的问题。我相信很多没有做过游戏运维的朋友会有这种想法，认为游戏运维就是玩玩游戏、写写脚本、上线、更新，日常维护之类的，但是真正的问题只有亲历后才知道有多复杂，那么怎么解决呢？考虑再三，我需要做一个平台，能自动管理上面这些需求的平台。
2、在云上我们做了什么
这是目前的运维管理平台
我们将平台分了三层：
第一层是CMDB层，CMDB只搜集静态的资源，比如说软硬件，项目、第三方、还有人，人是什么？就是要操作这个平台的账号，因为我们以后要给他定一个权限。
第二层管理平台，我们要把操作层的东西放在第二层管理平台，主要做的是权限（申请、变更、删除）、API接入、自动化部署，代码管理、运维成本管理（成本有时候需要对账，比如说CDN月底给你的账单有出入，所以我们有时候会修改账单，包括账单的汇总）、故障管理系统（会统计影响业务的故障）、私有云、公有云的操作等等。
第三层是业务平台，比如说产品管理、商务管理、财务对账等等。包括所有的游戏项目和非游戏项目的业务操作层面的整合。
HOPS历经三次改版， 目前这套系统的使用运维人员极少参与，几乎全部是运营、产品和财务的同事在使用，运维只是维护代码和流程。
大家通过这个平台来看，未来的运维模式一定是以运维/研发/业务/产品整合一体的平台化管理模式。绝不仅仅是只做CMDB基础管理平台，这个体现不出运维本身的价值，所以希望大家以后在设计运维系统的时候一定要考虑到业务层面的东西。设计框架都是自顶向下和由面到点的设计方法；实施过程则是由点到面，从下向上的一点一滴的积累模式。
以前运维平台主要工作也是做CMDB部分，主要是收集资源、执行操作、展现给相关的业务人员看，然后日常维护。
现在主要是收集，把展现和操作合并都交给业务人员，然后是日常的维护，然而我希望维护也不需要人来做了，慢慢的将维护智能化，这也是将来的一个运维发展趋势。
在这整个平台设计和进化过程中我一直信奉着一个理念：大道至简，简称为：简洁式运维。简洁是博大精深的升华，是大道至简在博采众长的基础上必须再整合创新，跳出原来的框框，抓住要害和根本，剔除那些无效的、可有可无的、非本质的东西，融合成少而精的东西。
所谓“为学日增，为道日减”就是这个道理。
3、如何选择云
接下来来说一下怎么去选择云平台，估计这是很多朋友都会对此感到困惑，我们选择一样东西必定跟需求或是喜好相关，对于我们运维人员来说，选择一门技术或是一个平台只有两个因素：成本与业务需求。
成本是资源、人力、管理成本。需求来自两方面，第一个是业务需求，业务需求指什么呢？大家或许都接到公司领导的通知说我们这个业务下半年要达到什么样的量，比如说带宽要跑到几百个G，并发量要达到几十万、上百甚至上千万等，这都属于业务需求。而技术需求来自研发方面，一般都是这两种需求来推动你的选择。
选择有什么标准呢？没有标准。因为每个公司的业务环境都不一样，都在不断的变化当中，所以它没有标准性。但是它有一个基准，就是可控。
可控包括两个方面，一个是行为可控，一个是人为可控。
行为可控：是指技术问题自己能搞定。能快速定位问题
人为可控：是指业务层面的问题，出现问题你一定要能找到相关的接口人解决问题。
4、曾经踩过的坑
下面是我们用云平台这么多年踩过的一些坑。这些坑有的是产品设计的问题，有的是技术本身的问题，还有是人为的问题。
用过云的朋友不知道有没有踩过这些坑，这些坑不是一家云平台的，是多个云平台的。其实每种云平台都有自己优势，而在其发展过程中，肯定也有一些考虑不周或是目前还无法实现的技术问题。因此，大家就不要私下问我哪个云平台好，哪个云平台差的话题了，否则下个月没有优惠了，运维成本高了，奖金也就没了，呵呵…….你问我拿了多少优惠？这个嘛，暂时保密。
下面是一个云平台选择的需求模型，基本上是通用的。
最里面是指网络类型选择，是选择公网平台还是私网平台，这个是最好事先确定下来，在这个基础上考虑是否用云主机，负载均衡、然后扩容支持，消息服务等。最外层就是CDN，是要用单独的第三方CDN还是和云平台结合的CDN，这个根据业务选择，包括安全也是。还有点播直播、图片处理，监控报警等等以及很多未列出来的功能。
要着重提的一点就是管理平台，通过跟运维人员或是云平台的业务人员进行交流沟通时发现他们都潜意识的忽略一个问题，就是平台管理。大部分运维人员更多的关注是云平台的功能和性能。我从一个用户的角度来看，更希望云平台能够提供更加人性化的功能，不光是基础功能要多、要完善，还需要更方便快捷的管理功能。
5、要达到的效果
做了这么多之后，我们要达到什么目的呢，就是这九点：
快速接入
低成本
高可用
支持海量用户
资源动态调整
安全性
刚开始只做这六个，从运维层面上来讲这样也可以了。
但是整合业务平台就需要增加下面的三点，
业务解耦
可管理性
简洁性
6、简洁式运维的思想
运维人员要有偷懒的精神，但不是真的偷懒，是要学会将复杂的工作简洁化，提高工作效率。要达到以上说的九点非常不容易，需要做很多细致的东西，比如说整体架构的分析、基础架构实施，和上层业务的整合等等，所以说简洁并不简单。
简洁运维一定是一群具有工匠精神的运维人追求极致的工作，如果没有追求极致的结果可能达不到简洁的效果。
最后用一句话作为总结：优秀的运维人员一定是具有工匠精神的设计师。
文章整理自第十二期应用性能管理大讲堂——运维专场 胡莱游戏 谭志宇《云上的运维》
分享到微信
分享到微博
