Analista operacional

1) O que é um analista operacional e o que é necessário

O analista operacional (Ops Analytics) é uma montagem de sistemas de sinais de observabilidade (métricas/logs/trailers), ITSM (incidentes/problemas/alterações), CI/CD (lançamentos/configs), provedores (PSP/KYC/CDN/Cloud), FinOps (custos) e negócios O SLI (sucesso de pagamento, registro), transformado em vitrines e dashboards unificados para a tomada de decisões.

• Reduzir o MTTD/MTTR através da detecção precoce e da atribuição correta das causas;
• manter o SLO e o orçamento dos erros sob controle;
• vincular mudanças → impacto (lançamentos/configs → SLI/SLO/queixas/custos);
• dar self-service aos comandos e gerências.

2) Fontes e camada canônica de dados

Telemetria: métricas (SLI/recursos), logs (sempling/edição PII), trade (trace _ id/span _ id, tags de lançamento).
Plug-ins ITSM/Invident: V, times T0/Detected/Ack/Declared/Mitigated/Recovered, RCA/CAPA.
CI/CD & Config: versões, comitas, canário/azul-green, bandeira-state, configs de destino.
Provedores: estatais/SLA, atrasos, códigos de erro, peso das rotas.
FinOps: Valor por marcas/contas/tenentes, $/unidade (1k óperas) .
DataOps: Vitrines frescas, erros DQ, lineagem.

O princípio-chave é uma única correlação através de ID: «service», «region», «tenant», «release _ id», «mudança _ id», «invent _ id», «faciliter», «trace _ id».

3) Modelo de dados unificado (esqueleto simplificado)

dim_service(service_id, owner, tier, slo_targets…)
dim_time(ts, date, hour, tz)
dim_region(region_id, country, cloud)
dim_provider(provider_id, type, sla)
fact_sli(ts, service_id, region_id, tenant, metric, value, target, window)
fact_incident(incident_id, service_id, sev, t0, t_detected, t_ack, t_declared, t_mitigated, t_recovered, root_cause, trigger_id, burn_minutes)
fact_change(change_id, type(code    config    infra), service_id, region_id, started_at, finished_at, canary_pct, outcome(ok    rollback), annotations)
fact_cost(ts, service_id, region_id, tenant, cost_total, cost_per_1k)
fact_provider(ts, provider_id, region_id, metric(latency    error    status), value)
fact_dq(ts, dataset, freshness_min, dq_errors)

4) SLI/SLO e métricas de negócios

Бизнес-SLI: `payment_success_ratio`, `signup_completion`, `deposit_latency`.
Тех-SLI: `availability`, `http_p95`, `error_rate`, `queue_depth`.
Camada SLO: alvos + burn-rate (janela curta/longa), anotações automáticas de violação.
Normalização: desempenho em 1k de sucesso/usuários/tráfego.

5) Correlações e atribuição de causas

Lançamentos/configs ↔ SLI/SLO: anotações em grafos; relatórios de causa e efeito (proporção de incidentes relacionados com mudanças; MTTR mudança-incidentes).
Provedores de serviços de negócios SLI: peso das rotas vs latency/erro, contribuição de cada provedor em falhas SLO.
Capacidade/recursos ↔ atrasos: superaquecimento de pool → crescimento p95 → impacto na conversão.

6) Anomalias e previsões

Anomalia-detecção: sazonalidade + liminares de marcação + mudança-fios de busca (antes/depois do lançamento).
Previsão de carga semanal/sazonal, previsão de orçamento de erros burn-out, prejulgamento de custos ($/unidade) .
Gardrelas: Alerts apenas com quórum de fontes (synthetic + RUM + Business SLI).

7) Vitrines e dashboards (árbitro)

1. Executive 28d: Mix de SEV, mediana MTTR/MTTD, SLO adherence, $/unidade, causas top.
2. SRE Ops: SLI/SLO + burn-rate, Page Storm, Actionable %, Change Failure Rate.
3. Mudar Impact: lançamentos/configs ↔ SLI/SLO/queixas, reversões e seus efeitos.
4. Providers: status-linha PSP/KYC/CDN, influências sobre o negócio SLI, tempos de respostas.
5. FinOps: per 1k txn, logs/egress, anomalias de custo, recomendações (sempling, armazenamento).
6. DataOps: frescura de vitrines, erros DQ, SLA de piplins, sucesso de backphill.

8) Qualidade dos dados e governance

Contratos de eventos: esquemas claros para incidentes/lançamentos/SLI (campos obrigatórios, fusos horários unificados).
Cheques DQ: abrangência, exclusividade das chaves, sintonia da timeline (t0≤detected≤ack...).
Régua: de dashbord a origem (traceable).
PII/segredos: edição/camuflagem por política; WORM para evidence.
SLA frescura: vitrines Ops ≤ 5 min de atraso.

9) Métricas de maturidade de analistas operacionais

Coverage:% dos serviços críticos em vitrines e bordões SLO (meta ≥ 95%).
Freshness: proporção de widgets com frescura ≤ 5 min (meta ≥ 95%).
Activability:% das transições de dashbord para ação (playbook/SOP/tíquete) ≥ 90%.
Detation Coverage: ≥ 85% dos incidentes detectam automação.
Atribute Rate: O percentual de incidentes com causa confirmada e desencadeador ≥ de 90%.
Mudar Impact Share: Proporção de incidentes relacionados com mudanças (controlando a tendência).
Data Quality: erros DQ/semana → ↓ QoQ.

10) Processo: de dados a ações

