支付宝故障事件引发了大量的关注和讨论。事情基本过程是因为电信运营商光纤被挖断，导致支付宝服务故障，2小时左右后服务恢复正常。本人曾有幸做过一些关于系统可靠性方面的工作，想借此次事件抱着抛砖引玉的态度，班门弄斧地谈一下系统的可靠性和对YunOS可靠性的一些想法。

 

系统可靠性是个什么东东？

Availability & MTBF, MTTR, MTTF

系统可靠性对于Availability, 经典定义是：

  

 

• MTBF: meantime between failures, 即平均故障间隔，就是从新的产品在规定的工作环境条件下开始工作到出现第一个故障的时间的平均值。MTBF越长表示可靠性越高正确工作能力越强 。通常MTBF关注点在硬件，但是对于整个系统的Availability来说，软件因素也是必须要考虑的。
• MTTR: meantime to repair，即平均恢复时间。就是从出现故障到恢复中间的这段时间。MTTR越短表示易恢复性越好。
• MTTF: meantime to failure，即平均失效时间。系统平均能够正常运行多长时间，才发生一次故障。系统的可靠性越高，平均无故障时间越长。(MTBF = MTTF + MTTR)

 

由于上面的经典公式比较泛化，业界除了军事和航天外都没有明确的计算标准，所以计算Availability通常会采用下面的公式： 即服务总时间减去历次服务中断的时间除以服务总时间。

 

 

 

服务中断 (Outage)

上面公式引入的Outage的 概念，一般翻译为服务中断。按照产生原因可以分为3类, 通常在系统设计中只关注第1类即产品因素导致的outage:

• 由产品因素导致 – 包括: 系统设计, 硬件, 软件, 系统组件缺陷; 系统设计中包括的必要的计划内的服务中断; 由于执行例行维护导致的
• 客户因素导致 – 主要包括：流程问题或错误; 服务环境因素：电源，地线，温度，湿度，安全问题等
• 外部因素导致 –包括：自然灾难，如飓风，洪水，地震等; 由与客户无关的第三方因素，如挖掘机

 

TL9000 标准中定义了2类Outage类型：

• 服务完全中断 （Total Outage）: 系统内的所有主要功能无法工作
• 服务部分中断 （Partial Outage）: 系统的服务能力下降一定比例（如20%），或系统内部分组件或功能无法工作

其中：

• “主要功能”的定义在不同用户会稍有不同
• 服务部分中断的比例是可以分摊和等价计算的，如10分钟内失去50% 服务能力可以等价于5分钟内失去100%服务能力
• 少量的服务能力中断可以不算做outage, 如 <10%的系统服务能力
• 短时间内的服务能力中断可以不算做outage, 如，<15秒的服务中断可以不计算在5个9可靠性中的outage, 但如果要求高于5个9的可靠性，可不计算的中断时间标准就需要缩短。

 

5个9， DPM 和 Failover Recovery Time

经常会听到有产品介绍自己的可靠性时会说达到了几个9，那么具体是什么概念呢？

 

平均计算一年的时间，包括闰年有365.25天，即525960分钟  (365.25 * 24 * 60)

从表格中可以看出，5个9对应着一年中的服务downtime 要求 <= 5.26分钟；3个9对应着一年中的服务downtime 要求 <= 525.96分钟，大约为不到9个小时

 

除了几个9的要求，还有DPM （Defect per million request or task）, 即在1百万请求或者操作当中，处理失败的数量，一般DPM 与 几个9的对应关系大致为：

• 1 DPM 对应99.9999% availability, 即6个9
• 10 DPM对应99.999% availability, 即5个9
• 1000 DPM对应99.9% availability, 即3个9

 

此外，系统运行出现错误要求能够及时探测，并且在规定时间内完成服务切换，如上文中提到的，5个9要求自动切换时间<15秒。这里涉及的内容较多，同时与本人目前从事YunOS工作关联不是特别紧密，就不展开详述了，如：

• 高可靠性可用性与弹性扩展 (High Availability & Scalability & Elasticity)
• 容错与灾难恢复(Fault Tolerance & Disaster Recovery)
• 备份与恢复 (Backup & Restore)
• 负载均衡 (Load Balancing)
• 内容分发 (Content Distribution)

 

 

支付宝服务在这次事件中表现出的系统可用性如何？

没有特别关注这个事件的具体细节，只是有个了解，从公开途径得知的大致情况是：

• 有小部分业务通过异地多活 （Geo-Redundancy and Multi-active）的容灾策略做到了实时业务切换
• 不支持多活业务的部分用了2个小时左右完成了业务切换, 这2个小时造成了部分服务的outage。

 

