Desvendando o Pilar de Completeness — Garantindo os Dados Essenciais para o Negócio

tiagomacul · an hour ago

📌 Este é o segundo artigo da nossa série exclusiva sobre a engenharia de dados do CMDB Health Dashboard. Se você perdeu o primeiro texto, onde exploramos a arquitetura do painel, os impactos operacionais e o papel dos Scheduled Jobs, vale a pena conferir a introdução clicando aqui: Artigo 1: Introdução ao CMDB Health Dashboard — A Fundação da Confiança nos Dados de Configuração.

Introdução ao CMDB Health Dashboard — A Fundação da Confiança nos Dados de Configuração

Introdução: O Risco dos Campos em Branco

No segundo artigo da nossa série sobre a integridade das fundações de dados, vamos analisar o pilar mais visível e imediato da saúde do ecossistema: Completeness (Completude).

Ter um Item de Configuração (CI) cadastrado na base de dados sem os seus atributos essenciais é quase tão prejudicial quanto não ter o registro mapeado. Se o time de operações de TI (ITSM) se depara com um servidor sem a informação de quem é o dono do ativo ou qual é o seu ambiente (Produção ou Homologação), o processo de tomada de decisão é interrompido. O pilar de Completeness mapeia exatamente esses vazios informacionais.

A Estrutura do KPI: Required vs. Recommended

O scorecard de Completeness subdivide-se em duas categorias de métricas configuradas no nível da classe do CI através do CI Class Manager:

Atributos Obrigatórios (Required Fields)

São os campos vitais sem os quais o CI perde o sentido operacional ou de conformidade legal. Se um campo definido como obrigatório estiver em branco, o CI impacta negativamente a nota de Required do painel.

Exemplo prático: O número de série corporativo em ativos de hardware ou o ID da subscrição em ativos de nuvem híbrida.

A Completeness (Completude) é uma métrica composta, estruturada a partir de dois indicadores independentes que avaliam a qualidade dos dados:

