¿Cómo depurar un problema de producción de forma sistemática?

Planteamiento y contexto aplicable

A las 09:10, el proceso de checkout se degrada en una región: los errores 5xx aumentan del 0.3% al 5.2%, la latencia p95 sube de 280 milisegundos a 2.6 segundos y una versión finalizó su despliegue 10 minutos antes. No se confirma pérdida de datos. Explique cómo evaluaría la gravedad, contendría el impacto, acotaría el alcance, probaría hipótesis, validaría la recuperación y preservaría evidencia para el análisis de causa raíz durante los primeros 30 minutos.

Esta es una pregunta de resolución de problemas a través de múltiples capas dirigida a ingenieros de software, SREs, ingenieros DevOps, ingenieros de plataforma e ingenieros de soporte técnico. No asigna la falla de antemano a un cliente, servicio, base de datos, red o dependencia de terceros. La habilidad fundamental consiste en utilizar evidencia para converger desde un síntoma hacia un límite de falla mientras se controla el riesgo operativo.

Los tiempos, las tasas de error y la latencia son datos de un escenario de entrevista, no umbrales de alerta universales. Mantenga la restauración del servicio separada de la demostración de la causa raíz. Durante un incidente grave, un equipo puede aplicar una mitigación reversible y probada mientras preserva logs, muestras de trazas e historial de cambios. Una afirmación sobre la causa raíz aún necesita evidencia que distinga entre hipótesis rivales.

Qué evalúa el entrevistador

La primera señal es una formulación precisa del problema. Decir «el sistema está lento» no permite orientar la acción. Una respuesta sólida establece el comportamiento esperado frente al real, la hora de inicio, los usuarios y regiones afectados, si la falla es continua o intermitente, las pérdidas de negocio, la integridad de los datos y el riesgo de seguridad. Esos hechos determinan si se debe declarar un incidente.

La segunda señal es la priorización. Cuando los usuarios están experimentando fallas activamente, el objetivo inmediato es reducir el impacto de forma segura. Un rollback, la desactivación de una funcionalidad, un desvío de tráfico o una degradación también pueden expandir un incidente si un cambio en la base de datos es incompatible, la capacidad de respaldo es insuficiente o los protocolos han divergido. Indique las condiciones, el aprobador, la ruta de reversión y las señales de recuperación para la mitigación elegida.

La tercera señal es el diagnóstico basado en hipótesis. Los logs, las métricas y las trazas son tipos de evidencia, no una secuencia en sí mismos. Una respuesta sólida propone una lista corta de hipótesis falsables, predice la evidencia que produciría cada una y elige la verificación de menor riesgo que permita diferenciarlas. Un despliegue cerca de la hora de inicio eleva la prioridad de una hipótesis; la correlación temporal no demuestra causalidad.

La cuarta señal es la coordinación del incidente. Si varias personas modifican configuraciones, reinician instancias o activan logs detallados simultáneamente, alteran el escenario y destruyen la atribución. Una respuesta madura designa un líder de incidente, un operador y un comunicador, congela cambios no relacionados y registra cada acción y resultado observado. Solo una ruta explícitamente autorizada modifica producción en un momento determinado.

Por último, el entrevistador busca un ciclo de verificación. La tasa de errores puede disminuir porque el tráfico bajó, y un reinicio puede ocultar temporalmente una fuga de recursos. Compare la recuperación con un control sano, inspeccione latencia, errores, saturación, acumulación de trabajo pendiente (backlog) y éxito del negocio, y luego concilie por separado cargos duplicados y órdenes faltantes. La recuperación inmediata y la prevención a largo plazo necesitan criterios de salida diferenciados.

Preguntas para aclarar antes de responder

