结论 - 可用性及其他:了解和提高分布式系统的弹性 AWS

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

结论

在本文中,我们确立了 12 条高可用性规则。

  • 规则 1 — 降低故障频率(提高 MTBF)、缩短故障检测时间(缩短 MTTD)和缩短修复时间(缩短 MTTR)是提高分布式系统可用性的三项因素。

  • 规则 2 — 工作负载中的软件可用性是决定工作负载总体可用性的一项重要因素,应与其他组件同等重视。

  • 规则 3 — 减少依赖项可以对可用性产生积极影响。

  • 规则 4 — 通常应该选择可用性目标等于或高于工作负载目标的依赖项。

  • 规则 5 — 使用备件以便提高工作负载中的依赖项的可用性。

  • 规则 6 — 备件的成本效益存在上限。利用最少的备件来实现所需的可用性。

  • 规则 7 — 不要在数据平面中的控制平面上设置依赖项,尤其是在恢复期间。

  • 规则 8 — 尽可能松散地耦合依赖项,让工作负载在依赖项受损时也能正常运行。

  • 规则 9 — 可观测性和检测对于缩短 MTTD 和 MTTR 至关重要。

  • 规则 10 — 侧重于缓解影响,而不是解决问题。以最快的速度恢复正常运行。

  • 规则 11 — 故障隔离可以降低总体故障率,从而缩小影响范围并延长工作负载的 MTBF。

  • 规则 12 — 让操作员可以轻松采取正确操作。

缩短 MTTD 和 MTTR 以及延长 MTBF 可以提高工作负载可用性。总结一下,我们探讨了涵盖技术、人员和流程的以下提高可用性的方法。

  • MTTD

    • 通过主动监控客户体验指标来缩短 MTTD。

    • 利用精细的运行状况检查实现快速故障转移。

  • MTTR

    • 监控影响范围和运行状况指标。

    • 按照 1/重启、2/重新引导、3/重新创建映像/重新部署、4/替换的顺序来缩短 MTTR。

    • 通过了解影响范围来绕过故障。

    • 使用重启时间更快的服务,例如虚拟机或物理主机上的容器和无服务器功能。

    • 尽可能自动回滚发生故障的部署。

    • 为诊断操作和重启程序建立运行手册和操作工具。

  • MTBF

    • 在软件发布到生产环境之前,通过严格的测试来消除软件中的错误和缺陷。

    • 实施混沌工程和故障注入。

    • 在依赖项中使用适量的备件来容许故障。

    • 通过故障容器最大限度地减少故障的影响范围。

    • 实施部署标准和变更标准。

    • 设计简单、直观、一致且有据可查的操作人员界面。

    • 针对卓越运营设定目标。

    • 当可用性是工作负载的关键维度时,优先考虑稳定性而不是新功能的发布。

    • 通过节流和/或卸除负载来实现使用配额,以避免过载。

记住自己永远无法完全成功地防止故障。专注于具有最佳故障隔离的软件设计,以便限制影响的范围和程度,理想情况下将影响保持在“停机”阈值以下,并采取非常快速、非常可靠的检测和缓解措施。现代分布式系统仍然需要将故障视为不可避免的,并且需要在各个层面上进行设计以实现高可用性。