a. 系统日志报错是指在/var/log/messages中能够找到类似下面这样的报错
Sep 3 13:43:22 host1.a1 kernel: : [14809594.557970] sd 6:0:11:0: [sdl] Sense Key : Medium Error [current] Sep 3 20:39:56 host1.a1 kernel: : [61959097.553029] Buffer I/O error on device sdi1, logical block 796203507
b. tsar io指标变化是指rs/ws/await/svctm/util等这些指标的变化或突变，由于报错期间会引起读写的停顿，所以通常会体现在iostat上，继而被采集到tsar中。
- 在tsar io指标中，存在这样一条规则让我们区分硬盘工作是否正常 qps=ws rs<100 & util>90，假如没有大规模的kernel问题，这种情况一般都是硬盘故障引起的。
c. 系统指标变化通常也由于io变化引起，比如D住引起load升高等。
d. smart值跳变具体是指197(Current_Pending_Sector)/5(Reallocated_Sector_Ct)的跳变。这两个值和读写异常的关系是：
- 媒介读写异常后，在smart上能观察到197(pending) 1，表明有一个扇区待确认。
- 随后在硬盘空闲的时候，他会对这个197(pending)中攒的各种待确认扇区做确认，如果读写通过了，则197(pending) -1，如果读写不通过则 197(pending)-1 且 5(reallocate) 1。
总结下来，在整条报错链路中，只观察一个阶段是不够的，需要多个阶段综合分析来证明硬件问题。由于我们可以严格证明媒介故障，我们也可以反向推导，当存在未知问题的时候能迅速地区分出是软件还是硬件问题。
上述的工具是结合运维经验和故障场景沉淀出来，同时我们也深知单纯的一个发现源是远远不够的，因此我们也引入了其他的硬件故障发现源，将多种检查手段结合到一起来最终确诊硬件故障。
2.2.如何收敛
上一章节提到的很多工具和路径用来发现硬件故障，但并不是每次发现都一定报故障，我们进行硬件问题收敛的时候，保持了下面几个原则：
- 指标尽可能与应用/业务无关：有些应用指标和硬件故障相关性大，但只上监控，不作为硬件问题的发现来源。 举一个例子，当io util大于90%的时候硬盘特别繁忙，但不代表硬盘就存在问题，可能只是存在读写热点。我们只认为io util>90且iops<30 超过10分钟的硬盘可能存在硬件问题。
- 采集敏感，收敛谨慎：对于可能的硬件故障特征都进行采集，但最终自动收敛分析的时候，大多数采集项只做参考，不作为报修依据。 还是上一个硬盘io util的例子，如果单纯出现io util>90且iops<30的情况，我们不会自动报修硬盘，因为kernel问题也可能会出现这个情况。只有当 smartctl超时/故障扇区 等明确故障项出现后，两者关联才确诊硬盘故障，否则只是隔离观察，不报修。
2.3.覆盖率
以某生产集群，在20xx年x月的IDC工单为例，硬件故障及工单统计如下：
去除带外故障的问题，我们的硬件故障发现占比为97.6%。
3.硬件故障自愈3.1 自愈流程
针对每台机器的硬件问题，我们会开一个自动轮转工单来跟进，当前存在两套自愈流程：【带应用维修流程】和【无应用维修流程】，前者针对的是可热拔插的硬盘故障，后者是针对余下所有的整机维修硬件故障。
在我们的自动化流程中，有几个比较巧妙的设计：
a. 无盘诊断
- 对于宕机的机器而言，无法进无盘(ramos)才开【无故宕机】维修工单，这样能够大量地减少误报，减少服务台同学负担。
- 无盘中的压测可以完全消除当前版本的kernel或软件的影响，真实地判断出硬件是否存在性能问题。
b. 影响面判断/影响升级
- 对于带应用的维修，我们也会进行进程是否D住的判断。如果存在进程D住时间超过10分钟，我们认为这个硬盘故障的影响面已扩大到了整机，需要进行重启消除影响。
- 在重启的时候如果出现了无法启动的情况，也无需进行人工干预，直接进行影响升级，【带应用维修流程】直接升级成【无应用维修流程】。
c. 未知问题自动化兜底
- 在运行过程中，会出现一些机器宕机后可以进无盘，但压测也无法发现任何硬件问题，这个时候就只能让机器再进行一次装机，有小部分的机器确实在装机过程中，发现了硬件问题继而被修复了。
d. 宕机分析
- 整个流程巧妙的设计，使得我们在处理硬件故障的时候，同时具备了宕机分析的能力。
- 不过整机流程还以解决问题为主导向，宕机分析只是副产品。
- 同时，我们也自动引入了集团的宕机诊断结果进行分析，达到了1 1>2的效果。
3.2.流程统计分析
如果是同样的硬件问题反复触发自愈，那么在流程工单的统计，能够发现问题。例如联想RD640的虚拟串口问题，在还未定位出根因前，我们就通过统计发现了：同个机型的机器存在反复宕机自愈的情况，即使机器重装之后，问题也还是会出现。接下来我们就隔离了这批机器，保障集群稳定的同时，为调查争取时间。
3.3.业务关联误区
事实上，有了上面这套完整的自愈体系之后，某些业务上/kernel上/软件上需要处理的问题，也可以进入这个自愈体系，然后走未知问题这个分支。其实硬件自愈解决业务问题，有点饮鸩止渴，容易使越来越多还没想清楚的问题，尝试通过这种方式来解决兜底。
