在线服务的黑天鹅

软件随想录（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 它确实是一种客观存在，给用户访问及体验带来了不便。我们不会通过回避问题来避免它的出现。当出现问题后，需要通过问题复盘的方式，帮助我们来重审事件的 经过，检查流程、机制、代码等共性层面的问题，避免在同一个地方再次踩坑。同时也可以反思团队在项目中的表现是否达到了平均以上的水平，是否存在一些低级 错误？

        在另外一方面，如果问题超出了之前的认知及应对策略的范围，属于黑天鹅式的问题，则没必要太多的自责。具有完美心态的工程师需要理性的看待各种批评及质疑，毕竟在一定程度，这是业界在共同应对的一个类型的难题，这些不稳定问题的出现也是在线服务的一部分。