Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: Richardhit
New Today: 11
New Yesterday: 75
Overall: 142305

People Online:
Visitors: 73
Members: 0
Total: 73

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Is restarting a server or service considered a change?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Is restarting a server or service considered a change?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
GT
Newbie
Newbie


Joined: Aug 07, 2006
Posts: 2

PostPosted: Tue Aug 08, 2006 12:55 pm    Post subject: Is restarting a server or service considered a change? Reply with quote

We've had a debate here at work and people have decided that restarting a server or service is considered a change and requires an RFC. In fact, it's now been decided that even if a service is unavailable that we cannot restart its processes until we submit an RFC and obtain approval.

I see the point in documenting the reboot, but it seems to me that the above decisions will lead to delays in restoring service and this will negatively impact systems availability. Comments?
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Tue Aug 08, 2006 4:50 pm    Post subject: Reply with quote

Hi GT

I can see why you would expect a delay, however, in this situation we have set up Standard Changes for this type of 'Housekeeping type' Changes.

In this way you get the swift response and no delay, and also the audit trail we all want to track issues.

I hope this helps

Regards

Ed
Back to top
View user's profile
outager
Newbie
Newbie


Joined: Aug 01, 2006
Posts: 7

PostPosted: Tue Aug 08, 2006 8:33 pm    Post subject: Reply with quote

In my former job we also handled a reboot of a server in the change proces. For the small servers we had standard changes as Ed says. For restarting larger servers (up to the mainframe) we had an urgent change procedure.

Paul.
Back to top
View user's profile
GT
Newbie
Newbie


Joined: Aug 07, 2006
Posts: 2

PostPosted: Wed Aug 09, 2006 12:12 pm    Post subject: Reply with quote

Ed wrote:
Hi GT

I can see why you would expect a delay, however, in this situation we have set up Standard Changes for this type of 'Housekeeping type' Changes.

In this way you get the swift response and no delay, and also the audit trail we all want to track issues.

I hope this helps

Regards

Ed


So you've made them self-approved changes? This makes sense to me.
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Wed Aug 09, 2006 7:37 pm    Post subject: Reply with quote

Hi GT

We came to the conclusion that we do not want to 'stand in the way of Change', but to facilitate it, therefore pre-approving this kind of Change made perfect sense.

It's not without it's pitfalls - You have to make sure that the procedure behind the change is as solid as you can get it.

We ask for a Standard Change Release Notification from the Techies so that we know what they have done/are doing and can keep track of the changes as they make them (We post them in our Forward Schedule of Change as well).

Regards

Ed
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Sat Aug 12, 2006 10:57 pm    Post subject: Reply with quote

Hello GT,

In most organizations that we encounter, restarting a server is "not" a Change, as a "Change" implies the modification of a Configuration. Rebooting a machine does not change the machine's configuration and, therefore, changes nothing other than the state of the server, itself.

Restarting a server is typically treated as a basic "Service" that yields a Service Request when it is invoked by the requestor.

I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
TemperedMeasures
Newbie
Newbie


Joined: Aug 13, 2006
Posts: 8

PostPosted: Mon Aug 14, 2006 10:51 am    Post subject: Reply with quote

In most groups I've worked with, unless there is an alteration to the structure (i.e., not just a reboot), it isn't considered a change. Should it be documented... absolutely. That way we have evidence if we need to commit to a true change/alteration.

Dan Vogel
Back to top
View user's profile Visit poster's website
MrDon
Newbie
Newbie


Joined: Aug 24, 2006
Posts: 10

PostPosted: Fri Aug 25, 2006 8:07 pm    Post subject: Reply with quote

My take on it....

If the reboot is part of a solution to get a service back online, then just an incident should be required.

If however, the reboot is part of a measure to prevent a possible problem, then I would consider that an emergency change. This then allows for approval time and to get an outage message to any affected users.
Back to top
View user's profile
Ines
Newbie
Newbie


Joined: Mar 21, 2006
Posts: 18

PostPosted: Sat Oct 14, 2006 12:27 pm    Post subject: server restarts Reply with quote

