Por que SUP-01
demorou mais este mês?
A diferença está concentrada em um único nó: N1 — Extrair dados. Em março, esse passo demorou 3m 27s; em abril, voltou ao normal de 1m 42s. Os outros três nós tiveram performance consistente entre os meses.
Workflow comparado · março ⇄ abril
A causa do pico em março foi o conector Icertis. A latência de resposta saltou para 2.840ms (vs. baseline 1.241ms) durante uma janela de manutenção da plataforma na noite de 31 mar, comunicada pela TI deles em ticket interno.
| Conector · N1 | Latência mar | Latência abr | ∆ |
|---|---|---|---|
| SAP | 897ms | 894ms | −0,3% |
| Ariba | 624ms | 612ms | −1,9% |
| Icertis | 2.840ms | 1.241ms | −56,3% |
Foi um evento pontual e já resolvido. Não há ação necessária. Mas vale registrar: o p95 do Icertis em horários de maintenance window pode comprometer o SLA do D+1, então recomendo configurar uma circuit-breaker para reagendar a execução de SUP-01 quando latência do Icertis ultrapassar 2s. Quer que eu rascunhe essa configuração?
Rascunho pronto. Não aplico nada antes da sua confirmação.
Comportamento esperado em uma janela de degradação como a de 31 mar:
- Atlas detecta latência alta logo na primeira tentativa de N1.
- Pausa a run, salva contexto e aguarda 30 min.
- Re-tenta. Se Icertis estiver normal, segue. Se não, repete até 3 vezes.
- Em vez do relatório chegar atrasado e degradado, ele chega uns minutos depois, mas íntegro — ou escala para humano explicitamente.
Confirma a aplicação? Posso publicar como SUP-01 v2.5 agora, ou deixar como rascunho para você revisar amanhã com o time.