Skip to content | Change text size

ITS home
 

DSM Change Management

Contents

Why is DSM Change Management Important

Business critical IT services such as SAP, Calista, MUSO, my.monash, web and email are reliant on the data storage and will be unavailable if the data storage is unavailable. As it is unacceptable for these services to be unavailable, changes to the data storage environment must under go rigorous testing and comply with strict change management processes before being implemented into the production environment.

DSM change management does not remove the need to comply with ITS Change Management but enhances it. DSM change management is the process of developing & testing new technologies or necessary software upgrades before implementing into the production environment. ITS Change Management is more a "gate keeper" role to production which provides visibility to other areas of what is moving into production.

 

DSM Change Management Principles

The purpose of the change management principles is to define the system governing the introduction of new technology, service upgrades and other changes in the DSM environment. These changes can be initiated from various areas including vendor upgrades or new technology, customer requests, or internally from the DSM team investigating new DSM strategies.

The primary purpose of these principles is to ensure that nothing is changed in the DSM environment without consultation and authorisation of the other members of the DSM team to make certain all possible consequences can be considered.

  • DSM change management process applies to all landscapes of the DSM environment, with the exception of isolated (not coexisting on shared hardware with production) test environments
  • All changes will be presented by the Change Owner to the DSM team before any physical work can begin in any DSM environment
  • Before any changes can be applied to the test environment, they must be authorised to proceed by Data Storage Manager and the relative Technical Authorisers. The technical authoriser and the change implementer cannot be the same person.
  • Before any changes can be migrated from the test environment to the production environment the following must be completed;
    • Change Owner must present the testing results to DSM team
    • The change must be signed off by the respective technical authoriser
    • The change must be signed off by the Data Storage Manager
  • The change must comply with ITS Change Management policy
  • All changes will be recorded and tracked in the ITS Change Management system
  • Where possible, all new components will be installed in the test environment for a minimum of one week prior to being moved to production. This is to confirm the health of the new component and ensure the various firmware versions are compatible with existing production environment. 
  • In the event of hardware failure, replacement parts will be sourced from the test / development environment where they are known to be healthy and compatible with the production environment.

DSM Change Management Authorisers

Role Primary Secondary
Data Storage Manager Steven White Russell Keil
Technical Authorisers    
Network Kheeran Dharmawardena Tom Maher
Disk Storage George Scott Stuart Lamble
Tony Cataldo
Tape Library George Scott Stuart Lamble
Tony Cataldo
Backup & Restore SW Cyrus Khavar George Scott
Tony Cataldo

Stuart Lamble
Chris Bourke
Tivoli Storage Resource Manager Steven White Cyrus Khavar
Chris Bourke

Return to Top of Page

Routine Changes

Applying the formal change management process to all changes can impede the provision of a flexible and responsive services. Therefore, for practical reasons, changes which are minor and performed as part of normal duties on a frequent basis can be pre approved and performed with minimal change management. These are classified as routine changes.

The factors that decide whether the routine change management process can be applied to a change are;

  • the level or risk associated with the change;

  • whether this is a routine task which the change implementer is comfortable with carrying out; &

  • has this change been documented and signed off for pre-approval

A routine change is a change that has a documented procedure. The document template is available at  http://www.its.monash.edu.au/staff/systems/dsm/technical/forms/index.html.

Return to Top of Page

Changes Classified as Routine Changes

 

These type of changes can be classified as routine changes which are used for day to day management or provisioning of storage. These changes are documented and the people performing these changes are familiar with the tasks involved and associated risk.

The documented procedure for performing these tasks must be followed to minimise risk.

 

Component Task Sub-Task Risk Level Routine Change Management
9509 Switch Add a New Server Port Allocation L Yes No
    Port Zoning (peer review) M Yes No
  Routine Configuration Changes Password L Yes   No
           
DS4500 / XSI /IPstor Assign storage to a server Creating / removing the luns L Yes No
    Extending of luns L No No
    Map luns to server L Yes No
  Connecting  a new Server   L Yes No
  Replacing a faulty disk   L Yes No
           
           
Backup Restore Facility Tape Library Adding or removing cartridges  L No  
           
           
   TSM Adding or modifying a new client L Yes No
    Changes to Schedules L    
           
           
           
           
           
 

* Note these hardware components must still comply with the principle, "Where possible, all new components will be installed in the test environment for a minimum of one week prior to being moved to production. This is to confirm the health of the new component and ensure the various firmware versions are compatible with existing production environment."

Return to Top of Page