故障是不可避免的，衡量运维同学的关键指标是系统可用性，这个指标就是通过故障时间来计算出来的，也就是每一年没有故障的时间除以总时间得出的比例就是系统可用性，我们常说的系统高可用达到4个9，就是指系统可用时间99.99%，这里代表的就是一年里有52分钟是故障时间。
当然，故障也有不同的等级，我在阿里巴巴的时候，我们规定有事故级、A级、B级、C级等，事故级就是整个系统不可用，类似系统宕机等等，A级是主要业务逻辑影响大部分用户使用，B级是主要业务逻辑影响小部分用户使用或者非主要业务逻辑影响大部分用户使用，C级是非主要业务影响小部分用户使用。根据不同级别的故障及时间会算出最终一个可用性指标，作为运维同学的KPI关键指标。
每年阿里巴巴都会有很多的故障发生，让我印象最深刻的一次故障，从级别上来说是C级，但这个故障对我影响非常大，我来好好回忆下这次故障的发现及处理全过程。
故障现象
国际站的业务指标是新增注册用户数，这个关键指标在一贯的数据表现都是缓慢增长的。当时我们的应用监控系统已经上线了，也就是通过我们的系统可以随时查看各种业务指标，相比业务部门的统计数据还要快，因为我们是直接从应用内部抓取数据进行统计分析的。在对这个关键业务指标的监控图上发现，最近两周的整体趋势跟之前不太一样，之前一直是缓慢上升的趋势，而最近两周有缓慢下降的趋势，这是个细微的差别，但毕竟还是有差别，然后系统就报警了，认为这是一个故障。
焦虑的查找过程
我们收到这个故障后开始着手调查，常规的方法检查系统的各个接口访问是否正常、查询日志是否正常等等，查了好长时间都没有发现任何问题。基本上是把能查的都查过了，那就只能是某些第三方系统出问题的，我们把所有用户注册相关的第三方系统列出来，涉及到有十几个独立应用，分别找到对应的应用负责人要求帮忙核查，经过一段时间统计和监控数据的探查，也没发现问题。
那段时间很是焦虑啊，我们就又把最近那些系统做过发布也列出来，发现两周之内有6个系统有过发布记录，然后跟着这些系统一个一个排查过去，在我们就要绝望的时候，终于找到了问题的真正原因——验证码系统在发布的时候漏掉了一台服务器。
故障原因详述
我来详细解释一下这个问题，该验证码系统是一个独立的系统，而且有高P同学写的，代码质量有点高，而且在高压力的情况下会自动拒绝客户请求，等待下一次请求再响应，这样做的好处是系统稳定性高。在两周前因为日志收集的相关功能做了一次线上发布。该系统是由两台服务器来提供服务的，可以承受住日常访问量2-3倍的流量，常规发布过程是先将一台服务器从线上拿下来（一般做法是从负载均衡中取消即可），将应用程序更新为最新的版本，然后加入到线上提供服务，而这次发布过程由于负责发布的运维同学在最后一个步骤的时候敲错了一个指令，导致该服务器在更新完程序后并没有加到负载均衡后面，也就是说日常由两台服务器提供服务的变成了由一台服务器来提供服务，相应的服务能力就减半了，在常规情况下验证码响应也是没问题的，只有在高峰期会导致部分用户获取不到验证码，而由于系统程序实现得很好，系统并不会崩溃，从而隐藏了问题的暴露。那么在新用户注册的时候，由于有部分请求拿不到验证码，有些用户就在注册过程中就卡住了、放弃了，因此导致了前面的那个故障，新增注册用户数呈缓慢下降的趋势。
通过这个故障，让我深刻意识到几点：
1、人是最不可靠的，虽然每天都在做的事情，但还是会出现遗漏、出错等；
2、核查清单是必要的（查理芒格的普世智慧之一），靠人脑记忆是靠不住的，只有通过严格的核查清单，才可以减少出错的可能性；
3、任何一个可能出问题的地方，最终总是会出问题。
