Presupuestos de error para equipos pequeños: SLOs realistas y rituales

Por qué los equipos pequeños necesitan presupuestos de error desde el principio

Los equipos pequeños lanzan rápido porque tienen que hacerlo. El riesgo normalmente no es un apagón dramático. Es el mismo fallo pequeño que se repite: un registro inestable, un pago que a veces falla, un despliegue que en ocasiones rompe una pantalla. Cada uno roba horas, erosiona la confianza y convierte los lanzamientos en una moneda al aire.

Los presupuestos de error dan a los equipos pequeños una manera simple de moverse rápido sin fingir que la fiabilidad "simplemente sucederá".

Un SLO (objetivo de nivel de servicio) es una promesa clara sobre la experiencia del usuario, expresada como un número durante una ventana de tiempo. Ejemplo: “Los checkouts exitosos son al menos 99.5% en los últimos 7 días.” El presupuesto de error es la cantidad permitida de “malo” dentro de esa promesa. Si tu SLO es 99.5%, tu presupuesto semanal es 0.5% de checkouts fallidos.

No se trata de perfección ni de teatro de uptime. No es un proceso pesado, reuniones interminables o una hoja de cálculo que nadie actualiza. Es una manera de ponerse de acuerdo sobre qué significa “lo bastante bueno”, notar cuando te estás desviando y tomar una decisión calmada sobre qué hacer a continuación.

Comienza pequeño: elige 1 a 3 SLOs orientados al usuario vinculados a tus recorridos más importantes, mídelo con señales que ya tengas (errores, latencia, pagos fallidos) y haz una revisión semanal corta donde mires el consumo del presupuesto y elijas una acción de seguimiento. El hábito importa más que las herramientas.

SLOs, SLIs y presupuestos de error en palabras sencillas

Piensa en la fiabilidad como un plan de dieta. No necesitas días perfectos. Necesitas un objetivo, una forma de medirlo y una tolerancia para la vida real.

Un SLI (indicador de nivel de servicio) es el número que vigilas, como “% de solicitudes que tienen éxito” o “p95 de carga de página por debajo de 2 segundos”. Un SLO es la meta para ese número, como “99.9% de las solicitudes tienen éxito”. El presupuesto de error es cuánto puedes fallar el SLO y seguir en el buen camino.

Ejemplo: si tu SLO es 99.9% de disponibilidad, tu presupuesto es 0.1% de tiempo de inactividad. En una semana (10.080 minutos), 0.1% son unos 10 minutos. Eso no significa que debas intentar “usar” esos 10 minutos. Significa que cuando los gastas, estás conscientemente intercambiando fiabilidad por velocidad, experimentos o trabajo de nuevas funciones.

Ese es el valor: convierte la fiabilidad en una herramienta de decisión, no en un ejercicio de reporte. Si has quemado la mayor parte del presupuesto el miércoles, pausas cambios riesgosos y arreglas lo que está fallando. Si apenas gastas, puedes lanzar con más confianza.

No todo necesita el mismo SLO. Una app pública orientada al cliente puede necesitar 99.9%. Una herramienta interna de administración suele poder ser más laxa porque menos gente lo nota y el impacto es menor.

Elige qué proteger: los pocos recorridos que los usuarios notan

No empieces midiendo todo. Empieza protegiendo los momentos donde un usuario decide si tu producto funciona o no.

Elige 1 a 3 recorridos de usuario que carguen la mayor parte de la confianza. Si esos están sólidos, la mayoría de los demás problemas se sienten menores. Buenos candidatos son el primer contacto (registro o inicio), el momento del dinero (checkout o upgrade) y la acción principal (publicar, crear, enviar, subir o una llamada API crítica).

Escribe qué significa “éxito” en términos sencillos. Evita lenguaje técnico como “200 OK” a menos que tus usuarios sean desarrolladores.

Algunos ejemplos que puedes adaptar:

• Registro: el usuario envía el formulario y entra en la app en X segundos, sin ver un error.
• Checkout: el pago se completa, aparece la pantalla de confirmación y el usuario no es cobrado dos veces.
• Publicar / Ejecutar job / Llamada API: la acción termina y el usuario ve el resultado esperado.

Elige una ventana de medición que coincida con la velocidad a la que cambias cosas. Una ventana de 7 días funciona cuando lanzas a diario y quieres retroalimentación rápida. Una de 28 días es más tranquila si los lanzamientos son menos frecuentes o tus datos son ruidosos.

