Gestion du cycle de vie CI CMDB (héritée)
Entre le moment de sa création et le moment où il n’est plus nécessaire, un CI CMDB passe généralement par plusieurs états opérationnels tout en subissant diverses opérations. Gestion du cycle de vie des CI fournit le mécanisme permettant de définir des états et des actions pour un CI et vous permet d’appliquer les actions appropriées en fonction de l’état d’un CI afin d’adapter la gestion du cycle de vie des CI aux besoins de l’entreprise.
Le gestionnaire de données CMDB est désormais une solution plus complète et intégrée pour la gestion en bloc des opérations du cycle de vie des CI, telles que la suppression et l’archivage. Pour en savoir plus sur le gestionnaire de données CMDB, reportez-vous à la section .
- États opérationnels
- Ensemble d’états dans lesquels un CI peut se trouver, par exemple « Opérationnel » ou « Réparation en cours ». Un CI ne peut être associé qu’à un seul état opérationnel à la fois. Les choix des états opérationnels sont basés sur le operational_status champ de la table [cmdb_ci]. Plusieurs états opérationnels sont définis dans le système de base, tels que « Hors service » et « Réparation en cours ». Vous pouvez modifier cette liste pour refléter les états opérationnels pertinents pour votre entreprise. Remarque :La gestion du cycle de vie des CI permet à plusieurs opérateurs et automatisations de définir simultanément différents états opérationnels d’un CI. Un CI ne pouvant pas être associé à plusieurs états opérationnels, il est important de configurer chaque état opérationnel avec une priorité. Ces priorités sont ensuite utilisées dans une telle situation pour déterminer lequel des états opérationnels est l’état opérationnel cumulatif.Par défaut, Mappage des services est configuré pour ignorer tous les CI hôtes pour lesquels la valeur État opérationnel [operational_status] n’est pas 1 (Opérationnel) ou la valeur État [install_status] est 100 (absent). Pour plus d’informations sur ce comportement, consultez Préparation de déploiements ServiceNow personnalisés pour l’utilisation de Service Mapping [KB0647574] dans la base de connaissances HI.
- Actions de CI
- Ensemble d’actions qui peuvent être appliquées à un CI au cours de sa durée de vie. Vous pouvez définir les actions de CI qui sont pertinentes pour votre entreprise.
- Actions de CI compatibles
- Gestion du cycle de vie des CI permet à un CI d’avoir plusieurs actions de CI actives simultanément, mais elles doivent être spécifiquement définies comme compatibles. Par défaut, il n’y a pas deux actions compatibles l’une avec l’autre pour un CI. Vous pouvez modifier ce comportement en spécifiant des paires d’actions compatibles et donc autorisées à être appliquées simultanément à un CI. Par exemple, vous pouvez spécifier que les actions de CI « Application de correctif » et « Mise en service » sont compatibles, ce qui permet d’appliquer les deux simultanément à un CI.
- Actions de CI non autorisées
- Par défaut, n’importe quelle action de CI peut être appliquée à n’importe quel CI. Vous pouvez restreindre ce comportement en définissant une règle selon laquelle une action n’est pas autorisée pour un CI lorsqu’il se trouve dans un état opérationnel spécifique. Par exemple, vous pouvez définir une action de CI non autorisée dans laquelle il n’est pas permis d’appliquer l’action « Mise en service » à un serveur Linux dans un état « Non opérationnel ».
- Transitions opérationnelles non autorisées
- Par défaut, les transitions sont autorisées de n’importe quel état opérationnel à un autre. Vous pouvez restreindre ce comportement en définissant une règle selon laquelle, pour un CI spécifié, une transition d’un certain état opérationnel à un autre état opérationnel n’est pas autorisée. Par exemple, vous pouvez définir que pour un serveur Linux, il n’est pas autorisé de passer de « Réparation en cours » à « Non opérationnel ».
- Demandeur
- Un demandeur peut être un opérateur de workflow ou un opérateur n’appartenant pas au workflow qui tente de définir des états opérationnels et d’appliquer des actions de CI. Chaque demandeur a un ID de demandeur associé qui est un GUID et qui peut être un contexte de workflow actif ou un ID d’opérateur non enregistré dans le workflow.
- Heure du bail
- Période que chaque demandeur (en particulier les opérateurs ne faisant pas partie du workflow) peut fournir, pendant laquelle une action de CI spécifiée est autorisée à être active pour un CI spécifié.
CMDB CI Lifecycle Management fournit un ensemble d’API pour gérer les états opérationnels des CI et les actions des CI. Et l’interface utilisateur dans laquelle vous définissez un ensemble de règles pour restreindre certaines transitions d’états opérationnels et restreindre les actions en fonction des états opérationnels. Il fournit également un mécanisme permettant d’auditer l’état opérationnel et les actions des CI pendant tout le cycle de vie du CI.
Les fournisseurs tels que l’automatisation, les workflows ou Gestion des changements peuvent utiliser Gestion du cycle de vie des CI comme mécanisme de gestion des états opérationnels des CI et appliquer des actions de CI. Par défaut, le comportement de Gestion du cycle de vie des CI n’a aucune restriction sur certaines opérations et des restrictions complètes sur d’autres opérations. L’interface utilisateur de Gestion du cycle de vie des CI vous permet de modifier ce comportement par défaut en spécifiant les actions de CI non autorisées, les actions de CI compatibles et les transitions opérationnelles non autorisées qui limitent certaines opérations et en activent d’autres.
- Gérez les états opérationnels et les actions des CI tout au long de leur cycle de vie.
- Gérez les transitions d’états opérationnels des CI.
- Restreindre certaines transitions d’états opérationnels.
- Associez certaines actions à certains types de CI qui sont dans un état opérationnel spécifique.
- Restreindre les applications Gestion des services IT basées sur l’état opérationnel du CI.
- Auditez les états opérationnels et les actions des CI pendant tout le cycle de vie du CI.
API de gestion du cycle de vie
Gestion du cycle de vie des CI fournit un ensemble d’API pour gérer l’état opérationnel et les actions des CI tout au long de leur cycle de vie. Toutes les restrictions et autorisations spécifiées par les règles de l’interface utilisateur sont appliquées lors de l’exécution des API de gestion des états. Si une API tente d’effectuer une opération restreinte, l’opération est bloquée et une erreur est consignée.
Enregistrement des demandeurs
Lorsque vous utilisez les API de gestion du cycle de vie pour appliquer des actions de CI, les demandeurs doivent être enregistrés et obtenir un ID de demandeur unique dans les tables de gestion du cycle de vie. Pour s’inscrire et obtenir un ID de demandeur, les utilisateurs ne faisant pas partie du workflow doivent appeler l’API registerOperator . Les utilisateurs de workflow peuvent utiliser le contexte de workflow actif comme ID du demandeur et ils n’ont pas besoin d’appeler explicitement registerOperator.
Une fois les opérations de cycle de vie du CI terminées, le demandeur doit appeler l’API unregisterOperator pour annuler l’inscription. Tous les enregistrements de gestion des états associés à cet ID de demandeur spécifique sont alors marqués comme inactifs ou supprimés par la CI Lifecycle Management — Restore Internal State Management Tables tâche planifiée.
Intégration avec Gestion des incidents et Gestion des problèmes
Une instance de base inclut l’action CreateTask de CI prédéfinie utilisée pour créer une tâche pour un CI. Les nouvelles instances ont une action de CI non autorisée prédéfinie, spécifiant que l’action « CreateTask » n’est pas autorisée pour tout CI ayant un état opérationnel Mis hors service . Cette restriction est intégrée avec Gestion des incidents et avec Gestion des problèmes pour empêcher la création de tâches d’incident ou de problème pour les CI mis hors service. L’action de CI « CreateTask » est utilisée comme qualificatif de référence pour le Configuration Item champ des tables Incident/Problème. Lors d’un nouvel incident ou d’un nouveau problème, les CI dont Operational Status la valeur est « Mis hors service » sont exclus de la Configuration Item liste du formulaire. Pour plus d’informations sur les qualificatifs de référence, reportez-vous à la rubrique Qualificatifs de référence .
Intégration à Gestion des actifs
- Lorsqu’un Operational Status champ passe de l’état Hors service à un autre état, le champ /Hardware Status du StatusCI est défini sur Installé.
Lorsqu’un Statuschamp CIHardware Status /passe de Mis hors service à un autre état, le Operational Status champ est automatiquement défini sur Non opérationnel.
Le changement d’état de « Hors service » à un autre état est rarement, et par défaut, l’état est changé en « Non opérationnel ». Toutefois, il se peut que ce ne soit pas l’état prévu pour l’enregistrement. Par conséquent, il est important que les administrateurs examinent et gèrent l’état de manière appropriée dans ce cas.
Chaque fois qu’un StatusHardware Status CI change, il est synchronisé avec le champ correspondant Asset State du CI, et vice versa, ce qui permet de synchroniser le CI Operational Status et le CI correspondantAsset State.
Pour plus d’informations sur le mappage Asset State et Substate les champs au champ /Hardware Status (s’il s’agit du matériel) d’un CI, consultez Mapper l’état de l’actif et l’étatStatus matériel du CI. Et pour plus d’informations sur la mise hors service d’actifs, voir Mettre hors service des actifs.