Cometí un error en producción: cómo comunicarlo y ayudar a resolverlo

La terminal devolvió una respuesta inesperada. Una migración bloqueó la tabla principal, un despliegue afectó la pantalla de pago o una variable de entorno fue sobreescrita. El ritmo cardíaco se acelera. Cualquier ingeniero u operador de sistemas con experiencia ha sentido esa misma presión. La diferencia entre un incidente controlado y una crisis prolongada no radica en no cometer errores jamás, sino en lo que haces durante los primeros diez minutos tras detectar el problema.

Quedarse paralizado por la incomodidad o intentar arreglarlo todo a ciegas antes de que alguien se dé cuenta es el camino más directo para agravar la falla. Este es el protocolo desarrollado tras años de gestión de infraestructuras críticas.

1. Detén la degradación antes de buscar culpables

En momentos de emergencia, la prioridad absoluta es proteger a los usuarios y la integridad de los datos. Identificar la causa raíz es importante, pero eso corresponde a la etapa en que la operación vuelva a ser estable.

Antes de cualquier impulso precipitado:

1. Deja de cambiar parámetros sin registrar: ejecutar comandos apresurados con la esperanza de un acierto fortuito suele generar un segundo problema sobre el primero.
2. Evalúa el rollback inmediato: si la versión anterior funcionaba bien y existe un mecanismo automatizado de reversión, utilízalo. Volver al estado seguro compra tiempo para investigar con calma.
3. Protege la información: si existe riesgo de corrupción o pérdida de datos, pon el servicio en modo de mantenimiento o activa interruptores de contingencia (circuit breakers).

2. Comunica con hechos, claridad y sin pánico

El peor fallo no es el error técnico original; es mantener al equipo y a los líderes desinformados mientras el impacto crece. Una comunicación efectiva es objetiva, concisa y directa.

Utiliza una estructura de cuatro puntos en el canal de incidencias:

• Qué ocurrió: "A las 14:32, durante el despliegue de la versión 2.4, una modificación de índice bloqueó transacciones en la tabla principal de pedidos."
• Impacto observado: "Los usuarios experimentan errores de tiempo de espera al finalizar compras. Los registros guardados con anterioridad continúan intactos."
• Acción en curso: "Iniciamos el rollback hacia la versión 2.3. Tiempo estimado de recuperación: 7 minutos."
• Qué se requiere: "Necesitamos que un especialista con acceso de administrador a la base de datos verifique la liberación de bloqueos de conexión."

Esta postura desarma el pánico. Muestra que la dificultad fue identificada, que hay personas trabajando en ella y que existe un plan ordenado hacia la solución.

3. Separa lo comprobado de las suposiciones

Durante un incidente activo, suelen surgir opiniones encontradas al mismo tiempo. Es fundamental conservar la disciplina operativa:

• Separa los datos objetivos de telemetría (uso de CPU, tasas de error HTTP, latencias y registros del sistema) de las corazonadas.
• Asigna a una persona la responsabilidad de coordinar las comunicaciones mientras otra persona lidera la corrección técnica.
• Mantén abiertas notas de texto con el registro exacto de cada comando ejecutado, hora y resultado obtenido. Serán esenciales para el análisis posterior.

4. El análisis post-incidente sin señalamientos (Blameless Post-Mortem)

Una vez que el sistema se recupera y las métricas se estabilizan, comienza la etapa más valiosa: aprender de lo vivido.

Si un único comando ejecutado por una persona fue capaz de derribar toda una operación, el problema no es esa persona. La verdadera debilidad residía en la falta de mecanismos de protección, en la ausencia de validaciones automatizadas en la pipeline o en permisos excesivos.

Reúne al equipo para responder cuatro preguntas esenciales:

1. ¿Qué provocó el incidente y cuál fue la secuencia cronológica de los hechos?
2. ¿Cómo detectamos la falla y cuánto tiempo pasó entre el inicio del error y la primera acción?
3. ¿Qué partes de los planes de contingencia funcionaron adecuadamente?
4. ¿Qué acciones concretas tomaremos para que este escenario no vuelva a repetirse? (Por ejemplo: pruebas de carga previas, validación de esquemas en staging o candados de seguridad en migraciones).

Ejercicio práctico para el lector

Antes de tu próximo despliegue relevante en un entorno de producción, responde a estas tres preguntas:

1. Si este cambio falla a mitad de camino, ¿cuál es el comando o botón exacto para regresar a la versión previa?
2. Ante una anomalía, ¿a quién debes notificar en los primeros cinco minutos?
3. ¿Cómo comprobarás, mediante una métrica o consulta verificable, que el sistema se encuentra saludable tras la modificación?

Desarrollar el hábito de responder a estas dudas antes de presionar enter es lo que distingue al operador reactivo del profesional que transmite confianza a cualquier equipo.

Continúa leyendo: conoce Qué hacer cuando te bloqueas en un proyecto y Seniority en la práctica.