slo-implementation
por wshobsonUse a skill slo-implementation para definir SLIs, SLOs, budgets de erro e alertas de burn rate em iniciativas de Reliability. Ela ajuda equipes a transformar metas de serviço em objetivos mensuráveis com exemplos no estilo PromQL e orientações práticas do SKILL.md.
Esta skill recebe nota 68/100, o que significa que pode ser listada para usuários do diretório, mas deve ser encarada mais como um framework guiado por documentação do que como uma implementação pronta para uso. O repositório traz conteúdo real suficiente para ajudar um agente a identificar quando utilizá-la e oferece exemplos práticos de SLI/SLO, mas a adoção ainda exige alguma interpretação, já que não há arquivos de suporte, etapas de instalação nem regras operacionais visíveis além do markdown.
- Boa capacidade de acionamento: a descrição e a seção "Quando usar" delimitam com clareza tarefas de metas de confiabilidade, SLI/SLO, budget de erro e alertas.
- Conteúdo de workflow consistente: a skill inclui conceitos concretos de SLI/SLO e exemplos de PromQL para disponibilidade e latência, o que é mais acionável do que um prompt genérico.
- Boa clareza para decisão de instalação: dá para entender que se trata de um framework para definir SLIs, SLOs e budgets de erro, e não de uma skill placeholder ou apenas demonstrativa.
- A execução operacional ainda depende bastante de interpretação, porque o repositório não mostra scripts, referências, recursos nem comando de instalação que transformem o framework em um workflow executável.
- O trecho faz referência a um arquivo externo (`references/slo-definitions.md`), mas os sinais estruturais indicam que não há arquivos de referência, o que reduz a confiança e a sensação de completude.
Visão geral da skill slo-implementation
A skill slo-implementation ajuda a transformar metas vagas de confiabilidade em Service Level Indicators (SLIs), Service Level Objectives (SLOs), error budgets e lógica de alertas concretos. Ela é mais indicada para SREs, times de plataforma, engenheiros backend e product owners com foco em confiabilidade que precisam de uma forma repetível de definir o que significa, na prática, uma saúde de serviço “boa o bastante”.
Para que serve a skill slo-implementation
Use a skill slo-implementation quando você precisar:
- definir metas mensuráveis de confiabilidade para um serviço
- escolher o tipo certo de SLI, como disponibilidade ou latência
- definir uma meta de SLO alinhada ao impacto no negócio
- derivar um error budget a partir dessa meta
- criar alertas com base em burn rate ou consumo de SLO
Ela é mais útil do que um prompt genérico do tipo “escreva um SLO para mim” porque oferece uma hierarquia estruturada de SLI para SLO para SLA e ancora o trabalho em detalhes de implementação, como janelas de medição e consultas no estilo PromQL.
Quem deve instalar
A slo-implementation skill faz mais sentido se você já tem telemetria ou consegue obtê-la em breve. Ela é especialmente útil para times que usam métricas no estilo Prometheus e querem adotar práticas de confiabilidade alinhadas a SRE sem precisar inventar o framework do zero.
Ela é menos útil se:
- você ainda não tem métricas de serviço realmente úteis
- seu principal problema é resposta a incidentes, e não desenho de metas de confiabilidade
- você só precisa de um documento de SLA com foco jurídico ou voltado ao cliente
O que mais importa para quem está avaliando a adoção
A maioria das pessoas que pesquisam por slo-implementation install quer saber:
- se a skill entrega ajuda prática para desenhar SLOs, e não só teoria
- se ela cobre detalhes de implementação, como queries e alertas
- se ela ajuda a evitar SLOs ruins, como metas vaidosas de uptime
- se ela é concisa o bastante para entrar em um fluxo real de trabalho
Nesses pontos, a skill é prática: ela cobre tipos comuns de SLI, exemplos de definição de metas e a relação entre objetivos e error budgets.
Principais pontos fortes e tradeoffs
O principal diferencial de slo-implementation é manter o foco em medição de confiabilidade e desenho de políticas, em vez de escorregar para conselhos genéricos de observabilidade. Esse foco torna a skill mais fácil de acionar com qualidade.
O tradeoff é que a skill só será tão boa quanto o contexto do serviço que você fornecer. Se você não especificar jornadas de usuário, padrões de tráfego, dependências, thresholds e nomes de métricas, a saída pode soar plausível, mas será difícil de operacionalizar.
Como usar a skill slo-implementation
Contexto de instalação da skill slo-implementation
Instale a skill no ambiente em que seu agente consegue acessar skills customizadas. Um padrão comum é:
- adicionar o repositório de origem à sua configuração de skills
- habilitar a skill
slo-implementation - acioná-la quando a tarefa for definir ou revisar SLIs, SLOs, error budgets ou alertas baseados em SLO
Se a sua ferramenta permitir instalação direta de skills, use o carregador de skills habitual para o repositório em:
https://github.com/wshobson/agents/tree/main/plugins/observability-monitoring/skills/slo-implementation
Como as evidências no repositório mostram apenas o arquivo SKILL.md para essa skill, planeje ler esse arquivo primeiro, em vez de esperar scripts auxiliares ou referências extras.
Leia este arquivo primeiro
Comece por:
plugins/observability-monitoring/skills/slo-implementation/SKILL.md
Esse arquivo contém o conteúdo principal do slo-implementation guide: propósito, quando usar, hierarquia SLI/SLO/SLA, tipos comuns de SLI, exemplos de metas e padrões de implementação.
Quais entradas a skill precisa para gerar algo útil
Para obter uma slo-implementation usage de alta qualidade, forneça ao agente:
- o nome do serviço e o que os usuários fazem com ele
- as jornadas mais importantes voltadas ao usuário
- as métricas e labels disponíveis hoje
- dashboards, alertas ou PromQL já existentes, se houver
- volume de tráfego e sazonalidade
- criticidade para o negócio e custo de indisponibilidade
- expectativas de latência por endpoint ou operação
- modos de falha conhecidos
- se você precisa de SLOs internos, alinhamento com SLA externo ou ambos
Sem isso, a skill ainda consegue rascunhar um SLO, mas tende a cair em metas genéricas de disponibilidade e SLIs simplistas baseados apenas em requisições.
Como transformar uma meta vaga em um prompt forte
Prompt fraco:
- “Create SLOs for my API.”
Prompt melhor:
- “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 que isso funciona:
- define o limite do serviço
- aponta para métricas reais
- restringe o escopo a jornadas de usuário relevantes
- pede saídas para as quais a skill foi feita
Melhor fluxo de trabalho para usar a skill slo-implementation pela primeira vez
Um fluxo prático de slo-implementation usage é:
- escolher um serviço, e não a plataforma inteira
- nomear de 1 a 3 jornadas críticas do usuário
- mapear cada jornada para sinais já existentes
- pedir à skill SLIs candidatos
- revisar se esses SLIs refletem a experiência do usuário, e não apenas aspectos internos do sistema
- definir uma meta inicial de SLO e um error budget
- rascunhar a lógica de alertas
- testar se as métricas realmente sustentam o desenho proposto
- revisar thresholds e exclusões antes do rollout
Isso evita um erro comum: tentar definir uma política corporativa de confiabilidade para toda a empresa de uma vez só.
O que a skill tende a entregar bem
A slo-implementation skill é mais forte em:
- propor padrões comuns de SLI, como disponibilidade e latência
- explicar as relações entre SLI, SLO e SLA
- traduzir metas de confiabilidade em razões mensuráveis
- sugerir faixas de metas e enquadramento de error budget
- esboçar alertas baseados em consumo de SLO
Ela ajuda bastante quando você precisa de um primeiro rascunho operacional com rapidez e quer que ele venha ancorado na linguagem padrão de SRE.
Onde os times costumam travar
A adoção geralmente emperra por um destes motivos:
- o time não consegue concordar sobre qual é o limite do serviço voltado ao usuário
- só existem métricas de infraestrutura, e não métricas de jornada de usuário
- faltam histogramas de latência, então SLIs com threshold ficam fracos
- as métricas incluem tráfego de bots, jobs internos ou health checks, o que distorce numerador e denominador
- as metas são escolhidas por política interna, e não com base em risco e custo
A skill pode ajudar a estruturar a conversa, mas não consegue inventar medição confiável quando a telemetria não existe.
Padrões de prompt práticos que melhoram a qualidade da saída
Peça que a skill produza saídas em um formato pronto para decisão, por exemplo:
- “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.”
Esses padrões de prompt geram saídas com nível de implementação, em vez de conselhos abstratos sobre confiabilidade.
Como usar slo-implementation em trabalho de Reliability
Para slo-implementation for Reliability, use a skill nestes momentos:
- antes de lançar um novo serviço
- durante iniciativas de melhoria de observabilidade
- depois que incidentes recorrentes mostrarem que seus alertas atuais geram ruído
- quando a liderança pedir metas de confiabilidade conectadas ao impacto no cliente
- quando você precisar conectar velocidade de engenharia à política de error budget
Ela é mais valiosa quando o time está saindo do “monitorar tudo” para “medir o que realmente importa para os usuários”.
FAQ da skill slo-implementation
A slo-implementation é melhor do que um prompt comum?
Sim, se sua tarefa for especificamente desenhar SLI/SLO. Um prompt comum pode gerar definições aceitáveis, mas slo-implementation tem mais chances de preservar a hierarquia, incluir fórmulas mensuráveis e conectar metas a error budgets e alertas.
A skill slo-implementation é amigável para iniciantes?
Moderadamente. Iniciantes conseguem usá-la, mas os melhores resultados vêm quando você já conhece conceitos básicos de SRE e tem algum contexto de telemetria. Se você está começando em SLOs, use a skill primeiro em um serviço só e revise cada métrica proposta antes de adotá-la.
Ela exige Prometheus?
Não, mas o conteúdo da skill claramente se encaixa bem em uma forma de pensar alinhada a Prometheus e PromQL. Se você usa Datadog, CloudWatch, Grafana ou outra stack, ainda pode aproveitar a lógica e traduzir as expressões de métricas para a sua plataforma.
Quando eu não devo usar slo-implementation?
Não use slo-implementation como ferramenta principal se:
- você precisa de linguagem jurídica de SLA
- você não tem nenhuma telemetria de serviço aproveitável
- seu problema real é ownership, e não medição
- seu serviço ainda é imaturo demais para definir jornadas de usuário estáveis
Nesses casos, instrumente primeiro ou resolva o problema de modelo operacional antes de formalizar SLOs.
Ela também ajuda com alertas?
Sim. A skill não trata apenas da definição de metas; ela também cobre o lado operacional de error budgets e alertas baseados em SLO. Isso a torna mais útil do que um template que para em metas percentuais.
Como melhorar a skill slo-implementation
Forneça contexto de negócio, não só métricas técnicas
Para melhorar os resultados de slo-implementation, diga ao agente o que confiabilidade significa comercialmente:
- Qual fluxo perde receita quando se degrada?
- Quais usuários são premium ou sensíveis à latência?
- Qual duração de impacto é tolerável?
Isso ajuda a skill a escolher metas realistas, em vez de cair em números aspiracionais como 99.99%.
Defina explicitamente os limites do serviço
Uma entrada mais forte para o slo-implementation guide deixa claro o que conta e o que não conta. Por exemplo:
- incluir requests de escrita da API pública
- excluir
/healthz, rotas administrativas e jobs internos em batch - medir apenas a conclusão bem-sucedida e visível para o usuário, não só a aceitação da requisição
Clareza de escopo é um dos fatores que mais determinam se um SLO será confiável para o time.
Forneça nomes de métricas e queries de exemplo
A skill se torna muito mais acionável quando você compartilha telemetria real. Uma boa entrada inclui:
- nomes de métricas
- dimensões de labels
- buckets de histograma
- queries de alerta atuais
- links de dashboards ou trechos copiados
Isso permite que a saída evolua de SLOs conceituais para definições quase prontas para implementar.
Evite SLIs de vaidade
Um erro comum é escolher métricas fáceis de coletar, mas com ligação fraca com a experiência real do usuário. Exemplos:
- reinícios de pod
- saturação de CPU isoladamente
- uptime bruto de uma dependência sem mapeamento para impacto no serviço
Peça que a skill justifique por que cada SLI reflete a confiabilidade percebida pelo usuário. Se ela não conseguir, substitua esse SLI.
Itere depois do primeiro rascunho
Sua primeira saída de slo-implementation deve ser tratada como rascunho. Melhore-a perguntando:
- “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?”
Essa segunda passada normalmente produz um desenho operacional muito melhor do que aceitar o primeiro conjunto de metas.
Faça um teste de estresse com incidentes históricos
Uma das melhores formas de melhorar a saída da slo-implementation skill é comparar os SLIs e alertas propostos com incidentes reais. Pergunte:
- esse SLO teria detectado o problema?
- ele teria contado falhas inofensivas em excesso?
- a política de burn rate teria paginado cedo demais ou tarde demais?
Essa etapa de validação transforma um documento bem montado em algo que os times realmente conseguem operar.
Use um serviço por vez
Se os resultados parecerem genéricos, o escopo provavelmente está amplo demais. A skill funciona melhor quando fica focada em um único serviço ou em uma única jornada de usuário. Divida sistemas grandes em passadas separadas e só depois padronize os padrões.