High Level: (CIO Council approved 3/3/2017)
- Send out email yearly with proposed dates to CIO Council, CITL, UMG.
Adjust as needed based on their feedback.
- Schedule work in advance and communicate to CIO Council, CITL, UMG on the intended use of Maintenance Window. Included will be: need, priority, outage hours and impacts possible during planned work.
- Exception Processing: Organization’s CIO would raise objection on use of previously communicated and approved Extended Maintenance Window and would escalate to the University IT OCIO for disposition or rescheduling.
UIT Extended Maintenance Window Procedure (University IT OCIO for review 3/22/2017)
On occasion, a longer period of contiguous time is required for IT maintenance which does not fit into a pre-established weekly maintenance window. In most cases, University IT needs to plan these events well in advance of the maintenance to insure that resources are available, broad communication has enough time to reach affected areas, and other groups can schedule supporting activities so the change can be successful.
When the length of the required maintenance activity exceeds the regular maintenance window and there will be (or is likely to be) impact to a large number of campus users, University IT will plan the work in an Extended Maintenance Window. This document establishes the communications and procedures by which the Extended Maintenance Windows are planned, scheduled for use, and exception processing (if needed). Application specific outages where business owners external to University IT take responsibility for approving and scheduling down time may be scheduled outside the pre-planned Extended Maintenance Windows.
1. Yearly Planning
- University IT Change Management Team will send out yearly email with proposed dates to the CIO Council, CITL (Campus IT Leaders) and UMG groups with prospective dates.
- CIO Council, CITL and UMG representatives will review dates with their respective organizations and reply if issue(s) exist with any of the proposed yearly dates.
- University IT CAB will also review the proposed dates.
- Each date published is a “Sunday” starting at 12:01 AM for 8 hours. If the entire 8 hours is needed for maintenance, pre-work to take down affected production services/applications can be scheduled to start the night before on Saturday at 11 PM, returning production to service by 9AM unless a longer time was requested.
- Dates will remain consistent from year to year to minimize confusion and impact on business, but when the need arises, can be adjusted based on feedback prior to end of proposed dates review period.
- After a 3 week review period, the Extended Maintenance Window dates are approved and published to change.stanford.edu.
- Everyone should assume that the Extended Maintenance Windows will be used as previously communicated and plan work accordingly on those dates.
- University IT staff should plan their work accordingly, using the established maintenance windows where possible and use the pre-approved Extended Maintenance Windows if work will take longer.
- University IT staff need to provide as much time as possible to announce and communicate the usage of a pre-approved Extended Maintenance Window. In general. this means that the Change Owner (or their management) should inform CAB about the work 4 to 6 weeks prior to the pre-approved Extended Maintenance Window.
- Once CAB or a member of the UIT Change Management team is informed of the work (via email or Change Request), the UIT Change Management team will communicate to CIO Council, CITL, and UMG on the intended use of the pre-approved Extended Maintenance Window.
- Included in the announcement will be as much information as possible. It will generally include:
- Extended Outage Windows dates and times
- Possible impacts during planned work (end user centric)
- Reviewed at CAB after the Change Request has been placed. In the case for Extended Maintenance Window usage, the lead time required is at least 2 weeks for the Change Request following the initial announcement (4 to 6 weeks if possible).
- If a pre-approved Extended Maintenance Window will not be used, inform CIO Council, CITL, UMG about the cancelation.
3. Exception Processing
- Objection raised by someone on the use an Extended Maintenance Window after the work has been announced, the objections should be elevated to that person’s representative on either CIO Council, CITL or UMG.
- That member of CIO Council, CITL, UMG will escalate the issue directly to a member of University IT OCIO for consideration.
- University IT OCIO will work with the Change Owner and CAB to determine a mitigation to or cancelation of the pre-approved Extended Maintenance Window.
- Emergency Changes required to restore or stabilize services that are currently experiencing a Major Incident do not need to seek exception approvals. Instead they should send the Incident Number and Change Request to the Commencement Monitoring distribution list.
Roles and Responsibilities
- CIO Council, CITL (Campus IT Leaders) and UMG (University Management Group) : Review proposed Extended Maintenance Window dates with their organization and report on significant conflicts. Communicate to their organization any scheduled use of an Extended Maintenance window. Manage an exceptions to approved Extended Maintenance Windows with University IT - OCIO member.
- University IT OCIO : Work with Stanford senior leadership when conflicts arise to mitigate scheduled maintenance of a pre-approved Extended Maintenance Window or have the date for the work changed.
- University IT Change Management Group : Coordinate communication of proposed, accepted, and scheduled Extended Maintenance Windows dates.
- University IT CAB : Review proposed Extended Maintenance Window dates with their group as well as scheduled use of existing maintenance window.
- University IT Staff : Notify University IT Change Management group as early as possible when an approved Extended Maintenance Window will be used by their group.
- R&DE has late night dining locations open until 2:30 during school years. (not a problem during summer)
- FSS & DMR like to avoid work for the first 8 days of the month since that Month End Close and report runs.