Who owns what
Operations work is split into a few roles. This page says what each role does and who decides what. Read it on your first day of production duty.
How it works
A role is a hat, not a person. In a small team one person wears two or three hats. What matters is that every hat has exactly one name on it each week. If nobody owns a task, nobody does it.
The roles
| Role | What they do | Typical rota |
|---|---|---|
| Release owner | Decides what goes to production and when. Runs the pre-release checks on Production release safety. Only one person ships to production at a time. | Per release, or per week |
| Production duty (on-call) | Runs the daily production check. First to look when an alarm fires. Leads the incident flow until someone else takes over. | Weekly, handed over in writing |
| Infra owner | Owns Terraform, the CI/CD pipelines, AWS accounts, DNS and certificates. Reviews every infra change. Runs terraform apply. | Long-lived |
| Security owner | Owns who can access what: SSO, MFA, IAM, secret rotation. Reads GuardDuty and CloudTrail findings. Runs the weekly security scan. | Long-lived |
| Mobile release owner | Builds and submits app store releases. Checks symbol upload and version numbers. Watches crash-free users after a rollout. | Per release |
| Cost owner | Reads the monthly bill. Owns spend caps on AI providers. Removes idle resources. | Monthly |
Who decides what (RACI)
RACI means: Responsible (does the work), Accountable (owns the result, one person only), Consulted (asked before), Informed (told after).
| Activity | Release | Duty | Infra | Security | Mobile | Cost |
|---|---|---|---|---|---|---|
| Daily production check | I | A/R | I | I | C | - |
| Production API or web release | A/R | I | C | - | - | - |
| Rollback during an incident | C | A/R | C | - | - | - |
| Incident communication | I | A/R | I | I | I | - |
| Incident write-up | C | A/R | C | C | C | - |
terraform apply on staging or prod | I | I | A/R | C | - | I |
| New pipeline or new service | C | - | A/R | C | - | I |
| Secret rotation | I | I | R | A | - | - |
| Grant or remove AWS access | - | - | R | A | - | - |
| GuardDuty finding, severity 7 or higher | I | R | C | A | - | - |
| App store submission | I | - | - | - | A/R | - |
| AI provider key, quota or spend cap | I | C | R | C | - | A |
| Monthly spend review | - | - | C | - | - | A/R |
Rules
Only one person ships to production at a time. Two people deploying in parallel caused releases to revert each other. Before you tag, ask in the team channel and check every production pipeline for a run in progress.
Production duty is handed over in writing. Write what is open, what is being watched, and what is safe to ignore. A verbal handover loses the details that matter at 2 a.m.
The person who wrote a change does not approve their own production release. A second pair of eyes catches the stale base, the missing migration, or the wrong account.
Mistakes we made
- Two people shipped production on the same day. One deployed by manual pipeline runs, the other by tag, built from an older base. The tagged releases removed the other person's features from production, twice in one day. Name one release owner per day.
- Nobody owned AI provider spend. A monthly spending cap tripped and every realtime AI session failed. It looked exactly like a code bug. The cost owner now watches the provider spend page and gets the cap alert.
- Nobody owned access reviews. Every human IAM user in production had admin rights and no MFA, and nobody noticed until the first full security scan. The security owner now runs a weekly check.
Checklist
- Every role on this page has a name for this week.
- Production duty has a written handover from last week.
- The team channel knows who the release owner is today.
- Each person knows which roles they hold and where the runbooks are.