Cómo construir una app web que rastree el cumplimiento de SLA con precisión

Definir el cumplimiento de SLA y qué vas a construir

El cumplimiento de SLA significa cumplir las promesas medibles en un Service Level Agreement (SLA): un contrato entre proveedor y cliente. La tarea de tu app es responder una pregunta simple con evidencia: ¿Cumplimos lo prometido, para este cliente, durante este periodo?

Conviene separar tres términos relacionados:

• SLI (Service Level Indicator): la medida cruda (por ejemplo, “porcentaje de checks exitosos”, “tiempo hasta la primera respuesta”, o “tiempo hasta restaurar el servicio”).
• SLO (Service Level Objective): un objetivo interno para un SLI (a menudo más estricto que el SLA). Ejemplo: “objetivo de 99.95% de uptime”.
• SLA: el compromiso acordado externamente, normalmente ligado a créditos o penalizaciones. Ejemplo: “99.9% de uptime mensual”.

Métricas comunes de SLA que vas a rastrear

La mayoría de apps de seguimiento de SLA empiezan con un pequeño conjunto de métricas que se mapean a datos operativos reales:

• Disponibilidad / uptime: porcentaje de tiempo en que el servicio está “up” durante el periodo de informe.
• Tiempo de respuesta (soporte): tiempo desde la creación del ticket por el cliente hasta la primera respuesta humana.
• Tiempo de resolución: tiempo desde la creación del incidente/ticket hasta el cierre o la restauración.
• Ventanas de elegibilidad: reglas como “contar solo horario laboral”, “excluir mantenimiento programado” o “medir solo de 08:00 a 18:00 en la zona horaria del cliente”.

Quién usa la app—y por qué

Diferentes usuarios quieren la misma verdad, presentada de forma distinta:

• Ops/SRE: detectar incumplimientos temprano y validar las líneas temporales de incidentes.
• Equipos de soporte: cumplir compromisos de respuesta y resolución por cliente.
• Managers: ver tendencias, riesgos y si los equipos cumplen objetivos de forma consistente.
• Clientes: ver informes transparentes (y a veces una página de estado) que muestren qué pasó.

Qué vas a construir (y qué no)

Este producto trata sobre seguimiento, evidencia e informes: colectar señales, aplicar reglas acordadas y generar resultados aptos para auditoría. No garantiza rendimiento; lo mide—con precisión, consistencia y de forma que puedas defender más tarde.

Requisitos: métricas, reglas y quién necesita qué

Antes de diseñar tablas o escribir código, aclara dolorosamente qué significa “cumplimiento” para tu negocio. La mayoría de los problemas de seguimiento de SLA no son técnicos—son problemas de requisitos.

Reúne las entradas (y no confíes en la memoria)

Empieza por recoger las fuentes de verdad:

• Contratos de clientes y MSAs (incluyendo anexos y adendas de ticketing)
• Niveles de servicio (por ejemplo, Básico vs Premium) y qué clientes pertenecen a cada nivel
• Horario laboral y zonas horarias por cliente (o por servicio)
• Exclusiones y reglas especiales: ventanas de mantenimiento planificado, fuerza mayor, retrasos por el cliente, dependencias de terceros, periodos de gracia

Escribe estas reglas de forma explícita. Si una regla no puede enunciarse claramente, no puede calcularse de forma fiable.

Decide qué debe rastrearse

Lista las “cosas” del mundo real que pueden afectar un número de SLA:

• Incidentes / caídas (inicio, fin, severidad, servicios impactados)
• Solicitudes/tickets (creación, primera respuesta, resolución, pendiente por cliente)
• Mantenimientos (programados vs emergencia; si cuentan contra la disponibilidad)
• Caídas parciales (degradación) y si cuentan o no

También identifica quién necesita qué: soporte quiere riesgo de incumplimiento en tiempo real, managers quieren resúmenes semanales, clientes quieren resúmenes simples (a menudo para una página de estado).

Elige 1–3 métricas para la primera versión

Mantén el alcance pequeño. Elije el conjunto mínimo que demuestre que el sistema funciona de extremo a extremo, por ejemplo:

• % de disponibilidad por servicio por mes
• Tiempo de respuesta de incidentes (primera respuesta humana) dentro de horario laboral
• Tiempo hasta resolución para incidentes de severidad 1

Checklist de requisitos y criterios de éxito

