Política de Post-implantación

En un anterior post, indicábamos que dentro del enfoque DevOps actual, es necesario incorporar una nueva fase al ciclo de vida de desarrollo para controlar el rendimiento de los componentes (DevPerOps) mediante una Oficina Técnica de Rendimiento (OTR) de continua y como, antes de que los componentes promocionen a producción, es posible establecer ciertos controles que aseguren unos estándares de calidad y rendimiento mínimo, política de promoción.

No obstante, a pesar de establecer reglas previas en entornos previos, en producción es el único entorno en el que va a ser posible medir todas las métricas y su correlación con factores de negocio.

Para que exista una adecuada política de post-implantación, deben existir dos componentes básicos:

1. Control sobre que componentes suben a producción para obtener la fecha en la que un componente se ha dado de alta, baja o ha sufrido una modificación.

2. Ejecuciones correctas de los componentes software tras su puesta en producción, que permita evaluar cambios de comportamiento en cualquier métrica asociada al proceso modificado.

Estos dos puntos son vitales a la hora de establecer un mecanismo de control en los elementos que suben a producción y evaluar su impacto en los procesos de negocio.

La política post-implantación tiene en cuenta los siguientes elementos, generando un informe de salida con el OK o NOK antes de pasar a la plena productividad.

●  Se tendrá un informe sobre si el elemento ya ha sido evaluado en un entorno previo a producción “política de promoción”, lo que servirá de base para saber si ya se han corregido ineficiencias de forma proactiva.

●  Desde un equipo centralizado se prestará atención a los procesos que tras su implantación afecten a cualquier proceso de negocio, consumiendo un mínimo establecido y aquellos elementos que incrementen en un determinado porcentaje sus métricas asociadas de rendimiento respecto a la versión previa de producción.

✔   Si todo es correcto y no supera ningún umbral de los marcados pasara a plena producción.

✘   En caso contrario, se remitirá el componente al aplicativo para su revisión generando una incidencia para la corrección del software.

●  Deberá existir un compromiso por parte del aplicativo para su corrección en un tiempo limitado, entrando dentro de la garantía del proveedor por detección temprana en producción.

Con este mecanismo de control se detectarán que todos aquellos elementos que no se han podido evaluar entornos previos, evaluándose inmediatamente después de su puesta en producción, reduciendo el tiempo de corrección y mitigando su impacto en los procesos de negocio.

Además, detectar casos con problemas de rendimiento tras su implantación en producción, conlleva varios beneficios:

●  Asegurar el rendimiento óptimo de cualquier elemento software.

●  Solución de manera temprana a ineficiencias en el software en periodo de garantía.

●  Disminución de los costes tras la detección temprana de su impacto.

●  Controlar como afecta el ciclo de desarrollo a los procesos de negocio (porcentaje del total de cambios con impacto tras la subida a producción)

●  Ranking de aplicaciones y proveedores de software con relación al rendimiento del software en función de las incidencias detectadas.

Sólo en el entorno de producción es viable validar el rendimiento de un componente software y su impacto en los principales objetivos de negocio de los clientes (Costes, SLA y Tiempos de respuesta), a partir de una evaluación de las métricas asociadas a un elemento individual tras su puesta en producción, Post-Implantación.

0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir!

Deja una respuesta

Tu dirección de correo electrónico no será publicada.