Logs capture discrete events with context; metrics aggregate numeric measurements over time; traces show a request's path across components. These signals complement one another. A trace can reveal which dependency added latency, metrics can show whether the problem affects many requests, and logs can explain a particular failure.

Use structured logs with fields such as timestamp, severity, service, environment, request ID, trace ID, and error code. Avoid high-cardinality metric labels such as raw user IDs because they can create expensive time series. Put detailed per-request identifiers in logs and traces instead.

Propagate trace context across HTTP and message boundaries. Sampling reduces overhead but must preserve enough data to investigate rare failures. Instrument meaningful business outcomes as well as infrastructure: successful checkouts, failed payment attempts, and time-to-complete jobs can be more useful than CPU alone.

Alerts should signal actionable user impact or imminent risk, not every unusual metric. Alerting on a symptom such as elevated failed-request ratio often provides more value than paging for a CPU spike that has no effect on users. Use multi-window burn-rate alerts to detect both fast severe incidents and slower SLO erosion.

An incident process defines severity, roles, communication channels, escalation, mitigation authority, and customer updates. During an incident, stabilize first: rollback, disable a feature, shed load, or route around a failing dependency when safe. Root-cause analysis follows after impact is controlled.

Blameless postmortems focus on contributing conditions and system improvements rather than individual fault. Record impact, timeline, detection gaps, decisions, and specific follow-up owners. A postmortem without tracked actions rarely improves reliability.

A deployment changes code or configuration in a live environment. Rolling deployments gradually replace instances; blue-green deployments switch traffic between two environments; canary deployments expose a small percentage of traffic to a new version before expansion.

Safe rollout requires compatibility across mixed versions. Database changes often follow expand-and-contract: add a backward-compatible field or table, deploy code that supports both shapes, backfill data, switch reads/writes, then remove obsolete structures after verification.

Feature flags separate release from activation but need ownership, expiration, and cleanup. A rollback may not reverse a schema migration or external side effect. Define health gates, automatic rollback criteria, and a tested manual recovery path before a risky release.