The Frustration

Everyone has experienced the frustration of troubleshooting a complex problem with no idea of what caused the issue. The only thing you have to work with are the symptoms such as alerts and performance metrics, from which you try to deduce plausible causes. Leading to the initial reaction:

โ€œWhat the $%&! changed!โ€

Troubleshooting could be easier if you were aware of the configuration changes that occurred so you can quickly narrow down what you need to consider.

Gartner has shared that โ€œMore than 80% of all incidents are caused by planned and unplanned changes.โ€ As a result, large IT operations have policies that prevent configuration changes during critical or busy seasons of their business to minimize incidents.The problem is that none of the existing tools directly tackle what changed.

How about Configuration Management Database (CMBD) or Network Inventory Systems โ€“ donโ€™t they contain configuration information?

The configuration details in CMDBs or Inventory systems are pretty rudimentary and contain only basic inventory information such as CPU and Memory or network relationships. But relevant, up-to-date, detailed configuration information that would be useful in troubleshooting incidents is not included.

How about ITIL Change Management โ€“ that should track all changes, right?

Assuming configuration changes nicely initiates a Change Request and follows the change management process, the Change Request itself only describes what is intended to be carried out. It does not actually have the details of the configuration changes that were made. It is helpful to know the recent work completed that may be related to the incident but the actual configuration changes are essential to be able to isolate and determine the root cause.

How about Network Config Management, Server Config Management, and Application Configuration Management systems โ€“ that should have the detailed configs, right?

These config mgmt systems do have detailed configs, some may have versioning, and show you changes between the configs. The limitation is that they are often constrained to specific domains or silos, e.g. networks only, servers-only, or specific applications. You need to be able to see change events across all functions to be able to correlate and determine the root cause.

Answering โ€œWhat the $%&! Changed!โ€ is the essence of SIFF.

SIFF = Search for dIFF

Why SIFF Today?

SIFF helps infrastructure operations in the following 3 areas:

  1. Troubleshooting & Repair
  2. Change Management
  3. Governance & Compliance

Troubleshooting & Repair

Our goal is to help infrastructure operations become more efficient and effective at troubleshooting incidents and complex problems by providing the necessary configuration change events to help identify the root cause.

Unlike existing configuration management tools, SIFF does not configure or provision systems or devices, we focus on providing features and capabilities that help with the analysis and troubleshooting of complex incidents.

Change Management

Change Management is a critical process that helps ensure changes made to the infrastructure do not adversely affect current operations. It helps reduce unnecessary incidents by providing approval controls and coordination of work or Change Requests to be performed. 

SIFF helps improve the change management process by associating actual configuration changes with their corresponding Change Request, making process improvements such as peer reviews viable. Currently, it is uncommon for most infrastructure operations to perform peer review of configuration changes because it is time and labor intensive for an additional resource to verify the changes across all related systems and devices. As SIFF monitors configuration changes, it automatically tags the change events with the corresponding Change Request ID so that it can be easily reviewed. Unplanned or unauthorized changes are more easily visible and candidates for investigation. Additionally the change events can be easily searched during incident troubleshooting.

Governance & Compliance

The configuration of systems, devices, services that make up the infrastructure is the code or DNA of your infrastructure. A big benefit in solving the โ€œWhat the $%&! Changed!โ€ problem is the resulting data become readily accessible for many governance and policy compliance activities. From detailed asset / inventory reporting, configuration compliance monitoring to security audits and forensic analysis. Our goal is to make it easy to access these data and support these governance and monitoring requirements.

Comments are closed.