¿Cuáles son las ventajas y desventajas de un plan de recuperación ante desastres en la nube?

El problema con los planes de recuperación ante desastres rara vez es del lado de la tecnología: al final del día, puede elegir la tecnología que desee para garantizar la recuperación en caso de desastre.

El mayor problema parece ser el componente humano: he visto muchas organizaciones gastar tiempo y dinero en desarrollar un plan, solo para ponerlo en un cajón y verlo una vez al año (en el mejor de los casos).
Sin embargo, un año es mucho tiempo y, mientras tanto, cada organización sufre cambios significativos.

En teoría, los cambios técnicos ya deberían estar reflejados en su plan debido a su (con suerte) proceso de cambio que funciona perfectamente. Debe garantizar que toda su documentación esté actualizada, incluido su DRP.

Sin embargo, el cambio más grande está en el lado humano: garantizar que tenga acceso a todos los contactos relevantes, tanto a nivel de proveedor como a nivel interno, está resultando ser bastante difícil. Los planes que revisé en el pasado tenían información de contacto desactualizada y un tercio de las personas mencionadas en ellos (tanto dentro de la empresa como a nivel de proveedor) ya no estaban disponibles por varias razones.

Es fácil pensar en un plan de recuperación ante desastres como un problema de TI. Pero es un problema de negocios porque requiere la aceptación en muchos niveles (por ejemplo: los roles en el Plan DR deben ser parte de la descripción del trabajo de los empleados. Cuando un jugador clave abandona la organización, RR.HH. y el departamento respectivo deben asegurarse que alguien más puede asumir el papel y TI debe estar informado sobre el cambio)

Descargo de responsabilidad: en este momento estoy trabajando en una aplicación web que facilitará la implementación y el mantenimiento de este tipo de planes. Siéntase libre de registrarse en Kreelu, la aplicación Framework Management, si desea recibir una notificación cuando se lance.

Sam ha hecho algunos puntos muy buenos sobre los pros y los contras literales de un plan de recuperación ante desastres basado en la nube. En mi opinión, uno realmente necesita pensar que cualquier nivel de grupo de recursos (Datacenter, IaaS Cloud, Servers, etc.) como otro activo para ayudar a producir una solución tolerante a fallas. Cuando administro servidores en una nube, siempre enfatizo que mis clientes siguen una práctica de construcción para fallar donde el enfoque debe estar más en la agilidad y el corto tiempo para desplegar recursos adicionales en un momento de necesidad o simplemente para poner en pie nuevos recursos para migrar cargas de trabajo existentes a. En ese sentido, tener un plan de recuperación ante desastres que utiliza una nube como opción de recuperación ante desastres no está mal en absoluto. Hay muchos pasos involucrados que deben tomarse para garantizar que su entorno siga siendo funcional después de ejecutar cualquier tipo de plan de DR, por lo que no veo cómo el uso de la nube cambia ese hecho.

Si desea explorar una solución que le permita implementar sus cargas de trabajo en una cantidad cada vez mayor de grupos de recursos en la nube mientras le permite administrar completamente los sistemas en la nube, debe considerar RightScale http://www.rightscale.com

Además de ser una gran herramienta para administrar implementaciones en la nube grandes y pequeñas, el marco de configuración utilizado en RightScale ServerTemplate le permite utilizar exactamente el mismo marco de configuración para sus servidores (digamos que la aplicación, la base de datos son ejemplos en los que pensar) y poder aprovisionarlos en cualquiera de las muchas nubes compatibles (AWS, Rackspace, Datapipe, Softlayer, Logicworks y más). Esto es muy valioso ya que no tiene que reinvertir el esfuerzo en los esfuerzos de reconstrucción y solución de problemas debido a un cambio en la configuración entre dos entornos que puede llamar PROD y DR 🙂: ¡el proceso de configuración se vuelve idéntico independientemente del grupo de recursos en la nube en el que elija implementar! Esto ahorra un montón de esfuerzo al final y le permitirá volver rápidamente a sus sistemas a un estado operativo con muchas nubes diferentes para elegir.