Prod vs Non-Prod

[changeborg]

I'm sure this has been discussed so my apologies if I am rehasing a conversation but could not locate one.

We are in the midst of a discussion between change management and a functional group on this. Here's a quick summary:
Change Group:
-Believes that the changes against non-production environments should be treated no differently

Functional Group:
-Believes that all non-production environment changes are low impact changes

I will say that amongst our group (change management) that there is a bit of a differing opinion. The manager believes that we should have a separate workflow for anything non-production as the CAB would not care about non-production. The staff in the change team that has been around for a while sees this a bit more black and white. Mind you that all we are talking about is the infrastructure side of the world as the application side in this scenerio have a uniquely separate change and release process.

I'm curious how others manage the differences with the environments and the way they progress through your workflows.[/list]

[UKVIKING]

It depends

The way it is done where I am is as follows

All non production systems and applications are controlled / owned by the Release Manager. The RM ensures that the enviroments - Projects and Support - are available for use to the users in question - programmers, project teams, etc. The Environments manager makes sure that the system / application / environment when delivered is configured based on the defined requirement for the purpose. Once delivered, the RM takes over

All non production system, applications, service, database work and other related work must be filtered / approved / acknowledged / inform the Release Manager. All down time has to be agreed by the RM - who seeks the environment user owner acquiesence /acknowledgement.

As patch management, deployment management and all related activities are within scope of RM process, all activity in non production falls under the RM

if a system has not been delivered, the RM does not care - unless the work impacts any existing system, application, service or database.

Change Management does the same for all production and DR systems as these are Production.

The CM depends on the RM process to be followed

And having said that, incident management and fault resolutions where systems require reboots / restarts to restore services are handled as incident activities - within reason. If the service is down and a reboot is needed to restore - restore service. If the service is up but a reboot is needed to solve an outstanding incident.... schedul and approve
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

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

[Sunny60in]

Where I work:

- Test bed changes are categorised to be low on impact & Risk. However, that doesn't make these changes as standard or no impact change. So they go through the change management cycle.
- These changes are discussed in a meeting (call it a CAB for these servers) and participants are those present in regular CAB except business guys. They have never shown their willingness to join (it doesn't matter to them)

I am also aware of a place where non production & production environment are treated as different customers having a trust relationship.

[mtimofeyev]

Working on a similar project where the goal is to introduce better controls for changes in non-prod. The message is great "we want more control, but none of the bureaucracy". Ain't it great?

[Diarmid]

Hehe!

Great to hide behind a term that has lost its meaning by becoming a pejorative.

One of the dictionary definitions of a bureau is "an agency for the co-ordination of related activities". Just consider that your procedures are such an agency.
_________________
"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