Forem: Marcos Vilela

Quando o Banco Não Caiu: Um Incidente de Conexão Que Expôs um Problema de Resiliência na Aplicação

Marcos Vilela — Thu, 16 Apr 2026 11:26:28 +0000

Incidentes reais são excelentes testes de maturidade técnica. Eles revelam não apenas falhas de código, mas principalmente falhas de premissas arquiteturais.

Este artigo descreve a investigação de um incidente envolvendo perda de conexão com PostgreSQL em ambiente produtivo, durante um pico de eventos. O objetivo aqui não é apontar culpados, mas demonstrar capacidade analítica, organização de evidências e raciocínio estruturado de troubleshooting.

Contexto do Incidente

Durante um pico elevado de processamento de eventos, o backend perdeu conexão com o banco de dados e não conseguiu se recuperar automaticamente. O banco permaneceu saudável durante todo o período. A aplicação, porém, entrou em modo degradado e passou a retornar dados mockados ao invés de consultar o banco real.

Primeira Hipótese: Banco Instável?

Sempre que há perda de conexão, a suspeita inicial costuma ser:

Failover do RDS
Reinício automático
Exaustão de conexões
Saturação de CPU ou I/O

A investigação começou pelo lado do banco.

Evidências coletadas

Status do RDS permaneceu Available
Nenhum evento de failover
Nenhum reboot automático
Métricas de CPU e memória estáveis
Log do banco registrou:

could not receive data from client: Connection reset by peer

Esse log é crucial. Ele indica que quem encerrou a conexão foi o cliente, não o banco. A hipótese de indisponibilidade do RDS foi descartada.

Mudança de Foco: Aplicação

Com o banco saudável, a análise passou para a aplicação.

Observações importantes:

O container continuou rodando (não houve restart)
Não houve crash
A API permaneceu respondendo
Porém, estava desconectada do banco

Isso é um estado perigoso: sistema aparentemente saudável, mas funcionalmente degradado.

Análise do Código

Ao revisar a implementação do serviço de banco de dados, foi identificado o seguinte padrão:

Existe uma variável interna isConnected
Após a primeira conexão bem-sucedida, essa variável é marcada como true
O sistema passa a assumir que o banco continuará disponível indefinidamente

Problemas estruturais identificados:

isConnected é tratada como fonte de verdade permanente
Não há mecanismo de recriação do pool
Não existe estratégia de reconexão automática
Falhas de socket não invalidam o estado interno
O erro não força reinicialização do container

Durante o pico de eventos, o backend encerrou abruptamente o socket TCP.

Após isso:

O pool ficou inválido
isConnected permaneceu true
A aplicação acreditava estar conectada
Nenhuma nova tentativa de conexão foi realizada

Resultado: sistema ativo, porém inutilizável do ponto de vista de dados reais.

Causa Raiz

A causa raiz não foi indisponibilidade do banco.

Foi uma falha de resiliência na camada de aplicação.

O sistema foi projetado com a premissa implícita de que:

"Se conectou uma vez, permanecerá conectado."

Essa premissa não é válida em ambientes distribuídos.

Conexões TCP podem ser encerradas por:

Picos de carga
Timeouts
Saturação temporária
Interrupções de rede
Problemas internos do runtime

Sem mecanismo de reconexão, qualquer falha transitória se torna permanente até intervenção manual.

Ação Corretiva Imediata

A solução operacional foi simples:

Reset da task do backend
Pool recriado
Conexão restabelecida
Serviço normalizado

Isso confirmou o diagnóstico: o problema estava no estado interno da aplicação.

Lições Arquiteturais

Este incidente reforça princípios fundamentais de sistemas distribuídos:

Conexões não são permanentes.
Pools não são imutáveis.
Estado interno pode mentir.
Healthcheck deve validar dependências reais.
Resiliência não é opcional em cenários de alta carga.

O banco estava saudável. A infraestrutura estava saudável. O problema estava na suposição arquitetural.

Conclusão

O incidente demonstrou que o maior risco não estava na infraestrutura, mas na camada de aplicação. A reinicialização resolveu o estado atual, mas não corrige o problema estrutural. Sistemas robustos não apenas se conectam — eles sabem se reconectar.

E isso faz toda a diferença quando a carga aumenta e o comportamento real do sistema começa a divergir das premissas iniciais de projeto.

Foi uma lição aprendida, não atuei na camada da aplicação, mas no throubleshooting e resolução pontual do incidente, o que estava na minha alçada.

Criando uma Composite Actions para utilizar em do CI/CD do GitHub

Marcos Vilela — Mon, 06 Apr 2026 11:11:51 +0000

O GitHub Actions é uma ferramenta poderosa para orquestrar pipelines de CI/CD, mas às vezes você deseja um pouco mais de controle sobre o que acontece dentro deles. Uma composite action oferece a flexibilidade de uma etapa de fluxo de trabalho normal com a conveniência de uma ação... e, quando combinada com um coletor baseado em TypeScript, torna-se um componente reutilizável e de nível de plataforma.

Por que uma composite action?

Executa no mesmo runner do job: ideal para tarefas de orquestração e arquivo de contexto (nenhum contêiner separado).
Permite mixar shell e outras actions sem escrever JavaScript puro.
Fácil de versionar e publicar no marketplace; repositórios mono ou multi-repo podem reutilizá-la.

Nós escolhemos esse modelo porque queríamos:

Capturar contexto do workflow (branch, run_id, status, duração).
Ler artefatos JSON produzidos pelo pipeline.
Agregar logs/outputs e enviar para um serviço de telemetria.
Não quebrar o job se algo falhar — execução sempre com if: always().

Estrutura do repositório

.
├── action.yml               # definição da composite action
├── package.json             # dependências e scripts
├── src/
│   ├── collector.ts         # lógica em TypeScript
│   └── lib/                 # módulos auxiliares testáveis
├── dist/                    # bundle JS (commitado)
├── tests/                   # Jest unit tests
└── .github/workflows/       # workflows de demo, feature, main...

