【首发】腾讯蓝鲸核心功能图文详解（精彩互动） | 高效运维

【首发】腾讯蓝鲸核心功能图文详解（精彩互动） | 高效运维

主要讨论参与人员

cloudliu@腾讯游戏邵勇强@HW-深圳张磊@浙江大学-杭州王琦@华尔街见闻-上海

编辑

程成@爱普（内容收集 & 文章整理）萧田国（审核 & 发布）

嘉宾介绍

党受辉（咖啡党），腾讯游戏 蓝鲸产品中心总监做过多年运维团队管理，期间为不同类型的游戏及千万PCU级游戏平台设计过自动化运营系统。目前负责腾讯游戏运维支撑体系（蓝鲸）的建设和运营，致力于打造行业级的基础运维无人值守解决方案以及数据化增值运维解决方案，推动devops生态。十余年来专注行业信息化及运维领域。

好的。下面就是本次分享的互动环节整理（真的非常精彩哦：）。

备注：如果您想更多了解腾讯蓝鲸，可以先参阅如下资料：

腾讯蓝鲸核心功能图文详解（分享实录）

腾讯蓝鲸体系架构及设计思想

第1部分：关于蓝鲸和数据库的配合

Q1：如何应对关系数据库更新？A1：我们这有专职的DBA团队，数据库的更新操作他们建设有统一的系统并给我们开放了接口，如果没有这样的团队，有两种做法，某次更新操作如果能封装进脚本，就自建原子调用，大多数不行的，应用运维就将这个节点设置为暂停节点，等DBA操作完之后，再继续走下边的流程。

Q2：咱们这边多少dba，维护多少个数据库？他们也采用蓝鲸?A2：腾讯游戏有20多个DBA，维护了近2万个DB实例。除了维护之外，还负责存储的开发，例如Tmysql和TSpider等，下次可以请DBA的同学也到群里分享一下。

Q3：我们dba团队采用蓝鲸监控还是也有类似什么系统，能有这么强大的维护能力？A2：DBA有一套专用的系统，叫GCS，可以完成DB相关的监控和操作，这套系统提供了API给蓝鲸，跟蓝鲸上的各种app打通。

第2部分：agent及数据采集

Q4：蓝鲸如何考量机器上的agent等进程的资源占用以及隔离这些进程？A4：我们的agent占用系统资源平时低于1%，可以设置连续三次高于某值时agent自杀，这类功能对于智能agent是都会有的，检测间隔5秒。

Q5：如果放开由自己写agent数据采集上来，由于数据没有格式化，如何做自动化分析？A5：上报数据的格式除了前几列是我们固定的，后边的都是运维自己定义的。在运维用yaml写计算逻辑的时候，前一部分是解析逻辑，运维要用我们指定的语法对上报数据做解析，如果数据格式变化，那要重写yaml。

第3部分：报警及自动化处理

Q6：关于报警这块，如何做到告警去重、合并、聚合?A6：故障自愈有收敛机制，每条告警都带有时间戳和类型，会与时间库比对匹配，具体的规则我们按照我们的业务特性是固化的，这里就不方便说了，大致是按照时间、类型、机房等。

Q7：凡是监控，肯定会有误报的可能性，蓝鲸的自动化修复程序遇到监控程序误报，还会照常执行恢复脚本吗？A7：故障自愈的逻辑是应用运维根据具体告警设置的，逻辑中都会带有检测节点，如果是误报，检测节点走不过去；如果是固定套餐，都是做了检测逻辑的，例如ping告警的处理逻辑中第一步就是“ping一次”。

Q8：自动化处理告警有一个弊端：无法知道是什么原因导致这条告警，蓝鲸在自动化处理之下，是如何做到告警数量收敛的呢？A8：我们的事件库中收录了很多渠道的带时间标签信息，另外有一个规则匹配库，和事件库，规则库是根据我们业务的监控情况配置的，例如我们的一台服务器故障，会引发ping告警，基础agent上报超时告警，业务进程不存在告警，甚至会引发在线下降告警，这些一部分是通过固定规则库过滤的，另一部分是应用运维根据自己配置的方案过滤的。

Q9：连锁报警怎么自动处理的呢？按报警时间还是会判断主次？或按报警级别之类的？A9：在设定的时间窗口内，收敛一系列告警，通过故障树收敛规则判断出故障的主原因，有些原因是分析类的，有些故障是处理类的。处理类会继续执行故障自愈的处理模块实施处理操作；单对于解析出来的超过三个以上的完全相同的处理预案，会暂停处理要求运维确认，以防止是批量误报，这类异常防御策略，曾经成功规避过运维误报告警ID导致的大面积故障。

