Five things to record before restarting a server
A concise restart checklist covering affected users, dependencies, active work, recovery access and a meaningful post-restart test.
Source of concept: Incident Response – Google SRE Workbook. A checklist before the following reboot is an independent offer of this note, and the public order is not the reboot of all servers.
Restarting sometimes returns the service, but it may also destroy the most important evidence of failure. I think before that we need to know what we want to correct and how to measure success. Reshaping the operating system is not enough.
Five before the action.
- Effect on Users: Who is affected? Who confirmed the stop time and where was the information recorded?
- Attachments: What database, storage or authentication system? Read the stop and start of the same service document.
- Active work and evidence: Time processing, transaction, file transfer and backup operations are underway? Record errors and time before the temporary situation is lost.
- Recovery and Access path: The useable version is responsible for retrieval and consular access if the network fails? Don’t assume Snapshot without reviews, an independent backup.
- End criterion: Which user test confirms the health of the service and who announces the result?
Short registration, but useable.
A simple pattern for operation notes:
The cause of action: ... the affected services:... the documented evidence: ... responsible for the review; the post-launched test; the decision if the failure is:
This pattern is my suggestion to avoid a vague decision; it is not an alternative to the approved process of the organization or constructive guide. For clusters and services of redundancy, load evacuation and node role must be explored in accordance with the design.
After clarification, the work has not been finished.
In a hypothetical example, the web server has risen, but reporting timing services have not begun. A healthy entry page does not reveal this flaw. The review must return to the same things we listed before the stop.
If Restart temporarily resolves the problem, record the result closely: “After launch, the specified scenario succeeded; the reason has not yet been explored.”
Related study: Real Health Service.
Continue reading
All posts →
The runbook you need at three in the morning
A one-page service runbook template: purpose, dependencies, logs, health checks, recovery and escalation, without storing passwords in the document.
The server is up. Does the service actually work?
Go beyond ping with a real user scenario, an essential dependency check and an actionable alert. Define what a healthy service means.
A few minutes of clock drift: how much trouble can it cause?
Check Windows domain time sources and synchronization before changing settings. Distinguish clock drift from a time-zone display issue.