多云管理，恺英实战之道

讲师简介

徐巍

上海恺英网络科技有限公司

高级总监

刚刚几位演讲嘉宾，一位关注高可用；另外一位关注网络。我现在待的是一家很有特点的公司，整个基础设施，90%的跑在公有云，也有一些物机房，我认为挺符合现在的混合云架构，所以我的演讲题目是恺英网络的多云实践之道。

1.自我介绍和现状

首先做一下自我介绍，从毕业至今，我一直从事运维及技术保障相关工作，至今十来年，之前是在在线视频，后续在一些在线交易系统公司，目前在一家游戏公司，做了很多年的IAAS和PAAS相关的事情，也亲历过数次公司业务从1到100，爆发式增长。

恺英网络是一家有超过10年历史的游戏公司，研发和平台并重，经过多年发展，形成了以研发运营于一体的游戏平台，在基础设施这块，基于游戏场景，形成了托管IDC和多公有云的弹性计算平台。

2. 问题

由于历史原因，恺英的混合云环境存在着一些历史包袱，简单的来说，就是567，有5个物理托管IDC，6朵云，7家CDN供应商，定位相对模糊，缺乏顶层规划，导致有些混乱，管理成本高昂。

这种混乱的状态就会带来一些问题：

1、稳定性的问题，某公有云严重故障导致公司关键业务长时间中断，还有某IDC掉电导致业务中断8小时以上；

2、效率的问题，众所周知，游戏对速度的要求极高，需要能快速部署，快速上线，而如此复杂的底层环境无法保证高效的资源交付与代码上线；

3、成本问题，供应商越多，资源越分散，管理难度越高，就会导致很多不必要的浪费，以及闲置，也不利于商务谈判，成本无法做到相对较优。

稳定性问题主要体现在哪些方面呢？这么多云，几乎每年每朵云都会挂1次或者多次，各个业务分布在各个云中，有的还相互有依赖，必然导致故障的概率变得很高。

同时，多种云，如果都是通过portal操作，必然会涉及到每个人的操作习惯，以及权限管理等问题，会导致安全、以及标准化导致的影响稳定性的潜在风险。

配置管理也会是问题，人员离职，权限是否记得回收，上万服务器规模下，每天都有机器创建和销毁，通过页面和脚本操作一定没有未来。

效率问题主要体现在不同人的习惯和熟练度不一样，成千上万的机器通过页面来创建，完全无法保证质量和交付效率，质量不好，重复确认和返工，更会拖慢效率，同时人员的变动，导致操作习惯的变化会出更大的问题。

另外成本问题也不可忽视，去年，我们在线上发现一些机器在那儿闲置着，其中有一台是有60多T磁盘空间的虚拟机，因为业务变化，95%的空间都是浪费的，这台机器一个月的成本是6万块，应该闲置了有至少小半年，这就是多少钱了？仔细盘点，你就会发现服务器、IP、硬盘、对象存储谁创建的？什么时间创建的？怎么创建的？为谁创建的？成本怎么分摊？这些问题搞不清楚。

3. 多云之道

解决这些问题要有宏观的规则。

1、Design for failure。刚才小米的演讲也提过，我经常跟云供应商沟通，开会的时候，有句话我也经常说：“你们所有的云都是不可完全信任的，一定会crash的”，我们一定要为失败而设计，我们的人会犯错，公有云会挂，代码会出BUG，网络会出问题，整个互联网的架构就是要在这些不确定性因素下，尽量确保可靠性，降低出问题的概率。

2、简单即好用。所有的东西一定是越简单越好，越复杂越不可靠。目前恺英有很多的云和物理托管IDC，我们需要仔细思考，是否真的需要这么多的云和物理IDC，这些东西的定位是什么？能不能做减法？举一个例子，有很多新的技术、产品和想法，我们要慎重地去评估和考量究竟要不要引入。有时候“用好”一个工具远远比用“好的”一个工具重要。

3、只有标准化才有未来，标准化才有自动化，自动化才有平台，平台化才有数据，有了架可流动可计算的数据，才有现在大家都在聊的 AIOPS 的可能。

