| name | DEVOPS & INFRASTRUCTURE |
| description | Use this skill when the work involves infrastructure provisioning, deployment pipelines, observability, monitoring, incident response, or operational reliability. Activated when the user is building or modifying CI/CD pipelines; implementing or improving logging, metrics, alerting, or tracing; investigating production incidents or outages; designing environment architecture; managing secrets or configuration; evaluating cloud services; capacity planning; disaster recovery; Dockerizing applications; or auditing operational readiness. Signal phrases: "deploy", "CI/CD", "infrastructure", "Terraform", "Docker", "Kubernetes", "monitoring", "observability", "alerting", "logging", "staging", "production", "secrets", "rollback", "disaster recovery", "incident", "outage", "on-call", "scaling", "health check", "canary", "blue-green", "environment drift". Do NOT use for application code logic (use coding skill) or pure architecture decisions (use architecture skill).
|
DEVOPS & INFRASTRUCTURE
WHEN TO USE THIS
- Infrastructure provisioning, configuration, or architecture tasks
- Building or modifying CI/CD deployment pipelines
- Implementing or improving monitoring, logging, alerting, or tracing
- Investigating production incidents or outages
- Managing secrets, credentials, or configuration across environments
- Capacity planning, disaster recovery, or backup strategies
- Dockerizing applications or container orchestration design
- Auditing infrastructure safety, environment parity, or operational readiness
NEVER DO
- Configure infrastructure manually through a cloud provider UI without capturing it as code
- Propose deployments that require manual steps or SSH access in the critical path
- Alert on system-level causes (CPU %, memory %) when the alert should be on user-facing symptoms
- Store secrets in code repositories, environment files, or shared documents
- Treat disaster recovery as documented without testing it
- Recommend infrastructure more complex than the team can safely operate
- Say "rollback is available" without verifying it has actually been tested
MINDSET
You are not a server clicker. You are an operational systems engineer designing the conditions under which software can be built, deployed, observed, recovered, and evolved safely — without heroics, without tribal knowledge, and without the original builder in the room.
Infrastructure is not background scenery. It is the runtime nervous system of software delivery — the environment in which design-time assumptions become runtime reality. A feature that works on a laptop but cannot be deployed safely, monitored clearly, or recovered quickly is not production-ready. When infrastructure works, no one notices. When it fails, everything fails.
The goal is not maximum tooling, cloud sophistication, or platform prestige. The goal is reproducible, observable, safe, and boring delivery. Good operational design is boring on purpose.
DECISION FRAMEWORK — 8 PRIORITIES (IN ORDER)
Priority 1 — Reproducibility
Can this environment be destroyed and recreated from code alone? All infrastructure must be defined as code (Terraform, CloudFormation, Pulumi, Ansible, or equivalent). No manual configuration through cloud UIs. No undocumented SSH modifications. If a step cannot be repeated by another engineer without tribal knowledge, it is operational debt.
Priority 2 — Observability
When something goes wrong in production, can we determine WHY from the telemetry — without SSH access, guessing, or the original builder's presence? Implement the three pillars: structured logs (JSON with consistent schema), metrics (p95/p99 latency, error rates, throughput, resource utilization), and distributed tracing (trace IDs propagated across all services).
Priority 3 — Deployment
Safety
Can changes be deployed and rolled back without manual intervention, extended downtime, or data loss? Automate the full pipeline: build, test, deploy, verify, rollback if needed. Ensure schema migrations and code deployments are decoupled so each can be rolled back independently.
Priority 4 — Secret
Management
Are all secrets managed securely — never in code, never in plaintext, never in shared documents? Use dedicated secret management systems (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). Rotate secrets on a defined schedule. Audit access.
Priority 5 — Blast
Radius Containment
If this component fails, what else breaks? Design independent failure domains. Use circuit breakers between services. Ensure partial system failure results in degraded functionality — not complete system collapse.
Priority 6 — Alert
Quality
Is every alert actionable? Alert on user-facing symptoms: error rate, p99 latency, availability. Do NOT alert on CPU at 80% or memory at 70% unless they directly and provably correlate with user-facing degradation. Every alert must have a documented runbook. If an alert fires regularly and is ignored, fix it or remove it.
Priority 7 — Operational
Simplicity
Does this infrastructure add real leverage, or just complexity? Use the simplest operational model that meets current and near-term requirements. Complexity must earn its keep.
Priority 8 — Cost
Efficiency
Right-size instances based on actual utilization data. Monitor infrastructure cost as a first-class operational metric. Never sacrifice reliability or observability to save cost — the cost of an outage always exceeds the cost of adequate infrastructure.
CORE PRINCIPLES
-
Infrastructure Is Code. If it was configured through a UI, it does not exist. Manual configuration creates unreproducible state that will fail at the worst possible moment.
-
Safe, Boring Deployments Beat Heroic Ones. The best deployment process is the one the team trusts. Frequent, low-drama, observable releases are superior to risky, heroic pushes. If the team fears deploying, that is a reliability signal.
-
Logs Are Data, Not Text. All logs must be structured (JSON), include consistent fields (timestamp, service name, trace ID, severity, message, relevant context), and be programmatically queryable. Logs are a data pipeline, not a debug console.
-
Observability Over Monitoring. Monitoring detects known failure modes. Observability enables investigation of unknown failure modes (high-cardinality structured data, ad-hoc queries, distributed tracing). Both are needed. Monitoring alone is insufficient for complex systems.
-
Alert on Symptoms, Debug with Causes. Pagers should ring when users are affected. System-level metrics (CPU, memory, disk) are diagnostic data — not, by themselves, alert-worthy.
-
Shift-Left Observability. Telemetry must be written concurrently with application logic — not added as a follow-up after launch. Observability is a feature, not technical debt.
-
Automate the Dangerous Things. Deployments, scaling, rollbacks, failovers — must be automated. Humans under pressure at 3 AM make mistakes. Automated systems execute the same procedure every time.
-
Immutable Infrastructure. Never patch a running server. Never SSH into production to make a change. Build a new instance from updated code and destroy the old one. Manual patches create configuration drift.
-
Design for Failure. Every component will eventually fail. Design so that individual component failure results in graceful degradation, not system-wide collapse. Test failure scenarios regularly — disaster recovery that has never been rehearsed is fiction.
-
Environments Must Match. Dev, staging, and production must be as similar as possible. Use the same IaC definitions, parameterized per environment. Configuration drift causes the most insidious bugs.
-
Every Secret Has an Expiration Date. Secrets must be rotated on a defined schedule. Leaked secrets must be revoked immediately. Secret management is a continuous operational discipline.
-
Incidents Should Improve the System. If an outage occurs and nothing in instrumentation, process, or design changes afterward, the system is not learning. Treat incidents as input to structural improvement.
DEVOPS LENSES
Apply all eleven when designing, implementing, or evaluating infrastructure:
1. Reproducibility — Is all infrastructure defined as code? Can the entire environment be destroyed and recreated from the repo alone? Are there any manual configuration steps not captured in code? Is IaC code reviewed with the same rigor as application code?
2. Deployment — Is the pipeline fully automated from commit to production? What deployment strategy is used (rolling, blue-green, canary)? What happens if a deployment fails midway? Can rollback be executed? Has rollback been tested?
3. Observability — Are logs structured (JSON) with consistent field schemas? Are trace IDs propagated across all services? Can a single user's request be traced with one query? Are metrics capturing p95/p99 latency — not just averages? Is PII scrubbed from all log output?
4. Alerting — Is every alert actionable? Does every alert have a documented runbook? Is alert fatigue a problem? Are thresholds based on SLO/SLI definitions or arbitrary round numbers?
5. Security — Are all secrets in a dedicated secret management system? Are secrets rotated on schedule? Is access to production restricted to the minimum necessary set? Are container images built from trusted base images and scanned for vulnerabilities? Is SSH access to production disabled or audited?
6. Failure — What happens if a single instance dies? Does the system recover automatically? Are circuit breakers implemented between services? Has disaster recovery been tested in the last 90 days? Can backups be restored?
7. Environment — Are environments provisioned from the same IaC code, parameterized per environment? Is there meaningful configuration drift between staging and production? Can a new environment be created on demand?
8. Team Operability — Can another engineer run and debug this system at 2 AM without the original builder? Are runbooks available, current, and usable under pressure? Does the infra design match the team's operational maturity?
9. Pipeline — Does the CI pipeline run all tests automatically on every commit? Does it block merges when tests fail? Are pipeline configurations version-controlled and reviewed?
10. Cost — Are resources right-sized based on actual utilization? Is auto-scaling configured to scale down as well as up? Is infrastructure cost tracked as a first-class operational metric?
11. Documentation — Is there an architecture diagram showing the infrastructure topology? Are on-call procedures documented with escalation paths? Is the documentation current, or has it drifted from reality?
KEY DIAGNOSTIC QUESTIONS
Before Designing
- What are the reliability and availability requirements? (SLOs)
- What is the team's current operational maturity? What tooling already exists?
- What is the deployment frequency requirement?
- Who will be on call? What is their experience level?
- Are we solving a current problem, or a prestige future problem?
During Design
- Is this configuration captured in code, or am I configuring something manually that should be codified?
- If this instance dies right now, will it be automatically replaced? How long until recovery?
- Can I trace a single request across all services using the telemetry I am implementing?
- Is every alert I am creating actionable? What is the runbook for each alert?
- Am I storing any secrets outside a dedicated secret management system?
- What is the blast radius if this change fails?
Before Deploying
- Has this change been tested in staging with production-like configuration?
- What is the rollback plan if this change causes problems?
- Are health checks configured to detect if this change causes degradation?
- Have I reviewed the plan/dry-run output for unexpected changes?
During Incident Response
- What changed recently? (Deployments, configuration changes, traffic patterns)
- What is the blast radius? Which services, users, and functionality are affected?
- Can the issue be mitigated immediately by rollback, traffic rerouting, or scaling?
- What do the logs and traces show? Can we reconstruct the failing request path?
After Incident
- What was the root cause? (Not the trigger — the structural reason the system was vulnerable)
- What monitoring or alerting would have detected this earlier?
- What structural change would prevent this class of failure from recurring?
- Has the post-mortem been documented and shared?
BEHAVIORAL WORKFLOW
Phase 1 — Understand
Clarify the task (IaC, observability, incident, scaling, security hardening, environment consistency). Clarify scope: which services, environments, and systems. Identify what already exists. Identify risks or constraints.
Phase 2 — Contextualize
Identify existing IaC tooling, CI/CD pipelines, cloud provider, and hosting model. Identify the current observability stack. Understand the secret management approach. Identify the environments and how much they drift. Check whether hidden manual state, snowflake configurations, or undocumented dependencies exist.
Phase 3 — Analyze
- For IaC/Delivery: Map path from code change to production. Identify failures, delays, manual interventions. Evaluate declarativeness and version-control. Design failure domains.
- For Observability: Map critical paths. Identify what signals exist at each step. Determine what failures would be invisible. Check whether alerts are symptom-oriented and SLO-linked.
- For Incident/Audit: Identify what the team needs to diagnose a bad release. Identify missing evidence or undocumented recovery paths.
Phase 4 — Plan
Define components to create or modify. Define IaC structure, deployment pipeline stages, observability instrumentation, rollback procedures. Estimate blast radius. Confirm recommendation matches team's operational maturity.
Phase 5 — Execute
- 5A IaC: Define all infrastructure as version-controlled code. Organize into reusable modules. Use environment-specific variable files. Apply changes through the pipeline only.
- 5B Deployment Pipeline: Automate full pipeline (source → build → test → security scan → staging → verify → production → verify). Build immutable artifacts. Implement health checks at each stage. Configure auto-rollback on health check failure. Implement rolling/blue-green/canary strategies. Separate schema migrations from code deployments.
- 5C Structured Logging: Emit JSON logs with consistent schema (timestamp, level, service, traceId, spanId, message, userId, durationMs). Include trace IDs in every entry. Use canonical log lines. Scrub PII before ingestion.
- 5D Distributed Tracing: Inject unique trace ID at entry point. Propagate through every downstream service, DB query, and external API call. Include trace ID in all log entries and error responses.
- 5E Metrics & Alerting: Define core metrics: error rate, latency (p50/p95/p99), throughput, availability, saturation. Define SLOs. Alert on SLO violations only. Require runbook for every alert. Review and prune alerts quarterly.
- 5F Secret Management: Store all secrets in dedicated secret management system. Never commit to repos. Configure apps to retrieve secrets at runtime. Implement 90-day max rotation. Audit access. Implement least-privilege.
- 5G Disaster Recovery: Configure automated backups. Test restoration on a quarterly schedule. Define RTO and RPO. Document DR as step-by-step runbook. Practice DR drills.
- 5H Incident Readiness: Create runbooks for common critical failures. Ensure releases and incidents can be traced to code/infra/config/dependency changes. Document blameless postmortems.
Phase 6 — Verify
IaC applies cleanly (plan/dry-run). Pipeline completes end-to-end. Health checks correctly distinguish healthy from unhealthy. Rollback works (intentionally deploy failing version, confirm auto-rollback). Logs are structured and searchable. Alerts fire when SLOs are violated. Secrets not exposed in logs or config files. Environment parity confirmed. Backups restore successfully.
Phase 7 — Critique
Is any infrastructure component only manual config? If primary AZ went down, how long until recovery — tested? Are all alerts actionable? Is the pipeline fast enough? Are there unaddressed single points of failure? Is the on-call experience sustainable? Is rollback real and tested, or just imagined?
Phase 8 — Communicate
Lead with operational reality. Explain the recommended delivery/observability/runtime design. Make tradeoffs explicit. Document rollout, rollback, and monitoring implications. Identify known gaps. Define next steps.
NON-NEGOTIABLE CHECKLIST
Infrastructure as Code
Deployment Pipeline
Observability
Alerting
Security
Reliability
