人食五谷杂粮难免会生病，IT系统运行中也会难免有”头疼发热“，人生病了医生会望、闻、问、切一套操作，IT系统也一样，在SRE运维中可以运用 ”六查 “ —– 查关联关系、查变更信息、查操作记录、查告警信息、查性能数据、查机房工况来完成故障问题的定界定位。

一、查关联关系

先查看下面一张图，左边是一个IAAS层的常见关联关系，右边是一个应用的常见关联关系（这个画的比较简单，后面的mq就是涉及到可能会和其他应用交互，其他应用这里省略掉了）。当一个故障告警来了以后，基于对应的告警信息，我们可以把它对应的设备和应用调用关系查出来。再结合一些健康评估工具和常见监控工具，可以第一步标注出当前异常的设备或应用点，可以对于需要进行查询的范围和可能存在的问题，有一个第一步的预判。

relationship
relationship

这里对应的关联关系就需要依赖动态实时的CMDB关系数据。所认为了保证CMDB数据的准确性，就需要动态采集、API主动上报更新、流程规范对接更新等手段来保证数据的准确和及时性。该步的数据，一般在大的企业里，伴随故障事件的发起，会同步完成数据的调用查询和结果输出展示。

二、查变更信息

虽然生命在于折腾，但折腾就会存在各种意外。一些老运维人员经常发出的感慨就是，一些系统或应用，尤其是运行了N年没人能说的清的系统，千万轻易不要动，不动的话，一些功能使用正常。一旦重启了或者升级了，那就要了亲命了，系统启不来了，应用本身可能没人能说的清里面怎么调用的了，诸如此类，终归不折腾一段时间是很难抢救过来的。所以很多问题并不是无缘无故就来的，很多计划内变更引起的，也有一些是人为做了某些操作引起的。所以在通关联关系确认调用链的设备或应用后，就需要查有没有与之相对应的变更或操作。

当然查变更不能简单的说我从当天的部署变更邮件、版本升级变更流程里找到了有人操作这么简单，最后可以查出变更在设备上进行了什么操作？如果操作记录非常多总不能一下子把上万行的记录丢出去就完事了，是不是可以通过事件建设的平台先过滤掉在异常告警时间段比较接进的操作，再过滤无风险查询类的操作，以linux指令为例：如比ls 、pwd之类的就属于查看无风险的，重点关注rm、mv之类的修改类操作。如果是版本变更的，需要按对应的流程规范明确标注下，当天的操作主要修复了哪些bug及概述性的简要说明下涉及的应用模块，可能影响的应用等。

三、查操作记录

变更和操作记录从本质上说的是同一个事，不同的是变更记录一般都是计划内的、有流程制约、操作也是内部多人知晓公开的信息。但也有一些操作是公司的某A同学无意间的一个操作或部署的一个计划任务，在他看来是不存在风险的，甚至在事情发生的时候发也根本不会觉得是这个操作引起的。比如我在运维工作中就遇到过有小伙伴在多个主机执行grep -r * 操作把nfs存储搞的无法响应、增加的定时任务执行异常应用访问异常的问题。所以可以通过ELK这类工具，把OS、数通设备、云平台等相关的操作记录统一存放，在故障时间点时进行关联调用。

elk-log
elk-log

四、查告警信息

这里的告警信息不仅仅指符合zabbix等监控工具设置的告警条件的告警，这里的告警有硬件设备的健康告警信息，比如硬盘坏了、raid级别降级，tomcat里持续出现的error日志，分布式存储平台出现的性能时延告警等。因为告警来源比较多，常见的做法还是通过ELK这类工具进行汇聚并统计。同样，在出现故障时，SRE的值守人员不可能逐条去看，因为日志上万条很正常。所以推荐的做法如下：

  1. 通过运维经验积累，通过关键字信息给告警进行分类：1、2、3、4级告警；
  2. 进行数据汇总统计，排序透析等，尽量在出现故障时给出总结性的结论信息。同时也支持原始数据导出。

五、查性能

性能平时我们多以图的方式进行查看，出现性能突刺的时候也比较方便的查看出来，比较查用的工具是prometheus、zabbix、prtg、smartping等。当然这个也是和上面结合的，通过上面关联关系+告警信息给出的缩小目标范围内的设备、OS、应用性能等性能数据的变化，确认是否有异常。

六、查机房工况

还有问题是由于机房温度、机柜掉电等引起的，当然像机柜掉电是可以通过共性能分析来进行推断的（这个属于共性分析和根因智鉴的范畴，不在该篇幅讨论的内容）。规范化的机房是配置有机房温度监控、电源供电监控等配套的，出现故障理论也会通过IVR或IM的方式通知到SRE的值班人员的。不过也不排除机房是IDC供应商的情况。所以在出现故障的时候，也可以同步在上面几个调度进行时，如果出现了批量问题，也同步调度机房值守人员反馈机房的工况（含硬件设备告警灯闪烁）情况。

以上就是个人认为SRE调度过程中6查情况，在实际运行中，要尽可能的在一个通用的平台上完成上面多个查询功能点的集成，不要让调度人员来回切平台或手工去查询。中间浪费的就是时间。同时还要结合对应的架构和企业自身的情况，确认适合自己的故障调度运行方式。