Probar gratis
6 min lectura Guide 763 of 877

Proyectos de Monitoreo y Observabilidad

Buen monitoreo previene problemas y acelera el debugging. GitScrum ayuda a los equipos a planificar trabajo de observabilidad y trackear mejoras de monitoreo junto con desarrollo de features.

Fundamentos de Observabilidad

LOS TRES PILARES
════════════════

MÉTRICAS:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  Mediciones numéricas a lo largo del tiempo                │
│                                                             │
│  Ejemplos:                                                  │
│  ├── Request rate: 1,500 req/s                             │
│  ├── Error rate: 0.1%                                      │
│  ├── Latency p99: 250ms                                    │
│  └── CPU usage: 45%                                        │
│                                                             │
│  Herramientas: Prometheus, CloudWatch, Datadog             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

LOGS:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  Registros de eventos discretos                            │
│                                                             │
│  Ejemplo:                                                   │
│  {                                                          │
│    "timestamp": "2024-01-15T10:30:00Z",                    │
│    "level": "ERROR",                                        │
│    "service": "payment-service",                           │
│    "message": "Payment failed",                            │
│    "user_id": "123",                                       │
│    "error_code": "INSUFFICIENT_FUNDS"                      │
│  }                                                          │
│                                                             │
│  Herramientas: ELK, Loki, CloudWatch Logs                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

TRACES:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  Seguimiento de requests a través de servicios             │
│                                                             │
│  Request: GET /checkout                                     │
│  ├── API Gateway (5ms)                                     │
│  │   └── Auth Service (10ms)                               │
│  ├── Order Service (50ms)                                  │
│  │   ├── Inventory Service (15ms)                          │
│  │   └── Pricing Service (20ms)                            │
│  └── Payment Service (100ms)  ← Cuello de botella          │
│                                                             │
│  Herramientas: Jaeger, Zipkin, AWS X-Ray                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Observabilidad como Feature

INCLUYENDO EN DEFINITION OF DONE
════════════════════════════════

CRITERIOS DE ACEPTACIÓN TÍPICOS:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  Feature: Nuevo endpoint de checkout                       │
│                                                             │
│  FUNCIONAL:                                                 │
│  ├── ☐ Usuario puede completar compra                      │
│  ├── ☐ Maneja errores de pago gracefully                   │
│  └── ☐ Envía confirmación por email                        │
│                                                             │
│  OBSERVABILIDAD (agregar estos):                           │
│  ├── ☐ Métricas: checkout_requests_total, latency          │
│  ├── ☐ Logs: Structured logs con correlation ID            │
│  ├── ☐ Alertas: Error rate > 1%, Latency p99 > 2s          │
│  └── ☐ Dashboard: Panel de checkout en Grafana             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

TEMPLATE DE STORY CON OBSERVABILIDAD:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  Story: Implementar [feature]                              │
│                                                             │
│  Subtareas:                                                 │
│  ├── Implementar funcionalidad                             │
│  ├── Agregar unit tests                                    │
│  ├── Agregar métricas de negocio                           │
│  ├── Configurar alertas                                    │
│  └── Actualizar dashboard                                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Planificación de Observabilidad

TRABAJO DE OBSERVABILIDAD EN SPRINTS
════════════════════════════════════

TIPOS DE TRABAJO:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  PROACTIVO (planificar en sprints):                        │
│  ├── Nuevos dashboards para features                       │
│  ├── Mejora de coverage de métricas                        │
│  ├── Estandarización de logs                               │
│  ├── Implementar tracing                                   │
│  └── Documentación de runbooks                             │
│                                                             │
│  REACTIVO (surge de incidentes):                           │
│  ├── Alertas que faltaban                                  │
│  ├── Logs insuficientes                                    │
│  └── Mejoras post-mortem                                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

BALANCE SUGERIDO:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  Sprint típico:                                             │
│  ├── 70-80% Features                                       │
│  ├── 10-15% Tech debt (incluye observabilidad)             │
│  └── 10-15% Bugs/mantenimiento                             │
│                                                             │
│  Si tuviste incidentes recientemente:                      │
│  ├── Aumentar trabajo de observabilidad                    │
│  └── Priorizar gaps identificados en post-mortems          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Alertas

ESTRATEGIA DE ALERTAS
═════════════════════

NIVELES DE SEVERIDAD:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  🔴 CRITICAL (despertar a alguien):                        │
│  ├── Servicio caído                                        │
│  ├── Error rate > 5%                                       │
│  └── Usuarios no pueden completar acción crítica           │
│                                                             │
│  🟠 HIGH (atención durante horas de trabajo):              │
│  ├── Error rate > 1%                                       │
│  ├── Latency p99 degradada significativamente              │
│  └── Queue creciendo más rápido de lo que se procesa       │
│                                                             │
│  🟡 MEDIUM (revisar en próximo día hábil):                 │
│  ├── Warnings aumentando                                   │
│  ├── Disk usage > 80%                                      │
│  └── Dependency intermittent                               │
│                                                             │
│  🔵 LOW (info para awareness):                             │
│  ├── Nuevo deployment                                      │
│  └── Métricas inusuales pero no críticas                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

EVITANDO ALERT FATIGUE:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  ✅ Cada alerta debe ser actionable                        │
│  ✅ Incluir runbook en la alerta                           │
│  ✅ Revisar alertas regularmente                           │
│                                                             │
│  ❌ Alertar por cosas que no requieren acción              │
│  ❌ Umbrales demasiado sensibles                           │
│  ❌ Demasiadas alertas = ignorarlas todas                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Tracking en GitScrum

TAREAS DE OBSERVABILIDAD EN GITSCRUM
════════════════════════════════════

LABELS:
┌─────────────────────────────────────────────────────────────┐
│  📊 metrics         │ Relacionado a métricas               │
│  📝 logging         │ Mejoras de logs                      │
│  🔔 alerting        │ Configuración de alertas             │
│  📈 dashboard       │ Dashboards y visualización           │
│  🔍 tracing         │ Distributed tracing                  │
│  📚 runbook         │ Documentación operacional            │
└─────────────────────────────────────────────────────────────┘

EJEMPLO DE EPIC:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  Epic: Observabilidad del módulo de pagos                  │
│                                                             │
│  Stories:                                                   │
│  ├── [📊] Agregar métricas de transacciones               │
│  ├── [📝] Estandarizar logs de pagos                      │
│  ├── [🔔] Configurar alertas de error rate                │
│  ├── [📈] Dashboard de métricas de negocio                │
│  └── [📚] Runbook de incidentes de pagos                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

POST-INCIDENT TASKS:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  Incidente: INC-123 - Pagos fallando                       │
│                                                             │
│  Tareas de mejora identificadas:                           │
│  ├── [🔔] Alerta para timeout de payment provider         │
│  ├── [📝] Mejorar logs de errores de pago                 │
│  └── [📈] Agregar métricas de latency por provider        │
│                                                             │
│  Prioridad: Alta (prevenir recurrencia)                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Soluciones Relacionadas de GitScrum