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: APiquet
New Today: 37
New Yesterday: 49
Overall: 146066

People Online:
Visitors: 58
Members: 3
Total: 61 .

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 do you do it
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

How do you do it

 
Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message
tink43
Newbie
Newbie


Joined: Feb 26, 2007
Posts: 4

PostPosted: Tue Feb 27, 2007 1:53 am    Post subject: How do you do it Reply with quote

We are in the process of rewritting our policies and procedures for change management. I have 2 questions.

1.) Would you consider a standard reboot a RFC?

2.) Should you have timeframes associated with your classification of a change. For instance if you have a high impact change- should you require a 2 week lead time from when the RFC is entered? We currently do it that way and was just curious how other companys were doing it.

Thanks
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Tue Feb 27, 2007 7:42 am    Post subject: Reply with quote

In answer to your question on a reboot

Why is the server being rebooted ?

If it is part of a solution to an incident no.... because it does not change the configuration and since the service may not be 100%, the reboot is part of the incident recovery plan

If the server is being rebooted and the service is 100% at the time .... first why is the server being rebooted ?

If it is part of a routine monthly maintenance or something like it; then the plan to do the work should go through the change management process

why ? you ask ... The reboot does not affect the configuration items.

The answer is the change management process is the best place to be the focal point for things like scheduled maintenance etc since the FSC and PSA are deliverable

FSC = Forward Schedule of Change
PSA = Projected Service Availability

Also, if there is a change which was approved, when it happens, the SD would say... ey this is the rgeular periodic reboot.


Also the same would apply if the reboot is not part of a regularly scheduled maintenance or an incident but a wild whim by an engineer.

This way you keep the wild whims under lock and key
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
tink43
Newbie
Newbie


Joined: Feb 26, 2007
Posts: 4

PostPosted: Wed Feb 28, 2007 12:57 am    Post subject: Reply with quote

Thank you. That makes a lot of sense. I was thrown into Change management a couple of years ago and I haven't had any training except for the ITIL foundation and I really trying to make sure we get this right in the new policies and procedures.
Back to top
View user's profile
dsemeniuk
Itiler


Joined: Feb 06, 2007
Posts: 41

PostPosted: Wed Feb 28, 2007 2:13 am    Post subject: Reply with quote

I am not sure on the Rebooting of Server example.

I would think this would go through Change Management as you really need to understand the impact of rebooting a server. There could be other services running on that server that need consideration and should have proper review and approval before rebooting the server.

So I would like to see an RFC be submitted, depending on the urgency of course, after the fact RFC would suffice if it was an emergency, but still proper review and approval should be followed. I wouldn't want people just rebooting servers without proper authorization.

Does that make sense?
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Wed Feb 28, 2007 3:56 am    Post subject: Reply with quote

dsemeniuk,

Look at the definition of Change Management - control the configuration items and the work which changes the configuration data of them.

A reboot does not change any configuration of a device it merely on/offs the device. Depending on the use of that device is whether the service & users notice it or not

If the service is already impacted by problems with the server, a reboot is a good incident recovery method - especially for Microsoft products

For ex:, a server has a Blue Screen of Death or just froze or the application running on it froze the system. A reboot would restore the server to an operational state.

It is kind hard to get diagnostics from a BSD'd machine -remotely.

So under a incident, a reboot is merely one of the steps to restore service. Since there was no configuration item attributes changes (Power on power off is not a attribute... it is a slogan for the Power Rangers !!!!), a change would not be necessary

Under the circumstances of rebooting the server every 8th day; this act is impacting the service (even Out of Hours) because the Service Desk monitoring team will notice it and if it takes longer than the alarm threshold, a incident ticket would usually be generated and then closed

However, in this case; the objective of pushing the regularly scheduled change is to assess and announce the risk, impact and justification for the silly (IMHO) task.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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


Joined: Feb 06, 2007
Posts: 41

PostPosted: Wed Feb 28, 2007 4:44 am    Post subject: Reply with quote

I understand that in theory, we are not really changing anything on the server by doing a reboot but....what about its status?

You are really changing the status of that CI to Decomissioned, Down, or Under Maintenance, whatever you choose to use.

I know this one is very debatable and I am having a hard time not having control around somebody wanting to reboot a server.

If all of a sudden you get calls from other users saying what happened, I lost my connection, or I cannot access so and so, how are you going to know what "changed" to cause that incident?
Back to top
View user's profile
DanA
Itiler


Joined: Feb 12, 2007
Posts: 27
Location: Minneapolis, MN, USA

PostPosted: Tue Mar 06, 2007 11:11 am    Post subject: Reply with quote

If it is a planned reboot, we generally have them open a Change Request to track it and make it known to all. If it is part of incident restoration, then we just track it in the incident record.
Back to top
View user's profile
goitilcouk
Newbie
Newbie


Joined: Feb 24, 2007
Posts: 19

PostPosted: Wed Mar 14, 2007 12:42 am    Post subject: Reply with quote

Our process:
Reboot - not a change unless the server was taken out of the farm/cluster as part of a problem, then an RFC is raised to re-introduce it

Regarding your second question, we operate a standard 8 day lead time for all changes (with the exception of standard = 3 days and emergency = immediate).

The part that changes based on the risk/impact is the process (ie approval cycle and wheter it goes to the CAB)
Back to top
View user's profile Send e-mail Visit poster's website
jpgilles
Senior Itiler


Joined: Mar 29, 2007
Posts: 123
Location: FRance

PostPosted: Fri Apr 13, 2007 1:43 am    Post subject: reboot is a change Reply with quote

Back to my definition of a change, rebooting a server may be considered as a change

definition: "any action or operation modifying the nominal state of a component taking part in the provision or the delivery of a service"

If the normal status of a server is "up and running" then shutting it down is a change and needs to be evaluated in terms of impact, risk, ....

In addition, your server may be under supervision of some monitoring tools which may generate automated alerts when the server is shut down. That means that the requested operation is not only to reboot the server, but also, to turn off and on again some parameters within those tools (unless you do not care to bother people with an alert for a normal situation ...) : that is definitely a change... (basically 2 i a row).

best regards
_________________
JP Gilles
Back to top
View user's profile Send e-mail
CoolCat
Newbie
Newbie


Joined: Apr 19, 2007
Posts: 4

PostPosted: Thu Apr 19, 2007 9:35 pm    Post subject: Reply with quote

The way I see it - these need to be spereated into two scenario's (Categorised):

1 - A server freezes (BSOD) for whatever reason and needs to be rebooted to restore the service as quickly as possible (Incident Management). Users are down, there has been an impact.

2 - A planned reboot for maintenance etc... (Change Control) process to be followed. Users are working there is going to be an impact.

Thoughts...
Back to top
View user's profile
Ed
Senior Itiler


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

PostPosted: Thu Apr 19, 2007 10:58 pm    Post subject: Reply with quote

Hi all

We actually treat this as a Standard Change. As a Change because taking the service away from the customer is a Change i.e. we are changing the status of a CI (the service) at this point from available to un-available and then back to available. As a Standard Change because it is a Change that is repeatable, and the risk/impact are known and understood.

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
Page 1 of 1

 
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.