正文
评论：就算有手册，一个人操作还是容易犯错。而且这种删除的操作，都不大好回滚，因为改变系统的服务设置，很可能是连锁的实时的反应。
One of these subsystems, the index subsystem, manages the metadata and location information of all S3 objects in the region. This subsystem is necessary to serve all GET, LIST, PUT, and DELETE requests.
这些子系统之一，即索引子系统，管理该区域中所有S3对象的元数据和位置信息。该子系统对于所有GET，LIST，PUT和DELETE请求都是必需的。
The second subsystem, the placement subsystem, manages allocation of new storage and requires the index subsystem to be functioning properly to correctly operate. The placement subsystem is used during PUT requests to allocate storage for new objects.
第二子系统，即放置子系统，管理新存储器的分配，并要求索引子系统正常工作以正确操作。在PUT请求期间使用放置子系统为新对象分配存储。
Removing a significant portion of the capacity caused each of these systems to require a full restart. While these subsystems were being restarted, S3 was unable to service requests.
删除大部分容量会导致每个系统需要完全重新启动。当这些子系统正在重新启动时，S3无法处理请求。
评论：大量删除会要求系统重启，这是个什么设计逻辑？一般情况下，系统设计时不会做真正的删除，只是标记为Disable状态。特别时数据库操作，Delete是一件很危险的事情，所以尽量不使用，以Mark Disable来代替。然后，最后线下维护时，再统一Delete那些Disable的记录。
Other AWS services in the US-EAST-1 Region that rely on S3 for storage, including the S3 console, Amazon Elastic Compute Cloud (EC2) new instance launches, Amazon Elastic Block Store (EBS) volumes (when data was needed from a S3 snapshot), and AWS Lambda were also impacted while the S3 APIs were unavailable.
而S3 API不可用时，在依赖S3进行存储的US-EAST-1区域中的其他AWS服务，包括S3控制台，Amazon Elastic Compute Cloud（EC2）新实例启动，Amazon Elastic Block Store（EBS）卷（当需要从S3快照）和AWS Lambda也受到影响。
S3 subsystems are designed to support the removal or failure of significant capacity with little or no customer impact.
S3子系统设计用于在很少或没有客户影响的情况下，支持大容量的移除或故障。
We build our systems with the assumption that things will occasionally fail, and we rely on the ability to remove and replace capacity as one of our core operational processes.
当我们建立系统时，假设偶尔会失败，那么依靠移除和替换能力，这是我们的核心运营流程。
