Skill: infra-sre
Si no está monitoreado, no existe.
Trigger
- Un servicio está caído y no te diste cuenta
- Querés dashboards para ver el estado del sistema
- Necesitás alertas que avisen antes de que explote
- Hay que definir SLOs y error budgets
- Estás haciendo postmortem de un incidente
Workflow LEND
1. ANALIZAR
├── ¿Qué servicios corren? (API, worker, DB, frontend)
├── Stack actual (Prometheus? Datadog? CloudWatch? Nada?)
├── ¿Qué métricas importan? (latencia, errores, throughput, saturación)
└── ¿Hay logs centralizados?
2. OFRECER (Menú del Senior)
├── A) Mínimo: healthcheck endpoint + uptime monitoring (UptimeRobot/Heartbeat)
├── B) Standard: Prometheus + Grafana dashboards + alertas críticas
└── C) Full SRE: todo + SLIs/SLOs + error budgets + runbooks + logging (Loki/ELK)
3. ELEGIR → el usuario confirma
4. HACER
├── Endpoint /health y /metrics en la app
├── Exporters (node_exporter, postgres_exporter, blackbox_exporter)
├── Prometheus config + reglas de alerta
├── Grafana dashboards (USE method for infra, RED method for services)
├── Alertmanager (Slack, email, PagerDuty)
└── Runbooks para incidentes comunes
5. VERIFICAR
├── Las métricas llegan a Prometheus
├── Las alertas se disparan correctamente (probar con condiciones reales)
└── El dashboard muestra datos con sentido
Patrones
- USE method: Utilization, Saturation, Errors (para infra)
- RED method: Rate, Errors, Duration (para servicios)
- Four golden signals: latency, traffic, errors, saturation
- SLIs: medir lo que importa al usuario (latencia P99, error rate)
- SLOs: objetivos realistas (99.9% okay, 99.99% requiere esfuerzo)
- Error budget: 100% - SLO. Cuando se acaba, parar features, arreglar estabilidad
- Postmortems sin blame: el sistema falló, no la persona
Anti-patrones
- Alertas que nadie mira (alerta que no duele = ruido)
- Dashboards sin contexto (métrica sin unidad = números flotando)
- SLOs aspiracionales sin data histórica
- No tener runbooks — en medio de un incidente no se piensa
- Monitorear todo menos lo que ve el usuario
1---2name: infra-sre3description: >4 Monitoreo, alertas y confiabilidad de sistemas — Prometheus, Grafana,5 logging, SLIs/SLOs, incident response y observabilidad.6 Trigger: Cuando necesitás monitorear un servicio, configurar alertas, definir SLOs o responder a un incidente.7license: MIT8metadata:9 author: Leandro Benjamin L.10 version: "1.0"11---1213# Skill: infra-sre1415Si no está monitoreado, no existe.1617## Trigger1819- Un servicio está caído y no te diste cuenta20- Querés dashboards para ver el estado del sistema21- Necesitás alertas que avisen antes de que explote22- Hay que definir SLOs y error budgets23- Estás haciendo postmortem de un incidente2425## Workflow LEND2627```281. ANALIZAR29 ├── ¿Qué servicios corren? (API, worker, DB, frontend)30 ├── Stack actual (Prometheus? Datadog? CloudWatch? Nada?)31 ├── ¿Qué métricas importan? (latencia, errores, throughput, saturación)32 └── ¿Hay logs centralizados?33342. OFRECER (Menú del Senior)35 ├── A) Mínimo: healthcheck endpoint + uptime monitoring (UptimeRobot/Heartbeat)36 ├── B) Standard: Prometheus + Grafana dashboards + alertas críticas37 └── C) Full SRE: todo + SLIs/SLOs + error budgets + runbooks + logging (Loki/ELK)38393. ELEGIR → el usuario confirma40414. HACER42 ├── Endpoint /health y /metrics en la app43 ├── Exporters (node_exporter, postgres_exporter, blackbox_exporter)44 ├── Prometheus config + reglas de alerta45 ├── Grafana dashboards (USE method for infra, RED method for services)46 ├── Alertmanager (Slack, email, PagerDuty)47 └── Runbooks para incidentes comunes48495. VERIFICAR50 ├── Las métricas llegan a Prometheus51 ├── Las alertas se disparan correctamente (probar con condiciones reales)52 └── El dashboard muestra datos con sentido53```5455## Patrones5657- **USE method**: Utilization, Saturation, Errors (para infra)58- **RED method**: Rate, Errors, Duration (para servicios)59- **Four golden signals**: latency, traffic, errors, saturation60- **SLIs**: medir lo que importa al usuario (latencia P99, error rate)61- **SLOs**: objetivos realistas (99.9% okay, 99.99% requiere esfuerzo)62- **Error budget**: 100% - SLO. Cuando se acaba, parar features, arreglar estabilidad63- **Postmortems sin blame**: el sistema falló, no la persona6465## Anti-patrones6667- Alertas que nadie mira (alerta que no duele = ruido)68- Dashboards sin contexto (métrica sin unidad = números flotando)69- SLOs aspiracionales sin data histórica70- No tener runbooks — en medio de un incidente no se piensa71- Monitorear todo menos lo que ve el usuario