Menu
The ORR process — a self-assessment checklist covering monitoring, alarming, runbooks, on-call, scaling, security, deployment safety, cost, and dependencies. Must pass before launch.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
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.
| name | Operational Readiness Review |
| description | The ORR process — a self-assessment checklist covering monitoring, alarming, runbooks, on-call, scaling, security, deployment safety, cost, and dependencies. Must pass before launch. |
| leadership_principles | ["Ownership","Insist on the Highest Standards","Think Big"] |
An Operational Readiness Review (ORR) is a structured self-assessment that a team completes before launching a new service, feature, or significant change to production. It is a mandatory gate—nothing ships to production without a passing ORR.
The ORR is not a meeting with approvers. It is a checklist of operational requirements that the team fills out, providing evidence for each item. A senior engineer or principal reviews the completed ORR and either approves or identifies gaps. The ORR does not test whether the feature works—it tests whether the team can operate the feature in production when things go wrong.
The philosophy: if you can't operate it, you can't launch it. Writing code is 10% of the job. Operating it for years is the other 90%.
Load agents/ops-bar-raiser.md when reviewing ORR evidence. Use it to verify observability, alarms, runbooks, deployment safety, rollback capability, capacity, dependencies, and whether the team can operate the system under pressure.
The ORR originated from Amazon's experience launching services that "worked" but couldn't be operated. Teams would build features, demonstrate them in dev, and ship to production—only to discover at 2 AM that nobody knew how to restart the service, what constituted "healthy," or who to contact when the database filled up.
Amazon's ORR process has prevented thousands of operational incidents by catching gaps before they become 2 AM pages. The checklist has evolved over 15+ years from hard-won lessons. Each item exists because a team skipped it and suffered the consequences.
The ORR is owned by the team, not by a central authority. This reflects Amazon's ownership model: the team that builds it operates it. The ORR is their promise that they're ready to operate what they've built.
Feature Implementation ──────────────────────────────────────────→ Launch
│ │
│ Start ORR self-assessment │
│ (2-4 weeks before target launch) │
│ │ │
│ ▼ │
│ Team fills out checklist │
│ (identifies gaps, creates tickets for fixes) │
│ │ │
│ ▼ │
│ Gaps resolved │
│ (dashboards built, alarms set, runbooks written) │
│ │ │
│ ▼ │
│ Senior/Principal review │
│ (evidence verified, concerns raised) │
│ │ │
│ ├── Pass → Launch approved │
│ └── Fail → Fix gaps → Re-review │
│ │
└──────────────────────────────────────────────────────────┘
The ORR covers nine categories, each with specific items:
Each ORR item requires evidence, not just a checkbox:
| Item Type | Acceptable Evidence |
|---|---|
| Dashboard exists | Screenshot or URL showing real data |
| Alarm configured | Alarm ARN + proof it fires (test alarm history) |
| Runbook written | URL to runbook + name of person who tested it |
| Load test completed | Report showing results at 2x expected traffic |
| Rollback tested | Date of last rollback test + time to complete |
| On-call trained | Names of rotation members + shadowing dates |
| Security reviewed | Threat model document + review sign-off |
| Cost estimated | Spreadsheet with per-unit costs + projected volume |
| Status | Meaning | Required for Launch |
|---|---|---|
| ✅ PASS | Item complete with evidence | — |
| ⚠️ CONDITIONAL | Item partially complete, acceptable risk with mitigation | Mitigation documented |
| ❌ FAIL | Item not addressed | Must fix before launch |
| N/A | Item doesn't apply to this service (with justification) | Justification documented |
Launch criteria:
Format: 60-minute meeting with the team and a senior/principal reviewer
Agenda:
Within 2 weeks of launch:
| Mechanism | What It Enforces | How |
|---|---|---|
| Pipeline launch gate | No deployment to prod without ORR | Deployment system checks for approved ORR ticket |
| ORR template in team wiki | Consistent coverage | Team can't "forget" categories—template lists them all |
| Quarterly ORR re-assessment | Operational standards maintained over time | Calendar reminder triggers re-review of existing services |
| Reviewer rotation | Fresh eyes on operational readiness | Different reviewer each ORR prevents groupthink |
| ORR failure postmortem | Learning from gaps | If a launch incident maps to an ORR gap, team writes COE |
| Rationalization | Why It's Wrong | What To Do Instead |
|---|---|---|
| "We'll finish the ORR after launch, it's blocking our deadline" | The ORR exists because post-launch is when you need operational readiness. Launching without it is launching without a parachute. | Start the ORR 4 weeks before target launch. If it's not passing, move the launch date. |
| "We have monitoring, just not for everything yet" | Partial monitoring means you'll detect some failures and miss others. The ones you miss are the ones that become critical incidents. | Complete monitoring for all operations before launch. Use the checklist—every item exists because someone missed it and paid the price. |
| "The team is too small for on-call rotation" | If the team is too small for on-call, it's too small to own a production service. Two-person rotations work. | Establish rotation with at least 2 people. Cross-train aggressively. If truly single-threaded, escalation path to partner team required. |
| "Load testing is too expensive/complex for this service" | The production load is coming whether you test for it or not. Discovering your limits during peak traffic is not a strategy. | Use synthetic load testing tools. Even basic load tests (2x expected QPS for 30 minutes) catch most scaling issues. |
| "This is a low-traffic internal service, it doesn't need full ORR" | Internal services become critical dependencies for other teams. Low traffic doesn't mean low impact—batch jobs and cron jobs run at critical times. | Every production service gets an ORR. Scale the depth to the risk, but never skip it entirely. |
After completing the ORR, verify: