Tienes una tienda online. Alguien está pagando ahora mismo. El pago falla. El cliente recibe un error. El cliente se va. Acabas de perder una venta.
Sin un panel operativo, no encontrarías el error hasta mañana, cuando revises el informe diario.
Con un panel operativo, el equipo de operaciones detecta el error en segundos. Lo arregla de inmediato. El cliente lo intenta de nuevo. La venta se completa.
Coste de una detección lenta: cientos de dólares por hora y por error.
Los paneles operativos detectan problemas en tiempo real, no horas o días después.
La función de los paneles operativos
Los paneles operativos vigilan la salud de los sistemas y las operaciones en curso.
La web está activa. Funcionan los procesos de pago. Responden los procesadores de pagos. Se envía el correo. Las llamadas a la API funcionan.
Un panel operativo no trata de ingresos ni de métricas de negocio. Trata de la salud de los sistemas.
Requisito de datos en tiempo real
El panel operativo debe actualizarse en tiempo real o casi (en menos de un minuto).
Los datos retrasados no sirven. Si el panel se actualiza cada hora, te pierdes las caídas que ocurren entre actualizaciones.
El requisito de tiempo real implica que el panel operativo es caro de construir y mantener. Úsalo solo para sistemas críticos.
Qué vigilar en el panel operativo
Disponibilidad del sistema
La web responde. Verde si está activa, rojo si está caída.
Tiempo de respuesta
Qué tan rápida es la web. Verde si tarda menos de dos segundos, amarillo si tarda de dos a cinco segundos, rojo si tarda más de cinco segundos.
Tasa de errores
Qué porcentaje de solicitudes devuelve errores. Verde si es menos de 0,1 %, amarillo si está entre 0,1 % y 0,5 %, rojo si supera el 0,5 %.
Transacciones activas
Cuántas transacciones hay ahora mismo. Como referencia. No es buena ni mala en sí misma.
Embudo de conversión en curso
Cuántos visitantes están en cada paso del pago ahora mismo. Un abandono en cualquier paso activa una investigación.
Rendimiento de las API
Tiempos de respuesta de las integraciones externas. Procesador de pagos, servicio de correo, API de envíos.
Rendimiento de la base de datos
Tiempos de respuesta de las consultas, estado del conjunto de conexiones.
Ejemplo real: panel operativo de una tienda online
Sección superior (salud del sistema)
Estado de la web: ACTIVA (verde). Tiempo de respuesta: 1,2 segundos (verde). Tasa de errores: 0,08 % (verde). Usuarios activos: 423. Transacciones en curso: 17.
Sección central (embudo de pago)
Vista del carrito: 127 usuarios. Inicio del pago: 89 usuarios (70 % de conversión desde el carrito). Datos de envío: 72 usuarios (81 % de conversión). Datos de pago: 68 usuarios (94 % de conversión). Confirmación del pedido: 64 usuarios (94 % de conversión). Abandono en los datos de envío: 17 usuarios (ojo, es más alto de lo normal, investigar).
Sección inferior (integraciones)
Procesador de pagos: responde en 800 ms (verde). Servicio de correo: 99,8 % de entrega (verde). Calculadora de envíos: responde en 1200 ms (amarillo, algo lenta).
Acción inmediata
El abandono en los datos de envío es más alto de lo normal. Investiga si la lentitud de la calculadora de envíos está causando abandonos.
Sistema de alertas
El panel operativo debería lanzar alertas cuando las métricas se ponen en rojo.
Avisa al equipo de operaciones de inmediato. No con un correo que se puede pasar por alto. Con SMS, mensajería del equipo o un buscapersonas que interrumpa.
Los umbrales deben ser estrictos. No quieres falsas alarmas. Pero es mejor tener una falsa alarma y detectar un problema real que perder problemas.
Ejemplos de umbrales: web caída durante 30 segundos = alerta. Tasa de errores superior al 1 % durante 5 minutos = alerta. Tiempo de respuesta superior a 5 segundos durante 10 minutos = alerta. El procesador de pagos no responde = alerta inmediata.
El turno de guardia
Para sistemas lo bastante críticos como para necesitar un panel operativo, necesitas un turno de guardia.
Alguien es responsable de la vigilancia las 24 horas, los 7 días. Si salta una alerta a las 3 de la madrugada, la persona de guardia se despierta y arregla el problema.
La guardia es cara. Pero el coste de una caída es más caro.
Pon en el panel operativo con guardia solo los sistemas críticos.
Qué NO vigilar
No vigiles métricas de negocio en el panel operativo. Los ingresos, las conversiones y las tendencias de tráfico son para paneles de negocio, no para paneles operativos.
Mezclar negocio y operaciones confunde el fin del panel. Lo operativo trata de la salud de los sistemas. Lo de negocio trata de la salud del negocio.
Paneles separados para fines separados.
Panel frente a alertas
El panel operativo te permite vigilar de forma proactiva. Mira el panel antes de que el problema se vuelva crítico.
Las alertas te permiten responder de forma reactiva. Ocurre el problema, salta la alerta y lo arreglas.
Se necesitan los dos. El panel para la vigilancia proactiva. Las alertas para la respuesta reactiva cuando nadie está mirando el panel.
Guías de respuesta a incidentes
Cuando salta una alerta, qué pasa después. El equipo operativo debería tener una guía para cada tipo de alerta.
Alerta de web caída: reiniciar el servidor web. Si sigue caída, pasar a la copia de respaldo. Si sigue caída, escalar a un ingeniero sénior. Alerta de procesador de pagos caído: cambiar al procesador de respaldo. Avisar a los clientes de un posible retraso. Vigilar hasta que se recupere el procesador principal. Alerta de base de datos lenta: revisar el conjunto de conexiones. Si está lleno, ampliarlo. Revisar el registro de consultas. Cancelar las consultas lentas. Vigilar.
Las guías evitan el pánico. Unos pasos claros evitan errores.
Preguntas frecuentes
¿Cada cuánto debemos revisar el panel operativo?
De forma continua en horario laboral. Una persona vigilando en todo momento. Fuera del horario laboral, vigila la persona de guardia. Para sistemas no críticos, revisa cada hora. Para sistemas críticos (procesamiento de pagos, pago en la tienda), vigilancia continua. Define qué sistemas son críticos: sistemas donde una hora de caída cuesta muchos ingresos. Todo lo demás se puede revisar cada hora. Con el creador de webs de WEMASY, puedes configurarlo directamente en tu web.
¿Qué tiempo de respuesta es aceptable?
Para el pago de una tienda online: menos de dos segundos. Para una web de marketing: menos de tres segundos. Para herramientas internas de administración: menos de cinco segundos. Si es más lento, sufre la conversión o la experiencia de usuario. Mide desde la perspectiva del usuario, no del servidor. Si el usuario nota el retraso, es demasiado lento.
¿Cómo evitamos la fatiga de alertas?
Umbrales estrictos. Alerta solo cuando haya un problema real. Si recibes diez alertas al día y nueve son falsas alarmas, la gente deja de prestar atención. Es mejor tener dos alertas al día que sean todas reales. Ajusta los umbrales sin miedo. Si salta una alerta y no es urgente, sube el umbral. La fatiga de alertas acaba con la capacidad de respuesta.
¿Debe poder consultarse el panel operativo desde el móvil?
Sí. La persona de guardia necesita consultarlo desde cualquier sitio. Asegúrate de que funciona en el teléfono. La persona de guardia puede estar lejos de su mesa. Optimiza para móvil. Botones táctiles grandes. Diseño sencillo. Carga rápida incluso con 4G.
¿Cómo seguimos la salud operativa a lo largo del tiempo?
Registra todas las métricas. Aunque el panel operativo sea en tiempo real, conserva el historial. Revisa cada semana: cuántas veces estuvimos caídos, cuán lentos fuimos y cuáles fueron los errores principales. Usa el historial para identificar problemas sistémicos. Ejemplo: si tienes tres tiempos de espera agotados del procesador de pagos por semana, investiga el procesador de pagos. No te limites a ajustar el umbral de la alerta.
¿Y si la persona de guardia no sabe cómo arreglar el problema?
Ten una vía de escalado. La persona de guardia es quien responde primero. Si no puede arreglarlo en cinco minutos, escala a un ingeniero sénior. El ingeniero sénior es el segundo nivel. Si ninguno de los dos puede arreglarlo, escala al soporte del proveedor o a la dirección general. Las guías deberían describir la vía de escalado para cada tipo de alerta.