保持你的应用程序正常运行对现代组织来说是至关重要的任务。遵循这些步骤来减少影响客户的停机风险。
2021年6月8日星期二，发生了一次大规模的互联网故障，导致大量网站和应用程序瘫痪。像许多这样的故障一样，这一次是由一个相对较小的网络播放器Fastly引起的。Fastly为互联网的主要部分提供云服务和本地缓存。当它发生故障时，整个互联网都感受到了影响。
随着你的应用程序规模的扩大，它也变得更加复杂。更大的规模和更多的复杂性意味着更高的问题风险，可能会影响可用性。
一家知名的监控公司在从小型公司发展到中型公司的过程中遭遇了严重的可用性问题。它的流量急剧增加，而它的基础设施却跟不上。更糟糕的是，它并不总是知道什么时候出现了问题，当然也不知道什么时候会出现问题。
你如何在你的应用程序中避免可用性问题？你如何在扩大规模时使你的应用程序成熟起来，从而满足你的客户不断增长的需求？
这并不容易。
提高可用性并不是要写出正确的代码。提高应用程序的可用性，更多的是改善你的组织的操作过程、程序和文化，以便灌输维持可用性所需的做法。
有五个步骤，所有公司都可以采取，以提高他们的应用程序的可用性，减少他们的操作问题的风险。
第一步：了解你的风险
许多人没有意识到他们的应用程序中蕴含着多少风险。这种风险大部分是以代码中的技术债务的形式存在的，但有些风险是基于已知的决定，这些决定是关于系统应该如何运行的，意味着结果是未知的。
前任美国国务卿唐纳德-拉姆斯菲尔德（Donald Rumsfeld）有句名言：有 "已知的已知"，也有 "已知的未知"，但需要关注的问题是 "未知的未知"--那些我们不知道的问题，我们不知道。
风险管理就是要消除未知因素，使其成为已知因素。在现代应用的情况下，风险管理是关于识别关注的领域，给它们贴上标签，对它们进行量化，并对它们进行优先排序。然后，解决对我们的业务有最大影响的风险。
为了做到这一点，你的应用程序中的每个服务的每个开发团队都应该创建和维护一个风险矩阵。风险矩阵是一个电子表格，包含了尽可能多的问题和潜在问题的清单。这是由与服务有利害关系的每个人进行的头脑风暴，以确定尽可能多的风险。然后，对于每一个风险，他们被分配两个数字：
- 严重性，说明如果这个风险发生，对我们的业务将是多么严重的问题。
- 可能性，具体说明这个风险发生的可能性有多大。
一个风险可以有很高的严重性，但可能性很低，这意味着它不可能发生，但如果它发生了，其影响将是巨大的。它可以有很高的可能性，但严重性较低，这意味着风险更有可能发生，但不会成为一个严重的问题。
最令人担忧的风险是那些具有高可能性和高严重性的风险。它们对我们的业务构成非常严重的问题，而且很可能发生。这些是影响最大的风险。
风险矩阵为每个团队提供了一个模型，以确定其业务工作量的优先次序，了解哪些工作是重要的，哪些是不重要的。正确和一致地做，它可以用来对各团队的风险进行优先排序，让管理层将资源分配给最大的问题。
风险矩阵使技术债务和悬而未决的问题具有可见性和优先性。它们是开发团队和管理层之间的一个伟大的沟通工具。
有效使用风险矩阵将有助于减少应用程序的可用性问题。
第二步：观察你的软件
了解你的软件和你的运营基础设施在任何时候都在做什么，对于保持高可用性至关重要。应用程序和基础设施的分析可以让你了解你的应用程序是如何执行的，让你调整和优化你的操作环境，检测和解决实时操作问题，并了解谁在使用你的软件以及他们是如何使用的。
如果使用和设置得当，分析可以对悬而未决的可用性问题提供早期指示，让你在应用程序或操作问题变成可用性问题之前就能解决它。
有许多免费和付费的系统和服务，提供应用程序和基础设施的指标和分析。所有这些都有优点和缺点。免费系统对于那些想要建立和维护自己的系统，甚至定制它们以适应他们的特殊需要的人来说是有价值的。付费系统可以提供更多不需要动手的体验，但往往需要大量的资金投入。更现代的付费系统甚至提供人工智能系统，为你分析你的应用程序的性能，给你提供问题的早期指标，而你甚至可能在现有的深度数据中没有注意到。
一个完整的系统来分析你的软件，可以提供以下能力：
- 持续监控你的系统，了解它的工作情况。
- 检查围绕部署的性能变化，看一个部署是否可能带来问题，或验证问题是否已经解决。
- 当检测到各种大小或形状的异常情况时，通过通知告知你，让你查看更深层次的数据，以确定可能出了什么问题。
- 协助你解决一个正在发生的事件，使用可以帮助理解为什么会发生特定问题的数据。
分析也是监测服务水平协议（SLA）的一个好方法。这包括公共SLA（那些对客户可见的）和内部SLA（那些描述内部服务之间的承诺）。分析是团队间沟通的一个重要工具。
第三步：减少你的技术债务
一旦你有了分析，并且通过风险矩阵和其他工具确定了你的技术债务和其他问题，你就需要评估和减少影响最大的问题。知道你的问题是什么很好，但如果你不努力减少这些问题，那就没有用。
如果你的矩阵上有一个高严重性、高可能性的风险，正在推动可用性问题，它必须被修复。但修复它并不一定意味着重写以消除风险。你可以通过降低风险的严重程度或可能性来解决可用性问题。
换句话说，如果你不能轻易地消除一个给你带来麻烦的问题，那么要么让这个问题不那么频繁地发生--这样它就不是一个频繁的关注源，要么通过降低严重程度来减少问题发生时的影响。无论哪种方式，最终的结果都是该问题不再是一个主要的驱动因素。它可能仍然是一个公认的风险，但频率的降低或影响的减少使得它不再是一个关键的问题。
定期关注技术债务有助于保持可用性。但要注意不要追求完美。你的目标不应该是消除所有的技术债务，从而消除所有的风险。除非你是在为飞机、火箭或类似的系统构建控制软件，否则你需要平衡努力和问题的影响。过分关注减少技术债务，可能表明你花了太多的时间专注于 "完善 "软件，而牺牲了其他一些商业机会。
第四步：尽可能实现恢复的自动化
当事件发生时，恢复所需的时间会对你的整体应用可用性产生巨大影响。快速恢复是很重要的。同样重要的是正确诊断问题，并采取措施确保它不会再次发生。
当可用性事件发生时，应对措施一般包括以下步骤：
- 你注意到问题正在发生（要么你发现了问题，要么客户报告了问题）。
- 分析导致问题的原因。
- 你推出一个补救措施，以减少或消除问题。
- 如果有必要，你要实施一个永久性的修复措施。
- 对这一事件进行验尸。
每次有事件发生时，都会发生同样的事件序列。问题是这个过程需要时间。从问题发生时，或第一次注意到它时，到补救措施到位以消除问题的时间，称为平均修复时间（MTTR）。你的MTTR越长，你的可用性就越低。由于人类参与诊断和修复问题，你的MTTR可能相当长，影响客户满意度。
然而，有时你会意识到某些类型的问题可能发生，而且修复问题的过程可以是安静的、自动化的。通过自动修复这些类型的问题，你可以极大地提高你的MTTR。
一个可自动修复的典型例子是当一个计算机实例离线时。这可能是由于软件问题、网络问题或其他原因而发生的。但监控软件可以检测到实例停止响应的时间，并且实例可以立即被重新启动。或者，在云中，该实例可以被终止，并被一个新的实例取代。这可以自动发生。因为不需要人的参与，你对这类问题的MTTR可以减少，这可以明显提高你的可用性。
第5步：定期尝试和破坏
保持你的应用程序运行的最好方法是定期尝试并破坏它。
是的，这是对的。你没有听错。
世界上最大的应用程序的运营商经常通过定期尝试破坏他们的应用程序来测试他们对问题的适应性。
这个想法是这样的。你的软件会失败。但你想让它在半夜或在操作上的关键时刻失败吗？还是你希望它在一个更合适的时间发生故障，而你的工程师在一旁看着，准备更快地发现和修复问题？
无论哪种情况，你都能获得关于你的应用程序如何运行的宝贵经验。在第一种情况下，当你试图找出应用程序的问题时，你会给你的客户提供一个糟糕的体验和潜在的长期损害。在第二种情况下，你知道是什么原因造成的问题（是你造成的），你可以迅速修复它。你的教训是一样的，但教训的成本要小得多。
有两种常见的方法来完成这种生产操作测试。第一种被称为游戏日。游戏日是在预定的时间内，将特定的故障注入你的运营基础设施，以观察问题的表现，以及你能多快地发现和解决问题。例如，一个常见的游戏日测试场景是使整个数据中心瘫痪，看看你的应用程序是否可以故障转移到一个备份数据中心。
第二种常见的生产运行测试方法被称为混乱测试。混沌测试涉及到让一个软件系统运行，随机地和不可预测地，定期地破坏你的系统的一部分。这可能涉及到服务器崩溃，打破网络链接，或使负载平衡器离线。混沌测试是测试自动恢复机制和证明你的恢复过程的安全性和有效性的好方法。
无论哪种情况，目标都是以可控的方式发现问题，从错误中学习，并提高你的应用程序的质量，以便能够从这些故障中自我修复。这两种方法的双重目标是提高你的操作可靠性和提高你的应用可用性。
改善流程，提高可用性
提高应用程序的可用性不是为了追求完美或消除所有的风险。它更多的是关于改善你的操作流程：努力减少问题的严重性和可能性，密切监控应用程序和基础设施，保持技术债务的控制，自动恢复机制，并定期对这些恢复机制进行测试。遵循这些步骤，你的应用程序的可用性将得到明显的改善，你的客户将更加高兴，而这些更加高兴的客户将意味着你的公司有更多的业务。