首先我们要思考边界在哪里？恺英的业务分几类，有一类是游戏业务，其实我没有游戏背景，对游戏相关业务的理解不是很深刻，在座的不知道有没有游戏公司的技术？国内的页游、手游里面存在着一个很有特点的场景，单区单服，一个VM里面有nginx、C++、cache、db，整个游戏区服全部的东西都在里面，用户访问的整个生命周期基本都可以在这台VM里面完成，无需对外交互，同时单个区服的人数都是有限制的，一般最高3000-5000玩家同时在线。

如果要扩容，就直接再起一台，这叫scale out，而无需scale up，这种场景的特点主要是相对独立，同时对全局可靠性的要求相对较低，单个区服故障不影响其他的节点，也不影响大盘，可做分布式部署，这类需求所需的资源节点我们称之为边缘节点。

恺英还有一部分业务是游戏平台，它与其他的互联网应用没有太大的区别，本质上就是用户的注册、登陆、支付等等一系列的东西，对可靠性要求较高，同时也会有大量的交互，并有较高的发布频率，基于这些特点，我们把他定位为核心业务，需要放置在核心节点。

再后面，我会简单地讲到康威定律，工作这么多年，越来越深刻领悟到一切架构的设计与你组织的架构是有密切的关系。如果你组织架构存在着一些混乱和不合理，基于屁股决定脑袋原理，业务架构不可能好得了，这也就是康威定律，后面我会展开来讲。

基于以上思考，我们的IAAS架构如下，整个网络分为核心节点和边缘节点，平台类的业务全部集中在核心节点上，通过异构双活确保核心业务可用，数据落地到自建托管IDC，确保数据安全，同时游戏业务分散到各个边缘节点，做多云部署，分散风险，从宏观上保证整体的可控。

标准化怎么做呢？我的建议是就像造房子，从地基打起，一层层的垒，夯实，主要包括机房、网络、服务器、OS、software、application等等。

举个例子，server这一层，我们建立了一张资源映射表，恺英内部会有一个自定义服务器型号，同时和各个公有云的相同配置和性能的服务器资源建立映射关系，这样就对用户屏蔽了各个云的差异，当然这个映射关系的建立需要经过测试，确保性能和配置，以及价格处在相对一致的水准。

在我的理解里面，做运维其实归根到底就是两件事情： 第一，资源的生命周期管理。一个资源从创建到上线，从故障到恢复，从变更到回收，整个生命周期的管理。而资源包含很多，IP、网络、存储、域名等等，每一种关键资源都需要从整体上收口，从流程上把控，谁能做得更精细，谁就能做得更好，生孩子容易养孩子难，相信在座的诸位爸爸妈妈深有体会。

Workflow，他是一个面向用户的编排工具，主要目的是规范输入，让用户做选择题，而不是问答题，本质上而言，它就是一个表单系统，生成你所需要的计算资源、存储资源或者数据库资源等等的东西的信息，并发送给下一个核心应用resource gateway。当然，目前这个工单系统面向的主要用户是运维，后续会逐步面向研发和业务。

Resource Gateway 是整个多云自动化体系中很核心的一环，他会屏蔽各个云的差异，实现对用户的透明，确保资源创建，并把数据落到CMDB和服务树，保证所有的资源从生到死是统一收口的，并且是标准化的。

resource gateway 调用云的api创建资源后，会通过作业平台执行初始化，如安装监控agent，优化相关内核配置，收集主机信息等等一系列的操作，确保每一台经过这个流程交付的机器均满足生产需求，配置一致，完全可控。

多云资源管理的整个体系不仅仅只是上面的一块了，还有大量的相关子系统，如监控体系、日志、以及各个关键资源的管理，如DB，cache，DNS解析、甚至域名备案和证书管理等等，这一切的关键是需要确保这些数据在各个系统基于某些流程准确、及时的流动起来，能流转的数据才是有用的数据，死的数据没有任何价值，计算机，乃至人类社会，一定要有输入和输出，才有价值。

