1

I have been tasked with compiling a list of possible network equipment changes at a data center. The task includes tagging which changes need change control and which don't. Does anyone know of a "best practices" list that I can start from?

The methods for doing change control at this data center are well established. The list would be of specific configuration items that should or should not be included in the change control process, of example;

static route entries
switch port assignments
firewall rule additions/changes
etc.

jpolache
  • 155
  • 8

2 Answers2

1

the configuration files(if they are text based) are best candidates for revision control. have a repository with the images you install (switches, routers etc.)

keep a journal of changes as well - this will give a clear idea on what is changed the most frequent and you can take from there.

take a look at this video - describes how facebook does it from dev to prod.

http://www.youtube.com/watch?v=T-Xr_PJdNmQlink text

silviud
  • 2,687
  • 2
  • 18
  • 19
  • 1
    change control != revision control – Zypher Dec 20 '10 at 19:50
  • sure - how do you translate in practice change control ?! - ticketing system ? – silviud Dec 20 '10 at 19:58
  • Yes, many ticketing systems have a change-control mechanism included or as an add-on. Change-control is the process that governs the planning and approval of changes. What you described, revision control, can be used for auditing of the process after the fact, but it does nothing for determining what needs CAB approval, manager approval, pre-approval, etc. – mfinni Dec 21 '10 at 15:20
  • ok then we shall say that the ticketing system will trigger a change and therefore is controlled by some authorities and version control will actually reflect the implementation change. – silviud Dec 21 '10 at 15:42
  • No, not unless you also bought something that does server automation/orchestration. – mfinni Dec 21 '10 at 16:51
  • some script ... – silviud Dec 21 '10 at 18:52
0

I'm no data centre expert, but my gut feeling about this is:

You need change control for everything that has a potential to have a significant impact on more than one customer.

While changes specific to a single customer can be left up to them to control if it is their request.

Significant impact would include anything that has one or more of the following effects:

  1. Forces the customer to effect a change in their use of the service (even if a provision has been made for such changes in the terms and conditions);
  2. Alters backup and restore operations;
  3. Alters build procedures.

I'm sure there are potentially many other reasons, but these are the key ones that come to mind.

asoundmove
  • 266
  • 1
  • 2
  • 6