slo-implementation
por wshobsonUsa la skill slo-implementation para definir SLI, SLO, presupuestos de error y alertas de burn rate en trabajo de Reliability. Ayuda a los equipos a convertir los objetivos del servicio en metas medibles con ejemplos de estilo PromQL y orientación práctica de SKILL.md.
Esta skill obtiene una puntuación de 68/100, lo que significa que puede incluirse en el directorio, pero conviene abordarla como un marco guiado por documentación y no como una implementación lista para usar. El repositorio ofrece suficiente contenido real para ayudar a un agente a reconocer cuándo utilizarla y aporta ejemplos prácticos de SLI/SLO, pero su adopción sigue requiriendo cierta interpretación porque no hay archivos de soporte, pasos de instalación ni reglas operativas visibles más allá del markdown.
- Buena capacidad de activación: la descripción y la sección "When to Use" delimitan con claridad las tareas de objetivos de fiabilidad, SLI/SLO, presupuestos de error y alertas.
- Contenido de flujo de trabajo con sustancia: la skill incluye conceptos concretos de SLI/SLO y ejemplos de PromQL para disponibilidad y latencia, lo que resulta más accionable que un prompt genérico.
- La decisión de instalación es bastante clara: los usuarios pueden ver que se trata de un marco para definir SLI, SLO y presupuestos de error, no de una skill de relleno ni de una simple demo.
- La ejecución operativa exige bastante inferencia porque el repositorio no muestra scripts, referencias, recursos ni ningún comando de instalación que convierta el marco en un flujo de trabajo ejecutable.
- El extracto hace referencia a un archivo externo (`references/slo-definitions.md`), pero las señales estructurales indican que no hay archivos de referencia, lo que reduce la confianza y la sensación de completitud.
Visión general de la skill slo-implementation
La skill slo-implementation te ayuda a convertir objetivos de fiabilidad vagos en Service Level Indicators (SLIs), Service Level Objectives (SLOs), presupuestos de error y lógica de alertas concretos. Encaja especialmente bien para SREs, equipos de plataforma, ingenieros backend y responsables de producto con foco en fiabilidad que necesitan una forma repetible de definir qué significa realmente una salud del servicio “suficientemente buena”.
Para qué sirve la skill slo-implementation
Usa la skill slo-implementation cuando necesites:
- definir objetivos de fiabilidad medibles para un servicio
- elegir el tipo de SLI adecuado, como disponibilidad o latencia
- fijar un objetivo de SLO alineado con el impacto de negocio
- derivar un presupuesto de error a partir de ese objetivo
- crear alertas basadas en burn rate o consumo del SLO
Es más útil que un prompt genérico tipo “escríbeme un SLO” porque ofrece una jerarquía estructurada de SLI a SLO y luego a SLA, y aterriza el trabajo en detalles de implementación como ventanas de medición y consultas de estilo PromQL.
Quién debería instalarla
La slo-implementation skill encaja muy bien si ya tienes telemetría o puedes disponer de ella pronto. Es especialmente útil para equipos que usan métricas de estilo Prometheus y quieren adoptar prácticas de fiabilidad alineadas con SRE sin tener que inventar el marco desde cero.
Es menos útil si:
- todavía no tienes métricas de servicio realmente significativas
- tu problema principal es la respuesta a incidentes y no el diseño de objetivos de fiabilidad
- solo necesitas un documento de SLA legal o de cara al cliente
Lo que más suele importar antes de adoptarla
La mayoría de quienes evalúan slo-implementation install quieren saber:
- si ofrece ayuda accionable para diseñar SLOs, y no solo teoría
- si cubre detalles de implementación como consultas y alertas
- si puede ayudar a evitar SLOs malos, como objetivos de uptime meramente decorativos
- si es lo bastante concisa como para usarla dentro de un flujo de trabajo real
En esos puntos, la skill resulta práctica: cubre tipos de SLI habituales, ejemplos de definición de objetivos y la relación entre objetivos y presupuestos de error.
Puntos fuertes y tradeoffs clave
El principal diferenciador de slo-implementation es que se mantiene centrada en la medición de fiabilidad y el diseño de políticas, en lugar de desviarse hacia consejos genéricos de observabilidad. Ese foco hace que sea más fácil invocarla bien.
La contrapartida es que la skill solo será tan buena como el contexto del servicio que le des. Si no especificas recorridos de usuario, patrones de tráfico, dependencias, umbrales y nombres de métricas, la salida sonará plausible, pero será difícil llevarla a operación.
Cómo usar la skill slo-implementation
Contexto de instalación para la skill slo-implementation
Instala la skill en el entorno donde tu agente pueda acceder a skills personalizadas. Un patrón habitual es:
- añadir el repositorio de origen a tu configuración de skills
- habilitar la skill
slo-implementation - invocarla cuando la tarea sea definir o revisar SLIs, SLOs, presupuestos de error o alertas basadas en SLO
Si tu herramienta admite instalación directa de skills, usa tu cargador habitual para el repositorio en:
https://github.com/wshobson/agents/tree/main/plugins/observability-monitoring/skills/slo-implementation
Como la evidencia del repositorio muestra solo SKILL.md para esta skill, conviene leer primero ese archivo en lugar de esperar scripts auxiliares o referencias adicionales.
Lee primero este archivo
Empieza por:
plugins/observability-monitoring/skills/slo-implementation/SKILL.md
Ese archivo contiene la sustancia real de la slo-implementation guide: propósito, cuándo usarla, jerarquía SLI/SLO/SLA, tipos comunes de SLI, ejemplos de objetivos y patrones de implementación.
Qué entrada necesita la skill para producir resultados útiles
Para obtener una slo-implementation usage de alta calidad, dale al agente:
- el nombre del servicio y qué hacen los usuarios con él
- los recorridos de usuario más importantes
- las métricas y labels disponibles actualmente
- dashboards, alertas o PromQL existentes, si los hay
- volumen de tráfico y estacionalidad
- criticidad de negocio y coste de una caída
- expectativas de latencia por endpoint u operación
- modos de fallo conocidos
- si necesitas SLOs internos, alineación con un SLA externo o ambas cosas
Sin esto, la skill aún puede redactar un SLO, pero tenderá a caer en objetivos de disponibilidad genéricos y SLIs simplistas basados en requests.
Convierte un objetivo difuso en un prompt sólido
Prompt débil:
- “Create SLOs for my API.”
Mejor prompt:
- “Use the
slo-implementationskill to define SLIs and SLOs for a multi-tenant payments API. Our critical user journeys are charge creation and webhook delivery. We use Prometheus. Available metrics includehttp_requests_total,http_request_duration_seconds_bucket, and queue retry counters. Propose 2 to 3 SLIs, recommend SLO targets, calculate monthly error budgets, and suggest burn-rate alerts. Exclude admin endpoints and health checks.”
Por qué funciona:
- define el perímetro del servicio
- apunta a métricas reales
- limita el alcance a recorridos de usuario relevantes
- pide salidas para las que la skill está pensada
Mejor flujo de trabajo para un primer uso
Un flujo práctico de slo-implementation usage es:
- identificar un solo servicio, no toda la plataforma
- nombrar de 1 a 3 recorridos de usuario críticos
- mapear cada recorrido a las señales existentes
- pedir a la skill SLIs candidatos
- revisar si esos SLIs reflejan la experiencia del usuario y no solo aspectos internos del sistema
- fijar un objetivo inicial de SLO y presupuesto de error
- redactar la lógica de alertas
- comprobar si las métricas realmente soportan el diseño
- ajustar umbrales y exclusiones antes del despliegue
Esto evita el fallo común de intentar definir de una sola pasada una política de fiabilidad para toda la empresa.
Qué suele resolver bien la skill
La slo-implementation skill destaca especialmente en:
- proponer patrones comunes de SLI como disponibilidad y latencia
- explicar las relaciones entre SLI, SLO y SLA
- traducir objetivos de fiabilidad en ratios medibles
- sugerir rangos de objetivos y el enfoque de presupuesto de error
- esbozar alertas basadas en consumo del SLO
Resulta especialmente útil cuando necesitas un primer borrador operativo con rapidez y quieres que esté anclado en el lenguaje estándar de SRE.
Dónde suelen atascarse los equipos
La adopción suele frenarse por una de estas razones:
- el equipo no logra acordar cuál es el perímetro del servicio de cara al usuario
- solo existen métricas de infraestructura, no métricas de recorridos de usuario
- faltan histogramas de latencia, por lo que los SLIs basados en umbral quedan débiles
- las métricas incluyen tráfico de bots, jobs internos o health checks que distorsionan numerador y denominador
- los objetivos se eligen por razones políticas y no a partir de riesgo y coste
La skill puede ayudar a estructurar la conversación, pero no puede inventar una medición fiable cuando no existe telemetría.
Patrones de prompt prácticos que mejoran la calidad del resultado
Pide a la skill salidas en un formato listo para decidir, por ejemplo:
- “List candidate SLIs with rationale and tradeoffs.”
- “Recommend one primary SLO and one secondary guardrail SLO.”
- “Show PromQL-style formulas for each SLI.”
- “Identify exclusions that should not count against the SLO.”
- “Suggest alerting windows for fast and slow burn.”
Estos patrones de prompt generan resultados con nivel de implementación, en lugar de consejos abstractos sobre fiabilidad.
Cómo usar slo-implementation para trabajo de Reliability
Para slo-implementation for Reliability, úsala en estos momentos:
- antes de lanzar un servicio nuevo
- durante iniciativas de mejora de observabilidad
- después de incidentes recurrentes que muestran que las alertas actuales generan ruido
- cuando dirección pide objetivos de fiabilidad vinculados al impacto en clientes
- cuando necesitas conectar la velocidad de ingeniería con una política de presupuesto de error
Aporta más valor cuando el equipo está pasando de “monitorizarlo todo” a “medir lo que de verdad importa a los usuarios”.
Preguntas frecuentes sobre la skill slo-implementation
¿Es slo-implementation mejor que un prompt normal?
Sí, si tu tarea es específicamente diseñar SLIs y SLOs. Un prompt normal puede generar definiciones aceptables, pero slo-implementation tiene más probabilidades de respetar la jerarquía, incluir fórmulas medibles y conectar los objetivos con presupuestos de error y alertas.
¿La skill slo-implementation es apta para principiantes?
Moderadamente. Las personas que empiezan pueden usarla, pero los mejores resultados llegan cuando ya se conocen conceptos básicos de SRE y se dispone de algo de contexto de telemetría. Si eres nuevo en SLOs, usa la skill primero con un único servicio y revisa cada métrica propuesta antes de adoptarla.
¿Requiere Prometheus?
No, pero el contenido de la skill encaja claramente bien con una forma de pensar de estilo Prometheus y PromQL. Si usas Datadog, CloudWatch, Grafana u otro stack, puedes seguir aprovechando la lógica y traducir las expresiones de métricas a tu plataforma.
¿Cuándo no debería usar slo-implementation?
No uses slo-implementation como herramienta principal si:
- necesitas lenguaje legal de SLA
- no dispones de ninguna telemetría de servicio utilizable
- tu problema real es de ownership, no de medición
- tu servicio aún es demasiado inmaduro como para definir recorridos de usuario estables
En esos casos, primero instrumenta o resuelve el problema del modelo operativo antes de formalizar SLOs.
¿También puede ayudar con alertas?
Sí. La skill no se limita a definir objetivos; también cubre la parte operativa de los presupuestos de error y las alertas basadas en SLO. Eso la hace más útil que una plantilla que se queda en porcentajes objetivo.
Cómo mejorar la skill slo-implementation
Da contexto de negocio, no solo métricas técnicas
Para mejorar los resultados de slo-implementation, explica al agente qué significa la fiabilidad en términos de negocio:
- ¿Qué flujo pierde ingresos cuando se degrada?
- ¿Qué usuarios son premium o especialmente sensibles a la latencia?
- ¿Qué duración de impacto es tolerable?
Esto ayuda a la skill a elegir objetivos realistas en lugar de caer por defecto en cifras aspiracionales como 99.99%.
Define explícitamente los límites del servicio
Una entrada más sólida para la slo-implementation guide deja claro qué cuenta y qué no. Por ejemplo:
- incluir requests de escritura de la API pública
- excluir
/healthz, rutas de administración y jobs batch internos - medir solo la finalización exitosa visible para el usuario, no simplemente la aceptación de la request
La claridad de perímetro es uno de los factores que más determina si un SLO va a ser fiable y aceptado.
Proporciona nombres de métricas y consultas de ejemplo
La skill se vuelve mucho más accionable cuando compartes telemetría real. Una buena entrada incluye:
- nombres de métricas
- dimensiones de labels
- buckets de histogramas
- consultas de alertas actuales
- enlaces a dashboards o fragmentos copiados
Eso permite que la salida pase de SLOs conceptuales a definiciones casi listas para implementar.
Evita los SLI de vanidad
Un modo de fallo frecuente es elegir métricas fáciles de recopilar pero poco conectadas con la experiencia real del usuario. Ejemplos:
- reinicios de pods
- saturación de CPU por sí sola
- uptime bruto de una dependencia sin mapear su impacto real sobre el servicio
Pide a la skill que justifique por qué cada SLI refleja la fiabilidad percibida por el usuario. Si no puede hacerlo, sustituye ese SLI.
Itera después del primer borrador
La primera salida de slo-implementation debe tratarse como un borrador. Mejórala preguntando:
- “Which SLI is most representative of user harm?”
- “What would make this SLO impossible to measure accurately?”
- “Which exclusions are risky or easy to abuse?”
- “How would this change for low-traffic services?”
- “What alerting would reduce noise while protecting the error budget?”
Esta segunda pasada suele producir un diseño operativo mucho mejor que aceptar sin más el primer conjunto de objetivos.
Ponla a prueba con incidentes históricos
Una de las mejores formas de mejorar la salida de la slo-implementation skill es comparar los SLIs y alertas propuestos con incidentes reales. Pregunta:
- ¿este SLO habría detectado el problema?
- ¿habría contado en exceso fallos inocuos?
- ¿la política de burn rate habría paginado demasiado pronto o demasiado tarde?
Ese paso de validación convierte un documento bien presentado en algo que el equipo puede operar de verdad.
Usa un servicio cada vez
Si los resultados te parecen genéricos, probablemente el alcance es demasiado amplio. La skill funciona mejor cuando se centra en un solo servicio o en un único recorrido de usuario. Divide los sistemas grandes en pasadas separadas y estandariza patrones después.