Gestão de ciclo de vida do IC do CMDB (legado)

Versão de lançamento: Xanadu

Atualizado 1 de ago. de 2024

7 min. de leitura

Do momento da criação até o momento em que não é mais necessário, um IC do CMDB normalmente passa por muitos estados operacionais durante várias operações. A Gestão de ciclo de vida do IC fornece o mecanismo para definir estados e ações para um IC e permite realizar ações apropriadas com base no estado de um IC para personalizar a gestão do ciclo de vida do IC para as necessidades de negócios.

O CMDB Data Manager é agora uma solução mais abrangente e integrada para gerenciar operações de ciclo de vida do IC, como exclusão e arquivamento em massa. Para obter mais informações sobre o CMDB Data Manager, consulte .

Termos associados à Gestão de ciclo de vida do IC:

Estados operacionais: Um conjunto de estados em que um IC pode estar, como “Operacional” ou “Reparo em andamento”. Um IC pode ser associado a apenas um único estado operacional em um determinado momento. As opções de estados operacionais são baseadas no campo operational_status na tabela [cmdb_ci]. Há vários estados operacionais definidos no sistema de base, como “Descontinuado” e “Reparo em andamento”. É possível modificar esta lista para refletir os estados operacionais que são relevantes para o seu negócio.
Nota:
Por padrão, o Mapeamento de serviços é configurado para ignorar todos os ICs de host para os quais o valor de status operacional [operational_status] não é 1 (Operacional) ou o valor de status [install_status] é 100 (ausente). Para obter informações adicionais sobre este comportamento, consulte Preparar implantações ServiceNow personalizadas para trabalhar com Mapeamento de serviços [KB0647574] na Base de conhecimento HI.
A Gestão do ciclo de vida do IC permite que vários operadores e automações definam simultaneamente diferentes estados operacionais de um IC. Como um IC não pode ser associado a vários estados operacionais, é importante configurar cada estado operacional com uma prioridade. Essas prioridades são usadas nessa situação para determinar qual dos estados operacionais é o cumulativo.
Ações de IC: Um conjunto de ações que podem ser aplicadas a um IC durante seu tempo de vida. É possível definir ações de IC que são relevantes para o seu negócio.
Ações de IC Compatíveis: A Gestão do ciclo de vida do IC permite que um IC tenha várias ações de IC ativas simultaneamente. No entanto, elas devem ser definidas especificamente como compatíveis. Por padrão, não há duas ações para um IC que sejam compatíveis entre si. É possível mudar este comportamento especificando pares de ações que são compatíveis e, portanto, podem ser aplicadas simultaneamente a um IC. Por exemplo, é possível especificar que as ações de IC “Patch” e “Provisionamento” são compatíveis, tornando possível aplicar ambas simultaneamente a um IC.
Ações de IC não Permitidas: Por padrão, qualquer ação de IC pode ser aplicada a qualquer IC. É possível restringir esse comportamento definindo uma regra de que uma ação não é permitida para um IC quando esse está em um estado operacional específico. Por exemplo, é possível definir uma Ação de IC não permitida na qual não é permitido aplicar a ação “Provisionamento” a um Servidor Linux que está em um estado “Não operacional”.
Transições Operacionais não Permitidas: Por padrão, as transições são permitidas de qualquer estado operacional para outro. É possível restringir esse comportamento definindo uma regra que a transição não é permitida para um IC especificado. Por exemplo, é possível definir que não é permitido fazer a transição de “Reparo em andamento” para “Não operacional” para um Servidor Linux.
Solicitante: Um solicitante pode ser um operador de fluxo de trabalho ou sem fluxo de trabalho que está tentando definir estados operacionais e aplicar ações de IC. Cada solicitante tem um ID de solicitante associado que é um GUID e que pode ser um contexto de fluxo de trabalho ativo ou um ID de operador registrado sem fluxo de trabalho.
Horário do leasing: Um período que cada solicitante (especialmente os operadores sem fluxo de trabalho) pode fornecer. Uma ação de IC especificada tem permissão para estar ativa para um IC especificado durante esse período.

A Gestão de ciclo de vida do IC do CMDB fornece um conjunto de APIs para gerenciar estados operacionais e ações de IC. E a IU em que você define um conjunto de regras para restringir determinadas transições de estado operacional e ações com base em estados operacionais. A Gestão também fornece um mecanismo para auditar o estado operacional e as ações de IC durante todo o ciclo de vida do IC.

Provedores como automação, fluxos de trabalho ou Gestão de mudanças podem usar a Gestão de ciclo de vida do IC como um mecanismo para gerenciar estados operacionais de IC e aplicar ações de IC. Por padrão, o comportamento da Gestão de ciclo de vida do IC não tem restrições em algumas operações e tem restrições totais em outras operações. A IU da Gestão de ciclo de vida do IC permite modificar esse comportamento padrão ao especificar Ações de IC não permitidas, Ações de IC compatíveis e Transições operacionais não permitidas que restringem algumas operações e habilitam outras.

Com a Gestão de ciclo de vida do IC, é possível:

Gerenciar estados operacionais e ações de IC em todo o ciclo de vida do IC.
Gerenciar transições de estado operacional de IC.
Restringir determinadas transições de estado operacional.
Associar determinadas ações a tipos de IC que estão em estado operacional específico.
Restringir as aplicações de IT Service Management com base no estado operacional do IC.
Auditar os estados operacionais e as ações de IC durante todo o ciclo de vida do IC.

APIs de gestão de ciclo de vida

A Gestão de ciclo de vida do IC fornece um conjunto de APIs para gerenciar estados operacionais e ações de IC durante todo o ciclo de vida do IC. Todas as restrições e permissões especificadas por regras na IU são aplicadas quando as APIs de gestão de estados são executadas. Se uma API tentar executar uma operação restrita, a operação será bloqueada e um erro será registrado em log.

Como registrar solicitantes

Ao usar as APIs de gestão de ciclo de vida para aplicar ações de IC, os solicitantes devem ser registrados para obter um ID de solicitante que seja exclusivo nas tabelas de gestão de ciclo de vida. Para registrar e obter um ID de solicitante, os usuários sem fluxo de trabalho devem chamar a API registerOperator. Os usuários de fluxo de trabalho podem usar o contexto de fluxo de trabalho ativo como o ID do solicitante e não precisam chamar o registerOperator.

Depois de concluir as operações de ciclo de vida do IC, o solicitante deve chamar a API unregisterOperator para cancelar o registro. Todos os registros de gestão de estado associados a esse ID do solicitante específico são marcados como inativos ou são removidos pelo trabalho agendado CI Lifecycle Management — Restore Internal State Management Tables.

Integração com Gestão de incidentes e Gestão de problemas

Uma instância de base inclui a ação de IC predefinida CreateTask usada para criar uma tarefa para um IC. Novas instâncias têm uma Ação de IC não permitida predefinida, especificando que a ação “CreateTask” não é permitida para qualquer IC com um estado operacional “Descontinuado”. Esta restrição é integrada com Gestão de incidentes e Gestão de problemas para impedir a criação de tarefas de incidentes ou problemas para ICs descontinuados. A ação de IC “CreateTask” é usada como um qualificador de referência para o campo Configuration Item das tabelas de Incidentes/Problemas. Em um novo incidente ou problema, os ICs em que Operational Status está “Descontinuado” são filtrados da lista Configuration Item no formulário. Para obter mais informações sobre qualificadores de referência, consulte Qualificadores de referência.

integração com Gestão de ativos

Em um sistema de base, o campo Operational Status de um IC e os campos Status/Hardware Status (se for hardware) serão mantidos sincronizados se um dos valores dos dois campos for “Descontinuado”. Quando Operational Status de um IC é definido como “Descontinuado”, o campo Status/Hardware Status é definido automaticamente como “Descontinuado”. O oposto também é verdade. Quando o campo Status/Hardware Status de um IC é definido como “Descontinuado”, Operational Status é definido automaticamente como “Descontinuado” também.

Quando um campo Operational Status muda do status “Descontinuado” para outro, o campo Status/Hardware Status do IC é definido como “Instalado”.
Quando um campo Status/Hardware Status do IC muda do status “Descontinuado” para outro, o campo Operational Status é definido automaticamente como “Não operacional”.

A mudança do estado “Descontinuado” para outro acontece raramente e, por padrão, o estado é alterado para “Não Operacional”. No entanto, esse pode não ser o estado pretendido para o registro. Portanto, é importante que os administradores revisem e gerenciem o estado adequadamente neste caso.

Sempre que o Status/Hardware Status de IC muda, ele é sincronizado com o campo Asset State correspondente do IC e vice-versa, mantendo o Operational Status de IC e o Asset State de IC correspondente sincronizados.

Para obter mais informações sobre como mapear campos Asset State e Substate para um campo de ICs Status/Hardware Status (se for hardware), consulte Mapeamento do estado de ativo e do status de hardware de IC. E, para obter mais informações sobre como descontinuar ativos, consulte Descontinuação de ativos.