Crea una hoja de una página que puedas probar más tarde:

• Definiciones claras de métricas (timestamps de inicio/fin, zona horaria, redondeo)
• Reglas de inclusión/exclusión (mantenimiento, espera por cliente)
• Umbrales por nivel (p. ej., 99.9%, respuesta en 1 hora)
• Requisitos de salida (informe al cliente, dashboard interno, exportación)

Éxito: dos personas calculan manualmente el mismo mes de ejemplo y tu app coincide exactamente.

Modelo de datos para SLAs, servicios, incidentes y eventos

Un rastreador de SLA correcto empieza con un modelo de datos que pueda explicar por qué un número es lo que es. Si no puedes trazar una cifra de disponibilidad mensual hasta los eventos exactos y las reglas usadas, tendrás disputas con clientes e incertidumbre interna.

Entidades principales (mantenlas explícitas y simples)

Como mínimo, modela:

• Customer (tenant/account): posee servicios, calendarios, contactos y preferencias de reporte.
• Service: lo que se mide (API, app web, componente por región). Incluye una relación opcional padre/hijo si vas a agregar múltiples componentes.
• Plan: envoltura comercial (por ejemplo, “Gold”), usado para adjuntar un conjunto por defecto de políticas SLA.
• SLA policy: las reglas medibles: objetivo de uptime, objetivo de tiempo de respuesta, ventana de medición y qué se considera “excluido”.
• Incident: agrupación legible (título, severidad, línea temporal) que referencia los eventos subyacentes.
• Event: los hechos inmutables (cambios de estado, señales de monitorización, reconocimientos) que impulsan los cálculos.

Una relación útil: customer → service → SLA policy (posiblemente vía plan). Incidentes y eventos referencian el servicio y el cliente.

Esquema mínimo para seguimiento basado en tiempo

Los errores temporales son la causa #1 de mala aritmética SLA. Almacena:

• occurred_at como UTC (timestamp con semántica de zona horaria)
• received_at (cuando tu sistema lo vio)
• source (nombre del monitor, integración, manual)
• external_id (para deduplicar reintentos)
• payload (JSON bruto para depuración futura)

También guarda customer.timezone (cadena IANA como America/New_York) para mostrar y para la lógica de “horario laboral”, pero no la uses para reescribir el tiempo del evento.

Horario laboral y festivos

Si los SLA de tiempo de respuesta se pausan fuera del horario laboral, modela calendarios explícitos:

• working_hours por cliente (o por región/servicio): día de la semana + hora inicio/fin
• holiday_calendar ligado a una región o cliente, con rangos de fechas y etiquetas

Mantén las reglas dirigidas por datos para que ops puedan actualizar un festivo sin desplegar código.

Auditabilidad: crudo vs calculado

Almacena eventos crudos en una tabla append-only y guarda resultados calculados por separado (p. ej., sla_period_result). Cada fila de resultado debe incluir: límites del periodo, versión de entradas (versión de la política + versión del motor), y referencias a los IDs de eventos usados. Esto hace que la recomputación sea segura y te da una traza de auditoría cuando los clientes preguntan “¿Qué minutos de caída contaste?”.

Ingesta de eventos: cómo entran los datos en tu app

Los números SLA son tan confiables como los eventos que ingieres. El objetivo es simple: capturar cada cambio que importe (inicio de caída, incidente reconocido, servicio restaurado) con timestamps consistentes y contexto suficiente para calcular cumplimiento más tarde.

Fuentes comunes de eventos

La mayoría de equipos acaban tirando de una mezcla de sistemas:

• Herramientas de ticketing/incidentes (Jira Service Management, ServiceNow, Zendesk): timestamps de creado/reconocido/resuelto, cambios de prioridad, cambios de asignado.
• Herramientas de monitorización (Pingdom, Datadog, CloudWatch, Prometheus Alertmanager): señales up/down, alert fired/cleared, resultados sintéticos.
• Logs de infraestructura y aplicación: eventos de deploy, picos de error, fallos de health check (útiles cuando la monitorización es ruidosa o falta).
• Entradas manuales: una UI pequeña para “inicio/fin de caída verificada por negocio” o “mantenimiento iniciado” cuando la automatización no sabe la verdad.

Opciones de ingesta (y cuándo usarlas)

Webhooks suelen ser lo mejor para precisión en tiempo real y menor carga: el sistema origen empuja eventos a tu endpoint.

