OVHcloud y su Crisis Global: 11 Días de Patching
Un Despliegue Estratégico
El proceso de actualización de OVHcloud comenzó un miércoles en Sydney, una ubicación que, aunque puede parecer exótica, fue seleccionada estratégicamente. Esta región es pequeña, y su horario nocturno coincide con las horas laborales de los equipos en Europa. Con la metodología “follow the sun”, cada región se encarga de continuar el proceso durante su jornada local, asegurando que la operación no detenga el servicio globalmente.
Durante la primera noche, de un total de 6,000 servidores, entre 20 y 30 no se reiniciaron correctamente, lo que se atribuyó a problemas en la memoria o configuraciones defectuosas. La operación culminó en 11 días, con las últimas regiones actualizadas el 19 de julio.
Un Rediseño sin Preaviso
La decisión más controvertida que tomó OVHcloud fue el llamado “patching unilatéral à impact contrôlé”. Esto se traduce en que no se realizaron ventanas de mantenimiento previamente negociadas y los reinicios se aplicaron sin el consentimiento individual de los clientes. Esta política fue diseñada para gestionar mejor los impactos inevitables, buscando diluir cualquier problema en lugar de prevenirlo por completo.
Los ingenieros de OVHcloud crearon un análisis de co-localización para evitar que dos hosts con proyectos del mismo cliente se reiniciaran simultáneamente. A pesar de esto, el enfoque se consideró como un “mejor esfuerzo” sin garantías absolutas. Las cargas más delgadas, incluidas más de 4,300 máquinas virtuales de bases de datos, fueron migradas una a una.
Comunicación y Transparencia: Un Desafío
Un aspecto crítico de esta operación fue la comunicación de OVHcloud. La empresa optó por no tener una página de estado público al principio para evitar exponer la secuencia de despliegue, y limitó la información mientras el parque de servidores seguía siendo vulnerable. Esta estrategia fue diseñada para prevenir que algunos clientes intentaran replicar el problema en sus propios sistemas.
Sin embargo, la falta de comunicación generó ciertos problemas. Algunas máquinas virtuales no reiniciaron después del proceso, lo que provocó que se identificara y corrigiera un conflicto de servicios al segundo día. También se reportaron pérdidas de datos en tres clusters y bloqueos de APIs en la región de París. Además, cerca de 90,000 clientes de la región GRA6 no recibieron actualizaciones por correo electrónico debido al rechazo del envío masivo de mensajes. Finalmente, se desarrolló una solución provisional con una bandera de información en el espacio del cliente.
Lecciones Aprendidas y Futuro
A pesar de los desafíos, este nivel de detalle en la comunicación es poco común en un proveedor de tales dimensiones. OVHcloud se encuentra en una posición sólida en el mercado de la nube pública y advierte que este ejercicio se repetirá con futuras actualizaciones en respuesta a vulnerabilidades del núcleo. La empresa se compromete a mejorar la comunicación con sus clientes para mitigar situaciones similares en el futuro.
Si alguna vez tu VPS reinicia sin aviso, ya sabrás la razón detrás de esta decisión y a qué riesgos se enfrenta OVHcloud a nivel global.
About the Author
