分布式之基石: 可靠性——What a tangled web we weave

总结阅读DDIA和凤凰架构的感想和笔记。

可靠性

Oh what a tangled web we weave,
When first we practice to deceive.
——Walter Scott

每当我们在日常讨论起软件系统的可靠性时，总是用模糊的定义或是一种高度理想化的期望来描述它：

• 在给定规模的输入，软件正常工作且在预期时间内输出。
• 在错误或不规范使用的场景下，软件仍能按用户期望输出。
• 有效限制恶意访问。

开发和测试保障可靠性

在敏捷开发“轻文档，重沟通”的系统中，我们常常将系统的有效工作负载、在什么场景下应当有怎样的输出以用户故事的方式提出，往往规定的是正常流程，但对于错误、不规范的输入则较少以文档约束，其他开发模式中实际也很少用非常详实的文档约束什么是错误和不规范(或许有，但笔者未接触过)。

为此在工作中，我们建立了代码评审、结对编程和测试等流程，以隐含的、在开发者之间流传的编程规约，以及测试工程师以三方视角来检验可靠性，这被事实证明可以有效地保障系统的局部可靠性。但经验也是用试错换来的，每一条编程规约的背后，都是无数程序员血泪的教训。

只要是经验，在软件开发过程中，研发总会疏忽，代码总会有缺陷，我们必须正视人为错误的发生，逢山开路，遇水架桥。在开发测试层面，提升可靠性常用的手段有：

• 文档评审：产品经理在完成需求文档PRD的编写后，和研发以及测试工程师讲解需求背景、业务目标和业务效果。研发工程师在完成技术方案后，和其他研发以及测试工程师采取合适机制评审，探讨技术细节。
• 选择合适的开发模型，瀑布式开发、敏捷开发、XP等，他们各自有各自的方法论，比如敏捷开发可以考虑采取测试驱动开发(TDD)，XP中的结对编程。
• 单元测试、代码评审等，避免编程错误和常见的开发经验错误，保障代码质量最基本的手段。
• 联调测试：重点测试各模块各组件的接口，确认接口正确对接，业务功能符合设计。
• 系统测试：完成整体端到端的业务逻辑的测试，确保在给定规模下，系统能够正常工作，且非功能指标达到要求。
• 验收测试：由产品、客户等确认系统的完备性，以及符合其业务预期。
• 回归测试：在持续交付上，系统的演进需要通过回归测试确保变更外的功能也能够正确工作。
• 自动化测试、非功能测试等等常见测试手段与流程。

硬件的可靠性

在整个软件生命周期中，我们提到了开发和测试，他们通过经验和规约在一定程度保障可靠性。当软件投产工作时，硬件损坏、接错网线、断电等也是不可忽略的问题。

除了人为导致的故障，硬件也有可能出现故障，服务器的各个元件在工作中收到物理环境的影响，会导致数据出现错误、损坏，硬件设计者们为此加入了纠错码来发现或纠正数据的正确性，但纠错码能够纠错的位数是有限的，纠错码甚至自身都有可能因为物理环境的影响而错误；硬件存在使用寿命，元件老化导致不正确的工作，出现错误的运算或是无法工作。这些都是小概率事件，为减少这些问题出现的概率，数据中心和机房每一条管理条例的背后都是无数运维血泪的教训。

我们常用失效率、平均失效间隔(MTBF)、平均无故障时间(MTTF)和平均修复时间(MTTR)来描述硬件的可靠性。

平均失效率：
$$\lambda =\frac{N_f}{\Delta t\cdot N}$$