engineering-devops-automator

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: engineering-devops-automator
description: "Automate infrastructure provisioning, CI/CD pipelines, and cloud operations for reliable deployments. Use when you need Terraform infrastructure-as-code, Docker containerization, blue-green or canary deployments, monitoring and alerting setup, log aggregation, disaster recovery planning, secrets management, cost optimization, or multi-environment configuration with tools like Vault, ELK, Loki, or AWS."
metadata:
  version: "1.1.1"
---

# DevOps & Infrastructure Guide

## Overview
This guide covers infrastructure automation, CI/CD pipeline development, deployment strategies, monitoring, and cloud operations. Use it when provisioning infrastructure, building pipelines, setting up observability, managing secrets, or planning disaster recovery.

## First 10 Minutes

- Inventory the delivery surface before proposing changes: CI config, infrastructure directories, runtime manifests, Dockerfiles, and observability config.
- Run the existing validation commands before editing anything. If the repo has no validation path for infra changes, add one as part of the task.
- Use `scripts/analyze_deployment_risk.py` on the repo root to summarize CI, Docker, Terraform, and Kubernetes signals before proposing rollout changes.
- Identify the rollback path for the current deploy system. If you cannot explain how to revert the change in under 5 minutes, the rollout plan is incomplete.

## Refuse or Escalate

- Refuse "just push it" requests when there is no rollback path, no health signal, or no way to test the change outside production.
- Escalate before changing production state if the plan includes database replacement, Terraform destroys, state moves, certificate rotation, or security group broadening without a compensating control.
- Escalate when the repo mixes multiple deployment systems and ownership boundaries are unclear. Untangling that is a separate task.
- Do not recommend Kubernetes by default. If the workload is a single service with simple networking and predictable scale, stay with the simpler runtime.

## Infrastructure Decision Rules

### Provisioning
- Use Terraform with remote state (S3 + DynamoDB lock) so every resource is version-controlled and safe from concurrent modifications.
- Use Terraform workspaces or directory-per-environment layout with shared modules to catch drift between staging and production.
- Use the same Terraform modules as production with variable overrides -- never create infrastructure via cloud console.

### CI/CD Pipelines
- Structure as discrete stages (lint, test, build, scan, deploy) with explicit dependencies so security failures block deployment.
- Deployment strategy: **blue-green** for zero-downtime + instant rollback, **canary** for gradual traffic shifting with metric-based promotion, **rolling** when simplicity matters and brief mixed-version traffic is acceptable.
- Automate any manual step performed more than twice; delete the manual runbook entry to prevent drift.

### Containerization
- Use multi-stage Docker builds with distroless or Alpine final images to minimize attack surface.
- CI must run Trivy (or equivalent) and fail on CRITICAL/HIGH findings before merge.

### Monitoring and Reliability
- Instrument the four golden signals (latency, traffic, errors, saturation); alert on symptoms, not causes.
- Every alert must link to a runbook; alerts without runbooks get deleted or converted to dashboard metrics within one sprint.
- Enforce structured JSON logging; ship to centralized system (ELK, Loki) with compliance-aligned retention.
- Configure liveness probes for 30-second restart; set PodDisruptionBudget for availability during disruptions.

### Disaster Recovery
- Automate failover with runbooks tested quarterly; an untested DR plan is no plan.

### Cost Optimization
- Review cloud utilization monthly; downsize any instance averaging below 20% CPU over 14 days.

### Secrets Management
- Store secrets in Vault or AWS Secrets Manage