• ¿Es este un planteamiento metodológico o sobre experiencia pasada? Utilice el escenario proporcionado si es metodológico. Si el entrevistador pide experiencia propia, cambie a un incidente verificable, identifique su autoridad personal y los roles del equipo, y no invente trabajo en producción.
• ¿Cuál es el impacto en el usuario y la gravedad? Una herramienta interna de bajo volumen puede permitir la observación. Una falla generalizada en checkout, daño de datos o un evento de seguridad requiere escalamiento inmediato, restricción de cambios y un equipo de respuesta más amplio.
• ¿Podrían estar comprometidos los datos o la seguridad? Con latencia únicamente, el tráfico parcial puede seguir siendo seguro. Posibles cobros duplicados, accesos no autorizados o corrupción de datos exigen pausar escrituras o aislar la ruta, y elevan el nivel de aprobación para la recuperación.
• ¿Qué incluyó el despliegue? Código, configuración, migraciones de base de datos, versiones de dependencias e infraestructura tienen diferentes riesgos de rollback. Revertir una aplicación tras escrituras con esquemas incompatibles puede empeorar el incidente.
• ¿Dónde está el grupo de control sano? Otra región, una instancia con la versión anterior, un tenant sin la funcionalidad o endpoints alternativos en la misma región pueden separar causas de versión, región, entrada y dependencias. Sin un control, cree una solicitud sintética de bajo riesgo o una verificación de solo lectura.
• ¿Cuál es mi rol y nivel de autoridad? El líder del incidente mantiene el estado global, el operador modifica el sistema y el comunicador actualiza a las partes interesadas. Un investigador debe presentar evidencia y escalar en lugar de exceder su autoridad en producción.
• ¿Qué mitigaciones se consideran seguras? Feature flags, desvíos de tráfico, un stack estable, degradación del servicio y rollback son opciones viables únicamente tras confirmar la capacidad, la compatibilidad de estado y los pasos de reversión.

Estructura de respuesta en 30 segundos

«Primero establezco el alcance, el riesgo en los datos y la gravedad, declarando un incidente y congelando cambios no relacionados cuando sea necesario. Mientras los usuarios se vean afectados, elijo una mitigación probada y reversible con capacidad suficiente y preservo evidencia. Comparo tiempo, región, versión, grupos de solicitudes y dependencias; planteo algunas hipótesis falsables; uso métricas para el alcance, trazas para ubicar el límite lento y logs para la falla específica. Modifico una sola variable documentada a la vez. La recuperación exige SLIs saludables, éxito en las transacciones del negocio, drenado de backlogs y conciliación de datos, seguidos por el análisis de causa raíz y trabajo de prevención».

Esta apertura establece orden. Una respuesta profunda también debe exponer las condiciones de decisión y la evidencia que llevaría a descartar una hipótesis.

Respuesta detallada paso a paso

Comience con un acuerdo sobre los síntomas para que el equipo investigue el mismo problema:

• Esperado frente a real: la línea base de 5xx es 0.3% y p95 es 280 milisegundos; los valores actuales son 5.2% y 2.6 segundos.
• Tiempo: detectado a las 09:10 después de un despliegue que finalizó 10 minutos antes; determine el inicio real y si la falla es continua.
• Alcance: confirmado actualmente en una sola región; continúe desglosando por endpoint, versión, tenant, dispositivo y datos de entrada de la solicitud.
• Impacto: cuantifique checkouts fallidos y pérdidas de negocio, y determine si existe una alternativa para el usuario.
• Integridad: verifique cargos duplicados, cobros sin orden asociada, eventos faltantes y acceso no autorizado por separado. «No confirmado» no significa «ausencia demostrada».

Si el impacto supera el umbral de incidente, establezca un plano de coordinación único. El líder del incidente mantiene las prioridades y el registro de decisiones; el operador ejecuta los cambios en producción; el comunicador publica el impacto en el usuario, los hechos conocidos, la acción en curso y la hora de la próxima actualización con una cadencia fija. Congele despliegues no relacionados. Registre la cronología, capturas de dashboards, IDs de traza representativos, versiones de cambio y cada intervención. Preservar evidencia no debe bloquear la mitigación, pero los reinicios a ciegas borran evidencia en memoria y alteran observaciones posteriores.

