A fixed maintenance window every month, how do sites arrange their own maintenance plans
What about the site's maintenance plan for a fixed patch window every month? Align the window with the upstream fixed rhythm, and then schedule it in three stages: 'prepare one week before the window, only process the matched items on the day of the window, and verify and keep records after the window'. The upstream can align because they are also fixed: the Drupal core scheduling page reviewed on the day writes that the third Wednesday of each month (Coordinated Universal Time) is the security version release window. After the plan is fixed, maintenance changes from 'running after the announcement' to 'executing according to the calendar'.
Why does the upstream choose a fixed window
The fixed window is used to allow dependent parties to reserve personnel. In addition to Drupal's third Wednesday of each month, the release rhythm of WordPress is also announced in advance: the release page reviewed on that day indicates that Beta 1 will be released on October 20th, the candidate version on November 17th, and the official version on December 8th. A new default theme will be included with the new version. These two rhythms are one per month and one per year, but they can all be written into the calendar in advance, and there is no need for the site to use temporary overtime to deal with expected events.
What should be prepared in the week before the window?
Only three things are done in the preparation stage: list, backup, and grouping.
| Stage | Action | Completion standards |
|---|---|---|
| One week before the window | Export the program version and list of extended components, compare the impact range of the upstream announcement | Be able to list two lists: 'Hit items' and 'Non-hit items' |
| One week before the window | Run a full backup and simulate recovery | Record the time taken to recover and confirm that the data (including static files) can really come back |
| Three days before the window | Group the site according to the exposure surface, determine which group to move in this window | Each group has a rollback point and person in charge |
| The day of the window | Only update the hit items, do not change the function or theme | Each action can be rolled back individually |
| Two days after the window | Review the version, cache, response header and key process | Archive the review records, and abnormal items back to the tracking list |
The backup exercise is often skipped, but it is exactly the premise of whether the window can be held: without recoverable backups, anyone will choose 'let's not move this time' on the day of the window.
What to do and not to do on the day of the window
Only do the hit entries on the day. Three forbidden actions: do not upgrade the components not hit by hand, do not do template versioning, do not merge feature releases. The reason is that two types of changes are mixed together in the same day, it is not clear to attribute the cause when problems arise, and the rollback also needs to remove irrelevant changes.
Content scheduling should be avoided in advance. Use scheduled publishing to place marketing content outside the window, do not squeeze batch deployment and maintenance in the same period; hold the manuscripts in the window period first, and release them after the re-examination is passed. It is reliable to send the maintenance records to the relevant personnel by email on the day of the window, rather than补叙 in the group after the event.
Verification and record after the window
Perform a retest in four steps: Check if the version is truly within the repair range; clear program and external caches; check if the response headers of critical addresses are still publicly cacheable; run the core business process (submit forms, log in to the background, generate pages). The record format is fixed to three columns: what was changed, verification results, rollback point location.
The deployment method determines the speed of this step. For sites deployed with Docker images, rollback means rolling back to the previous tag and pulling up, which is minute-level; for sites deployed with Baota panel or LNMP commands, rollback involves the database and site directory, so the recovery exercise before the window is particularly important. No matter how stable the window arrangement is, there must be a way to go back.
Common questions
Is it necessary to keep the window open when the upstream issues an emergency notice temporarily?Emergency notices are processed by classification: anonymous and already in the wild can trigger a small window separately on the same day; the rest are still included in the nearest regular window.
Is it too sparse to happen once a month?It is sufficient for small stations that do not hit any entries. High-risk sites can bring the 'verification list' up to once a week, but the upgrade actions are still concentrated in a fixed window.
How to arrange for multiple sites to share one machine?Group by exposure surface, small stations first, main stations next, and leave time for re-examination between each group; the deployment of processes sharing the same process group will affect the recovery time, and this point should be taken into account when scheduling the window length.