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: RheaTietje
New Today: 31
New Yesterday: 79
Overall: 149811

People Online:
Visitors: 53
Members: 2
Total: 55 .

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

How to handle Server Reboots?
Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
UrgentJensen
Senior Itiler


Joined: Feb 23, 2005
Posts: 458
Location: London

PostPosted: Tue Jul 01, 2008 6:12 pm    Post subject: Reply with quote

I totally agree with everthing that anyone has said on this topic, so the answer is yes.

UJ
_________________
Did I just say that out loud?

(Beige badge)
Back to top
View user's profile
peted
Newbie
Newbie


Joined: Apr 03, 2008
Posts: 5

PostPosted: Tue Jul 01, 2008 8:34 pm    Post subject: Reply with quote

I believe that a server reboot to resolve an Incident stays within Incident Management. The theory being that the service is already degraded to warrant an Incident. I don't believe that applying Change will add value to the exercies, and it will create an artificially high Emergency Change percentage.

Routine reboots to keep the smooth running of servers are put into the Forward Schedule of Change as 'information' items and do not need formal RFCs as long as the reboot does not bring into effect any change (e.g. configuration file changes, additional hardware, software upgrades). The theory is that if a service works under the current configuration, there should be no reason why powercycling should cause that service not to work when it's finished.

If the reboot brings into effect a change on the server (see examples above) then I require an RFC to be submitted as it introduces an element of risk into the equation which needs to be weighed up in CAB.
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Tue Jul 01, 2008 8:43 pm    Post subject: Reply with quote

peted,

what you are saying is that the low level of risk justifies that approach.

That is fair enough, but the levels of risk and the tolerance to risk varies for different organizations and indeed for different circumstances within an organization.

For this reason there is no definitive answer to the question Or, as Viking would say, it all depends.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
joshinplano
Itiler


Joined: Jun 20, 2007
Posts: 24
Location: Dallas, TX

PostPosted: Wed Jul 02, 2008 1:39 am    Post subject: Reply with quote

AndyW wrote:
Hi,
is there something "official" I can find the answer to that question in the ITIL books? How does the ITIL framework address this issue?

What about the Problem that the Change Manager is not available 24 by 7.
Say a reboot is necessary. An emergency change will be created and the Change Manager is not available?
Of course emergency changes can be raised afterwards but only for documentation purposes. But this does not serve the objective. Since then no impact assessment will be done.

Cheers,


No, nothing official.

But, I would say that if the CM is not available, a manager/leader of the technology team supporting the service, or the service owner themselves (probably the Tech leader supporting it or someone on that team that has the authority) should approve it. Technology groups are there to support the service, so they should understand any impacts to the service, business, or other services and provide the immediate yes/no on rebooting. Then, that support individual should report the next day regarding what they did and why.
Back to top
View user's profile
ozz
Itiler


Joined: Apr 02, 2006
Posts: 40

PostPosted: Wed Jul 02, 2008 6:05 am    Post subject: Reply with quote

I am with Ed
Services are not available and the CI called a server is failed.
Reboot is really no more than saying its Known Error and a reboot is the workaround..

Oz
_________________
Ozzie Sutcliffe

NYC
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Wed Jul 02, 2008 7:26 pm    Post subject: Reply with quote

Hi,

I think all the answers are correct. But the question is wrong. A reboot is an action, not an ITIL concept and so it cannot be classified as any one ITIL thing.

For example:

- A machine that reboots itself without instruction has caused an incident.

- A reboot intended to apply a new patch or other software is part of a change process.

- A reboot to maintain long term integrity is part of a maintenance process.

- A reboot to a machine that has ceased to provide service is part of an incident resolution process.

- A reboot to a machine that is still providing some, but not all, services, is problematic.

Now, any reboot has the potential for unanticipated consequences. Therefore all reboots must be performed in a controlled manner to address the risks.

Typically these controls will be analogous to certain generic change management controls, but they can be defined very specifically for any or each server. Therefore a generic process is neither necessary nor best.

Obviously, non-urgent reboots should take place during quiet or maintenance times when it is easier to verify the success (you cannot test a reboot before doing it because each reboot is logically unique) without compromising services; but the controls still apply.