Decida si mitigar antes de profundizar en el diagnóstico. Utilice una comparación clara: ¿es el daño actual mayor que el peor riesgo creíble de la mitigación? Detenga escrituras o aísle la ruta cuando sea posible que ocurran daños en los datos. Haga un rollback o desvíe tráfico cuando el cambio reciente sea reversible con seguridad y el objetivo estable cuente con suficiente capacidad. Prefiera un feature flag, rate limit o ruta de compatibilidad cuando hayan cambiado esquemas, formatos de mensajes o efectos secundarios externos. Toda mitigación necesita una señal esperada, una ventana de observación y una acción de reversión.

Inicie el diagnóstico mediante contrastes, no abriendo el archivo de log más extenso. Encuentre un límite donde solo un lado esté degradado a través de cinco dimensiones:

1. Tiempo: ¿qué código, configuración, certificados, tráfico y estado de dependencias cambiaron cerca del inicio?
2. Región: ¿la misma versión funciona bien en otro lugar y la versión anterior también falla en la región afectada?
3. Versión: dentro de una misma región, ¿difieren las instancias viejas y nuevas en tasa de errores y latencia?
4. Solicitud: ¿la falla se concentra por endpoint, tenant, método de pago, versión de dispositivo o tamaño de entrada?
5. Dependencia: ¿el tiempo lento se acumula en el cliente, borde (edge), aplicación, base de datos, caché o llamada a terceros?

Organice las posibles causas en un registro de hipótesis en lugar de dejarlas en el chat:

Ordene las verificaciones por probabilidad, impacto en el usuario, tiempo de respuesta y riesgo en producción. Las métricas ubican cuándo y dónde comienza un problema. Las trazas distribuidas muestran en qué punto gasta tiempo una solicitud. Los logs estructurados explican errores específicos, reintentos y transiciones de estado. El código, la configuración y el historial de despliegues describen qué cambió. Una sola línea de log no puede representar a toda la población, mientras que un agregado no puede explicar una máquina de estados individual; correlaciónelos mediante un ID de solicitud y la misma ventana de tiempo.

Modifique una sola variable por experimento y registre por escrito cómo el resultado refutaría la hipótesis. Enviar una solicitud sintética acotada a través de una configuración anterior puede distinguir entre un problema de configuración y uno de datos de entrada. Activar logs detallados en todo el entorno de producción puede aumentar la E/S y la latencia, exponer datos sensibles y alterar la falla. Ejecute primero la prueba más probable, más segura y con mayor poder de discriminación, utilizando una réplica sana, staging o tráfico limitado. Cuando no sea posible una reproducción segura, mantenga el lenguaje de «causa más probable» en lugar de elevar la correlación a certeza.

Tras una corrección o mitigación, verifique con señales independientes de la acción: 5xx, p50/p95/p99, tasa de checkouts exitosos, saturación de recursos, backlog de colas y pools de conexiones, errores aguas abajo, reintentos y estado de alertas. Compare al menos una región sana o versión estable y observe durante una ventana predeterminada lo suficientemente extensa para cubrir la variación normal. Concilie órdenes con pagos para detectar cobros duplicados, órdenes faltantes y estados bloqueados. Finalice la mitigación solo después de que los resultados de los usuarios se recuperen, los backlogs se vacíen y las comprobaciones de integridad sean satisfactorias.

Complete el análisis de causa raíz tras la estabilización. Separe el detonante directo, las condiciones técnicas que amplificaron el impacto y las deficiencias de proceso que retrasaron la detección. Los elementos de prevención necesitan un responsable, una fecha límite y un método de verificación: despliegue canary de configuraciones regionales, sondas sintéticas a dependencias, IDs de solicitud de extremo a extremo, criterios de fallback automático o un runbook ensayado. Dos mejoras probadas son más útiles que diez recomendaciones sin responsable asignado.

Ejemplo de respuesta de alta calidad

