DevOps QA / Advanced: operational validation and governance / Lesson 15
Canary analysis, confounders, and uncertainty
Compare candidate and control observations fairly and preserve an inconclusive outcome when the experiment cannot support a decision.
On this page
Lesson goals
- Identify cohort imbalance, sparse data, and invalid aggregation.
- Predefine metrics, windows, and decision criteria.
Make candidate and control comparable
A canary comparison asks whether the candidate changes an outcome under sufficiently comparable conditions. Traffic mix, geography, device type, customer tier, cache warmth, dependency load, and time of day can confound the comparison. A candidate serving mostly easy requests can look better while being worse within every important class. Define assignment and analysis units, record exposure, and compare relevant strata. Random assignment can reduce bias when feasible, but small cohorts still vary. A dashboard difference alone is an observation, not proof that the candidate caused it.
Commit to the analysis before seeing outcomes
Choose primary indicators, guardrails, minimum data, observation windows, and action thresholds before inspecting the candidate result. Repeatedly checking until a favorable p-value or graph appears changes error behavior; use a justified sequential method or a fixed analysis plan. Multiple metrics create more opportunities for chance findings, so distinguish primary harm signals from exploratory diagnostics. The synthetic plan below records scope and an inconclusive result. It is not a statistical engine. A real team should choose methods appropriate to dependencies between observations and the business cost of false promotion versus false rejection.
{
"primaryMetric": "eligible-booking-failure-rate",
"guardrails": ["data-integrity", "tail-latency"],
"strata": ["request-class", "region"],
"analysisWindow": "predeclared-lab-window",
"insufficientData": "inconclusive",
"repeatedLooks": "use-reviewed-sequential-policy"
}
The fields are application-defined and do not implement statistical corrections. A reviewed plan must specify actual sample and uncertainty methods. No live traffic, monitoring query, or rollout controller is connected to this example.
Aggregate rates with explicit weights
Averages of percentages can mislead when denominators differ. Sum compatible bad and eligible counts for a pooled rate, or compare strata under a common reference mix when composition differs. Tail percentiles cannot generally be averaged to obtain a global percentile; use compatible underlying histograms or raw observations with a documented method. The example computes a standardized failure rate from per-class counts and predetermined weights. It illustrates mix control only. Missing strata must not be dropped silently, and uncertainty still requires a method suited to the data-generating process.
def standardized_rate(counts, weights):
if set(counts) != set(weights) or abs(sum(weights.values()) - 1) > 1e-9:
raise ValueError("INVALID_STRATA")
result = 0.0
for name, weight in weights.items():
bad, total = counts[name]
if weight < 0 or total <= 0 or not 0 <= bad <= total:
raise ValueError("INVALID_COUNTS")
result += weight * bad / total
return result
Use the same predeclared weights for candidate and control and define the strata consistently. This is not a significance test, and correlated events or changing assignment can invalidate naïve uncertainty estimates. The function performs arithmetic only.
Interpret sparse outcomes honestly
Zero observed errors does not imply a zero underlying error probability. Small samples can support only broad conclusions, especially for rare severe failures. Require both statistical and practical significance where the analysis method supports them: a tiny reliable change may be operationally irrelevant, while a large but uncertain harm signal may justify holding exposure. Do not increase exposure merely to collect data when the potential harm is unacceptable. Complement observations with pre-release tests, targeted synthetic checks, and integrity invariants, keeping the limitations of each source visible.
Make the conclusion reproducible
Keep the candidate and control identities, exposure assignment, raw bounded aggregates, data-quality checks, analysis version, and decision rationale. Reanalysis should reproduce the result under the declared method rather than selecting a new baseline after a failure. Investigate surprising differences using traces and stratified views before changing policy. If candidate and control both degrade because of a shared dependency, a relative comparison can look neutral while users suffer; absolute SLO and integrity guardrails remain essential. A mature evaluator can say hold because the experiment is invalid rather than forcing every observation into pass or fail.
Common errors and fixes
A candidate wins only because it receives easier traffic
- Why it happens
- Cohort composition is ignored.
- How to fix it
- Compare meaningful strata or a justified common mix.
- Prevent it next time
- Record assignment and balance checks before analysis.
Regional p95 values are averaged as global p95
- Why it happens
- Percentiles are treated as additive metrics.
- How to fix it
- Use compatible distributions and a documented aggregation method.
- Prevent it next time
- Review metric algebra with the analysis plan.
A gate keeps looking until a candidate passes
- Why it happens
- Repeated analysis has no sequential policy.
- How to fix it
- Use a fixed or reviewed sequential decision method.
- Prevent it next time
- Predeclare windows, metrics, and action criteria.
Check your understanding
1. Candidate and control have equal aggregate error rates, but candidate is worse in each request class. Explain a plausible cause.
Show worked solution
Different traffic weights can hide within-class regressions. Inspect denominators and assignment, then compare with common justified weights or matched strata. The aggregate equality does not settle causality or safety. Preserve absolute guardrails and uncertainty.
2. Both candidate and control slow down during a database incident. What should a relative canary gate do?
Show worked solution
Avoid declaring success merely because the difference is small. Apply absolute user-impact guardrails and classify shared degradation or invalid comparison. Hold exposure and use incident procedures as appropriate; the control is a comparison, not an exemption from service requirements.
Key takeaways
- Fair comparison requires valid assignment, denominators, and aggregation.
- Uncertainty and practical impact both matter.
- Absolute guardrails protect against shared degradation.