Aprende sobre presupuestos de error para equipos pequeños: fija SLOs realistas para productos tempranos, decide qué incidentes importan y sigue un ritual semanal simple de fiabilidad.
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.
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.
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:
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.
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.
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.
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).
Mantén la escala pequeña y úsala cada vez.
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.
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”.
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:
Entre seguimientos y compromisos, decide tu regla de lanzamientos para la semana y mantenla aburrida:
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.
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:
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ó.
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:
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.
Pon un temporizador de 10 minutos, abre un documento compartido y responde estas cinco preguntas:
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.
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:
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”.
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.
Un SLO es una promesa de fiabilidad sobre la experiencia del usuario, medida en una ventana de tiempo (por ejemplo 7 o 30 días).
Ejemplo: “99.5% de los pagos se completan con éxito en los últimos 7 días.”
Un presupuesto de error es la cantidad permitida de “mala experiencia” dentro de tu SLO.
Si tu SLO es 99.5% de éxito, tu presupuesto es 0.5% de fallos en esa ventana. Cuando quemas el presupuesto demasiado rápido, reduces cambios arriesgados y arreglas las causas.
Empieza con 1–3 recorridos que los usuarios notan inmediatamente:
Si esos son fiables, la mayoría de los demás problemas se sienten menores y es más fácil priorizarlos después.
Elige una línea base que puedas cumplir la mayoría de semanas.
Si hoy estás en 98.5%, empezar en 98–98.5% es más útil que declarar 99.9% y no cumplirlo.
Usa conteos simples: intentos vs éxitos.
Fuentes de datos iniciales útiles:
No esperes a tener observabilidad perfecta; empieza con un proxy fiable y mantenlo consistente.
Cuenta un incidente si un usuario externo lo notaría y no podría completar un recorrido protegido.
Ejemplos que cuentan contra el presupuesto:
No cuentes molestias internas a menos que el uso interno sea el objetivo principal del producto.
Una regla simple: alertar por quemado del presupuesto, no por cada pequeño pico.
Dos tipos de alerta útiles:
Esto reduce la fatiga de alertas y centra la atención en lo que realmente cambia lo que vas a lanzar.
Limítalo a 20 minutos, misma hora, mismo documento:
Al final, decidir el modo de lanzamiento: Normal, o .
Usa una política por defecto sencilla que se pueda decir en voz alta:
La meta es un intercambio calmado, no buscar culpables.
Algunos guardarraíles prácticos:
Si trabajas sobre una plataforma como Koder.ai, haz que “revertir al último estado bueno” sea una maniobra rutinaria y trata las reversiónes repetidas como señal de invertir en tests o controles de despliegue.