Todos los hallazgos de investigación y números que aparecen a continuación son datos ficticios de un escenario de entrevista. Demuestran una respuesta hablada y no corresponden a un incidente real ni a umbrales universales.

«Trataría esto como un incidente activo en checkout. Los errores 5xx pasaron de 0.3% a 5.2%, p95 subió de 280 milisegundos a 2.6 segundos y los usuarios continúan experimentando fallas. Inmediatamente verificaría la existencia de cobros duplicados, órdenes faltantes y riesgos de seguridad; mientras no se descarten, ‘no se confirma pérdida de datos’ no garantiza seguridad. Congelaría despliegues no relacionados, asignaría un líder de incidente, un operador de producción y un comunicador, y preservaría muestras de trazas y registros de cambios.

El despliegue reciente es una hipótesis de alta prioridad, no una conclusión. Compararía las instancias viejas y nuevas en la región afectada, utilizando luego una región sana como segundo control. Supongamos que en la región afectada la v42 tiene 5.4% de 5xx y la v41 tiene 5.0%, mientras que la v42 en otra región tiene 0.4%. Eso debilita la hipótesis de un problema exclusivo de la versión de código y apunta a una configuración regional o problema de dependencia.

A continuación inspeccionaría las trazas para el mismo segmento de checkout. Supongamos que el 91% de las fallas se deben a un timeout en la llamada al servicio de tokenización de pagos, donde el p95 es de 2.3 segundos en la región afectada y 180 milisegundos en la sana. El registro de cambios muestra que la configuración regional v17 se desplegó a las 09:00 y redirigió esa llamada a una nueva ruta de proxy. Preservaría evidencia representativa, confirmaría la compatibilidad de v17 a v16, la autoridad para el rollback y el comportamiento de las conexiones existentes, para luego revertir únicamente esa configuración regional. No haría simultáneamente un rollback de código, reinicio y escalado.

Un dashboard en verde tras la reversión no es suficiente. Supongamos que durante los siguientes 15 minutos los errores 5xx bajan a 0.4%, el p95 desciende a 320 milisegundos, las colas se vacían y el volumen de checkout se recupera. La conciliación entre órdenes y pagos confirma además que no hay cobros duplicados, órdenes faltantes ni estados bloqueados. La reversión controlada de la configuración sumada a esas señales independientes respalda que la ruta del proxy fue el detonante directo. Aun así, lo reproduciría en staging y analizaría por qué la configuración regional carecía de despliegue canary y de salvaguardas de latencia sobre dependencias.

La prevención incluiría despliegues progresivos para configuraciones regionales, sondas sintéticas por región y alertas de latencia de cola para tokenización de pagos, criterios de fallback automático que cubran tanto errores como latencia, y un runbook para rollback de configuración y conciliación de datos. Cada elemento tendrá un responsable, una fecha límite y un ejercicio de simulacro de incidente como criterio de aceptación».

Errores comunes

• Declarar el despliegue reciente como la causa raíz → Tráfico, certificados o cambios aguas abajo pueden coincidir con él → Construya controles por versión y región, y luego ejecute una verificación cuya predicción pueda fallar.
• Abrir todos los logs al principio → Sin tiempo, alcance ni hipótesis, más datos generan más anomalías irrelevantes → Cuantifique el síntoma y use métricas y trazas para acotar el componente y segmento.
• Hacer rollback incondicionalmente → Una versión anterior puede ser incompatible tras cambios de esquema, mensajes o estado → Verifique la compatibilidad de estado, la capacidad y la ruta de reversión antes de elegir la mitigación.
• Permitir que todos intenten aplicar una solución → Cambios concurrentes destruyen la atribución y pueden expandir el incidente → Asigne roles y canalice los cambios en producción a través de una autoridad registrada.
• Considerar el reinicio como la causa raíz → Reiniciar restablece colas, conexiones o memoria y solo prueba que el estado se limpió → Descubra qué genera ese estado y observe si vuelve a acumularse.
• Revisar únicamente la latencia promedio → Una cola de fallas severa puede quedar oculta en el promedio → Inspeccione errores, percentiles de latencia, tráfico y saturación, segmentados por la cohorte afectada.
• Activar logs detallados sin evaluar el riesgo → El logging puede incrementar E/S y latencia o exponer campos sensibles → Limite las instancias, la duración y los campos, con un apagado automático.
• Omitir la conciliación de datos tras la recuperación de los dashboards → Los reintentos por timeout pueden haber provocado cobros duplicados, órdenes faltantes o acumulación en colas → Concilie explícitamente los registros de negocio y los efectos secundarios externos.
• Cerrar la revisión con «mejorar el monitoreo» → Sin métrica, responsable, umbral o prueba, no hay mejora verificable → Defina acciones ejecutables y acéptelas mediante simulacros o inyección de fallas.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: El rollback finaliza, pero el incidente no mejora. ¿Qué sigue?

