- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2 hours ago
📌 Este é o quarto artigo da nossa série exclusiva sobre a engenharia de dados do CMDB Health Dashboard. Com o pilar de Correctness, encerramos esta jornada técnica sobre os indicadores fundamentais de saúde da sua CMDB. Caso tenha perdido algum capítulo desta série, você pode acessar todos os conteúdos através dos links abaixo:
- Artigo 1: Introdução ao CMDB Health Dashboard — A Fundação da Confiança nos Dados de Configuração, Medium
- Artigo 2: Desvendando o Pilar de Completeness — Garantindo os Dados Essenciais para o Negócio, medium
- Artigo 3: Dominando o Pilar de Compliance - Certificação e Auditoria Automatizada de Dados, Medium
- Artigo 4: Medium
Introdução: O Inimigo Silencioso da Obsolescência
Chegamos ao último artigo da nossa trilha técnica sobre o CMDB Health Dashboard. Até aqui, garantimos que a base de dados tem substância (Completeness) e segue as regras de governança corporativa (Compliance). No entanto, o tempo é um fator implacável na engenharia de software. À medida que novos servidores nascem, ativos são aposentados e integrações atualizam tabelas simultaneamente, o banco de dados começa a acumular registros órfãos, duplicados ou que simplesmente pararam de atualizar.
O KPI de Correctness (Exatidão ou Correção) funciona como o zelador e auditor de qualidade final da base, limpando os desvios estruturais que minam a confiança operacional.
- As Quatro Submétricas Críticas de Correctness
O scorecard de Correctness consolida de forma analítica quatro fontes de falhas estruturais na base de dados:
- Duplicate CIs (Registros Duplicados): Ocorre quando dois ou mais registros representam a mesma entidade física no mundo real. O motor de identificação e conciliação — o IRE (Identification and Reconciliation Engine) — é a ferramenta usada para mapear essas redundâncias com base em regras de chaves exclusivas.
- Stale CIs (Dados Obsoletos / Sem Atualização): Representa dados técnicos que pararam no tempo. São os registros cuja data de última descoberta (last_discovered) ou última atualização superou a janela de tempo máxima estipulada. Isso indica falha em Discovery Schedules, credenciais expiradas ou que o ativo foi desativado na realidade sem que o ciclo de baixa fosse rodado.
- Orphan CIs (Registros Órfãos): Componentes ou elementos da infraestrutura que perderam seus vínculos obrigatórios de arquitetura (ex: uma instância de software listada no banco, mas cujo servidor físico hospedeiro foi deletado).
- Orphan Relationships: Linhas na tabela de relacionamentos (cmdb_rel_ci) que apontam para registros pai ou filho que não existem mais.
┌─── Duplicate CIs ➔ Identificados via motor IRE
├─── Stale CIs ➔ Monitorados via janelas de inatividade
[ KPI CORRECTNESS ]
──┼─── Orphan CIs ➔ Caçados por regras de integridade de classe
└─── Orphan Rels ➔ Vínculos fantasmas expurgados da cmdb_rel_ci
>> Configuration > CI Class Manager
> Open Hiererchy
> Busque por uma classe, por exemplo: Linux Server
> Expandir a aba Health
> Selecione Correctness
> As configuracoes constam nas abas
Orphan Rule
Staleness Rule
.
- Exemplo Prático de Negócio e Remediação Automática
Considere uma grande operação logística que lida com milhares de itens de configuração. Uma falha de credencial de rede em um dos datacenters impede que o motor de varredura acesse um lote de servidores virtuais por 45 dias seguidos.
- O Alerta: O dashboard detecta que o campo last_discovered superou o limite de tolerância configurado no CI Class Manager. Esses CIs entram na categoria de Stale Data.
- A Remediação Ativa (Data Remediation Tasks): Em vez de simplesmente gerar um relatório para análise posterior, o ecossistema ServiceNow gera uma tarefa de remediação estruturada baseada em workflows. O time de governança de dados pode disparar uma ação em lote para suspender esses ativos, apagar os relacionamentos órfãos de forma segura ou acionar a equipe de redes para corrigir a credencial falha.
Conclusão da Série: A Maturidade das Fundações de Dados como Diferencial Competitivo
Ao longo desta jornada de 4 artigos, exploramos como o CMDB Health Dashboard transiciona o gerenciamento de configuração de um repositório confuso e estático para um ambiente dinâmico e altamente confiável. Mapear e governar de maneira equilibrada a Completude (Completeness), a Conformidade (Compliance) e a Exatidão (Correctness) é o que separa os projetos de tecnologia comuns das arquiteturas corporativas de alta performance.
Manter a saúde dessas fundações de dados limpas blinda seus investimentos em HAM, SAM e CSDM, gerando o retorno financeiro e a eficiência que o negócio moderno exige.
- 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:
- https://www.youtube.com/@servicenowbr/
- https://www.facebook.com/groups/servicenowbrasil
- https://macul.medium.com/
- https://www.servicenow.com/community/brazil-snug/tkb-p/snug-br-brazil-tkb-board
- NowBridge.
- https://www.linkedin.com/groups/5134493/
- https://www.servicenow.com/community/user/viewprofilepage/user-id/73505
- https://github.com/Tiagomacul/
- https://www.tiktok.com/@servicenowbr
- https://open.spotify.com/show/1Qa4xVz7xXnKM9y9wggfT9
- https://join.slack.com/t/servicenowbrasil/shared_invite/zt-2sooa78s7-MWwcMxEdbktNjjIYRZfqHg
- https://www.linkedin.com/in/tiagomacul/
- Tiago Macul MVP 2026: My Community Power.
Conteúdos de interesse