OpsMgr. Where the technology ends and the organization starts. Part II: I think I saw an Alert...

--------------------------------------------------------------------------------- 
Postings in the same series:
Part   I:  Introduction.
Part III:  Beyond The Alert.
---------------------------------------------------------------------------------

Before monitoring starts
As stated in the previous blog posting in this series, at a certain stage in the monitoring process, the technology ends and the organization kicks in. Actually this isn’t correct at all. The organization has to be in place during the whole monitoring process as well of course. Even better, before the monitoring starts.

Say what?
Let me explain it more detailed. Suppose you have an IT environment in place. In that environment certain Line of Business Applications (LOBs) are running. These LOBs must be monitored. But how can you properly monitor it without exactly knowing what elements do make up these LOBs? Without having the organization reached an agreement on that, proper monitoring of these LOBs won’t be possible at all.

So before monitoring starts, the organization must be in place AND also have a list of what to monitor, based on their core business, LOBs and what elements do make up those LOBs. Only then proper monitoring is possible. Some times I see organizations where the IT department is told to monitor LOBs without having a clear definition of what elements are part of those same LOBs. Per department (development/testers/users/management for instance) there are totally different views upon it. This results in monitoring too much/less objects or the wrong ones. Thus having a negative impact on the monitoring process as a whole. People think they have it covered but actually they haven’t and are confronted with it on the worst moment…

Advise 01:
Before creating a Distributed Application or a whole set of other rules/monitors in order to monitor a LOB make sure there is mutual agreement on what elements do make up that particular LOB. Also check on the severity levels of the Alerts and their priority settings in order to reflect the status of the monitored LOB so it matches the organizations priorities. (Never raise a critical Alert while a Warning is sufficient.)

Monitoring is running
OK. The LOBs got defined just fine and are being monitored properly in OpsMgr. Every one happy. Let’s switch off the Console and look the other way! Wait! This is not the way to go about it. But nor is putting some one in front of the OpsMgr Console, waiting until an Alert comes in. (Don’t you dare to take your eyes of the screen…..)

Now what?
Divide and Conquer! Simple as that. Let OpsMgr work for you and let the related departments work with OpsMgr. Create Diagram Views related to the departments fields of work. Diagram Views are nice since they are graphical display of the monitored LOBs/services/servers/objects. Use big screen TV's for it so no one can neglect it. With a single glance one can see the status of their Exchange/SQL/IIS environment for instance of that of the LOBs. When the Diagram View doesn’t work for you, there are other solutions available, like Visio or Savision Live Maps.

On top of that, create specific Folders in the Console containing the Alert-, Performance- and State Views relevant to the departments. And scope these Folders so the departments only see what is relevant to their line of work. This will keep the Console neat and tidy without too much information in it.

Also use different Alert Resolution States. Based on that different Alert Views can be built as well which filter the Alerts on their Resolution State and a certain group of Servers. This particular Alert View can be added to the folder relevant for a department. Thus keeping the Alerts they see related to their line of work. With PS the process of changing Alert Resolution State can be automated.

Every department has some one who is the manager. Use subscriptions here to get the manager of the department notified about Critical Alerts which are related to the responsibilities of that same department. This way the manager ‘knows’ about it and can manage the process of getting things fixed. Also this way the manager gets in the loop earlier and not when it is ‘too late’.

Advise 02:
Visualize as much as possible. Use Distributed Applications and Diagram Views for this purpose. Scope these visualizations to the related departments. Use big screen TV’s per department so a whole department knows with a single glance how they are doing. Visio or Savision Live Maps are good tools as well here.

Advise 03:
Use scoped Views in combination with Alert Resolution States. This will make OpsMgr as a whole more workable for the departments. They are not interested in becoming OpsMgr experts. They are interested in how their systems/services are operating. Provide that and you will see how happy they are with OpsMgr.

Advise 04:
Get the manager of the related department involved as well. Provide a read-only Console, reports which are automatically created and (automatically) send to him/her on a regular basis and set up a notification model for the manager which – for instance – sends out only the Critical Alerts related to that department.

Next posting in this series will be about using Notifications, how to connect to ticketing systems (not a technical approach). Also how  to close an Alert will be described in this series.

Duh! Right click, and select Close. Nope. There is more to it, at least when you want to use OpsMgr to its fullest. :)