La reciente crisis mundial causada por una actualización defectuosa muestra una vez más que todo cambio a los ambientes productivos requiere ser validado y certificado. Si ha tenido problemas causados por efectos inesperados fruto de un cambio, su proceso de certificación requiere ser mejorado.
¿Es esto algo ajeno o imposible de evitar? Ni lo uno ni lo otro. Las lecciones son múltiples y es necesario aprender de ellas. El manejo de caídas de hardware, al ser variables conocidas (red, disco, memoria, CPU, energía), pueden automatizarse y hoy día generalmente se cuenta con dicha protección.
Pero ¿qué pasa cuando la caída es por daños lógicos de la información o del software? En estos casos, primero hay que encontrar el origen del problema, lo más complicado y demorado, y luego desarrollar y aplicar la solución. Todo esto implica procesos no automatizables, con tiempos no previsibles, siendo la peor pesadilla para cualquier empresa que brinde servicios con software.
¿Cómo entonces blindarse contra crisis provenientes de cambios al software? ¿Es posible? La respuesta es sí. Esto se logra teniendo un proceso de certificación de cambios a producción que sea exhaustivo y real en cuanto a las consecuencias posteriores al cambio, y por otro lado, teniendo la capacidad de comparar y encontrar esas diferencias para determinar su solución.
Con esto sería suficiente en un mundo perfecto donde las personas que administran el proceso de certificación sean infalibles. Aunque generalmente sea exitoso, es indispensable tener un plan de acción seguro para los casos donde no sea así, donde tengamos que reversar. Y esto es posible si se tiene la capacidad de regresar en el tiempo.
Todo lo anterior es la razón de ser de dbFlashCopy, que habilita de forma inmediata ambientes alternos de producción para todo uso. Uno de ellos son los ambientes de certificación, o como máquina del tiempo para los datos, regresando en el tiempo con precisión de segundos, protegiendo datos y servicios para usuarios de Oracle y MySQL.
