La mitad de tus servicios empiezan a dar timeout a la vez y no se ha desplegado nada. ¿Cómo llevas ese incidente?

Declara el incidente, asigna un comandante de incidentes y separa la investigación de la comunicación. Después caza la dependencia compartida: autenticación, DNS, una base de datos, un certificado, el plano de control de la malla de servicios o una zona de la nube. Revisa qué cambió fuera de los despliegues, es decir, envíos de configuración, feature flags, registros DNS, certificados caducando y el estado del proveedor. Mitiga antes de diagnosticar descartando carga, haciendo failover o desactivando el flag sospechoso, y luego verifica con SLI de cara al usuario.

Amplio y simultáneo sin despliegue casi nunca son diez bugs independientes, es una sola cosa por debajo de todos ellos. Así que monto la estructura del incidente de inmediato, comandante y alguien de comunicación, y luego empiezo con la lista de capas compartidas: servicio de autenticación, DNS, la base de datos principal, el plano de control de la malla, certificados y estado del proveedor de nube. En paralelo pregunto qué cambió que no sea código, porque los envíos de configuración y los feature flags son cambios que la gente olvida contar. Tuvimos exactamente este patrón una vez y resultó ser la renovación de una autoridad certificadora interna que había dejado caducar en silencio un certificado intermedio, así que todos los handshakes de TLS mutuo empezaron a fallar en el mismo minuto. La pista era que los fallos eran a nivel de conexión y no de aplicación. Mientras corre esa investigación quiero una palanca de mitigación lista, normalmente descartar tráfico no esencial o hacer failover a la región secundaria, porque prefiero estar degradado y estable a estar completamente roto mientras pensamos. Luego verifico con métricas de usuarios reales, no solo con pods en verde.