slo-architect

Topics in the source

• SLO Architect
• When to use
• When NOT to use
• Core principle: an SLO is a promise about user experience
• Quick start
• The 3 Python tools
• slodesigner.py
• errorbudgetcalculator.py

Define SLOs that mean something. Most "SLOs" in the wild are arbitrary numbers no one believes — 99.9% on every endpoint, no SLI definition, no error budget, no policy for what happens when budget burns. This skill enforces the discipline from Google's SRE Workbook: pick the right SLI, set a target users actually care about, calculate the error budget, wire multi-window burn-rate alerts, and have a written policy for when budget runs out. Defining a new SLO for a service or feature Reviewing existing SLOs for common bugs Picking the right SLI (event-based vs time-window based vs request-based) Computing error budgets and burn-rate alert thresholds Tying SLOs to existing controls — feature flags abort, chaos blast radius, operator capability levels General observability strategy (metrics + logs + traces) → use observability-designer Customer-facing SLAs with legal teeth → that's contract drafting, not engineering Performance load testing (capacity, not reliability) → use performance-profiler Active incident response → use incident-response The four cardinal mistakes: 1. Target too high (99.99%+ on services that can't support it) — every minor blip violates SLO; alerts become noise.

This is an excerpt. Refer to the complete source and its current requirements.