Server in hung state . Does it require a change request?

Discuss and debate ITIL Change Management issues
Post Reply
User avatar
shivaShanker
Newbie
Newbie
Posts: 1
Joined: Sun Jul 16, 2017 8:00 pm

Server in hung state . Does it require a change request?

Post by shivaShanker » Mon Jul 17, 2017 4:00 am

Hi All,

Server in hung state . Does it require a change request to reboot it? The server is in hung doing nothing and it is almost like its down.I feel we just reboot it to bring it back online and treat that as an Incident.

your thoughts please.



User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Post by UKVIKING » Thu Jul 20, 2017 9:30 am

Why do you think a Change Request is needed to power off / on a device to restore it to service - as per Incident Management

A Change Request is not needed to do run & maintain activities like this - which is a means or action to restore a service that is down.

If there is an Incident regarding this hung device, then the action to reboot / restart is tracked by the incident should be sufficient; however, the company needs to define in its change management policy and incident mgmt. policy what is within change scope or not

Now.. if the server was not in a hung state and the system required a reboot during the working day - impacting the service that is being delivered by that device, then, s change may be needed - depending on the reason for the reboot
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

User avatar
noBS
Newbie
Newbie
Posts: 2
Joined: Mon Nov 20, 2017 7:00 pm

Post by noBS » Tue Nov 21, 2017 5:12 pm

So I'm new to this forum (Hello all!) and this post is a few months old, however, I thought I would throw this perspective into the mix...

A power state change to a device is still a Change. That part should be easily agreed upon, right?

So looking at the reason why there would be a state change, your approach here could be to classify as an emergency change - which by definition should only be used for a handful of reasons including to restore on ongoing system outage.

A typical scenario is that a business service is down and a hung process/server is thought to be the cause. What happens when the server reboot does not restore the service? What happens if that reboot impacts something else?

Another consideration is with people and providing an easy to follow process that provides for consistency of message and consistency of action. If you create conditions for things rather than "if server is restarted create RFC", it leaves things open to interpretation or allows staff to do what's easiest as opposed to do what is required.

So long as the process is clearly defined either approach works.

Post Reply