Getty Images
Les défis de la CMDB à l’ère DevOps
Si les CMDB sont encore appréciées, elles ne dominent plus la gestion IT. Découvrez les options d’intégration de la CMDB qui subsistent et pourquoi les administrateurs doivent envisager d’autres solutions que ces logiciels.
Les CMDB, ou bases de données de gestion des configurations, sont apparues comme la source unique de vérité concernant les aspects les plus importants d’un environnement IT. Les experts s’appuient sur cette source pour administrer les changements, maintenir la sécurité et la conformité, gérer les coûts et les performances de l’informatique, ainsi que le dépannage et la gestion des incidents.
Mais les CMDB sont loin d’être parfaites.
Par exemple, elles peuvent nécessiter un travail manuel fastidieux. Leur utilité dépend de la fraîcheur, de l’exactitude et de l’exhaustivité des données qu’elles contiennent. Les informations d’une CMDB peuvent devenir inexactes ou incomplètes alors que les professionnels IT s’efforcent d’accomplir d’autres tâches urgentes. Cela entraîne une érosion progressive de la qualité des données relatives aux actifs et aux configurations.
Alors que le rythme des développements s’accélère et que l’environnement IT devient plus accessible aux équipes DevOps et aux utilisateurs métiers, il est impossible d’ignorer les défis des CMDB. Comment un développeur peut-il provisionner rapidement des ressources et des services pour une nouvelle application si la CMDB est obsolète ou imprécise, voire inexistante ? Des pratiques telles que l’approche DevOps exigent plus de flexibilité que ne peut l’offrir une CMDB standard. D’où la question suivante : Sous l’ère DevOps, la CMDB est-elle obsolète ?
Qu’est-ce qu’une CMDB ?
En termes simples, une base de données de gestion de configurations est un référentiel qui stocke des listes d’informations et de dépendances sur un large éventail de biens informatiques, appelés éléments de configuration (IC). Ces éléments comprennent le matériel, les logiciels, les réseaux, les détails de l’emplacement physique, les documents et différents supports.
Les premières CMDB n’étaient rien de plus que des listes ou des bases de données, voire des tableurs nécessitant la saisie et la mise à jour manuelles des informations. Au fur et à mesure que les CMDB ont évolué, des fonctions supplémentaires de découverte et d’importation de données ont permis de simplifier et d’accélérer les enregistrements, en recueillant des logs directement auprès des CI ou diverses sources, comme d’autres bases de données.
Idéalement, une CMDB possède un ensemble complet de renseignements sur chaque élément CI de l’environnement IT de l’entreprise. La CMDB peut s’accompagner d’outils permettant d’interroger, de trier, de filtrer, d’établir des graphiques (visualisation) et des rapports sur le contenu de la CMDB. Ces interactions offrent une visibilité sur l’environnement informatique. Les administrateurs s’assurent que tout fonctionne comme installé ou comme prévu.
Comment la CMDB et l’approche DevOps interagissent-elles ?
Les paradigmes de programmation agile tels que le DevOps ont déclenché une révolution dans la création et la livraison d’applications et de services. En permettant la collaboration entre les équipes de développement et d’exploitation, on obtient – en principe – des logiciels plus adaptables, plus efficaces et de meilleure qualité. Les CMDB ont joué un rôle dans cette révolution, dans la mesure où les données et les informations qu’elles contiennent autorisent des déploiements, un dépannage et une réponse aux incidents plus rapides, ainsi qu’une conformité et une gestion des changements plus rigoureuses.
Mais les outils et les solutions CMDB cèdent sous la pression croissante exercée par la prolifération des ressources, les demandes de modification accrues et la montée en puissance de plateformes et de pratiques de gestion plus pertinentes. Dans ces environnements, la CMDB se heurte aux activités DevOps de deux manières :
- L’augmentation des types de ressources et de leurs volumes
L’objectif initial de la CMDB était principalement de piloter le matériel physique, c’est-à-dire effectuer une gestion des actifs. Les CMDB se sont étendues aux actifs immatériels, à savoir les logiciels et les services. Aujourd’hui, la plupart des entreprises prennent couramment en charge une série de biens virtuels, tels que les VM, les conteneurs et les ressources en cloud, que les équipes DevOps utilisent à chaque déploiement. Désormais, la CMDB doit assurer le suivi des 10 VM exécutées sur un serveur physique et suivre les dépendances entre les VM et le serveur physique. La complexité sans cesse croissante est difficile à gérer pour les CMDB.
- Des changements toujours plus rapides
Non seulement les CMDB doivent faire face à un nombre beaucoup plus important de CI dans l’environnement, mais ces éléments apparaissent et changent aussi plus rapidement que certaines CMDB ne peuvent le supporter.
Par exemple, un serveur physique traditionnel est installé dans le centre de données et, une fois configuré, fonctionne sans être modifié pendant cinq ans. Mais une machine virtuelle créée à des fins d’évaluation et de test ne fonctionne que quelques mois, avant d’être retirée et détruite une fois l’évaluation terminée. Et un conteneur virtuel peut être déployé, exécuté et mis hors service en quelques minutes, voire en quelques secondes. Même avec une automatisation et des flux de travail bien pensés, le rythme de création et de modification des données pousse les technologies CMDB à leurs limites.
Des alternatives aux CMDB adaptées à l’approche DevOps
Les CMDB sont appelées à contenir et à restituer d’énormes quantités de données, notamment les détails financiers de chaque actif, les profils de performance et de configuration, l’historique des mises à niveau et des modifications, ainsi que d’autres détails qui peuvent être totalement sans rapport avec l’utilisation réelle de l’actif. Ainsi, on attend parfois des CMDB qu’elles en fassent trop et qu’elles dépassent leurs capacités. Certaines organisations IT cherchent à remplacer la CMDB par une alternative plus efficace, telle que la gestion du cycle de vie des applications (ALM), afin de concentrer l’attention sur les applications et les services, plutôt que sur les ressources sous-jacentes.
Il est temps de moderniser la CMDB
Les équipes IT et DevOps ont toujours besoin de systèmes solides et d’une gestion des changements, mais les CMDB ne suffisent peut-être pas à répondre à l’ampleur et au rythme opérationnel des infrastructures modernes. Heureusement, il existe quelques stratégies simples qui permettent de remédier aux limites de la CMDB.
Réévaluer et recentrer les CMDB. Déterminez si une entreprise a besoin de la portée et du contenu d’une base de données de gestion de configurations. Les CMDB ont vu le jour lorsque les data centers étaient relativement petits et statiques. Une source unique de vérité, dont la portée était limitée et dont le contenu était rarement modifié, était un objectif pratique, même s’il était géré manuellement. Les exigences de l’informatique actuelle peuvent signifier qu’il n’est pas pratique, voire impossible, d’établir et de maintenir cette source unique de vérité de manière fiable.
Demandez-vous si une CMDB doit réellement contenir des détails aussi complets pour l’ensemble de l’environnement. Les organisations IT peuvent réduire et recentrer les CMDB pour répondre à des attributs ou à des objectifs spécifiques, comme le suivi des composants et des ressources essentiels à la mission.
Améliorer les CMDB. Les CMDB avancées peuvent inclure des fonctions de découverte améliorées, qui permettent de mieux trouver et interroger les entités physiques et virtuelles. Du point de vue du processus ou du flux de travail, les mises à jour de la CMDB sont liées à l’autorisation, à l’approvisionnement et à la gestion du cycle de vie, ce qui permet de s’assurer que toute modification de l’environnement, telle que le cycle de vie des machines virtuelles, est saisie dans l’outil de gestion des configurations.
Recherchez d’autres outils qui alimentent et vérifient les CMDB. Ces outils incluent généralement des capacités de machine learning et d’IA, qui permettent à l’outil d’apprendre comment l’environnement fonctionne et de fournir des données de manière autonome aux CMDB et aux autres services.
Supprimer et remplacer les CMDB. Évaluez si d’autres outils de gestion et de surveillance sont plus pertinents. Aujourd’hui, les DSI se concentrent principalement sur la maintenance des applications et des services. L’infrastructure sous-jacente – ce qui est déployé, où il se trouve et qui en est le propriétaire, par exemple – est souvent une considération secondaire. Une dernière alternative consiste à déprécier et à retirer les CMDB au profit d’autres outils hautement automatisés qui fournissent des fonctionnalités de découverte, de rapport, d’audit et de gestion des changements dont l’entreprise a besoin.
Par exemple, l’accent mis aujourd’hui sur la gestion des applications et des services conduit à l’adoption de plateformes de gestion du cycle de vie des applications ou de cadres plus complets de gestion des opérations et des services IT. Faites appel à des outils automatisés, tels que Chef ou Ansible, pour faciliter la découverte, le déploiement et la gestion des configurations.
Au-delà des CMDB pour le DevOps
Comme de plus en plus de développeurs gèrent les tâches liées aux opérations, il est essentiel de comprendre les ressources et les services présents dans l’entreprise, ainsi que la façon dont ces actifs sont configurés. Ce type d’information aide les exploitants à provisionner de nouvelles ressources et aux développeurs à déployer les dernières versions de logiciels avec précision et en toute sécurité. Les CMDB ont longtemps été le rempart de ces efforts, mais elles ne sont peut-être plus la meilleure source unique de vérité dans des environnements dynamiques et complexes.
Les organisations DevOps délaissent les CMDB d’autrefois pour adopter des plateformes normalement plus légères et plus polyvalentes, telles que ServiceNow, Now Platform, CloudBees CI, Red Hat Ansible Automation Platform, SaltStack, TeamCity et d’autres. Attention toutefois à la problématique de cybersécurité : CMDB ou non, ces outils de gestion de configuration peuvent faire l’objet d’attaques particulièrement dévastatrices. Multiplier les outils n’est pas forcément une mauvaise idée.
