El proceso de actualizaci\u00f3n de OVHcloud comenz\u00f3 un mi\u00e9rcoles en Sydney, una ubicaci\u00f3n que, aunque puede parecer ex\u00f3tica, fue seleccionada estrat\u00e9gicamente. Esta regi\u00f3n es peque\u00f1a, y su horario nocturno coincide con las horas laborales de los equipos en Europa. Con la metodolog\u00eda “follow the sun”, cada regi\u00f3n se encarga de continuar el proceso durante su jornada local, asegurando que la operaci\u00f3n no detenga el servicio globalmente.<\/p>\n
Durante la primera noche, de un total de 6,000 servidores, entre 20 y 30 no se reiniciaron correctamente, lo que se atribuy\u00f3 a problemas en la memoria o configuraciones defectuosas. La operaci\u00f3n culmin\u00f3 en 11 d\u00edas, con las \u00faltimas regiones actualizadas el 19 de julio.<\/p>\n
La decisi\u00f3n m\u00e1s controvertida que tom\u00f3 OVHcloud fue el llamado “patching unilat\u00e9ral \u00e0 impact contr\u00f4l\u00e9”. 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\u00edtica fue dise\u00f1ada para gestionar mejor los impactos inevitables, buscando diluir cualquier problema en lugar de prevenirlo por completo.<\/p>\n
Los ingenieros de OVHcloud crearon un an\u00e1lisis de co-localizaci\u00f3n para evitar que dos hosts con proyectos del mismo cliente se reiniciaran simult\u00e1neamente. A pesar de esto, el enfoque se consider\u00f3 como un \u201cmejor esfuerzo\u201d sin garant\u00edas absolutas. Las cargas m\u00e1s delgadas, incluidas m\u00e1s de 4,300 m\u00e1quinas virtuales de bases de datos, fueron migradas una a una.<\/p>\n
Un aspecto cr\u00edtico de esta operaci\u00f3n fue la comunicaci\u00f3n de OVHcloud. La empresa opt\u00f3 por no tener una p\u00e1gina de estado p\u00fablico al principio para evitar exponer la secuencia de despliegue, y limit\u00f3 la informaci\u00f3n mientras el parque de servidores segu\u00eda siendo vulnerable. Esta estrategia fue dise\u00f1ada para prevenir que algunos clientes intentaran replicar el problema en sus propios sistemas.<\/p>\n
Sin embargo, la falta de comunicaci\u00f3n gener\u00f3 ciertos problemas. Algunas m\u00e1quinas virtuales no reiniciaron despu\u00e9s del proceso, lo que provoc\u00f3 que se identificara y corrigiera un conflicto de servicios al segundo d\u00eda. Tambi\u00e9n se reportaron p\u00e9rdidas de datos en tres clusters y bloqueos de APIs en la regi\u00f3n de Par\u00eds. Adem\u00e1s, cerca de 90,000 clientes de la regi\u00f3n GRA6 no recibieron actualizaciones por correo electr\u00f3nico debido al rechazo del env\u00edo masivo de mensajes. Finalmente, se desarroll\u00f3 una soluci\u00f3n provisional con una bandera de informaci\u00f3n en el espacio del cliente.<\/p>\n
A pesar de los desaf\u00edos, este nivel de detalle en la comunicaci\u00f3n es poco com\u00fan en un proveedor de tales dimensiones. OVHcloud se encuentra en una posici\u00f3n s\u00f3lida en el mercado de la nube p\u00fablica y advierte que este ejercicio se repetir\u00e1 con futuras actualizaciones en respuesta a vulnerabilidades del n\u00facleo. La empresa se compromete a mejorar la comunicaci\u00f3n con sus clientes para mitigar situaciones similares en el futuro.<\/p>\n
Si alguna vez tu VPS reinicia sin aviso, ya sabr\u00e1s la raz\u00f3n detr\u00e1s de esta decisi\u00f3n y a qu\u00e9 riesgos se enfrenta OVHcloud a nivel global.<\/p>\n