Un cambio de tu equipo tumba producción. Cuéntame qué pasa a continuación.

Primero restaura el servicio, después investiga. Pon en marcha la mitigación segura más rápida, normalmente un rollback salvo que revertir sea más arriesgado, mantén un incident commander claro y una persona distinta a cargo de la comunicación, y protege al ingeniero implicado para que no tenga que arreglar y explicar a la vez. Después haz una revisión sin culpables que encuentre las debilidades del sistema (barreras que faltan, ruta de despliegue insegura, pruebas flojas) en vez de a la persona.

Mitigación primero. La única pregunta en los primeros cinco minutos es cuál es la vuelta segura más rápida a un estado que funcione, y normalmente eso es un rollback y no un arreglo inspirado bajo presión. Me aseguro de que alguien sea incident commander y de que otra persona lleve la comunicación, porque los peores incidentes que he visto fueron aquellos en los que quien tecleaba también respondía al directivo que se sumaba a la llamada. Si el ingeniero que lanzó el cambio es la mejor persona para arreglarlo, lo arregla, y yo le quito de encima todas las demás conversaciones. Cuando ya está estable, la revisión va sobre el sistema. Cuando esto pasó en mi equipo, un cambio de configuración se saltó staging porque la ruta de despliegue lo permitía. El ingeniero fue la última ficha del dominó, no la causa. Las acciones fueron una barrera en esa ruta, una prueba para ese fallo concreto y mejores alertas, cada una con un nombre y una fecha. Y en la revisión digo en voz alta que el cambio era razonable con la información que tenía, porque todo el equipo está mirando cómo se trata a esa persona.