Polling es un buen respaldo cuando no hay webhooks: tu app busca periódicamente cambios desde el último cursor. Necesitarás manejo de rate limits y lógica cuidadosa de “since”.

Importación CSV ayuda con backfills y migraciones. Trátala como camino de ingesta de primera clase para poder reprocesar periodos históricos sin hacks.

Un formato de evento recomendado (con idempotencia)

Normaliza todo en una única forma interna de “evento”, incluso si los payloads upstream difieren:

• event_id (required): único y estable ante reintentos. Prefiere el GUID del origen; si no, genera un hash determinístico.
• source (required): p. ej., datadog, servicenow, manual.
• event_type (required): p. ej., incident_opened, incident_acknowledged, service_down, service_up.
• occurred_at (required): el momento en que ocurrió el evento (no cuando lo recibiste), con zona horaria.
• received_at (system): cuando tu app lo ingirió.
• service_id (required): el servicio relevante para el SLA que afecta.
• incident_id (opcional pero recomendado): enlaza múltiples eventos a un incidente.
• attributes (opcional): prioridad, región, segmento de cliente, etc.

Guarda event_id con una restricción única para hacer la ingesta idempotente: los reintentos no crearán duplicados.

Reglas de validación que previenen datos malos

Rechaza o cuarentena eventos que:

• Tengan timestamps faltantes/invalidos, o occurred_at muy en el futuro.
• No se mapeen a un service_id conocido (o requieran un flujo explícito “unmapped”).
• Dupliquen un event_id existente.
• Lleguen fuera de orden de forma que rompan tus reglas (mantenlos, pero márcalos como “necesita revisión” en vez de sobrescribir en silencio).

Esta disciplina al inicio te ahorra discutir informes SLA después—porque podrás apuntar a entradas limpias y trazables.

Motor de cálculo de SLA: convertir eventos en cumplimiento

Tu motor de cálculo es donde los “eventos crudos” se convierten en resultados de SLA defendibles. La clave es tratarlo como contabilidad: reglas deterministas, entradas claras y un rastro reproducible.

Empieza con una línea temporal normalizada

Convierte todo en un único flujo ordenado por incidente (o por impacto de servicio):

• timestamps (UTC) para: incidente iniciado, reconocido/primera respuesta, mitigado, resuelto, reabierto
• cambios de estado: pausado/despausado, esperando al cliente, ventana de mantenimiento activa
• alcance: qué servicio(s) y cliente(s) están impactados, y con qué severidad

Desde esta línea temporal, calcula duraciones sumando intervalos, no restando dos timestamps a ciegas.

Time-to-first-response (TTFR) y time-to-resolution (TTR)

Define TTFR como el tiempo transcurrido “cobrable” entre incident_start y first_agent_response (o acknowledged, según el texto del SLA). Define TTR como el tiempo transcurrido “cobrable” entre incident_start y resolved.

“Cobrable” significa quitar intervalos que no deben contarse:

• fuera del horario laboral (para SLAs que aplican solo en horario laboral)
• pausas explícitas (p. ej., “esperando al cliente”)
• exclusiones como mantenimiento programado o retrasos por el cliente

Detalle de implementación: almacena una función calendario (horario laboral, festivos) y una función de reglas que tome una línea temporal y devuelva intervalos facturables.

Caídas parciales e incidentes multi-servicio

Decide desde el inicio si calculas:

• SLAs por servicio (recomendado): un incidente puede producir múltiples registros de impacto por servicio, cada uno con su TTFR/TTR
• SLAs por cliente: la misma caída puede afectar solo a un subconjunto de tenants

Para caídas parciales, pondera por impacto solo si el contrato del SLA lo requiere; de lo contrario trata “degradado” como una categoría de incumplimiento separada.

Trazabilidad: guarda entradas, salidas y replays

Cada cálculo debe ser reproducible. Persiste:

• los eventos exactos usados (con ids, timestamps y origen)
• los intervalos derivados (qué se excluyó y por qué)
• los resultados finales (TTFR, TTR, banderas de incumplimiento y versión de la regla)

Cuando las reglas cambien, podrás volver a ejecutar cálculos por versión sin reescribir la historia—crucial para auditorías y disputas con clientes.

Lógica de informes: periodos, disponibilidad y casos límite

Los informes son donde el seguimiento de SLA gana o pierde confianza. Tu app debe dejar claro qué rango temporal se mide, qué minutos cuentan y cómo se derivaron los números finales.