Q10：每天几十万预警/告警数据都会在界面展示吗？運維人员也没法看呀？另外我们每次部署升級效率如何？A10：预警量每天是万级别，在故障自愈官网上是可以看到的，但有做按类别折行，而且有分了业务，还算能看下去。

Q11：告警逻辑树，是通过什么方式整理出来的？A11：应用运维自己应该熟悉自己的业务架构、某类告警的排查方式。对于首次出现的告警，是不能由系统自动恢复的。

Q12：我想知道我们预警处理那么高准确率怎么做到的？我们故障树，告警相关性分析，也做了十几年了，规则整理和大数据分析准确性都不高。A12：实话讲，预警的准确率是被总量拉高的，因为运维配置的预警量太大，每天多达上万，大多数预警都是不需要处理的，这个是按成功处理计算的，因此准确率看起来很高。真正反映我们故障自动恢复能力的是“报警”的自愈率，94.25%。

Q13：请问自动恢复系统依据的核心原则是什么？如何保障在业务依赖复杂，报警多而分散的情况下做修复判断呢？A13：告警捕获——告警条目信息字段补全——收敛规则过滤——事件库分析——自动处理这里最复杂的就是收敛规则过滤和事件库分析两个环节，由于我们的基础告警类型都是相似的，因此可以沉淀出一整套过滤规则，这个估计对大家的参考意义不大。告警量其实并不是问题。

Q14：你们这些告警会产生工单分配出去吗？如果修复了会自动关闭吗？会继续追踪吗？A14：告警经过收敛后产生极个别的告警通过工单发送出去，通过故障自愈修复的告警，用户可以选择通知，也可以选择不通知，最后通过故障自愈的健康度分析继续跟踪，规避业务潜在风险。

第4部分：开发语言及成本

Q15：底层都是用python实现的吗？还是用golang实现的？两者做底层各有什么优劣？A15：管控平台主要是c实现的，包括agent；其他的平台绝大多数都是python的，我们应该是深圳最大的python团队了。漏了一点，数据平台不是，storm平台还是用java继续二次开发的。

Q16：T级别以上数据使用的是Hadoop？还是python的numpy？针对秒级实时分析又是用什么实现的呢？A16：基于kafka、storm的二次开发，目前蓝鲸数据平台上单个监控项的流量是每天1.3t，平均25亿条，平台总量每天60亿条左右，源数据未做长期存储，用了ES和我们TEG开发的hermes。

Q17：蓝鲸平台从设计到开发，使用了多少开发人力和运维人力和其他人员等？A17：蓝鲸一期项目是四个运维做出的原型，没开发。paas的原型搞定之后，cloudliu开始逐步投入资源，二期完成（基本功能完全具备）时候大概有十余个开发。后续对稳定性、安全性，管控平台、数据平台的投入就另算了。

第5部分：数据录入及一致性

Q18：资产管理怎么自动录入，比如扩容的是服务器，路由器，交换机等物理设备？A18：蓝鲸配置平台相当于云化的cmdb，页面操作都有对应的接口，运维的操作流程中会嵌入对配置平台的修改维护节点，否则配置会出现错误。这涉及到操作类APP的一个上线审核流程，这在我们内部是比较严格的，需要运营规划以上级别审核过的app才能连续使用，否则N天后就会打不开（N可配置）。

Q19：原子服务组成一个流程后，这个流程的中间节点执行失败了，是否有事务机制保障？如何补偿？A19：流程的执行过程中，如果失败，默认暂停在失败节点并发送通知给运维，用户可以登录蓝鲸，选择重试节点或者跳过操作。

第6部分：其他

Q20：针对传统企业-erp业务系统，是否适合蓝鲸？A20：传统企业的erp系统如果使用的是AIX、Solaris 之类的服务器，我们的agent目前没有做适配。

Q21：被蓝鲸平台替代的运维人员是如何安置的？辞退吗？A21：蓝鲸之前运维主要在忙基础操作服务，应用运维逐步利用蓝鲸讲基础服务自动化之后，都转向增值服务，目前的运维团队相比蓝鲸早期的时候还扩充了很大的规模。

Q22：蓝鲸平台的公有云服务是否能支持呼叫接入功能？就是为中小企业提供呼叫落地接入，坐席灵活分配。A22：这个目前真没有。

———问答环节结束———

再次附赠相关参考资料，如下：

腾讯蓝鲸核心功能图文详解（分享实录）

腾讯蓝鲸体系架构及设计思想

如何一起愉快地发展

提示：目前高效运维新群已经建立，欢迎加入。您可添加萧田国个人微信号xiaotianguo8 为好友（或扫描如下二维码），进行申请，请备注“申请入群”。