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: C7397
New Today: 11
New Yesterday: 50
Overall: 146274

People Online:
Visitors: 43
Members: 2
Total: 45 .

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 - Server Reboot - An RFC?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Server Reboot - An RFC?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
Kerrie
Newbie
Newbie


Joined: Oct 31, 2007
Posts: 2

PostPosted: Wed Oct 31, 2007 11:44 pm    Post subject: Server Reboot - An RFC? Reply with quote

If a live server is required to be rebooted, with no changes being made, should an RFC be raised (either upfront or restrospectively) according to the ITIL process?
Back to top
View user's profile
Kyoanna
Newbie
Newbie


Joined: Oct 15, 2007
Posts: 4
Location: Kraków, Poland

PostPosted: Wed Oct 31, 2007 11:53 pm    Post subject: Reply with quote

Hmmm..... not an easy problem. I am not sure if there is ITIL definition of this kind of situations.
I suppose there is no need to raise an RFC, maybe it's better to register a planned Incident (or some planned Incidents - it depends on the server type), that there can be a problem with some services during or after the reboot.
Back to top
View user's profile
Mnsotapop
Newbie
Newbie


Joined: Oct 30, 2007
Posts: 2
Location: Minnesota

PostPosted: Thu Nov 01, 2007 12:53 am    Post subject: Reply with quote

I don't know if this is the "correct" way to do it, but we open a Service Call (we use HPservice desk) and then the manager for the server must ok the reboot
Back to top
View user's profile
Kerrie
Newbie
Newbie


Joined: Oct 31, 2007
Posts: 2

PostPosted: Thu Nov 01, 2007 4:52 am    Post subject: Reply with quote

Thank you both for your replies, but in my opinion I do think an RFC should be raised. This will ensure that the correct Approval process is followed, plus everyone who should be notified will be.

But I would like to know whether this is inline with ITIL, or whether ITIL doesn't actually stipulate the process down to this level.

Can anyone else help?

Thanks.
Back to top
View user's profile
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Thu Nov 01, 2007 5:21 am    Post subject: Reply with quote

Per the ITIL definition, yes, a RFC should be submitted for a server reboot. An ITIL Change is defined as the change of status or attribute of a Configuration Item. Even if you don't have a formal CMDB, most people would agree that a server's status and attributes should be tracked.

Rebooting a server takes the status of the server from online to offline and then back to online.

I would hope that a mature Change Management process would handle this as a Standard (pre-approved) Change or a Minor (the Change Manager has the authority to approve) Change. Having every server reboot go to the CAB could needlessly weigh down the process.
Back to top
View user's profile
ARoll
Senior Itiler


Joined: Apr 10, 2006
Posts: 86
Location: Boise Idaho

PostPosted: Thu Nov 01, 2007 9:36 am    Post subject: Reply with quote

i agree with dboylan. if you are following the book word for word, yes a server reboot would have an RFC and is most likely situations a standard change. That being said, let's take a look at practical application. Given the level of maturity in which most organizations are currently at, going to this level is just not accomplished easily and there will be a fair amount of push back. In previous organization, a server reboot on its own was handled as a service call, if it were a reboot as apart of a formal change it would be a task associated to that change. It does just depend on what level of detail your organization is currently handling, if within your cmdb you are tracking the online/offline status then yes will want to pursue the rfc route.
_________________
Adam
Practitioner - Release and Control
Blue Badge

"Not every change is an improvement, but every improvement requires a change"
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Mark-OLoughlin
Senior Itiler


Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Thu Nov 01, 2007 10:36 pm    Post subject: Reply with quote

Hi,

A reboot should be controlled under change control. You are changing the state of the server and any applications etc. on that server from an "up" state to a "down" state" during the reboot causing potential outage or service disruption or possible performance issues.

If the server is in a clustered environ,ment you have a reduced possibility of service disruption but still it should be a change request due to the change in state of the CI.

i live in the real world and know that support teams will fight this and arguee the fact. So declare reboots as emergency changes (unless they
can be planned withing your change lead times).
Have the support teams call the change manager for all reboots
Have the Change Manager enpowered to approve the reboots - after a quick analysis or not to aprove if the impact is so high.
Change Manager then informs the Service Desk of the reboot and they can prepare for any potential calls that may come in.