Los productos tempranos tienen limitaciones: el tráfico puede ser bajo (un mal despliegue distorsiona los números), los flujos cambian rápido y la telemetría suele ser escasa. Está bien. Empieza con conteos sencillos (intentos vs éxitos). Afina las definiciones cuando el recorrido deje de cambiar.

Establece SLOs realistas para un producto temprano

Empieza con lo que lanzas hoy, no con lo que desearías tener. Durante una o dos semanas, captura una línea base para cada recorrido clave: con qué frecuencia tiene éxito y con qué frecuencia falla. Usa tráfico real si lo tienes. Si no, usa tus propias pruebas más tickets de soporte y logs. Estás construyendo una imagen aproximada de lo “normal”.

Tu primer SLO debe ser algo que puedas alcanzar la mayoría de las semanas mientras sigues lanzando. Si tu tasa de éxito base es 98.5%, no pongas 99.9% y esperes. Pon 98% o 98.5% y ajústalo después.

La latencia es tentadora, pero puede distraer al principio. Muchos equipos obtienen más valor de un SLO de tasa de éxito primero (las solicitudes completan sin errores). Añade latencia cuando los usuarios la noten claramente y tengas datos lo suficientemente estables para que los números tengan sentido.

Un formato útil es una línea por recorrido: quién, qué, objetivo y ventana de tiempo.

• Nuevos usuarios que se registran: 98.5% de los intentos de registro tienen éxito en una ventana móvil de 7 días.
• Usuarios que pagan en el checkout: 99.0% de los pagos se completan en una ventana móvil de 30 días.
• Usuarios activos cargando la página principal: 99.0% de las cargas de página tienen éxito en una ventana móvil de 7 días.

Mantén la ventana más larga para momentos de dinero y confianza (facturación, autenticación). Mantenla más corta para flujos cotidianos. Cuando puedas cumplir el SLO con facilidad, súbelo un poco y sigue avanzando.

Decide qué incidentes importan y qué ignorar

Los equipos pequeños pierden mucho tiempo de fiabilidad cuando cada contratiempo se convierte en un simulacro de incendio. La meta es simple: el dolor visible para el usuario consume presupuesto; todo lo demás se trata como trabajo normal.

Un conjunto reducido de tipos de incidentes es suficiente: caída total, caída parcial (un flujo clave deja de funcionar), degradación de rendimiento (funciona pero está lento), despliegue problemático (un release provoca fallos) y problemas de datos (incorrectos, faltantes, duplicados).

Una escala de severidad que cabe en un post-it

Mantén la escala pequeña y úsala cada vez.

• Sev1: Muchos usuarios bloqueados en un recorrido clave, o los datos están en riesgo. Dejar todo y arreglar.
• Sev2: Algunos usuarios bloqueados, o un recorrido clave es poco fiable. Arreglar hoy o programar para el siguiente día laborable.
• Sev3: Rotura menor o inconveniente interno. Regístralo y seguir adelante.

Decide qué cuenta contra el presupuesto. Trata los fallos visibles para el usuario como gasto: registro o checkout roto, timeouts que siente el usuario, picos de 5xx que detienen recorridos. El mantenimiento planificado no debería contar si se comunicó y la app se comportó como se esperaba durante ese período.

Una regla termina la mayoría de los debates: si un usuario externo real lo notaría y no podría completar un recorrido protegido, cuenta. Si no, no cuenta.

Esa regla también cubre áreas grises comunes: una caída de un tercero cuenta solo si rompe tu recorrido de usuario, las horas de bajo tráfico siguen contando si hay usuarios afectados, y las pruebas internas no cuentan a menos que el dogfooding sea tu uso principal.

Rastrear el consumo del presupuesto con señales ligeras

La meta no es una medición perfecta. Es una señal compartida y repetible que te diga cuándo la fiabilidad se está volviendo cara.

Para cada SLO, elige una fuente de verdad y síguela: un dashboard de monitorización, logs de la app, una comprobación sintética que golpee un endpoint, o una métrica única como checkouts exitosos por minuto. Si luego cambias el método de medición, anota la fecha y trátalo como un reinicio para no comparar peras con manzanas.

Las alertas deben reflejar el consumo del presupuesto, no cada contratiempo. Un pico breve puede ser molesto, pero no debería despertar a nadie si apenas afecta el presupuesto mensual. Un patrón simple funciona bien: alertar en “quemado rápido” (estás en camino de quemar el presupuesto de un mes en un día) y una alerta más suave en “quemado lento” (en camino de gastarlo en una semana).

