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?
Selecting CIs when closing Events/Alerts
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
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
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
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.
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.
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
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
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
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.
Conceptually, I would tend to agree that you want the CI that caused the outage and not the one that first displayed the symptoms.
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
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
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter