Aprende a diseñar y construir una app web que rastree la fiabilidad de herramientas internas con SLIs/SLOs, flujo de incidentes, dashboards, alertas e informes.
Antes de elegir métricas o construir dashboards, decide de qué se encargará tu app de fiabilidad y de qué no. Un alcance claro evita que la herramienta se convierta en un “portal de ops” para todo que nadie confíe.
Empieza listando las herramientas internas que cubrirá la app (p. ej., ticketing, nóminas, integraciones CRM, pipelines de datos) y los equipos que las poseen o dependen de ellas. Sé explícito sobre los límites: “sitio web orientado al cliente” puede estar fuera de alcance, mientras que “consola de administración interna” está dentro.
Diferentes organizaciones usan esta palabra de formas distintas. Escribe tu definición operativa en lenguaje claro: típicamente una mezcla de:
Si los equipos no están de acuerdo, tu app acabará comparando peras con manzanas.
Elige 1–3 resultados principales, como:
Esos resultados guiarán qué medir y cómo presentarlo.
Lista quién usará la app y qué decisiones toman: ingenieros investigando incidentes, soporte escalando problemas, managers revisando tendencias y stakeholders que necesitan actualizaciones de estado. Esto moldeará la terminología, permisos y el nivel de detalle de cada vista.
El seguimiento funciona solo si todos están de acuerdo en qué significa “bien”. Empieza separando tres términos que suenan parecido.
Un SLI (Service Level Indicator) es una medición: “¿qué porcentaje de peticiones tuvo éxito?” o “¿cuánto tardan en cargar las páginas?”
Un SLO (Service Level Objective) es la meta para esa medición: “99.9% de éxito durante 30 días”.
Un SLA (Service Level Agreement) es una promesa con consecuencias, normalmente externa (créditos, penalizaciones). Para herramientas internas, a menudo establecerás SLOs sin SLAs formales—suficiente para alinear expectativas sin convertir la fiabilidad en derecho contractual.
Manténlo comparable entre herramientas y fácil de explicar. Una línea base práctica es:
Evita añadir más hasta poder responder: “¿qué decisión impulsará esta métrica?”
Usa ventanas móviles para que los scorecards se actualicen continuamente:
Tu app debe convertir métricas en acción. Define niveles de severidad (p. ej., Sev1–Sev3) y desencadenantes explícitos como:
Estas definiciones hacen que el alertado, las líneas de tiempo de incidentes y el seguimiento de presupuesto de errores sean consistentes entre equipos.
Una app de seguimiento de fiabilidad solo es tan creíble como sus datos. Antes de construir pipelines de ingestión, mapea cada señal que tratarás como “verdad” y escribe qué pregunta responde (disponibilidad, latencia, errores, impacto de despliegues, respuesta a incidentes).
La mayoría de equipos puede cubrir lo básico usando una mezcla de:
Sé explícito sobre qué sistemas son autoritativos. Por ejemplo, tu “SLI de uptime” podría provenir solo de probes sintéticos, no de logs de servidor.
Establece la frecuencia según el caso de uso: dashboards pueden refrescar cada 1–5 minutos, mientras que los scorecards se calculan cada hora o día.
Crea IDs consistentes para herramientas/servicios, entornos (prod/stage) y propietarios. Acordad reglas de naming temprano para que “Payments-API”, “payments_api” y “payments” no sean tres entidades distintas.
Planifica qué conservar y por cuánto tiempo (p. ej., eventos raw 30–90 días, agregados diarios 12–24 meses). Evita ingerir payloads sensibles; guarda solo metadatos necesarios para análisis de fiabilidad (timestamps, códigos de estado, buckets de latencia, etiquetas de incidente).
Tu esquema debe facilitar dos cosas: responder preguntas del día a día (“¿esta herramienta está sana?”) y reconstruir qué pasó durante un incidente (“¿cuándo empezaron los síntomas, quién cambió qué, qué alertas saltaron?”). Empieza con un conjunto pequeño de entidades core y haz explícitas las relaciones.
Una base práctica sería:
Esta estructura soporta dashboards (“tool → estado actual → incidentes recientes”) y drill-downs (“incident → events → checks y métricas relacionadas”).
Añade campos de auditoría donde necesites responsabilidad e historial:
created_by, created_at, updated_atstatus más seguimiento de cambios de estado (en la tabla Event o en una tabla history dedicada)Finalmente, incluye tags flexibles para filtrado e informes (p. ej., equipo, criticidad, sistema, cumplimiento). Una tabla tool_tags (tool_id, key, value) mantiene el etiquetado consistente y facilita rollups y scorecards.
Tu tracker de fiabilidad debería ser “aburrido” en el mejor sentido: fácil de ejecutar, de cambiar y de dar soporte. El stack “correcto” suele ser el que tu equipo puede mantener sin heroicidades.
Elige un framework web mainstream que conozca el equipo—Node/Express, Django o Rails son opciones sólidas. Prioriza:
Si integras con sistemas internos (SSO, ticketing, chat), escoge el ecosistema donde esas integraciones sean más sencillas.
Si quieres acelerar la primera iteración, una plataforma de vibe-coding como Koder.ai puede ser un punto de partida práctico: describes entidades (tools, checks, SLOs, incidents), flujos (alerta → incidente → postmortem) y dashboards en chat, y generas rápidamente un scaffold de app funcional. Koder.ai suele orientar hacia React en frontend y Go + PostgreSQL en backend, lo que encaja con el stack “aburrido y mantenible” que muchos equipos prefieren—y puedes exportar el código si luego migras a un pipeline manual.
Para la mayoría de apps internas, PostgreSQL es la opción por defecto: maneja bien consultas relacionales, consultas temporales y auditoría.
Añade componentes extra solo cuando resuelvan un problema real:
Decide entre:
Estandariza dev/staging/prod y automatiza despliegues (CI/CD) para que los cambios no alteren silenciosamente los números de fiabilidad. Si usas una plataforma (incluyendo Koder.ai), busca separación de entornos, hosting/despliegue y rollback rápido (snapshots) para iterar sin romper el tracker.
Documenta la configuración en un lugar: variables de entorno, secretos y feature flags. Mantén una guía “cómo ejecutar localmente” y un runbook mínimo (qué hacer si la ingestión para, la cola se acumula o la base alcanza límites). Una página corta en /docs suele ser suficiente.
Una app de seguimiento triunfa cuando la gente puede responder en segundos: “¿Estamos bien?” y “¿Qué hago después?” Diseña pantallas alrededor de esas decisiones, con navegación clara de overview → herramienta específica → incidente.
Haz de la página principal un centro de mando compacto. Lidera con un resumen global de salud (p. ej., número de herramientas cumpliendo SLOs, incidentes activos, mayores riesgos actuales), luego muestra incidentes y alertas recientes con badges de estado.
Mantén la vista por defecto tranquila: resalta solo lo que necesita atención. Cada tarjeta debe permitir drill-down directo al servicio o incidente afectado.
Cada página de herramienta debe responder “¿esta herramienta es suficientemente fiable?” y “¿por qué / por qué no?” Incluye:
Diseña gráficas para no expertos: etiqueta unidades, marca umbrales SLO y añade pequeñas explicaciones (tooltips) en vez de controles densos.
Una página de incidente es un registro vivo. Incluye una línea de tiempo (eventos auto-capturados como alerta disparada, reconocida, mitigada), actualizaciones humanas, usuarios impactados y acciones tomadas.
Facilita publicar actualizaciones: una caja de texto, estatus predefinidos (Investigating/Identified/Monitoring/Resolved) y notas internas opcionales. Al cerrar el incidente, la acción “Iniciar postmortem” debería autocompletar hechos desde la línea de tiempo.
Los admins necesitan pantallas sencillas para gestionar tools, checks, objetivos SLO y owners. Optimiza para corrección: valores por defecto sensatos, validación y advertencias cuando los cambios afectan reportes. Añade un rastro visible de “última edición” para que la gente confíe en los números.
Los datos de fiabilidad solo permanecen útiles si la gente confía en ellos. Eso significa vincular cada cambio a una identidad, limitar quién puede hacer ediciones de alto impacto y mantener un historial claro para revisar.
Para una herramienta interna, por defecto usa SSO (SAML) u OAuth/OIDC vía tu IdP (Okta, Azure AD, Google Workspace). Reduce la gestión de contraseñas y automatiza onboarding/offboarding.
Detalles prácticos:
Empieza con roles simples y añade reglas más finas solo cuando haga falta:
Protege acciones que cambian resultados o narrativas de reporte:
Loguea cada edición de SLOs, checks y campos de incidentes con:
Haz los logs de auditoría buscables y visibles desde las páginas relevantes (p. ej., la página de un incidente muestra su historia completa). Esto mantiene las revisiones basadas en hechos y reduce discusiones durante postmortems.
La monitorización es la “capa sensor” de tu app: convierte el comportamiento real en datos confiables. Para herramientas internas, los checks sintéticos son a menudo la vía más rápida porque controlas qué significa “healthy”.
Arranca con un conjunto pequeño de tipos de checks que cubren la mayoría de apps internas:
Mantén las validaciones determinísticas. Si una validación puede fallar por contenido cambiante, generarás ruido y erosionarás la confianza.
Por cada ejecución de check captura:
Almacena datos como eventos de series temporales (una fila por ejecución) o como agregados por intervalo (rollups por minuto con cuentas y p95 de latencia). Los eventos raw son excelentes para depuración; los rollups son mejores para dashboards rápidos. Muchas equipos mantienen ambos: raw por 7–30 días y rollups para reportes a largo plazo.
Un resultado faltante no debe ser automáticamente “down”. Añade un estado unknown para casos como:
Esto evita inflar el downtime y hace las “brechas de monitoreo” visibles como su propio problema operativo.
Usa workers en background (scheduling tipo cron, colas) para ejecutar checks en intervalos fijos (p. ej., 30–60 segundos para herramientas críticas). Implementa timeouts, reintentos con backoff y límites de concurrencia para que el checker no sobrecargue servicios internos. Persiste cada resultado—incluso fallos—para que el dashboard de uptime muestre estado actual y un historial fiable.
Las alertas convierten el seguimiento en acción. El objetivo es simple: notificar a las personas correctas, con el contexto adecuado, en el momento justo—sin inundar a nadie.
Define reglas de alerta que mapeen directamente a tus SLIs/SLOs. Dos patrones prácticos:
Para cada regla, almacena el “por qué” junto al “qué”: qué SLO impacta, la ventana de evaluación y la severidad prevista.
Envía notificaciones por los canales que los equipos ya usan (email, Slack, Microsoft Teams). Cada mensaje debe incluir:
Evita volcar métricas raw. Ofrece un “siguiente paso” corto como “Revisa despliegues recientes” o “Abre logs”.
Implementa:
Aunque sea una herramienta interna, la gente necesita control. Añade escalado manual (botón en la página de alerta/incidente) e integra con tooling de on-call si existe (PagerDuty/Opsgenie) o, al menos, una rotación configurable almacenada en la app.
La gestión de incidentes convierte “vimos una alerta” en una respuesta compartida y trazable. Incorpora esto en la app para que la gente vaya de señal a coordinación sin saltar entre herramientas.
Permite crear un incidente directamente desde una alerta, una página de servicio o una gráfica de uptime. Prefill campos clave (servicio, entorno, fuente de la alerta, primer visto) y asigna un ID único.
Un conjunto por defecto de campos mantiene esto ligero: severidad, impacto en clientes (equipos internos afectados), owner actual y enlaces a la alerta desencadenante.
Usa un ciclo simple que refleje cómo trabajan los equipos:
Cada cambio de estado debe capturar quién lo hizo y cuándo. Añade actualizaciones en la línea de tiempo (notas cortas con timestamp), y soporte para adjuntos y enlaces a runbooks y tickets (p. ej., /runbooks/payments-retries o /tickets/INC-1234). Esto se convierte en el hilo único de “qué pasó y qué hicimos”.
Los postmortems deben ser rápidos de iniciar y consistentes para revisar. Proporciona plantillas con:
Vincula los ítems de acción al incidente, haz seguimiento de su cumplimiento y muestra elementos atrasados en dashboards de equipo. Si soportas “learning reviews”, permite un modo sin culpas que se centre en sistemas y procesos en vez de errores individuales.
El reporting es donde el seguimiento de fiabilidad se vuelve toma de decisiones. Los dashboards ayudan a los operadores; los scorecards ayudan a líderes a entender si las herramientas internas mejoran, qué áreas necesitan inversión y qué significa “bueno”.
Construye una vista consistente por herramienta (y opcionalmente por equipo) que responda rápido:
Cuando sea posible, añade contexto ligero: “SLO fallado por 2 despliegues” o “Mayor downtime por dependencia X”, sin convertir el informe en un review completo del incidente.
Los líderes rara vez quieren “todo”. Añade filtros por equipo, criticidad de la herramienta (Tier 0–3) y ventana temporal. Asegura que la misma herramienta pueda aparecer en múltiples rollups (equipo platform la posee, finanzas la usa).
Proporciona resúmenes semanales y mensuales para compartir fuera de la app:
Mantén la narrativa consistente (“¿Qué cambió desde el periodo anterior?” “¿Dónde estamos sobre presupuesto?”). Si necesitas un primer texto para stakeholders, enlaza a una guía corta como /blog/sli-slo-basics.
Un tracker de fiabilidad se vuelve una fuente de verdad. Trátalo como un sistema productivo: seguro por defecto, resistente a datos erróneos y fácil de recuperar cuando algo falla.
Restringe cada endpoint—incluso los “solo internos”.
Mantén credenciales fuera del código y de logs.
Almacena secretos en un gestor y rótalos. Da a la web app acceso a la base con el mínimo privilegio: roles separados de lectura/escritura, restringe acceso solo a las tablas necesarias y usa credenciales de corta duración cuando sea posible. Encripta en tránsito (TLS) entre navegador↔app y app↔base.
Las métricas de fiabilidad solo sirven si los eventos subyacentes son confiables.
Añade comprobaciones server-side para timestamps (desfase de reloj/zonas), campos obligatorios y claves de idempotencia para deduplicar reintentos. Registra errores de ingestión en una dead-letter queue o tabla de “cuarentena” para que eventos malos no envenenen los dashboards.
Automatiza migraciones de base y pruebas de rollback. Programa backups, restaura y pruébalos periódicamente, y documenta un plan mínimo de recuperación ante desastres (quién, qué, cuánto tiempo).
Por último, haz la propia app de fiabilidad fiable: añade health checks, monitorización básica de lag en colas y latencia DB, y alerta cuando la ingestión cae silenciosamente a cero.
Una app de seguimiento tiene éxito cuando la gente confía y la usa. Trata el primer lanzamiento como un bucle de aprendizaje, no como un "big bang".
Elige 2–3 herramientas internas muy usadas y con owners claros. Implementa un conjunto pequeño de checks (por ejemplo: disponibilidad del homepage, éxito de login y un endpoint API clave) y publica un dashboard que responda: “¿Está arriba? Si no, ¿qué cambió y quién lo posee?”
Mantén el piloto visible pero contenido: un equipo o un pequeño grupo de power users basta para validar el flujo.
En las primeras 1–2 semanas, recopila activamente feedback sobre:
Convierte el feedback en tareas concretas. Un botón “Reporta un problema con esta métrica” en cada gráfica suele sacar las ideas más rápidas.
Añade valor por capas: conecta a tu herramienta de chat para notificaciones, luego a tu herramienta de incidentes para creación automática de tickets, luego a CI/CD para marcas de despliegue. Cada integración debe reducir trabajo manual o acortar el tiempo de diagnóstico—si no, solo añade complejidad.
Si prototipas rápido, considera usar el modo de planificación de Koder.ai para mapear el scope inicial (entidades, roles y flujos) antes de generar la primera build. Es una forma sencilla de mantener el MVP ajustado—y como puedes snapshotear y hacer rollback, iteras en dashboards e ingestión conforme los equipos afinan definiciones.
Antes de desplegar a más equipos, define métricas de éxito como usuarios activos semanales del dashboard, reducción del time-to-detect, menos alertas duplicadas o revisiones SLO consistentes. Publica un roadmap ligero en /blog/reliability-tracking-roadmap y expande herramienta por herramienta con owners claros y sesiones de capacitación.
Comienza por definir el alcance (qué herramientas y entornos se incluyen) y tu definición operativa de fiabilidad (disponibilidad, latencia, errores). Luego elige 1–3 resultados que quieras mejorar (p. ej., detección más rápida, informes más claros) y diseña las primeras pantallas en torno a las decisiones clave que necesitan los usuarios: “¿Estamos bien?” y “¿Qué hago ahora?”
Un SLI es lo que mides (por ejemplo, % de peticiones exitosas, latencia p95). Un SLO es el objetivo para esa medición (por ejemplo, 99.9% en 30 días). Un SLA es una promesa formal con consecuencias (a menudo externa). Para herramientas internas, los SLOs suelen alinear expectativas sin la carga administrativa de los SLA.
Usa un conjunto pequeño y homogéneo que sea comparable entre herramientas:
Añade más métricas solo si puedes decir qué decisión impulsarán (alertas, priorización, trabajo de capacidad, etc.).
Usa ventanas móviles para que los scorecards se actualicen continuamente:
Elige ventanas que coincidan con cómo tu organización revisa el rendimiento para que las cifras sean intuitivas y se usen.
Define desencadenantes explícitos ligados al impacto en usuarios y duración, por ejemplo:
Documenta estas reglas en la app para que alertas, líneas de tiempo de incidentes y reportes sean consistentes entre equipos.
Mapea qué sistema es la “fuente de verdad” para cada pregunta:
Sé explícito (por ejemplo: “el SLI de uptime proviene solo de probes”), de lo contrario los equipos discutirán qué números cuentan.
Usa pull para sistemas que puedas consultar periódicamente (APIs de monitorización, APIs de ticketing). Usa push (webhooks/eventos) para eventos de alto volumen o en tiempo casi real (despliegues, alertas, actualizaciones de incidentes). Una división común es: dashboards se actualizan cada 1–5 minutos, y los scorecards se calculan cada hora o diariamente.
Normalmente necesitas:
Registra cada edición de alto impacto con quién, cuándo, qué cambió (antes/después) y de dónde vino (UI/API/automatización). Combina eso con control de acceso por roles:
Estos guardarraíles evitan cambios silenciosos que minen la confianza en tus cifras de fiabilidad.
Trata los resultados faltantes de checks como un estado desconocido, no como downtime automático. Los datos pueden faltar por:
Hacer visible el estado “desconocido” evita inflar el downtime y pone de manifiesto las brechas de monitorización como un problema operativo propio.
Haz explícitas las relaciones (tool → checks → metrics; incident → events) para que las consultas «resumen → detalle» sigan siendo sencillas.