Flapper Detection Strategy for Configuration Item Synchronization

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In remote network management, updating the service model to account for minor changes, known as 'flapper values,' can be wasteful in terms of memory and processing resources, leading to poor system performance.

Innovation Solution

A flapper detection strategy is implemented to identify flapper values and prevent unnecessary re-computation of the service model by distinguishing between significant and minor changes, using a flapper candidates table and detection strategies to determine whether a new value is a flapper value.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the service model is re-computed for every change in CI records, then the service model remains synchronized with the current state, but processing resources are wasted on minor changes

Engineering Contradiction:
Improveservice model synchronizationVSAvoidprocessing resources
Core Design Contradiction:
ReliabilityVSLoss of energy

Solution Approach 1:

The system performs preliminary classification of changes by comparing the magnitude of change against a threshold before initiating re-computation. This preliminary action filters out insignificant changes that would not affect service model accuracy, thereby avoiding wasted processing resources while maintaining synchronization for meaningful changes.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system changes the parameter being monitored from absolute change to relative change by introducing a threshold value. Instead of re-computing for any change, the system only triggers re-computation when the change exceeds the threshold, transforming the parameter evaluation criterion to eliminate unnecessary processing.

Inventive Principle:
Principle #35Parameter changes

2Reliability

If the service model is re-computed for every change in CI records, then the service model remains up-to-date, but system performance deteriorates

Engineering Contradiction:
Improveservice model accuracyVSAvoidsystem performance
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system performs preliminary classification of changes by comparing the magnitude of change against a threshold before initiating re-computation. This preliminary action filters out insignificant changes that would not affect service model accuracy, thereby avoiding wasted processing resources while maintaining synchronization for meaningful changes.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system changes the parameter being monitored from absolute change to relative change by introducing a threshold value. Instead of re-computing for any change, the system only triggers re-computation when the change exceeds the threshold, transforming the parameter evaluation criterion to eliminate unnecessary processing.

Inventive Principle:
Principle #35Parameter changes

3Device complexity

If all changes are treated equally, then the system is simple to implement, but memory and processing resources are wasted

Engineering Contradiction:
Improvesystem simplicityVSAvoidmemory and processing resources
Core Design Contradiction:
Device complexityVSLoss of energy

Solution Approach 1:

The system changes the parameter being monitored from absolute change to relative change by introducing a threshold value. Instead of re-computing for any change, the system only triggers re-computation when the change exceeds the threshold, transforming the parameter evaluation criterion to eliminate unnecessary processing.

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The system applies different quality treatment to different changes based on their magnitude. Significant changes trigger full re-computation while minor changes are filtered out. This local differentiation in processing quality optimizes resource usage without requiring complex system architecture.

Inventive Principle:
Principle #3Local quality

Data Source

PatentUS11115471B2Identifying and mitigating configuration item flapping
Publication Date: 2021.09.07 SERVICENOW INC
  • US11115471B2 patent drawing
  • US11115471B2 patent drawing
  • US11115471B2 patent drawing

AI summary

A computational instance of a remote network management platform includes a persistent storage that contains a plurality of CI records corresponding to a set of computing devices disposed within a managed network, a set of software applications configured to execute on the set of computing devices, and a network-based service that is provided by execution of the set of software applications. The computational instance also includes one or more server devices configured to: receive an indication of a change to a CI record of the plurality of CI records; add, to a flapper candidates table in the persistent storage, a new value for a field of the CI record; determine, using a flapper detection strategy, flapper strategy data based on the new value and at least one old value for the field; and determine, based on the flapper strategy data, whether to trigger a re-computation of the service model.