Changes and maintenance

A change begins with a summary and the service it affects. The change manager records risk, scheduled start and end, and a rollback plan before moving the record into Review. A reviewer can then decide whether the planned work is Approved or Rejected. Approved work can move to Implementing, then Verified when the result has been checked. Rolled back preserves a different outcome when the plan had to be reversed.

These states help a team distinguish a proposal from an authorized window and a started change from a verified result. The scheduled dates give the service owner a concrete interval to discuss with customers. A component can show Maintenance when the visible service is deliberately affected, but the component state should be checked against the actual work rather than set solely because a change exists.

• Plan. Name the service, risk, window and rollback approach.
• Decision. Review the change before treating the window as approved.
• Outcome. Record implementation, verification or rollback in the change state.

Agree who drafts a change, who makes the approval decision and what information is required for each risk level. Decide how much notice service users need for a planned maintenance window and who writes that communication. The change record can supply the schedule and outcome, while message delivery remains a separately configured connection.

Set the meaning of Verified: the person reviewing a finished change should know which service behavior was checked. Decide how a rollback is recorded when the scheduled end has passed but the service remains affected. Keep the change summary concise enough to identify the work without hiding the practical risk. A rollback plan needs instructions useful to the on-duty team, not just a statement that rollback is possible.

The team plans an authentication service upgrade. The change manager records a Medium risk, the scheduled window and the rollback steps, then moves the change to Review. The reviewer checks whether the window conflicts with another service event and approves it. Before work begins, the service owner checks the related component and the customer communication plan. At the start of the window, the change becomes Implementing.

If sign-ins work after the upgrade, the team marks the change Verified and returns the component to Operational after checking the customer experience. If sign-ins fail and the team restores the earlier version, the outcome is rolled back. Either path retains the planned start and end so later reviews can compare the intended window with what happened.

• Change schedule — See approved and implementing work by start and end.
• Change approval inbox — Review changes waiting for a decision.
• Component status board — Check the visible service state during maintenance.

Rehearse a maintenance change before a customer-impacting window. Review implementation for service ownership and communication setup.