Aula Prática · 2 horas

Aperfeiçoamento de Etapas Técnicas

Qualidade de Requisitos Não Funcionais — medindo NFRs localmente com Docker

🎯 O que vamos fazer

Subir um projeto SRE real com os dados da OLIST
Achar ferramentas locais para testar requisitos não funcionais
Usar o SWEBOK para nomear os eixos de RNF
Medir, tirar métricas e observar o sistema rodando em Docker

🧰 Pré-requisitos

Docker e Docker Compose instalados
Git + um terminal
Dataset OLIST (CSVs) baixado
Disposição para quebrar e consertar 🔧

🔄 As 3 etapas da aula

Etapa 1Rodar o projeto com a OLIST

Etapa 2Ferramentas locais de teste de RNF

Etapa 3Métricas + observabilidade em Docker

Agenda & Objetivos

Duas horas, mão na massa — do "sobe o projeto" ao "interpreta a métrica"

Visão geral

🕐 Roteiro (2h)

0:00–0:15 — Contexto: projeto SRE + dataset OLIST
0:15–0:55 — Etapa 1: subir o projeto com dados da OLIST
0:55–1:15 — SWEBOK e os eixos de RNF mensuráveis
1:15–1:40 — Etapa 2: ferramentas locais (carga, obs, segurança)
1:40–2:00 — Etapa 3: medir, observar e analisar

✅ Ao final você consegue

Rodar um stack Docker completo com dados reais
Nomear eixos de RNF usando o SWEBOK / ISO 25010
Escolher ferramentas locais por eixo de qualidade
Coletar latência, throughput, erro e uso de recursos
Ler um dashboard e apontar o gargalo

O projeto base — um stack SRE

github.com/afonsolelis/20261sre-primeironome-ultimonome

Contexto

🧱 O que sobe em Docker

ClickHouse — banco analítico colunar (portas 8123/9000)
MinIO — storage S3-compatível (data lake local)
ingestor — worker que lê do MinIO e carrega no ClickHouse
dashboard — app Streamlit na porta 8501
*-init — containers idempotentes de provisionamento

docker compose up -d → pipeline S3 → ingestão → análise

💻 Abrir repositório no GitHub

🔍 Por que é bom para NFR

É um pipeline de dados real: tem I/O, query pesada e UI
Tudo conteinerizado → fácil medir por container
Não tem observabilidade ainda — essa é a sua missão
Carga = consultas analíticas sobre a OLIST

Onde olhar no repo

docker-compose.yaml (serviços) · app/ (Streamlit + ingestor) · sql/ (schema/views) · tests/

O dataset OLIST

Brazilian E-Commerce Public Dataset — dados reais de e-commerce

Os dados

📦 O que é

~100 mil pedidos reais (2016–2018) de marketplaces no Brasil
9 tabelas relacionadas, em CSV
orders · order_items · payments · reviews
products · customers · sellers · geolocation · category

Fonte: Kaggle — "Brazilian E-Commerce Public Dataset by Olist"

🎯 Por que serve para medir NFR

Volume real: dá para gerar carga de verdade
Joins pesados: pedido × item × produto × pagamento
Consultas analíticas → estressam CPU, memória e I/O
Cardinalidade alta → bom para latência p95/p99

Exemplo de pergunta analítica

"Ticket médio por categoria e estado, por mês" — um join de 4 tabelas que vira carga de leitura no ClickHouse.

Etapa 1 — Rodar o projeto com a OLIST

Meta: dashboard no ar consultando dados reais

Mão na massa · 40 min

📝 Passo a passo

Clone o repositório e entre na pasta
cp .env.example .env e ajuste as variáveis
docker compose up -d — sobe ClickHouse, MinIO, ingestor, dashboard
Suba os CSVs da OLIST para o bucket do MinIO (console :9001)
Dispare/observe o ingestor carregando no ClickHouse
Abra o Streamlit em :8501 e valide os gráficos

✅ Funcionou se…

docker compose ps mostra tudo healthy
ClickHouse responde: SELECT count() FROM orders > 0
O dashboard abre sem erro e mostra dados da OLIST

Travou? Debug rápido

