Disponibilidad y Downtime: SLA, Métricas y Cómo Calcular el Uptime
Publicado el 3 de junio de 2026 · Niwo
- ¿Qué es la Disponibilidad de Sistemas?
- Ejemplo Práctico
- Disponibilidad vs Uptime vs Confiabilidad
- Una Analogía Práctica
- SLA, SLO y SLI — Los Tres Pilares
- SLI (Indicador de Nivel de Servicio)
- SLO (Objetivo de Nivel de Servicio)
- SLA (Acuerdo de Nivel de Servicio)
- El Pipeline SLA → SLO → SLI
- Presupuestos de Error (Error Budgets): La Innovación SRE
- Cómo Calcular la Disponibilidad
- Fórmula Básica (Componente Individual)
- Disponibilidad Compuesta (Sistemas Multicomponente)
- Disponibilidad Incluyendo Mantenimiento Planificado
- Disponibilidad por Nivel SLA
- MTBF, MTTR y MTTA Explicados
- MTBF (Tiempo Medio Entre Fallos)
- MTTR (Tiempo Medio de Reparación/Recuperación)
- Desglose del MTTR
- MTTA (Tiempo Medio de Acuse de Recibo)
- El Triángulo MTBF / MTTR / Disponibilidad
- Los Nueves de la Disponibilidad
- Qué Significa Cada Nivel de Nueves
- Cuándo Necesitas Cada Nivel
- El Costo de los Nueves
- Estrategias de Alta Disponibilidad
- Redundancia
- Mecanismos de Conmutación por Error (Failover)
- Balanceo de Carga
- Arquitectura Multi-Región
- Los Tres Pilares de las Operaciones HA
- Monitoreo y Medición de Disponibilidad
- Monitoreo Sintético
- Monitoreo de Usuarios Reales (RUM)
- Recolección de SLI con Prometheus
- Recomendaciones de Stack de Monitoreo
- Preguntas Frecuentes
- ¿Cuál es la diferencia entre disponibilidad y confiabilidad?
- ¿Cómo calcular la disponibilidad de un sistema?
- ¿Qué es 99.999% de disponibilidad?
- ¿Qué mide el MTTR?
- ¿Cuántos nueves tiene AWS?
- Conclusión
- Puntos Clave
- Ponlo en Práctica
¿Qué es la Disponibilidad de Sistemas?
La disponibilidad de sistemas mide la proporción de tiempo que un servicio, aplicación o componente de infraestructura permanece operativo y accesible para sus usuarios. Es la métrica de confiabilidad más importante en operaciones de TI — y la base de todo Acuerdo de Nivel de Servicio (SLA).
La definición formal es directa:
Disponibilidad (%) = Uptime / (Uptime + Downtime) × 100Donde:
- Uptime = tiempo total que el sistema estuvo operativo durante el período de medición
- Downtime = tiempo total que el sistema no estuvo disponible durante el período de medición
- El resultado se expresa como un porcentaje entre 0% y 100%
Ejemplo Práctico
Una aplicación web registra 43 minutos de downtime en un mes de 30 días:
Disponibilidad = (43,200 min − 43 min) / 43,200 min × 100
= 43,157 / 43,200 × 100
= 99.90%Ese único cálculo determina si cumples tu SLA, si debes un crédito de servicio a tus clientes y si tu equipo celebra o realiza una autopsia técnica (postmortem).
Nota: La disponibilidad de sistemas y el downtime son dos caras de la misma ecuación. No puedes mejorar una sin entender la otra. Para una visión más profunda de qué significa el downtime y qué lo causa, lee nuestra guía: ¿Qué es Downtime? Definición, Causas y Cómo Minimizarlo.
Disponibilidad vs Uptime vs Confiabilidad
Estos tres términos se usan a menudo como sinónimos — pero miden cosas fundamentalmente diferentes. Entender la distinción es crítico al negociar SLA o diseñar dashboards de observabilidad.
| Concepto | Definición | Cómo se Mide | Ejemplo |
|---|---|---|---|
| Disponibilidad | Si el sistema es accesible y funcional | Porcentaje del tiempo operativo | 99.99% disponible en un mes |
| Uptime | El tiempo bruto que el sistema está funcionando | Tiempo (horas, minutos) | 719 horas de operación en un mes de 30 días |
| Confiabilidad | La probabilidad de que el sistema funcione correctamente y sin fallos durante un período | MTBF (horas), tasa de error, tasa de éxito | MTBF de 2,190 horas entre fallos |
Una Analogía Práctica
Piensa en una máquina expendedora:
- Uptime = la máquina está encendida
- Disponibilidad = puedes insertar dinero y seleccionar un producto (la máquina es alcanzable y responde)
- Confiabilidad = la máquina dispensa el producto correcto cada vez, sin atascarse
Un sistema puede tener alto uptime pero baja disponibilidad (un servidor que funciona pero devuelve errores 503), o alta disponibilidad pero baja confiabilidad (una base de datos alcanzable pero que devuelve datos corruptos). La excelencia operativa requiere los tres.
pie title Causas Comunes de Downtime
"Error Humano" : 45
"Apagones Eléctricos" : 43
"Fallo de Hardware" : 25
"Errores de Software" : 20
"Ciberataques" : 15
"Problemas de Red" : 12
"Otros" : 10
SLA, SLO y SLI — Los Tres Pilares
La Ingeniería de Confiabilidad del Sitio (SRE) — la disciplina pionera de Google — define tres capas distintas para gestionar la calidad del servicio. Entender estas capas transforma la disponibilidad de una métrica pasiva a una herramienta de ingeniería activa.
SLI (Indicador de Nivel de Servicio)
Un SLI es la medición bruta que te indica si un servicio cumple las expectativas. Los SLI más comunes incluyen:
- Latencia: Percentil 95 del tiempo de respuesta < 200 ms
- Rendimiento: Peticiones por segundo
- Tasa de error: Porcentaje de peticiones con código de estado 5xx
- Disponibilidad: Fracción de sondeos o peticiones exitosas
Ejemplo: “La proporción de peticiones HTTP GET a la API que devuelven un 200 OK en menos de 500 ms.”
SLO (Objetivo de Nivel de Servicio)
Un SLO es tu objetivo — el umbral que tu equipo se compromete a cumplir internamente. Siempre es más estricto que tu SLA.
Ejemplo: “El 99.95% de las peticiones a la API se completarán exitosamente en menos de 500 ms, medido en una ventana móvil de 30 días.”
Los SLO dan a los equipos de ingeniería un objetivo de confiabilidad claro y basado en datos. Responden a la pregunta: “¿Qué tan confiable necesita ser este servicio?”
SLA (Acuerdo de Nivel de Servicio)
Un SLA es el compromiso contractual que haces con tus clientes. Especifica:
- La disponibilidad mínima que garantizas (ej., 99.9%)
- Cómo se mide la disponibilidad (ventana de medición, exclusiones)
- Penalizaciones si no cumples el objetivo (créditos de servicio, reembolsos)
Ejemplo: “Garantizamos 99.9% de uptime mensual. Si no lo cumplimos, recibes un 10% de crédito de servicio.”
El Pipeline SLA → SLO → SLI
SLI (medición) → SLO (objetivo) → SLA (contrato)Una práctica SRE saludable establece el SLA por debajo del SLO para crear un colchón de seguridad. Si tu SLA es 99.9%, tu SLO podría ser 99.95% — lo que te da un margen de error (error budget) del 0.05% antes de que los clientes se vean afectados.
Presupuestos de Error (Error Budgets): La Innovación SRE
Un presupuesto de error es la cantidad de downtime que tu SLO permite en una ventana móvil. Convierte la confiabilidad de una meta abstracta a un recurso que se puede gastar.
Fórmula del Presupuesto de Error:
Presupuesto de Error = (1 − SLO) × Tiempo TotalEjemplo Práctico:
- SLO = 99.95% de disponibilidad en 30 días
- Tiempo total = 43,200 minutos
- Presupuesto de error = (1 − 0.9995) × 43,200 = 0.0005 × 43,200 = 21.6 minutos al mes
Esto significa que tu equipo puede permitirse 21.6 minutos de downtime al mes sin violar el SLO. ¿La innovación? Puedes gastar el presupuesto de error en despliegues arriesgados, experimentos de funciones o mantenimiento — siempre que no lo agotes. Cuando el presupuesto se acaba, cambias el enfoque a trabajo de confiabilidad.
🔍 Usa nuestra Calculadora de Downtime para calcular presupuestos de error exactos para cualquier nivel de SLO o SLA — ve al instante cuánto downtime permiten tus objetivos.
Cómo Calcular la Disponibilidad
El cálculo de la disponibilidad depende de tu ventana de medición y de si estás midiendo un componente individual o un sistema compuesto.
Fórmula Básica (Componente Individual)
Disponibilidad = (Tiempo Total − Downtime) / Tiempo Total × 100Disponibilidad Compuesta (Sistemas Multicomponente)
Cuando un servicio depende de múltiples componentes, la disponibilidad general es el producto de la disponibilidad de cada componente.
Disponibilidad del Sistema = A₁ × A₂ × A₃ × ... × AₙEjemplo Práctico — Aplicación Web de Tres Capas:
| Componente | Disponibilidad Individual | Impacto en el Sistema |
|---|---|---|
| Servidor web (Nginx) | 99.99% | A₁ = 0.9999 |
| Servidor de aplicación | 99.95% | A₂ = 0.9995 |
| Base de datos (PostgreSQL) | 99.99% | A₃ = 0.9999 |
Disponibilidad del Sistema = 0.9999 × 0.9995 × 0.9999
= 0.9993
= 99.93%Observa que 99.93% es menor que cualquier componente individual. Esta es la razón por la que los sistemas distribuidos requieren que cada componente sea significativamente más confiable que el objetivo general — un principio conocido como presupuesto de disponibilidad.
Disponibilidad Incluyendo Mantenimiento Planificado
Algunas organizaciones calculan la disponibilidad excluyendo el downtime planificado (ventanas de mantenimiento). Otras lo incluyen todo. Siempre verifica qué convención usa tu SLA:
- Disponibilidad no ajustada: Incluye todo el downtime (planificado + no planificado)
- Disponibilidad ajustada: Excluye las ventanas de mantenimiento pre-aprobadas
La diferencia puede ser sustancial. Un sistema con 99.95% de disponibilidad no ajustada podría aparecer como 99.99% después de excluir el mantenimiento planificado.
Disponibilidad por Nivel SLA
La tabla siguiente muestra exactamente cuánto downtime permite cada nivel SLA en diferentes ventanas de tiempo:
| Nivel de Disponibilidad | Nueves | Downtime Diario | Downtime Semanal | Downtime Mensual | Downtime Anual |
|---|---|---|---|---|---|
| 99% | 1 nueve | 14 min 24 s | 1 h 40 min | 7 h 12 min | 3.65 días |
| 99.5% | — | 7 min 12 s | 50 min 24 s | 3 h 36 min | 1.83 días |
| 99.9% | 3 nueves | 1 min 26 s | 10 min 4 s | 43 min 28 s | 8.76 horas |
| 99.95% | — | 43 s | 5 min 2 s | 21 min 44 s | 4.38 horas |
| 99.99% | 4 nueves | 8.6 s | 1 min 0 s | 4 min 23 s | 52 min 34 s |
| 99.999% | 5 nueves | 0.86 s | 6.0 s | 26 s | 5 min 15 s |
| 99.9999% | 6 nueves | 0.09 s | 0.6 s | 2.6 s | 31.5 s |
💡 ¿Necesitas convertir entre porcentaje de disponibilidad y minutos de downtime para una ventana de tiempo específica? Nuestra Calculadora de Downtime maneja todos los niveles SLA desde 99% hasta 99.9999% — selecciona cualquier valor y ve el downtime exacto en segundos, minutos u horas.
MTBF, MTTR y MTTA Explicados
Los porcentajes de disponibilidad te dicen cuánto downtime ocurrió, pero no te dicen por qué ni qué tan bien respondió tu equipo. Ahí es donde entran MTBF, MTTR y MTTA.
MTBF (Tiempo Medio Entre Fallos)
El MTBF mide la confiabilidad — el tiempo operativo promedio entre fallos consecutivos. Un MTBF más alto = sistema más confiable.
MTBF = Tiempo Total de Operación / Número de FallosEjemplo Práctico: Un balanceador de carga funciona 8,760 horas (1 año) y experimenta 6 fallos:
MTBF = 8,760 / 6 = 1,460 horas ≈ 60.8 díasEsto significa que el balanceador funciona aproximadamente 60 días en promedio entre fallos.
Cómo se relaciona MTBF con la disponibilidad:
Disponibilidad ≈ MTBF / (MTBF + MTTR)Si MTBF = 1,460 horas y MTTR = 2 horas:
Disponibilidad ≈ 1,460 / (1,460 + 2) = 99.86%MTTR (Tiempo Medio de Reparación/Recuperación)
El MTTR mide la capacidad de recuperación — qué tan rápido tu equipo puede restaurar el servicio tras un fallo. Un MTTR más bajo = recuperación más rápida.
MTTR = Tiempo Total de Downtime / Número de FallosEjemplo Práctico: Un clúster de base de datos experimenta 4 interrupciones que suman 10 horas de downtime:
MTTR = 10 / 4 = 2.5 horasMTTR es la métrica más actionable de esta familia porque refleja directamente la calidad de tus procesos de respuesta a incidentes — runbooks, alertas, preparación de guardia y herramientas.
Desglose del MTTR
En la práctica, el MTTR se compone de varias subfases:
| Fase | Descripción | Duración Típica |
|---|---|---|
| MTTD (Tiempo Medio de Detección) | Tiempo desde el inicio del fallo hasta que salta la alerta | 30 s – 15 min |
| MTTA (Tiempo Medio de Acuse) | Tiempo desde la alerta hasta que un humano la reconoce | 2 – 15 min |
| MTTT (Tiempo Medio de Diagnóstico) | Tiempo dedicado a identificar la causa raíz | 15 – 60 min |
| MTTF (Tiempo Medio de Corrección) | Tiempo para implementar y verificar la solución | 5 – 120 min |
MTTR Total ≈ MTTD + MTTA + MTTT + MTTF
MTTA (Tiempo Medio de Acuse de Recibo)
El MTTA mide la capacidad de respuesta — el intervalo entre que salta una alerta y un humano la reconoce. Es un indicador rezagado de la disciplina de guardia y la calidad del enrutamiento de alertas.
Rangos objetivo:
- Oro: < 2 minutos (sistemas críticos de producción con guardia 24/7)
- Plata: < 5 minutos (servicios críticos con rotación de pager)
- Bronce: < 15 minutos (servicios estándar con alertas por email+Slack)
El Triángulo MTBF / MTTR / Disponibilidad
Estas tres métricas forman una relación cerrada:
Disponibilidad = MTBF / (MTBF + MTTR)| MTBF | MTTR | Disponibilidad | Clasificación |
|---|---|---|---|
| 30 días | 4 horas | 99.44% | Buena — herramienta interna típica |
| 60 días | 2 horas | 99.86% | Excelente — producción estándar |
| 90 días | 30 min | 99.98% | Óptima — misión crítica |
| 365 días | 15 min | 99.997% | Élite — nivel AWS/Azure |
Ideas clave: Puedes lograr la misma disponibilidad teniendo un sistema extremadamente confiable (MTBF alto) O recuperándote extremadamente rápido (MTTR bajo). Los mejores equipos optimizan ambas.
Los Nueves de la Disponibilidad
La abreviatura de “nueves” (99.9%, 99.99%, 99.999%) es el vocabulario estándar de la disponibilidad en la industria. Cada nueve representa una reducción de diez veces en el downtime permitido.
Qué Significa Cada Nivel de Nueves
| Nivel de Nueves | La Matemática | Downtime/Año | Equivalente en el Mundo Real |
|---|---|---|---|
| 90% (cero nueves) | 1 fallo en 10 | 36.5 días | Inaceptable para producción |
| 99% (un nueve) | 1 fallo en 100 | 3.65 días | Desarrollo/pruebas, herramientas internas |
| 99.9% (tres nueves) | 1 fallo en 1,000 | 8.76 horas | SaaS estándar, producción B2B |
| 99.99% (cuatro nueves) | 1 fallo en 10,000 | 52.6 min | Empresarial, servicios financieros |
| 99.999% (cinco nueves) | 1 fallo en 100,000 | 5.26 min | Telecomunicaciones, servicios de emergencia |
| 99.9999% (seis nueves) | 1 fallo en 1,000,000 | 31.5 s | Grado portador, control de tráfico aéreo |
Cuándo Necesitas Cada Nivel
-
Tres nueves (99.9%) es la línea base para cualquier servicio de internet en producción. Significa que tus clientes experimentan aproximadamente un día laboral de downtime al año. Para la mayoría de los productos SaaS, esto es aceptable — especialmente si el downtime ocurre fuera del horario pico.
-
Cuatro nueves (99.99%) es el estándar para infraestructura empresarial y plataformas financieras. Menos de una hora de downtime al año requiere redes redundantes, despliegues multi-Zona de Disponibilidad y conmutación por error automatizada. No puedes lograr esto con un solo servidor.
-
Cinco nueves (99.999%) es territorio de misión crítica. Menos de 6 minutos de downtime al año exige arquitectura activo-activo multi-región, replicación en tiempo real y un equipo de respuesta a incidentes en espera 24/7.
-
Seis nueves (99.9999%) es grado portador — piensa en centrales telefónicas, despacho de emergencias 911 y comunicaciones por satélite. Requiere infraestructura completamente redundante y distribuida geográficamente, sin puntos únicos de fallo y con conmutación por error automatizada medida en milisegundos.
El Costo de los Nueves
Cada nueve adicional es exponencialmente más caro de alcanzar:
- 99.9% → 99.99%: ~3–5× aumento en costo de infraestructura
- 99.99% → 99.999%: ~5–10× aumento en costo de infraestructura
- 99.999% → 99.9999%: ~10–20× aumento en costo de infraestructura
Regla general: Nunca pagues por más nueves de los que tu negocio necesita. Una startup con $1M de ingresos anuales no necesita cinco nueves. Un procesador de pagos con $1B en volumen diario probablemente sí.
Estrategias de Alta Disponibilidad
La alta disponibilidad (HA) es la disciplina de ingeniería que diseña sistemas para permanecer operativos a pesar de fallos en los componentes. HA no es una tecnología única — es un conjunto de patrones aplicados en toda la pila.
Redundancia
Elimina los puntos únicos de fallo en cada capa:
- Hardware: Fuentes de poder N+1, almacenamiento RAID, NICs redundantes
- Cómputo: Múltiples instancias del servidor de aplicaciones detrás de un balanceador de carga
- Base de datos: Replicación primario-secundario con conmutación por error automatizada
- Red: Enlaces de internet duales de diferentes ISP, switches redundantes
Mecanismos de Conmutación por Error (Failover)
| Tipo | Cómo Funciona | Tiempo de Failover | Costo |
|---|---|---|---|
| Activo-Pasivo | Un servidor maneja el tráfico; una réplica en espera toma el control al fallar | 30 s – 5 min | Medio (recursos en espera inactivos) |
| Activo-Activo | Ambos servidores manejan tráfico simultáneamente; la pérdida de uno reduce capacidad | < 1 s (DNS/LB) | Alto (capacidad total en ambos sitios) |
| Automático | Los checks de salud detectan fallos y redirigen el tráfico sin intervención humana | Segundos | Medio-Alto (requiere orquestación) |
| Manual | El ingeniero de guardia activa el failover mediante runbook | 5 – 30 min | Bajo (dependiente de humanos) |
Balanceo de Carga
Distribuye el tráfico entre múltiples instancias saludables para evitar que un solo servidor se convierta en un cuello de botella — o en un punto de fallo.
- Capa 4 (TCP/UDP): HAProxy, Nginx Stream, AWS NLB
- Capa 7 (HTTP/HTTPS): Nginx, Traefik, AWS ALB, Cloudflare
- Global: Basado en DNS (Route53, Cloudflare DNS) con failover por checks de salud
Arquitectura Multi-Región
Para cuatro nueves o más, necesitas distribución geográfica:
- Activo-Pasivo multi-región: La región principal maneja todo el tráfico; la región secundaria está en espera con datos replicados. El failover es manual o semi-automatizado.
- Activo-Activo multi-región: Ambas regiones manejan tráfico en vivo simultáneamente. Requiere balanceo de carga global, replicación de datos con resolución de conflictos y una gestión cuidadosa de sesiones.
Los Tres Pilares de las Operaciones HA
- Monitoreo: Detecta fallos más rápido que tus usuarios
- Automatización: Elimina la latencia humana del camino de recuperación
- Pruebas: Valida tu diseño HA mediante ingeniería del caos y game days
Sin los tres, tu arquitectura multi-región es solo una forma más cara de fallar.
Monitoreo y Medición de Disponibilidad
No puedes mejorar lo que no mides. El monitoreo efectivo de la disponibilidad requiere las herramientas adecuadas y el enfoque correcto para la recolección de SLI.
Monitoreo Sintético
El monitoreo sintético simula el comportamiento del usuario con scripts o sondeos predefinidos:
- UptimeRobot: Monitoreo HTTP/HTTPS gratuito con intervalos de 5 minutos y páginas de estado
- Pingdom: Checks sintéticos avanzados con scripts de transacciones multi-paso (login → búsqueda → compra)
- Checkly: Monitoreo sintético code-first con checks de navegador basados en Playwright
- Grafana Synthetic Monitoring: Sondeos open source integrados con el ecosistema Grafana
Monitoreo de Usuarios Reales (RUM)
RUM captura interacciones reales de usuarios para medir la disponibilidad desde la perspectiva del usuario:
- Google Analytics / CrUX: Datos de rendimiento de usuarios reales agregados por usuarios de Chrome
- Datadog RUM: Reproducción completa de sesiones con correlación de trazas frontend y backend
- New Relic Browser: Seguimiento de errores JavaScript y métricas de carga de páginas
Recolección de SLI con Prometheus
En el ecosistema Kubernetes y cloud-native, Prometheus es el estándar para la instrumentación de SLI:
# Disponibilidad del servicio en los últimos 30 días
1 - (
sum(rate(http_requests_total{status=~"5.."}[30d])) /
sum(rate(http_requests_total[30d]))
)Esta consulta PromQL calcula la proporción de respuestas no-5xx en una ventana móvil de 30 días — una medición directa de SLI.
Recomendaciones de Stack de Monitoreo
| Caso de Uso | Herramientas Recomendadas |
|---|---|
| Monitoreo simple de uptime (1–10 servicios) | UptimeRobot, Better Uptime |
| Multi-servicio con alertas | Pingdom, Checkly |
| Cloud-native / Kubernetes | Prometheus + Grafana + Alertmanager |
| Observabilidad completa (APM + RUM + logs) | Datadog, New Relic, Grafana Cloud |
🔍 Usa nuestra Calculadora de Downtime junto con tus datos de monitoreo — convierte tus minutos de downtime medidos en un porcentaje de disponibilidad y compruébalo contra tus objetivos SLA al instante.
Preguntas Frecuentes
¿Cuál es la diferencia entre disponibilidad y confiabilidad?
La disponibilidad mide si un sistema es accesible (¿puedes alcanzarlo?). La confiabilidad mide si se comporta correctamente (¿las respuestas son válidas?). Un sistema puede estar 99.99% disponible pero solo ser 95% confiable si devuelve errores o datos corruptos con frecuencia. La disponibilidad es una métrica binaria (funciona/no funciona); la confiabilidad es una métrica de corrección (respuestas buenas/malas).
¿Cómo calcular la disponibilidad de un sistema?
La disponibilidad del sistema se calcula como (Tiempo Total − Downtime) / Tiempo Total × 100. Para sistemas compuestos, multiplica la disponibilidad de cada componente. Ejemplo: una aplicación web con 99.99% de uptime en un mes de 30 días (43,200 minutos) y 43 minutos de downtime tiene 99.90% de disponibilidad. Usa nuestra Calculadora de Downtime para conversiones instantáneas.
¿Qué es 99.999% de disponibilidad?
99.999% de disponibilidad (“cinco nueves”) permite un máximo de 5 minutos y 15 segundos de downtime al año — aproximadamente 26 segundos al mes. Es el estándar para infraestructura de misión crítica como centrales telefónicas, sistemas de pago y servicios de despacho de emergencias. Alcanzar cinco nueves requiere arquitectura activo-activo multi-región con conmutación por error automatizada.
¿Qué mide el MTTR?
El MTTR (Tiempo Medio de Reparación/Recuperación) mide el tiempo promedio que toma restaurar un sistema después de un fallo. Incluye detección, acuse, diagnóstico y reparación. Un MTTR más bajo significa recuperación más rápida. Un MTTR menor de 1 hora se considera excelente; menos de 15 minutos es nivel élite. MTTR es la métrica más impactante de optimizar porque reduce directamente la duración del downtime.
¿Cuántos nueves tiene AWS?
AWS se compromete a objetivos de disponibilidad específicos por servicio en su documentación de SLA. Amazon S3 tiene un SLA de 99.99% (cuatro nueves). Amazon EC2 tiene un SLA de 99.99% para despliegues multi-instancia en diferentes Zonas de Disponibilidad. AWS Lambda tiene un SLA de 99.95%. Ningún servicio de AWS garantiza 100% de disponibilidad, y la mayoría ofrece créditos de servicio si no cumplen sus objetivos SLA publicados. AWS reporta uptime agregado entre todos sus servicios, pero la experiencia real varía por región y configuración del servicio.
Conclusión
La disponibilidad de sistemas no es solo un número — es el lenguaje que tu infraestructura usa para decirte qué tan saludable está. Entender cómo calcularla, cómo desglosarla en SLI, SLO y SLA, y cómo usar los presupuestos de error para impulsar decisiones de ingeniería transforma la disponibilidad de un boletín de calificaciones en una ventaja competitiva.
Puntos Clave
- Disponibilidad = Uptime / (Uptime + Downtime) × 100 — Conoce la fórmula y cuándo aplicarla
- Distingue entre uptime, disponibilidad y confiabilidad — Miden cosas diferentes, y confundirlas lleva a un mal diseño de SLA
- Establece SLO más estrictos que los SLA — El margen es tu presupuesto de error, y es tu recurso operativo más valioso
- Optimiza MTTR antes que MTBF — La recuperación rápida suele ser más barata e impactante que prevenir todos los fallos posibles
- Adapta los nueves a tu negocio — Cinco nueves es un logro técnico; cuatro nueves suele ser la respuesta empresarial correcta
- Mide lo que importa — Usa monitoreo sintético, RUM y SLI basados en Prometheus para rastrear la disponibilidad desde todos los ángulos
Ponlo en Práctica
¿Listo para aplicar lo que has aprendido?
- Calcula tu disponibilidad actual — Nuestra Calculadora de Downtime convierte entre porcentajes de uptime y minutos de inactividad para cualquier ventana de tiempo, desde diaria hasta anual
- Revisa tus objetivos SLA — ¿Son realistas? ¿Tus SLO te dan suficiente presupuesto de error?
- Lee sobre fundamentos de downtime — Nuestra guía ¿Qué es Downtime? cubre definiciones, causas, costos y estrategias para minimizar interrupciones no planificadas
Empieza a medir, empieza a mejorar, y deja que los números guíen tu viaje hacia la confiabilidad.
