Vamos a ser sinceros, nadie se esperaba que un datacenter OVH ardiese quemando todo, ni ellos ni nosotros, tampoco quiero cortar cabezas, prefiero que OVH haya aprendido de sus errores y haga todo lo posible para que estos errores no vuelvan a ocurrir.
Por otro lado, no tenemos que llevarnos las manos a la cabeza diciendo que OVH no son profesionales, son unos inútiles, etc, o no al menos hasta que sepamos (si algún dia sabemos) que ha pasado, porque otra catástrofe parecida ocurría en 2011 cuando el datacenter de Amazon en Irlanda dejaba de funcionar al caer un rayo.
Y si preguntamos a la gente de sistemas descubrimos que desastres como estos han ido ocurriendo a lo largo de la historia, recuerdo uno que ocurrió hace muchos años en un datacenter en EEUU, no recuerdo cual fue el problema, si la solución y fue volcar a cintas de backup de HP y traslada dichas cintas en furgoneta a otro datacenter, como esta existen más historias, y como parece que estamos condenados a que ocurran vamos a ver varios "trucos" para evitar que esto pase.
- Redundancia, podemos tener nuestro proyecto ejecutándose en el datacenter A de nuestro proveedor y por seguridad podemos tener una copia redundante en otro datacenter de nuestro proveedor, será más caro pero también es más seguro y si cae el datacenter A se puede levantar el datacenter B en muy poco tiempo y la cantidad de datos que se ha podido perder puede ser mínima, dependiendo de cuando haya ocurrido la caída.
- Segundo backup de seguridad en otro proveedor diferente al que usamos para alojar la web, así aunque el proveedor principal tenga una perdida total de sus servicios tendríamos la opción de recuperar todo desde este segundo backup de seguridad. Efectivamente en un backup de seguridad las copias se hacen por la noche y se pueden perder horas de trabajo, pero mejor horas que días, meses o incluso años.
- Gestionar las DNS vía Cloudflare o servicio similar, al usar un servicio como Cloudflare las DNS se actualizan rápidamente si es necesario apuntar a la IP de nuevas máquinas, en cambio si usamos el servido estándar de los proveedores de dominios la propagación de DNS puede ser más lenta.
- Automatización, ya sea mediante snapshot de nuestros servidores o usando Ansible u otros productos similares, para poder levantar las máquinas que necesitamos sin necesidad de tener que configurarlas de cero, obviamente los archivos derivados de snapshots habrá que alojarlos también en el segundo backup de seguridad, la ventaja de Ansible es que al ser archivos de configuración de texto plano se pueden alojar en un repositorio de git.
- Usar git y herramientas de despliegue automatizadas como Deployer para que los procesos de despliegue sean automatizados.
Con todos estos elementos, y seguramente muchos más que ahora mismo no tengo en mente desastres como el de OVH se pueden mitigar, y lo importante no es que rueden cabezas, sino aprender del pasado y tener la configuración para que no vuelva a ocurrir en el futuro.
Fuente de la foto: https://twitter.com/avedonnicholas/status/1369577530898976769