从上文的分析可以得知，这次支付宝服务中断属于由外部因素导致的Partial Outage；好像也没听说之前还出过其他Outage, 就假定没有了；如果本年内不再有其他计划外的Outage，则本年内支付宝服务的Availability 和 Reliability可以达到99.9% - 99.99%, 介于3个9 与 4个9之间，非常接近4个9。 应该处于互联网服务高端位置，但是还没有达到其他有更高要求领域的标准，如电信领域的运营商客户普遍要求5个9，99.999%的可用性。

 

从中可以看到由于异地多活的容灾策略，让小部分业务可以完成短时切换，完全满足了High Availability 和 Reliability的要求。

 

但是作者也大胆推测异地多活目前可能还是试用阶段，大部分受影响的其他业务很可能还不支持异地多活。如果支持的是Active-Standby模式，备份服务在服务中断事件发生时是否立即启用自动代替主服务，即备份服务的Failover Recovery策略是否及时生效，同时异地容错(Geo-Redundancy)是否支持, 这些从公开的信息中都没有提及，不过从出现2个小时的Partial Outage的结果来看还是有不少地方可以改进的。

 

Geo-Redundancy & Multi-Active, Active-Active, Active-Standby, N+K

上面提到了异地多活，这里还想在对Geo-Redundancy 和 Fault Tolerance & Disaster Recovery再多说几句。容灾策略可以分为：

• 无容错 (No FT or DR)：系统不考虑Error Detection和 Failover Recovery，出了问题只能重启或者干脆无法服务

• 主从备份(Active-StandBy): 正常情况下只有主服务工作，备份服务不工作，在主服务出现故障时，备份服务可以立即启用，通常是1+1 的方式，这种策略备份服务在很多时候可能都是冗余，但又是必须，所以资源使用率不高。

• 双活(Active-Active): 系统有2个服务集群，这2个集群同时提供服务，可以根据不同策略将服务转发到其中1个集群。当其中一个集群中全部或者部分节点/组件服务中断时，另一个集群可以立刻接管。这种策略资源使用率比Active-Standby高，但对系统架构与设计的要求也高，如需要支持数据实时备份与同步。同时如果由于设计不当，可能会导致在Failover 后系统的服务能力下降，具体请看下面的N+K部分。

• 异地双活(Active-Active with Geo-Redundancy): 和双活类似，区别在2个服务集群部署在不同的地理位置，中间通过高速网络连接。这种策略优势明显：可以抵抗单一地区的突发事故，包括自然灾害，但是需要有跨长距离的高速网络连接，成本提高。

• 多活和异地多活(Multi-Active with Geo-Redundancy): 类似的，同时提供多个服务集群即为多活，如果多个服务集群分别部署在异地即为异地多活。这种策略比异地双活的优势是可以抵抗多地的同时突发事故。架构设计复杂度也很高，需要考虑多地间的备份和同步。据说只有Google和Facebook实现了，还有目前处于试用阶段的支付宝。

 

• N+K: 与上面不同，N+K是指系统可用性的一种能力而不是指部署策略，即包含N个服务器Node的系统在其中K个Node失效的情况下还能够提供N个Node的服务能力。比如上面提到的1+1 Active-Active, 如果经过适当设计调整就可以实现N=1, K=1的能力。

 

具体来讲，比如在系统架构设计时可以分别部署N/2个 Node在两地,即1+1 Active with Geo-Redundancy，让每个地区的Engineered Capacity为系统最大能力的40%，而满足整体业务能力要求可以通过增加系统资源实现。这样在一个地区内所有Node都完全失效的情况下，另一个地区即使完全接管失效节点所有服务，负载也只达到了系统Capacity的80%而没有Overload。此时即实现了N+K 中的1+1。

 

再例如：系统升级时，在支持N+K的系统中可以同时先关闭并升级最多K个Node, 而对外的服务能力没有任何降低，整个服务也没有downtime, 不需要Scheduled Outage 维护窗口.

 

下面2张系统架构图是本人曾经参与设计过的2个系统架构的例子,一个是传统模式，另一个是Cloud模式。贴出参考就不做过多分析了。

 

Legacy Mode： Geo-Diverse Active-Active with N+K 

 

 

Cloud Mode： Geo-Diverse Active-Active with Auto-Scaling in Amazon AWS

 

 

YunOS的系统可靠性

YunOS, 是阿里巴巴集团旗下的一款智能设备操作系统产品，融合了阿里巴巴在云数据存储、云计算服务以及智能设备操作系统等多领域的技术成果，并且可搭载于智能手机、智能机顶盒（DVB/IPTV/OTT）、互联网电视等多种智能终端设备.

YunOS在应用层架构上大致可分为2部分：

• 云端服务
• 客户端应用

云端服务属于典型的互联网服务，对这部分暂时不详细展开了，本文上面介绍的概念和方法都可以适用。想重点讨论的是客户端应用这部分，目的是希望从本文上面的分析中得到有助于提高客户端可靠性的方法或者是测试策略。

 

