缩短 MTTR
发现故障后，剩余的 MTTR 时间就是实际修复故障或减轻影响所用的时间。要修复或缓解故障，您必须知道发生了什么问题。在这一阶段，有两组关键指标可以提供见解：1/影响评估指标和 2/运营状况指标。第一组指标可以告诉您故障的影响范围，并衡量受影响的客户、资源或工作负载的数量或百分比。第二组指标有助于确定产生影响的原因。发现原因后，操作人员和自动化机制可以响应和消除故障。有关这些指标的更多信息，请参阅附录 1 — MTTD 和 MTTR 关键指标。
规则 9
可观测性和检测对于缩短 MTTD 和 MTTR 至关重要。
绕过故障
减轻影响的最快方法是使用能够绕过故障的快速失效子系统。这种方法使用冗余，通过将故障子系统的工作快速转移到备用子系统来缩短 MTTR。软件进程、EC2 实例、可用区和区域都可以配备冗余。
备用子系统可以将 MTTR 缩短到几乎为零。恢复时间仅仅是将工作重定向到备件所花费的时间。这一过程的延迟往往极低，并且工作仍然能按照既定 SLA 完成，从而保持系统的可用性。所以 MTTR 只会出现轻微甚至可能难以察觉的延长，而不会造成长时间的不可用。
例如，如果您的服务使用应用程序负载均衡器 (ALB) 后面的 EC2 实例，则您可以将运行状况检查的时间间隔配置为五秒，如果检测到两次故障，就将目标标记为运行状况不佳。这意味着您可以在 10 秒钟内检测到故障，并停止向运行状况不佳的主机发送流量。在这种情况下，MTTR 实际上与 MTTD 相同，因为故障只要被检测到就会得到缓解。
这就是高可用性或持续可用性工作负载想要实现的目标。我们希望快速检测到发生故障的子系统，将其标记为故障，停止向其发送流量，然后将流量发送到冗余子系统，从而快速绕过工作负载中的故障。
请注意，使用这种快速失效机制会让您的工作负载对瞬时错误非常敏感。在上面的示例中，我们应该确保负载均衡器运行状况检查仅对实例执行浅层或活性和本地
可观测性和检测子系统故障的能力对于成功绕过故障至关重要。您必须知道影响范围，这样才能将受影响的资源标记为运行状况不佳或出现故障，然后停止服务，将其绕过。例如，如果单个可用区出现部分服务受损，则您的检测工具需要能够识别出存在可用区范围内的问题，以便绕过该可用区内的所有资源，直到其恢复为止。
绕过故障可能还需要额外的工具，具体取决于环境。在上文使用 EC2 实例和 ALB 的示例中，假设一个可用区中的实例正在接受本地运行状况检查，但是一个孤立的可用区损伤导致它们无法连接到其他可用区中的数据库。在这种情况下，负载均衡运行状况检查不会让这些实例停止服务。这就需要一种不同的自动化机制来从负载均衡器中移除可用区或让实例无法通过运行状况检查，而这又需要确定影响范围是否为可用区。对于未使用负载均衡器的工作负载，需要使用类似的方法来防止特定可用区中的资源接受工作单元或完全移除可用区的容量。
在某些情况下，我们无法将工作自动转移到冗余子系统，例如在没有主节点选择机制的情况下将主数据库故障转移到辅助数据库。这是 AWS多区域架构
能够采用不太严格的一致性模型的工作负载可以通过自动多区域故障转移来绕过故障，从而缩短 MTTR。Amazon S3 跨区域复制或 Amazon DynamoDB 全局表
我们可以通过两种不同的策略来绕过故障。第一种策略是预先配置足够的资源来处理故障子系统的全部负载，从而实现静态稳定性。资源可以是单个 EC2 实例，也可以是整个可用区的容量。在故障期间尝试配置新资源会延长 MTTR，并在恢复路径中向控制平面添加依赖项。但是，预先配置资源需要额外付费。
第二种策略是将部分流量从出现故障的子系统路由到其他子系统，并卸除
恢复到已知良好状态
修复期间的另一种常见缓解措施是将工作负载恢复到先前的已知良好状态。如果导致故障的可能是近期发生的更改，则我们可以回滚该更改以便恢复到先前状态。
如果导致故障的可能是瞬时情况，那么重新启动工作负载可能会减轻影响。我们来分析一下这两种场景。
在部署过程中，尽可能缩短 MTTD 和 MTTR 依赖于可观察性和自动化功能。您的部署过程必须持续监视工作负载，以防出现错误率增加、延迟增加或异常情况。发现这些问题后，部署过程应该暂停。
我们可以采用多种部署策略，例如就地部署、蓝绿部署和滚动部署。每种策略都可以利用不同的机制来恢复到已知良好状态。系统可以自动回滚到先前状态、将流量转移回蓝色环境，或者要求手动干预。
CloudFormation 的创建和更新堆栈操作提供自动回滚功能，AWS CodeDeploy 也提供这一功能。CodeDeploy 还支持蓝绿部署和滚动部署。
要利用这些功能并尽可能缩短 MTTR，请考虑通过这些服务来自动部署所有基础设施和代码。如果无法使用这些服务，您可以考虑使用 AWS Step Functions 实施 saga 模式来回滚发生故障的部署。
在考虑重启时，我们有很多不同的方法。我们可以重启服务器（用时最长），也可以重新启动线程（用时最短）。下表列出了一些重启方法和完成的大致时间（体现数量级差异，数字并不准确）。
| 故障恢复机制 | 预估 MTTR |
|---|---|
| 启动和配置新虚拟服务器 | 15 分钟 |
| 重新部署软件 | 10 分钟 |
| 重启服务器 | 5 分钟 |
| 重启或启动容器 | 2 秒 |
| 调用新无服务器函数 | 100 毫秒 |
| 重启进程 | 10 毫秒 |
| 重启线程 | 10 微秒 |
从表中可以看到，使用容器和无服务器功能（例如 AWS Lambda
作为一般的恢复方法，您可以从下到上做出选择：1/重启、2/重新引导、3/重新创建映像/重新部署、4/替换。但是，进入重新引导步骤后，绕过故障通常是更快的方法（一般最多需要 3-4 分钟）。因此，为了在尝试重启后最快速地缓解影响，请绕过故障，然后在后台继续恢复过程以恢复工作负载的容量。
规则 10
侧重于缓解影响，而不是解决问题。以最快的速度恢复正常运行。
故障诊断
检测到故障之后，修复过程进入诊断阶段。这是操作人员试图确定问题所在的阶段。这一过程可能包括查询日志、查看运行状况指标或登录主机进行故障排除。所有这些操作都需要时间，因此创建工具和运行手册来加快这些操作也有助于缩短 MTTR。
运行手册和自动化
同样，在确定了问题和修复措施之后，操作人员通常需要执行一些步骤来实现修复目的。例如，在发生故障后，修复工作负载的最快方法可能是重启工作负载，而这可能涉及多个有序的步骤。您可以使用运行手册来自动执行这些步骤或为操作人员提供具体指导，从而加快修复流程并降低执行出现操作的风险。