O collector.ts é o coração: lê variáveis de ambiente, analisa diretórios de artefatos, soma tamanhos de logs, faz retries no envio HTTP e gera um payload estruturado.

Exemplo de `action.yml`

name: "[ORG] Metrics-Collect Composite Action"
description: "Collect and send structured pipeline metrics to an external endpoint."
author: "Platform Engineering Team"

inputs:
  endpoint_url:
    description: "HTTP endpoint to receive metrics (if empty, dry-run)"
    required: false
    default: ""
  auth_token:
    description: "Token used for auth (pass as secret)"
    required: false
    default: ""
  artifact_patterns:
    description: "Comma-separated artifact name patterns to download"
    required: false
    default: ""
  include_logs:
    description: "Whether to attempt log collection"
    required: false
    default: "true"
  working_directory:
    description: "Working directory (for monorepos)"
    required: false
    default: ""
  dry_run:
    description: "If true, do not send HTTP requests"
    required: false
    default: "false"

outputs:
  metrics_status:
    description: "Overall status: ok | partial | failed"
    value: ${{ steps.run-collector.outputs.metrics_status }}
  payload_path:
    description: "Local path to generated payload"
    value: ${{ steps.run-collector.outputs.payload_path }}

runs:
  using: "composite"
  steps:
    - name: Download artifacts (pattern)
      uses: actions/download-artifact@v4
      with:
        name: ${{ inputs.artifact_patterns }}
        path: ./artifacts
      continue-on-error: true

    - name: Run Metrics Collector
      shell: bash
      run: |
        node $GITHUB_ACTION_PATH/dist/index.js \
          --endpoint "${{ inputs.endpoint_url }}" \
          --auth-token "${{ inputs.auth_token }}" \
          --artifact-dir "./artifacts" \
          --include-logs "${{ inputs.include_logs }}" \
          --working-directory "${{ inputs.working_directory }}" \
          --dry-run "${{ inputs.dry_run }}" || true

Collector em TypeScript

A justificativa por usar TypeScript:

Tipagem, autocompletar e refatorações fáceis durante o desenvolvimento.
Testes com Jest (busca por arquivos JSON, análise de logs, tratamento de erros).
Construção um bundle único com @vercel/ncc garante que o runner não precisa instalar nada.

Trecho de src/collector.ts:

async function main() {
  const inps = parseArgs();
  const ctx = await collectWorkflowContext();
  const artifactFiles = await discoverJsonFiles(inps.artifactDir);
  // ...agrega dados...
  try {
    const res = await sendWithRetry(inps.endpoint!, payload, headers, inps.retryCount!, inps.timeoutMs!);
    // ...insere status/event_id no payload...
  } catch (err) {
    console.error('Failed to send payload', err);
  }
}

main().catch(e => { console.error(e); process.exitCode = 0; });

O código trata todos os erros localmente, grava metrics-output/payload.json e produz outputs para a composite.

Integração com CI/CD

Adicionei um workflow de exemplo (.github/workflows/feature-workflow.yml) que roda o pipeline principal e, em seguida, chama a composite para coletar métricas:

jobs:
  call-shared-ci:          # job reutilizável de CI
    uses: org/shared-workflows/backend-ci@v1

  collect-metrics:
    needs: [call-shared-ci]
    if: always()
    runs-on: ubuntu-latest
    permissions:
      contents: read
      actions: read
    steps:
      - uses: actions/checkout@v6
      - uses: org/metrics-collect@v1
        with:
          endpoint_url: ${{ secrets.METRICS_ENDPOINT }}
          auth_token: ${{ secrets.METRICS_TOKEN }}
          artifact_patterns: "step-result-*,coverage-report"
          include_logs: "true"

A condição if: always() garante que, mesmo que a verificação de lint/test falhe, ainda coletamos dados.

Demo local com `act`

O repositório contém um workflow de demo que gera artefatos JSON falsos e executa a action com endpoint_url apontando para webhook.site:

on: workflow_dispatch
jobs:
  demo:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - run: mkdir artifacts; echo '{"foo":1}' > artifacts/metrics.json
      - uses: ./
        with:
          endpoint_url: ${{ secrets.INPUT_ENDPOINT_URL }}
          include_logs: "true"

O act pode executar esse workflow offline, contanto que você passe -s INPUT_ENDPOINT_URL="https://webhook.site/...".

Casos de uso

Telemetry / Analytics: enviar métricas de duração, falha e outputs para um motor centralizado.
Auditoria: consolidar resultados de lint, testes e segurança em um único payload para relatórios de conformidade.
Cross-repo dashboards: equipes podem empacotar essa action e aplicar em todos os repositórios simples ou monorepos.

Arquitetura definida

Composite Action (orquestração): inputs/outputs declarados, download de artefatos, execução do binário bundle.
Collector TypeScript: lógica pura, agnóstica de GitHub; módulos auxiliares testáveis.
Bundle dist/index.js: resultante do @vercel/ncc (commitado).
Workflows: demo (para desenvolvimento), feature/staging/main (integração/prod).

Tolerância a falhas

Falhas no download de artefatos ou envio HTTP não quebram o job (usar continue-on-error e || true).
Logs e payload são persistidos localmente (metrics-output/) para inspeção.
Retries com backoff exponencial no módulo HTTP.

Publicando e versionando

Usamos semantic-release em uma workflow de release que dispara na conclusão da staging:

dependencies:
  - name: release-workflow
    uses: org/shared-workflows/shared-release@staging

Cada release produz uma tag (v1, v1.1.0, etc). Consumidores referenciam org/metrics-collect@v1 para estabilidade.

Conclusão

