Gestion du cycle de vie du CI CMDB (héritée)
De sa création au 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 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 pour adapter la gestion du cycle de vie du 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 gérer les opérations de cycle de vie des CI telles que la suppression et l’archivage, en bloc. Pour en savoir plus sur le gestionnaire de données CMDB, reportez-vous à la section Utilisation du gestionnaire de données CMDB.
- États opérationnels
- Ensemble d’états auxquels 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 d’états opérationnels sont basés sur le operational_status champ dans la table [cmdb_ci]. Plusieurs états opérationnels sont définis dans le système de base, tels que « Mis 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. Étant donné qu’un CI ne peut 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 du statut [operational_status] opérationnel n’est pas 1 (opérationnel) ou la valeur du statut [install_status] est 100 (absent). Pour plus d’informations sur ce comportement, consultez Préparation de déploiements ServiceNow personnalisés pour fonctionner avec 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
- La 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 entre elles pour un CI. Vous pouvez modifier ce comportement en spécifiant des paires d’actions qui sont compatibles et qui peuvent donc ê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 de les appliquer 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 interdisant une action 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 qui est 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 permis de passer de « Réparation en cours » à « Non opérationnel ».
- Demandeur
- Un demandeur peut être un opérateur de workflow ou un opérateur hors workflow qui essaie de définir des états opérationnels et d’appliquer des actions 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é pour un workflow.
- Heure du bail
- Période que chaque demandeur (en particulier les opérateurs qui ne font 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é.
Gestion du cycle de vie des CI CMDB fournit un ensemble d’API pour gérer les états opérationnels 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 pour restreindre les actions en fonction des états opérationnels. Il fournit également un mécanisme pour auditer l’état opérationnel du CI et les actions du CI pendant tout le cycle de vie du CI.
Les fournisseurs tels que l’automatisation, les workflows ou Gestion des changements peuvent utiliser la gestion du cycle de vie des CI comme mécanisme pour gérer les états opérationnels des CI et appliquer des actions de CI. Par défaut, le comportement de la gestion du cycle de vie des CI n’a aucune restriction sur certaines opérations et aucune restriction complète 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 des actions de CI non autorisées, des actions de CI compatibles et des transitions opérationnelles non autorisées qui restreignent certaines opérations et en activent d’autres.
- Gérez les états opérationnels et les actions de CI tout au long du cycle de vie du CI.
- Gérez les transitions d’états opérationnels des CI.
- Restreignez certaines transitions d’états opérationnelles.
- Associez certaines actions à certains types de CI qui sont dans un état opérationnel spécifique.
- Restreindre les applications Gestion des services IT en fonction de l’état opérationnel du CI.
- Auditez les états opérationnels et les actions de 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 des CI et les actions de CI pendant tout le cycle de vie du CI. Toutes les restrictions et allocations spécifiées par les règles de l’interface utilisateur sont appliquées lorsque les API de gestion des états s’exécutent. 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 qui ne font pas partie du workflow doivent appeler l’API registerOperator . Les utilisateurs de workflow peuvent utiliser le contexte de workflow actif comme ID de 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’enregistrement. 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 autorisée pour aucun CI dont l’état opérationnel est Mis hors service . Cette restriction est intégrée 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. Dans un nouvel incident ou problème, les CI dont Operational Status l’état est « Mis hors service » sont filtrés hors de la Configuration Item liste du formulaire. Pour plus d’informations sur les qualificatifs de référence, voir Qualificatifs de référence .
Intégration à Gestion des actifs
- Lorsqu’un Operational Status champ passe de l’étatStatusHors service à un autre état, le champ /Hardware Status du CI est défini sur Installé.
Lorsque l’état/Hardware Statusle champ d’un CI passe de l’étatStatusHors 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 rare, et par défaut, l’état est changé sur « 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 StatusCI /Hardware Status change, il est synchronisé avec le champ correspondant Asset State du CI, et vice versa, en maintenant synchronisé le CI Operational Status et les correspondants Asset State du CI.
Pour plus d’informations sur le mappage et les champs avec un CI / SubstateHardware Status (si son matériel), voir Mapper l’état de l’actif et l’état matériel du CI.StatusAsset State Et pour plus d’informations sur la mise hors service des actifs, voir Mettre hors service des actifs.