Config change

Treat model-serving equivalence as a production SLO. Run sensitive quality evaluations continuously on the real serving matrix, segment signals by model, hardware, route, and context configuration, and connect feedback spikes to recent infrastructure changes while preserving user privacy.

Treat feature flags as production deploys with a state space. Validate partial and mixed-version combinations, canary global control points, and stop on sudden authorization anomalies. GitHub added traffic-anomaly monitors and expanded rate-limit scaling tests for the missed edge case.

Database configuration changes need staged rollout and automated fast-rollback — a single bad config push that breaks health check responses can cause the routing layer to simultaneously drop all database hosts, producing a total outage with no code change involved.

Network and routing changes deserve the same staged rollout and review as application code. The "resilience project" is itself a risk window.

A latent bug can sit quiet until ordinary input you don't control wakes it. That input is part of your test matrix.

Your process manager may silently cap OS resource limits like LimitNOFILE to a value orders of magnitude below what you configured — always check the actual ulimits live in production processes, not just the config files.

Config changes need the same staged rollout as code. "It's just a rule" is how a global outage starts.

Capacity you can't actually schedule isn't capacity. Test that autoscaling can really claim idle resources under real load.

Configuration parameters that control minimum capacity thresholds must have semantic validation — silently defaulting to zero when a floor setting is removed is a single config push away from a regional outage.

Tooling should refuse to remove capacity below safe thresholds. And your status page must never depend on the thing that's down.