{"id":2211,"date":"2020-02-08T18:51:13","date_gmt":"2020-02-08T17:51:13","guid":{"rendered":"http:\/\/siff.io\/?p=2211"},"modified":"2020-06-05T09:28:45","modified_gmt":"2020-06-05T16:28:45","slug":"why-siff","status":"publish","type":"post","link":"https:\/\/webdev.siff.io\/why-siff\/","title":{"rendered":"Why SIFF?"},"content":{"rendered":"\n

The Frustration<\/strong><\/p>\n\n\n\n

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:<\/p>\n\n\n\n

\u201cWhat the $%&! changed!\u201d<\/strong><\/p>\n\n\n\n

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. <\/p>\n\n\n\n

Gartner has shared that \u201cMore than 80% of all incidents are caused by planned and unplanned changes.\u201d <\/strong>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.<\/p>\n\n\n\n

How about Configuration Management Database (CMBD) or Network Inventory Systems \u2013 don\u2019t they contain configuration information?<\/strong><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

How about ITIL Change Management \u2013 that should track all changes, right?<\/strong><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

How about Network Config Management, Server Config Management, and Application Configuration Management systems \u2013 that should have the detailed configs, right?<\/strong><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Answering \u201cWhat the $%&! Changed!\u201d <\/strong>is the essence of SIFF.<\/p>\n\n\n\n

SIFF = S<\/strong>earch for dIFF<\/strong><\/p>\n\n\n\n

Why SIFF Today?<\/p>\n\n\n\n

SIFF helps infrastructure operations in the following 3 areas:<\/p>\n\n\n\n

  1. Troubleshooting & Repair<\/li>
  2. Change Management<\/li>
  3. Governance & Compliance<\/li><\/ol>\n\n\n\n

    Troubleshooting & Repair<\/strong><\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    Change Management<\/strong><\/p>\n\n\n\n

    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. <\/p>\n\n\n\n

    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.<\/p>\n\n\n\n

    Governance & Compliance<\/strong><\/p>\n\n\n\n

    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 \u201cWhat the $%&! Changed!\u201d <\/strong>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.<\/p>\n","protected":false},"excerpt":{"rendered":"

    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: \u201cWhat the $%&! changed!\u201d Troubleshooting […]<\/p>\n","protected":false},"author":5,"featured_media":2112,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","_mi_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[32,33],"tags":[27,29,28,30,31,26],"_links":{"self":[{"href":"https:\/\/webdev.siff.io\/wp-json\/wp\/v2\/posts\/2211"}],"collection":[{"href":"https:\/\/webdev.siff.io\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webdev.siff.io\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webdev.siff.io\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/webdev.siff.io\/wp-json\/wp\/v2\/comments?post=2211"}],"version-history":[{"count":0,"href":"https:\/\/webdev.siff.io\/wp-json\/wp\/v2\/posts\/2211\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webdev.siff.io\/wp-json\/wp\/v2\/media\/2112"}],"wp:attachment":[{"href":"https:\/\/webdev.siff.io\/wp-json\/wp\/v2\/media?parent=2211"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webdev.siff.io\/wp-json\/wp\/v2\/categories?post=2211"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webdev.siff.io\/wp-json\/wp\/v2\/tags?post=2211"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}