Transformar lógica de coleta de métricas em uma composite action permite padronizar instrumentação em toda a organização. O uso de TypeScript e bundling com ncc garante código limpo, testável e que roda rapidamente nos runners.

Shared Workflows: minha experiência definindo pipelines reutilizáveis

Marcos Vilela — Tue, 03 Mar 2026 19:53:52 +0000

Nos últimos meses trabalhei na definição de um modelo padrão de shared workflows para projetos de backend Node.js e recursos de infraestruturas implantados na AWS. Neste artigo descrevo a motivação, decisões de arquitetura, trechos de código e aprendizados que considero úteis para quem quer adotar um modelo similar.

Problema e motivação

Em organizações com múltiplos times e repositórios, cada projeto costuma inventar seu pipeline (lint, test, build, deploy). Isso gera retrabalho, inconsistências de segurança e custo de manutenção alto. Minha meta foi criar um conjunto de workflows reutilizáveis — fáceis de configurar por repositórios consumidores — que reduzissem duplicação e padronizassem boas práticas.

Abordagem

Optei por usar reusable workflows do GitHub Actions (on: workflow_call) e separar claramente responsabilidades, exemplo:

CI: lint, install, cache, unit/integration tests, security scan (yarn audit).
Infra CI: Terraform fmt/init/plan (shared-terraform-ci).
CD: build/push para ECR, deploy blue/green em ECS (shared-backend-deploy-ecs).
Release: criação automática de branch de release e PR para main (shared-release-workflow).

Essa separação facilita reaproveitamento: um repositório pode chamar apenas o CI shared, ou o deploy shared, ou ambos através de wrappers.

Trechos de consumo (exemplos)

Consumo do shared CI num projeto:

jobs:
  ci:
    uses: ./.github/workflows/shared-backend-ci.yml
    with:
      working_directory: app
      node_version: '20'
      enable_security_scan: true
    secrets:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Wrapper que executa deploy em staging e, em seguida, chama o workflow de release se o deploy teve sucesso:

jobs:
  deploy:
    uses: ./.github/workflows/shared-backend-deploy-ecs.yml
    with:
      environment: staging
      tf_backend_bucket: my-staging-state
      tf_var_file: envs/staging/variables.tfvars
    secrets:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  promote:
    needs: deploy
    if: ${{ needs.deploy.result == 'success' }}
    uses: ./.github/workflows/shared-release.yml
    secrets:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Decisões arquiteturais chave

Reusable workflows via workflow_call favorecem versão e rollback centralizado. Consumidores apontam para uma tag (@v1) no repositório de shared workflows.
Segreguei permissões por job (princípio de menor privilégio): jobs de lint/test usam contents: read; jobs de release/deploy recebem permissões mais elevadas apenas quando estritamente necessário.

Aprendizados e recomendações

Parametrização é essencial. Trabalhei com working_directory, app_path, image_tag e outros inputs para permitir que projetos com monorepos ou estruturas diferentes reutilizem os mesmos workflows.
Teste local e validação estática. Ferramentas como actionlint, shellcheck e checkov evitaram regressões e problemas de segurança antes do merge.
Documente uso e exemplos. Consumidores adotam shared workflows muito mais rápido quando encontram exemplos práticos e um README conciso com nomes de secrets esperados.
Tenha um piloto. Validar o modelo em um projeto piloto permitiu ajustar inputs e detectar diferenças (por exemplo, onde o monorepo precisava de um working_directory diferente).

Riscos & mitigação

Diferenças entre repositórios: mitigação com inputs configuráveis e exemplos detalhados.
Permissões excessivas: mitigação com revisão de permissões por job e uso de roles para operações AWS.
Dependência central: documentar SLA de alterações e versionar via tags semânticas para evitar breaking changes.

Conclusão

Criar um modelo de shared workflows traz retorno rápido em escala: menos esforço duplicado, pipelines padronizados e melhorias de segurança centralizadas. A chave do sucesso foi manter o design simples, parametrizável e bem documentado, além de validar por meio de um piloto real.

Se você estiver começando, recomendo iniciar pelo shared CI (lint/test) e, em seguida, evoluir para um shared deploy com validações de infraestrutura (Terraform) e deploys controlados.

[Boost]

Marcos Vilela — Tue, 03 Mar 2026 19:53:00 +0000

Reestudando sua infraestrutura

Marcos Vilela ・ Jan 27

#security #iac #vulnerabilityanalysis #devops

Template de testes de API com K6

Marcos Vilela — Tue, 24 Feb 2026 12:18:31 +0000

Escrevi um template para servir de modelo para escrita de testes de performance para testar APIs REST com k6, integrando Prometheus e Grafana localmente e adicionando utilitários reutilizáveis para autenticação, checks, thresholds e geração de relatórios. A seguir descrevo as decisões que tomei, exemplos de código e como rodar localmente e no CI.

Por que escolhi o k6

Escolhi o k6 por ser leve, confiável e por permitir escrever testes em JavaScript com boa legibilidade. Ele integra bem com observability (Prometheus/Grafana) e funciona tanto via CLI quanto em container — ideal para rodar localmente ou em pipelines de CI.

Estrutura do projeto

Organizei o repositório com foco em reutilização e clareza:

tests/ — scripts organizados por tipo (smoke, load, stress, soak).
lib/ — utilitários e helpers:
- lib/common/ — auth.js, checks.js, generators.js, thresholds.js
- lib/config/loader.js — carregador de configurações (.env, env vars e arquivos JSON)
- lib/utils/ — logger.js, reporter.js
docker-compose.yml — stack local com k6, prometheus e grafana
.env.example — exemplo mínimo de variáveis locais

Essa divisão mantém os testes pequenos e delega lógica compartilhada para lib/.

Configuração e precedência de variáveis

Implementei uma lógica simples de carregamento de configuração em lib/config/loader.js:

