Selecting CIs when closing Events/Alerts

[db0]

Our SD tool auto assigns CIs to event records, because we always know which device is impacted. I am of the opinion that the CI for an incident or event should reflect the device that caused the service interruption, not necessarily what device was impacted.

One of my peers believes that for events, the CI should be left to reflect what device was impacted. Isnt that what the Service record is intended to reflect?

[UKVIKING]

Both of you are half right

The issue is how is the CMDB organized so that the CI that is the cause of the alert can have a drill down to what potential impact to what the alert means

The problem is that there also not be an answer

This would depend on the tool used
The amount of details about the CIs and how well defined the CMDB is
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[db0]

We use the Service record to reflect what service/business capability is impacted, and the CI to reflect a specific asset. My opinion is that you would want to choose the asset that caused impact to the service.

For example, you have 4 servers that go offline and an event record is generated. Through troubleshooting, you find that a switch actually caused the servers to go offline. Wouldn’t you want to select the CI for the switch?

If you choose the switch as the CI, you should be able to see if other incidents were caused by the switch outage, or if a change caused the switch to go offline. If you leave the server CIs on the event records, you would not be able to see related incidents, or perform change correlation/detection.

[UKVIKING]

DB0

You are absoutely right that you want the right level of information at the right time

However, the limiting factor is going to be the tool, the capability of the tool and the individuals implementing the tool

also, this is more of a Configuration mgmt issue to do this and a SD issue to be the benefactor of this

you are preaching to the choir on this
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Timo]

But John, I would think that ideally you would first decide on the level of information required, have the appropriate data model, etc, etc and then pick a tool that can support that. From the practical stand point, yes, he is probably limited by the existing tool implementation in his ability to select the appropriate CI.

Conceptually, I would tend to agree that you want the CI that caused the outage and not the one that first displayed the symptoms.

[UKVIKING]

Timo

True

but it is not a SD discussion but a Config mgmt and a design of the tool discussion

while we can pontiifcate about what we want

we have to weigh that against what we need and what we can afford as well as what we can configure
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter