Las aplicaciones afectan a los costes de la infraestructura tecnológica:
Objetivo: Reducción del consumo de CPU
Las aplicaciones consumen CPU y también producen archivos o registros que deben ser almacenados en el sistema de storage.
Ilustramos un ejemplo en el ámbito de pico de factura:
- Al inicio del proyecto se parametriza la fórmula de facturación.
- Identificada la fórmula de facturación, se trabajará en inventariar de forma continua aquellos elementos que por su horario de ejecución sean los principales responsables del consumo, tanto en pico principal, picos secundarios o líneas base.
Utilizaremos nuestra tecnología propia BOA (Cloud) con algoritmos, esto nos permitirá, de forma automatizada:
- Identificar de forma diaria del 100% procesos que afectan a factura y sus cambios de comportamiento.
- Identificar todos los caminos críticos que afecten al cumplimiento de SLA o ANS
Mapa de las ineficiencias que afectan al sistema:
- Con la información técnica se confecciona un mapa de las ineficiencias que afectan al sistema. Identificamos más de 270 ineficiencias en el código, diseño, ingeniería y parametrización.
Ejemplo ineficiencias consumidoras de MIPS BATCH zOS
- DB2: Entre el 10% y el 30% de los elementos que generan sobrecostes pueden mejorar su acceso a BBDD: índices no utilizados, tablas sin índice cluster, exceso de campos en índices, descargas duplicadas…
- Otros: procesos obsoletos, asignación primaria y secundaria, pasos de copia poco eficientes, archivos VTS vs Disco, reducción de llamadas a módulos o rutinas…
- Programas: deletes o insert masivos, cursor por select, matchings, inicializaciones de estructuras grandes, reducción de llamadas a rutinas, Bucles de código…
- SORT: unificación de pasos SORT y duplicados, registros vacíos en, parametrización, Cambio MERGE, acortar archivos, INREC / OUTREC, mejora Joinkeys…
Para alcanzar el ahorro propuesto se ofrecen soluciones en las diferentes áreas de la infraestructura y aplicaciones:
Conociendo el mapa de ineficiencias y de consumos se realiza la planificación de actuaciones que rebajarán el consumo de los picos del sistema.
Estas actuaciones pueden ser:
Vigilancia de las nuevas subidas de software
Anualmente entre el 30% y el 45% de los elementos tecnológicos que componen las aplicaciones son sustituidos. Continuamente se generan multitud de nuevas versiones de los elementos en producción.
Estas modificaciones, realizadas por motivos funcionales o regulatorios, suelen aumentar el consumo de CPU de la instalación y aumentar los tiempos de respuesta o de entrega de datos.
Identificamos que ratio de nuevos desarrollos impactan en el consumo.
Transacciones Online
Generalmente muy pocos elementos (entorno al 2% del total) concentran la mayor parte del consumo.
Se calcula diariamente todas las transacciones TOP que influyen en el criterio de facturación, tanto por su consumo unitario como por su consumo agrupado puesto que existen TOP “ocultos” debido a su volumen de ejecuciones.
Generamos escenarios de ahorro en relación con la optimización de los elementos identificados.
Procesos Batch
En horario de máximo pico encontramos procesos Batch que aumentan al consumo del criterio de facturación. También identificamos procesos superconsumidores que en parte son responsables de segundos picos.
Estos procesos pueden ser optimizados para rebajar su consumo, pero también puede valorarse la replanificación en otro horario que no afecte a factura ni a su SLA.
Pueden encontrarse procesos obsoletos que realizan consumo y los datos generados por ellos ya no son necesarios, por lo tanto podrían no ejecutarse.
Parametrización de la infraestructura.
En ocasiones hay parámetros que no están totalmente alineados con la utilización real de la infraestructura por el negocio digital.
Se estudia la parametrización de la infraestructura para localizar las oportunidades de ahorro y mejora que una configuración diferente nos pueda ofrecer.
Se realiza la revisión de utilidades que afectan al consumo a través de la información nativa del sistema.
Downsizing / Offloading
Identificamos aquellas aplicaciones que podrían ejecutarse en infraestructuras con menor coste y que no complejicen su operación. Se confeccionará un listado de transacciones que por su ROI y criticidad puedan ser objeto de estudio de un proceso de Downsizing, tanto:
Completo: reescritura de código y BBDD.
Parcial: utilización de herramientas de mercado para la reescritura de código o base de datos únicamente.
Storage
Mes a mes aumentan los Gigabytes almacenados y el parque de discos, puede que no todos los datos deban recibir el mismo tratamiento.
El objetivo prioritario es identificar qué tipo de datos se están almacenando para la reducción del aumento de la necesidad de espacio en disco.