10 - 对于“拥抱故障”的反思

对于故障的思考

前几天微博feed呵呵了一下，于是最近就没干别的全都在善后，闲暇之余也想总结一下这些年对于故障的一些思考。

根据历次经验来看，解决问题并不复杂，很多时候作为“事后诸葛亮”来分析，导致故障的根本原因都非常的简单。但是在“捅破那层窗户纸”之前，我们看故障却如“雾里看花”一样，大部分的时间都花在定位问题上，并且需要相关各方面的人来介入，这就导致效率的低下。而又因为参与的人多，沟通成本必然上升，各种干扰因素也会时不时的冒出来，就导致的解决故障的时间延长是个必然了。

总体来说，引发故障的原因可以归纳为3中：

1. 各种变更，90%

2. 资源不可用，9%

3. 自己作，1%

大家可以回想一下自己遇到的故障最终找到的原因，基本都可以归纳到前2项中，至于第三项，必须解释一下，有些时候我们明知到不符合规范要求，但是由于各种理由妥协了，这基本就注定我们为自己挖了一个坑，只是不知道自己会在什么时候掉下去。这些，我都归纳到自己作里面了，在此警醒自己，有些规范是一步都不能退让的。

发现

说到发现就必然想到监控，但是好的监控可以帮助你，坏的监控会让你扔掉手机。试想，你每天收到300+的短信报警，谁还有心情逐条去看呢？所以，监控并不仅仅是有了就完事，而是要在监控的基础上实现我们监控真正的目的----发现问题。

要做的事情一般有如下几种：

1. 分级 （重要的电话，一般的短信，可延迟处理的邮件）

2. 加工分析 （摒弃出问题就报的逻辑，加入重试、验证、加权等逻辑）

3. 关联 （硬件 + 软件 + 服务 ，通过内在关系聚合在一起）

定位

定位之难处理过故障的人都深有体会。一个人开发的系统你找到这个人就可以了，一个team开发的系统你找到这个team的主管就可以了，n个人+n个部门一起参与建设的系统，基本上就只有两眼一抹黑了。毕竟“总架构师”们也不见得能把所有逻辑路径搞的门清，而且互联网公司三天一上线谁也不敢拍胸脯保障全了解。

但是，定位又恰恰是解决故障最关键的一个点，大量事实验证8成的时间用于定位，而解决方案其实用不了2成的时间。

想要快速定位，需要做的事情个人总结有如下几种：

1. 信息汇总 （只有拿到全部信息的情况才可以下有效的判断）

2. trace系统 （缩小排查范围）

3. 趋势变化分析 （定位时间点）

通过经验，时间点是一个非常关键的线索，大部分的故障原因都出现在关键时间点附近。

最后，说一点和技术没关的，在处理故障的时候还是要有拥抱故障的心态，尽量提供真实的信息，有些时候出于“部门利益”的考虑，可能会造成“聪明反被聪明误”的事情发生。

处理

俗话说得好，常在河边走哪有不湿鞋。故障对于运维来说，就如同“达摩克利斯之剑”一样，它就在那里，随时随地都有可能掉在你头上。但是，如果悲观的认为这就是命了，完全对故障无感这其实是对自己的不负责。不过，如果反过来想要通过各种手段达到永远不出故障，个人认为这也不现实，毕竟这个世界上没有100%健壮的系统。

那么，我们应该追求的系统是什么样子的呢？

个人认为，我们需要追求的应该是一套可以针对任何突发情况进行快速自愈的系统，我们枚举不全可能会出问题的点，但是我们可以根据悲观主义，设计出来在各种问题都爆发的情况下，如何能保障服务继续的提供，至少是有限的提供。只有这样，我们才不会被未知的故障击倒。

对于快速自愈有如下几个通用的办法

1. 回滚 （宁可错杀不可放过）

2. 降级 （丢车报帅）

3. 重启 （这个就不说了，万能法宝）

以上这几种方法，其实可以做成一些固有套路，在没有完全定位清楚的前提下，按照一定的规划来实施，就如同使用了“时间倒流”的魔法一样，让服务重新可用。最不济，也可以为追查真正的问题争取来一定的时间。

最后，说一点和技术无关的，在故障处理过程中，尤其是大型故障，一定有一个统一的大脑来指挥和汇总信息，在这种时候“无中心化”只能让事情变得更糟。

其他

大家都知道“只有千日追贼，没有千日防贼”的，但是对于运维工作来说，我们要做的就是“千日防贼”，所以我们只能将工作都做在前面，做在日常的工作中。而对于故障，不要深恶痛绝，因为每次故障其实都是一次机会，这是证明我们的各种自动化运维系统的功效的一次机会。既然故障无法避免，那么区分牛不牛的标准就变成了处理的快不快，而且每次故障也都是一次非常好的经验积累，我相信处理过100次故障的人的经验一定比没处理过故障的人丰富，这是种必然。

最最后，希望大家都抛开“责任人”这种无意义的东西，做到真正的“拥抱故障”，从故障中吸取养分让系统和个人都有对应的成长。

 

原文：https://weibo.com/p/1001603887407542962403