2016年2月8日星期一，UTC 时间 17:45，我们在用于提供 Redis Cloud 服务的 Google Cloud Platform 集群之一中遇到了重大中断。 到 UTC 时间 19:30，我们已能够将服务恢复到 95% 以上的受影响用户，这些用户的数据库端点具有以下后缀模式：us-central1-1-1.gce.garantiadata.com，并在 UTC 时间 20:38 完全恢复。
Redis Cloud 集群以类似 Docker 容器的方式构建——基础设施由裸机或虚拟服务器组成，我们在其上部署我们的集群工具。 部署后，每个集群可以托管多个数据库，每个数据库以完全安全和隔离的方式运行。 我们的集群具有容错能力，因此它们能够承受单个节点的故障并从中恢复，而不会中断服务。 然而，遗憾的是，前天的情况有所不同，因为软件更新引入的错误导致同一集群中的多个节点同时发生故障。 由于故障的性质，我们不得不诉诸于手动恢复集群。
以下是中断的时间表
- UTC 时间 10:30，我们的 DevOps 团队开始部署我们服务软件的每周升级。我们的每周更新仅针对非关键集群组件，不会影响服务。 任何确实影响服务的维护活动都以不同的方式管理，并会提前通知我们的用户。
- 每周升级会逐步部署到我们的集群。 首先，我们将升级部署到单个集群，并对其执行健全性和稳定性测试。 只有这样，我们才会继续推出升级，一次一个集群，一个云接一个云。
- UTC 时间 17:30，每周更新首次部署在 Google Cloud Platform 上，部署到集群 us-central1-1-1.gce.garantiadata.com。
- 将升级部署到 GCP 的节点导致集群管理进程之一出现严重问题，将其锁定在资源密集型的无限循环中。 经过几分钟的抖动后，服务器变得无响应。
- UTC 时间 17:41，由于该软件问题，集群中的第一个节点发生故障。 自动故障转移已立即触发并成功。
- UTC 时间 17:45，另外四个节点已停止响应。 由于集群的大部分节点发生故障，因此无法自动恢复，我们的 DevOps 团队已开始手动恢复。
- 集群的手动恢复包括多个自动化操作，因此在 UTC 时间 17:45 到 19:30 之间，我们的团队采取了以下步骤
- 集群中的所有节点均已关闭并终止。
- 所有集群的端点均已从与集群关联的 DNS 区域中删除。
- 已从头开始预配和构建新的集群节点，不包括每周更新。
- 集群原始节点使用的存储已重新连接到其新节点，从而可以恢复启用持久性的数据库。
- 所有没有数据持久性的数据库都已引导启动、启动，并在此后立即可用。
- 所有具有数据持久性的数据库都已引导启动、启动并开始恢复。 数据库从存储恢复到内存所需的时间与数据库的大小和操作复杂性成正比，因此较大的数据库上线速度较慢。
- 我们的 DevOps 团队在执行恢复时遇到了另一个问题，这导致该过程花费了更长的时间。 我们的 DNS 提供商限制了我们的工具生成的删除请求，并且这些受限制请求的重试未得到正确处理。 这导致必须在重新启动集群之前手动删除 DNS 条目，从而增加了停机时间。
- UTC 时间 20:38，集群的最后一个（也是最大的）数据库已成功从持久性中恢复，并且该服务已恢复为完全运行状态。
虽然语言安慰作用不大，但对于此次中断，我们深表歉意，并且我们敏锐地意识到它对我们的许多客户产生了影响。 我们 Redis 的所有人都在致力于提供最佳的 Redis-as-a-Service 解决方案，我们将不遗余力地完成此使命。 由于此次中断，尽管这对我们来说是第一次，但我们已立即采取措施以确保此类事件不再发生。 具体来说，以下是我们在近期内将采取的措施
- 所有自动每周升级均已暂停，直到部署可防止发生此类中断事件的适当程序。
- 我们正在重新验证与 DevOps 代码部署相关的 QA 流程。
- 我们正在改进我们的工具，以便它可以处理 DNS 请求的限制。
Redis 8来了—而且是开源的
分享
