Metade dos seus serviços começa a dar timeout de uma vez e nada foi publicado. Como você conduz esse incidente?

Declare o incidente, designe um comandante de incidente, e separe investigação de comunicação. Depois cace a dependência compartilhada: autenticação, DNS, um banco de dados, um certificado, o control plane do service mesh ou uma zona de nuvem. Cheque o que mudou fora dos deploys, ou seja, pushes de configuração, feature flags, registros de DNS, certificados expirando e status do provedor. Mitigue antes de diagnosticar, descartando carga, fazendo failover ou desligando a flag suspeita, e depois verifique com SLIs voltados ao usuário.

Amplo e simultâneo sem deploy quase nunca significa dez bugs independentes, significa uma coisa embaixo de todos eles. Então eu subo a estrutura de incidente na hora, comandante e uma pessoa de comunicação, e aí começo pela lista da camada compartilhada: serviço de autenticação, DNS, o banco primário, o control plane do mesh, certificados e saúde do provedor de nuvem. Em paralelo eu pergunto o que mudou e não é código, porque pushes de configuração e feature flags são mudanças que as pessoas esquecem de contar. A gente teve exatamente esse padrão uma vez e acabou sendo uma renovação de autoridade certificadora interna que tinha expirado um intermediário em silêncio, então todo handshake de TLS mútuo começou a falhar no mesmo minuto. O indício era que as falhas eram no nível de conexão e não no nível de aplicação. Enquanto essa investigação roda eu quero uma alavanca de mitigação pronta, normalmente descartar tráfego não essencial ou fazer failover para a região secundária, porque eu prefiro ficar degradado e estável do que totalmente quebrado enquanto a gente pensa. Depois eu verifico com métricas de usuário real, não só pods verdes.