Calculadora de Disponibilidad SLA
Calcula el tiempo de inactividad permitido según la tasa SLA.
- Per year
- 8.8 h
- Per month (30d)
- 43.2 min
- Per week
- 10.1 min
- Per day
- 1.4 min
Descripción general
Los objetivos de disponibilidad se citan como porcentajes, y los porcentajes son malos transmitiendo escala. El 99 % y el 99,9 % parecen contiguos y se diferencian en más de tres días al año. Esta calculadora convierte el porcentaje en tiempo, que es la forma en la que la cifra sirve de verdad.
Introduce una cifra de disponibilidad y obtienes el tiempo de caída permitido para un año, un mes, una semana y un día.
Cómo se usa
- Introduce un porcentaje de disponibilidad en Availability (%), o pulsa un preajuste.
- Lee el tiempo de caída permitido en las cuatro ventanas: Per year, Per month (30d), Per week y Per day.
Los preajustes cubren los niveles que aparecen en los acuerdos reales: 90, 95, 99, 99.9, 99.95, 99.99 y 99.999.
La tabla de referencia
| Disponibilidad | Por año | Por mes (30 d) | Por semana | Por día |
|---|---|---|---|---|
| 90% | 36.50 days | 3.00 days | 16.8 h | 2.4 h |
| 95% | 18.25 days | 1.50 days | 8.4 h | 1.2 h |
| 99% | 3.65 days | 7.2 h | 1.7 h | 14.4 min |
| 99.9% | 8.8 h | 43.2 min | 10.1 min | 1.4 min |
| 99.95% | 4.4 h | 21.6 min | 5.0 min | 43.2 s |
| 99.99% | 52.6 min | 4.3 min | 1.0 min | 8.6 s |
| 99.999% | 5.3 min | 25.9 s | 6.0 s | 864 ms |
Hay dos cosas que merece la pena notar. La columna diaria es aquello dentro de lo cual tiene que caber un despliegue malo. Y por debajo de más o menos el 99,99 %, el tiempo de caída permitido en un día es más corto que lo que suele tardar una persona en ver una alerta, abrir un panel y decidir qué hacer, que es la frontera práctica donde la fiabilidad deja de ser un problema operativo y pasa a ser un problema de arquitectura.
Cómo elegir un objetivo
Trabaja hacia atrás desde las consecuencias, no hacia delante desde la ambición.
Pregúntate qué pasa durante la caída. Si un trabajo por lotes se retrasa y luego se pone al día, el objetivo puede ser bajo. Si un cliente no puede completar una compra, el objetivo sigue a los ingresos. Si de él depende un servicio de emergencias, el objetivo no es realmente la pregunta que estás haciendo.
Después compara el objetivo con tus dependencias. La disponibilidad se compone de forma multiplicativa para todo lo que esté en serie: un servicio que necesita tres componentes, cada uno al 99,9 %, tiene un techo de en torno al 99,7 % antes de haber hecho nada mal por su cuenta. No puedes prometer más de lo que permite tu camino crítico, y añadir un reintento no cambia la aritmética a menos que los fallos sean independientes.
Por último, compáralo con tu proceso de recuperación. Un objetivo del 99,99 % con conmutación manual y una guardia a la que se avisa por correo no es un objetivo, es un deseo. La cifra implica el mecanismo.
SLO y SLA son cifras distintas
Mantén el SLO interno más estricto que el SLA contractual. La distancia es tu margen de operación: la región en la que ya has incumplido tu propio objetivo y has empezado a reaccionar, pero todavía no has incurrido en penalización.
Un SLO interno del 99,9 % detrás de un SLA contractual del 99,5 % te da unas 2,9 horas de holgura al mes entre la primera señal (43 minutos) y el primer crédito en factura (3,6 horas). Si las dos cifras son iguales, el momento en que te enteras es también el momento en que debes dinero, lo que elimina cualquier posibilidad de resolver el problema sin ruido.
Lee también las exclusiones. La mayoría de los SLA no cuentan el mantenimiento anunciado, los fallos causados por la configuración del propio cliente ni los casos de fuerza mayor. Esas salvedades hacen que un servicio pueda cumplir su SLA en un mes en el que los usuarios sufrieron indisponibilidad real, lo cual es un resultado jurídico, no de ingeniería.
Decidir qué cuenta como caída
El porcentaje es aritmética; lo difícil es la definición a la que se aplica. Dos equipos pueden informar de disponibilidades distintas para el mismo mes sin que ninguno mienta.
¿Medido desde dónde? Una comprobación desde dentro de tu propia red se salta la CDN, el DNS y el camino por internet, que es donde ocurre buena parte de los fallos visibles para el usuario. Medir desde fuera da una cifra más cercana a lo que vivieron los usuarios y peor que la que muestra tu panel.
¿Medido cada cuánto? Una sonda cada cinco minutos no puede detectar una caída más corta de cinco minutos, y a una caída de 30 segundos le atribuye cero o cinco minutos de indisponibilidad según cuándo caiga. Sondear de forma gruesa no te hace más fiable; hace que tu medición vea menos.
¿Qué endpoint? Un health check que devuelve 200 siempre que el proceso está en marcha informará de disponibilidad total durante una caída en la que fallaron todas las peticiones reales. La comprobación tiene que ejercitar las dependencias que importan.
Fallo parcial. Si un endpoint de veinte está roto, ¿el servicio está en pie? Una definición basada en tiempo suele decir que sí. Los usuarios de ese endpoint dicen que no. Esta es la razón principal para definir la disponibilidad como proporción de peticiones correctas en lugar de como intervalos de servicio en pie; para ese planteamiento, mira la calculadora de presupuesto de error.
Escribe la definición antes de comprometerte con la cifra, porque la definición es donde surgirá el desacuerdo más adelante.
Ejemplos
- Justificar redundancia. El 99,9 % permite 43 minutos al mes; un despliegue en una sola región con conmutación manual gasta más que eso en un solo incidente con toda normalidad.
- Dimensionar una ventana de mantenimiento. Una ventana de cuatro horas se pasa de presupuesto para cualquier cosa al 99,9 % o mejor si cuenta como caída. O no cuenta, contractualmente, o necesitas una migración sin interrupción.
- Poner a prueba la promesa de un proveedor. Una reclamación de 99,99 % sin ninguna conmutación automática descrita en ninguna parte de la documentación es una cifra de marketing.
- Fijar un umbral de alerta. Al 99,95 %, un minuto de caída por semana es la quinta parte del presupuesto semanal. Esa es la escala que tiene que resolver tu sistema de alertas.
Notas
Aquí el año son 365 días y el mes son 30 días. Los años bisiestos y los meses naturales desplazan un poco las cifras; si la diferencia decide algo en un contrato, usa la definición escrita en el contrato.
Esta herramienta responde a «cuánto tiempo de caída permite este porcentaje». Si además quieres saber cuántas peticiones fallidas individuales caben en el presupuesto, y cuánto te has gastado ya, usa la calculadora de presupuesto de error: es la misma aritmética aplicada al volumen de peticiones en lugar de al tiempo.