Periodos: calendario, facturación y ventanas rolling

Da soporte a los periodos de informe que los clientes realmente usan:

• Mensual/trimestral calendario (p. ej., 1–31 de marzo)
• Ciclos de facturación (p. ej., 15→14, alineados a facturas)
• Ventanas rolling (p. ej., “últimos 30 días” actualizado diariamente)

Almacena periodos como timestamps explícitos de inicio/fin (no “mes = 3”) para poder reproducir cálculos después.

Disponibilidad: minutos totales vs minutos elegibles

Una fuente frecuente de confusión es si el denominador es todo el periodo o solo el tiempo “elegible”.

Define dos valores por periodo:

• Minutos elegibles: minutos que cuentan para el SLA (a menudo excluyen mantenimiento programado, caídas por el cliente o tiempos fuera del soporte)
• Minutos de downtime: minutos elegibles en los que el servicio se considera caído

Luego calcula:

availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes

Si minutos elegibles puede ser cero (p. ej., un servicio monitoreado solo en horario laboral y el periodo no contiene ninguno), define la regla por adelantado: “N/A” o tratarlo como 100%—pero sé consistente y documenta.

Convertir números en un claro aprobado/fallido

La mayoría de SLAs necesitan tanto un porcentaje como un resultado binario.

• Porcentaje: p. ej., 99.95% para el periodo
• Aprobado/Fallido: compara con el objetivo SLA (p. ej., aprobado si ≥ 99.9%)

También conserva la “distancia al incumplimiento” (presupuesto de downtime restante) para que los dashboards puedan avisar antes de cruzar el umbral.

Casos límite que debes manejar deliberadamente

• Zonas horarias: elige una zona de reporte por cliente/contrato (a menudo la del cliente) y convierte eventos consistentemente.
• Horario de verano (DST): nunca asumas que un día tiene 1440 minutos. Usa timestamps con conocimiento de zona horaria para que la longitud del periodo sea correcta en transiciones DST.
• Falta de timestamp de fin: los incidentes a veces carecen de resolved timestamp. Trátalos como “abiertos” y hazles un tope al final del periodo del informe, marcando el registro para limpieza.

Finalmente, conserva los inputs crudos (eventos incluidos/excluidos y ajustes) para que cada informe pueda responder “¿por qué es este número?” sin rodeos.

Interfaz y dashboards que hacen obvio el estado del SLA

Tu motor de cálculo puede ser perfecto y aún así fallar a los usuarios si la UI no responde la pregunta básica: “¿Estamos cumpliendo el SLA ahora y por qué?” Diseña la app para que cada pantalla empiece con un estado claro y luego permita profundizar en los números y en los eventos crudos que los generaron.

Vistas principales a construir

Dashboard overview (para operadores y managers). Lidera con un conjunto pequeño de tiles: cumplimiento del periodo actual, disponibilidad, cumplimiento de tiempos de respuesta y “tiempo restante antes del incumplimiento” cuando aplique. Usa etiquetas explícitas (p. ej., “Disponibilidad (este mes)” en vez de “Uptime”). Si soportas múltiples SLAs por cliente, muestra primero el peor estado y permite expandir.

Detalle del cliente (para equipos de cuentas y reportes al cliente). Una página de cliente debe resumir todos los servicios y niveles SLA para ese cliente, con un estado simple aprobado/advertencia/fallido y una explicación corta (“2 incidentes contados; 18m de downtime contados”). Añade enlaces a /status (si proporcionas una página de estado para clientes) y a la exportación del informe.

Detalle del servicio (para investigación profunda). Aquí muestra las reglas SLA exactas, la ventana de cálculo y un desglose de cómo se formó el número de cumplimiento. Incluye un gráfico de disponibilidad a lo largo del tiempo y una lista de incidentes que contaron para el SLA.

Línea temporal del incidente (para auditorías). Una vista de un solo incidente debe mostrar una línea temporal de eventos (detectado, reconocido, mitigado, resuelto) y qué timestamps se usaron para las métricas de “respuesta” y “resolución”.

Filtros que responden preguntas reales

Haz los filtros consistentes en todas las pantallas: rango de fechas, cliente, servicio, nivel y severidad. Usa las mismas unidades en todas partes (minutos vs segundos; porcentajes con los mismos decimales). Cuando los usuarios cambien el rango, actualiza todas las métricas de la página para evitar desajustes.

