VTEX 13/07/2023: o rollback não segura a cascata e é preciso recuperação de desastre

01 · CONTEXTO

Um alarme de interrupção global

Em 13 de julho de 2023, às 15:02 UTC, os alarmes da VTEX indicaram uma possível interrupção global da plataforma. A equipe de resposta a incidentes se reuniu, identificou um problema no módulo License Manager e começou a remediá-lo.

Ao ler, procure três coisas: o que a reversão de um deploy resolveu e o que ela não resolveu; como se reconstrói parte da infraestrutura degradada, com uma recuperação de desastre feita sob pressão; e o que a empresa decidiu mudar depois, em especial na estratégia de cache.

02 · LINHA DO TEMPO

Do alarme à infraestrutura degradada

O relatório oficial registra uma sequência de marcos, todos em UTC. O diagrama mostra só os componentes que o texto menciona e não pretende reproduzir as dependências internas da plataforma.

1. A equipe identificou um problema no módulo License Manager.

2. Às 15:14 UTC a equipe reverteu um deployment e observou recuperação gradual do License Manager.

3. A equipe também identificou uma falha em cascata em vários módulos.

4. Às 15:36 UTC a maior parte da cascata estava mitigada, mas uma parte da infraestrutura subjacente seguia degradada e afetava quase metade das sessões e dos pedidos globais.

03 · O DEPLOY REVERTIDO E A CASCATA

Reverter ajudou o módulo, mas não encerrou o incidente

Às 15:14 UTC a equipe reverteu um deployment e viu o License Manager se recuperar aos poucos. O mesmo relatório diz também que foi identificada uma falha em cascata em vários módulos.

Às 15:36 UTC a maior parte da cascata estava mitigada, mas uma parte da infraestrutura subjacente continuava degradada e afetava quase metade das sessões e dos pedidos globais. O relatório afirma ainda que várias ações aumentaram a estabilidade da plataforma, porém não de forma consistente até 100%.

04 · RECUPERAÇÃO DE DESASTRE

Reconstruir parte da infraestrutura

Às 16:47 UTC, depois de várias ações que não levaram a estabilidade a 100% de forma consistente, a VTEX iniciou um protocolo de recuperação de desastre para reconstruir por completo parte da infraestrutura degradada. Uma atualização de status publicada durante o incidente dizia que o processo estava demorando mais do que o previsto inicialmente.

1. Uma parte da infraestrutura subjacente estava degradada e afetava quase metade das sessões e dos pedidos globais.

2. A recuperação de desastre começou a reconstruir parte da infraestrutura degradada.

3. A VTEX distribuiu o tráfego para a infraestrutura saudável, com cuidado para evitar regressão nas mitigações.

4. Nas duas horas seguintes, o fluxo de vendas foi de quase metade para quase 100%.

5. Às 19:26 UTC mais de 90% do fluxo global de vendas estava recuperado, e logo depois a recuperação chegou a 100%.

Mesmo depois de a recuperação chegar a 100%, houve instabilidade menor para alguns clientes, com uma taxa de cancelamento de pedidos acima do normal, de cerca de 2-5%, que se resolveu às 23:20 UTC.

05 · AÇÕES E O DIA ANTERIOR

O que a VTEX decidiu mudar

O relatório lista ações para evitar incidentes parecidos. Uma delas é acompanhar mais cedo as métricas de deploy do sistema e identificar serviços sem atualização por certo período, como forma de garantir gestão de mudanças preventiva.

Outra é redesenhar a estratégia de cache entre vários serviços, com botões de flush ajustáveis de forma centralizada. Segundo o relatório, isso reduz o tempo para mitigar incidentes, porque evita ter de provisionar capacidade para invalidar certos caches.

1. A ação trata de caches usados por vários serviços.

2. A estratégia redesenhada inclui botões de flush de cache que podem ser ajustados de forma centralizada.

3. O relatório diz que isso reduz o tempo de mitigação, porque evita provisionar capacidade para invalidar certos caches.

Os dois relatórios são publicações separadas, e o relatório global não menciona o outro; por isso este texto não liga um incidente ao outro por causa. Compare os dois em pares, atentando para o que cada um aprendeu sobre disponibilidade e sobre quanto da plataforma uma falha pode alcançar.