docker compose logs -f ingestor · cheque credenciais do MinIO no .env · confirme que os CSVs estão no bucket certo.

SWEBOK — o fundamento de qualidade

Guide to the Software Engineering Body of Knowledge (IEEE)

Base teórica

📚 O que o SWEBOK diz

É o corpo de conhecimento consolidado da Engenharia de Software (IEEE)
Tem uma área inteira: Software Quality
Trata qualidade como atributo mensurável, não "achismo"
Aponta para modelos de qualidade — em especial a ISO/IEC 25010

🔀 RF × RNF

Requisito Funcional (RF): o que o sistema faz
Requisito Não Funcional (RNF): quão bem ele faz
RNF = atributos de qualidade (os "-ilidades")

No nosso projeto

RF: "mostrar ticket médio por categoria". RNF: "responder em menos de 800ms no p95 com a base completa da OLIST".

Os eixos de RNF (SWEBOK / ISO 25010)

Seis atributos de qualidade e a pergunta que cada um responde

Eixos

ISO/IEC 25010 — modelo de qualidade referenciado pelo SWEBOK. Foco nos eixos que viram requisito não funcional.

⚡ Performance Efficiency

É rápido e econômico em recursos sob carga?

Ex: p95 da consulta < 800ms; CPU < 70%.

🛡️ Reliability

Continua funcionando e se recupera de falhas?

Ex: taxa de erro < 1% durante a carga.

🔒 Security

Protege dados e acessos?

Ex: sem credencial hardcoded; imagem sem CVE crítica.

🎨 Usability

É fácil de entender e usar?

Ex: dashboard navegável sem manual.

🔧 Maintainability

É fácil de mudar e testar?

Ex: análise estática sem smell crítico.

📦 Portability

Roda em outro ambiente sem dor?

Ex: sobe igual com um docker compose up.

Hoje medimos os eixos de cima (performance, reliability, recursos) — são os que dão métrica objetiva rodando localmente.

Quais RNF dá para medir localmente?

Com Docker, sem nuvem, sem custo — o objetivo vs. o difícil

Recorte

✅ Mensuráveis localmente

Performance: latência (p50/p95/p99) e throughput (req/s)
Reliability: taxa de erro e disponibilidade sob carga
Eficiência de recursos: CPU, memória e I/O por container
Security (parcial): scan de imagem e de código estático
Maintainability (parcial): linters e métricas de código

🟡 Difíceis só localmente

Usability: precisa de gente usando (teste com usuário)
Portability: exige rodar em ambientes diferentes
Disponibilidade real (SLA): precisa de produção e tempo

Regra prática

Se dá para gerar carga e ler um número, dá para medir local. O resto vira requisito qualitativo com critério de aceite.

Etapa 2 — Ferramentas locais de teste de RNF

Tudo roda em Docker, do seu laptop — escolha por eixo

Mão na massa · 20 min

Pesquise e escolha pelo menos uma ferramenta por categoria. Todas têm imagem oficial em Docker.

⚡ Carga & Performance

k6 · Locust · Apache Bench (ab) · wrk · Artillery

Medem: latência, throughput, erro sob carga.

📊 Observabilidade

Prometheus + Grafana · cAdvisor · node_exporter · OpenTelemetry · Loki · Jaeger/Tempo

Mostram: métricas, logs e traces em dashboard.

🔒 Segurança

Trivy (imagem) · OWASP ZAP (web) · Bandit / Semgrep (código)

Acham: CVEs, segredos e falhas estáticas.

🔧 Recursos & Código

docker stats · cAdvisor · ruff / flake8 · radon (complexidade)

Medem: CPU/mem por container e saúde do código.

Critério: a ferramenta tem que rodar offline, em container, e cuspir um número que dê para comparar antes/depois.

Observabilidade local com Docker

Os 3 pilares e como plugar no stack que já existe

Etapa 3 · setup

🔭 Os 3 pilares

Métricas: Prometheus coleta, Grafana mostra, cAdvisor dá CPU/mem por container
Logs: Loki + Promtail centralizam o que cada serviço escreve
Traces: OpenTelemetry + Jaeger/Tempo mostram o caminho da requisição