I also look at it from a communications point fo view to ensure that all people know about the reboot that should i.e the change manager, the service desk, the support teams and then can deal with any issues that come out of it together.
Back to top
View user's profile
Jane
Newbie
Newbie


Joined: Nov 08, 2007
Posts: 2
Location: Minnesota, MN

PostPosted: Fri Nov 09, 2007 11:51 am    Post subject: Reply with quote

Yes, you should definitely do an RFC as you are making a change to a production server.
Back to top
View user's profile
JoePearson
Senior Itiler


Joined: Oct 13, 2006
Posts: 116
Location: South Africa

PostPosted: Thu Nov 15, 2007 2:38 am    Post subject: Reply with quote

This needn't be a complex question in one organisation - you just set the policy and go with it (managing your risk along the way). But I don't believe there's one standard answer for all organisations.

Here's something to think about: rebooting a server is not a change to the infrastructure. Everything is configured and operating exactly the same way afterwards as it was intended to work before. (Assuming you do it properly and restart all system services and applications.)

So it's more a question of what level of control you require, and at what cost in bureaucracy. If you've got cowboy sys admins, yes, force them through change control. If you have a case where a critical production server has crashed and the emergency change manager is not responding to messages ... don't wait.
Back to top
View user's profile Visit poster's website
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Thu Nov 15, 2007 6:24 am    Post subject: Reply with quote

JoePearson wrote:
This needn't be a complex question in one organisation - you just set the policy and go with it (managing your risk along the way). But I don't believe there's one standard answer for all organisations.

Here's something to think about: rebooting a server is not a change to the infrastructure. Everything is configured and operating exactly the same way afterwards as it was intended to work before. (Assuming you do it properly and restart all system services and applications.)

So it's more a question of what level of control you require, and at what cost in bureaucracy. If you've got cowboy sys admins, yes, force them through change control. If you have a case where a critical production server has crashed and the emergency change manager is not responding to messages ... don't wait.


Joe,

I agree with your comments about a level of control that you require and its cost in bureaucracy, but I must disagree on the fact that a server reboot is not a Change per the strict definition of ITIL.

In ITIL, a Change is not defined as just a change in an attribute or configuration of the infrastructure. Per SS 8.2.1, a Change is defined as "Change is the process of moving from one defined state to another." This would (in my opinion) include moving from a state of "In Production" to "Unavailable" and then back to "In Production"

That doesn't mean that Change Management must encompass server reboots. Your environment may have too much bureaucracy for this to be feasible. But my understanding, per the strict ITIL definition, is that reboots should be under Change Management.
Back to top
View user's profile
Mark-OLoughlin
Senior Itiler


Joined: Oct 12, 2007
Posts: 306
Location: Ireland

PostPosted: Thu Nov 15, 2007 7:51 pm    Post subject: Reply with quote

Hi,

the reason I would put server reboots under change management it becuase whatever is running on that server may become unavailable during the reboot (clustered environments can be considered an exception if the apps that the users use are still available during a reboot - though you have to consider the capacity capability).

