Site Reliability Engineering — Intermedio

Dirigido a ingenieros y profesionales técnicos que ya dominan los fundamentos de SRE y buscan operar con mayor autonomía sobre la fiabilidad de sistemas en producción, este curso profundiza en el diseño riguroso de SLIs y SLOs, la construcción de un stack de observabilidad completo y la definición de políticas de alertas orientadas a síntomas de usuario. A lo largo de ocho horas de trabajo práctico, el participante aprenderá a depurar configuraciones de monitorización defectuosas, a comparar y seleccionar estrategias de gestión de incidentes adaptadas al contexto de su equipo, a redactar postmortems sin culpa con acciones de mejora verificables, a integrar el seguimiento del error budget en pipelines de entrega continua y a documentar runbooks operacionales completos para escenarios de degradación. Al finalizar, el participante será capaz de establecer y mantener un ciclo coherente de fiabilidad —desde la definición de objetivos hasta la respuesta a incidentes y la mejora continua— sobre un servicio real o de laboratorio.

1. Conceptual — Explicar qué hace coherente la elección de un SLI respecto de la experiencia real del usuario y por qué ciertas métricas internas resultan inadecuadas como base de SLOs.
2. Conceptual — Distinguir las dimensiones de un stack de observabilidad (métricas, logs y trazas) y el rol que cada una desempeña en la detección y diagnóstico de problemas en sistemas multicapa.
3. Conceptual — Comparar al menos dos modelos de gestión de incidentes —como la guardia rotativa y el equipo dedicado— identificando los factores organizativos que determinan la idoneidad de cada uno.
4. Procedimental — Diseñar SLIs y SLOs para un servicio web dado, justificando la métrica elegida frente a las alternativas descartadas.
5. Procedimental — Integrar un stack de observabilidad en un servicio de ejemplo, conectando métricas, logs y trazas mediante herramientas estándar del ecosistema cloud.
6. Procedimental — Diseñar una política de alertas orientada a síntomas de usuario y depurar una configuración existente con alertas ruidosas o ausentes, corrigiendo su causa en un entorno de laboratorio.
7. Integrador — Adaptar una plantilla de postmortem sin culpa a un incidente simulado, produciendo un análisis con causa raíz y acciones de mejora verificables, e integrar un mecanismo de error budget tracking en un pipeline CI/CD que condicione decisiones de despliegue.
8. Integrador — Diseñar un runbook operacional para un escenario de degradación de servicio que vincule los SLOs definidos, las alertas configuradas y los pasos de diagnóstico, escalado y mitigación en un único flujo operativo coherente.

Bloque 1 — SLIs, SLOs y error budgets en profundidad. El curso arranca con el diseño metódico de indicadores y objetivos de nivel de servicio: se analiza qué convierte a una métrica en un SLI genuinamente centrado en el usuario, se trabaja la justificación de la elección frente a alternativas descartadas y se formaliza la definición de la ventana de medición y el umbral de SLO. A partir del SLO se deriva el error budget y se examina cómo integrarlo como señal de control en un pipeline CI/CD, de modo que el estado del presupuesto de error influya directamente en la decisión de promover o bloquear un despliegue.

Bloque 2 — Observabilidad: métricas, logs y trazas. El segundo bloque aborda la construcción práctica de un stack de observabilidad completo sobre un servicio de ejemplo. Se revisan los tres pilares —métricas de series temporales, logs estructurados y trazas distribuidas— y su complementariedad para detectar y diagnosticar incidentes en sistemas multicapa. Los participantes integran herramientas estándar del ecosistema cloud para instrumentar el servicio y validan que el stack proporciona visibilidad suficiente para evaluar el cumplimiento de los SLOs definidos en el bloque anterior.

Bloque 3 — Alertas orientadas a síntomas y depuración de monitorización. Partiendo del stack construido, se diseña una política de alertas que prioriza los síntomas percibidos por el usuario sobre las causas internas. Se estudian los anti-patrones más frecuentes —alert fatigue, falsos negativos por umbrales estáticos, ausencia de cobertura en rutas críticas— y a continuación se realiza un ejercicio de depuración sobre una configuración intencionalmente defectuosa: los participantes identifican y corrigen las causas de alertas ruidosas o ausentes en un entorno de laboratorio controlado.

Bloque 4 — Gestión de incidentes y postmortems sin culpa. Este bloque cubre el ciclo completo de respuesta a incidentes. Se comparan modelos organizativos de guardia —rotación de equipos de desarrollo, equipo SRE dedicado y modelos híbridos— evaluando su idoneidad según el tamaño del equipo, la criticidad del servicio y la madurez de la organización. Tras la resolución del incidente, se trabaja la redacción de postmortems sin culpa: los participantes adaptan una plantilla estándar a un incidente simulado, identifican la causa raíz mediante técnicas de análisis causal y formulan acciones de mejora medibles y asignables.

Bloque 5 — Runbooks operacionales. El curso cierra con la elaboración de documentación operacional accionable. Se analiza la anatomía de un runbook eficaz —condiciones de activación, árbol de diagnóstico, criterios de escalado y procedimientos de mitigación— y se diseña un runbook completo para un escenario de degradación de servicio que integre los SLOs, las alertas y las lecciones extraídas de los postmortems trabajados en bloques anteriores, produciendo un artefacto verificable y reutilizable por el equipo.

• Acceso a un entorno cloud (AWS, GCP o Azure) o a un clúster Kubernetes local (minikube / kind) con permisos suficientes para desplegar servicios y configurar recursos de monitorización.
• Herramientas instaladas localmente o accesibles vía navegador: Prometheus y Grafana para métricas, Loki o equivalente para logs, y Tempo o Jaeger para trazas distribuidas.
• Cliente kubectl y CLI del proveedor cloud correspondiente, ambos autenticados contra el entorno de laboratorio.
• Acceso de escritura a un repositorio Git y a un pipeline CI/CD de ejemplo (GitHub Actions, GitLab CI o equivalente) para el ejercicio de error budget tracking.
• Navegador web actualizado y conexión a internet estable para acceder a documentación de referencia y entornos de laboratorio remotos si se utilizan.

Para aprovechar este curso el participante debe haber completado SRE01 o disponer de conocimiento equivalente, lo que implica: familiaridad con los conceptos de SLI, SLO y SLA; comprensión básica del error budget como mecanismo de decisión; experiencia operando servicios en entornos cloud; y manejo elemental de herramientas de monitorización y línea de comandos. Sin esa base conceptual, los ejercicios prácticos de los bloques 1 a 5 resultarán de difícil seguimiento.