القائمة
Dashboards, alarms, and runbooks that make a service operable. Covers latency, error rate, availability, throughput, and severity-based alarming.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | Operational Excellence |
| description | Dashboards, alarms, and runbooks that make a service operable. Covers latency, error rate, availability, throughput, and severity-based alarming. |
| leadership_principles | ["Customer Obsession","Ownership","Insist on the Highest Standards","Dive Deep"] |
Operational excellence means your service is observable, alarmed, and documented such that any on-call engineer can understand its health and respond to problems—even at 3 AM without the original author available. This requires dashboards that show the right metrics at the right granularity, alarms that fire at the right thresholds with the right severity, and runbooks that provide actionable steps for each alarm.
Load agents/ops-bar-raiser.md when evaluating dashboards, alarms, runbooks, and operational burden. Use it to challenge whether the service can be diagnosed, mitigated, and rolled back by someone who did not write the code.
At Amazon, you build it, you own it, you operate it. There is no separate operations team that runs your service. The team that writes the code carries the pager. This means operational excellence is not an afterthought—it's a core competency of every engineer. A service without proper alarms is a service where customers discover problems before you do. A service without runbooks is a service where every incident requires the original author, creating a single point of failure.
Every service needs three dashboard levels:
Level 1: Customer Experience Dashboard (primary)
Level 2: Service Health Dashboard
Level 3: Deep Dive Dashboard
Alarms are categorized by severity and mapped to response actions:
P1: Critical — Customer-facing impact, immediate page
P2: High — Significant degradation, urgent page
P3: Medium — Degradation detected, ticket created
P4: Low — Informational, review during business hours
Every alarm links to a runbook that contains:
| Intention | Mechanism |
|---|---|
| "I'll add dashboards before launch" | Operational readiness review blocks launch without dashboards |
| "I'll write runbooks when I have time" | Every alarm creation requires a runbook link. No link = alarm rejected |
| "I'll tune alarms when they get noisy" | Monthly alarm review meeting. Alarms that fire >5x without action are auto-escalated to manager |
| "I'll monitor after deployment" | Deployment dashboard auto-opens on deploy. Bake time requires green metrics |
| What They Say | Why It's Wrong | What To Do Instead |
|---|---|---|
| "We'll add monitoring after MVP" | If you can't tell if MVP is working, you can't iterate on it | Monitoring is part of MVP. Ship metrics before features if you must prioritize |
| "Our error rate is fine at 0.5%" | 0.5% of 10M requests/day = 50,000 customer failures | Set targets based on absolute customer impact, not just percentages |
| "The alarm is too noisy, I'll suppress it" | Noisy alarms are a sign of a real problem (either the alarm or the service) | Fix the alarm threshold or fix the underlying issue. Never suppress without investigation |
| "We don't need p99.9, p99 is enough" | Your worst-affected customers live at p99.9. They're often your biggest customers | Monitor p99.9. Alert on p99. Dashboard shows p99.9 for awareness |
Applying Amazon's raise-the-bar principle to every code review. What reviewers look for — clarity, correctness, design, reuse, operational readiness. "Ship It" means the change raises or maintains the quality bar.
Blameless post-incident analysis focused on timeline, 5 Whys, mechanisms over people, and concrete action items with owners.
Internal /build flow mechanism that maintains fixed-size procedural memory of durable implementation-quality lessons.
Review a technical design before specs or implementation. Evaluate problem clarity, requirements, alternatives, trade-offs, architecture, dependency behavior, security, operations, cost, testability, and simplicity.
Bridge between an approved Design Document and code. Decompose the system-level blueprint into N vertical specs (requirements → design → tasks), each independently deliverable. Fail fast by ordering hardest-first. Execute wave-by-wave with approval gates.
Stage 4 of Working Backwards: Write the PR/FAQ — a press release announcing the product as if it already exists, plus a comprehensive FAQ addressing hard questions. This is the core Amazon mechanism that forces clarity, customer-centric thinking, and rigorous pre-mortems before any code is written.