Drill-down sin perder confianza

Cada métrica resumen debe tener una ruta “¿Por qué?”:

• De un porcentaje de cumplimiento → lista de incidentes contados en ese periodo.
• De un incidente → eventos crudos y los timestamps derivados usados en cálculos.
• De disponibilidad → intervalos de downtime con fuentes (evento de monitorización vs ajuste manual).

Usa tooltips con moderación para definir términos como “Downtime excluido” u “Horario laboral”, y muestra el texto exacto de la regla en la página de servicio para evitar conjeturas.

Manténlo simple pero inequívoco

Prefiere lenguaje claro sobre abreviaturas (“Tiempo de respuesta” en vez de “MTTA” a menos que la audiencia lo espere). Para el estado, combina color con etiquetas textuales (“En riesgo: 92% del presupuesto de errores usado”) para evitar ambigüedad. Si la app soporta logs de auditoría, añade una caja pequeña “Último cambio” en las reglas SLA y en exclusiones enlazando a /settings/audit-log para que los usuarios verifiquen cuándo cambiaron las definiciones.

Alertas y notificaciones por incumplimientos

Las alertas son donde tu app de seguimiento SLA deja de ser un informe pasivo y empieza a ayudar a equipos a evitar penalizaciones. Las mejores alertas son oportunas, específicas y accionables—es decir, dicen a alguien qué hacer después, no solo que algo está “mal”.

Define disparadores que encajen con decisiones reales

Empieza con tres tipos de disparadores:

• Cercano a incumplimiento: p. ej., “Te quedan 30 minutos para cumplir el SLA de tiempo de respuesta”, o “La disponibilidad de este mes ha caído a 99.92% y el SLA es 99.9%.” Este es el aviso más valioso porque permite recuperación.
• Incumplimiento ocurrido: se dispara cuando el motor confirma que no se cumplió el SLA para la ventana relevante.
• Violaciones repetidas: detecta patrones como “3 incumplimientos en 30 días” o “mismo servicio incumplió dos veces esta semana”, que suelen indicar un problema sistémico.

Haz los disparadores configurables por cliente/servicio/SLA, ya que distintos contratos toleran umbrales distintos.

Elige canales y mantén los mensajes accionables

Envía alertas donde la gente realmente responde:

• Email para notificaciones aptas para auditoría y stakeholders externos.
• Slack para coordinación interna rápida.
• SMS (opcional) para escalaciones de alta severidad.

Cada alerta debe incluir enlaces profundos como /alerts, /customers/{id}, /services/{id}, y la página de detalle del incidente o evento para que los respondedores puedan verificar números rápidamente.

Reduce el ruido: deduplicación, horarios de silencio y escalado

Aplica deduplicación agrupando alertas con la misma clave (cliente + servicio + SLA + periodo) y suprimiendo repeticiones durante una ventana de cooldown.

Añade horarios de silencio por zona horaria del equipo para que alertas no críticas de “cercano a incumplimiento” esperen a horario laboral, mientras que “incumplimiento ocurrido” puede saltarse el silencio si la severidad es alta.

Finalmente, soporta reglas de escalado (p. ej., notificar al on-call tras 10 minutos, escalar a un manager tras 30) para evitar que alertas se queden atascadas en un buzón.

Control de acceso, autenticación y registros de auditoría

Los datos de SLA son sensibles porque exponen rendimiento interno y entitlements específicos de clientes. Trata el control de acceso como parte de la “aritmética” SLA: el mismo incidente puede producir distintos resultados según qué SLA se aplique.

Roles que soportar desde el día uno

Mantén roles simples y luego afina permisos.

• Admin: configura ajustes globales, gestiona servicios, SLAs, usuarios, integraciones y elementos de facturación.
• Agent: crea/actualiza incidentes y ventanas de mantenimiento, adjunta eventos y añade notas postmortem.
• Manager: lee todo dentro de su alcance, aprueba definiciones SLA y exporta informes.
• Customer viewer: ve solo sus propios servicios, objetivos SLA, historial de incidentes e informes orientados al cliente.

Un default práctico es RBAC + scoping por tenant:

• Cada registro (servicio, política SLA, informe) tiene un tenant/cliente propietario.
• Usuarios internos pueden tener alcance en múltiples tenants; espectadores de cliente en exactamente uno.
• Permisos de edición más restrictivos que los de lectura: p. ej., agents pueden editar incidentes pero no cambiar reglas SLA.