Just in case this is all too simple, there is the further complication (for our discussion) that different circumstances and different organizations have different degrees of risk tolerance.

And so...

There must be a procedure for managing the rebooting of servers. It could be written to comprehensively cover all the above issues. Or it could just say "Raise an RFC". Or it could find some middle ground.

It all depends on the maturity of your management system. The less mature the more likely to go for the "raise an RFC" scenario. but as you gain understanding, buy-in and confidence you can start to evolve more specific procedures to streamline your operations without compromising your management.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
UKVIKING
Senior Itiler


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

PostPosted: Wed Jul 02, 2008 7:45 pm    Post subject: Reply with quote

Well done synopsis
diarmid...

hopefully this will kill this thread with the exception of UJ who will raise it to inrritate my SD when the Chipmunks are on lunch break
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Feb 14, 2008
Posts: 77

PostPosted: Tue Jul 08, 2008 12:36 am    Post subject: Reply with quote

Hi folks,
I would like to give you my feedback on this topic.
For more than one month we handle Server Reboots via Emergency Change requests.
Since then it seems that we brought it under control. This also provides us with trend data e.g. which applications has the most reboots per week.

The only thing which still annoys me a bit is the argumentation with users who do not understand why an emergency change request is necessary because they have a clustered environment and the reboot wouldn't impact the users at all due to the clustered redundancy.

Cheers,
Back to top
View user's profile
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Tue Jul 08, 2008 1:17 am    Post subject: Reply with quote

Hi Andy,

Glad to hear your news.
About the user's argumentation, don't put the emphasis on impact but on the change itself.
Just say that on rebooting, the CI status of the server changed from on, off, and on again. That would update the CMDB and therefore you would be able to detect how many reboots have happened.

Asril
Back to top
View user's profile
UrgentJensen
Senior Itiler


Joined: Feb 23, 2005
Posts: 458
Location: London

PostPosted: Tue Jul 08, 2008 2:01 am    Post subject: Reply with quote

So... what's the answer then? Turn the server off, submit a change sometime later?

Ok, I've had enough of this, I'm calling the Chipmonks...
_________________
Did I just say that out loud?

(Beige badge)
Back to top
View user's profile
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Tue Jul 08, 2008 10:06 am    Post subject: Reply with quote

But what's the question?
I was just giving advice to Andy how to argue with his users.

Squirrels, chipmonks at 12! Tataa ...
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Tue Jul 08, 2008 3:15 pm    Post subject: Reply with quote

asrirlm,

asrilrm wrote:
About the user's argumentation, don't put the emphasis on impact but on the change itself.
Just say that on rebooting, the CI status of the server changed from on, off, and on again. That would update the CMDB and therefore you would be able to detect how many reboots have happened.


I have to totally disagree with this. It all stems from the artificial use of "change".

Firstly the user is not going to be impressed by a theoretical argument, rather than a practical one, and secondly counting reboots does not require a CMDB. It just digs a deeper hole for user relationships.

Andy,

now that you have it under control, streamline your process so that the user is not frustrated by the time and "paperwork" involved.. Explain to the users why you took the steps you did and what you are now doing to make it work smoother while retaining the improved control.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
AndyW
Senior Itiler


Joined: Feb 14, 2008
Posts: 77

PostPosted: Tue Jul 08, 2008 5:09 pm    Post subject: Reply with quote

Hi,
in principle this is fine. But If I would allow users in a clustered environment not to raise an emergency this would have the potential to weaken our policy.

Cheers,
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Tue Jul 08, 2008 6:52 pm    Post subject: Reply with quote

Andy,

why are users raising reboot requests?
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
asrilrm
Senior Itiler


Joined: Oct 07, 2007
Posts: 441
Location: Jakarta, INA

PostPosted: Tue Jul 08, 2008 8:07 pm    Post subject: Reply with quote

Diarmid,
Diarmid wrote:
I have to totally disagree with this. It all stems from the artificial use of "change".


From the beginning I've stated that I myself don't see server reboot as real change, but some fellow posters argued that the CI status has changed and therefore it is a change.
Artificial change, that probably is the right term.
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 Previous  1, 2, 3, 4  Next
Page 3 of 4

 
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.