Métodos para guiar

RED (Rate, Errors, Duration) para serviços · USE (Utilization, Saturation, Errors) para recursos.

🧩 Plugando no compose

services:
  prometheus: { image: prom/prometheus }
  grafana:    { image: grafana/grafana }
  cadvisor:   { image: gcr.io/cadvisor/cadvisor }

cAdvisor já enxerga todos os containers do stack
Grafana pluga no Prometheus e você monta o dashboard
k6 pode exportar direto para o Prometheus

Métricas — o que medir em cada eixo

Do eixo de qualidade ao número concreto

Métricas

⚡ Performance

Latência p50 / p95 / p99 · Throughput (req/s) · Tempo da query

Ferramenta: k6 / Locust contra o :8501 e o HTTP do ClickHouse.

🛡️ Reliability

Taxa de erro (%) · Requisições falhas · Disponibilidade na carga

Ferramenta: métricas de erro do k6 + status no Grafana.

💻 Recursos

CPU (%) · Memória (MB) · I/O de disco e rede — por container

Ferramenta: cAdvisor + Prometheus + docker stats.

🔒 Segurança

Nº de CVEs por severidade · Segredos expostos · Findings de SAST

Ferramenta: Trivy na imagem + Bandit no código Python.

Sempre registre o baseline: meça antes de qualquer mudança. Sem baseline, não dá para dizer se melhorou.

Etapa 3 — Medir, observar e analisar

O ciclo: carga → métrica → dashboard → análise

Mão na massa · 30 min

📝 Roteiro

Suba o stack de observabilidade (Prometheus + Grafana + cAdvisor)
Escreva um teste de carga (k6) que consulta o dashboard/ClickHouse
Rode a carga e veja p95, throughput e erro
No Grafana, observe CPU/memória por container durante o teste
Anote o baseline de cada métrica

✅ Saídas esperadas

Latência p95 sob X usuários virtuais
Throughput máximo antes do erro subir
Qual container satura primeiro (ClickHouse? dashboard?)

Pergunta-guia

"Quando a carga dobra, o que estoura primeiro: CPU do ClickHouse, memória do dashboard, ou a latência da query?"

Como analisar o que você mediu

De número solto a decisão de engenharia

Análise

🎯 SLI, SLO e baseline

SLI — o indicador que você mede (ex.: p95 da consulta)
SLO — a meta para esse indicador (ex.: p95 < 800ms)
Baseline — o valor atual, ponto de partida
Compare medido × meta: ok / atenção / estourou

🔎 Achando o gargalo

Correlacione carga × recursos × latência no mesmo intervalo
Latência sobe + CPU do DB satura → gargalo no banco
Erro sobe sem saturar recurso → limite de conexão / timeout

Fechamento

Para cada eixo medido escreva: métrica · valor · meta · veredito · 1 hipótese de melhoria.

Entrega da aula

Evidência de que você mediu — não só rodou

Critérios

📦 Entrega mínima

Projeto rodando com dados da OLIST (print do dashboard)
Tabela de RNF mensuráveis: eixo → métrica → ferramenta → valor
Resultado do teste de carga: p95, throughput e taxa de erro
Print do Grafana com CPU/memória durante a carga
Uma análise curta + 1 hipótese de melhoria

🛠️ Como apresentar

Liste as ferramentas escolhidas e por quê
Mostre o baseline de cada métrica
Aponte o gargalo encontrado com evidência

Formato da linha da tabela

Performance · p95 · k6 · 640ms (meta < 800ms) → ✅ ok

Recap & próximos passos

Do projeto no ar à qualidade medida e observável

Fechamento

1 · Projeto + OLIST

Stack SRE em Docker rodando com dados reais

2 · SWEBOK

Eixos de RNF nomeados pela ISO 25010

3 · Ferramentas

Carga, observabilidade e segurança locais

4 · Observabilidade

Métricas, logs e traces com Prometheus/Grafana

5 · Análise

Baseline, SLI/SLO e gargalo identificado

Próximo nível: levar a mesma observabilidade para a nuvem (AWS) e transformar os baselines em SLOs com alertas.