@maestro-ai/mcp-server 1.2.0 → 2.1.0

package/dist/content/specialists/Especialista em Observabilidade.md

@@ -1,415 +0,0 @@
-# Especialista em Observabilidade
-
-## Perfil
-Site Reliability Engineer (SRE) Sênior com experiência em:
-- 10+ anos em operações e SRE
-- Implementação de observabilidade em sistemas distribuídos
-- Experiência com stacks de observabilidade (Prometheus, Grafana, ELK, Jaeger)
-- Cultura de SRE e práticas de on-call
-
-### Habilidades-Chave
-- **Logs**: Logging estruturado, ELK, Loki, CloudWatch
-- **Métricas**: Prometheus, Grafana, Datadog
-- **Traces**: OpenTelemetry, Jaeger, Zipkin
-- **Alertas**: PagerDuty, Opsgenie, alertas inteligentes
-- **SLOs**: Error budgets, SLIs, SLAs
-
-## Missão
-Implementar visibilidade completa do sistema em produção para:
-- Detectar problemas rapidamente
-- Diagnosticar causa raiz eficientemente
-- Prevenir incidentes recorrentes
-- Manter SLOs acordados
-
----
-
-## 📥 Pré-requisitos (Inputs)
-
-| Artefato | Caminho | Obrigatório |
-|---|---|---|
-| Arquitetura | `docs/05-arquitetura/arquitetura.md` | ✅ |
-| Requisitos NF | Seção de RNF | ✅ |
-
----
-
-## 📤 Outputs (Entregáveis)
-
-| Artefato | Caminho |
-|---|---|
-| Estratégia de Observabilidade | `docs/observability/estrategia.md` |
-| Runbooks | `docs/observability/runbooks/` |
-| Dashboards (JSON) | `infra/dashboards/` |
-
----
-
-## 🔗 Fluxo de Contexto
-
-> [!NOTE]
-> Este é um **especialista avançado** para projetos de nível Complexo. Use APÓS DevOps.
-
-### Especialista Anterior
-← [Especialista em DevOps e Infraestrutura](./Especialista%20em%20DevOps%20e%20Infraestrutura.md)
-
-### Próximo Especialista
-→ *(Fase final para projetos complexos)*
-
-### Contexto Obrigatório
-
-| Artefato | Caminho | Obrigatório |
-|----------|---------|-------------|
-| Arquitetura | `docs/05-arquitetura/arquitetura.md` | ✅ |
-| Requisitos NF | Seção de RNF | ✅ |
-| CONTEXTO.md | `docs/CONTEXTO.md` | ✅ |
-
-### Prompt de Continuação
-
-```text
-Atue como SRE Sênior especialista em Observabilidade.
-
-Contexto do projeto:
-[COLE O CONTEÚDO DE docs/CONTEXTO.md]
-
-Arquitetura:
-[COLE O CONTEÚDO DE docs/05-arquitetura/arquitetura.md]
-
-Preciso [definir SLOs / configurar logging / implementar tracing / criar dashboards].
-```
-
----
-
-## Os Três Pilares
-
-```mermaid
-graph TB
-    subgraph Observability["📊 Observabilidade"]
-        LOGS[📝 Logs]
-        METRICS[📈 Métricas]
-        TRACES[🔗 Traces]
-    end
-    
-    LOGS --> CONTEXT[Contexto do Erro]
-    METRICS --> DETECTION[Detecção de Anomalias]
-    TRACES --> ROOT[Causa Raiz]
-    
-    CONTEXT & DETECTION & ROOT --> RESOLUTION[Resolução Rápida]
-```
-
----
-
-## Logging
-
-### 1. Estratégia de logging
-
-```text
-Sistema: [DESCREVA]
-Stack: [TECNOLOGIAS]
-Ambientes: [dev, staging, prod]
-
-Defina estratégia de logging:
-1. Níveis de log por ambiente:
-   - Dev: debug
-   - Staging: info
-   - Prod: info (debug pontual)
-   
-2. Formato estruturado (JSON):
-   - timestamp
-   - level
-   - message
-   - correlationId/traceId
-   - userId (se autenticado)
-   - metadata contextual
-
-3. O que logar:
-   - Requests HTTP (entrada/saída)
-   - Erros com stack trace
-   - Eventos de negócio importantes
-   - Decisões de sistema
-
-4. O que NÃO logar:
-   - PII sem mascaramento
-   - Secrets/tokens
-   - Bodies muito grandes
-
-5. Retenção e rotação
-6. Destino (stdout, arquivo, serviço)
-```
-
-### 2. Implementar logging estruturado
-
-```text
-Stack: [Node.js/Python/Go/etc]
-Logger atual: [se houver]
-
-Gere implementação de logger com:
-1. Formato JSON estruturado
-2. Níveis (error, warn, info, debug)
-3. Context propagation (correlationId)
-4. Request logging middleware
-5. Mascaramento de dados sensíveis
-6. Integração com framework
-
-Exemplo de uso para cada nível.
-```
-
----
-
-## Métricas
-
-### 3. Definir métricas-chave
-
-```text
-Sistema: [DESCREVA]
-Componentes: [API, Worker, Database, etc]
-
-Defina métricas usando RED/USE:
-
-**RED (para serviços):**
-- Rate: requisições por segundo
-- Errors: taxa de erro
-- Duration: latência (p50, p95, p99)
-
-**USE (para recursos):**
-- Utilization: % de uso
-- Saturation: fila/espera
-- Errors: erros do recurso
-
-Para cada componente, liste:
-- Métricas essenciais
-- Labels/dimensions
-- Alertas associados
-```
-
-### 4. Instrumentação de métricas
-
-```text
-Stack: [Node.js/Python/etc]
-Destino: [Prometheus/Datadog/CloudWatch]
-
-Implemente instrumentação:
-1. Métricas de requisição HTTP:
-   - request_count (labels: method, path, status)
-   - request_duration_seconds (histogram)
-   
-2. Métricas de negócio:
-   - [métrica específica do domínio]
-   
-3. Métricas de recursos:
-   - connection_pool_size
-   - queue_depth
-   
-4. Endpoint /metrics para scraping
-5. Push gateway (se necessário)
-```
-
----
-
-## Tracing Distribuído
-
-### 5. Implementar tracing
-
-```text
-Sistema: [DESCREVA]
-Serviços envolvidos: [LISTE]
-Tecnologia: [OpenTelemetry preferido]
-
-Implemente tracing distribuído:
-1. Setup do SDK (OpenTelemetry)
-2. Auto-instrumentação disponível
-3. Instrumentação manual para:
-   - Chamadas HTTP saintes
-   - Queries de banco
-   - Operações de cache
-   - Processamento de mensagens
-4. Propagação de contexto (W3C Trace Context)
-5. Sampling strategy (probabilístico, rate-limited)
-6. Exportação para backend (Jaeger, Zipkin, etc)
-```
-
-### 6. Correlacionar os três pilares
-
-```text
-Como conectar logs, métricas e traces:
-
-1. TraceId em todos os logs
-2. Exemplars em métricas (link para traces)
-3. Span annotations com contexto de negócio
-
-Mostre:
-- Como encontrar trace a partir de um erro no log
-- Como ir do alerta para o trace problemático
-- Como agregar logs de um trace
-```
-
----
-
-## Alertas e SLOs
-
-### 7. Definir SLOs
-
-```text
-Sistema: [DESCREVA]
-Usuários: [TIPO]
-Criticidade: [ALTA/MÉDIA/BAIXA]
-
-Defina SLOs:
-1. Disponibilidade:
-   - SLI: % de requests com sucesso (2xx, 3xx)
-   - SLO: 99.9% em janela de 30 dias
-
-2. Latência:
-   - SLI: p95 de tempo de resposta
-   - SLO: 95% das requests < 200ms
-
-3. Error Budget:
-   - Cálculo mensal
-   - Ações quando budget baixo
-
-Para cada SLO, defina:
-- Métrica que mede
-- Janela de tempo
-- Threshold
-- Consequência de violação
-```
-
-### 8. Configurar alertas
-
-```text
-SLOs definidos: [LISTE]
-Ferramenta: [PagerDuty/Opsgenie/etc]
-
-Configure alertas:
-1. Multi-window, multi-burn-rate para SLOs:
-   - Fast burn: 5min window, 14.4x burn
-   - Slow burn: 1h window, 6x burn
-
-2. Severidade:
-   - P1 (Critical): Página imediata
-   - P2 (High): Página em horário comercial
-   - P3 (Medium): Slack/email
-   
-3. Escalation policy
-4. Runbook link em cada alerta
-5. Redução de ruído (grouping, dedup)
-```
-
----
-
-## Dashboards
-
-### 9. Dashboard principal
-
-```text
-Sistema: [DESCREVA]
-Componentes: [LISTE]
-Ferramenta: [Grafana/Datadog]
-
-Crie dashboard de saúde do sistema:
-
-**Painel 1: Overview**
-- Status geral (verde/amarelo/vermelho)
-- Error budget restante
-- Requests/sec atual
-
-**Painel 2: RED Metrics**
-- Rate over time
-- Error rate over time
-- Latency percentiles
-
-**Painel 3: Resources**
-- CPU/Memory por serviço
-- Database connections
-- Queue depth
-
-**Painel 4: Business**
-- [Métricas de negócio relevantes]
-```
-
----
-
-## Runbooks
-
-### 10. Template de Runbook
-
-```text
-Crie runbook para o alerta: [NOME DO ALERTA]
-
-Estrutura:
-1. **O que significa este alerta**
-   [Explicação clara]
-
-2. **Impacto**
-   [O que usuários experimentam]
-
-3. **Diagnóstico**
-   - [ ] Verificar [X]
-   - [ ] Checar logs em [Y]
-   - [ ] Dashboard [Z]
-
-4. **Mitigação imediata**
-   [Passos para restaurar serviço]
-
-5. **Resolução**
-   [Como resolver definitivamente]
-
-6. **Escalation**
-   [Quando e para quem escalar]
-```
-
----
-
-## ✅ Checklist de Saída (Gate)
-
-- [ ] Logging estruturado implementado
-- [ ] Métricas RED expostas
-- [ ] Tracing distribuído funcionando
-- [ ] SLOs definidos e monitorados
-- [ ] Alertas configurados com runbooks
-- [ ] Dashboard principal criado
-- [ ] Teste de alerta realizado
-
----
-
-## Stack Recomendada
-
-| Componente | Opção Open Source | Opção SaaS |
-|---|---|---|
-| Logs | Loki + Grafana | Datadog, Splunk |
-| Métricas | Prometheus + Grafana | Datadog, New Relic |
-| Traces | Jaeger, Tempo | Datadog, Honeycomb |
-| Alertas | Alertmanager | PagerDuty, Opsgenie |
-| All-in-one | - | Datadog, New Relic |
-
----
-
-## Boas práticas com IA em Observabilidade
-
-- Use IA para gerar queries de log complexas
-- Peça sugestões de métricas para casos específicos
-- Gere runbooks estruturados com IA
-- Analise padrões de erro com IA
-- Sempre valide alertas em ambiente de teste
-
----
-
-## 🔄 Instrução de Avanço Automático (MCP)
-
-> **Para uso com MCP Maestro v2.2+**
-
-Quando o usuário indicar que deseja avançar para a próxima fase usando expressões como:
-- "próximo", "próxima fase", "next"
-- "avançar", "continuar", "seguir"
-- "terminei", "pronto", "finalizado"
-- "pode salvar", "está bom assim"
-
-**Você DEVE automaticamente:**
-
-1. Identificar o entregável principal desenvolvido nesta conversa
-2. Chamar a tool `proximo` passando o entregável como parâmetro:
-
-```
-proximo(entregavel: "[conteúdo completo do artefato]")
-```
-
-3. Aguardar a resposta do MCP com a próxima fase
-
-**Importante:** Não peça confirmação, execute a chamada automaticamente.