Changes

A change has a service, summary, risk level, scheduled start and end, and rollback plan. These details let the Change Approver decide whether the proposed work can proceed. The status separates a draft from a reviewed proposal, an approved change, implementation and its final verified or rolled-back outcome. A short summary alone cannot explain an operational decision.

Keep the schedule attached to the same service that the incident or problem affects. If a platform operator proposes a workload adjustment, the reviewer should see the intended window and how the team would recover if the intervention does not work.

• Prepare. Platform Operator records the service, risk, window and rollback plan.
• Decide. Change Approver reviews the proposal and approves or rejects the change.
• Confirm. The operator records implementation and then verifies or rolls back the outcome.

The schedule view groups approved and implementing changes with both window boundaries. It helps the team see when work was planned. The outcome board separates verified, rolled-back and rejected decisions for later review. A rejected proposal must remain distinguishable from one that was implemented and reversed.

Choose the person authorized to approve a change and the evidence expected for each risk level. Agree on how scheduled windows are recorded, including the time convention used by the team. Decide who records the implementation result and who checks verification against the service and cluster observations.

If execution occurs through a deployment pipeline or Kubernetes controller, configure that connection separately. Keep the pipeline result available to the operator, but retain the approved plan and the recorded outcome in the change history. The status should reflect the actual reviewed decision and work result.

An incident points to repeated readiness loss in a production workload. The operator drafts a service change with a rollback plan and a window after peak traffic. The Change Approver reviews the risk and approves the proposal. The operator moves the change into Implementing and compares a later workload observation with the earlier one before marking the change Verified. The execution details remain with the system used to perform the work.

If ready replicas fall further, the operator follows the rollback plan and records rolled back. The incident responder then updates the incident with the continuing service impact. A change marked Verified while the related service remains impaired would need an explanation grounded in the actual service outcome.

• Changes for review — Inspect the risk, schedule and rollback plan awaiting a decision.
• Change window schedule — See approved and implementing work with start and end dates.
• Change outcome board — Compare verified, rolled-back and rejected changes.

Rehearse change review and compare its record model.