在线服务的黑天鹅

软件随想录（More Joel on Software）有这样一段话

提高服务稳定性的最大困难，就是”黑天鹅难题”（problem of black swans）。这个名词是由Nassim Taleb提出来的（www.edge.org/3rd_culture/taleb04/taleb_indexx.html），他这样定义：”黑天鹅代表外来因素，是一个超出正常预料的事件。”几乎所有的互联网服务中断，都来自于意料之外的突发事件，属于极其小概率的非主流意外。这类事件是如此罕见，以至于常规的统计方法—-比如”故障间隔平均时间”—-都失效了。”请问新奥尔良市发生特大洪水的平均间隔时间是多少？”

Tim这两天也是刚忙完InfoQ的ArchSummit的演讲，正在利用周日休息一下，但是一醒来就收到消息说某服务有些问题。于是赶紧连线了一堆正在处理事件的工程师，等拿到初步的原因分析之后，已经4小时之后了。

“墨菲定律”，一位工程师说，“周五觉得这个地方有些隐患，已经有一段时间了，打算下一周来处理，未料它今天就出了问题”。墨菲定律是指“凡是可能出错的事必定会出错”，指的是任何一个事件，只要具有大于零的机率，就不能够假设它不会发生。因此在线服务发生问题之后，总有工程师随即证明墨菲定律的魔力。

不过我觉得用黑天鹅难题更能体现在线服务可用性的不可控，可用性是指一个系统中提供服务与设计时间的比例，通常用百分比来表示。在线服务通常看到最多的是以下3种

• 99.9%，服务中断时间：525.6分钟/年
• 99.99%，服务中断时间：52.56分钟/年
• 99.999%，服务中断时间：5.256分钟/年

当一个系统有大量用户使用之后，通常不能接受系统不可用，因此互联网服务通常会把可用性目标定在99.99%及以上，但是极少能达到99.999%的。Tim有一个服务由于功能简单且稳定，基本不需要变更代码，且有容错的设计，服务池没有单点问题，所以觉得2014年可以达成99.999%了。谁料最近这个服务池被一个极偶然的脚本全部干掉了。尽管运维工程师马上进行了处理，但是最后也较难满足1年低于5分钟中断的期望。虽然这个是个偶然的案例，但是它却是典型的黑天鹅事件。

对于系统服务可用性的问题，在专业领域其实有3个词汇去描述的。描述的顺序通常是 fault -> error -> failure。这方面大多定义引用来自《Patterns for Fault Tolerant Software》一书，在书中描述如下。

用一个通俗的例子来描述三者的定义是，如果把fault比作是数据库网线断了，则error是网络不通连不上数据库，导致的failure是不能注册用户。由于error及failure是不可避免的，所以在代码设计上更多的是做容错（fault-tolerance）。

我们可以通过服务之间进行良好的容错设计，进一步用代码review，关键路径的梳理来确保容错策略的落实。上线的checklist来确保变更出现异常时候的应对。即便如此，容错只能帮助我们规避大部分已知的问题，随着系统长时间运行，总是有意外情况出现，曾经有同事碰到关键的服务中出现内存出错这种小概率事件，查出来之后，当事的工程师的肯定为了怎么写好问题总结那一段话在绞尽脑汁。

当团队规模比较小的时候，服务本身可控性还是比较强，关键路径中的每一段代码团队成员非常熟悉。当出现异常问题，团队成员也可以快速想到各种处理方法来快速解决。但是当系统变大，每个团队只参与其中大系统一个单元时，问题会变得更复杂。从概率的角度，大的系统中小的模块的failure不可避免，容错流程的规则总是会存在疏忽的地方，系统中存在复杂的网状调用，无法完全做到松耦合（理想的松耦合是指一个服务的失败不会引起另外一个依赖服务的失败），因此可能一个缺乏经验工程师的一行不经意的代码会造成不可控的后果。

大型系统不可预知问题的排查通常需要更多时间，需要多个团队共同参与来定位及解决问题。但在线服务由于可用性的要求，出了问题之后，处理问题的紧急程度会比分析问题更高，因此并不会第一时间来讨论及分析问题，工程师需要凭有限的现象迅速做出判断，将问题消灭在萌芽阶段。但正是不能判断真实的原因，问题延续的时间比预期的要久也成为常见的现象。

对于公司来说，肯定希望所有的服务都有99.999%的可用性；但由于黑天鹅的现象，理想的可用性较难达到，这也很容易成为工程师的心理负担。当稳定性出现问题后，相关的技术团队心理上不会比一个战败的队伍感觉强，甚至一些工程师还会造成心理上的压力。夜深人静时候电话突然响起，第一反应通常会是“莫非是服务出问题了？”。

工程师应该用什么样的心态去看待出现的问题？

一方面，问题failure它确实是一种客观存在，给用户访问及体验带来了不便。当出现问题后，还可以通过问题复盘的方式，帮助我们来重审事情的经过，来检查流程、机制、代码等共性层面的问题，避免在一个地方再次踩坑。团队在项目中的表现是否达到了平均以上的水平？

在另外一方面，如果问题超出了之前的认知范围，或者是黑天鹅式的问题，也没必要太多的自责，理性的看待批评及质疑，毕竟在一定程度，这些问题的出现也是在线服务的一部分。

Similar Posts:

• 应用层的容错与分层设计
• Feed消息队列架构分析
• 微观架构及宏观架构
• 分布式缓存的一起问题
• 有故障，毋宁死