Gestion du cycle de vie des CI CMDB (héritée)
Entre sa création et jusqu’à ce qu’il ne soit plus nécessaire, un CI CMDB passe généralement par plusieurs états opérationnels. Gestion du cycle de vie 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 pour adapter la gestion du cycle de vie des CI aux besoins de l’entreprise.
CMDB Data Manager (Gestionnaire de données CMDB) est désormais une solution plus complète et intégrée pour gérer les opérations du 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 Travailler avec le gestionnaire de données CMDB.
- États opérationnels
- Ensemble d’états dans lesquels un CI peut se trouver, tel que « 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 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 :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 de statut [operational_status] opérationnel n’est pas 1 (opérationnel) ou la valeur de statut [install_status] est 100 (absent). Pour plus d’informations sur ce comportement, voir Préparation de déploiements ServiceNow personnalisés pour fonctionner avec Mappage des services [KB0647574] dans la base de connaissances HI.
- Actions de CI
- Ensemble d’actions qui peuvent être appliquées à un CI pendant sa durée de vie. Vous pouvez définir des actions de CI 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 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 de les appliquer simultanément à un CI.
- Actions de CI non autorisées
- Par défaut, toute 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 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 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 autres que des workflows) 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 permettant de 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 pour restreindre les actions en fonction des états opérationnels. Il fournit également un mécanisme permettant d’auditer l’état opérationnel du CI 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 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 pas de restrictions sur certaines opérations, ni de restrictions totales 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 Actions de CI non autorisées, Actions de CI compatibles et Transitions opérationnelles non autorisées qui restreignent certaines opérations et en activent d’autres.
- Gérez les états opérationnels des CI et les actions des CI tout au long de leur cycle de vie.
- Gérez les transitions d’états opérationnels de CI.
- Restreignez 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 en fonction de l’état opérationnel du CI.
- Auditez les états opérationnels des CI et les actions des CI tout au long du 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 des CI pendant l’ensemble du cycle de vie des CI. Toutes les restrictions et autorisations spécifiées par les règles dans 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
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 du workflow peuvent utiliser le contexte du workflow actif comme ID de 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’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 dans lesquels Operational Status figure « Hors service » sont filtrés hors de la liste sur le Configuration Item 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’étatStatusMis hors service à un autre état, le champ /Hardware Status du CI est défini sur Installé.
Lorsque le champ d’un CI/Hardware Statuspasse 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é 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 StatusCI /Hardware Status change, il est synchronisé avec le champ correspondant Asset State du CI, et vice versa, en gardant synchronisé les Operational Status CI et les correspondants Asset State du CI.
Pour plus d’informations sur le mappage et les champs avec le champ Asset State d’un CI /Hardware Status (s’il s’agit de son matériel), voir Mapper l’état de l’actif et l’état matériel du CI.StatusSubstate Et pour plus d’informations sur la mise hors service des actifs, consultez Mettre hors service les actifs.