这一块呢，主要是从各个维度，可视化的来看资源的使用情况，关注供应商管理和成本就可以从供应商的角度来看，哪些多哪些少；关注业务就会看哪个部门资源多，分布是怎么样的？哪个业务变化比较大？有了这个工具，资源管理员，还有老板就可以很容易的获取到宏观资源的使用情况，为决策提供数据支持。

刚刚那些东西里面有很多的一些细节，涉及到一些特别重要的东西：数据。怎么保证这些数据能很好的流动？怎么及时发现一些异常数据？每个异常数据背后的深刻原因是什么？这些都需要一个旁观者去探索和发现，所以我们专门建了巡检系统，每天或者每周对各个资源，业务的状态做巡检，并产生报表。

这些报表可能不是很好看，但是会从各个角度去统计，提供数据，我们就能及时地发现一些代码的BUG或者流程的不完善等等之前没有考虑的问题，不断FIX它，让它逐步收敛到我们所期望的状态，这个事情一定是要先收口再来治理，同时就是一些细节，一点点去扣，一点点治理下去，细节是魔鬼，执行是王道。

容量与成本这一块，我们还在开发过程中，所以没有放图。成本控制这块我有些思考，一个公司高速增长的阶段，之前我觉得成本很重要，现在看起来不是那么重要了。怎么说呢，之前我还就职于一家电商公司的时候，整个IAAS建设，两年花了10个亿，花到我心疼的感觉，就经常challenge业务，你为什么要那么多资源？能不能代码写好点，少要点资源？后面我才逐渐理解，公司业务高速增长，成本一定要为效率让步，你省了一个亿，也许降低效率，导致公司少融一轮资或者对IPO造成一些麻烦，损失远远不止1个亿，正确的做法应该是站在全局思考，后续公司发展到一定的阶段或者平稳期，再来齐心协力挤水分。

成本这一块，关键的是需要把成本和利用率关联起来，从几个维度来看，从供应商来看，哪个云的利用率很低？从业务来看，哪个业务的利用率很低，同时成本又比较高，收入还一般？我们需要把这些应用找出来，和业务一起优化。

成本优化是一件对大家都很痛的事情，特别是业务方，很有可能对这个事情有所抵触，所以需要量化，并且和kpi挂钩，并通过技术手段给业务方最直接的建议，减少业务调整的成本，并告诉业务你已经节省了多少多少钱，通过红黑榜push业务，逐步形成一个良好的机制，常态化，而不是运动化。

应用的生命周期这块，由于主题原因，今天不会展开太多，主要是通过CICD，实现代码的持续集成和生产环境部署，并提供给研发自助式使用。很多互联网公司每天几百几千次发布，运维一般都不太介入，CD的核心能力主要是灰度和一键回滚，能效团队可以基于这个判断一个团队的发布成功率，如果回滚的比例偏高说明是有问题的。

4. 挑战与应对

刚刚谈的是多云管理的东西。接下来会重点给大家聊聊其他的东西，有了多云只能解决一部分稳定性、效率和成本的问题。在绝大部分非技术驱动的公司，业务与技术这一块始终有很多的博弈，技术在短期内往往被高估，长期而言却会被低估，我所从事的工作是偏向后台技术的，屁股决定脑袋，我就会认为技术非常重要，但是最近这几年的经历，让我发现业务更重要。

在很多公司，如果你站在CEO的角度来看，技术只是一个支撑的作用，这个时候他不会去关注技术重构的需求，或者有稳定性的需求，站在业务角度来看，就是我要上新的业务，老的业务要变化，这就意味着变更和快速开发，快速迭代，但稳定性的问题其实还在那里。

看看这张图片，想象一个场景，一辆在高速上狂奔的汽车，或者一架正在飞行的客机，老板关注的是跑得快慢，但要想跑得快就要不断的换轮子和发动机和变速箱，升级配置，重新架构设计，但这个过程车或者飞机还不能停。目前很多大点的公司的CTO其实挺惨，偏向于大中台，管运维、安全、大数据、架构、中间件的，管这一摊偏向于业务支撑的体系，不怎么碰业务了。在这个过程中，业务的实际需求，和这些需求带给后端技术的潜在稳定性、效率的需求其实是有些冲突的，从而对双方产生很多的挑战。