MTBF测试

目前，终端侧的可靠性测试基本上是采用称为”MTBF测试”的专有测试活动来进行的。

 

中国移动2015版的MTBF测试的标准是：每轮测试5台终端并行连续循环执行以下用例7X24小时，期间记录系统级问题，包括死机、重启、白屏、脱 网等严重问题。最终计算终端的无故障运行时间

 

T：T = 5X7X24 /（故障数）

 

如果终端支持稳定性测试中对应的本地及通信类业务，则要求终端对于支持的业务满足稳定性测试中，在 TD-SCDMA、TD-LTE 网络下平均无故障运行时长指标不低于 250 小时。零售价 2500 元以上不低 于 350 小时。

 

北美电信运营商AT&T的MTBF指标是这样定义的：7台手机每天24小时不间断运行AT&T规定的测试，测试内容包括2G/3G语音呼叫、短彩信、浏览器上网、电话本操作。测试过程中出现的测试用例失败情况都会记录下来，然后用7台手机总的运行时间除以全部手机出现的测试失败次数，即得到MTBF值。整个测试过程全部采用自动化方式，并且都在AT&T的现网环境下进行，该测试已经成为所有与AT&T合作的终端厂商都必须通过的测试，而且是所有厂商公认的最难通过的测试。

 

YunOS的MTBF测试是由YunOS系统测试团队执行的，同时制定了更为严格的通过标准。

 

MTBF测试与系统可靠性

可以看出，MTBF测试标准的定义与上文介绍的System Availability的概念不是完全一致，因为移动终端毕竟与服务端从架构，实现方法，到用户群体都不尽相同；严格来讲MTBF测试是终端可靠性测试其中的稳定性测试部分。然而有不少地方是两者是相通和可以借鉴的。比如：

 

• MTBF中的故障数可以近似理解为Outage，系统重启属于Total Outage, 模块Crash属于Partial Outage
• 提升可靠性都是需要降低故障数减小downtime
• 在系统和应用设计中都需考虑如何减少错误，或者出现错误如何恢复。
• 终端上的一些后台服务可以近似理解为服务端应用，虽然不能完全照搬上文中提到容灾和恢复的场景，但是可以借鉴其中的一些思路。
• 终端上可以通过参考DPM的概念增加数据衡量指标，但可能不需要也不现实每个场景都执行100万次操作，可以依据实际情况调整标准要求
• 可以参考Failover策略中错误探测，隔离，恢复的操作在出现错误时及时发现，快速恢复重新启动来减少对用户造成的负面影响，恢复时间即Failover Recovery Time就成了一个关键指标

 

系统可靠性设计，建模与测试

这个Topic太大了，不在这里详述了，有一点想要强调的是，任何系统的可靠性，健壮性都不是依靠测试来提高的，测试只能起到结果验证和数据反馈的作用；相反，可靠性是系统架构和设计的关键组成部分。

 

具体讲就是要在设计阶段对采用的模型，样式，架构等有清晰的需求，同时要详细计算系统中每个组件可能失效的场景和几率，以及由此引发的可能Outage带来的downtime，计算出产品目前距离达到可靠性标准的差距。然后通过合理的技术手段改进设计，改进的部分要作为产品的Feature 写入需求文档，实现后最终通过测试和产品环境上的历史数据来验证。

 

例如：下面是Downtime Budget图表示例，Downtime Budget是系统可靠性设计过程中的一个环节，通过分配系统各个组件可能的Downtime 比例来找到最需要改进提高的地方。

 

 

总结

从整篇文章的分析逻辑中可以看出，系统的可靠性，包括产品的整体质量都不能仅仅依靠测试环节来保证。任何希望通过测试发现问题，修复Bug解决问题来提高产品质量的想法都是不切实际的，因为在产品设计之初，质量就被隐含其中了。

 

最后，分享一些和质量相关的观点和理念来作为此文的结尾：

 

关于测试：

• 测试是无法穷尽和发现所有错误的
• 测试的目的不是为了证实软件的正确性，可是要尽可能的发现错误

 

关于需求：

• 软件生命周期中缺陷数量占比：需求和架构54%， 设计25%，编码15%，其他6%
• 需求是一个项目的灵魂。模棱两可的需求带来不可避免的后果就是返工。
• 高质量的软件产品要求足够详细的需求规格说明，然而很多组织没有能力或者不愿意制作详细的需求规格说明

 

关于产品质量：

• 质量不能够通过评鉴一个已完成的产品而得到，因为在设计之初质量就被隐含了
• 流程与成功不是等价的，没有流程成功就不可能保证，但有了流程不意味着一定能成功
• 从长远发展看，提高产品质量应该从规范软件开发流程做起，这是一个软件企业从小作坊到集成规范化大公司的必经之路，也是从根本上解决质量问题的一个关键手段