Variáveis passadas via CLI/CI (__ENV) têm prioridade;
Em seguida, eu leio o .env local;
Por fim, valores padrões vindos de config/staging.json ou config/production.json.

Trecho simplificado:

// lib/config/loader.js (trecho)
const currentEnv = __ENV.ENVIRONMENT || dotEnv.ENVIRONMENT || 'staging';
const configFile = JSON.parse(open(`../../config/${currentEnv}.json`));

const config = Object.assign({}, configFile, {
  BASE_URL: __ENV.BASE_URL || dotEnv.BASE_URL || configFile.BASE_URL,
  USERNAME: __ENV.USERNAME || dotEnv.USERNAME || configFile.USERNAME,
  PASSWORD: __ENV.PASSWORD || dotEnv.PASSWORD || configFile.PASSWORD,
  AUTH_TOKEN: __ENV.AUTH_TOKEN || dotEnv.AUTH_TOKEN || configFile.AUTH_TOKEN,
});

Nota: __ENV é a forma padrão do k6 para acessar variáveis de ambiente passadas na execução.

Autenticação reutilizável

Para endpoints protegidos criei lib/common/auth.js. A função authenticate() tenta:

Retornar AUTH_TOKEN se presente (útil para debug);
Caso contrário, fazer login com USERNAME/PASSWORD e retornar o token.

Uso típico em um teste:

import { authenticate } from '../../lib/common/auth.js';

export function setup() {
  const token = authenticate();
  return { token };
}

A função valida a resposta (checks) e chama fail() em caso de erro para interromper o teste quando a autenticação falha.

Checks e thresholds

Criei helpers para checks (lib/common/checks.js) e thresholds (lib/common/thresholds.js) para padronizar asserts e SLOs:

// Exemplo de test (smoke)
import http from 'k6/http';
import config from '../../lib/config/loader.js';
import { standardChecks } from '../../lib/common/checks.js';

export const options = {
  vus: 1,
  duration: '10s',
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<500'],
  },
};

export default function () {
  const res = http.get(`${config.BASE_URL}/health`);
  standardChecks.is200(res);
}

Os thresholds possibilitam que o job do CI falhe automaticamente quando os SLOs não são atendidos.

Relatórios

Integrei o k6-reporter para gerar summary.html e summary.json. No lib/utils/reporter.js exporto handleSummary:

import { htmlReport } from "https://raw.githubusercontent.com/benc-uk/k6-reporter/main/dist/bundle.js";

export function handleSummary(data) {
  return {
    "summary.html": htmlReport(data),
    "summary.json": JSON.stringify(data),
  };
}

E nos testes eu apenas faço:

import { handleSummary } from '../../lib/utils/reporter.js';
export { handleSummary };

Observability: Prometheus + Grafana

Para observability local usei docker-compose.yml com k6, Prometheus e Grafana. Configurei o k6 para enviar métricas via remote write para o Prometheus, e ativei remote-write-receiver no contêiner do Prometheus.

Execução local recomendada:

docker-compose up -d
# rodar um teste (container k6 já monta o repositório):
docker-compose run --rm k6 run tests/smoke/01-health-check.js

