简单复盘一下 AWS 这次事件作为一个 AIGC Startup SRE 的一些操作吧,希望能帮到大家
从入职开始发现我们主要的集群在 USE1 之后,我就开始做一些准备了。
我主要做的事情有这几件事
- 将我们核心的几个数据库做了多地的备份,形成了 USE1,Tokyo,SG 三地备份。这样在极端情况下,我们损失一部分数据,但是也能保证服务的继续
- 将我们 SG 的测试集群从原本的 EC2 自己简单搭的 K3S,重构为了一个标准的 AWS EKS 集群。这样可以在灾害时刻快速 warmup 一个集群,复用 AWS 已有组件。将 manifest 变更的代价降至最小
- 简单梳理了一个 SOP,包含用户公告,DNS 切换,封版等事宜
回到今天,我大概在 AWS 事故发生后的10min,发现了我们容器中有新的 Pod 无法 setup。
在和 AWS 支持确认是 USE1 的问题后,我意识到 ECR 的事件必然关联其余事件,于是我就果断按照我自己规划的 Tier1 等级事件开始处理(对于 SRE 来说,这种事情宁可错,但是不能错过)
T+0 min,我发布了全员公告,开始进入紧急模式。我 setup 了一个全员公开会议。所有人员可以随时加入
T+2 min,我确认事件如我所预期的一样,在逐渐扩大,我发出了两个指令,1. 全线禁止任何代码合入/提交(主要是避免新创建资源会导致 Pod rotate 进而影响流量),2. 请运营同学准备公告
T+3 min, 我开始按照 SOP,开始进行数据库在 SG 区域的恢复,并且级联创建诸如 OpenSearch / Redis 等在内的依赖
T+5 min,我们开始正式的确认上下游依赖的具体问题,确认一个新上线的核心服务受到影响
T+10min,我们停服公告和其余服务的受影响公告发出
T+10min,我请另外两位同时协助 setup 新的 ECR 以及清理测试环境已有资源,并同步 CTO ,在极端情况下,我们可能会存在保体验,丢数据的决策。
T+15min, 我们最终确认目前已创建的资源以及流量入方向不会受到太大影响。切换方案挂起,但是我们继续准备相关资源
T+30min,我们第一个数据库恢复完毕
T+40min,我们第二个数据库恢复完毕
T+1h,我们所有关联的核心 infra,RDS/ES/Redis 都 stand by,并且按照生产架构设置主从等优化选项。同时我们也开始正在新的集群启动新的服务
所幸,最终 AWS 的 crash 没有影响我们全部服务。我们无须面对切换流量后复杂的数据修复工作
大概 T+2h 到 T+3h 后,我正式通报全员,紧急状态解除。为保险起见,今晚依旧对 feature 封版。
回顾整个事故,我还可以做的更多
- 将我之前为自己准备的极端 case SOP,对全员公开。这样确保我即便不在线,也有人能接替我
- 我们可以做一些提前的预先演练
- 指令下达可以更果断一些
差不多就是这样,一点分享,希望能帮到大家