Questão de Tecnologia da Informação · FGV CGE-SP 2025 (nº 118)

Observabilidade é a capacidade de entender o estado interno de um sistema a partir de seus dados externos, usando métricas (números sobre o desempenho), logs (registros textuais de eventos) e traces (caminhos completos de uma requisição). FinOps é a disciplina que une finanças e operações, focando na otimização de custos de nuvem.

• (A) Correta: A alternativa aborda o problema de forma integrada e eficaz. O disparo no p99 é uma latência de cauda, que afeta uma pequena parcela dos usuários, mas de forma severa, e viola o SLO. Usar traces (Jaeger) para identificar os spans lentos é a forma mais precisa de diagnosticar a causa raiz da latência. A correlação com logs (Loki) via trace_id é a prática ideal de observabilidade para entender o contexto do problema, especialmente com os logs DEBUG excessivos. Para FinOps, reverter o nível de log para INFO é a solução direta para o aumento de custos de armazenamento. Habilitar tail-based sampling para traces é uma estratégia inteligente de FinOps: garante que 100% dos traces problemáticos (lentos ou com erro) sejam capturados para análise, enquanto os traces normais são amostrados, otimizando custos sem comprometer a capacidade de diagnóstico de incidentes críticos.

• (B) Incorreta: Embora o p99 alto indique violação do SLO, caracterizar como quebra de SLA é precipitado. Rollback é para regressões, e não há indicação de nova implantação. Aumentar replicas (escalar horizontalmente) pode não resolver a latência de cauda se o problema for um gargalo específico (ex: banco de dados, código ineficiente) e não capacidade geral. Investigar a rede física com SNMP agressivo é uma ação drástica e prematura sem evidências que a justifiquem, ignorando as ferramentas de observabilidade da aplicação.

• (C) Incorreta: A estabilidade da média não significa que os alertas estão mal configurados; o p99 é um indicador crucial da experiência do usuário e do SLO. Ajustar o SLO para p50 é uma armadilha da banca, pois ignora completamente a experiência dos usuários mais afetados e esconde problemas de performance, sendo uma má prática de engenharia de confiabilidade. Pausar o distributed tracing em produção para FinOps é contraproducente, pois remove uma ferramenta essencial para diagnosticar problemas complexos como este, especialmente quando há alternativas mais inteligentes como o tail-based sampling.

• (D) Incorreta: Afirmar que o p99 é um outlier não prioritário é um erro grave. O p99 a 2000ms claramente viola o SLO de p95 < 500ms, pois p99 é sempre maior ou igual a p95. Ignorar a latência de cauda é uma má prática. Aplicar head-based sampling de 1% para traces em um cenário de diagnóstico de p99 alto é contraproducente, pois a maioria dos traces lentos seria perdida, dificultando a investigação. A economia de custos não deve comprometer a capacidade de resolver um incidente crítico que afeta a experiência do usuário.

• (E) Incorreta: Embora contenção de recursos possa ser uma causa, o p99 alto com média estável e excesso de logs DEBUG sugere mais um problema de código, configuração ou dependência externa do que uma contenção geral de CPU/I/O. Aumentar recursos sem diagnóstico é uma solução cara (FinOps) e ineficiente que pode não resolver a causa raiz. Embora o FinOps seja secundário à resolução do incidente, a questão pede para considerar o FinOps, e a alternativa A oferece uma solução que otimiza custos enquanto resolve o incidente.