Yonder Tech uses a streamlined Change Control Process for all live systems. This is to provide the below key benefits:
- Ensure changes with any potential operational impacts are fully considered prior to action.
- Ensure full rollback plans exist prior to action.
- Provide expert technical oversight, without undermining the wider staff-base's self-determination.
- Provides an audit trail to demonstrate appropriate actions were taken.
This process is not envisaged to be a blocker to new activity or introduce excessive administrative overhead. It will help reduce the incidence of accidental impingement on normal operations, but is still open to human error in all its forms.
What is covered by Change Control
Any change to a live/production system is within scope for change control. However, if the entire change is done within a fully version controlled environment then it does not require a change control request.
Examples Requiring Change Control
- Install a new development system on to a production server: while the new system itself isn't within change control, the fact it is being installed on to a production server introduces risk to the server and its other systems. As a result, it requires change control.
- Changing an existing database column data type to allow new feature usage: while the change may be to expand the data range, this could have unintended consequences on other systems and usage.
- Setting Live a new system: similar to installing a new system
Examples Not Requiring Change Control
- A script text label change when a new version of the script is created for this change: there is no risk to other scripts, systems etc from this change and there is a clear and absolute rollback/recovery path of using the old script version should it be required.
- Setting live a new script or new usage of an existing system where no changes to incumbent configuration is required: this is the border between what does and doesn't require change control. Common sense should be applied and if in doubt a change control request raised.
When a change to a live/production system has been identified as being required, a new request should be raised via the Request Platform. A change request may be for a single change item, or for a group of related and similar risk changes (e.g. multiple new SSRS reports).
- The primary request reviewers are Michael Hollett and Andrew Harvey.
- Secondary/Emergency request reviewers are Rob Farrance and Danny Jessup.
Requests should be logged by the team member who wishes to carry out the actions.
Note: the requestor and the reviewer can not be the same person.
Change Request Contents
A change request should detail the key information of the change and where it interfaces to other systems. It is not a review of the business rational or suitability of the change.
The steps of the process are:
1. Create the Change Request
- Create a new change request and include all key information relating to the change as the summary in the appropriate Pending list. See the template in the request platform for an example of the simple format of Summary and Risks.
- If you foresee any risks these should be listed under "Risks", and any mitigation/rollback proposals should be included.
- Assign yourself to the request
- Once the request has been logged, assign a present request reviewer to the request and they shall be notified.
2. Request Reviewer Actions
- The reviewer shall review the request details and discuss any unknowns with the requestor.
- The reviewer shall log any additional risks they have identified.
- The reviewer shall discuss appropriate mitigation and rollback processes with the requestor and record them.
- Once the reviewer and requestor are both happy with the request details and its risks & mitigation, the Reviewer will mark the request as either Accepted or Rejected and move it to the appropriate Reviewed list.
Example Completed Request