Questão de Engenharia de Software — Geral — FCC 2025

DevOps, DevSecOps e Observabilidade: práticas para infraestrutura confiável

Gabarito: letra C. A alternativa correta é a que promove a criação de dashboards dinâmicos e interativos integrados a sistemas de alerta, permitindo o acompanhamento em tempo real de métricas, logs e eventos — exatamente o que define a observabilidade moderna, que vai além do monitoramento tradicional ao correlacionar métricas, logs e traces para entender não apenas onde ocorreu um erro, mas por que ele aconteceu. As demais alternativas contrariam os princípios de automação, integração e visibilidade contínua que sustentam DevOps e DevSecOps.

O enunciado descreve um cenário de fortalecimento de práticas de automação e monitoramento, com ferramentas como Ansible, AWX, Prometheus, Grafana e ELK Stack. O cerne da questão é identificar qual prática realmente contribui para uma infraestrutura confiável e segura nesse contexto. Para isso, é preciso entender três conceitos que se entrelaçam: DevOps, DevSecOps e observabilidade.

DevOps é uma cultura e um conjunto de práticas que integram desenvolvimento (Dev) e operações (Ops), com o objetivo de entregar software de forma rápida, contínua e com qualidade. Isso se dá por meio da automação de processos (build, teste, deploy), da colaboração entre equipes e do monitoramento contínuo do ambiente. O DevSecOps incorpora a segurança em todas as fases do ciclo de vida, seguindo o princípio do shift left — mover a segurança para o início do processo, em vez de tratá-la apenas no final. A segurança, portanto, não é uma barreira final, mas uma responsabilidade compartilhada e automatizada.

A observabilidade é o conceito que diferencia as boas práticas das ruins. O monitoramento tradicional coleta métricas e logs para identificar falhas e gargalos. A observabilidade, por sua vez, permite entender o comportamento do sistema por meio da correlação entre métricas, logs e traces, fornecendo um panorama completo. Com isso, as equipes conseguem identificar padrões ocultos, prever falhas e agir proativamente. Ferramentas como Prometheus (métricas), Grafana (dashboards) e a ELK Stack (logs) são exatamente os pilares dessa abordagem: coletar dados de diferentes fontes, correlacioná-los e apresentá-los de forma visual e acionável.

A pegadinha da banca está em apresentar alternativas que parecem razoáveis, mas que contradizem os princípios de automação e integração. Por exemplo, manter controle manual de segurança, fazer deploy manual em produção, ou priorizar análise pontual de eventos sem integração com métricas são práticas que vão contra a essência do DevOps. A palavra-chave que separa a alternativa correta das demais é integração: dashboards que integram métricas, logs e eventos, com alertas em tempo real, é o que de fato contribui para a segurança e confiabilidade.

Guarde este critério: em questões de DevOps/DevSecOps, a resposta correta quase sempre envolve automação, integração e visibilidade contínua. Alternativas que sugerem processos manuais, isolamento de dados ou segurança como etapa final estão, via de regra, erradas. É exatamente nessa fronteira que as alternativas se dividem.

Alternativa A — ❌ Incorreta

A alternativa afirma que se deve priorizar a coleta estruturada de logs e a análise pontual de eventos críticos, mesmo que a integração com dados de métricas operacionais ainda não esteja contemplada nos painéis de observabilidade. Isso contraria o conceito de observabilidade, que exige a correlação entre logs, métricas e traces para entender o comportamento do sistema. A análise pontual de eventos, sem integração, é uma prática de monitoramento tradicional e limitada, que não permite identificar a causa raiz de problemas. A banca explora aqui a tentação de focar em logs isoladamente, mas a essência da observabilidade é justamente a integração.

Alternativa B — ❌ Incorreta

A alternativa sugere usar ferramentas de automação (Ansible, AWX) para padronizar tarefas recorrentes, mas mantendo o controle manual de processos relacionados à segurança e conformidade. Isso é o oposto do DevSecOps, que prega a automação da segurança em todas as fases do ciclo de vida. O controle manual de segurança cria gargalos, aumenta o risco de erro humano e vai contra o princípio do shift left. A pegadinha está em apresentar a automação para tarefas rotineiras, mas deixar a segurança de fora — o que é uma visão ultrapassada e insegura.

Alternativa C — ✅ Correta ⟵ GABARITO

A alternativa C descreve exatamente o que a observabilidade moderna deve fazer: criar dashboards dinâmicos e interativos integrados a sistemas de alerta, permitindo o acompanhamento em tempo real de métricas, logs e eventos de servidores e aplicações. Isso contribui diretamente para a segurança e confiabilidade da infraestrutura, pois permite a detecção precoce de falhas, a correlação de dados e a ação proativa. Ferramentas como Prometheus, Grafana e ELK Stack são os meios para alcançar esse objetivo. A alternativa espelha os termos-chave do enunciado: automação, monitoramento e observabilidade integrados.

Alternativa D — ❌ Incorreta

A alternativa propõe configurar pipelines de CI/CD voltados às fases de teste e homologação, adotando o deploy manual no ambiente de produção como medida de controle e rastreabilidade. Isso contradiz o princípio da entrega contínua, que busca automatizar todo o processo de deploy, reduzindo riscos e aumentando a frequência de entregas. O deploy manual é uma prática arcaica que introduz erros e atrasos. A banca tenta fazer o candidato acreditar que o controle manual é uma medida de segurança, mas no DevOps a automação é justamente o que garante rastreabilidade e confiabilidade.

Alternativa E — ❌ Incorreta

A alternativa sugere implementar soluções de monitoramento orientadas à coleta de dados históricos e análise pós-incidente, com alertas configurados para períodos específicos e foco na redução de falsos positivos fora do horário comercial. Isso é uma visão reativa e limitada do monitoramento. A observabilidade moderna exige monitoramento contínuo e proativo, com alertas em tempo real, independentemente do horário. A análise pós-incidente é importante, mas não pode ser o foco principal. A pegadinha está em apresentar uma prática de monitoramento tradicional (reativa) como se fosse adequada, quando o ideal é a observabilidade proativa.

Gabarito: letra C