O IRE no ServiceNow (Identification and Reconciliation Engine) é o mecanismo central que identifica e reconcilia Configuration Items (CIs) no CMDB, garantindo um único registro confiável por ativo. Ele decide quando criar, atualizar ou bloquear um CI com base em regras de identificação, regras de reconciliação e precedência de fontes — sustentando a integridade de dados que ITAM, ITOM, SecOps e CSDM exigem para operar com confiança.
O que é o IRE no ServiceNow?
O IRE é o componente do ServiceNow que controla como os dados entram e são atualizados no CMDB. Toda ingestão que passa por ele é avaliada contra um conjunto de regras antes de gravar: se o CI já existe, ele é atualizado; se não existe, um novo registro é criado; se a fonte não tem autorização sobre o atributo, a gravação é bloqueada. O objetivo é direto: um CI, um registro, uma fonte de verdade.
Por que a integridade de dados é crítica no CMDB
Um CMDB sem qualidade de dados compromete toda a operação que depende dele. Quando o mesmo ativo aparece duplicado, ou quando duas integrações sobrescrevem uma à outra a cada sincronização, os relatórios perdem confiabilidade e as decisões passam a se apoiar em dados instáveis. Os sintomas mais frequentes são duplicidade de CIs, atributos inconsistentes, conflito entre fontes e baixa confiança nos dashboards. Em ambientes que alimentam o CMDB por múltiplas fontes, esse risco é estrutural — e é exatamente o problema que o IRE existe para resolver.
Os três blocos do IRE
O IRE é composto por três tipos de regra que atuam em conjunto. Compreender a função de cada um é o que separa um CMDB estável de um CMDB que “briga consigo mesmo”.
| Bloco | O que decide | Pergunta que responde |
|---|---|---|
| Regras de identificação | Como o ServiceNow reconhece um CI | “Esse CI já existe no CMDB?” |
| Regras de reconciliação | Quais fontes podem atualizar quais atributos | “Esta fonte pode gravar este dado?” |
| Precedência de fontes | Qual fonte prevalece em caso de conflito | “Quando duas fontes discordam, quem vence?” |
Regras de identificação (identification rules)
As regras de identificação usam identifier entries com prioridades para reconhecer um CI por atributos únicos — serial number, serial number type, nome, object ID, entre outros. O IRE avalia da entrada mais forte para a mais fraca: para hardware, por exemplo, ele testa primeiro a combinação serial number + serial number type; se não houver correspondência, testa o serial number isolado, e assim por diante. Assim que encontra um match, atualiza o CI e para. Se nenhuma entrada corresponder, cria um novo registro. Identificadores fortes e estáveis são a defesa primária contra duplicidade.
Regras de reconciliação (reconciliation rules)
As regras de reconciliação definem quais fontes de dados podem atualizar uma tabela ou um conjunto de atributos. Elas são declaradas em qualquer classe da hierarquia e herdadas pelas classes filhas — uma regra na classe “Server” vale para “Linux Server” e “Windows Server”, salvo regra específica. Na prática, é o que impede que uma planilha importada sobrescreva um atributo que só o Discovery deveria controlar.
Precedência de fontes (data source precedence)
Quando mais de uma fonte está autorizada a atualizar o mesmo atributo, as regras de precedência elegem a fonte autoritativa por classe ou por atributo. É o mecanismo que elimina o efeito “ping-pong”, em que o valor de um CI muda a cada sincronização porque duas integrações disputam o mesmo campo. Regras dinâmicas permitem ainda tratar CIs obsoletos (stale): após uma duração efetiva definida, um CI pode ser atualizado por uma fonte de menor prioridade, evitando dados congelados.
Como o IRE processa um CI na prática
O fluxo é determinístico, não aleatório. A identificação é executada primeiro; a reconciliação só atua depois que o CI foi identificado; e os conflitos seguem uma ordem estrita de precedência. Em termos operacionais:
- Uma fonte envia um payload (com a classe do CI e seus atributos) ao IRE.
- O IRE aplica as regras de identificação por prioridade até encontrar — ou não — um CI correspondente.
- Identificado o CI, as regras de reconciliação verificam se a fonte pode gravar cada atributo.
- Havendo concorrência entre fontes autorizadas, a precedência decide qual valor prevalece.
- O CI é criado, atualizado ou tem atributos mascarados, conforme as regras.
Quais métodos de ingestão usam o IRE — e quais não usam
Este é o ponto mais subestimado em projetos de CMDB: nem toda forma de popular o CMDB passa pelo IRE. Métodos que ignoram o IRE inserem dados sem identificação nem reconciliação, e são a origem mais comum de duplicidade em massa.
| Método de ingestão | Usa o IRE? |
|---|---|
| ServiceNow Discovery | Sim |
| Service Graph Connectors (integrações de terceiros) | Sim |
| IntegrationHub ETL (importações) | Sim |
| Integrações REST diretas sem Service Graph Connector | Não — não recomendado |
| Importações manuais fora do IntegrationHub ETL | Não — não recomendado |
IRE, ITAM, ITOM e CSDM: o efeito em cadeia
A integridade entregue pelo IRE não é um fim em si — ela é a base sobre a qual outras disciplinas operam. No ITAM, CIs confiáveis significam rastreio preciso de ativos e decisões de licenciamento e custo mais assertivas. No ITOM, dados consistentes melhoram a correlação de eventos e a análise de causa raiz, reduzindo ruído operacional. E no CSDM, o IRE ajuda a manter a estrutura do CMDB aderente ao modelo, sustentando a governança de serviços. Sem reconciliação confiável, cada uma dessas camadas herda o erro da camada de baixo.
Problemas comuns: CIs duplicados x CIs sobrecarregados
Dois defeitos opostos sinalizam regras de identificação mal calibradas. Reconhecê-los cedo evita retrabalho de deduplicação em produção.
| Problema | O que acontece | Causa típica |
|---|---|---|
| CIs duplicados | Vários registros representam o mesmo ativo | Identificadores fracos ou que mudam com o tempo |
| CIs sobrecarregados | Ativos distintos colapsam em um único registro | Critérios de identificação amplos demais |
Boas práticas para implementar o IRE com eficiência
- Partir das regras prontas (OOTB) e entendê-las antes de customizar.
- Eleger a fonte autoritativa por classe e por atributo, atribuindo a precedência correta.
- Priorizar identificadores fortes e estáveis (serial number costuma ser melhor que nome).
- Testar regras em ambiente sub-produtivo com cenários reais: dados parciais, dados conflitantes e múltiplas fontes.
- Monitorar os logs de processamento do IRE e tratar filas de deduplicação periodicamente.
- Alinhar o desenho de classes e relacionamentos ao modelo CMDB/CSDM.
- Auditar regras e qualidade de dados em ciclos regulares — integridade de dados é processo contínuo, não projeto único.
Execução especializada faz a diferença
Regras de identificação e reconciliação mal definidas não causam erro imediato — elas degradam o CMDB silenciosamente, até que relatórios e automações deixem de ser confiáveis. Como ServiceNow Elite Partner no Brasil e vencedora do Technology Excellence Partner Award 2024–2025, a 4MATT atua com mais de 80 especialistas certificados no desenho, na calibragem e na sustentação do IRE, transformando o CMDB em uma fonte de verdade estável para ITAM, ITOM, SecOps e CSDM.