Após subir a stack você pode abrir Grafana (http://localhost:3000) e Prometheus (http://localhost:9090).

Integração com CI (GitHub Actions)

Usei a grafana/k6-action para executar scripts no CI. Exemplo de step:

- name: Run K6 Smoke Test
  uses: grafana/k6-action@v0.2.0
  with:
    filename: tests/smoke/01-health-check.js
  env:
    BASE_URL: ${{ secrets.BASE_URL }}
    ENVIRONMENT: staging

Recomendo rodar smoke em PRs e load/stress em jobs separados ou agendados para evitar impacto em ambientes de produção.

Boas práticas que segui

Não commitar segredos (.env está no .gitignore).
Reutilizar helpers em lib/ para diminuir duplicação.
Definir thresholds para transformar métricas em critérios de sucesso/falha.
Manter testes idempotentes para que possam ser executados várias vezes sem efeitos colaterais.

Problemas que enfrentei e como resolvi

Leitura de .env: implementei parsing que aceita aspas e ignora comentários.
Autenticação: incluí suporte a AUTH_TOKEN estático para facilitar debug sem chamadas de login.
Observability: configurei Prometheus para aceitar remote write do k6 no ambiente local.

Exemplo mínimo pronto para copiar

// tests/smoke/01-health-check.js
import http from 'k6/http';
import config from '../../lib/config/loader.js';
import { standardChecks } from '../../lib/common/checks.js';

export const options = {
  vus: 1,
  duration: '10s',
};

export default function () {
  const res = http.get(`${config.BASE_URL}/health`);
  standardChecks.is200(res);
}

Conclusão

Criar este template me ajudou a padronizar a forma como escrevemos e executamos testes de carga: fica mais fácil rodar localmente com observability, sendo assim para cada projeto, inicio um novo repositório a partir desse template, posso utilizar os testes padrões para validação e escrever novos testes logicamente, tendo assim mais flexibilidade, robustez, escala e padronização, além de poder, integrar/utilizar o K6 nas pipelines de CI/CD.

Como integrei testes de carga com K6, GitHub Actions e OpenTelemetry

Marcos Vilela — Tue, 10 Feb 2026 11:24:58 +0000

Neste artigo, compartilho minha experiência construindo uma infraestrutura de testes de carga gerida de forma eficiente com GitHub Actions e observável via integração com OpenTelemetry (OTel). O objetivo era garantir que o desempenho da nossa API pudesse ser monitorado facilmente dentro dos pipelines de CI/CD.

O Problema

Precisávamos executar testes de desempenho regularmente contra nossos ambientes de staging e produção sem intervenção manual. Além disso, as métricas geradas por esses testes precisavam ficar visíveis nos nossos dashboards centralizados do Grafana, que usam o Amazon Managed Prometheus (AMP) alimentado por um OpenTelemetry Collector.

Por que o K6?

Escolhi o K6 porque permite escrever testes em JavaScript, tornando-os acessíveis para toda a equipe. É leve, compatível com containers e tem suporte nativo para exportar métricas para OpenTelemetry.

Estrutura do caso de uso

Estruturei o repositório para lidar com diferentes tipos de testes:

Smoke Tests: Verificações rápidas de saúde executadas em pull requests.
Load Tests: Baselines de desempenho padrão executadas em agendamentos.
Stress & Soak Tests: Testes mais agressivos para identificar pontos de ruptura.

Aqui está um exemplo simplificado de como estruturei um teste básico usando checks e thresholds:

import http from 'k6/http';
import { check } from 'k6';

export const options = {
    thresholds: {
        http_req_duration: ['p(95)<2000'], // 95% das requisições devem estar abaixo de 2s
        http_req_failed: ['rate<0.01'],     // Menos de 1% de falha
    },
};

export default function () {
    const res = http.get('https://api.staging.example.com/health');

    check(res, {
        'status é 200': (r) => r.status === 200,
    });
}

Passo 1: Implementação no GitHub Actions

O núcleo da automação fica no GitHub Actions. Criei um workflow que permite execução agendada (cron) e acionamento manual (workflow_dispatch) para ambientes específicos.

Um desafio específico foi garantir que o binário do K6 estivesse corretamente instalado e disponível no PATH. Usar a action oficial grafana/setup-k6-action foi a solução mais confiável.

Aqui está a configuração essencial do arquivo de workflow .github/workflows/load-tests.yml:

name: K6 Load Tests

on:
    schedule:
        - cron: '0 0 * * 5' # Toda sexta-feira à meia-noite
    workflow_dispatch:
        inputs:
            environment:
                type: choice
                options: 
                    - staging
                    - production
            test_type:
                type: choice
                options: 
                    - smoke
                    - load

jobs:
    run-tests:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v4

            - name: Setup k6
                uses: grafana/setup-k6-action@v1

            - name: Run K6 Test
                run: k6 run --out opentelemetry tests/${{ inputs.test_type }}/test.js
                env:
                    K6_OTEL_EXPORTER_TYPE: http
                    K6_OTEL_HTTP_EXPORTER_ENDPOINT: ${{ vars.OTEL_COLLECTOR_ENDPOINT }}

Passo 2: Integração com OpenTelemetry

Esta foi a parte mais crítica da configuração. Integrar o K6 com nosso OpenTelemetry Collector exigiu configurações específicas para garantir que as métricas viajassem do runner do GitHub Action para nosso collector e, finalmente, para o Prometheus.

O suporte nativo do K6 ao OTel é excelente, mas nuances de configuração importam.

Configuração do protocolo

Precisei definir explicitamente o tipo do exporter para http porque o collector escuta na porta 4318 para payloads HTTP/OTLP. Por padrão, algumas ferramentas assumem gRPC (porta 4317).

env:
    K6_OTEL_EXPORTER_TYPE: http
    K6_OTEL_HTTP_EXPORTER_ENDPOINT: ${{ vars.OTEL_COLLECTOR_ENDPOINT }}
    K6_OTEL_EXPORTER_INSECURE: true

A variável de endpoint geralmente é algo como seu-domínio.com:4318. O K6 adiciona o protocolo/caminho correto se configurado apropriadamente, mas aprendi que K6_OTEL_HTTP_EXPORTER_ENDPOINT é a variável específica quando o tipo é http, enquanto K6_OTEL_EXPORTER_ENDPOINT costuma ser usada para gRPC ou defaults genéricos.

Atributos de recurso e filtragem

Em um ambiente de observabilidade compartilhado, taguear suas métricas é obrigatório. Nosso collector descarta qualquer métrica que não contenha um client_id específico. Resolvi isso injetando K6_OTEL_RESOURCE_ATTRIBUTES diretamente no pipeline:

K6_OTEL_RESOURCE_ATTRIBUTES: client_id=test3,environment=${{ matrix.environment }},service_name=k6-load-tests

Isso garante que, ao consultar k6_http_req_duration no Grafana, eu possa filtrar exatamente pela execução do teste e ambiente.

Passo 3: Simulação local com Act

Testar workflows do GitHub Actions cometendo e dando push com mensagens "fix ci" é tedioso. Integrei o act para simular o ambiente do GitHub Actions localmente.

Criando um arquivo simples de payload de evento dispatch-event.json, pude verificar o comportamento exato da injeção de variáveis de ambiente e da execução do comando K6 sem sair do terminal:

act workflow_dispatch -e .github/dispatch-event.json -W .github/workflows/load-tests.yml

Isso economizou horas de depuração, especialmente ao ajustar as variáveis de ambiente do OTel.

Conclusão

Ao combinar K6, GitHub Actions e OpenTelemetry, implementei um sistema onde o desempenho é monitorado como a saúde da aplicação.

Automação: Não há mais execução manual dos testes de carga.
Visibilidade: Métricas estão no mesmo dashboard que as métricas da aplicação.
Depuração: Testes locais com act garantem que o pipeline permaneça estável.

Se for montar testes de carga, recomendo priorizar o aspecto de observabilidade desde cedo. Ver gráficos em tempo real de Virtual Users (VUs) e Duração de Requisições ao lado do uso de CPU do servidor oferece insights que um relatório local isolado nunca proporciona.

Economia não é sorte, é automação. Veja como monitorei custos na AWS com Terraform.

Marcos Vilela — Tue, 03 Feb 2026 12:09:13 +0000

Automatizando FinOps na AWS: Como construímos um módulo de Monitoramento de Custos com Terraform e incident.io

Marcos Vilela ・ Feb 3

#finops #aws #terraform #iac

A /home encheu? Como usei Block Storage para expandir o armazenamento sem dor.

Marcos Vilela — Tue, 03 Feb 2026 12:07:59 +0000

Marcos Vilela

Nov 6 '24

Como expandi o armazenamento da minha pasta /home com Block Storage

#beginners #linux #blockstorage #braziliandevs

Comments

4 min read

A /home encheu? Como usei Block Storage para expandir o armazenamento sem dor

Marcos Vilela — Tue, 03 Feb 2026 12:06:56 +0000

Marcos Vilela

Nov 6 '24

Como expandi o armazenamento da minha pasta /home com Block Storage

#beginners #linux #blockstorage #braziliandevs

Comments

4 min read

Automatizando FinOps na AWS: Como construímos um módulo de Monitoramento de Custos com Terraform e incident.io

Marcos Vilela — Tue, 03 Feb 2026 12:03:52 +0000

Gerenciar custos em nuvem e um desafio constante para equipes de engenharia. A disciplina de FinOps busca trazer visibilidade e accountability para esses gastos, mas sem as ferramentas certas, e fácil ser surpreendido pela fatura no final do mês.

Neste artigo, compartilho a experiência e os detalhes técnicos da criação de um módulo Terraform reutilizável para automatizar alertas de orçamento na AWS, integrando diretamente com ferramentas de resposta a incidentes (neste caso, o incident.io), eliminando intermediários desnecessários como funções Lambda para esse fim específico.

O Problema

Precisávamos de uma maneira padronizada de criar "guardrails" financeiros para novos projetos. Toda nova conta ou ambiente (staging, production) na AWS deveria nascer com um orçamento definido e um canal de alerta configurado.

Os requisitos eram:

Definir um limite mensal em dólares.
Alertar quando o gasto real atingir certas porcentagens (ex: 80%, 100%).
Alertar quando a previsão (forecast) indicar que o orçamento será estourado.
Enviar esses alertas para nossa plataforma de gerenciamento de incidentes.
Ser seguro (dados criptografados em repouso).

A Arquitetura Simplificada

Inicialmente, considerou-se usar AWS Lambda para processar os alertas do AWS Budgets e formatar o JSON para o webhook. No entanto, percebemos que poderíamos simplificar a arquitetura utilizando a capacidade nativa do SNS de realizar chamadas HTTPS (Webhooks).

O fluxo ficou assim:
AWS Budgets -> SNS Topic (Criptografado) -> HTTP POST -> Incident.io

Essa abordagem reduz a complexidade operacional (menos código para manter) e o custo.

A Implementação com Terraform

Abaixo, detalho as partes cruciais do módulo, focando em como resolvemos os desafios de segurança e flexibilidade.

1. Segurança Primeiro: Criptografia KMS

O AWS SNS suporta criptografia de dados (Server-Side Encryption). Para ambientes corporativos, isso não é opcional. No entanto, usar uma chave KMS gerenciada pelo cliente (CMK) requer politicas de acesso especificas para permitir que o serviço de AWS Budgets (que é um serviço global) chame um recurso regional e use a chave para criptografar a mensagem antes de enviá-la ao tópico.

resource "aws_kms_key" "cost_alerts_key" {
  description             = "KMS key for encrypting FinOps SNS topics"
  deletion_window_in_days = 10
  enable_key_rotation     = true

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "Enable IAM User Permissions"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::${local.account_id}:root"
        }
        Action   = "kms:*"
        Resource = "*"
      },
      {
        Sid    = "Allow AWS Budgets to use the key"
        Effect = "Allow"
        Principal = {
          Service = "budgets.amazonaws.com"
        }
        Action = [
          "kms:GenerateDataKey*",
          "kms:Decrypt"
        ]
        Resource = "*"
      }
    ]
  })
}