Mantén un pequeño registro de fiabilidad para no depender de la memoria. Una línea por incidente basta: fecha y duración, impacto en usuarios, causa probable, qué cambiaste y un dueño del seguimiento con fecha límite.

Ejemplo: un equipo de dos personas lanza una nueva API para una app móvil. Su SLO es “99.5% de solicitudes exitosas”, medido desde un contador. Un despliegue malo baja el éxito al 97% durante 20 minutos. Se dispara la alerta de quemado rápido, hacen rollback y el seguimiento es “añadir una comprobación canaria antes de despliegues”.

Un ritual semanal de fiabilidad: 20 minutos, misma hora, mismas notas

No necesitas un proceso grande. Necesitas un hábito pequeño que mantenga la fiabilidad visible sin robar tiempo de construcción. Un chequeo de 20 minutos funciona porque convierte todo en una pregunta: ¿estamos gastando fiabilidad más rápido de lo previsto?

Usa el mismo hueco del calendario cada semana. Mantén una nota compartida que vayas appendiendo (no la reescribas). La consistencia vence al detalle.

Una agenda simple que encaja:

• Mirada al presupuesto: presupuesto restante para cada SLO y la mayor causa de consumo.
• Nuevos incidentes: una línea cada uno (qué pasó, cuándo, impacto usuario).
• Seguimientos: elegir 1–3 acciones que realmente terminaréis.
• Compromisos: asignar dueño y fecha de entrega, y parar a tiempo.

Entre seguimientos y compromisos, decide tu regla de lanzamientos para la semana y mantenla aburrida:

• Normal: lanzar según lo planeado.
• Precavido: lanzar, pero evitar cambios riesgosos en el área afectada.
• Congelado: pausar cambios en un área hasta que el problema principal esté arreglado.

Si tu flujo de registro tuvo dos cortas caídas y quemó la mayor parte de su presupuesto, podrías congelar solo los cambios relacionados con el registro mientras sigues lanzando trabajo no relacionado.

Convertir el presupuesto en decisiones de hoja de ruta sin dramatismo

Un presupuesto de error solo importa si cambia lo que haces la próxima semana. El punto no es el uptime perfecto. Es una forma clara de decidir: ¿lanzamos funciones o pagamos deuda de fiabilidad?

Una política que puedas decir en voz alta:

• Si el presupuesto está sano, sigue lanzando y arregla el peor problema de fiabilidad que ya conoces.
• Si el presupuesto se está quemando rápido, pausa trabajo de funciones no esenciales y pasa la semana reduciendo la principal causa de fallos.
• Si el presupuesto está agotado, trata el trabajo de fiabilidad como la hoja de ruta hasta volver dentro de los límites.

Eso no es castigo. Es un intercambio público para que los usuarios no lo paguen después.

Cuando desaceleres, evita tareas vagas como “mejorar estabilidad”. Elige cambios que alteren el resultado siguiente: añadir un guardarraíl (timeouts, validación de entradas, límites de tasa), mejorar una prueba que habría detectado el error, facilitar el rollback, arreglar la fuente principal de errores o añadir una alerta ligada a un recorrido de usuario.

Mantén el reporte separado de la culpa. Premia los informes rápidos de incidentes, incluso cuando los detalles estén desordenados. El único informe realmente malo es el que llega tarde, cuando nadie recuerda qué cambió.

Trampas comunes en las que caen los equipos pequeños

Una trampa frecuente es fijar un SLO de primera clase desde el día uno (99.99% suena genial) y luego ignorarlo en silencio cuando la realidad aparece. Tu SLO inicial debe ser alcanzable con la gente y herramientas actuales, o se vuelve ruido de fondo.

Otro error es medir lo incorrecto. Equipos miran cinco servicios y un gráfico de base de datos, pero se pierden el recorrido que el usuario realmente siente: registro, checkout o “guardar cambios”. Si no puedes explicar el SLO en una frase desde el punto de vista del usuario, probablemente sea demasiado interno.

La fatiga de alertas agota a la única persona que puede arreglar producción. Si cada pequeño pico pagina a alguien, las páginas se vuelven “normales” y los incendios reales se pierden. Pager sólo por impacto de usuario. Enruta el resto a una revisión diaria.

Un asesino silencioso es el conteo inconsistente. Una semana cuentas una ralentización de dos minutos como incidente, la siguiente no. Entonces el presupuesto se convierte en debate en vez de señal. Escribe las reglas una vez y aplícalas con consistencia.

Guardarraíles que ayudan:

