Regla de los 5 nueves

La regla de los 5 nueves

Los nueves solo tienen sentido con una ventana de medición y una definición de servicio disponible. Un cálculo anual no describe automáticamente el SLA que firma un proveedor.

La regla de los 5 nueves es una forma habitual de expresar un objetivo en el ámbito de la infraestructura tecnológica para medir la disponibilidad de un sistema o servicio. Se refiere a un nivel de disponibilidad del 99.999%, lo que implica que en una ventana ideal de 365 días, el presupuesto matemático es de aproximadamente 5,26 minutos al año.

¿Qué significa 99.999% de disponibilidad?

El porcentaje de disponibilidad se calcula en función del tiempo que un sistema está operativo en comparación con el tiempo total de la ventana elegida. Aquí hay un desglose:

• 99% de disponibilidad: 3.65 días de inactividad al año.
• 99.9% de disponibilidad: 8.76 horas de inactividad al año.
• 99.99% de disponibilidad: 52.56 minutos de inactividad al año.
• 99.999% de disponibilidad: 5.26 minutos de inactividad al año.

¿Por qué es importante?

La regla de los 5 nueves es especialmente relevante en entornos donde la alta disponibilidad es crítica, como:

• Servicios en la nube: Cada servicio de AWS, Google Cloud o Azure tiene compromisos propios; no hay garantía uniforme de cinco nueves para toda una plataforma.
• Sistemas financieros: Transacciones bancarias o bolsas de valores no pueden permitir tiempos de inactividad prolongados.
• Telecomunicaciones: Servicios de emergencia o redes móviles requieren un funcionamiento continuo.
• Infraestructuras críticas: Hospitales, aeropuertos o centrales eléctricas.

¿Cómo se logra?

Alcanzar un nivel de disponibilidad del 99.999% requiere una combinación de:

1. Redundancia:

   • Uso de múltiples servidores, discos o conexiones de red para evitar puntos únicos de fallo.
   • Ejemplo: Configuración de clusters o balanceadores de carga.

2. Monitoreo continuo:

   • Herramientas que detecten fallos en tiempo real y permitan una respuesta rápida.
   • Ejemplo: Uso de sistemas como Nagios, Prometheus o Datadog.

3. Mantenimiento preventivo:

   • Actualizaciones y revisiones periódicas para evitar fallos inesperados.
   • Ejemplo: Parches de seguridad y pruebas de rendimiento.

4. Planes de recuperación ante desastres:

   • Estrategias para restaurar servicios rápidamente en caso de fallos mayores.
   • Ejemplo: Copias de seguridad automatizadas y sistemas de failover.

5. Infraestructura de alta calidad:

   • Uso de hardware y software confiable y probado.
   • Ejemplo: Servidores empresariales y sistemas operativos estables.

Desafíos de los 5 nueves

• Costo: Mantener un nivel de disponibilidad tan alto requiere inversiones significativas en infraestructura y personal.
• Complejidad: La implementación de sistemas redundantes y de monitoreo puede ser técnicamente desafiante.
• Rentabilidad: No todos los sistemas necesitan este nivel de disponibilidad, por lo que es importante evaluar si el costo justifica los beneficios.

---

Nota: La regla de los 5 nueves es un objetivo ambicioso y no siempre es necesario para todos los sistemas. Es importante evaluar las necesidades específicas de cada proyecto antes de invertir en alcanzar este nivel de disponibilidad.

Véase también

• Balanceadores de carga — Balanceo como una pieza de arquitectura para disponibilidad, no una garantía por sí sola.

Cálculo: 365 × 24 × 60 × (1 − 0,99999) = 5,256 minutos. Un SLA puede usar otra ventana, excluir mantenimiento o definir disponibilidad mediante solicitudes; hay que leer el contrato antes de trasladar esta cifra.

Referencia: SLI/SLO/SLA, Google SRE. La lista de redundancia y monitoreo propone medidas, no una fórmula suficiente para alcanzar el objetivo. Considerar fallos correlacionados, dependencias, pruebas y ventana de medición. Los valores de la tabla usan una ventana de 365 días; expresan un presupuesto matemático, no una medición de disponibilidad.

+----------------------------------------+
| Floure &                               |
| Tachibana's guild                      |
| [Hikari · Nozomi · Vesper]             |
| SEAL: sha256/12: ae504e3ba1dc          |
| STATUS: LITURGY_IN_PROGRESS            |
+----------------------------------------+