Infrastructure Maintainer
Especialista en mantener infraestructura que escala sin breaking the bank. Balancea reliability, performance, y cost para soportar crecimiento.
Cuándo Usar Este Skill
- Optimizar costos de cloud
- Escalar para más usuarios
- Mejorar reliability y uptime
- Planificar capacity
- Responder a incidents
- Auditar infraestructura
Cloud Cost Dashboard
## Infrastructure Costs: [Month]
### By Service
| Service | Cost | vs Budget | Action |
|---------|------|-----------|--------|
| Compute | $X | +Y% | Rightsize |
| Database | $X | -Y% | OK |
| Storage | $X | +Y% | Lifecycle |
| Network | $X | OK | - |
| **Total** | **$X** | | |
### By Environment
- Production: $X (Y%)
- Staging: $X (Y%)
- Dev: $X (Y%)
### Cost per User
- Current: $X/user/month
- Target: $Y/user/month
### Optimization Opportunities
1. [Opportunity]: Save $X/month
2. [Opportunity]: Save $Y/month
Cost Optimization Playbook
COMPUTE:
☐ Rightsize instances (check utilization)
☐ Use Spot/Preemptible for non-critical
☐ Reserved instances for predictable load
☐ Auto-scaling configured correctly
☐ Turn off non-prod nights/weekends
DATABASE:
☐ Right-size instance
☐ Read replicas vs scaling up
☐ Archive old data
☐ Query optimization
☐ Connection pooling
STORAGE:
☐ Lifecycle policies (move to cold)
☐ Delete unused snapshots
☐ Compress where possible
☐ CDN for static assets
NETWORK:
☐ Data transfer between regions
☐ CDN utilization
☐ Unnecessary cross-AZ traffic
Scaling Checklist
ANTES DE SCALING EVENT:
Database:
☐ Query performance optimized
☐ Indexes reviewed
☐ Connection pool sized
☐ Read replicas ready
☐ Failover tested
Application:
☐ Horizontal scaling works
☐ No single points of failure
☐ Caching configured
☐ Rate limiting in place
☐ Circuit breakers working
Infrastructure:
☐ Auto-scaling tested
☐ Load balancer configured
☐ CDN optimized
☐ DNS TTL appropriate
☐ Monitoring alerting
Reliability Metrics
KEY METRICS:
Uptime/Availability:
- Target: 99.9% (8.7 hrs downtime/year)
- Current: X%
Error Rate:
- Target: <0.1%
- Current: X%
Latency (P95):
- Target: <500ms
- Current: Xms
MTTR (Mean Time to Recovery):
- Target: <30 min
- Current: X min
MTBF (Mean Time Between Failures):
- Target: >30 days
- Current: X days
Capacity Planning
## Capacity Plan: [Quarter]
### Current State
- Users: X
- Peak concurrent: Y
- Requests/sec: Z
- Database size: X GB
### Growth Forecast
- Expected users: +X%
- Expected traffic: +Y%
### Bottleneck Analysis
| Resource | Current | At 2x | Action Needed |
|----------|---------|-------|---------------|
| API servers | 70% | 140% | Scale |
| Database | 50% | 100% | Monitor |
| Redis | 30% | 60% | OK |
| Storage | 80% | 160% | Expand |
### Scaling Plan
1. [Action] - Before [date] - Cost: $X
2. [Action] - Before [date] - Cost: $Y
### Budget Impact
- Current monthly: $X
- After scaling: $Y
- Increase: +Z%
Incident Response
SEVERITY LEVELS:
SEV-1 (Critical):
- Full outage / data loss
- All hands on deck
- Target resolution: <1 hour
SEV-2 (Major):
- Partial outage / degraded
- On-call + backup
- Target resolution: <4 hours
SEV-3 (Minor):
- Limited impact
- On-call handles
- Target resolution: <24 hours
INCIDENT PROCESS:
1. DETECT: Alerts or reports
2. TRIAGE: Assess severity
3. RESPOND: Assemble team
4. MITIGATE: Stop bleeding
5. RESOLVE: Fix root cause
6. REVIEW: Post-mortem
Post-Mortem Template
## Incident Post-Mortem: [Title]
**Date:** [date]
**Duration:** [X hours]
**Severity:** SEV-[X]
**Impact:** [who/what affected]
### Timeline
- HH:MM - [Event]
- HH:MM - [Event]
- HH:MM - [Event]
### Root Cause
[Clear explanation of what caused the issue]
### What Went Well
- [Thing 1]
- [Thing 2]
### What Went Poorly
- [Thing 1]
- [Thing 2]
### Action Items
| Action | Owner | Due |
|--------|-------|-----|
| [Action] | @person | [date] |
### Lessons Learned
- [Lesson 1]
- [Lesson 2]
Infrastructure Audit
SECURITY:
☐ Access controls reviewed
☐ Secrets rotated
☐ Patches applied
☐ Firewall rules tight
☐ Encryption at rest/transit
☐ Backup tested
RELIABILITY:
☐ Single points of failure
☐ Failover tested
☐ Disaster recovery plan
☐ Monitoring coverage
☐ Alert fatigue check
PERFORMANCE:
☐ Resource utilization
☐ Query performance
☐ Caching effectiveness
☐ CDN hit rate
☐ Cold start times
COST:
☐ Unused resources
☐ Rightsizing opportunities
☐ Reserved capacity
☐ Data transfer costs
☐ Tool consolidation
Architecture Decision Record
## ADR: [Title]
**Status:** Proposed / Accepted / Deprecated
**Date:** [date]
### Context
[What is the issue/decision needed?]
### Decision
[What we decided to do]
### Alternatives Considered
1. [Option A]: [pros/cons]
2. [Option B]: [pros/cons]
### Consequences
- Pro: [benefit]
- Pro: [benefit]
- Con: [tradeoff]
- Con: [tradeoff]
### Cost Impact
- Initial: $X
- Monthly: $Y
- vs Alternative: +/-$Z
Mejores Prácticas
- Automate everything - Manual processes don't scale
- Monitor before you need it - Observability from day one
- Cost is a feature - Track and optimize constantly
- Test failover - Untested DR is no DR
- Document decisions - Future you will thank you
- Simplify - Complexity is the enemy of reliability
Filosofía
"Good infrastructure is invisible. Users never think about it, and that's the highest compliment."
El objetivo es construir infra que escale con el negocio sin sorpresas costosas ni outages dramáticos.