Vamos fazer uma breve revisão do incidente da AWS como algumas operações de um SRE de uma startup AIGC, espero que isso possa ajudar a todos. Desde que comecei, percebi que nossos principais clusters estão na USE1, então comecei a me preparar. As principais coisas que fiz foram as seguintes: 1. Fiz backups em várias localidades de nossos principais bancos de dados, formando backups em USE1, Tóquio e SG. Assim, em situações extremas, podemos perder uma parte dos dados, mas ainda garantir a continuidade do serviço. 2. Reestruturei nosso cluster de teste em SG, que originalmente era um K3S simples montado em EC2, para um cluster padrão AWS EKS. Isso permite que, em momentos de desastre, possamos rapidamente aquecer um cluster, reutilizando componentes já existentes da AWS. Reduzi o custo de mudança do manifest ao mínimo. 3. Elaborei um SOP simples, incluindo anúncios para usuários, troca de DNS, congelamento de versões, entre outros. Voltando ao dia de hoje, cerca de 10 minutos após o incidente da AWS, percebi que havia novos Pods em nosso contêiner que não conseguiam ser configurados. Após confirmar com o suporte da AWS que era um problema da USE1, percebi que o evento do ECR estava necessariamente relacionado a outros eventos, então comecei a lidar com isso de acordo com o plano que eu havia elaborado para eventos de nível Tier1 (para um SRE, esse tipo de situação é melhor errar do que deixar passar). T+0 min, publiquei um anúncio para todos e entrei em modo de emergência. Configurei uma reunião pública para todos. Todos os membros da equipe podiam entrar a qualquer momento. T+2 min, confirmei que o incidente estava se expandindo como eu esperava e emiti dois comandos: 1. Proibição total de qualquer código sendo integrado/submetido (principalmente para evitar que novos recursos criados causassem a rotação de Pods, afetando assim o tráfego), 2. Pedi à equipe de operações que preparasse um anúncio. T+3 min, comecei a seguir o SOP e a realizar a recuperação do banco de dados na região SG, além de criar em cascata dependências como OpenSearch/Redis. T+5 min, começamos a confirmar os problemas específicos das dependências upstream e downstream, confirmando que um novo serviço central que havia sido lançado estava sendo afetado. T+10 min, emitimos o anúncio de parada de serviço e o anúncio de outros serviços afetados. T+10 min, pedi a mais duas pessoas para ajudar a configurar um novo ECR e limpar os recursos existentes no ambiente de teste, e informei o CTO que, em situações extremas, poderíamos ter que tomar decisões sobre manter a experiência e perder dados. T+15 min, confirmamos que os recursos já criados e a direção do tráfego não seriam muito afetados. O plano de mudança foi suspenso, mas continuamos a preparar os recursos relacionados. T+30 min, nosso primeiro banco de dados foi recuperado. T+40 min, nosso segundo banco de dados foi recuperado. T+1h, toda a nossa infraestrutura central associada, RDS/ES/Redis, estava em stand by e configuramos opções de otimização como mestre-escravo, de acordo com a arquitetura de produção. Também começamos a iniciar novos serviços em um novo cluster. Felizmente, o crash da AWS não afetou todos os nossos serviços. Não tivemos que enfrentar o trabalho complexo de recuperação de dados após a mudança de tráfego. Cerca de T+2h a T+3h depois, informei oficialmente a todos que o estado de emergência foi encerrado. Para garantir, ainda congelamos as funcionalidades esta noite. Ao revisar todo o incidente, percebo que poderia ter feito mais: 1. Tornar o SOP de casos extremos que preparei anteriormente público para todos. Assim, garantiria que, mesmo que eu não estivesse online, alguém poderia me substituir. 2. Poderíamos realizar alguns ensaios prévios. 3. As instruções poderiam ser dadas de forma mais decisiva. É mais ou menos isso, uma pequena partilha, espero que possa ajudar a todos.