performance-slo-planner

Performance & SLO/SRE Planner

Turn vague "it should be fast and reliable" expectations into measurable SLIs, SLOs, a load model, a test matrix, and a reliability backlog for production readiness. Pairs with Azure Load Testing tooling for execution. This skill plans; it does not run the tests.

When to Use

• Defining service level objectives and error budgets before launch.
• Characterizing load behavior (steady, peak, spike, soak) for a system with "no characterized load."
• Setting latency/throughput budgets and a false-positive/accuracy baseline.
• Producing a reliability/SRE backlog for a production-readiness review.

When Not to Use

• Running the load tests: hand the test matrix to the Azure Load Testing tools.
• Security, RAI, or privacy concerns: use the respective specialist skill.
• Authoring or restating requirements: cite the PRD's existing NFR ids rather than re-deriving targets.
• Redefining user journeys: reference the PRD's existing FR ids rather than inventing flows.

Inputs

Gather what exists; flag what is missing as an assumption to validate.

1. Business goals (BRD): the business objectives and risk tolerance behind the targets (for example revenue-critical flows, contractual SLAs) that justify each SLO and error budget.
2. Critical user journeys: the flows that must stay fast (for example: incident ingest → display, dispatch action, alert acknowledge).
3. Stated NFRs (PRD): latency/availability targets from the PRD's NFRs, Success Metrics, and Operational Readiness sections (for example stratified SLAs like "Critical ≤ 60s, Standard ≤ 3min").
4. Traffic assumptions: expected and peak concurrency, request rates, and growth.
5. Accuracy expectations: false-positive tolerance where relevant (for example alerting).

Procedure

1. Identify SLIs. For each critical journey pick measurable indicators: latency (p50/p95/p99), availability, error rate, and accuracy/false-positive rate where relevant.
2. Set SLOs and error budgets. For each SLI define a target, a measurement window, and the resulting error budget. Anchor each SLO to a specific PRD NFR id when present; otherwise propose a target and mark it [ASSUMPTION] for tuning.
3. Define the load model. Specify steady-state, peak, spike, and soak profiles with concurrency/rate and duration for each.
4. Build the test matrix. Map each load profile to the journeys it exercises, the pass/fail SLO thresholds, and the environment.
5. Plan capacity and degradation. Note scaling assumptions, saturation points, and required graceful-degradation behavior (no silent fidelity drops).
6. List observability hooks. Name the metrics/traces needed to measure each SLI in production; an SLO you cannot measure is not real.
7. Write the backlog to .copilot-tracking/performance-plans/<date>-performance-slo-plan.md using the Output Format.