SLOs para herramientas internas simplificados: establece objetivos medibles de disponibilidad y latencia, y vincúlalos a alertas que un equipo pequeño pueda mantener sin agotamiento.
Las herramientas internas parecen pequeñas porque la audiencia es reducida. El impacto muchas veces no lo es: si tu dashboard de operaciones está caído, los pedidos se detienen; si tu consola de soporte va lenta, los clientes esperan; si el panel de administración falla, las correcciones se acumulan.
Sin objetivos claros de fiabilidad, cada caída se convierte en debate. Una persona minimiza un fallo de 10 minutos, otra lo trata como crisis. Se pierde tiempo en chats ruidosos, prioridades poco claras y trabajo sorpresa en el peor momento.
Los SLOs arreglan eso estableciendo expectativas sencillas que puedas medir. Responden a dos preguntas prácticas: qué debe funcionar y con qué nivel para que la gente haga su trabajo.
El coste oculto de “lo mantendremos bastante estable” aparece rápido. El trabajo se detiene mientras los equipos esperan a que la herramienta se recupere. Los pings de soporte se multiplican porque nadie sabe qué es normal. Los ingenieros se ven arrastrados a arreglos urgentes en lugar de mejoras planificadas. Los propietarios de producto dejan de confiar en el sistema y piden respaldos manuales. Los problemas pequeños perduran porque nunca cruzan una línea clara.
No necesitas un programa completo de fiabilidad. Un equipo pequeño puede empezar con unas pocas metas centradas en el usuario, como “el inicio de sesión funciona” o “los resultados de búsqueda cargan rápido”, más un conjunto pequeño de alertas ligadas a acciones reales.
Esto aplica sin importar cómo esté construida la herramienta. Si usas AppMaster (appmaster.io) para crear apps internas, elige las acciones de las que depende la gente, mide disponibilidad y tiempos de respuesta, y alerta solo cuando afecte al trabajo.
Estos tres términos suenan parecido, pero son tipos distintos de lenguaje sobre fiabilidad. Confundirlos es una fuente común de malentendidos.
Un SLI (Service Level Indicator) es una medición. Es algo que puedes contar, como “porcentaje de peticiones que tuvieron éxito” o “cuánto tardó la página en cargar”. Si no puedes medirlo de forma fiable, no es un buen SLI.
Un SLO (Service Level Objective) es el objetivo para esa medición. Responde: ¿qué nivel es suficiente para los usuarios la mayor parte del tiempo? Los SLOs te ayudan a decidir qué arreglar primero y qué puede esperar.
Un SLA (Service Level Agreement) es una promesa, normalmente por escrito y con consecuencias. Muchas herramientas internas no necesitan SLAs; necesitan metas claras, no compromisos estilo legal.
Un ejemplo rápido:
Fíjate en lo que falta: “nunca caerse” o “siempre rápida”. Los SLOs no buscan la perfección. Hacen visibles los trade-offs para que un equipo pequeño pueda elegir entre características, trabajo de fiabilidad y evitar esfuerzo innecesario.
Una regla práctica: si alcanzar el objetivo requiere gestas épicas, no es un SLO, es un deseo. Empieza con algo que tu equipo pueda mantener con calma y ajústalo más tarde si los usuarios siguen sufriendo.
Las herramientas internas fallan de formas concretas: el panel de administración carga pero guardar un registro se queda girando; un dashboard de ops se abre pero los gráficos no se actualizan; un portal funciona excepto que el login falla tras una actualización. Obtienes más valor al centrarte en las acciones que la gente usa a diario, no en cada página y botón.
Empieza por nombrar el tipo de herramienta, porque eso sugiere los caminos críticos. Los paneles de administración se tratan de “cambiar algo de forma segura”. Los dashboards de ops son sobre “ver qué está pasando ahora”. Los portales son sobre “entrar, encontrar información y enviar una solicitud”.
Luego escribe los principales recorridos de usuario en lenguaje llano. Un buen conjunto inicial:
Para cada recorrido, define qué cuenta como fallo. Sé estricto y medible: un error 500 es fallo, pero también lo es un timeout, una página que nunca termina de cargar o un formulario que indica éxito mientras faltan datos.
Mantén el alcance pequeño al principio. Elige 1 a 3 recorridos que coincidan con dolor real y riesgo real. Si las páginas en on-call suelen ser “nadie puede iniciar sesión” y “el botón guardar se queda colgado”, empieza con Inicio de sesión y Enviar formulario. Añade Búsqueda más tarde cuando confíes en las mediciones y en las alertas.
Los buenos SLIs son aburridos. Vienen de datos que ya tienes y coinciden con lo que siente el usuario cuando la herramienta funciona o falla. Si necesitas montar una nueva plataforma de monitorización solo para medirlos, elige SLIs más simples.
Empieza con disponibilidad en términos que la gente entienda: ¿puedo abrir la herramienta y finalizar la tarea? Para muchas herramientas internas, dos SLIs cubren la mayor parte del dolor:
Luego añade latencia, pero manténlo estrecho. Elige una o dos pantallas o endpoints que representen la espera de la que se quejan los usuarios, como cargar el dashboard o enviar un formulario. Medirlo todo suele crear ruido y discusiones.
Decide la ventana de medición desde el principio. Un periodo móvil de 30 días es común para herramientas estables; semanal puede funcionar cuando lanzas a menudo y quieres retroalimentación rápida. Sea lo que sea, manténlo para que las tendencias signifiquen algo.
Finalmente, elige una fuente de verdad por SLI y regístrala:
Ejemplo: si tu app interna está construida en AppMaster, puedes medir disponibilidad con un ping sintético al backend, la tasa de éxito a partir de respuestas API y la latencia desde los tiempos de petición del backend. La clave es consistencia, no perfección.
Empieza eligiendo un número de disponibilidad que puedas defender en una mala semana. Para muchas herramientas internas, 99.5% es un buen primer SLO. Suena alto, pero deja margen para trabajo de cambio normal. Saltar directamente a 99.9% suele implicar paginaciones fuera de horario y lanzamientos más lentos.
Para que la disponibilidad tenga sentido, tradúcela a tiempo. Un mes de 30 días tiene unos 43,200 minutos:
Ese tiempo permitido es tu presupuesto de errores. Si lo gastas pronto, pausas cambios arriesgados y te centras en fiabilidad hasta volver a la meta.
Para latencia, evita promedios. Ocultan los momentos lentos que los usuarios recuerdan. Usa un percentil (normalmente p95) y fija un umbral claro ligado a una acción real. Ejemplos: “p95 carga del dashboard por debajo de 2 segundos” o “p95 Guardar completa en menos de 800 ms”.
Una forma sencilla de fijar el primer número es observar una semana de tráfico real y elegir un objetivo ligeramente mejor que hoy pero no fantasioso. Si p95 ya es 1.9 s, un SLO de 2.0 s es seguro y útil. Un SLO de 500 ms solo generará ruido.
Alinea los SLOs con tu capacidad de soporte. Un equipo pequeño debería preferir pocos objetivos alcanzables a muchos estrictos. Si nadie puede responder en una hora, no pongas metas que supongan lo contrario.
Un SLO más estricto suena tranquilizador, pero tiene un precio. Si subes una herramienta de 99.5% a 99.9%, también estás diciendo “aceptamos muchas menos minutos malos”, lo que suele significar más paginaciones y más tiempo en fiabilidad en lugar de nuevas funciones.
La manera más sencilla de hacerlo real es hablar en términos de presupuesto de errores. Con 99.5% mensual puedes “gastar” unas 3.6 horas de inactividad en 30 días. Con 99.9% solo tienes unos 43 minutos. Esa diferencia cambia la frecuencia con la que detendrás trabajo de características para arreglar fiabilidad.
También ayuda adaptar expectativas a cuándo se usa realmente la herramienta. Un objetivo 24/7 es caro si la herramienta solo es crítica de 9 a 18. Puedes tener un SLO para horas laborales (más estricto) y otro laxo fuera de horas (menos paginaciones) para que el equipo pueda dormir.
El mantenimiento planificado no debería contarse como fallo siempre que se comunique y tenga límites. Trátalo como una excepción explícita (ventana de mantenimiento) en lugar de ignorar alertas después.
Escribe lo básico para que todos vean los trade-offs:
Tras 4 a 6 semanas de datos reales, revisa el objetivo. Si nunca gastas presupuesto, el SLO puede ser demasiado holgado. Si lo gastas rápido y las características se estancan, probablemente esté demasiado estricto.
Las alertas no son tus SLOs. Las alertas son la señal de “algo va mal ahora” que protege el SLO. Una regla simple: por cada SLO, crea una alerta que importe, y resiste la tentación de añadir más a menos que puedas demostrar que reducen el tiempo de inactividad.
Un enfoque práctico es alertar por consumo rápido del presupuesto de errores (cómo de rápido lo estás usando) o por un umbral claro que coincida con el dolor del usuario. Si tu SLO de latencia es “p95 < 800 ms”, no pagines por cada pico lento. Pagina solo cuando sea sostenido.
Una división simple que reduce ruido:
Umbrales concretos (ajusta según tu tráfico): si tu SLO de disponibilidad es 99.5% mensual, pagina cuando la disponibilidad cae por debajo de 99% durante 10 minutos (caída clara). Crea un ticket cuando baje de 99.4% durante 6 horas (quemado lento). Para latencia, pagina cuando p95 supere 1.5 s durante 15 minutos; ticket cuando p95 supere 1.0 s durante 2 horas.
Haz explícita la propiedad. Decide quién está de guardia (aunque sea “una persona esta semana”), qué significa reconocer (por ejemplo, en 10 minutos) y cuál es la primera acción. Para un equipo pequeño que ejecuta una app interna en AppMaster, la primera acción podría ser: revisar despliegues recientes, mirar errores de API y luego hacer rollback o redeploy si es necesario.
Tras cada alerta real, haz un pequeño seguimiento: arregla la causa o ajusta la alerta para que pagine menos pero siga captando impacto real en usuarios.
La fatiga por alertas suele empezar con buenas intenciones. Un equipo pequeño añade “solo unas pocas” alertas y luego una más cada semana. Pronto la gente deja de fiarse de las notificaciones y se pierden las verdaderas caídas.
Una trampa grande es alertar por cada pico. Las herramientas internas suelen tener tráfico en ráfagas (procesos de nómina, cierres de mes). Si una alerta salta por un bache de 2 minutos, el equipo aprende a ignorarla. Víncula las alertas a señales de impacto al usuario, no al ruido bruto de métricas.
Otra trampa es creer que “más métricas = más seguridad”. Muchas veces significa más paginaciones. Mantén un conjunto pequeño de señales que los usuarios realmente noten: fallos de login, páginas que cargan muy lento, trabajos clave que no terminan.
Errores que más ruido suelen crear:
Los dashboards siguen siendo útiles, pero deberían ayudarte a diagnosticar tras una alerta, no reemplazarla.
Si no tienes mediciones limpias aún, no finjas que sí. Añade instrumentación básica primero (tasa de éxito, p95 de latencia y una comprobación de “¿puede un usuario completar la tarea?”), luego fija umbrales basados en una o dos semanas de datos reales.
Antes de habilitar alertas, haz un preflight corto. La mayoría de la fatiga por alertas viene de saltarse estas comprobaciones y luego intentar arreglarlo bajo presión.
Lista de comprobación práctica para un equipo pequeño:
Después, asegúrate de que la alerta se pueda actuar realmente. Una alerta que salta cuando nadie está disponible enseña a ignorarla.
Decidid estos detalles operativos antes de la primera paginación:
Si construyes o cambias la herramienta (incluido en AppMaster), vuelve a ejecutar la lista. El código regenerado y los nuevos flujos pueden cambiar latencia y patrones de error, y tus alertas deben seguir el ritmo.
Un equipo de ops de 18 personas usa un dashboard interno todo el día para revisar el estado de pedidos, reenviar notificaciones fallidas y aprobar reembolsos. Si está caído o lento, el trabajo se detiene rápido.
Eligen dos SLOs:
Ahora añaden tres alertas que un equipo pequeño puede manejar:
Lo que importa es lo que ocurra la semana siguiente. Si la alerta de presupuesto se dispara dos veces, el equipo toma una decisión clara: retrasar una nueva función y dedicar dos días a arreglar la causa principal de latencia (por ejemplo, un scan de tabla sin índice). Si construyeron la herramienta en AppMaster, pueden ajustar el modelo de datos, regenerar y redeployar código limpio en lugar de apilar soluciones rápidas.
Los SLOs solo ayudan si permanecen ligados al trabajo real. El truco es tratarlos como un hábito pequeño, no como un programa nuevo.
Usa una cadencia que encaje con un equipo pequeño y clávala a una reunión existente. Un vistazo semanal rápido detecta deriva, y un ajuste mensual es suficiente una vez que tienes datos reales.
Un proceso ligero que funciona:
Mantén las mejoras pequeñas y visibles. Si “páginas lentas los lunes por la mañana” aparece tres veces, haz un cambio concreto (cachear un informe, añadir un índice, programar un job pesado más tarde) y vigila el SLI la semana siguiente.
Usa los SLOs para decir que no, de forma educada y clara. Cuando llegue una petición de baja prioridad, señala el presupuesto de errores actual y pregunta: “¿Esta cambio pone en riesgo nuestro flujo de guardado o aprobación?” Si ya estás gastando presupuesto, la fiabilidad gana. No es bloquear, es priorizar.
Mantén la documentación mínima: una página por herramienta. Incluye las acciones clave, los números de SLO, las pocas alertas ligadas y el responsable. Si la herramienta está en AppMaster, añade dónde ver logs/métricas y quién puede desplegar cambios, y ya está.
La forma más fácil de hacer la fiabilidad real es mantener la primera configuración diminuta. Elige una herramienta interna que cause dolor real cuando falla (transferencias on-call, aprobaciones de pedidos, reembolsos, ediciones de inventario) y fija objetivos alrededor de las pocas acciones que la gente hace cada día.
Una configuración mínima viable que casi todos los equipos pueden copiar:
Cuando eso esté estable, expande despacio: añade otra acción o una herramienta más al mes. Si no puedes decir quién será el responsable de una alerta, no la crees todavía.
Si estás construyendo o reconstruyendo herramientas internas, AppMaster puede facilitar el mantenimiento. Puedes actualizar modelos de datos y lógica de negocio visualmente y regenerar código limpio según cambien las necesidades, lo que ayuda a mantener los SLOs alineados con lo que la herramienta realmente hace hoy.
Prueba a crear una herramienta interna e incorporar SLOs básicos desde el primer día. Tendrás expectativas más claras, menos sorpresas y alertas que tu equipo pequeño pueda mantener.
¿Realmente necesitan SLOs las herramientas internas si sólo las usa un equipo pequeño?SLOs ponen fin a las discusiones sobre fiabilidad al convertir “algo bastante estable” en un objetivo claro y medible. Incluso con 20 usuarios, una caída puede detener pedidos, ralentizar soporte o bloquear aprobaciones, así que las herramientas pequeñas también pueden tener un gran impacto.
¿Qué debemos medir primero para un panel de administración o un dashboard de operaciones interno?Elige unas pocas acciones de usuario que la gente haga a diario y que bloqueen el trabajo cuando fallan. Buenos puntos de inicio: inicio de sesión, carga del dashboard principal con datos recientes, búsqueda/filtrado y envío correcto de formularios de creación/actualización.
¿Cuál es la diferencia entre SLI, SLO y SLA?Un SLI es la métrica que mides (por ejemplo, tasa de éxito o p95 de latencia). Un SLO es el objetivo para esa métrica (por ejemplo, 99.5% de éxito en 30 días). Un SLA es una promesa formal con consecuencias, y la mayoría de las herramientas internas no lo necesitan.
¿Cuál es un SLO de disponibilidad realista para un equipo pequeño?Un buen primer SLO de disponibilidad para muchas herramientas internas es 99.5% mensual, porque es alcanzable sin recurrir a gestas. Si la herramienta es realmente crítica en horario laboral, puedes apretarlo más tarde tras ver datos reales.
¿Cómo traducimos los porcentajes de disponibilidad a tiempo de inactividad comprensible?Traduce el porcentaje de disponibilidad a minutos para que todos entiendan la compensación. En un mes de 30 días, 99.5% permite unos 216 minutos de inactividad, mientras que 99.9% permite unos 43 minutos, lo que a menudo significa más paginaciones y más trabajo de fiabilidad.
¿Cómo debemos fijar SLOs de latencia sin crear ruido?Usa un percentil como p95, no una media, porque las medias ocultan los momentos lentos que los usuarios recuerdan. Fija el objetivo en una acción real (por ejemplo, “p95 carga del dashboard < 2 s en horario laboral”) y elige un umbral que puedas mantener con calma.
¿Qué SLIs son más fáciles de medir sin montar un gran sistema de monitorización?Empieza con métricas del servidor y registros que ya tengas: disponibilidad (alcanzable y respondiendo), tasa de éxito para acciones clave y p95 de latencia para uno o dos endpoints críticos. Añade comprobaciones sintéticas solo para los flujos más importantes para mantener la medición consistente y simple.
¿Cuántas alertas deberíamos configurar para una herramienta interna?Márcate un conjunto pequeño de alertas vinculadas al impacto en el usuario y solo pagina en problemas sostenidos. Una división útil es: una página urgente para “herramienta efectivamente caída” y un ticket no urgente para degradaciones de “quemado lento” que se pueden tratar en horario laboral.
¿Qué causa la fatiga por alertas en herramientas internas y cómo la evitamos?La mayoría de la fatiga por alertas viene de paginar en cada pico o en síntomas como CPU en vez del impacto al usuario (errores, latencia). Mantén pocas alertas, asigna un responsable a cada una y tras cada alerta real arregla la causa o ajusta la alerta para que suene menos pero siga captando problemas reales.
¿Cómo aplicamos SLOs si construimos nuestras herramientas internas en AppMaster?Elige las acciones clave en tu app y mide disponibilidad, tasa de éxito y p95 de latencia para esas acciones usando una fuente de verdad consistente. Si construyes herramientas internas en AppMaster, mantén los objetivos centrados en lo que hacen los usuarios (login, guardar, buscar) y ajusta medidas y alertas tras cambios mayores o regeneraciones para que reflejen el comportamiento actual.
21 ene 2026
8 min
20 ene 20268 min
20 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