Campos Obrigatórios (Required Fields😞 Verifica se os campos definidos como mandatórios no schema da classe de CI estão devidamente preenchidos.
Campos Recomendados (Recommended Fields😞 Valida o preenchimento de campos configurados especificamente na tabela cmdb_recommended_fields para cada classe de CI.

Ambos os indicadores são executados de forma independente seguindo uma agenda programada (schedule). A nota final de Completeness é derivada do resultado combinado dessas duas métricas.

Atributos Recomendados (Recommended Fields)

Campos que não travam o ciclo de vida inicial do registro, mas que enriquecem a governança e trazem eficiência de longo prazo para as áreas de suporte e negócios.

Exemplo prático: O grupo de suporte responsável (support_group) ou a criticidade do serviço vinculado.

Exemplo Prático de Configuração e Negócio: A Classe de Servidores

Vamos a um exemplo real de desenho de arquitetura para a classe de Servidores Linux (cmdb_ci_linux_server):

Regra de Completeness Definida: O Arquiteto de Soluções define no CI Class Manager que os campos IP Address, Asset Tag e Owned by são obrigatórios (Required), enquanto Location e Managed by são recomendados (Recommended).
O Alerta no Dashboard: Um Service Graph Connector ingere um lote de novos servidores virtuais vindos de um ambiente de nuvem, mas a API externa não traz a informação de quem é o dono do recurso (Owned by).
A Ação Operacional: O dashboard de saúde imediatamente identifica a omissão, derruba a nota de Completeness dessa classe específica e gera uma pendência visual para que os analistas de dados façam o saneamento enriquecendo os registros falhos.

De onde vêm os Campos Obrigatórios e Recomendados?

Para diagnosticar qualquer problema de Completeness, é fundamental compreender a origem técnica desses dados. A separação entre eles segue esta lógica:

Campos Obrigatórios (Required Fields😞
Origem: Não possuem uma tabela de configuração específica; o sistema os identifica lendo diretamente o esquema (schema) da classe de CI.
Definição: Qualquer campo que possua a flag de “Mandatory” marcada na classe do CI (ou em suas classes pai) é automaticamente considerado obrigatório.
Exceção: O sys_id é sempre excluído da avaliação, mesmo que esteja marcado como obrigatório.
Configuração: Não é possível configurar via tabela; o controle é feito puramente pelo atributo do campo no esquema da plataforma.
Campos Recomendados (Recommended Fields😞
Origem: São armazenados na tabela cmdb_recommended_fields e são totalmente configuráveis pelo administrador.
Estrutura: Cada registro contém dois campos-chave: table (a classe do CI) e recommended (uma lista, separada por vírgulas, dos nomes dos campos).
Hierarquia: Se nenhum registro for encontrado para a classe exata do CI, o sistema percorre a hierarquia da classe para localizar uma configuração em uma classe pai.
Comportamento: Se nenhuma configuração for encontrada em nenhum nível da hierarquia, a classe é ignorada pelo processo de Completeness, evitando falsas falhas.
Herança: Classes filhas herdam automaticamente a configuração de campos recomendados de suas classes pai.

Quais classes de CI são avaliadas?

Entender o escopo de avaliação é crucial. Antes de iniciar o processamento, o sistema constrói uma lista de classes de CI para avaliar seguindo este fluxo lógico:

Identificação Inicial:

O sistema consulta a tabela cmdb_ci, agrupando por sys_class_name, para encontrar todas as classes que possuem ao menos um registro.
Apenas classes cuja tabela base absoluta seja cmdb_ci são incluídas.
Nomes de classes inválidos são ignorados e registrados como avisos (warnings).

Filtragem via Health Metric Qualifier (cmdb_health_metric):

“Para configurar o escopo de avaliação do CMDB Health Dashboard, não editamos tabelas de configuração cruas, mas utilizamos a interface dedicada do CMDB Health. O sistema utiliza a tabela cmdb_health_metric como base de referência para os indicadores. A definição de quais classes entram ou saem do cálculo é feita na configuração de Health Preferences (acessível via CMDB Dashboard > Health Preferences), onde você define a política de saúde para cada classe, garantindo que o dashboard reflita apenas o que é relevante para o seu negócio."

Filtragem via Condição de Ativação (cmdb_health_config):

Se existir um registro de Health Config para uma classe de CI e uma métrica específica, uma condição de encoded query é aplicada.
Apenas os CIs que atendem a essa condição são avaliados; os demais são excluídos.
Caso não exista um registro de Health Config para uma determinada classe, todos os CIs pertencentes a ela serão avaliados.

Engenharia Reversa: Como o ServiceNow calcula os Atributos Obrigatórios? ⚙️

Para os arquitetos e desenvolvedores que gostam de entender o que acontece “sob o capô”, a submétrica de campos obrigatórios (Required Fields) segue uma lógica de execução assíncrona extremamente otimizada. Sempre que o Scheduled Job do CMDB Health é executado, o motor processa a base através dos seguintes passos estruturados:

Leitura do Schema da Classe: O sistema varre o dicionário de dados da classe de CI correspondente e coleta todos os campos marcados com a flag Mandatory (obrigatório), ignorando automaticamente o atributo nativo sys_id.
Validação de Regras Ativas: Caso nenhuma regra de obrigatoriedade seja encontrada para aquela tecnologia específica, a execução daquele lote é registrada como “pulada” (skipped) na tabela de controle (cmdb_health_processor_status), evitando o desperdício de processamento e garantindo que nenhum falso positivo de falha seja gerado.
Consulta Cirúrgica à Tabela (Sem Herança): O motor realiza uma query direta na tabela da classe utilizando uma correspondência estrita (sys_class_name = classe em processamento). Isso significa que ele não perde performance varrendo toda a hierarquia de classes filhas de uma só vez; o processamento é isolado e focado.
Aplicação do Filtro de Exceção (Condição OR): Para otimizar a busca no banco de dados, o ServiceNow aplica uma condição lógica OR cruzando todos os campos obrigatórios identificados. A query só retorna o registro do CI se pelo menos um desses campos estiver vazio.
Injeção de Filtros de Governança: Se você configurou filtros adicionais ou critérios de exclusão específicos na tabela de configuração de saúde (cmdb_health_config), essas regras são injetadas dinamicamente na query neste momento.

Mecanismo de Resiliência (Checkpoint): Se por algum motivo a rotina de madrugada for interrompida (uma reinicialização do nó ou janela de manutenção, por exemplo), o motor possui resiliência nativa: ele lê o último sys_id processado na tabela de status e retoma exatamente de onde parou.

G.Mapeamento Individual e Geração do Alerta: Para cada Item de Configuração (CI) retornado com pendências, o sistema faz uma checagem campo a campo para descobrir exatamente quais dados foram negligenciados. Por fim, um registro de falha é consolidado na tabela cmdb_health_result, gerando a famosa descrição detalhada que o time de sustentação visualiza: "Following required fields are not populated:", seguida do nome técnico dos campos ausentes.

O Mapa das Tabelas: Onde o Motor do CMDB Health Grava os Dados? 🗂️

Para entender o fluxo de processamento de ponta a ponta, precisamos conhecer o ecossistema de tabelas que o ServiceNow utiliza por trás dos panos. Elas se dividem entre tabelas de Configuração (onde você define as regras) e tabelas de Runtime/Status (onde o motor registra a execução e os erros).

Aqui está o dicionário essencial para todo Arquiteto de Soluções:

📊 Tabelas de Base e Configuração de Regras

cmdb_ci (Base Configuration Item): A tabela mãe de todo o CMDB. O motor do CMDB Health faz uma varredura inicial nela agrupando os registros por sys_class_name para mapear exatamente quais classes possuem itens ativos a serem avaliados no lote.
cmdb_recommended_fields (Campos Recomendados por Classe): Guarda as diretrizes que você define na interface. Seus campos fundamentais são table (o nome técnico da classe) e recommended (uma string separada por vírgulas com os atributos desejados). Ela possui comportamento de herança nativo: se uma classe filha não tiver uma regra própria, ela herda as diretrizes da classe pai.
cmdb_health_config (Configurações de Filtros de Saúde): Armazena as condições de ativação de registros por métrica e por classe. É aqui que o sistema sabe se um CI específico dentro daquela classe deve ou não entrar no escopo da avaliação da madrugada (ex: avaliar apenas servidores com o status Most Active).
sn_cmdb_ws_health_metric_qualifier (Qualificadores de Inclusão e Exclusão): Responsável por guardar regras refinadas de inclusão e exclusão por métrica. Seus principais atributos são class_name, metric, type e apply_to_children. O motor só processa essa tabela se ela possuir registros válidos e linhas populadas para a classe alvo.

⚙️ Tabelas de Logs, Métricas e Resultados (Runtime)

cmdb_health_result (Resultados de Falhas Individuais): Onde o "dedo é apontado". Cada falha de preenchimento gera uma linha aqui, associando o CI afetado à métrica violada. O campo description armazena a lista exata dos atributos que ficaram vazios. Ao início de cada nova rotina, o sistema marca os registros antigos com to_delete = true para posterior expurgo.
cmdb_health_result_count (Contagem Consolidada de Falhas): Tabela de agregação estatística. Ela limpa os dados históricos no início da execução e é reconstruída conforme o job avança, consolidando os volumosos totais que você enxerga nos gráficos de rosca do dashboard.
cmdb_health_metric_status (Rastreamento de Execução de Métricas): Monitora a saúde do próprio processo de cálculo em nível macro e sub-métrica. Mapeia campos como metric, status, started_on, run_time e active. Seus estados variam entre IN_PROGRESS, COMPLETE, TIME_OUT, MAX_FAILURES e NOT_RUN. Dica de ouro: se o seu dashboard parecer travado ou não atualizar, esta é a primeira tabela que você deve inspecionar.
cmdb_health_processor_status (Status de Processamento em Lote): Responsável pelo controle granular por lote de classe e métrica. Utiliza chaves como batch_name, metric, status, skipped e last_processed_id. O ciclo de vida do lote transiciona entre DRAFT, IN_PROGRESS e COMPLETE. O grande segredo aqui é o atributo last_processed_id: ele guarda o último sys_id processado com sucesso, permitindo que o motor retome uma execução interrompida sem recalcular tudo do zero.

Conclusão e Próximos Passos

Trabalhar o pilar de Completeness garante que sua base de dados possua substância informativa. Contudo, ter os campos preenchidos não significa necessariamente que eles estão seguindo as políticas internas da organização ou os padrões da indústria. No próximo artigo, avançaremos para o pilar de Compliance para auditar a conformidade dessas informações.

Introdução ao CMDB Health Dashboard — A Fundação da Confiança nos Dados de Configuração.
Configure KPI and metrics preferences (docs).
KB2788051 CMDB Health Dashboard — Completeness KPI: What Runs, How It Works, How CIs Are Evaluated, What’s Stored, and Where to Verify

Participe, entre nas comunidades, acompanhem os posts:

Conteúdos de interesse

O Guia Definitivo para Certificações ServiceNow: Da preparação à Manutenção. English, Español