Describe cómo liderarías la respuesta a un incidente crítico por un crash que afecta a un gran porcentaje de usuarios en producción

#Qué distingue a un IC de un mando de incidentes aquí

Esta pregunta está diseñada para ver si puedes liderar bajo presión sin quedar paralizado por querer la causa raíz completa antes de actuar, ni ser lo bastante temerario como para lanzar un parche a ciegas a millones de dispositivos. La señal senior es una respuesta calmada y estructurada: alguien declara el incidente y toma el mando explícitamente — aunque seas tú, diciéndolo en voz alta — porque la propiedad ambigua es como se desperdician los primeros veinte minutos con tres ingenieros investigando por separado el mismo stack trace en lugar de una persona dirigiendo trabajo en paralelo.

#Los primeros diez minutos: declara, todavía no investigues

En el momento en que un pico de crashes cruza un umbral de severidad real — un porcentaje definido de sesiones o de DAU, no una corazonada — declaro un incidente, asigno un incident commander, y abro un único canal que se convierte en la única fuente de verdad, específicamente para frenar la dispersión en hilos de Slack donde tres personas depuran en tres DMs distintos con tres imágenes parciales distintas. En esa primera ventana resisto la tentación de ponerme yo mismo a leer stack traces; mi primer trabajo es la estructura de mando y frenar la hemorragia, no ser el debugger más listo de la sala.

#Frena la hemorragia antes de entenderla

La palanca más grande en la respuesta a incidentes móviles es que Android e iOS te dan velocidades de mitigación muy distintas, y un ingeniero senior tiene que conocer ambas de memoria. En Android, si el crash correlaciona con un rollout escalonado reciente, pausar ese rollout en Play Console es casi instantáneo y compra tiempo real. En iOS no puedes retirar un binario ya instalado del teléfono de nadie — tus opciones son quitar la app de la venta para frenar nuevas instalaciones, y pedir una revisión expedita para un build corregido, que Apple normalmente resuelve en uno o dos días pero nunca es instantáneo. Precisamente por esto insisto, fuera del tiempo de incidente, en que toda funcionalidad de riesgo relevante viva detrás de un remote config del lado servidor o un kill switch — porque cambiar un flag es la única mitigación igual de rápida en ambas plataformas y que no depende del reloj de revisión de ninguna de las dos tiendas.

#Diagnosticar sin detener la mitigación

Mientras una línea de trabajo mitiga, una segunda línea — idealmente otra persona — busca la causa raíz, para que ninguna de las dos bloquee a la otra. Eso significa simbolizar el crash de inmediato (dSYMs en iOS, el archivo de mapeo de R8/ProGuard en Android) para que el stack trace sea legible en vez de un muro de offsets hexadecimales, y correlacionar el momento en que empezó el pico con todo lo que cambió recientemente: el último release, un cambio de remote config, un deploy de backend, el avance de un A/B test. En mi experiencia el crash lo causa el backend más a menudo de lo que la gente espera — una API empieza a devolver un null o un campo con una forma nueva, y una versión antigua de la app que nunca se protegió contra eso revienta al parsear, por lo que "qué cambió en el servidor en las últimas horas" pertenece a la checklist tan pronto como "qué publicamos nosotros".

#La comunicación es parte del trabajo, no un añadido

Un crash que afecta a una porción grande de usuarios es un evento de confianza tanto como uno de ingeniería, y un ingeniero senior gestiona el relato junto con el arreglo: una actualización factual, sin especulación, a stakeholders internos y a soporte con una cadencia fija — incluso "sin novedades, seguimos investigando, próxima actualización en veinte minutos" — para que nadie tenga que adivinar, más un plan claro de qué le dice soporte a los usuarios afectados. Quedarse en silencio durante un incidente es lo que convierte una mala hora en una mala semana, porque liderazgo y soporte empiezan a llenar ese silencio con sus propias suposiciones.

#Decidir entre rollback, hotfix o dejarlo correr

Una vez mitigado, decidir qué pasa después es un tradeoff real, no algo automático: un rollback completo es lo más seguro pero descarta todos los demás cambios de ese release; un hotfix puntual es más rápido de escribir que de probar y publicar con seguridad en ambas tiendas; y si el kill switch ya frenó la hemorragia, a veces lo correcto es publicar el arreglo real en el siguiente release normal en lugar de forzar un segundo cambio de emergencia sobre un sistema ya tenso. Tomo esa decisión de forma explícita, en voz alta, con el razonamiento expuesto, en lugar de quedarme por defecto con la opción que se siente más activa.

#El postmortem es donde se ve el liderazgo real

Una vez apagado el incendio, dirijo un postmortem sin culpas centrado en el sistema, no en la persona que escribió la línea que reventó — porque ese mismo error fue revisable, testeable y publicable por todo el proceso, no solo por un ingeniero. Lo que de verdad me importa como resultado son barreras concretas: un porcentaje por defecto de rollout escalonado más bajo, una alerta que dispare por la pendiente de la tasa de crashes y no solo por umbrales absolutos, una puerta de canary que ningún release pueda saltarse, y, si el diagnóstico mostró que fuimos lentos en detectar, una mirada honesta a por qué nuestras propias alertas llegaron después que los reportes de usuarios en redes sociales o en las reseñas de la tienda.