Estaba participando en un hilo reciente en la comunidad de OTN donde alguien estaba haciendo preguntas sobre la degradación después de una actualización de la base de datos. Una de las respuestas preguntó cuántas personas realmente practican la degradación de la base de datos. Creé esta encuesta para averiguarlo.
Me sorprendió encontrar una contribución a ese hilo que decía:
Ahora bien, ese cartel no lo dijo explícitamente, pero era casi como si esa persona estuviera diciendo que practicar degradaciones era una pérdida de tiempo porque nunca lo necesitarían. Le daré al cartel el beneficio de la duda y que este empleado de Oracle en realidad no estaba diciendo esto. No estoy tratando de meterme con este individuo. Dejaré que este hilo me brinde la oportunidad de discutir el tema desde un punto de vista más genérico. (Actualización: el posteador que me impulsó a escribir esta entrada de blog volvió al hilo en el tiempo que me llevó escribir esto y dijo:"No pretendía implicar que no deberíamos 'probar' las degradaciones".)
En julio, escribí una publicación de blog sobre The Data Guardian. En esa publicación de blog, dije:
El DBA necesita proteger los datos. Ese es el trabajo #1. El trabajo #2 es para que el DBA proporcione acceso eficiente y oportuno a los datos. ¿De qué sirve tener los datos si las personas que necesitan acceder a ellos no pueden acceder a los datos? Si esas personas tienen un rendimiento terrible cuando interactúan con los datos, es posible que no tengan acceso.
Como DBA, debemos realizar la gestión de riesgos. Necesitamos determinar qué riesgos podrían convertirse en realidad. El trabajo de los DBA es medir esos riesgos y determinar dos planes de acción. ¿Qué pasos se pueden tomar para evitar que ese riesgo se convierta en realidad y qué pasos debo tomar para resolver el problema cuando ese riesgo se convierta en realidad?
Incluso un DBA de nivel junior comprenderá la importancia de las copias de seguridad. Las copias de seguridad son una estrategia de gestión de riesgos. Si se pierden datos, podemos recuperar los datos de la copia de seguridad. E incluso un DBA de nivel junior comprende la importancia de poder restaurar desde la copia de seguridad.
En este hilo de OTN, escribí esto:
Para mí, esto es algo así como la Ley de Murphy. He dicho cosas similares en el pasado. La idea (y es el punto central de esta entrada de blog) es que si no tomo los pasos apropiados de gestión de riesgos, entonces solo le pido a los dioses que conviertan ese riesgo en realidad. Si me niego a ajustar mi espejo retrovisor y lo uso cuando estoy retrocediendo mi vehículo, bueno, ese es el día en que retrocedo en algo. Si me niego a atarme los cordones de los zapatos, bueno, ese es el día en que piso uno y tropiezo. El día que me niego a usar gafas protectoras cuando uso una herramienta eléctrica es el día en que tengo algo en el ojo. El día que voy a la playa y me niego a ponerme protector solar es el día que volveré a casa con una quemadura solar. Entiendes la idea.
Algunos lectores pueden estar pensando que estoy loco y que el universo no tiene este plan maestro para joderme solo porque estoy siendo complaciente. Y estaría de acuerdo. Entonces, lo diré de otra manera, si no planeo mitigar el riesgo, entonces no he hecho nada para evitar que se convierta en una realidad. Las posibilidades de que se haga realidad no disminuyen por mi inacción.
Hay dos componentes principales en la gestión de riesgos. 1) determinar la probabilidad de que ocurra ese elemento de riesgo y 2) determinar el impacto cuando ese riesgo ocurra. Los elementos que tienen la mayor probabilidad de ocurrir se mitigan primero. Esto es fácil y es algo que muchas personas que trabajan en gestión de riesgos suelen hacer. Colocan los elementos de riesgo en una hoja de cálculo y completan algún valor para la probabilidad de que ocurra ese riesgo. Cuando se completan, clasifican en la columna de probabilidad y comienzan la mitigación de riesgos de arriba hacia abajo. Muchas estrategias de gestión de riesgos dibujan una línea en algún lugar en el medio de la lista y deciden que cualquier elemento de riesgo debajo de esa línea tiene una probabilidad demasiado baja de que no nos preocupemos por ese elemento de riesgo. No podemos mitigar todos los riesgos posibles en el universo. Simplemente no hay suficiente tiempo para manejarlo todo. Así que tenemos que trazar la línea en alguna parte.
Una de las fallas que veo todo el tiempo es que la gestión de riesgos no dedica mucho tiempo a centrarse en el impacto de que ese riesgo se convierta en realidad. La hoja de cálculo debe incluir una columna similar que brinde una calificación del impacto en el negocio para ese elemento de riesgo. El administrador de riesgos también debe clasificar la hoja de cálculo en esta columna. ¡Cualquier elemento que tenga un gran impacto debe tener actividades de mitigación de riesgos, incluso si ese elemento tiene una baja probabilidad de ocurrir! Lamentablemente, muchos en el negocio de la gestión de riesgos no incluyen este paso de evaluar el impacto del riesgo. Nuevamente, cuando la hoja de cálculo se ordena por impacto en el negocio, se dibuja una línea en alguna parte.
Uno puede encontrar que los elementos de riesgo con una ALTA probabilidad tener un impacto BAJO o incluso MUY BAJO al negocio Me gustan las hojas de cálculo de gestión de riesgos que incluyen una tercera columna que es "probabilidad x impacto". Esta columna ayuda a comprender la relación entre los dos componentes de riesgo.
Volvamos a la pregunta de actualización de la base de datos que provocó esta publicación de blog. Creo que todos los que lean este artículo de blog deberían estar de acuerdo en que actualizar una base de datos de Oracle es una propuesta arriesgada. Hay tantas cosas diferentes que podrían salir mal con una actualización de la base de datos de Oracle. La probabilidad de un error de actualización es ALTO. Los elementos de mitigación de riesgos a menudo incluyen, entre otros, practicar la actualización en clones de producción y hacer una copia de seguridad de la base de datos antes de que comience el proceso de actualización. ¿Por qué hacemos esto? Bueno, el impacto al negocio es MUY ALTO. Si fallamos al actualizar nuestra base de datos de producción, nuestros usuarios comerciales no tendrán acceso a los datos. No somos muy buenos guardianes de datos si no podemos superar esta falla. Si practicamos la actualización lo suficiente en entornos que no son de producción, podemos reducir la probabilidad del elemento de riesgo a MEDIO. Pero con toda probabilidad, no podemos reducir esa probabilidad de riesgo específico a BAJA. Es por eso que realizamos la copia de seguridad antes de que comience la actualización. Aún debería haber problemas a pesar de que hemos hecho todo lo posible para reducir la probabilidad de ese elemento de riesgo, el impacto al negocio sigue siendo MUY ALTO. Por lo tanto, la estrategia de remediación de riesgos del DBA es tomar notas sobre dónde y qué causó que la actualización fallara y restaurar desde la copia de seguridad. La base de datos está funcionando y hemos eliminado el impacto al negocio Luego, el DBA vuelve a la mesa de dibujo para determinar cómo resolver lo que salió mal. El DBA está intentando reducir la probabilidad de que ese problema vuelva a ocurrir cuando regresen en un momento posterior para realizar el proceso de actualización nuevamente.
Así que volvamos al comentario en el hilo de OTN donde parecía decir que no vale la pena practicar las degradaciones de la base de datos. Estoy en desacuerdo. Y mi desacuerdo tiene todo que ver con el impacto al negocio Estoy de acuerdo con el comentario que dijo el cartel en su respuesta.
Estoy de acuerdo con eso al 100%. ¿Por qué hacemos esta “prueba exhaustiva”? Todo se debe a la mitigación de riesgos. Estamos intentando reducir la probabilidad que la actualización causará un bajo rendimiento o hará que la funcionalidad de la aplicación se rompa. Pero incluso como decía ese cartel, "siempre habrá problemas que aparecerán en producción después de la actualización porque es imposible probar el 100% de su aplicación". Nuevamente, estoy 100% de acuerdo con lo que dice este cartel aquí. Pero, ¿qué pasa con el impacto al negocio? Llegaré a eso en un minuto, pero primero tengo que desviarme un poco en el siguiente párrafo...
Recientemente actualicé un sistema de producción crítico de 11.2.0.4 a la versión 12.1.0.2. Donde trabajo, tenemos más pruebas de aplicaciones de las que he visto en mis otros trabajos. Contamos con un equipo completo de control de calidad que realiza las pruebas por nosotros. Incluso tenemos un equipo que está a cargo de nuestros esfuerzos de prueba automatizados. Contamos con robots automatizados que ejercitan el código de nuestra aplicación todas las noches. Además de todo eso, tenemos otra rutina automatizada que cada vez que las personas envían cambios de código a Test o Prod, esta rutina realiza un examen rápido de las rutas de código críticas. Actualicé los entornos de desarrollo (más de 15 de ellos) a 12.1.0.2 y luego esperé un mes. Luego actualicé Test y esperé 3 semanas antes de actualizar la producción. Se encontraron y resolvieron problemas antes de que actualizáramos la producción. Pero incluso después de todo eso, tuve grandes problemas una vez que se actualizó la producción. Puede visitar las publicaciones de mi blog desde mediados de octubre hasta mediados de diciembre para ver algunos de esos problemas. Estuve muy cerca de degradar esta base de datos, pero logré solucionar los problemas. Ahora volvamos al punto que estaba diciendo...
Una vez completada la actualización, la base de datos se abre para el negocio. Los usuarios de la aplicación ahora pueden usar la aplicación. ¿Qué sucede dentro de la base de datos en este punto? ¡Actas! Y las transacciones significan cambios de datos. En el momento en que el DBA abre la base de datos para el negocio después de que se completa una actualización, comienzan a ocurrir cambios en los datos. Después de todo esto, ese es el objetivo de la base de datos, ¿no es así? Capture los cambios de datos y haga que los datos estén disponibles para los usuarios finales de la aplicación.
Entonces, ¿qué sucede si estás en el barco que yo estaba el otoño pasado con la actualización de mi base de datos? Estaba golpeando cosas que no vimos en la no producción, incluso después de todas nuestras pruebas. El impacto al negocio era ALTO. Necesito poder reducir este impacto en el negocio. Tenía tres opciones. 1) Solucione los problemas, uno por uno. 2) Restaurar desde la copia de seguridad que hice antes de la actualización para poder recuperar la base de datos a la versión anterior. 3) Degradar la base de datos y volver a la mesa de dibujo. Elegí la primera opción. como siempre lo he hecho durante mi carrera. Pero, ¿y si eso no fuera suficiente? Puede llevar tiempo resolver los problemas. Algunas empresas simplemente no pueden permitirse ese tipo de tiempo con ese impacto negativo. al negocio ¿Cuántos sitios web se han abandonado porque el rendimiento era terrible o las cosas no funcionaban correctamente? Y para la gran mayoría de las bases de datos de producción, la opción 2 tiene un impacto terrible. al negocio! ¡Perderá transacciones después de que se complete la actualización! El DBA no podrá avanzar más allá de la actualización mientras mantiene la base de datos en la versión anterior, por lo que los datos se perderán y, para muchas bases de datos de producción, esto es inaceptable. La empresa puede permitirse una hora de pérdida de datos, pero ¿cuántas personas apretarían el gatillo de esta acción dentro de una hora de la actualización? Con toda probabilidad, esta acción se realizaría días después de la actualización y el impacto para el negocio por ese tipo de pérdida de datos está muy por encima de MUY ALTO. Eso deja a la opción 3 como la opción con el impacto más bajo. a la empresa para ayudar a resolver cualquier impacto que experimente la empresa después de la actualización.
Probablemente pueda deducir del último párrafo que creo que es importante que el DBA de Oracle sepa cómo degradar su base de datos después de completar una actualización. Admito que la probabilidad del DBA que necesita realizar una degradación es MUY BAJO. Pero el impacto de no degradar puede ser catastrófico para el negocio. (Aquí están esas dos palabras otra vez). Porque la probabilidad es bajo, no suelo bajar de categoría, pero debido al impacto de no poder bajar de categoría es muy alto, los practico de vez en cuando.
Entonces, para terminar, voy a volver a eso de la Ley de Murphy nuevamente. El universo no está conspirando en mi contra, pero como Data Guardian, necesito practicar buenos principios de gestión de riesgos. Eso significa evaluar la probabilidad y el impacto de los elementos de riesgo impuestos por mi cambio. Si bien es posible que el universo y los dioses no hagan que la Ley de Murphy o sus primos se pongan en marcha, no me estoy haciendo ningún favor al mitigar los elementos de riesgo. No estoy reduciendo la probabilidad ni un poco.