Observe a permissão explicita para budgets.amazonaws.com. Sem isso, o orçamento falha silenciosamente ao tentar publicar no tópico.

2. O Tópico SNS e a política de Publicação

O tópico SNS atua como o roteador. Além de criar o tópico, precisamos de uma aws_sns_topic_policy para autorizar o serviço de orçamento a publicar nele.

resource "aws_sns_topic" "cost_alerts" {
  name_prefix       = "${local.name_prefix}-cost-alerts-"
  kms_master_key_id = aws_kms_key.cost_alerts_key.arn
}

resource "aws_sns_topic_policy" "default" {
  arn = aws_sns_topic.cost_alerts.arn
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "AWSBudgets-Publish"
        Effect = "Allow"
        Principal = {
          Service = "budgets.amazonaws.com"
        }
        Action   = "SNS:Publish"
        Resource = aws_sns_topic.cost_alerts.arn
      }
    ]
  })
}

3. Flexibilidade com Dynamic Blocks

Um dos maiores desafios ao criar módulos reutilizáveis e atender as diferentes necessidades de notificação de cada time. Alguns querem alertas aos 50%, outros apenas aos 100%.

Utilizamos o recurso dynamic do Terraform para gerar as configurações de notificação com base em uma lista de objetos fornecida via variável.

resource "aws_budgets_budget" "cost_budget" {
  name              = "${local.name_prefix}-budget"
  budget_type       = "COST"
  limit_amount      = var.limit_amount
  limit_unit        = var.limit_unit
  time_period_start = "2024-01-01_00:00"
  time_unit         = var.time_unit

  # Bloco dinamico para notificacoes
  dynamic "notification" {
    for_each = var.notifications
    content {
      comparison_operator       = notification.value.comparison_operator
      threshold                 = notification.value.threshold
      threshold_type            = notification.value.threshold_type
      notification_type         = notification.value.notification_type
      subscriber_sns_topic_arns = [aws_sns_topic.cost_alerts.arn]
    }
  }
}

Isso permite que o consumidor do module configure alertas de forma declarativa e simples no arquivo .tfvars:

notifications = [
  {
    comparison_operator = "GREATER_THAN"
    threshold           = 80
    threshold_type      = "PERCENTAGE"
    notification_type   = "ACTUAL"
  },
  {
    comparison_operator = "GREATER_THAN"
    threshold           = 100
    threshold_type      = "PERCENTAGE"
    notification_type   = "FORECASTED"
  }
]

4. Integração via Webhook (A Parte "Chata")

A integração final e feita via uma assinatura SNS com protocolo HTTPS:

resource "aws_sns_topic_subscription" "incident_io" {
  topic_arn = aws_sns_topic.cost_alerts.arn
  protocol  = "https" # Detectado dinamicamente no codigo real
  endpoint  = var.incident_io_webhook_url
}

O Desafio da Confirmação da Assinatura:
Diferente de Lambda ou SQS, endpoints HTTP/HTTPS requerem uma confirmação de assinatura. O SNS envia um POST inicial com uma URL de confirmação.
Como estamos usando uma ferramenta de terceiros (incident.io), não temos controle direto para clicar programaticamente nesse link.

A solução adotada foi processual:

O Terraform aplica a infraestrutura.
O estado da assinatura fica como "PendingConfirmation".
O administrador acessa os logs do incident.io, localiza a mensagem de SubscriptionConfirmation e clica no link manualmente.

Embora não seja 100% automatizado (zero-touch), e um compromisso aceitável para uma configuração que ocorre apenas uma vez por ambiente.

Conclusão

Criar módulos de infraestrutura como código para FinOps e essencial para escalar o uso da nuvem de forma responsável. Ao centralizar a lógica de orçamentos, criptografia e notificações em um único modulo, garantimos que todos os ambientes seguem as melhores praticas de segurança e observabilidade financeira.

A escolha de remover camadas intermediarias (como Lambdas) simplificou a stack, tornando-a mais robusta e fácil de manter a longo prazo.

Reestudando sua infraestrutura

Marcos Vilela — Tue, 27 Jan 2026 17:30:47 +0000

Recentemente, parei para rever/revisar o IaC de infra/redes e sua infraestrutura aplicada, de um ecossistema de uma fintech (que chamaremos aqui de GlobalPay). O objetivo era avaliar a postura de segurança de seus apps diferentes que compõem o produto principal.

O que parecia ser uma varredura de rotina revelou uma lição valiosa: a segurança não é apenas um problema técnico, mas um desafio de governança e automação e também, revisão.

Aqui estão os principais aprendizados para quem trabalha com DevOps, Cloud e Segurança de Aplicações que pude tirar reestudando meu próprio código.

1. O perigo dos Templates de IaC Inadequados

Um dos achados mais curiosos foi que nos apps analisados apresentavam exatamente a mesma falha: a fuga de nomes internos de Load Balancers de staging e regiões da no cabeçalho Location de redirecionamentos HTTP.

O aprendizado: Quando usamos ferramentas como Terraform ou CloudFormation, um erro no template original é replicado em escala. Adversários usam essas informações para mapear ambientes de teste, que geralmente possuem controles de segurança menos rigorosos.

2. A Inconsistência é o seu maior inimigo

Durante a minha análise, encontramos um cenário de "dois mundos". Enquanto um app apresentava uma postura exemplar (o nosso benchmark), com HSTS, CSP e X-Frame-Options configurados corretamente, os apps adjacentes — teoricamente mais sensíveis — não possuíam poucos desses controles.

A lição: A segurança não pode ser seletiva. A falta de uma baseline mínima obrigatória centralizada faz com que cada time de desenvolvimento implemente sua própria versão de "segurança", criando buracos previsíveis no perímetro.

3. Vulnerabilidades "Clássicas" ainda derrubam gigantes

Identificamos uma vulnerabilidade ao ataque Slowloris DoS (CVE-2007-6750) em um dos endpoints. É uma falha de 2009 que ainda assombra ambientes que não configuram corretamente os timeouts de conexão em seus Load Balancers ou WAFs.

Além disso, o Bypass de Rate Limit no endpoint de autenticação foi classificado como crítico. Sem um limite rigoroso, a aplicação fica exposta a ataques de Account Takeover (ATO) via Credential Stuffing.

4. Hardening de Borda: Mais que apenas HTTPS

Muitos desenvolvedores acreditam que subir um certificado SSL/TLS é o suficiente. No entanto, a análise revelou que:

CORS Permissivo: Configurações de access-control-allow-origin: * (wildcard) em APIs financeiras permitem que qualquer site malicioso faça requisições em nome de usuários autenticados.
Fingerprinting de Tecnologia: Manter o cabeçalho X-Powered-By: Express facilita a vida do atacante, que pode buscar exploits específicos para aquela versão do framework.
Segurança de Cabeçalhos: A ausência de cabeçalhos críticos (como CSP para evitar XSS e HSTS para forçar HTTPS) foi uma falha abrangente.

5. Do Manual para o "Security as Code"

A maior conclusão deste relato não foi sobre quais portas estavam abertas, mas sobre a ausência de validações automáticas em pipelines de CI/CD.

Se tivesse implementado verificações de segurança automatizadas, seria impossível um app chegar à produção sem os cabeçalhos obrigatórios ou com políticas de CORS abertas.

Conclusão: O Projeto Arquitetônico Digital

A infraestrutura de uma empresa é como um edifício residencial. Não adianta o andar de investimentos ter portas blindadas se o andar de gestão de contas foi construído com janelas que não trancam.

A solução definitiva para os problemas encontrados não é consertar cada domínio manualmente, mas atualizar o único projeto arquitetônico digital (os templates de IaC) e garantir que cada novo andar construído siga o mesmo padrão de segurança máxima desde o alicerce.

Produtividade no Terminal: O Poder dos Aliases no Linux

Marcos Vilela — Tue, 13 Jan 2026 11:46:53 +0000