• Empieza con un SLO por recorrido clave, no por componente.
• Establece un SLO que puedas cumplir la mayoría de semanas, y apriétalo luego.
• Pager solo por impacto de usuario.
• Usa una definición simple de incidente y aplícala siempre igual.
• Haz los postmortems sobre “qué permitió que esto pasara”, no “quién lo causó”.

Si un despliegue rompe el login durante 3 minutos, cuéntalo siempre, aunque se arregle rápido. La consistencia es lo que hace útil al presupuesto.

Lista rápida que puedes revisar en 10 minutos

Pon un temporizador de 10 minutos, abre un documento compartido y responde estas cinco preguntas:

• ¿Cuáles son los 1 a 3 recorridos de usuario que no puedes permitir que se rompan?
• Para cada recorrido, ¿puedes escribir una frase de SLO con una ventana de tiempo?
• ¿Está claro qué cuenta como incidente y quién lo registra dentro de 24 horas?
• ¿Miraste los últimos 7 días y elegiste 1–3 seguimientos basados en impacto (no en molestia)?
• Si el presupuesto está bajo, ¿tienes una regla de lanzamiento simple?

Si no puedes medir algo todavía, empieza con un proxy que puedas ver rápido: pagos fallidos, errores 500 o tickets de soporte etiquetados “checkout”. Reemplaza proxies cuando el seguimiento mejore.

Ejemplo: un equipo de dos personas ve tres mensajes “no puedo restablecer contraseña” esta semana. Si el restablecimiento de contraseña es un recorrido protegido, eso es un incidente. Escriben una nota corta (qué pasó, cuántos usuarios, qué hicieron) y eligen un seguimiento: añadir una alerta en fallos de reset o añadir reintento.

Ejemplo: un equipo startup de dos personas usando un presupuesto de error para una funcionalidad

Maya y Jon dirigen una startup de dos personas y lanzan todos los viernes. Se mueven rápido, pero sus primeros usuarios de pago se preocupan por una cosa: ¿pueden crear un proyecto e invitar a un compañero sin que se rompa?

La semana pasada tuvieron un apagón real: “Crear proyecto” falló durante 22 minutos tras una migración defectuosa. También tuvieron tres periodos “lentos pero no muertos” donde la pantalla giró entre 8 y 12 segundos. Los usuarios se quejaron, pero el equipo discutió si la lentitud cuenta como “caída”.

Eligen un recorrido y lo hacen medible:

• SLO del recorrido: Crear proyecto tiene éxito en menos de 3 segundos, el 99% de las veces, por semana.
• Definición de incidente: Si la tasa de éxito baja de 97% por 10+ minutos, o la p95 de latencia supera 5 segundos por 15+ minutos, es un incidente y escriben una nota corta.

El lunes hacen el ritual de 20 minutos. Misma hora, mismo documento. Responden cuatro preguntas: qué pasó, cuánto presupuesto se consumió, qué se repitió y qué único cambio evitaría la repetición.

La compensación queda clara: el apagón más los periodos lentos consumieron la mayor parte del presupuesto semanal. Así que la “gran característica” de la próxima semana se convierte en “añadir un índice a la BD, hacer las migraciones más seguras y alertar sobre fallos de crear-proyecto”.

El resultado no es fiabilidad perfecta. Son menos problemas repetidos, decisiones más claras sí/no y menos carreras nocturnas porque acordaron de antemano qué significa “suficientemente malo”.

Próximos pasos: empieza pequeño y mantén el ciclo corto

Elige un recorrido de usuario y haz una promesa de fiabilidad sencilla sobre él. Los presupuestos de error funcionan mejor cuando son aburridos y repetibles, no perfectos.

Empieza con un SLO y un ritual semanal. Si después de un mes sigue siendo fácil, añade un segundo SLO. Si se vuelve pesado, redúcelo.

Mantén las cuentas simples (semanal o mensual). Mantén la meta realista para donde estás ahora. Escribe una nota de fiabilidad de una página que responda: el SLO y cómo se mide, qué cuenta como incidente, quién está a cargo esta semana, cuándo ocurre el chequeo y qué hacer por defecto cuando el presupuesto se quema demasiado rápido.

Si estás construyendo sobre una plataforma como Koder.ai (koder.ai), puede ayudar a emparejar iteración rápida con hábitos de seguridad, especialmente snapshots y rollback, de modo que “revertir al último estado bueno” siga siendo un movimiento normal y practicado.

Mantén el ciclo corto: un SLO, una nota, un chequeo semanal corto. La meta no es eliminar incidentes. Es notarlos temprano, decidir con calma y proteger las pocas cosas que los usuarios realmente sienten.