Salió un despliegue hace una hora y las tasas de error llevan subiendo desde entonces. ¿Qué haces?

Revierte primero e investiga después, salvo que el despliegue incluyera una migración de base de datos que haga inseguro el rollback. Confirma que la cronología encaja con el despliegue, comprueba si los errores se concentran en las instancias de la versión nueva y luego vuelve al artefacto anterior o redirige el tráfico. Cuando la tasa de errores se recupere, deja la build fallida disponible en un entorno de staging para poder diagnosticar sin que lo paguen los usuarios.

Por defecto, revertir. Una hora de errores en subida no es un misterio que resolver en vivo, es una hemorragia que parar, y el artefacto anterior es bueno conocido. Antes de apretar el gatillo hago dos comprobaciones rápidas. Una, ¿la curva de errores empieza de verdad a la hora del despliegue o ya subía antes?, porque si empezó antes el despliegue es una coincidencia y revertir malgasta diez minutos. Dos, ¿esta release incluía una migración de esquema?, porque si la incluía necesito saber si el código antiguo sigue funcionando contra el esquema nuevo. Si hicimos bien lo de expandir y contraer, funciona, y revertir es seguro. Si alguien eliminó una columna, revertir es ahora la opción peligrosa y voy a por un arreglo hacia delante o un feature flag. Cuando los errores se recuperan dejo la build mala desplegada en staging para poder reproducir sin clientes de por medio. Después, la pregunta que insistiría en hacer es por qué un canary no lo cazó, porque una hora de impacto significa que el despliegue no estaba vigilando la tasa de errores contra una línea base.