我叫颜小云，来自百度系统部，我在百度主要负责百度数据中心基础设施监控和运维系统的研发工作。我今天想给大家分享的题目叫数据中心基础设施故障管理最佳实践，这个也算是2016年ODCC数据中心基础设施运维最佳实践项目的延续。副标题是论告警收敛和监控架构，这是想强调一下，故障和告警是2个不同的概念，因为并不是所有的告警都是故障，因为很多告警可能是数据中心的正常操作引起的。因此我今天的分享可以用一句话来总结：就是如果通过对数据中心原始告警的处理，来产生真正有意义的故障，从而做好数据中心基础设施的故障管理工作。
数据中心的可靠性是最重要的，因此我们在建设初期就会做很多的2N或者N+1的架构，到了运维的时候，我们也会做数据中心的巡检和维保等等，除了这些以为数据中心的监控系统可以说是帮助我们发现数据中心监控状况的眼睛。但是在我看来，现在数据中心的这个“眼睛”其实有不少问题，而其中最主要的问题，恰恰是因为这个“眼睛“看到的东西太多了。举个例子：这里有1个实际的机房，大概有8万台服务器，我统计大概了有两个多月的告警数据，大家可以看到上面有很多点，在一个点表示12小时里面这个数据中心收到的告警量，一共有160个点，160×12小时，这样算下来就是2个多月的时间。每个点代表这12小时之内，我们数据中心所收到的告警数量，最多的时候12小时收到5800多条，平均每个小时610条，中位值是300多条。这是我们数据中心一个真实的案例，所以在我个人看来像这样的告警量是很难满足数据中心运维要求的，我认为现在告警至少有三个方面的问题。
第一， 数量确实太多了，这么多数量我们很难逐条处理，有很多运维同事直接批量确认了，这样批量确认可能会遗漏掉一些重要告警。
第二， 这种告警不能直接定位根因故障，特别是在一些重大故障的时候，会有很多告警上来持续刷屏，造成一些我们刚刚入职的新同学觉得比较恐慌，不知道发生了什么事情。
第三， 我觉得现在数据中心很多告警系统，往往并不能反映数据中心现在真实的健康状态。举两个例子，我们用了很多高压直流模块，模块也有不少坏件，所以我们也和我们的供应商去聊，问问他们有什么方法帮助我们提前发现模块的故障，而厂家的反馈是最有效的方法是看高压模块的内部温度，如果它的温度比较高，说明它的功率件可能有问题。但是很遗憾的是，高压模块里根本没有温度点的监控，它给我报了很多的电压、电流、功率，到那时对于我们发现它的故障来讲其实并没有直接的影响。另外1个例子是水泵，我们也和我们的水泵供应商聊怎么能够提前发现水泵的故障，他给我们反馈是看它的振动信号，如果振动超标了，发现逐渐变大了，说明这个水泵有问题。但是同样的情形也是一样的，水泵的监控信号里面是没有振动信号的。所以这些都是当前数据中心遇到监控遇到的问题。
遇到这些问题以后，我总结了一下大概有两个方面的做法可以帮助我们去解决这些问题，一个是告警过滤，通过设定合理的阈值，会过滤掉不少的垃圾告警，对于我们的一些正常操作，可以根据情况提前屏蔽掉一些垃圾告警。另外是告警定位，可以帮助我们识别告警根因，发现故障，比如我们数据中心的专家，如果他站在我们数据中心配电单线图上，他看到这个开关跳闸，那个开关跳闸，基本上可以看出来现在是什么情况。其实这种规则我们是可以抽象出来的，然后把它固化到软件上，在下次还有这种情况的时候，我们的软件就可以自动判断。
但具体怎么落地呢？第一个想法是让厂家去做，我们招标的时候，让厂家按照我们要求做到标书里面，落地的时候让厂家按照标书实现这个功能。但是现实往往有一些困难，首先它不是那么灵活，厂家通常做的都是标准品，他们提供给我们落地的产品并不是所有功能都能实现的。另外就算一些比较负责任厂家按照我们要求做了一些定制的东西，但是做完了之后，特别是各种管理系统，其实我们后续还有很多维护要求，这个时候要再去升级软件的时候，就会遇到一些困难，因此现在包括我们公司，包括腾讯，我们上层的管理系统都是自己研发的。如果我们要自己做研发的话，其实有两个途径，不管是百度也好，腾讯也好，基本都是从这条路来走的。第一，基于厂家告警自己做加工收敛，我们通过厂家的接口，把这些信息收集上来以后我们自己做告警收敛，还有一个途径是我根本不信任厂家的告警，厂家告警，系统告警一个都不看，我只采厂家实时数据或者设备状态，然后根据采集到的数据，我自己做告警引擎来判断。不管是哪种途径，都有两个重要问题要解决，一个是基础数据的准确性、时效性，必须非常及时告警，而且不能漏掉掉数据，不能说一千条告警，你传给我的时候只有八百条，这样是不行的，所以这两个问题都需要解决。
先说说数据的时效性和可靠性问题。有一句话说得好，如果你不能测量，你就没法管理，如果你不能管理，就无法改善。传统的数据中心架构就是这样的，厂家在数据中心本地有一套监控系统，下面有一些采集器，把被监控设备抓上来，厂家再通过一个接口把信息传给我们上层管理系统。这个接口每天大概要传好几百条告警，这么多告警，不可能一条一条人工去比对，我们没有统计之前，我们也会收到很多告警，我们也认为接口不会有问题，但是我们真正做统计的时候发现这个情况还是比较严重的。结果我们和供应商直接开一个数据库示图，我们上层再做一个软件，从数据库里面直接抓底层的告警，再和接口抓到的告警进行对比，结果一对比发现，情况远比我们想象得要糟糕。但不管怎么样，有了这样的机制，就建立了我们持续改善的基础。所以我们接下来也和运营商一起发现了很多接口问题，我们前前后后大概处理了半年时间，基本上现在可以说我们把接口的问题处理掉了。有一天我们电池在一个小时内上报了有4万条告警，但是都没有遗漏。
另外怎么做告警收敛，我们现在告警收敛有两个途径做，比较通用的是告警收敛引擎，我们把所有原始告警收集以后，我们会做三重合并，基础合并是把告警开始和结束的告警进行合并，第二是设备级别的告警，同一个类型的告警会合并在一起。还有系统级别的告警，在里面配了很多规则，一条一条的根据告警顺序，告警规则生效以后，系统会自动判断当前是说在做UPS还是空调的轮换，判断以后最后会出来一个根因告警，。还有一种做法叫故障预判引擎，我们会用机器学习算法看它的半个小时、一个小时的数据，比如温度，包括水泵振动信号采到之后，我们根据它的学习数据，基本可以预测到这个点位在半小时一小时之后它的数值之后，根据预测数值和实际采到的数值做对比，如果发现两个之间差额达到一定程度的时候，我们会判断这个点是有问题的。
最后说两个呼吁，希望能利用ODCC这个平台聚合行业力量，共建产业生态。一个是我们希望厂家在系统里添加数据层功能，可以做到数据标准化，故障预判引擎和故障收敛引擎，这样我们只专注于这里面的规则，我们就不用自己开发引擎，并不是所有用户都有自己开发引擎的能力。另外希望我们接下来能够更多的在接口、监控架构做到扁平化，统一采集器接口。这样用户管理系统可以从采集器这个级别直接到采集到监控数据，而不是一定要通过北向接口去采集。这就是我今天主要分享的内容，谢谢大家！