Se você utiliza a linha de comando diariamente, já deve ter percebido que passamos boa parte do tempo digitando os mesmos comandos repetidamente. Seja para limpar o cache do Docker, realizar um deploy ou formatar uma string, a repetição é a inimiga da eficiência. É aqui que entram os aliases do Linux.

O que são Aliases?

De forma simplificada, um alias é um apelido ou um atalho para um comando mais longo e complexo. Eles funcionam como substituições de texto no seu shell (Bash ou Zsh). Em vez de digitar uma sequência de 50 caracteres, você pode definir uma palavra de quatro letras que executa exatamente a mesma função.

Por que utilizar?

Redução de erros de digitação: Comandos complexos com muitas flags são propensos a erros.

Padronização: Você pode criar um fluxo de trabalho padrão para sua equipe ou para seus diferentes projetos.

Velocidade: A economia de segundos em cada comando se traduz em horas de produtividade ao final de um mês.

Exemplos simples mas práticos de uso

Gerenciamento de Infraestrutura Quem trabalha com Docker sabe que resíduos de contêineres e redes podem consumir gigabytes de memória rapidamente. Um alias de limpeza pode ser um grande aliado, o que costumo utilizar:

alias docker-prune-all="docker system prune --all --volumes -f"

Normalização de Strings Muitas vezes precisamos renomear arquivos removendo espaços, acentos e transformando tudo em minúsculas. Uma função no seu arquivo de perfil pode automatizar isso, esse me ajuda a normalizar frases que posso utilizar na criação de branchs:

normaliza() {
  echo "$*" | iconv -f utf8 -t ascii//TRANSLIT | tr "[:upper:]" "[:lower:]" | sed "s/ /-/g"
}

Lembretes de Workflow Se o seu processo de merge e deploy envolve muitos passos manuais, você pode criar um alias que apenas imprime o passo a passo na tela, servindo como um guia rápido, como um man de algum software/função:

alias deploy-help='echo -e "1. git pull\n2. npm run build\n3. dep deploy stage"'

Como configurar

Para tornar seus aliases permanentes, você deve adicioná-los ao arquivo de configuração do seu shell, geralmente o .bashrc ou .zshrc, localizados na pasta raiz do seu usuário (~/).

Uma boa prática é manter seus aliases em um arquivo separado chamado .bash_aliases e apenas o chamar dentro do seu arquivo principal. Isso mantém suas configurações organizadas e fáceis de transportar para outras máquinas.

Aliases não são apenas sobre digitar menos, são sobre criar um ambiente de trabalho que se adapta às suas necessidades. Ao identificar padrões no seu dia a dia e automatizá-los, você libera espaço mental para focar no que realmente importa: a solução dos problemas e o desenvolvimento de código de qualidade.

Forem: Marcos Vilela

Quando o Banco Não Caiu: Um Incidente de Conexão Que Expôs um Problema de Resiliência na Aplicação

Contexto do Incidente

Primeira Hipótese: Banco Instável?

Evidências coletadas

Mudança de Foco: Aplicação

Análise do Código

Causa Raiz

Ação Corretiva Imediata

Lições Arquiteturais

Conclusão

Criando uma Composite Actions para utilizar em do CI/CD do GitHub

Por que uma composite action?

Estrutura do repositório

Exemplo de action.yml

Collector em TypeScript

Integração com CI/CD

Demo local com act

Casos de uso

Arquitetura definida

Tolerância a falhas

Publicando e versionando

Conclusão

Shared Workflows: minha experiência definindo pipelines reutilizáveis

Problema e motivação

Abordagem

Trechos de consumo (exemplos)

Decisões arquiteturais chave

Aprendizados e recomendações

Riscos & mitigação

Conclusão

[Boost]

Reestudando sua infraestrutura

Marcos Vilela ・ Jan 27

Template de testes de API com K6

Por que escolhi o k6

Estrutura do projeto

Configuração e precedência de variáveis

Autenticação reutilizável

Checks e thresholds

Relatórios

Observability: Prometheus + Grafana

Integração com CI (GitHub Actions)

Boas práticas que segui

Problemas que enfrentei e como resolvi

Exemplo mínimo pronto para copiar

Conclusão

Como integrei testes de carga com K6, GitHub Actions e OpenTelemetry

O Problema

Por que o K6?

Estrutura do caso de uso

Passo 1: Implementação no GitHub Actions

Passo 2: Integração com OpenTelemetry

Configuração do protocolo

Atributos de recurso e filtragem

Passo 3: Simulação local com Act

Conclusão

Economia não é sorte, é automação. Veja como monitorei custos na AWS com Terraform.

Automatizando FinOps na AWS: Como construímos um módulo de Monitoramento de Custos com Terraform e incident.io

Marcos Vilela ・ Feb 3

A /home encheu? Como usei Block Storage para expandir o armazenamento sem dor.

Como expandi o armazenamento da minha pasta /home com Block Storage

A /home encheu? Como usei Block Storage para expandir o armazenamento sem dor

Como expandi o armazenamento da minha pasta /home com Block Storage

Automatizando FinOps na AWS: Como construímos um módulo de Monitoramento de Custos com Terraform e incident.io

O Problema

A Arquitetura Simplificada

A Implementação com Terraform

1. Segurança Primeiro: Criptografia KMS

2. O Tópico SNS e a política de Publicação

3. Flexibilidade com Dynamic Blocks

4. Integração via Webhook (A Parte "Chata")

Conclusão

Reestudando sua infraestrutura

1. O perigo dos Templates de IaC Inadequados

2. A Inconsistência é o seu maior inimigo

3. Vulnerabilidades "Clássicas" ainda derrubam gigantes

4. Hardening de Borda: Mais que apenas HTTPS

5. Do Manual para o "Security as Code"

Conclusão: O Projeto Arquitetônico Digital

Exemplo de `action.yml`

Demo local com `act`