Hace unos años Google definió que la principal funcionalidad de un sistema es el "uptime".
En términos simples, el uptime se refiere al tiempo durante el cual un sistema, servidor o máquina está en operación. Típicamente se mide en porcentaje, por ejemplo, 99,9% implicaría que un sistema podría estar indisponible por:
- Diario: 1m 26s
- Semanal: 10m 4.8s
- Mensual: 43m 50s
- Anual: 8h 45m 57s
Por consiguiente, para conseguir mayores niveles de uptime (porcentajes más altos), se requerirá de servidores más robustos, aplicaciones con menos errores, procedimientos más depurados y hoy también, la agregación de medidas de ciberseguridad. Por tanto, apuntar a mayores valores de uptime implica mayores costos.
El mito del uptime en la nube
Muchos sistemas se han migrado a la nube buscando mejorar el uptime, esperando que Microsoft Azure o Amazon AWS no fallen.
Sin embargo, la realidad nos ha mostrado que no hay proveedor infalible. El 29 de octubre de 2025 Microsoft Azure sufrió una caída masiva que duró más de 8 horas, afectando a servicios como Microsoft Store, Office 365 y Outlook entre otros.
Un par de semanas antes del incidente de Azure, se registró una falla masiva en Amazon AWS. Una falla en su DNS de la región este-1 provocó un efecto dominó, que implicó la caída de instancias EC2 (VPS), balanceadores de carga y de la consola de administración. La falla afectó a más de mil compañías y a más de un millón de usuarios.
Otros tipos de errores también pueden ocurrir. A comienzos del año 2024 Google Cloud (GCP) accidentalmente eliminó el usuario maestro de la compañía financiera australiana UniSuper, eliminando todos sus servicios, bases de datos y una caída de dos días con pérdidas millonarias.
Los casos mencionados son los que se provocaron por los grandes proveedores en Internet, pero hay muchas otras situaciones de indisponibilidad que se pueden dar, tales como ransomware, desastres naturales, fallas internas de configuración, sabotajes, etc.
¿Entonces qué se puede hacer?
La vieja sabiduría nos aconseja no poner todos los huevos en una misma canasta, y esta estrategia también nos sirve para mejorar la disponibilidad de nuestros sistemas.
Una recomendación de implementación simple, sería contar con un servicio de respaldo ubicado en otra ubicación (hot/standby), por ejemplo, fuera de Chile. Usar un segundo proveedor para alojar la infraestructura. En caso de falla de la ubicación primaria, mediante procesos manuales o automáticos, se restablece el servicio en la segunda ubicación. Esto permite un uptime superior a tener el servicio en una sola ubicación, aunque activar el proceso de cambio implica una penalidad de tiempo que afecta el uptime.
Una medida más efectiva (mayor uptime) es contar con sistemas distribuidos geográficamente, todos los nodos están activos y se ubican en diferentes proveedores, que mediante balanceadores de carga en la nube podrán automáticamente detectar las fallas en alguna ubicación y redirigen el tráfico hacia otros nodos operativos, posibilitando altos niveles de uptime con valores que superan el 99,99% mensual, es decir, con una indisponibilidad menor a 4 minutos y 23 segundos en un mes.
La evidencia y los casos aquí relatados indican que no podemos confiar en la suerte ni pensar que nada afectará a nuestros sistemas. Que alguna falla de indisponibilidad afecte a mi sistema es casi una certeza, pero, debemos responder ¿estamos preparados para la interrupción de nuestro servicio?, ¿podemos esperar por varios días sin el sistema? Lo mejor es estar preparados para cuando la indisponibilidad ocurra y contar con un plan.
