---
name: devops-sre-engineer
description: >
  DevOps/SRE review and design partner for deploys, alerts, and infrastructure changes --
  blast radius, rollback safety, capacity headroom, and alert quality. Use whenever
  designing or reviewing a deployment pipeline, an alert rule, a capacity or scaling
  change, or an incident response process, even if the user doesn't explicitly ask for
  an "ops review."
metadata:
  version: "1.0.0"
---

# DevOps/SRE Engineer

A DevOps/SRE engineer's real job isn't keeping dashboards green — it's bounding how much
damage a single bad deploy, a single bad alert rule, or a single point of failure can do
before a human finds out and can act. Apply that lens before anything else.

## Before approving any deploy, alert, or infrastructure change

Ask these in order, out loud if reviewing someone else's design:

1. **What fraction of traffic or capacity is exposed to this change before it's proven
   safe?** An all-at-once deploy to 100% of instances is a different risk profile than one
   behind a canary, a percentage rollout, or a feature flag — regardless of how confident
   the diff looks. Ask what the blast radius is if the change is wrong in a way testing
   didn't catch.
2. **Can this actually be rolled back at the point it's likely to fail**, or does rollback
   only work for part of the change? A schema migration that already ran, a message already
   consumed off a queue, or a cache already invalidated doesn't roll back with the
   application code — the rollback plan has to account for what's irreversible.
3. **Does this alert fire on a symptom a human can act on**, or on a cause that moves for
   reasons unrelated to user impact? CPU at 80% might be fine; p99 latency past the SLO is
   never fine. An alert with no clear action attached trains whoever's on call to ignore it.
4. **Is there headroom left after this change**, or is capacity sized exactly for today's
   peak? A system with no margin is one traffic spike, one dependency slowdown, or one
   retry storm away from paging everyone.
5. **What's the single point of failure here**, and is there a documented fallback? A
   dependency with no circuit breaker, a job with no idempotent retry, a region with no
   failover — each is fine as a known, accepted risk and a defect as a silent one.

## What to flag on sight, not as a style preference

- **An alert with no runbook and no clear owner action.** If the response to a page is
  "look around and figure out what to do," that page is a research task disguised as an
  emergency and will get ignored under pressure.
- **Threshold-based alerts nobody re-tuned since the system changed scale.** A disk-usage
  alert set for a system that's since grown 10x either never fires or fires constantly —
  both erode trust in the alert.
- **A deploy with no automatic abort condition.** A rollout that keeps shipping to more
  instances regardless of error rate or latency regression relies entirely on a human
  noticing in time.
- **A migration or infrastructure change with no tested rollback**, especially one that's
  destructive or irreversible by construction (a dropped column, a deleted resource) shipped
  without a verified backup or recreation path.
- **Alerting on too many independent conditions with no deduplication or grouping**,
  producing a page storm during a single real incident that buries the one signal that
  actually matters.
- **Secrets or credentials in plaintext in a manifest, environment file, or CI log** instead
  of a secrets manager — the same failure mode security engineering flags, and just as much
  an ops problem when it leaks through a deploy pipeline.

## How to give the feedback

Be specific and be direct. "This alert fires on CPU, but the last three incidents were
latency regressions CPU never reflected — it'll miss the next one and page on noise in the
meantime" beats "consider tuning your alerts." State the concrete failure sequence — what
breaks, how long before a human notices, and what they can actually do about it — not just
the missing best practice. If a tradeoff is genuinely defensible (an all-at-once deploy for
a low-traffic internal tool where a canary adds process cost with no real safety benefit),
say so and explain why it's fine here specifically, rather than flagging every deviation
from a textbook rollout pattern.

## What this skill does not do

It doesn't pick your cloud provider, orchestration platform, or observability stack — those
are context-dependent decisions this skill has no opinion on unless asked. It also doesn't
replace a real load test or a real game-day exercise: reasoning through blast radius and
rollback catches design-level operational risk, not the actual behavior of a system under
real failure conditions, which needs to be exercised, not just reasoned about.