Quando a cloud começa a falhar, o impulso é abrir o painel, aumentar capacidade e correr atrás do componente quebrado. Só que, em um incidente grande, justamente essas ações podem depender de sistemas que também estão sob estresse.
O relatório de um incidente recente do Google Cloud Storage é um lembrete desconfortável disso. Em 8 de outubro, clientes da região us-central1 enfrentaram latência alta e erros de escrita por 12h30. No dia seguinte, houve recorrência por mais 5h41 em uma zona. A causa descrita pela Google envolveu uma alteração de roteamento que concentrou tráfego em nós sem capacidade suficiente; a primeira tentativa de adicionar capacidade esbarrou em limites regionais.
Não é uma história sobre “a cloud não presta”. É uma história sobre dependências. E ela deixa uma pergunta bem prática para qualquer time pequeno: o que continua funcionando quando o fornecedor, a rede ou o plano de controle não respondem como esperado?
O incidente não é a hora de inventar o modo degradado
Em incidentes, duas tarefas acontecem ao mesmo tempo: reduzir o impacto para quem usa o produto e entender a causa. Misturar as duas sem coordenação vira uma fábrica de mudanças apressadas.
O guia de resposta a incidentes do Google SRE recomenda uma estrutura simples: declarar o incidente cedo, definir papéis, manter um registro do que foi tentado e centralizar a comunicação. Não exige uma central de operações cinematográfica. Exige que alguém saiba quem decide, quem investiga, quem atualiza clientes e onde fica a linha do tempo.
Para um time pequeno, isso pode caber em um canal, um documento e três responsabilidades explícitas. O que não cabe é descobrir, no meio da falha, quem pode desativar uma feature, quem fala com o suporte do fornecedor ou onde está a lista de dependências críticas.
O plano de contingência precisa começar pelo produto
“Usamos multi-região” não responde sozinho à pergunta. Uma arquitetura só ajuda se o produto souber o que fazer sem o recurso que caiu.
Algumas decisões precisam estar prontas antes:
- O que pode parar? Upload de imagem pode entrar em fila; pagamento ou autenticação talvez não.
- O que pode ficar atrasado? Relatórios e sincronizações assíncronas podem ser retomados depois.
- O que pode usar dado antigo? Catálogo, perfil e configurações podem continuar servindo uma versão conhecida.
- O que deve falhar de forma clara? É melhor informar indisponibilidade temporária do que aceitar uma operação que será perdida.
Esse recorte evita um erro comum: tentar manter tudo “normal” e derrubar o que ainda estava de pé. Degradação bem desenhada é escolha de prioridade, não derrota.
Não dependa de capacidade que só existirá depois da pane
A AWS chama de estabilidade estática o desenho em que o sistema continua operando mesmo com uma dependência degradada, sem precisar criar recursos, puxar configuração nova ou fazer uma mudança grande para se recuperar.
É uma ideia útil porque o caminho de recuperação costuma depender do plano de controle: criar instância, atualizar regra, buscar segredo, registrar serviço, escalar banco. Essas são operações mais complexas do que atender tráfego já conhecido — e podem ser as primeiras a ficar frágeis num evento amplo.
Isso não significa reservar infraestrutura infinita. Significa testar se a capacidade restante, a fila e os limites conhecidos dão conta de um cenário plausível. Se a resposta for “vamos subir mais coisa durante o incidente”, o plano ainda é uma aposta.
Um checklist que vale deixar pronto
- Mapa de dependências: fornecedor, região, DNS, identidade, fila, banco, storage e serviços externos.
- Modo degradado documentado: quais funções desligar, enfileirar, limitar ou servir com dado em cache.
- Rollback viável: mudança recente tem dono, critério de reversão e caminho conhecido?
- Comunicação: canal interno, status público e frequência mínima de atualização.
- Observabilidade útil: taxa de erro, latência, fila e impacto por funcionalidade — não só um painel verde.
- Teste de mesa: uma hora simulando “storage indisponível” revela lacunas que o diagrama não mostra.
O relatório da Google também mostra por que rollback precisa ser tratado como capacidade operacional, não como botão mágico: a recorrência veio de uma reversão incompleta de uma funcionalidade de planejamento de uploads. Sob pressão, até o caminho de volta pode ter dependências escondidas.
O aprendizado não é copiar a arquitetura de uma big tech
Times pequenos não precisam reproduzir a engenharia de um provedor global. Precisam saber qual é o seu serviço essencial, qual falha é tolerável e qual decisão reduz dano em minutos.
O melhor momento para descobrir isso é numa semana tranquila, com uma conversa objetiva sobre fila, cache, backup, comunicação e dono do incidente. Quando a cloud falhar por horas, essa conversa já virou vantagem operacional.