Qué puede ver/editar cada rol

Sé explícito con datos por cliente:

• Los customer viewers nunca deben ver campos internos (hipótesis de causa raíz, severidad interna, notas on-call, tags privados).
• Las políticas SLA deben versionarse para que un cliente pueda ver los términos del SLA que aplicaban en el momento de un incidente.

Opciones de autenticación que no te encasillan

Empieza con email/contraseña y exige MFA para roles internos. Planea SSO (SAML/OIDC) separando identidad (quién es) de autorización (qué puede acceder). Para integraciones, emite API keys ligadas a una cuenta de servicio con ámbitos estrechos y soporte de rotación.

Logs de auditoría que agradecerás

Añade entradas inmutables para:

• Cambios en reglas SLA (umbrales, calendarios, exclusiones, mapeos a servicios/clientes)
• Ediciones de incidentes (timestamps, transiciones de estado, overrides manuales de downtime)
• Cambios en permisos y API keys

Almacena quién, qué cambió (antes/después), cuándo, dónde (IP/user agent) y un ID de correlación. Haz los logs buscables y exportables (p. ej., /settings/audit-log).

Diseño de API para integraciones y automatización

Una app de seguimiento SLA raramente es una isla. Querrás una API que permita a herramientas de monitorización, sistemas de ticketing y flujos internos crear incidentes, enviar eventos y extraer informes sin trabajo manual.

Empieza con una superficie pequeña y predecible

Usa un path versionado (por ejemplo, /api/v1/...) para poder evolucionar payloads sin romper integraciones existentes.

Endpoints esenciales:

• Events: POST /api/v1/events para ingerir cambios de estado (up/down, muestras de latencia, ventanas de mantenimiento). GET /api/v1/events para auditorías y depuración.
• Incidents: POST /api/v1/incidents, PATCH /api/v1/incidents/{id} (acknowledge, resolve, assign), GET /api/v1/incidents.
• SLAs: GET /api/v1/slas, POST /api/v1/slas, PUT /api/v1/slas/{id} para gestionar contratos y umbrales.
• Reports: GET /api/v1/reports/sla?service_id=...&from=...&to=... para resúmenes de cumplimiento.
• Alerts: POST /api/v1/alerts/subscriptions para gestionar webhooks/targets de email; GET /api/v1/alerts para historial de alertas.

Haz consistente paginación y filtrado

Elige una convención y úsala en todos lados. Por ejemplo: limit, paginación por cursor, más filtros estándar como service_id, sla_id, status, from, to. Mantén el orden predecible (p. ej., sort=-created_at).

Define respuestas de error en las que los integradores puedan confiar

Devuelve errores estructurados con campos estables:

{ "error": { "code": "VALIDATION_ERROR", "message": "service_id is required", "fields": { "service_id": "missing" } } }

Usa códigos HTTP claros (400 validación, 401/403 auth, 404 not found, 409 conflict, 429 rate limit). Para ingesta de eventos, considera idempotencia (Idempotency-Key) para que los reintentos no dupliquen incidentes.

Límites de tasa y seguridad básica

Aplica rate limits razonables por token (y más estrictos para endpoints de ingesta), sanitiza inputs y valida timestamps/zona horaria. Prefiere tokens API con ámbitos (solo lectura vs escritura de incidentes), y registra quién llamó a qué endpoint para trazabilidad (detalles en tu sección de auditoría en /blog/audit-logs).

Estrategia de pruebas: demostrar que los números son correctos

Los números SLA solo sirven si la gente confía en ellos. Las pruebas para una app de seguimiento SLA deben centrarse menos en “¿carga la página?” y más en “¿la aritmética temporal se comporta exactamente como dice el contrato?” Trata tus reglas de cálculo como una característica del producto con su propio suite de tests.

Test unitarios de reglas con líneas temporales fijas

Empieza testeando unitariamente tu motor con entradas deterministas: una línea temporal de eventos (incidente abierto, reconocido, mitigado, resuelto) y un conjunto de reglas SLA claramente definido.

Usa timestamps fijos y “freeze time” para que las pruebas no dependan del reloj. Cubre casos límite que suelen romper los informes SLA:

