SCOM Alert Handling Matrix

An Operations Manager Administrator shouldn’t be responsible for resolving all alerts that rise within an organization. This is why i started to work on an “Alert Handling Matrix” which defines the responsabilities for resolving alerts.

SCOM is a great monitoring tool! In some cases it’s even smarter than the people managing the monitored components! How is that possible?? Well, Product teams & 3th party vendors create Management Packs that have deep insight in their products. IT departments use these products, but they probably don’t have the same level of expertise that the product developers have. This means that IT departments must go through a learning curve just to understand the alerts that occur. There’s a lot to learn out of alerts!!! It can really improve your skills in managing products.
The person that’s managing the SCOM environment is not the one managing all products running in the environment, this is why we must define responsabilities. To do this I use a “Monitor all Layers” approach.

Each Layer has several components each having a responsible. The responsible person must be able to see alerts for his component (through the SCOM webconsole, Operations Console, Sharepoint,…) and he must be able to respond to the alert. The Matrix can also contain components that are not monitored yet, this will be the feature requests that must be implemented in SCOM. The Matrix would then look like this and you could start assigning responsibles.

We can also start using Operations Managers Role Based Access based upon this or make alert views corresponding to responsabilities. Report upon alerts on a monthly base, etc…
Once we start getting control over alerts (document them), we can start thinking about delegating alert resolutions to a first line helpdesk. Ultimately ITIL or MOF will come into the picture. But for starters we MUST get control over all alerts and this is a TEAM effort. This team effort will get the monitoring up to a higher level.

Such a team exists out of a few people that agree upon implementation, design and changes over the monitoring.

It goes without saying that one person will probably be in charge of multiple “monitored components” and that the “monitoring owner” is most likely to be the SCOM administrator.
This is my vision on “how to get control over your alerts”, you may use it or feel free to have another opinion.

Alert Handling.xls


3 Responses to SCOM Alert Handling Matrix

  1. Rob Pettey says:

    Sounds like they need Service manager and Orchestrator 2012. Defining and automating responses to alerts is what these products do.

    • Samuel Dubrul says:

      Hi Rob, Thanks for commenting!
      My feeling is that most companies suffer under alert pressure. Creating incidents through Orchestrator from the start will make a lot of unhappy faces (think about the number of False – positives). So my suggestion is work on getting a clean scom console, keep the active alerts as low as possible. And than you can really start getting the benefits through the integration of SCOM with SCOR & SCSM.

  2. Karsten Heldgaard says:

    I think this is a good idea, and we had the same thought in our company. We are right now doing an upgrade to SCOM 2012 project, where we also have taken this approach.
    I will also post my ideas here going forward, but the Excel Sheet you have started is a good reference point. Also I agree on the comment on SCOR and SCSM, product owners need to fine tune the alerts before we open these connections, otherwise SCSM will be flooded with alerts.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s