Glossaire FinOps mainframe : les termes clés des coûts IBM z/OS
Les termes clés de la gestion des coûts IBM z/OS
S
AWLC — Advanced Workload License Charges
L’Advanced Workload License Charges (AWLC) est le modèle de tarification par défaut des logiciels mainframe IBM. Il calcule les coûts de licence mensuels à partir du pic de consommation de MSU en moyenne glissante sur 4 heures (R4HA), sur l’ensemble des LPAR d’une machine. Comme AWLC lie la facture de tout le mois à une seule période de pic, une seule fenêtre de forte demande peut fixer le coût du mois entier. La plupart des logiciels mainframe IBM, dont z/OS, les middlewares et les utilitaires, sont facturés sous AWLC, sauf si le client a négocié un autre modèle. Maîtriser les pics AWLC par le soft capping, la planification des charges de travail et la gestion dynamique de la capacité est la discipline centrale du FinOps mainframe.
B
Budget Variance Analysis (Analyse des écarts budgétaires)
Dans le FinOps mainframe, l’analyse des écarts budgétaires compare les dépenses MLC prévues aux frais de licence mensuels (MLC) réels, pour comprendre où et pourquoi les coûts se sont écartés des prévisions. La facturation mainframe IBM se calcule sur les périodes de pic de charge et non sur des tarifs fixes. De petits changements dans la planification des charges de travail ou dans les réglages de capacité peuvent donc créer des écarts budgétaires importants. Une analyse des écarts efficace exige une visibilité des coûts quasi en temps réel : attendre la facture mensuelle d’IBM, c’est trop tard pour corriger. Zetaly Cost Control (ZCC) suit en temps réel le budget prévu et le réel, et vous alerte avant que les seuils de consommation ne soient dépassés.
C
Capacity Planning (Planification de capacité)
La planification de capacité mainframe prévoit les besoins de traitement futurs. Elle vérifie que le système dispose d’assez de capacité CPU pour tenir les niveaux de service, sans gonfler inutilement les coûts de licences logicielles. Dans le cloud, la capacité s’ajuste plus facilement. Sur le mainframe, la capacité détermine directement les frais de licence mensuels (MLC). Surdimensionner une LPAR, c’est payer une capacité que vous n’utilisez pas. Une bonne planification aide à équilibrer capacité de performance et coût, un arbitrage propre aux environnements IBM z/OS. Des outils automatisés comme ZAC ajustent en continu, en temps réel, la capacité définie des LPAR : la planification de capacité classique devient plus dynamique et plus économe.
Chargeback / showback (refacturation interne)
Dans le FinOps mainframe, le chargeback répartit les coûts logiciels mainframe réels entre les entités métier ou les applications qui les ont générés. Chaque équipe devient ainsi financièrement responsable de sa consommation. Le showback en est une version plus légère : les coûts sont communiqués aux entités métier pour information, sans transfert financier formel. Les deux pratiques exigent une visibilité fine des coûts au niveau des LPAR et des charges de travail, une capacité centrale de Zetaly Cost Control (ZCC). Avec le chargeback ou le showback, la gestion des coûts mainframe cesse d’être une ligne du budget informatique central et devient une responsabilité financière partagée dans toute l’entreprise.
Cloud FinOps vs. Mainframe FinOps (FinOps cloud vs FinOps mainframe)
Le FinOps cloud gère et optimise les dépenses sur les plateformes de cloud public (comme AWS, Azure et Google Cloud), où les coûts varient selon la consommation de ressources et peuvent être suivis en détail. Le FinOps mainframe applique des principes de gestion financière similaires aux environnements IBM z/OS, mais les facteurs de coût sont très différents. Au lieu d’une facturation à l’heure, les coûts mainframe sont fixés par les frais de licence mensuels (MLC), calculés sur le pic de consommation de MSU selon AWLC, TFP et CMP. Les environnements mainframe impliquent aussi des contrats IBM de long terme, la complexité de l’architecture en LPAR et des questions de planification des charges de travail sans équivalent dans le cloud. Les outils FinOps cloud ont vite gagné en maturité, mais le FinOps mainframe exige des outils spécialisés, comme Zetaly Automated Capacity (ZAC) pour l’optimisation de la facturation AWLC et Zetaly Service Intelligence (ZSI) pour l’observabilité mainframe.
CMP — Country Multiplex Pricing
Le Country Multiplex Pricing (CMP) est une option de tarification des logiciels mainframe IBM qui regroupe les machines d’un même pays sous une seule facture, dans le modèle AWLC. La facturation repose sur le pic combiné de toutes les machines : CMP convient donc aux entreprises qui gèrent de la capacité sur plusieurs CPC dans un même pays. ZAC prend en charge nativement les environnements CMP : il gère l’allocation de capacité sur toute la structure CMP et lisse le pic de facturation R4HA à l’échelle de plusieurs machines. Le choix entre AWLC, CMP et TFP dépend des profils de charge, de l’implantation géographique et des conditions du contrat IBM de chaque entreprise.
CPC — Central Processor Complex
Le Central Processor Complex (CPC) est le système mainframe IBM physique : l’unité matérielle qui contient l’ensemble des processeurs, de la mémoire et des ressources d’entrée/sortie. Un CPC peut être divisé en plusieurs partitions logiques (LPAR), chacune avec son propre système d’exploitation et ses propres charges de travail. La capacité totale de traitement du CPC, mesurée en MSU, fixe le plafond de toutes les charges de travail de la machine. C’est un facteur clé des modèles de tarification comme CMP et TFP. Pour le FinOps, connaître la capacité du CPC est indispensable pour fixer des limites de capacité définie justes sur les LPAR et éviter les mauvaises surprises de facturation.
O
Defined Capacity, DC (Capacité définie)
La capacité définie (DC) est un réglage de LPAR qui plafonne la quantité maximale de traitement CPU, mesurée en MSU, que la partition peut consommer à un instant donné. Elle s’applique via le Workload Manager (WLM) de z/OS, en tenant compte des charges de travail : elle limite les pics de consommation sans bloquer complètement l’exécution des tâches prioritaires. Fixer une capacité définie adaptée sur chaque LPAR est l’un des moyens les plus directs de maîtriser les frais de licence mensuels (MLC), puisque la facturation repose sur le pic de consommation de MSU et non sur l’usage moyen. Des outils automatisés comme ZAC ajustent en continu les réglages de capacité définie, en temps réel, pour équilibrer dépenses et qualité de service.
H
Hard Capping
Le hard capping est une configuration de LPAR qui fixe un plafond absolu de consommation CPU : la partition ne peut en aucun cas dépasser la limite de MSU définie, quelle que soit la demande. Le hard capping garantit un maximum de facturation prévisible. Mais il peut priver de CPU les charges de travail critiques pendant les pics de demande, avec un risque de dégradation du service ou de non-respect des SLA (accords de niveau de service). Le hard capping est donc un outil de maîtrise des coûts grossier, comparé au soft capping ou à la gestion dynamique de la capacité définie. La plupart des stratégies FinOps mainframe des grandes entreprises préfèrent au hard capping des outils d’optimisation automatisée de la capacité, qui ajustent les limites en temps réel selon la priorité des charges de travail.
HMC — Hardware Management Console
La Hardware Management Console (HMC) est un poste de travail dédié qui sert à surveiller, gérer et configurer les composants matériels d’un Central Processor Complex (CPC) mainframe IBM. Elle donne une visibilité sur l’utilisation des processeurs et l’état des LPAR, et signale les événements matériels sur l’ensemble du parc mainframe. Pour le FinOps, les réglages de capacité définie des LPAR et les données d’événements matériels, accessibles via les API connectées à la HMC, peuvent guider des décisions d’optimisation des coûts en temps réel. Certains outils FinOps mainframe, dont Zetaly Automated Capacity (ZAC), utilisent les API de la HMC pour lire et modifier automatiquement la configuration de capacité des LPAR.
I
IBM z/OS
IBM z/OS est le principal système d’exploitation des mainframes IBM (IBM Z). Il est conçu pour le traitement transactionnel à haute disponibilité et à haut débit dans les grandes entreprises. La plupart des frais de licence mensuels (MLC) d’un mainframe viennent de z/OS et des middlewares IBM qui tournent dessus. Le système d’exploitation est donc à la fois le cœur de l’exploitation mainframe et le premier facteur de coût du point de vue FinOps. Comprendre l’architecture z/OS, dont la structure des LPAR, les règles du Workload Manager et les licences sub-capacity, est indispensable pour pratiquer un FinOps mainframe efficace. Les entreprises qui utilisent z/OS sont le public principal des plateformes FinOps mainframe comme Zetaly.
IMSU — Instantaneous MSU
L’Instantaneous MSU (IMSU) mesure en temps réel le rythme de traitement CPU consommé à un instant précis, exprimé en millions d’unités de service. Contrairement à la moyenne glissante sur 4 heures (R4HA), qui lisse les pics sur quatre heures, l’IMSU reflète le rythme de traitement brut, d’un instant à l’autre. Il peut dépasser largement le R4HA lors de courtes pointes de charge. Pour la facturation, l’IMSU ne détermine pas directement les MLC (c’est le R4HA qui le fait). Mais en suivant l’IMSU en temps réel, vous voyez si un pic de charge dure assez longtemps pour peser sur la facture. Les outils avancés de gestion de la capacité surveillent l’IMSU en continu pour décider intelligemment du soft capping avant que les pics n’apparaissent dans le R4HA.
IPLA — International Program License Agreement
L’International Program License Agreement (IPLA) est le modèle de licence d’IBM pour les logiciels mainframe facturés par un paiement unique (OTC, one-time charge), puis par des frais annuels d’abonnement et de support (ASC). L’IPLA couvre des outils et des utilitaires, distincts des produits facturés en frais de licence mensuels (MLC). Les produits MLC sont facturés chaque mois selon la consommation. Les produits IPLA, eux, sont achetés au départ, avec des frais de support récurrents. Les équipes FinOps mainframe qui gèrent le coût logiciel total doivent savoir si un logiciel est facturé en MLC ou en IPLA.
IT Cost Transparency (Transparence des coûts)
Dans le contexte du mainframe, la transparence des coûts informatiques est la capacité de voir, quasi en temps réel, d’où viennent les coûts logiciels mainframe, par LPAR, application, entité métier ou charge de travail. Pendant longtemps, la facturation mainframe a fonctionné comme une « boîte noire » : les équipes recevaient des factures IBM mensuelles et avaient peu de moyens d’attribuer les coûts à des activités ou à des services précis. Les plateformes FinOps mainframe modernes comme Zetaly Cost Control (ZCC) croisent les données d’utilisation IBM avec les conditions réelles du contrat pour montrer vos dépenses en détail. La transparence des coûts est la condition de toutes les autres pratiques FinOps : on ne peut pas optimiser ce que l’on ne voit pas.
L
LPAR — Logical Partition (partition logique)
Une partition logique (LPAR) est une subdivision des ressources physiques d’un mainframe IBM (CPU, mémoire et entrées/sorties) qui fonctionne comme un système virtuel indépendant, avec son propre système d’exploitation et ses propres charges de travail. Un seul mainframe IBM (CPC) peut héberger des dizaines de LPAR en même temps : les entreprises peuvent ainsi regrouper plusieurs charges de travail sur un matériel partagé. Pour le FinOps, la LPAR est l’unité principale de maîtrise des coûts. Les frais de licence mensuels (MLC) sont calculés sur le pic de consommation de MSU des LPAR, et les contrôles de capacité comme la capacité définie et le soft capping se règlent au niveau de la LPAR. Gérer la capacité définie des LPAR est le moyen le plus direct de réduire les MLC sans dégrader les performances.
M
FinOps mainframe
Le FinOps mainframe applique les principes de la gestion financière des opérations (FinOps), comme la collaboration entre équipes, la visibilité des coûts en temps réel et l’optimisation éclairée, aux environnements mainframe IBM. Le FinOps cloud gère une tarification variable, fondée sur la consommation, sur les plateformes de cloud public. Le FinOps mainframe, lui, traite les facteurs de coût propres à IBM z/OS : les frais de licence mensuels (MLC) calculés sur le pic de consommation de MSU, les modèles de tarification IBM complexes (AWLC, TFP, CMP) et la gestion de la capacité des LPAR. Le FinOps mainframe aide les entreprises à mieux maîtriser l’un de leurs coûts informatiques les plus élevés et les moins transparents, avec en général une baisse de 5 à 20 % des MLC, sans perte de performance ni de qualité de service. Les entreprises peuvent déployer le FinOps mainframe en combinant des outils de visibilité des coûts (comme Zetaly Cost Control (ZCC)) et des plateformes d’optimisation automatisée de la capacité (comme Zetaly Automated Capacity (ZAC)).
MIPS — Millions of Instructions Per Second
Le MIPS (millions d’instructions par seconde) est une mesure classique de la vitesse des processeurs mainframe : le nombre d’instructions que le processeur peut exécuter par seconde. Le MIPS a longtemps servi d’indicateur de la capacité mainframe et des licences logicielles. Ces dernières années, IBM l’a largement remplacé par le MSU (millions d’unités de service) comme unité officielle de tarification logicielle dans les modèles actuels. Dans la pratique, les deux termes s’emploient souvent l’un pour l’autre, même chez les praticiens expérimentés. Pour parler des coûts FinOps mainframe et de la facturation IBM, le MSU est l’unité techniquement correcte. Le MIPS est un terme historique, encore courant dans les échanges quotidiens sur le mainframe.
MLC — Monthly License Charges (frais de licence mensuels)
Les frais de licence mensuels (MLC) sont le modèle de facturation à l’usage qu’IBM applique aux logiciels mainframe, dont z/OS, les middlewares et les utilitaires. Les coûts MLC sont calculés chaque mois sur le rythme de traitement maximal (mesuré en MSU) consommé par les logiciels IBM sur le mainframe, en général selon la méthode de la moyenne glissante sur 4 heures (R4HA). Comme les MLC reposent sur le pic de consommation et non sur l’usage moyen ou total, une seule période de forte demande peut fixer le coût du mois. Maîtriser les MLC est le principal défi du FinOps mainframe. C’est le premier facteur de coût que des outils peuvent piloter. Zetaly Automated Capacity (ZAC) gère le pic de facturation R4HA des charges de travail facturées sous AWLC. Zetaly Data Platform (ZDP) et Zetaly Service Intelligence (ZSI) donnent de la visibilité sur les données d’exploitation du mainframe, quel que soit le modèle de tarification.
MSU — Millions of Service Units (millions d’unités de service)
Le MSU (millions d’unités de service) est l’unité standard d’IBM pour mesurer la capacité de traitement CPU du mainframe et la consommation des charges de travail, pour les licences logicielles. Un MSU représente environ un million d’unités de service de base de travail de traitement par heure, calibrées pour chaque modèle de matériel. IBM utilise les valeurs de MSU, avec la méthode de la moyenne glissante sur 4 heures (R4HA), pour calculer les frais de licence mensuels (MLC) des logiciels mainframe. Comprendre et gérer activement la consommation de MSU des LPAR est la base du FinOps mainframe, car réduire les pics de MSU est le principal moyen de baisser les MLC.
O
On/Off Capacity on Demand (On/Off CoD)
L’On/Off Capacity on Demand (On/Off CoD) est une fonction d’IBM qui permet d’activer temporairement de la capacité processeur supplémentaire sur le matériel mainframe, pour des périodes courtes et définies. Elle sert en général à absorber des pics de charge saisonniers sans payer cette capacité en permanence. L’On/Off CoD apporte de la souplesse, mais il faut la gérer avec soin du point de vue FinOps : activer de la capacité supplémentaire augmente les MSU disponibles du CPC, ce qui peut relever les pics MLC et faire monter les frais de licence mensuels au-delà du coût de base prévu. Les équipes FinOps mainframe doivent suivre l’usage de l’On/Off CoD en même temps que la planification de capacité et les prévisions MLC, pour éviter les mauvaises surprises en fin de mois.
P
Parallel Sysplex
Un Parallel Sysplex est un ensemble de mainframes IBM (CPC) qui fonctionnent comme un seul système logique. Il permet le partage des charges de travail, la haute disponibilité et une facturation regroupée sur l’ensemble. Dans une configuration Parallel Sysplex, les mainframes sont reliés par un matériel spécialisé, le Coupling Facility, qui permet le partage instantané des bases de données, des files de travail et des tâches de traitement. Pour le FinOps, un Parallel Sysplex peut ouvrir droit aux Parallel Sysplex License Charges (PSLC), qui regroupent la facturation sur toutes les machines de l’ensemble au lieu de la calculer machine par machine. C’est un avantage de coût possible pour les entreprises aux environnements prévisibles et très utilisés. Pour gérer coûts et performances sur un Sysplex, il faut une visibilité sur tout l’ensemble, et pas seulement machine par machine.
Parallel Sysplex License Charges (PSLC)
Les Parallel Sysplex License Charges (PSLC) sont un mode de facturation IBM ouvert aux entreprises qui exploitent une configuration Parallel Sysplex qualifiée. Les coûts de licences logicielles y sont regroupés sur toutes les machines de l’ensemble au lieu d’être calculés machine par machine. Pour être éligible, le Sysplex doit respecter les règles de participation d’IBM : au moins deux mainframes éligibles, reliés physiquement par des liens de couplage (coupling links) et un Sysplex Timer, et des images participantes qui représentent au moins 50 % de la charge z/OS totale de chaque machine. Les PSLC peuvent offrir un avantage de coût aux environnements multi-machines très utilisés, en répartissant la facturation sur toute la capacité de l’ensemble.
E
R4HA — Rolling 4-Hour Average (moyenne glissante sur 4 heures)
La moyenne glissante sur 4 heures (R4HA) est la méthode de calcul d’IBM qui détermine le pic de consommation de MSU pour la facturation des frais de licence mensuels (MLC). IBM calcule une moyenne glissante sur 4 heures de l’utilisation CPU pendant chaque jour du mois et prend la valeur R4HA la plus haute comme base de la facture MLC du mois. Un pic de charge bref mais soutenu, qui dure à peine quelques heures, peut donc fixer le tarif du mois entier. Comprendre le R4HA est capital pour le FinOps mainframe. Les stratégies de maîtrise des coûts doivent viser à éviter les pics R4HA par le soft capping et la planification des charges de travail, avec la capacité de gérer la capacité des LPAR en temps réel.
S
SCRT — Sub-Capacity Reporting Tool
Le Sub-Capacity Reporting Tool (SCRT) est un utilitaire fourni par IBM qui produit les rapports d’utilisation nécessaires aux licences sub-capacity. Il permet aux entreprises de payer les MLC selon la consommation réelle des charges de travail, et non selon la capacité matérielle totale du CPC. Le SCRT collecte les enregistrements SMF (System Management Facilities) de z/OS et produit des rapports mensuels qu’IBM utilise pour vérifier la facturation des modèles comme AWLC et TFP. Pour le FinOps mainframe, les données SCRT sont la source de référence sur la consommation réelle des logiciels IBM. Des outils comme Zetaly Data Platform (ZDP) peuvent traiter les données SMF avec les conditions du contrat et fournir des calculs de coûts rapides et précis. Sans reporting SCRT exact, les entreprises s’exposent à des erreurs de facturation ou à des problèmes de conformité avec les conditions de licence IBM.
SMF — System Management Facilities
System Management Facilities (SMF) est le sous-système de z/OS qui collecte en continu les données d’activité du système sur tout le mainframe. Les enregistrements SMF de type 70 (activité CPU) et de type 89 (utilisation des produits) sont les principales sources de données des calculs de facturation des logiciels IBM. Ils alimentent directement le Sub-Capacity Reporting Tool (SCRT), qui produit les rapports de licence mensuels. Ces données sont indispensables au FinOps mainframe. Des outils comme Zetaly Data Platform (ZDP) collectent et traitent les enregistrements SMF dès que z/OS les écrit : les équipes disposent de données de consommation à jour au lieu d’attendre le lendemain les rapports SCRT classiques.
Soft Capping
Le soft capping est une technique de configuration des LPAR qui limite la consommation CPU par les règles du Workload Manager (WLM) de z/OS et les réglages de capacité définie, sans l’arrêt net du hard capping. Contrairement au hard capping, le soft capping tient compte de la priorité des charges de travail. Par exemple, le WLM ralentit d’abord les charges de travail les moins prioritaires pour rester sous la limite de MSU définie, et protège ainsi les transactions prioritaires du manque de CPU. Le but du soft capping est de maîtriser la moyenne glissante sur 4 heures (R4HA), qui se traduit en frais de licence mensuels (MLC), tout en préservant la qualité de service des charges de travail critiques. Des outils comme ZAC vont plus loin : ils ajustent la capacité définie en temps réel pour gérer le pic de facturation R4HA, au lieu de s’appuyer sur des réglages statiques configurés à la main.
SAM — Software Asset Management (gestion des actifs logiciels)
La gestion des actifs logiciels (SAM) consiste à suivre, gérer et optimiser les licences logicielles d’une entreprise tout au long de leur cycle de vie, de l’achat au retrait, en passant par le déploiement et l’utilisation. Pour le mainframe, le SAM couvre à la fois les produits MLC (z/OS, middlewares, utilitaires facturés chaque mois sur le pic de consommation de MSU) et les produits IPLA (outils et utilitaires en paiement unique). Un SAM mainframe efficace exige un inventaire précis de ce qui est installé sur chaque LPAR, de ce qui est réellement utilisé, et du respect des conditions de licence IBM. L’accumulation de logiciels (produits déployés mais peu utilisés ou redondants) est un problème fréquent, relevé lors des revues SAM mainframe, et elle pèse sur les MLC. Le SAM mainframe rejoint aussi la conformité du reporting SCRT : les entreprises doivent s’assurer que leurs rapports Sub-Capacity Reporting Tool reflètent fidèlement les produits installés, pour éviter un risque d’audit IBM.
Sub-Capacity Licensing
Les licences sub-capacity sont une approche de tarification mainframe IBM : les entreprises paient les logiciels selon la consommation réelle de MSU de chaque LPAR, et non selon la capacité totale de la machine physique (CPC). Sans licence sub-capacity, une entreprise qui fait tourner plusieurs LPAR sur un grand mainframe paierait ses logiciels sur la capacité de toute la machine, même si la plupart des LPAR ne sont pas utilisées à pleine capacité. Les modèles sub-capacity, dont AWLC et TFP, gardent vos coûts proportionnels à la taille réelle des charges de travail. C’est pourquoi ils sont la norme dans la plupart des installations mainframe des grandes entreprises. L’éligibilité aux licences sub-capacity exige de respecter les obligations de reporting SCRT d’IBM. Le suivi de la consommation par LPAR est donc au centre de la gestion des coûts en sub-capacity.
Sysplex — System Complex
Un Sysplex (System Complex) est un ensemble de systèmes mainframe IBM (CPC) couplés pour fonctionner comme un seul système logique. Ils partagent charges de travail et données pour la haute disponibilité et l’évolutivité. Dans un Parallel Sysplex, la configuration la plus avancée d’IBM, les mainframes sont reliés par un matériel spécialisé, le Coupling Facility, qui permet le partage en temps réel des bases de données, des files de travail et des tâches de traitement. Pour le FinOps, le Sysplex complique la gestion des coûts : les charges de travail peuvent passer d’un système à l’autre, ce qui rend plus difficiles le suivi des MSU par LPAR et l’attribution de la facturation sur l’ensemble. Les entreprises qui exploitent des environnements Sysplex ont besoin d’outils de visibilité et d’optimisation des coûts qui couvrent tout l’ensemble, et pas seulement chaque machine.
T
TFP — Tailored Fit Pricing
Le Tailored Fit Pricing (TFP) est un modèle de tarification des logiciels mainframe IBM qui propose une mensualité fixe, fondée sur un accord négocié sur les types de charges de travail et les niveaux de consommation, au lieu d’une facturation variable sur le pic de consommation de MSU. Le TFP existe en deux grandes variantes. L’Enterprise Capacity facture un forfait pour un usage illimité de z/OS dans des catégories de charges de travail définies. Le Container Pricing applique un forfait à un ensemble défini de charges de travail éligibles. Pour les entreprises aux charges de travail prévisibles, le TFP peut apporter une certitude sur les coûts et des économies possibles par rapport à la facturation sur le pic d’AWLC. Mais les contrats TFP exigent une classification rigoureuse des charges de travail et un suivi de conformité. C’est pourquoi les entreprises qui passent au TFP ont intérêt à utiliser des outils d’observabilité comme Zetaly Data Platform (ZDP) et Zetaly Service Intelligence (ZSI), pour garder la maîtrise des coûts et décider à mesure que l’expertise mainframe interne évolue.
W
WLM — Workload Manager
Le Workload Manager (WLM) de z/OS est un composant du système d’exploitation IBM qui répartit automatiquement le CPU, la mémoire et les entrées/sorties entre les charges de travail concurrentes d’un mainframe. Il donne la priorité au travail selon son importance pour l’activité, et non selon son ordre d’arrivée. Le WLM s’appuie sur des règles de classes de service définies par les administrateurs, qui précisent quelles charges de travail passent en priorité et lesquelles peuvent être ralenties quand le système approche d’une limite de ressources. Pour le FinOps, le WLM applique le soft capping et les réglages de capacité définie : c’est lui qui choisit les charges de travail à ralentir à l’approche d’un plafond de MSU. Sans règles WLM bien configurées, les réglages de maîtrise des coûts peuvent pénaliser des transactions métier prioritaires.
Z
ZAC — Zetaly Automated Capacity
Zetaly Automated Capacity (ZAC) est une solution logicielle mainframe qui gère automatiquement, en temps réel, les réglages de capacité définie des LPAR pour réduire les frais de licence mensuels (MLC), sans dégrader la qualité de service. ZAC surveille en continu la consommation de MSU des LPAR et ajuste la capacité définie selon la priorité des charges de travail et l’exposition de facturation du moment, pour gérer le pic de facturation R4HA avant qu’il ne se forme. Les clients qui utilisent ZAC obtiennent en général une baisse de 5 à 20 % de leurs MLC dès le démarrage, sur plus de 30 déploiements en entreprise. ZAC agit sur toutes les charges de travail facturées sous AWLC, y compris les environnements de développement et de test des clients TFP.
En savoir plus sur ZACZCC — Zetaly Cost Control
Zetaly Cost Control (ZCC) est une solution d’analyse FinOps mainframe qui vous donne une visibilité quasi en temps réel sur les coûts des logiciels IBM, par LPAR, application et entité métier. ZCC traite les données SCRT avec les conditions réelles du contrat IBM, dont les structures de tarification AWLC et TFP, pour calculer des coûts MLC exacts dans la devise choisie par le client et lui montrer plus clairement d’où viennent ses coûts mainframe. ZCC facilite une gestion budgétaire anticipée grâce à des alertes de consommation, ainsi que la répartition des coûts et les rapports de refacturation par entité métier ou par application.
En savoir plus sur ZCCZDP — Zetaly Data Platform
Zetaly Data Platform (ZDP) est le produit de collecte de données mainframe de Zetaly. Il fonctionne avec tous les modèles de tarification IBM (AWLC et TFP). ZDP collecte en continu les données d’exploitation du mainframe, comme les enregistrements SMF, les journaux système, DCOLLECT et les journaux IMS, en utilisant moins de 0,2 % des ressources du mainframe. Comme cette surcharge est minime, les clients TFP peuvent surveiller intensivement leurs environnements sans gonfler la baseline qu’IBM utilise pour calculer leurs coûts TFP. ZDP alimente Zetaly Service Intelligence (ZSI) pour les tableaux de bord et les rapports, mais les clients peuvent aussi l’utiliser seul, avec leur propre outil de reporting.
En savoir plus sur ZDPZRP — Zetaly Resource Planning
Zetaly Resource Planning (ZRP) est une solution d’analyse prédictive pour la planification de la capacité et des coûts mainframe. ZRP construit des plans de capacité pluriannuels en combinant l’historique des charges de travail avec des données d’activité prévisionnelles (croissance prévue, nouvelles charges de travail, fusions ou changements de configuration) pour prévoir les besoins d’infrastructure et l’exposition aux coûts MLC. Son moteur de simulation permet aux équipes de modéliser plusieurs scénarios et d’en comparer les effets sur la capacité et les coûts avant de s’engager sur des choix de matériel ou de configuration. Les résultats comprennent des plans de capacité dans le temps, des recommandations d’architecture et de dimensionnement par CPC, et des estimations de consommation MLC par LPAR.
En savoir plus sur ZRPZSI — Zetaly Service Intelligence
Zetaly Service Intelligence (ZSI) est le produit de reporting et d’observabilité de Zetaly, construit sur les données collectées par Zetaly Data Platform (ZDP). ZSI produit des tableaux de bord et des rapports à partir des données d’exploitation du mainframe, organisés par métier : des publics non spécialistes peuvent lire les indicateurs mainframe et agir, sans dépendre d’un expert mainframe pour les traduire. ZSI fonctionne avec tous les modèles de tarification IBM. Il est le plus utile quand l’expertise mainframe interne diminue et que les équipes métier doivent décider à partir des données du mainframe.
En savoir plus sur ZSIzIIP — IBM Z Integrated Information Processor
Un zIIP (IBM Z Integrated Information Processor) est un processeur spécialisé des mainframes IBM, conçu pour décharger les processeurs généraux de certaines charges de travail : Java, traitement XML, certaines tâches de bases de données et certaines fonctions de middleware. La capacité de traitement des zIIP n’est pas soumise aux mêmes coûts de licences logicielles IBM que la consommation des processeurs généraux (CP, Central Processor). Déporter les charges de travail éligibles vers les zIIP peut donc réduire nettement les frais de licence mensuels (MLC). Du point de vue FinOps mainframe, maximiser l’utilisation des zIIP est l’une des stratégies de long terme les plus efficaces pour alléger la structure des coûts MLC. Elle exige toutefois une analyse des charges de travail pour repérer les traitements éligibles, et parfois des changements d’applications ou de configuration. Les produits de Zetaly, dont ZAC, ZDP et ZSI, aident les équipes à suivre l’utilisation des processeurs, y compris celle des zIIP, dans une stratégie complète d’optimisation des coûts.
zNALC — z New Application License Charge
Le z New Application License Charge (zNALC) est une option de tarification MLC à coût réduit pour les LPAR qui exécutent sur z/OS des nouvelles applications qualifiées. Il vise à encourager le développement de nouvelles charges de travail sur le mainframe. Les charges de travail éligibles qui tournent dans une LPAR qualifiée zNALC profitent de tarifs de licences réduits. Développer et déployer de nouvelles applications sur le mainframe devient ainsi plus intéressant financièrement que de les migrer vers d’autres plateformes. Les équipes FinOps mainframe qui gèrent un environnement mixte, avec des charges de travail AWLC classiques et de nouvelles applications éligibles au zNALC, doivent tenir compte de cette différence de tarif dans leurs scénarios de coûts et leur planification de capacité.