康威定律和技术债，前天一个头条的朋友跟我聊一个底层的技术问题，聊完我的感受是这样的，一个产品或一个应用为什么能出现？他一定和公司的组织架构有关系，公司的组织架构决定了技术体系的架构甚至于产品的架构，为什么有一些产品的诞生？因为有组织的诞生。组织一定是分层次和团队的，每个团队有自己的核心利益，比如说负责运维的，要做到最好是怎么样的，不准变更，一个月或者一个星期变更一次，不准扩容，或者上线什么业务要通知我，这样运维可以保证不出问题。

但是业务就活不了，也许业务老板正在谈一轮融资，正在准备IPO上市，业务没有十倍和百倍的增长，公司就死掉了。所以一定要从全局来看，站在老板的角度或者更高的角度来看问题。为了全局，局部要做一些妥协，我们要全局最优，而不是局部最优。

做技术的人，很多人都是完美主义者，我要把技术做得很牛，我要把产品逐步迭代达到一个很理想的状态。学过经济学的人会发现一个问题，一个叫“边际”的概念，你考试的时候从30分到60分随便弄弄就可以了，从60分到90分要努力，再从90分到100分不容易，你的边际成本是递增的，边际收益是递减的，这里有一个“二八原则”，80%的问题一般都是20%的因素导致，抓大放小即可。

前几年，我还是有一点技术洁癖的，因为某些技术问题，我会跟老板吵架，要资源来做现在看起来收益很小但投入很多的事情，当时总被老板challenge，现在回过头来想，技术债一定要有的，为什么呢？有债务就是借用了杠杆的力量，给业务更好的支撑了。技术债的关键在于什么？代码的重构和架构的更新是不是要继续，说白了就是利息是否还得上，利息还得上，这个债就不会导致整个资金链的断裂，技术人员，特别是技术管理者需要做好这个平衡。

举个例子，我们的网站发生了什么很严重的故障，导致整个网站宕机。你作为CTO，你去跟老板谈，现在技术难度很大，可能三五个月把网站停止更新和发布，你看哪个老板会同意？如果你跟老板说，保障业务的同时，做重构和业务更新，老板说，你去弄吧，他才不关心你要不要重构呢，只要不影响业务就行，所以 要不要重构，要不要还债是CTO和技术要自己想好，并平衡好和业务的关系。

如果大家关注新闻的话，就会发现今年以来，市面上常见的各大云厂商都挂了1到数次了，所以请大家记住一句话，所有的云都是不靠谱的，宕机一定会发生的，一定不能有单点，不能把自己的身家性命寄托在别人的手里，特别是单独的某一家。

防御性编程有很多的东西，比如说我们的业务一定要有关键路径与非关键路径区分，主路径怎么理解？不可降级。如在线交易系统的下单、支付不可降级，非关键路径是哪些？如风控(金融行业这块应该是关键路径)，风控服务出现问题，可以临时把他降级掉，业务支付的时候不再过风控审核。 限流，各个电商公司在具备一些活动的时候从客户端，到服务端都需要都一些限流控制，确保核心服务不会被突发性流量压垮，能在极端情况下提供有损服务。

降级与熔断，我的理解就是一前一后，降级在事前，熔断在事后，降级就是大促的时候先把非关键路径的部分服务降级，减少业务处理链条的长度，而熔断是在业务层有一些防御措施，如说多次请求之后就不再请求，避免雪崩。同时，还需要有一些补偿与恢复的预案，在真正发生问题时，有一些补偿和业务机制，特别是一些公司做了双活，一定有概率会发生数据脏掉的情况，如果这样怎么办，一定要先想好。依赖和被依赖这块呢，我之前有一次很深刻的经历，业务的主路径做了很多的优化，没有问题，但是却被一个非主路径业务异常给拖死了，关键路径依赖了非关键路径导致整个服务的不可用。

监控和告警，这个东西的重要性不言而喻，就像一辆汽车只有底盘、刹车、发动机与变速箱是不够的，你还需要速度表，油量表，还有后视镜等等配套的设备，也就是监控系统，监控本身不难，不管是zabbix，还是prometheus，各种监控工具都发展得比较成熟了，关于在告警，如何避免被告警淹没？如何精准定位？这一块还有很长的路要走。