1. Coleta → limpa → normaliza a vitrine → (ETL/ELT, função-camada para ML).
2. Detecção/previsão → escalação por matriz (IC/P1/P2/Comms).
3. Ação: playbook/SOP, gate de lançamento, bandeira de fich, mudança de provedor.
4. Evidence e AAR/RCA: timeline, gráficos, links para lançamentos/logs/trailers.
5. CAPA e soluções de produtos - priorização em burn-minutos e $ -impacto.

11) Exemplos de solicitação (ideia)

11. 1 Impacto de lançamentos em SLO (24h)

sql
SELECT r. change_id,
COUNT(i. incident_id) AS incidents,
SUM(i. burn_minutes) AS burn_total_min,
AVG(CASE WHEN i.root_cause='code' THEN 1 ELSE 0 END) AS code_ratio
FROM fact_change r
LEFT JOIN fact_incident i
ON i.trigger_id = r. change_id
WHERE r. started_at >= NOW() - INTERVAL '24 hours'
GROUP BY 1
ORDER BY burn_total_min DESC;

11. 2 Taxa de problemas dos provedores por região

sql
SELECT region_id, provider_id,
SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END) AS prov_inc,
COUNT() AS all_inc,
100. 0SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END)/COUNT() AS pct
FROM fact_incident
WHERE t0 >= DATE_TRUNC('month', NOW())
GROUP BY 1,2
ORDER BY pct DESC;

11. 3 Vale por 1k pagamentos de sucesso

sql
SELECT date(ts) d,
SUM(cost_total)/NULLIF(SUM(success_payments)/1000. 0,0) AS cost_per_1k
FROM fact_cost c
JOIN biz_payments b USING (ts, service_id, region_id, tenant)
GROUP BY d ORDER BY d DESC;

12) Modelos de artefatos

12. 1 Esquema de ocorrência do incidente (JSON, fragmento)

json
{
"incident_id": "2025-11-01-042",
"service": "payments-api",
"region": "eu",
"sev": "SEV-1",
"t0": "2025-11-01T12:04:00Z",
"detected": "2025-11-01T12:07:00Z",
"ack": "2025-11-01T12:09:00Z",
"declared": "2025-11-01T12:11:00Z",
"mitigated": "2025-11-01T12:24:00Z",
"recovered": "2025-11-01T12:48:00Z",
"root_cause": "provider",
"trigger_id": "chg-7842",
"burn_minutes": 18
}

12. 2 Catálogo de métricas (YAML, fatia)

yaml metric: biz. payment_success_ratio owner: team-payments type: sli target: 99. 5 windows: ["5m","1h","6h","28d"]
tags: [tier0, region:eu]
pii: false

12. 3 Cartão de Relatório Executivo (seções)

1) SEV mix and MTTR/MTTD trends
2) SLO adherence and burn-out risks
3) Change Impact (CFR)
4) Providers: Degradation and switchover
5) FinOps: $/unit, log anomalies/egress
6) CAPAs: Status and Deadlines

13) Ferramentas e pattern arquitetônicos

Data Lake + DWH: camada «crua» para telemetria, vitrine para soluções.
Processamento de streaming: near-real-time SLI/burn-rate, fitas online para anomalias.
Função Store: reutilização do fic (canarica, sazonalidade, provedor de sinais).
Semantic Layer/Metric Store: definições de métricas unificadas (SLO, MTTR...).
Access Control: RBAC/ABAC, row-level security para tenentes/regiões.
Catalog/Lineage: pesquisa, descrição, dependência, proprietários.

14) Folhas de cheque

14. 1 Lançamento de analistas operacionais

• Os dicionários SLI/SLO, SEC, as razões, os tipos de mudança, foram aprovados.
• Esquemas de evento e times unificados.
• Conectores de telemetria, ITSM, CI/CD, provedores, billing.
• Vitrines: SLI/SLO, Inventos, Changes, Providers, FinOps.
• Executive/SRE/Mudança/Provers dashboards estão disponíveis.
• As alertas quórum e a supressão foram configuradas para as janelas de serviço.

14. 2 Visão Ops semanal

• As tendências SEC, MTTR/MTTD, falhas SLO, burn-hour.
• Mudar Impact e CFR, status de repasse.
• Incidentes de provimento e tempos de reação.
• FinOps: $/un., anomalias logs/egress.
• CAPA status, vencimentos, prioridades.

15) Anti-pattern

«A parede do cronograma», sem acção.
Definições diferentes de métricas em comandos (sem camada semântica).
A falta de anotações de lançamentos/janelas é uma atribuição fraca das causas.
Orientação média em vez de p95/p99.
Sem normalização de volume, os grandes serviços «parecem piores».
PII em logs/vitrines, violação de retenções.
Os dados são «grampeados» (> 5-10 min para widgets reais-time).

16) Mapa de trânsito de implementação (4-8 semanas)

1. Ned. 1: acordos de dicionário de métricas, esquemas de eventos, correlação de ID; conexão SLI/SLO e ITSM.
2. Ned. 2: Inventos/Changes/Administradores, anotações de lançamentos; Executiva & SRE dashboards.
3. Ned. 3: Camada FinOps ($/unidade) , a ligação com o SLI; anomalia com quórum.
4. Ned. 4: self-service (semantic layer/metric store), catálogo e lineage.
5. Ned. 5-6: previsão de carga/custo, relatórios aos provedores, vitrine CAPA.
6. Ned. 7-8: cobertura de ≥95% Tier-0/1, SLA frescura ≤5 minas, revisões OPS regulares.

17) Resultado

O analista operacional é uma máquina de decisão, como definições de métricas unificadas, vitrines frescas, atribuição correta de causas e transições diretas para playbooks e SOP. Nesse sistema, a equipe rapidamente detecta e explica os desvios, avalia com precisão o impacto dos lançamentos e provedores, gere custos e reduz o risco - e os usuários recebem um serviço estável.