in my organisation, it depends on the reason behind the restart. eg 1 - server is unavailable, all users impacted by loss of service, and service needs to be restored via restart, then there would be a Sev 1 or Sev 2 ticket active, therefore can be performed under that ticket.
eg 2- service/system is available to staff, but the restart is required in a pro-active manner, then an urgent change is raised (meaning for us that lead times don't need to be met given the justification for the work) and an outage notification is sent to users.
eg 3- server requires reboot as tasks running in the background have crashed (so incident ticket has been raised with high severity), statewide staff are not impacted by the crashed tasks, but will be by the reboot, so an Emergency change is raised to approve this loss of service, outage notification sent to affected staff.
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3298
Location: London, UK

PostPosted: Sat Oct 14, 2006 6:59 pm    Post subject: Reply with quote

A Change should be any work where the configuration of a device has been changed.

Therefore a reboot or a restart hich is merely being done either for a response to an existing incident or as part ofa weekly or monthly maintenence cycle (why?) is NOT a Change per ITIL.

However, if the reboot is part of a configuration change// install etc; then it is part of the implementation plan for a change and there should be indicated as such

Lastly ... what to do about the reboots//restarts where there is no configuration change / Easy 1- there should be a Incident (service Request) record, 2 - if the users are going to be affected - a notification of some kind should go out

You need to come up with a Maintenance work - non configuration work - ticket standards

Now I used RFCs because our RFC system also linked to the notification system
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Ziad
Senior Itiler


Joined: Sep 27, 2006
Posts: 91

PostPosted: Sun Oct 15, 2006 2:18 am    Post subject: Reply with quote

As already stated by Frank and John, whenever a modification to a CI (any of its attributes) in the CMDB takes place (or is to take place), we have a change. Otherwise it's a standard activity.

Cheers,
Z!
Back to top
View user's profile Send e-mail
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Sun Oct 15, 2006 5:51 am    Post subject: Reply with quote

Under a number of circumstances, because restarting a server changes its state, it involves a number of activities that are usually handled by the Change Management process: planning (as short as it may be), risk management, Projected Service Availability, back-out/contingency planning, etc...

I am a little skeptical here. What server? Do you turn off an AS/400 just like that, as a service request? How critical is this server? How long will it be down? Can it wait until the next service window? ... How about restarting services on that server? How about virtual machines in the server? Which services are going to be affected? How much does it mean in productivity loss?

For the sake of efficiency, and because we should have the server fully under control, we should have the answers to all those questions readily available in a documented procedure. Depending on the server, you may allow the Service Desk to perform the action following that procedure. But you cannot decide off the bat that restarting *any* server is "merely" a service request left up to whoever is performing Incident Management to decide and execute.
_________________
BR,
Fabien Papleux

Accenture
Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
blamblam
Itiler


Joined: Jan 16, 2005
Posts: 37
Location: New Zealand

PostPosted: Tue Oct 17, 2006 1:20 pm    Post subject: Reply with quote

In ITIL a Change is defined as the process of moving from one defined state to another. Therefore, any request that: alters, removes or appends anything to a Configuration Item (CI), i.e. changing the baseline configuration of a CI, and/or has the potential to impact the Availability or Quality of Services within the production and supporting environments (test environment, Definitive Hardware Store (DHS), and Definitive Software Library (DSL)), is considered a Change and must follow the Change Management process.

It could be argued either way but I concur with Frank and John on this one in that the reboot does NOT change the baseline configuration of the server.
Back to top
View user's profile Visit poster's website
Lord
Newbie
Newbie


Joined: Oct 16, 2006
Posts: 1

PostPosted: Tue Oct 17, 2006 7:23 pm    Post subject: Reply with quote

isn't it the great question of Change Management? What is a Change? What is a Service Request? Isn't any change different? How can you handle almost all changes with just one process? Won't the process just get to big in order to be able using it for almost all changes?

So there's just one conclusion... You need to define what are changes, what are service requests, what changes can be pre approved, what changes need to run through the whole process...

As there is no fit-for-all answer for this questions, as every change is different, as every company is different, you just have a continous process of rethinking and improving your own Change Process.

It's a shame, no easy going, no easy life, nothing is really a standard, always rethinking... Guess I could really think of worse jobs.

To your question... What is the benefit of generating a RFC for rebooting? What is the relation between benefit and effort? Are there different forms of rebooting? Is there a SOP for rebooting? Instructions, who is to be informed? Is it a nearly automized process? Change Management is much about defining things.
Back to top
View user's profile
Ed
Senior Itiler


Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Tue Oct 17, 2006 8:57 pm    Post subject: Reply with quote

Since when did shutting down a server (to reboot it) not impact it's availability. Surely if a server is shut down , it is not available!

blamblam says

'In ITIL a Change is defined as the process of moving from one defined state to another. Therefore, any request that: alters, removes or appends anything to a Configuration Item (CI), i.e. changing the baseline configuration of a CI, and/or has the potential to impact the Availability or Quality of Services within the production and supporting environments (test environment, Definitive Hardware Store (DHS), and Definitive Software Library (DSL)), is considered a Change and must follow the Change Management process. '

and I agree so a Request for Change is needed

Regards

Ed
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.