本文根据〖2016 全球运维大会·深圳站〗咖啡党（党受辉）演讲整理而成，编辑同学为黄志@腾讯。分享力度之大，前所未有，敬请享用！
欢迎关注“高效运维（微信ID：greatops）”公众号，以抢先赏阅干货满满的各种原创文章。
党受辉
2012年开始负责腾讯游戏运维支撑体系（蓝鲸）的设计、建设和运营。结合SOA、云、大数据等理念及前沿技术，构建独立的运维基础架构，并通过产品化等方式，助力行业内应用运维团队的转型升级，推动 DevOps 生态。
我今天分享的主题是： 《蓝鲸体系设计思路及架构剖析》
主要分为4个部分：
蓝鲸在2015年年初的时候对外做过一轮针对运维的宣传，因为是针对运维，所以当时没有涉及其他方面，但其实蓝鲸的总体设计并不是仅针对运维这一个点的，今天就展开说一下。
一个企业要活下来，要关注五个点：产品设计、产品研发、市场渠道、业务运营、团队管理。
产品设计和市场渠道跟技术没有关系，产品研发是企业的研发线应该关注的内容，关注于怎么把产品的设计原封不动地做出来。
蓝鲸主要是针对后面两个点：业务运营、团队管理
承载这两个点的具体表现形式，我认为是各式各样的运营系统，你也可以说承载这两个点的表现形式是各种流程、规范，但我觉的这些太虚了。没有落到运营系统上的，都是浮云。
如果从企业运营系统构建的角度看，蓝鲸是一套垂直PaaS，如果从产品化的角度说，蓝鲸是一套企业操作系统。
蓝鲸的设计和业界大多数公司的运维体系都不一样，大部分公司的运维体系是类似于效仿ITIL理论，通过产品化一点点做出来，比如做出容量平台、发布平台、监控平台等等，这些平台在蓝鲸都没有。
蓝鲸是以另外一套思路设计的，因为我们的业务跟大家不一样。
一个企业可能有多个业务，开发负责人一般会让研发统一开发模式和开发框架；再先进点的可能会依托公有PaaS来做，开发出来的东西不用持续维护，云化全托管。
公有PaaS还会给你提供各种各样的API，让你不用写完系统的所有逻辑模块，你只需要按用量付费就行。所以说公有PaaS可能是目前成本最低的开发模式。
企业内部可能会有自己的私有云，并以公有云作为弹性扩展部分，甚至可能同时使用不同的公有云，因此跨云的管控是基本需求。
因为我们的业务大多数不是自己开发的，所以我们没有办法像其他公司那样，基于自己的开发框架开发出一套技术运营体系。
我们从全球挑选游戏，在签订代理合同的时候，这款游戏基本上都快开发完了，我们无法控制我们的业务是用什么语言写的、跑在什么操作系统上、用的什么架构……这些都是不可控的。
所以，蓝鲸的理念是：在不对业务架构做嵌入式改动的前提下，做无人值守运维。
第一个图是一个发布的流程，由点和线穿起来。
第二个图是一个故障流程，在接到告警后，首先登录服务器验证，根据验证的结果决定下一步怎么办，故障处理基本上是树状的分析逻辑。
最后一个是刷新配置的简单流程，这是配置中心的流程。
这些都是运维最基础的操作，我们看到的共性是它们都是由点和线连接而成的，这是我们设计蓝鲸的基础，只要你的运维工作是由点和线连接在一起的，就可以由蓝鲸来适配。
我们在企业业务架构旁边独立开发出了一套企业技术运营架构，我们把各种各样的点自动化，自动化之后再用引擎之类的东西把它串起来，形成一个自动化的调度链。
在上面做一个服务总线实现SOA模式，并从上面做相应的系统集成。
举一个例子，我们要搞一个无人值守的扩容流程，监控决策、获取资源、注册资源、部署版本、修改配置、DB操作、测试、开放。每一个节点我们如果能够都自动化的话，就可以做到无人值守。
获取资源
一般的公司会有自己的IaaS管理平台，通过调用API就可以拿到一个新的容器或者新的OS，如果没有这么先进的话，可能会先准备好一批机器放在那里，需要的话挑选就好了。
注册资源
如果是离线的CMDB，在操作的时候需要把机器注册到新的模块下。
版本部署，配置修改，运维只要手里有root，就可以任意修改文件，或者写一个脚本去改，也就是说，这一圈大多数的操作，只要运维有root都是可以实现自动化的。
理论上来讲，你们所管辖业务的单模块扩容都可以实现无人值守。问题在于可能是在另外一个模块上运行，你的脚本就不能用了，你要复制这种模块的成本比较高。
那么，有没有什么办法呢？怎么能够实现点的自动化并且通用起来？这就是我们蓝鲸的第一个平台——蓝鲸作业平台。
你可以在上面注册脚本，它帮你海量地分发执行，而且还有传文件的功能，可以从PC上往服务器上传文件，也可以从服务器 A 传到服务器B、C、D。
它所做的其实就是运维平常用root脚本或者root命令直接进行的操作。它最基本的功能，你可以认为是把运维的脚本标准化地管理起来了。
大家都应该带过运维团队，运维有一个不大好的习惯，一般不大喜欢别人的脚本，当一个运维离职之后，下一个人来了之后，他会在相对长的时间内把别人的脚本干掉重写一遍。
最可恶的是出了一个事故，
老板问：出什么事了？
他说：是上一个人写的脚本有漏洞。
老板又问：怎么解决呢？
他说：把这个脚本重构一下就好了。
每换一个运维都会把历史问题当成一个理由。后来我们的老板比较狠，他说：“以后谁再敢说是历史问题造成的事故，那我就让他变成历史。”
脚本的模块化，一般的运维写得都不是很好，或者不是按照统一的模式写的，公司的脚本标准化推过很多轮，但是效果不是特别好。
这个平台就可以解决这个问题，我一般是把运维的脚本备份起来，所有的脚本，执行历史等等这些东西都是可控的，脚本也可以被写得尽量短，通过平台的调度实现脚本之间的串接。
既然做成平台了，底层的并发和高可用就不需要脚本来做。
在我们这个平台上，如果用它往一万台服务器上执行一个脚本的话，自身的损耗时间是小于几秒钟的。
最关键的功能是，它能够让运维写的脚本变成一个可以被API调用的原子。你可以在上层开发的面向场景的调度自动化系统里面去调度，你实现了远程地调用一个任务，也就实现了自制原子。
比如说改配置，你就可以写一个改配置的脚本注册到里面去，通过API启用，让运维有一个不需要研发配合的B计划。
我们运维做很多工作的时候，可能不得不去推动研发、推动其他周边团队做很多改造来配合我们。
举一个例子，我们要改官网的一个图片或者特性，官网是没有API的，官网只提供页面操作，这个时候运维就只能等待官网团队做自动化。
但是有了这个平台，运维可以自己写脚本，去改配置文件，并且把这个脚本注册到作业平台，变成自制的原子节点。
直到有一天官网提供提供了API让运维可以调用，这个时候运维就可以可以放弃自己做的这个原子了，但是在此之前运维可以用这种方式不受任何制约的靠自己实现调度自动化。
首先，配置平台必须能够存取基础信息，还能够存储业务的拓扑结构，做得好一点的可把拓扑结构做成可视化的。
在第二阶段，你的CMDB要连线，CMDB在不连线的时候就是一个线下操作。你可能在处理完一个故障之后，改变了一个svr的ip，但是忘了去CMDB去修改这个变化，这个时候就可能出问题。
最理想的过程是，在整个调度自动化链条中，修改CMDB这个节点是嵌在链条内的，这样你就可以放大CMDB的作用。
比如说，你可以往里面自定义各种各样的属性，可以在不同的业务下对不同的业务进行配置，比如K=V，我就可以在业务的结构之外，以另外一个维度锁定我的操作对象，这就是CMDB的最基本的功能。
CMDB如果不产品化，不向别人推广的话，其实不一定要做到快速部署。
一般的Server都是有状态的，可以解决非标准业务的配置标准化问题，当业务足够大的时候可以解决跨云管理。
一般企业的内部IP编排都是按顺序来的，一个企业并购了另外一个企业，可能就会碰到有跨私有云的IP冲突问题，CMDB可以解决这个问题。
还有是双向的自校验，可以自检测运营环境变化，然后告警或者直接强制同步。
整个蓝鲸体系对IaaS层的所有操控都是依靠这个管控平台，统一为一个Agent，管控平台是我们内部一个比较重要的平台，海量全球化管控和跨云管控、大数据采集都靠它。
目前这三个平台已经和腾讯云合作，在腾讯云上可以体验云化版本，另外也已经完成了独立搭建版本的开发，目前提交给几家合作企业做内部测试。
这类基础平台的对外提供，都是免费的，可以管理服务器的数量我们设置了上限，1万台左右。
“自动化”这个词有点用烂了，大家写一个脚本就说自己自动化了，在我们内部把“自动化”重新定义了—在手工操作和智能操作之间大概要经历这么几个阶段：
脚本自动化：运维写很多脚本，一个回车全部执行完，这是脚本自动化，工作必须由运维来做，其他人没有操作权限。
系统自动化：DBA团队开发了一个DBA管理系统，官网团队开发了官网管理系统，你只需要在页面上点一下就操作了，这叫系统自动化或者web自动化。
但这里有个问题，在DBA管理系统上要做一个大的库表操作，可能要等一两个小时。
再比如即使有了一个测试管理平台，但你点击页面操作了之后，只是提交了一个单据，测试人员什么时候测你还不知道，可能要等到第二天，这个时候在系统之间切换就出现了一个“切换损耗”。
调度自动化：切换损耗的解决很容易想出来，就是调度自动化，无论是原有的系统还是在建的系统，都通过API的方式把核心服务暴露出来，在一个上层场景应用上整理好所有参数，点一个按钮，通过后边的调度引擎，帮你一个系统、一个系统之间进行切换，这叫跨系统调度自动化。
智能化：智能化最初阶段就是无人值守。自动化的核心节点并不多，但如果想升级为无人值守模式的话，就需要像图里这样再往里面添加很多节点，一个简单的扩容操作的无人值守链条，可能会有40多个节点，比如工单节点、校验节点、锁控节点等等。
在SOA模式下，需要在服务总线的上层构建各种类型的场景系统，这就需要说到PaaS。
什么是PaaS，如果你想称之为PaaS的话，至少需要具备两个要素：
一是对代码的全托管、免运维；二是能够提供云API。
技术运营体系为什么要做PaaS呢？
PaaS最大的优势在于成本低。
构建成本低，维护成本也低，低到普通应用运维都可以开发场景工具或者运营系统，这就是我们的目标。
我们的定位是用于开发企业内部的运维系统，我们需要让企业内部开发运维系统的成本降到足够低。
传统开发一个运营系统需要做什么？
先把需求确定好，去弄一台机器，把环境各种包打好，公共组件装好，然后开发，再代码部署，还得做代码管理，监控告警，日志追溯，反复修改，这是一般开发网站必须经过的过程。
但是PaaS上的模式是：应用需求、应用开发，其他的都不用管，甚至连代码部署到哪里都不知道。
APP Engine Docker，其实最划算的方式就是用容器，开发者并不知道运营系统被部署到哪里去了，只需要知道被部署到云上，已经实现了高可用就OK了。
既然我们做的是一个面向运营系统的垂直PaaS，那好处就是我们知道上面跑的都是运营系统，没有其他乱七八糟的东西。
那针对于一个运营系统来讲，我们还可以做进一步的成本拆解和降低。
比如说开发一个运营系统，至少要开发前台、后台，做得好一点的话会分离出组件，针对这三个部分能不能把成本降低一些？低到我们的普通运维就可以开发运营系统？
我们搜集了很多页面元素堆在这里让你去抄，让普通运维绕开前端开发的障碍，后台方面我们把登录鉴权、日志、权限控制、云API等封装到一起，我们可以把所有注册到服务总线里面的原子，以函数的形式封装到这个框架里去。
比如你要实现一个资源选择器的时候，经常会需要实现一组框框：
第一个框是选择哪个业务，选中这个业务的时候，它应该自动地把选中业务的模块列表塞到下面的框里去，这样一个简单的div在很多运维系统里都会碰到，而运维只需要用一行代码就可以实现。
通过这几种服务，运维能够低成本的搞出系统的前端、后台代码。
在我们内部，一个普通的正编运维经过30天左右的兼职培训就可以开发支撑工具甚至运营系统。一个智商正常的本科毕业生，经过三周的封闭培训也能达到类似效果。
我在跟业界一些运维交流的过程中，听他们反复地提到云技术、大数据技术，后来才发现这些运维不是在用大数据技术，只是在维护他们公司的云平台，数据平台而已。
但是蓝鲸数据平台不一样，它是由开发维护的，提供给运维来使用。
大家没有运维数据平台也能干活，数据采集类的需求可以用脚本采到文件里，传输到一起然后入库，再用sql捞，但当数据量大到一定程度，就跑不动了，这个时候运维需要改用另一种架构来做数据采集、汇总、计算和展示。
所需要的就是刚才提到的蓝鲸agent。蓝鲸体系就这么一个Agent，做了所有的事儿。
有的公司装了很多Agent，不是说技术上不能融合，而是因为它是由不同的团队开发的，Agent越多，维护的成本和风险越大。
整个采集、传输、汇总，以前的方式是运维写一些脚本，入库，这个过程在蓝鲸数据平台上只是如图配置好规则，经过计算之后再拿到一个结果流。
大数据计算对运维来说也是一个问题，他们写不了Storm计算任务，所以我们让他们写YAML来描述解析和计算逻辑，后来又有运维说这个也太复杂了，我们又做了SQL引擎，后面又开发了图形化托拽。
Storm的结果流和入流数据量是差距很大的，运维只需要把结果流数据展示到页面上，可以在PaaS上开发一个系统来展示，也可以使用我们提供的这个SaaS拖拽出一套仪表盘用于展示。
我们整个PaaS平台结构也是很复杂，在我们内部，这是运维系统的一种开发模式，凡是不属于原子操作的、不能够支撑所有场景的，都没有资格被说成一个PaaS下面被调动的原子平台。
比如监控，你做一个监控平台有什么用？监控的目的是为了修复故障，你直接集成一个系统把故障恢复就可以了，并不需要在底端做一个平台用来展示监控。
否则的话，你会发现做了一个监控平台、发布平台，它们当中都包含了对底层的控制部分和管道部分，这完全是重复建设。
而且在某些环境下，一些新的功能应该基于哪些平台开发，往往取决于哪个平台的负责人声音大，而不是“应该”，僵尸平台满地都是。
在蓝鲸模式下，你可以很清晰地知道下一个开发的应该是什么平台，你可以分析哪一个原子点没有自动化平台支撑，比如说官网，对官网的所有操作大家都是用脚本在操作的，这个时候就应该开发一个官网管理平台，将API对接到ESB。
因演讲内容非常多，关于更精彩的SaaS实现及故障自愈等内容，我们预计将于明天（4月20日）推出。敬请期待。
GOPS全球运维大会，别无分号！
开放运维联盟和高效运维社区联合主办。
联系客服
