Gestion du cycle de vie du CI CMDB (héritée)
Entre 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 au cours de diverses opérations. La gestion du cycle de vie des CI fournit le mécanisme permettant de définir les états et les actions d’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 plus d’informations sur le gestionnaire de données CMDB, reportez-vous à la section Travailler avec Gestionnaire de données CMDB.
- États opérationnels
- Ensemble d’états pouvant se trouver pour un CI, tels que « Opérationnel » ou « Réparation en cours ». Un CI ne peut être associé qu’à un seul état opérationnel à un moment donné. Les choix pour les é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 « Mis hors service » et « Réparation en cours ». Vous pouvez modifier cette liste pour refléter les états opérationnels pertinents dans 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 ê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, Service Mapping 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]100 (absent). Pour plus d’informations sur ce comportement, consultez Préparation des déploiements ServiceNow personnalisés pour travailler 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 des actions de CI pertinentes dans 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 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 indiquant qu’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 autorisé d’appliquer l’action « Mise en service » à un serveur Linux dont l’état est « 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 indiquant que, 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 à un 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 n’appartenant pas aux workflows) peut fournir, au cours de 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 et les actions des CI. Et l’interface utilisateur où 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. Elle fournit également un mécanisme permettant d’auditer l’état opérationnel et les actions du CI pendant tout le cycle de vie du CI.
Les fournisseurs tels que l’automatisation, les workflows ou Change Management 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 Gestion du cycle de vie des CI n’a aucune restriction sur certaines opérations et des restrictions complètes sur d’autres. L’interface utilisateur 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 du CI tout au long du cycle de vie du CI.
- Gérez les transitions d’états opérationnels des CI.
- Limiter certaines transitions d’états opérationnels.
- Associer certaines actions pour certains types de CI qui sont dans un état opérationnel spécifique.
- Restreindre les applications IT Service Management en fonction de l’état opérationnel du CI.
- Auditez les états opérationnels et les actions du CI pendant tout le cycle de vie du CI.
API de gestion du cycle de vie
CI Lifecycle Management fournit un ensemble d’API pour gérer l’état opérationnel et les actions des CI pendant tout le cycle de vie du CI. 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
Lors de l’utilisation des 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 d’un workflow doivent appeler l’API registerOperator . Les utilisateurs de workflow peuvent utiliser le contexte de workflow actif comme ID du demandeur et 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 sont supprimés par la CI Lifecycle Management — Restore Internal State Management Tables tâche planifiée.
Intégration à 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 CI non autorisée prédéfinie, spécifiant que l’action « CreateTask » n’est autorisée pour aucun CI ayant un état opérationnel mis hors service . Cette restriction est intégrée avec Gestion des incidents et pour Gestion des problèmes 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 qualificateur de référence pour le Configuration Item champ des tables Incident/Problème. Dans le cas d’un nouvel incident ou d’un nouveau problème, les CI dont Operational Status l’état est « Mis hors service » sont filtrés 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 Mis hors service à un autre état, le champ /Hardware Status du StatusCI est défini sur Installé.
Lorsqu’un StatusHardware Status champ de CI 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 rare, et par défaut, l’état est modifié en « Non opérationnel ». Toutefois, ce n’est peut-être 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 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 sur le champ /Hardware Status (s’il s’agit d’un matériel), consultez Mapper l’état de l’actif et l’état matériel d’unStatus CI. Pour en savoir plus sur la mise hors service des actifs, reportez-vous à la rubrique Mettre hors service des actifs.