Qué es el criterio de facturación
Las infraestructuras tecnológicas están dimensionadas para prestar servicio al número máximo de peticiones previstas. Los proveedores de infraestructuras facturan por diferentes criterios, entre los que se encuentran las líneas base o los picos máximos de consumo de la instalación, y dentro de estos modelos hay multitud de combinaciones.
Existen diferentes modelos de facturación: citamos dos modelos comunes a título ilustrativo de los sistemas zOS donde existen decenas de modelos:
- RXH: El consumo de MIPS media en un periodo horario determinado: 3, 4 o 6 horas (R3H, R4H, R6H).
- Media de picos: Se toma el pico máximo diario de 10, 20 días o todos los días del mes.
Las aplicaciones afectan a los costes de la infraestructura tecnológica:
Las aplicaciones consumen CPU y también producen archivos o registros que deben ser almacenados en el sistema de storage.
- En el caso del consumo de CPU o procesador, como ejemplo podemos encontrar los MIPS o MSU en los sistemas zOS y otros criterios en el caso de Cloud.
- El Storage se traduce en una cantidad de Gigabytes que deben ser almacenados en discos, bien se pueden facturar estos “Gigas” utilizados o los discos.
De forma continua se identifican la línea base y los picos que afectan a la facturación, vigilando e inventariando aquellos TOP que afectan al consumo de la instalación
Ilustramos un ejemplo en el ámbito de pico de factura:
Al inicio del proyecto se parametriza la fórmula de facturación:
- Identificada la formula de facturación, se trabajará en inventariar aquellos TOP que por su horario de ejecución sean los principales responsables del consumo.
- Utilizaremos nuestra tecnología propia BOA (Cloud) con algoritmos, esto nos permitirá, de forma automatizada:
- Identificación diaria del 100% procesos que afectan a factura.
- Todos los caminos críticos que afecten a SLA.
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…
Picos de consumo, concentración e ineficiencias detectadas son cruzadas para calcular el ahorro de cada una de las actuaciones:
Transacciones Online
Generalmente muy pocos elementos (entorno al 2% del total) concentran la mayor parte del consumo.
Procesos Batch en horario online
En horario Online de máximo pico encontramos procesos Batch que podrían ser optimizados, rebajando su consumo o replanificados llevando el consumo de estos a una franja que no afecte a factura.
Procesos Batch nocturnos
Identificamos los procesos batch más consumidores del segundo pico, ya que la rebaja de consumo del primero puede ocasionar que cambie el criterio de facturación y el segundo pico se convierta en el primero.
Las métricas de consumo junto con las ineficiencias detectadas en los TOP nos ofrecerán un escenario de Ahorro global.
Para alcanzar el ahorro propuesto se llevarán a cabo diferentes soluciones:
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.
Procesos Batch Online
En horario Online de máximo pico encontramos procesos Batch que podrían ser optimizados, rebajando su consumo o replanificados llevando el consumo de estos a una franja que no afecte a factura.
Procesos Batch nocturos
Identificamos los procesos batch más consumidores del segundo pico, ya que la rebaja de consumo del primero puede ocasionar que cambie el criterio de facturación y el segundo pico se convierta en el primero.
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.