Infrastructure System Change

Why Change Management

IT service change management exists as a discipline for several reasons. First, a majority of IT outages are due to changes—often unplanned changes. Change management can reduce the frequency of IT outages and mitigate the impact of errant changes. Second, IT organizations often have certain control objectives to meet business obligations, such as ensuring separation of duties to prevent any one person from being able to compromise institutional data. Third, change management can enable faster changing of IT: by creating a mechanism for changes to be approved, IT staff can submit changes, and by creating a mechanism for changes to be reviewed and scheduled, more changes can be implemented. Fourth, change management can help IT operate as a coherent system, where there is a systemic approach to decision-making rather than IT technicians feeling they must make often tough decisions between “doing their job” (e.g. patching databases, which requires downtime) and keeping IT services available.

IT service change management: changes to infrastructure hardware or software or configurations that have the potential to disrupt users.  Scheduled routine patches to system do not have to go through the official change management process. These items are posted on SURS intranet along with their corresponding schedule.

Process for Change:

  1. Submit a ticket using the Change Management/Infrastructure System Change service with the Change Management - System Change form.
    • Requester - the system change workflow assumes that the person performing the change is the person requesting the change.
    • Type of System Change - Change must be classified as one of the following:
      • Emergency - approved by Manager, CTO approves instead of CAB and notifies ELT
      • Normal - approved by Manager, CAB and ELT
      • Project - approved by Manager, PMO, CAB and ELT
      • Pre-Approved - approved by ELT
    • Suggested Date of Change - enter the date desired for change to take place
    • Description - A detailed description of the change must be given
    • Work Around Available - Describe if there is a workaround available
    • Impact - Specify impact: affects user, affects group, affects department, affects organization
    • Notify External Users -  specify if external users (members, agencies, etc. could potentially be impacted)
    • Urgency - low, medium or high
    • Backout Plan -  describe in detail the backout plan if change fails
  2. Once ticket is filled out and submitted, it will go through the approval process.
  3. Once all necessary approvals have been obtained, notifications must be sent by Manager to affected parties announcing what the change is and when it will happen. This include postings on website if needed.
  4. After notifications have been sent, Changes may be made on date/time scheduled,  Click complete on task "Perform Change".
  5. If changes were successful, complete task "Change Successful" as "yes" and ticket will be automatically closed.
  6. If changes were not successful, complete task "Change Successful" as "no" and task will get created to rollback change. The ticket will be changed automatically to "cancelled".  You can manually request a new date to try again and manually change ticket statuses or create a new change request.

 

Sample of Pre-Approved Changes are basically for NON-IMPACTING, NO DOWNTIME changes

  • Firewall Change Request
    • Whitelist/Blacklist IPs
    • Non-Impacting security policy change (limited scope)
    • Other non-impacting changes (address objects, IPSec tunnels, logging servers, etc)
  • Network Switch Change Request
    • Individual switch port config change
    • Logging server changes
    • Non-Impacting global setting change (SNMP, etc)
  • Emergency Maintenance
  • Authentication/Authorization Request (Cisco ISE Server)
    • Add MAC to authentication whitelist
    • Non-impacting modifications to authentication rules
    • Add/Delete network devices/resources