The upstream releases a high-risk patch every six to eight weeks, how long should the maintenance window of the site be set?
The upstream program releases a high-risk patch every six to eight weeks on average, how long should the site maintenance window be: A single window of several hours is more reasonable, relying on 'stable frequency' rather than 'sufficient single duration' to absorb the patch rhythm. Accumulating enough in one go and making changes all at once is equivalent to opening the risk exposure for the entire accumulation period. It is clear when the two sets of standards are checked on the same day: The rhythm of upstream high-risk patches is every six to eight weeks, while the median time for large-scale exploitation is only five hours, and human response speed is naturally slower than exploitation speed.
Two numbers: patch rhythm and exploitation speed
The former explains that 'the environment needs to be moved about seven or eight times a year,' and the latter explains that 'the time left for the site owner after the announcement is not days but hours.' These two numbers determine the shape of the window: the window length can be short, but enough short windows need to be reserved in a year, and each window should be able to start on the day of the announcement.
If the team's current situation is that they can only handle things at the end of the month, then additional mitigation measures should be added outside the window, and 'temporary relief' should be managed as an action with an expiration date.
How to determine the window length
| Stage | Time investment | Actions that must be completed | Complete judgment |
|---|---|---|---|
| Before the window | One to two days of preparation | Confirm the affected area, reproduce the test environment, and generate a recovery point | Can return to the current state according to the recovery point |
| Within the window | Several hours | Only move one layer: choose one between the program or running environment | Verify each key page and interface |
| After the window | Observe for one to two days | Check logs and abnormal logins, and verify the collection and push | Leave a verifiable verification record |
Determine if the window is long enough, not just looking at what time the patch is finished, but whether the problem can be rolled back within the same window. The rollback path is clear, two hours are enough; the rollback depends on on-site exploration, and even a day is not enough.
The list before, during, and after the window
The most important thing before the window is the recovery point. The backup capability of AnQiCMS can directly generate recovery points for data and files, and only the recovery points that have been practiced count as existing; only sites that have never been restored are backed up, and the window will still be stuck inside.
Move only one layer at a time inside the window: separate the version upgrade of the running environment from the version upgrade of the program itself, so that the cause can be judged immediately when an error occurs. After the window, leave a verification record, write down what was changed that day and which pages were verified, and read this record before the next window starts instead of relying on memory.
How to schedule content to avoid the window
The most likely problem in maintaining the maintenance window is not the traffic peak, but the release plan itself. Use scheduled releases to schedule articles, event pages, and update announcements outside the window, which can avoid two things: first, concurrent database changes and content writing within the window, and second, rolling back and undoing the newly released content after the window. Scheduled releases are also a part of the time factor; when the scheduling table and the operation and maintenance calendar are viewed on the same table, conflicts are visible at a glance.
It is recommended to freeze large-scale write operations such as batch imports and full-site replacements on the day of the window, as they can amplify the rollback cost when they occur simultaneously with upgrades.
Common questions
Can the window be extended to a full day to gain extra space?\nAnswer: Not recommended. The longer the window, the easier it is to move multiple layers at the same time, making it difficult to attribute problems, a short window with sufficient preparation is more stable.
How long can the temporary relief measures hold up?\nAnswer: Only until the patch is implemented, it is necessary to set an expiration date and assign a responsible person, otherwise it will remain in the environment for a long time.
How should the window be scheduled for unattended small stations?\nAnswer: Fixed to the same time period every month with a short window, equipped with automatic backup and email reminders, after the window only check whether the reminder has been restored.