Operational readiness starts early

Design for day two

Production begins after the launch moment

A successful deployment proves that a change reached an environment. It does not prove that the application can be supported through an outage, a provider issue, an expired credential, a bad data change, or a staff handoff.

Owners prepare for these moments while the system is still being shaped. A team that decides what to observe can build the right logs and health checks. A team that defines recovery can test rollback and restore. A team that names support ownership can give Operations useful information instead of an unfamiliar production surprise.

• Name business and technical owners with a maintained contact route
• Describe users, business impact, dependencies, data, and critical operating periods
• Define useful logs, health signals, alerts, and response ownership
• Document safe triage, escalation, communication, rollback, restore, and recovery actions
• Test the runbook with people who did not write the application

Connect signal to action

A dashboard does not respond to an incident

Logs record events, metrics show measurements, alerts call attention to selected conditions, and provider status pages report the provider's view of its service. Each can help, but none owns the response. An owner must decide which signals matter, who receives them, what first action is safe, and when to escalate.

The most useful signal leads to a decision. A high error rate may tell the application team to inspect a recent release. A provider incident may send Operations to the provider escalation route. A healthy provider status page does not rule out an application configuration, data, identity, or integration failure.

• Signal: what changed or crossed a meaningful threshold?
• Context: which application, environment, users, and dependency are affected?
• Owner: who investigates first and who must be informed?
• Action: what safe check, containment, rollback, or escalation follows?
• Evidence: what record will help the next responder and the later review?

Choose the right recovery move

Rollback, restore, and recovery are not synonyms

Rollback reverses a change, such as application code or configuration. Restore brings data or a system state back from a known copy or recovery point. Recovery is the broader work of returning the business service to an acceptable state. A technically healthy component may still leave users unable to complete their work.

Owners should define which action applies to likely failures and who can authorize it. They also need to account for data created between the incident and the recovery point, downstream effects, user communication, and confirmation that the business process actually works again.

• Rollback plan: how to reverse code, configuration, and provider changes
• Restore plan: what can be restored, from where, by whom, and with what data consequence
• Continuity plan: how essential work continues while normal service is unavailable
• Recovery confirmation: who verifies technical health and business usability

Read the status label

Ember has proposed routes, not final operating policy

The Ember support draft proposes Service Desk intake, IT Operations triage, escalation to Engineering for platform expertise, and provider escalation when a provider issue is suspected. It also proposes that Operations track provider tickets to closure and coordinate backup, restore, and rollback with Engineering support.

The monitoring draft proposes provider-status ownership, audit review, URL monitoring decisions, severity mapping, and response expectations. Both documents remain approval needed. IT Operations approval and required concurrence are MISSING, and implementation evidence is INSUFFICIENT. Owners may use the drafts to prepare questions and artifacts, but must not present the proposed process as adopted policy.