Registre que el rollback se completó y verifique que el tráfico realmente llegue a la versión anterior; de lo contrario, que el «rollback haya fallado» puede ser en sí una falla del sistema de despliegue. Si la versión anterior sigue degradada, disminuya la prioridad de la hipótesis de regresión de código y compare configuración regional, spans de dependencias, certificados, DNS, mezcla de tráfico y recursos compartidos. No vuelva a desplegar la nueva versión de inmediato a menos que restaurarla ofrezca un beneficio claro y un riesgo evaluado.

Pregunta de seguimiento 2: ¿Qué cambia si se sospecha de corrupción de datos?

La contención adquiere mayor prioridad. Pause las escrituras relevantes, aísle a los tenants afectados o active el modo de solo lectura; preserve logs de auditoría y eventos sin procesar; y exija la participación de los responsables de datos o seguridad en la aprobación de la recuperación. Valide una reparación sobre copias o datos aislados, haga un inventario del rango afectado, concílielo y aplique una corrección reversible. Respuestas de servicio en verde por sí solas no autorizan la reapertura de escrituras.

Pregunta de seguimiento 3: ¿Qué ocurre si hay logs dispersos pero no distributed tracing?

Utilice logs de acceso del gateway, marcas de tiempo, instancias, tipos de solicitudes y campos de correlación existentes para aproximar el límite. Envíe una solicitud sintética de bajo riesgo con un identificador conocido a través de cada paso. No comience a imprimir cuerpos de solicitudes en todo el entorno productivo. Tras el incidente, agregue un ID de solicitud desde el borde hasta las dependencias junto con campos de latencia, estado y versión en límites críticos; la falta de observabilidad es una condición amplificadora con un responsable y prueba de aceptación asignados.

Pregunta de seguimiento 4: Varios equipos insisten en que la falla está en el sistema de otro. ¿Cómo procede?

El líder del incidente asigna investigaciones de componentes en función del impacto en el usuario, no de culpas organizacionales. Todos trabajan a partir de una única cronología y un registro de hipótesis común, enviando predicciones comprobables y evidencia, como «esta solicitud salió de nuestro servicio con éxito en 120 milisegundos, mientras que el span siguiente tomó dos segundos». La autoridad sobre producción se mantiene unificada y el comunicador consolida los hechos para que ningún equipo altere el sistema de forma independiente.

Pregunta de seguimiento 5: El problema es intermitente y no se puede reproducir de manera confiable. ¿Cómo formula una causa raíz?

Amplíe primero la evidencia pasiva segura: tome muestras de éxitos y fallas, conserve dimensiones de versión y entrada, y capture el estado de recursos y dependencias. Busque controles naturales que permitan diferenciar hipótesis. Utilice inyección de fallas o reproducción de tráfico en aislamiento, sin crear condiciones riesgosas en producción para obtener certeza. Si la evidencia solo respalda una probabilidad, plantee el factor más probable y las incógnitas restantes, para luego agregar salvaguardas y observabilidad que reduzcan el impacto ante una recurrencia.