AWS近日披露了关于《Amazon EC2 以及 Amazon EBS 在东京区域 (AP-NORTHEAST-1) 的服务事件》的说明，以下为披露的原文，供各位参考。
针对在东京区域 (AP-NORTHEAST-1) 的服务中断事件，我们在这里提供更多信息。从 2019 年 8 月 23 日 11:36 AM CST (中国标准时间)开始，一小部分的 EC2 服务器在东京 (AP-NORTHEAST-1) 区域中单一可用区 (Availability Zone) 由于服务器过热造成停机。这导致在该可用区中受到影响的 EC2 实例与 EBS 卷效能降低。造成服务器过热的原因是控制系统故障，造成受影响的可用区的部分冷却系统失效。
受到影响的冷却系统已经在 2:21 PM CST (中国标准时间)修复，服务器温度也恢复到正常状态。在温度恢复正常后，EC2 实例的电源供应也已恢复。
在 5:30 PM CST (中国标准时间) ，大部分受影响的 EC2 实例与 EBS 卷都恢复正常工作，但仍有一小部分的实例与卷因为过热与断电暂时无法修复，因为底层硬件的故障，其中有些实例与卷需要更多的时间进行修复。
除了 EC2 实例与 EBS 卷受到影响外，在 12:21 PM CST (中国标准时间) EC2 RunInstances API 也受到了影响。在受影响的可用区中，尝试启动新的 EC2 实例和和尝试使用 RunInstances API 的 "idempotency token" 功能 (一个允许用户启动新的实例时重试而不会产生多余的实例的功能)时，也有发生错误。其他没有调用 "idempotency token"的 API 则可正常运作。
这个事件也导致透过 "idempotency token" 使用 Auto Scaling 时，无法启动新实例。
后台团队已经于 1:51 PM CST (中国标准时间) 修复了 “idempotency token” 与 Auto Scaling 相关的问题。并且于 3:05 PM CST(中国标准时间)在受影响的可用区中，修复了EC2 控制面板的子系统，开启新实例的功能已经可以正常工作。但在本事件中受到影响的卷所建立的新快照 (Snapshot) 依旧有一定的错误率。
本次事件是由于数据中心负责控制和优化冷却的控制系统故障所造成，这个控制系统在多个主机都有部署以实现高可用性，本控制系统中包含了允许与风扇、冷却器和温度传感器等硬件组件相互传递信号的第三方的程序，该程序可以直接或透过 Programmable Logic Controllers (PLC) 来与实际的硬件组件沟通。
在这事件发生前，数据中心的控制系统正在为了其中一台失效的控制主机进行备份处理，在备份处理中，控制系统要彼此互相交换信号 (例如：冷却装置与温度传感器交换信号)以保持最新的信息。由于该第三方程序中的一个错误，导致控制系统与组件过度的进行信息交换而造成控制系统无法回应。
我们的数据中心被设计成一旦控制系统发生错误，冷却系统就会自动进入最冷的模式，直到控制系统恢复正常为止，这样的设计对于我们大部分的数据中心都是有效的，但有一小部分的数据中心，由于冷却系统无法正确进入安全降温模式，而造成系统关机。
我们的数据中心加入了安全防护设计，在控制系统故障时，可以略过控制系统，直接进入净空模式将数据中心中的热空气迅速排出，但控制中心的团队在启动净空模式时发生了故障，所以数据中心的温度才会持续攀升，而服务器在到达温度上限后也开始自动关机了。
由于数据中心的控制系统故障，维运团队无法得知数据中心冷却系统的即时信息，在进行故障排除时，团队必须要对所有组件进行逐一的人工检查，才能让控制系统进入最冷模式，在这故障排除的过程中，发现控制空调组件的 PLC 控制器无法回应，控制器需要进行重置，是 PLC 控制器的错误造成了预设的冷却模式与净空模式无法正确动作，在 PLC 控制器被重置之后，该可用区数据中心的冷却系统就可以正常工作了，而数据中心的过高的温度也开始慢慢降低。
我们仍在与第三方供应商合作以了解导致控制系统和受影响的 PLC 无响应的错误和后续交互。 在此期间，我们已禁用在我们的控制系统上触发此错误的故障转移模式，以确保我们不会再次出现此问题。
我们还培训了我们的本地运营团队，以便在发生这种情况时快速识别和修复这种情况，并且我们相信，如果再次发生类似情况，无论什么原因，我们可以在客户受影响之前重置系统。 最后，我们正在努力修改我们控制受影响的空气处理单元的方式，以确保“清除模式”能够完全绕过PLC控制器。
这是我们在最新的数据中心设计中开始使用的一种方法，即使 PLC 无响应，我们也会更加确信“清除模式”将起作用。
在这次事件中，EC2 实例以及 EBS 储存在同一区域的其它的可用区没有受到影响。同时在多个可用区上充分执行他们的应用程序的客户，在这次的事件中依然可以维持服务可用。对于需要绝对高可用的客户，我们持续建议您使用高可用性的架构设计。任何与应用程序相关的元件都应该采用这种容错设计。
