Pasos concretos que un empresario o gerente puede seguir cuando su aplicación deja de funcionar: a quién llamar, qué verificar primero y cómo minimizar el impacto mientras se resuelve el problema.
En algún momento, toda aplicación deja de funcionar. No es una cuestión de si va a pasar, sino de cuándo, por qué y —sobre todo— qué hacés al respecto. Un servidor se satura, una actualización introduce un error, un proveedor externo se cae, alguien borra algo que no debía. Las causas son muchas y variadas. Lo que marca la diferencia entre un incidente molesto y uno catastrófico no es la causa: es la respuesta.
El problema es que la mayoría de las empresas no tienen un plan para cuando su aplicación deja de funcionar. Cuando ocurre —y ocurre siempre en el peor momento, un lunes a las nueve de la mañana o un viernes a las seis de la tarde—, la reacción es una mezcla de llamadas frenéticas, mensajes cruzados, decisiones improvisadas y horas perdidas tratando de entender qué pasó antes siquiera de empezar a resolverlo.
Este artículo propone una secuencia de acciones para empresarios y gerentes. No asume que seas técnico. Asume que sos la persona que recibe la llamada —o el mensaje, o la queja del cliente— que dice "el sistema no anda". Y te dice qué hacer a partir de ese momento.
Antes de escalar, verificá tres cosas que toman menos de un minuto y evitan falsas alarmas:
¿El problema es general o es solo tuyo? Si sos la única persona que reporta el problema, puede ser un tema de conexión, de navegador, de caché. Probá acceder desde otro dispositivo, desde otra red —los datos móviles del teléfono, no el wifi de la oficina—, o pedile a alguien externo que intente entrar. Si varias personas, desde distintas ubicaciones, reportan lo mismo, el problema es real.
¿El problema es de la aplicación o de un componente externo? Muchas aplicaciones dependen de servicios de terceros: pasarelas de pago, envío de correos, mapas, autenticación. Si solo una funcionalidad específica falla —no se pueden procesar pagos, pero el resto de la aplicación funciona—, el problema puede estar en el servicio externo, no en tu aplicación.
¿Hay algún aviso del proveedor? Revisá los canales oficiales de tu proveedor de infraestructura o de la plataforma que usás. AWS, Google Cloud, Azure y otros servicios publican incidentes en sus paneles de estado. Si hay un problema generalizado, no hay nada que puedas hacer más que esperar a que lo resuelvan. Pero al menos sabés que no es un problema de tu sistema.
Abrí el navegador en modo incógnito, conectate con los datos del teléfono —no con el wifi— y tratá de acceder a la aplicación. Si funciona, el problema es local: tu conexión, tu navegador, tu caché. Si no funciona, el problema está confirmado y podés pasar al siguiente paso.
Confirmado el problema, estos son los pasos que deberían ocurrir en el primer cuarto de hora:
En situaciones de estrés, el peor esquema es el de "todos haciendo todo". Alguien tiene que tomar las decisiones y coordinar al resto. Esa persona no necesariamente es la más técnica: es la que tiene la autoridad para asignar tareas, la calma para no empeorar la situación con decisiones apresuradas y la claridad para comunicar lo que está pasando.
Si esa persona sos vos —el dueño, el gerente general—, tu rol no es resolver el problema técnico: es asegurarte de que quien puede resolverlo tenga lo que necesita y de que el resto de la empresa sepa qué hacer mientras tanto.
Si tenés un equipo interno, un proveedor de desarrollo o un servicio de soporte, este es el momento de activarlo. La comunicación inicial debe incluir tres cosas:
Si la aplicación está caída y tiene usuarios externos —clientes, proveedores, público—, comunicar el incidente reduce la presión. Un mensaje simple en el sitio web, en redes sociales o por correo que diga "Estamos experimentando una interrupción del servicio. Nuestro equipo está trabajando para resolverlo. Actualizaremos en cuanto tengamos más información" evita que los clientes llamen uno por uno preguntando si el problema es solo de ellos.
Lo que no deberías hacer en la comunicación inicial:
Mientras el equipo técnico investiga y resuelve, la empresa sigue teniendo que operar. Algunas cosas que se pueden hacer dependiendo del tipo de aplicación:
No le pidas al equipo técnico reportes de avance cada cinco minutos. Cada interrupción para dar un estado es tiempo que no se dedica a resolver el problema. Establecé un ritmo de actualización —cada treinta minutos, cada hora— y respetalo. Si el equipo no tiene novedades en ese intervalo, que lo diga: "seguimos investigando, sin novedades" también es información útil.
El momento en que la aplicación vuelve a funcionar es crítico por dos razones: hay que verificar que realmente funciona, y hay que asegurarse de que no se pierda la información generada durante la caída.
Antes de decirle a nadie que el sistema volvió, verificá:
Si algo de esto falla, el sistema no está restaurado. Seguí en modo de incidente y no comuniques una resolución que después tengas que desmentir.
Si durante la caída la operación siguió con métodos alternativos —planillas, papel, registros manuales—, alguien tiene que cargar esa información en el sistema. Esta tarea es subestimada con frecuencia: lleva tiempo, es propensa a errores y suele recaer en las mismas personas que ya están sobrecargadas por el incidente.
Designar a alguien específicamente para esta tarea, darle tiempo para hacerla sin interrupciones y verificar una muestra de los datos cargados antes de dar por cerrado el incidente.
Un incidente del que no se aprende es un incidente que va a repetirse. En los días posteriores a la restauración, tres cosas deberían ocurrir:
No para buscar culpables, sino para entender qué falló y por qué. Las preguntas que importan:
Cada hallazgo del análisis debería traducirse en una acción concreta, con responsable y fecha:
La mejor forma de prepararse para el próximo incidente es simularlo. Elegir un día y una hora, desconectar un componente del sistema —en un entorno de prueba, no en producción— y ejecutar el plan de respuesta. Medir cuánto tarda cada paso, identificar los puntos donde el plan falla o es ambiguo, y ajustarlo.
Muy pocas empresas hacen simulacros de caída de servicio. Las que lo hacen resuelven incidentes reales en una fracción del tiempo que tardan las que improvisan.
Este artículo cubre qué hacer durante un incidente. El complemento necesario es tener un plan de continuidad operacional que defina, antes de que ocurra el incidente, quién hace qué, qué procesos alternativos existen y cómo se restaura la operación. Si tu empresa no tiene ese plan, el artículo sobre cómo preparar un plan básico de continuidad operacional explica por dónde empezar.
Hay decisiones durante un incidente que no deberían delegarse en el equipo técnico porque son decisiones de negocio:
Un incidente de disponibilidad es estresante, pero no es el fin del mundo si se maneja con criterio. Las empresas que responden bien no son las que tienen la mejor infraestructura: son las que tienen un plan, designan a una persona a cargo, comunican con claridad y aprenden de cada incidente para que el próximo sea más corto, menos costoso y mejor manejado. Como ocurre con otros riesgos técnicos que nadie revisa hasta que es tarde, la diferencia entre un incidente manejable y uno catastrófico no está en la tecnología sino en la preparación previa.
¿Quieres evaluar cómo aplicar esto a tu proyecto?
Cuéntanos tu caso →