• Incidente que empieza antes del periodo y termina dentro
• Incidentes solapados (¿el downtime se mergea o se apila?)
• Múltiples pausas (mantenimientos, espera por cliente)
• Minutos/segundos límite (exactamente a las 00:00, fin de mes, día bisiesto)

Tests end-to-end para todo el pipeline

Añade un pequeño conjunto de pruebas E2E que ejecuten el flujo completo: ingerir eventos → calcular cumplimiento → generar informe → renderizar UI. Estas detectan desajustes entre “lo que el motor calculó” y “lo que muestra el dashboard.” Mantén los escenarios pocos pero de alto valor y aserta en números finales (%, incumplimiento sí/no, tiempo hasta ack).

Construye fixtures reutilizables para calendarios y zonas horarias

Crea fixtures para horario laboral, festivos y zonas horarias. Quieres casos repetibles como “incidente ocurre viernes 17:55 hora local” y “un festivo desplaza el conteo del tiempo de respuesta.”

Monitoriza la propia app de SLA

Las pruebas no terminan al desplegar. Añade monitorización para fallos de jobs, tamaño de cola/backlog, duración de recalculación y tasas de error. Si la ingesta se atrasa o un job nocturno falla, tu informe SLA puede estar mal aunque el código sea correcto.

Despliegue, operaciones y una hoja de ruta práctica para el MVP

Lanzar una app de seguimiento SLA tiene menos que ver con infraestructura sofisticada y más con operaciones predecibles: tus cálculos deben correr a tiempo, los datos deben estar seguros y los informes reproducibles.

Camino de despliegue simple y fiable

Empieza con servicios gestionados para poder centrarte en la corrección:

• Base de datos gestionada (PostgreSQL): backups automáticos, point-in-time recovery, cifrado.
• Hosting de contenedores para web/API (p. ej., plataforma de contenedores gestionada): rollbacks fáciles y entornos consistentes.
• Almacenamiento de objetos para exportaciones (CSV/PDF) y artefactos grandes, con reglas de ciclo de vida.

Mantén entornos mínimos: dev → staging → prod, cada uno con su propia BD y secretos.

Jobs en background que necesitarás desde el día uno

El seguimiento SLA no es puramente request/response; depende de trabajo programado.

• Jobs de cálculo: recomputar ventanas SLA a partir de nuevos eventos y re-ejecutar tras datos tardíos.
• Generación de informes: resúmenes diarios/mensuales, exportes listos para el cliente.
• Higiene de datos: archivar eventos crudos viejos, compactar tablas derivadas, verificar integridad referencial.

Ejecuta jobs vía un proceso worker + cola o un scheduler gestionado invocando endpoints internos. Haz los jobs idempotentes (seguros de reintentar) y registra cada ejecución para auditoría.

Retención y exportaciones (sin prometer de más)

Define retención por tipo de dato: conserva resultados derivados más tiempo que las corrientes de eventos crudos. Para exportes, ofrece CSV primero (rápido, transparente) y luego plantillas PDF. Sé claro: las exportaciones son "mejor esfuerzo" en formato, mientras que la base de datos es la fuente de la verdad.

Hoja de ruta por fases para mantener el scope bajo control

1. MVP: un servicio, un SLA, una zona horaria, dashboard básico + informe mensual.
2. Más métricas: SLAs de tiempo de respuesta, ventanas de mantenimiento, exclusiones, múltiples calendarios.
3. Portal de clientes: vistas por cliente, control de acceso, informes descargables.
4. Página de estado: páginas públicas/privadas respaldadas por tu disponibilidad calculada (ver /blog/status-pages).

Prototipado rápido con Koder.ai (opcional)

Si quieres validar modelo de datos, flujo de ingesta y UI de informes rápidamente, una plataforma de vibe-coding como Koder.ai puede ayudarte a llegar a un prototipo end-to-end sin comprometerte con un ciclo completo de ingeniería. Porque Koder.ai genera aplicaciones completas vía chat (UI web + backend), es práctico para montar:

• un dashboard React para cumplimiento, presupuestos de error y líneas temporales de drill-down,
• un backend Go + PostgreSQL para almacenar eventos crudos y resultados por periodo,
• endpoints de exportación/informe y vistas sencillas para el portal de cliente.

Una vez que los requisitos y cálculos estén probados (la parte dura), puedes iterar, exportar el código fuente y pasar a un flujo de build-and-operate más tradicional—manteniendo funcionalidades como snapshots y rollback durante la iteración rápida.