If the service or application on the server become unavailabe youare changingtheir state from a working state to a non working state and hence your change instate of a CI (Applications and services can be CI's)

The other reason (and the main real world reason) is for communication. Putting a server reboot under change control means that the Change Manager is aware and shouw advise (even by email) that a server reboot is about to take place. The service desk and IT management can be informed so that they can deal with any calls being reported or management queries. Also it allows for the service owners to advise their users of the situation.

However you can add a provision to your change management process to allow say the change manager to approve reboots on the spot (providing there is low impact) otherwise its an emergency change. This will make it less cumbersome but stil allow you maintain control and provide communication
_________________
Mark O'Loughlin
ITSM / ITIL Consultant
Back to top
View user's profile
Timo
Senior Itiler


Joined: Oct 26, 2007
Posts: 295
Location: Calgary, Canada

PostPosted: Sat Nov 17, 2007 9:01 am    Post subject: Reply with quote

I agree with all the above posters that reboots should fall under change control. I think that RFC itself though is often mistaken for a complicated, time consuming document that requires time and effort to complete.

It could be the case, but it doesn't have to be. RFC's can take any form organization chooses them to be (not sure if ITIL prescribes anything specific).

Typically the need to reboot a server will arise either because of an incident (emergency change) or maintenance/support activity (normal/scheduled change). In case of a former, an RFC can be a phone call, email, or even in person communication with information about an incident to the change manager and/or ECAB.

In case of a latter, reboots would be reflected in FSC and have undergone regular CAB review and approval, unless it has been decided to pre-approve reboots, which I haven't seen anywhere yet.

So, to answer your question, yes, RFC is required. The difference is what form does the RFC take. Somebody please correct me if I am way off base here.

Thanks,

Michael
Back to top
View user's profile
thechosenone69
Senior Itiler


Joined: Jun 06, 2007
Posts: 268

PostPosted: Tue Nov 20, 2007 8:49 pm    Post subject: Reply with quote

Hi,

Very interesting topic. Well I disagree with some of you somehow. According to books I might be wrong but think of it this way. A customer calls saying that his server needs a hard reboot cause alot of users are having problem connecting to his server. How long its going to take you to approve this from the CM? Time is the enemy as they say. He can be losing alot of money-users untill you get the approvement for that reboot. I think the right way to do this is just logging it as a priority 1 incident. Call the customer to confirm the reboot. Then go ahead with it. Again this is just my point of view Smile

Many Thanks,

Ali Makahleh
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Tue Nov 20, 2007 9:10 pm    Post subject: Reply with quote

My two cents.

First what is the purpose of the reboot ?

If the reboot is an action that is part of restoring service - ie part of an incident, then there is no real need to have a RFC for the work

If the reboot is not part of incident management, then the next questions applies is as follows

Why is the server being rebooted or restarted ?
Will the service availability be impacted ie will the customers & users see the reboot ?

I dont think that the power status - on or off - of any device should be a tracked Configuration Item attribute. The attribute - Power On or Power Off - really should not be tracked. There are better attributes to use - CI Lifecycle status for one - Installed, Delivery, Obsolete

Having said that, here are a couple of scenarios and how I would handle it
Scenario 1

There are 4 web servers in a web farm - the 4 web servers are a cluster of servers. The web sites are distributed via s/w and h/w over the 4 web servers. The 4 machines share the load. 1 server has to be rebooted. The web sites and services wont be affected or impacted as the 3 have sufficient availabilty and capacity to handle the load

first - who asked for the reboot ? If there is a service request to reboot the server that is created in the incident ticket system and the appropriate system group is assigned the work and does the work, then I would not have a RFC raised - what is the point ? That is providing that there are initial and closure codes that IDENTIFY The type of work

No RFC needed

Scenario 2

There is a requirement to reboot every WinTel server every 3 months. This is a maintenance requirement to ensure that the server is cleared of temporary files. The work is to be done out of normal service houring during the posted maintenance window

A RFC should be raised for the start of this process and should contain the 'original list of serves to be done'

If more are added or removed from the maintenance list, then a RFC should be raised to TRACK and IDENTIFY the fact that a server is on or off the list

Scenario 3

Joe Bloggs working in department A thinks the server he is using to do his work is slow. So he opens a request to have it rebooted during business hours. He contacts the Service Desk for the service request. He is merely a user.

A RFC is raised mainly to protect the IT environmen from idiots like him

The RFC process should reject the change.

The main points for raising RFCs for reboots are to identify whether the service is being impacted and to track the work being done and to have sanity checks (approval) for impacting work.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


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

PostPosted: Tue Nov 20, 2007 9:39 pm    Post subject: Reply with quote

My take on this is fairly simple

Our role as Change Managers is to ensure that the business can pursue it's daily tasks with as little hindrance as possible.

Anything that impacts the availability of a service, therefore needs to be tracked and an audit trail maintained.

I also like to be consistent in my approach, which is why I cannot agree with John on his scenario 1.

I think any reboot of a server must come under Change Management - we deal with it via Standard Change - with a procedure that is cast iron going with the RFC as part of the Release documentation.

Regards

Ed
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk 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.