可用性问题
着手确定错误的优先级可能会导致混乱，并经常导致团队冲突。 工程师需要接受的一点是，在确定优先级之前，不需要修复所有错误。 让我们从同样的问题开始：“我们是否需要解决用户遇到的所有错误？”。
可用性问题是长期存在的。 现实世界的不确定性将这些问题强加给我们，我们必须接受这些问题。 对于以自己的工作感到自豪的工程师来说，选择正确的问题是一项艰巨的任务。 以下是一些示例故障，这些故障是由我们无法估计或无法控制的行为引起的：
- 与特定交付供应商建立的集成失败。 选择此交付选项的大约2％的用户面临失败的交互。 作为企业，由于后勤和运营问题，已决定与供应商断绝关系。 这将导致这种集成变得过时。 它将从列表中删除，导致用户根本无法选择它。 鉴于集成仅将需要几个星期的时间，并且其他选项可供用户使用，现在是否值得修复？
- 有关访问者的数据表明，一部分用户正在使用Internet Explorer 9访问您的网站。 由于兼容性问题，它们面临一些错误，其中很大一部分是由所使用JavaScript引起的。 要解决该问题，将需要使用此客户端的访问者特定的网站版本。 投资回报是否合理？
- 一些可用性问题出现在将服务部署到的单个AWS可用性区域中。 减轻这种情况的一种选择是投资于多区域部署。 考虑到下一个问题很可能会在很长时间之后发生，因此迁移是否必要？ 是否值得付出相关的成本–时间，精力和金钱？
这绝不是各种可能性的详尽列表。 工程团队每天都要面对这样的困境，并在正确的权衡中做出决定。 由于工程资源有限，并且企业/产品所有者希望提供一长串竞争性新功能以改善业务，因此必须做出妥协。 接受所有系统将包含永远不会解决的可用性问题是迈向改进的一步。 对于某些错误，“将无法解决！” 是唯一合理的决定。
解决故障时，工程生命周期的下一个“阶段”是验证故障列表，按优先级排序，并选择以下三种结果之一：“立即修复”，“稍后修复”或“将修复”无法解决”。 让我们以一个假设的例子为基础建立这个理论。 假设这是从实际用户监控系统提供给我们的数据，该系统连接到生产中的Web应用程序：
失败清单 | 受影响的用户 |
失败A | 2 |
失败B | 12 |
失败C | 40 |
有了这些信息，很容易做出选择。 由于“故障C”影响了最多的用户，因此让我们对其进行修复，然后按影响的降序进行。 但是，此数据缺少做出知情决定要执行的顺序所需的一些关键组件。
减轻任何故障都需要工程师付出一定的努力，这意味着每次修复都要花费组织有限的精力，时间和金钱。 如果不将这些估计值制成表格，就无法得出关于优先级是什么的结论。 通过将该信息添加到表中，它现在进行如下修改：
失败清单 | 受影响的用户 | 减轻成本 | 修复效率 |
失败A | 2 | 1个 | 2 |
失败B | 12 | 8 | 1.5 |
失败C | 40 | 40 | 1个 |
现在，添加这些维度的数据可以显示减轻这些故障并查找修复程序的效率。 以下是列表信息的细分：
- 解决故障A可能会在一天内发生。
- 结果，每周两个用户不再遇到错误。
- 修复故障A的效率是，花了一个工程日就给了我们两个不再面临错误的用户。
- 对于故障C，需要八个完整的日历周工作。 结果将只给您一个不再在每个工程日上遇到错误的用户。
现在，这种分析提供了一个完全不同的视角，从该视角来看工程团队的优先事项。 每个团队都需要确定达到修复效率的最佳方法，然后继续进行改进。
我们已经看到故障是如何永久存在的，并且潜在故障的列表可能会越来越多。 团队如何知道何时停止修复故障？ 工程团队不仅承担着修复故障的责任，而且还承担建立新功能和添加产品的责任。 最好的平衡方法是计算对业务指标的影响并确定每个修复程序的ROI。
但是，即使这样可能也不太实用。 对于您将遇到的所有错误，可能无法到达这些数据点。 两条简单的规则将帮助您创建一个基础，以了解要解决的问题以及何时停止：
1.使用一种度量标准，该度量标准可为您提高效率，从而优先处理错误列表。
工程团队不应基于错误列表做出决定。 他们应该查看总体影响，以确保该服务目前以足够好的质量运行。 与企业达成协议，以在任何给定时间段内未发生错误的用户数量代表服务的预期质量。 根据这些基准进行故障缓解工作。
2.知道错误列表是头等大事，而从小努力中获得大收益。
每个现实世界中的错误清单都是重中之重。 我们的经验表明，对于大多数应用程序，影响最大的3个错误占总影响的很大一部分。 总是会出现错误的尾巴，仅影响少数用户，大多数错误可以安全地忽略。
翻译自: https://www.javacodegeeks.com/2019/02/prioritizing-availability-issues.html
可用性问题