现在很多人提AIOPS，AIOPS在运维领域目前有两个地方比较好实施：一是监控；二是基于利用率和成本分析，来指导机型或者容器颗粒度优化，以及采购分析这一块。有些公司，如阿里等有在做类似这样的事情。告警这一块我们也还只是做一些简单告警收敛，聚合等等，还做不到告警的智能化判断，还有很长的路要走。

Chaos monkey与SOP，我们公司业务相对简单一点，并且经过前期的治理，已经具备灾备演练的实施能力，目前每个月会做一些故障演练，举个例子，一个业务有很多的应用，我们称之为APP，你可以以业务为单元，一组APP为整体做一些跨机房演练，逐个业务的演练。这里我们发现了一个大bug，有一天我们做整体的机房级演练，做了故障模拟后，突然发现整个运维平台不可用了，更不要谈进行机房级业务切换，后面仔细复盘。

发现整个演练涉及到很多运维工具的切换，甚至包括VPN、SSO等基础服务的跨机房可用，这些东西都是基于运维平台的，于是我们启动了运维平台的演练，从VPN到堡垒机，从DNS服务到SSO，再到监控系统，DB管理系统，这些东西都要做到长期的演练。

谈多云管理，安全还是要提两句。年前我有被上海市信管局的人叫过去喝茶了，为什么呢？因为信管局，网信办，还有工信部目前对互联网安全的要求越来越高了，而随着新的《网络安全法》的颁布与实施，发生大规模信息泄露等安全问题会对公司，和相关人员造成很严重的影响，最恶劣的情况是公司网站关停，相关人员蹲监狱了，所以这个时候一定要深刻理解安全，保护好公司，也保护好自己。

至于安全怎么做，我只能算半个门外汉了，总体而言，从组织架构上对安全加以重视，从流程制度上树立顶层框架，建立起事前预防，事中紧急处理预案，事后复盘改进的技术解决方案，同时和公司内部PR，业务各个部门做好协调，同外部白帽子、信管局等各个相关人员处理好关系，形成良性的治理环境，边收口边治理，踏雪有痕。

说故障之前，我想说几句话，聪明的人看别人跌倒了，自己不跌倒；一般的人是自己跌倒，爬起来不再跌倒；愚蠢的人一而再再而三地跌倒。

故障发生了后，我们一定要查找根因是什么？是流程的问题？技术的问题？还是人的问题？人肯定是会犯错，是意识问题还是能力问题？有没有办法减少人犯错的可能性？很多公司或者团队都做过这么一个事情，某一个人操作失误导致故障，于是改进方案就是再找一个人做double check，还要签字什么的，这种手段短期相对有效，长期一定无效，一定要通过技术手段或者流程，配合不断的意识上强化责任心来解决，我们相信我们的小伙伴，同时也明确人会犯错，但需要尽量减少。

整体来说，一个技术团队的很重要就是工程师文化的培养和积累，热爱技术，希望用技术解决问题，同时注重文档和不断的复盘，你们将战无不胜！

5. 一点心得

未来的云都是基础设施，像水和电一样，单纯做IAAS或者Paas的人会越来越少。而作为技术人员，需要关注底层，关注业务，关注数据，用数据说话，才能体现自己的价值。举个例子，这个业务跑得有点不好，什么叫好，什么叫不好，一切东西都要可量化，不量化的东西都是耍流氓。Design for failure，康威定律，还是回到人的架构，组织架构要合理，权责要明晰对等，业务架构层次化，边界要相对清晰，中间连接可控，否则这个过程要不断抽象迭代，会比较麻烦。

最后一句话送给大家“未长夜痛哭者，不足以语人生”。在你经历过痛彻心肺的伤痛后，在一次次跌倒爬起后，请记住，所有光鲜亮丽的背后一定是苦难。

说明：以上为上海恺英网络科技有限公司高级总监徐巍在 GOPS 2019 · 深圳站的分享。

DOIS 2019 · 北京站，DevOps 落地，从这里开始

7月5日~6日，我们在北京等您~

点击阅读原文，立即订票