Componentes de infraestrutura usados em serviços bancários
Infraestrutura é o conjunto de recursos (computação, rede, armazenamento e serviços de suporte) que permite que aplicações bancárias funcionem com desempenho, segurança e disponibilidade. Na prática, o Agente de Tecnologia precisa entender como esses componentes se conectam para diagnosticar lentidão, erros e indisponibilidades.
Servidores (compute)
Servidor é o recurso de processamento e memória onde rodam aplicações, APIs, jobs e serviços de apoio. Pode ser físico, máquina virtual ou contêiner, mas conceitualmente sempre entrega CPU, RAM e acesso a rede e disco.
- Escala vertical: aumentar CPU/RAM do mesmo servidor (rápido, mas tem limite).
- Escala horizontal: adicionar mais instâncias (melhor para alta disponibilidade e picos).
- Capacidade: CPU alta pode indicar carga real, loop, GC, criptografia intensa; memória alta pode indicar cache, vazamento, filas internas.
Storage (armazenamento)
Storage é onde dados persistem. Em bancos, a performance do armazenamento impacta diretamente transações, conciliações, extratos e relatórios. Conceitualmente, observe dois eixos: latência (tempo de resposta) e IOPS/throughput (quantidade de operações/volume por segundo).
- Bloco: discos para sistemas e bancos (bom para baixa latência).
- Arquivo: compartilhamento de arquivos (logs, artefatos, integrações legadas).
- Objeto: grandes volumes e durabilidade (backups, documentos, evidências).
Sintomas comuns: latência de disco alta pode causar timeouts na aplicação e aumento de tempo de resposta mesmo com CPU baixa.
Balanceamento de carga (load balancer)
Balanceador distribui requisições entre instâncias de um serviço para melhorar disponibilidade e desempenho. Também pode encerrar TLS, aplicar regras de roteamento e checagens de saúde.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
- Health check: define se uma instância está apta a receber tráfego.
- Algoritmos: round-robin, least connections, hash por sessão.
- Sticky session: prende o cliente a uma instância; pode ser necessário em legados, mas reduz elasticidade.
Proxies e gateways
Proxy é um intermediário que encaminha tráfego. Gateway é um ponto de entrada controlado para serviços, aplicando políticas. Em ambientes bancários, é comum separar responsabilidades:
- Reverse proxy: recebe requisições externas e encaminha para serviços internos (pode cachear, comprimir, limitar taxa).
- API Gateway: centraliza autenticação/autorização, rate limit, roteamento por versão, transformação de payload e observabilidade.
- Gateway de integração: padroniza comunicação com sistemas internos/legados e parceiros.
Falhas típicas: configuração de rota errada, limite de conexões, certificados expirados, regras de firewall/ACL bloqueando tráfego.
Filas e mensageria
Filas e mensageria desacoplam sistemas: em vez de um serviço depender de resposta imediata do outro, ele publica uma mensagem e o consumidor processa no seu ritmo. Isso é crucial para absorver picos (ex.: folha, pagamentos, loterias, virada do dia) e reduzir impacto de instabilidades.
- Fila: modelo ponto-a-ponto; cada mensagem é consumida por um consumidor.
- Pub/Sub (tópicos): um produtor publica e vários consumidores recebem.
- Garantias: at-most-once, at-least-once, exactly-once (na prática, exige idempotência).
- DLQ: fila de mensagens com erro para análise e reprocessamento controlado.
Sintomas comuns: aumento de lag (atraso) indica consumidores lentos, indisponíveis ou mensagens “presas” por erro; pode gerar efeito cascata (acúmulo, timeouts e degradação).
Alta disponibilidade, tolerância a falhas e continuidade
Alta disponibilidade (HA)
Alta disponibilidade é a capacidade de manter o serviço acessível apesar de falhas. Em termos conceituais, busca-se eliminar pontos únicos de falha e permitir substituição automática de componentes.
- Redundância: múltiplas instâncias, múltiplas zonas, múltiplos links.
- Failover: troca automática para instância/ambiente saudável.
- Health checks e auto-healing: remover instâncias ruins e repor novas.
Tolerância a falhas
Tolerância a falhas é continuar operando mesmo quando parte do sistema falha, possivelmente com degradação controlada. Exemplos práticos em serviços bancários:
- Degradação graciosa: extrato detalhado indisponível, mas saldo e últimas transações continuam.
- Timeouts e retries com backoff: evita travar o sistema inteiro quando um downstream está lento.
- Circuit breaker: interrompe chamadas a um serviço instável para proteger o restante.
Continuidade (resiliência operacional)
Continuidade trata de manter ou recuperar serviços após incidentes maiores (falha de datacenter, indisponibilidade prolongada, corrupção de dados). Conceitos essenciais:
- RTO (Recovery Time Objective): tempo máximo aceitável para recuperar.
- RPO (Recovery Point Objective): perda máxima aceitável de dados (janela de backup/replicação).
- DR (Disaster Recovery): estratégia e ambiente para recuperação.
Conexão com cenários bancários: indisponibilidade em canais digitais pode gerar filas de atendimento, impacto reputacional e risco operacional. Por isso, além de “voltar”, é importante voltar com integridade (consistência de transações) e com comunicação clara para áreas de negócio.
Monitoramento e observabilidade: métricas, logs e traces
Monitoramento responde “o que está acontecendo?” com indicadores e alertas. Observabilidade vai além: ajuda a entender “por que está acontecendo?” a partir de evidências correlacionadas. O tripé é métricas, logs e traces.
Métricas
Métricas são séries temporais numéricas (ex.: latência p95, taxa de erro, CPU). Boas métricas permitem alertas objetivos e leitura rápida de saúde.
- Golden Signals: latência, tráfego, erros, saturação.
- RED (serviços): Rate (taxa), Errors (erros), Duration (duração).
- USE (infra): Utilization, Saturation, Errors.
Logs
Logs são eventos textuais/estruturados com contexto (timestamp, serviço, correlação, usuário/conta mascarados, código de erro). Em incidentes, logs ajudam a localizar o ponto de falha (ex.: exceção, timeout, validação).
- Estruturados: JSON com campos (facilita filtro e agregação).
- Níveis: INFO, WARN, ERROR; excesso de DEBUG pode degradar performance.
- Correlação: incluir um correlation-id para seguir uma requisição ponta a ponta.
Traces (rastreamento distribuído)
Traces mostram o caminho de uma requisição por múltiplos serviços e o tempo gasto em cada etapa (spans). São essenciais quando a lentidão não está em um único ponto.
- Span: etapa individual (ex.: chamada ao banco, chamada a API externa).
- Trace: conjunto de spans da mesma requisição.
- Identificação de gargalos: qual dependência está consumindo mais tempo.
SLAs, SLOs e gestão de incidentes
SLA e SLO
SLA (Service Level Agreement) é o compromisso formal de nível de serviço (ex.: disponibilidade mensal). SLO (Service Level Objective) é a meta interna mensurável que orienta engenharia e operação. Um SLO bem definido evita alertas “barulhentos” e foca no que importa ao usuário.
- Indicador (SLI): métrica que mede o serviço (ex.: % de requisições com sucesso, latência p95).
- SLO: alvo para o SLI (ex.: 99,9% de sucesso no mês).
- Error budget: margem de falha aceitável; se estoura, prioriza-se estabilidade.
Gestão de incidentes (visão prática)
Incidente é qualquer degradação relevante do serviço. Um fluxo típico envolve: detecção, triagem, mitigação, comunicação e análise de causa raiz.
- Detecção: alertas por SLO/SLI e sinais (picos de erro, latência).
- Triagem: classificar severidade e escopo (quais canais, quais regiões, quantos usuários).
- Mitigação: reduzir impacto rapidamente (rollback, desativar feature, aumentar capacidade, isolar dependência).
- Comunicação: atualizações periódicas para stakeholders e registro do que foi feito.
- RCA (causa raiz) e ações: corrigir e prevenir recorrência (runbooks, testes, limites, observabilidade).
Passo a passo: como ler um painel de monitoramento em incidentes
O objetivo é sair do sintoma (ex.: “app fora”) para uma hipótese provável (rede, aplicação, banco de dados, mensageria) usando evidências.
Passo 1: confirme o impacto no usuário
- Verifique taxa de sucesso (HTTP 2xx/3xx) e taxa de erro (4xx/5xx).
- Compare com o baseline (mesmo horário/dia da semana).
- Separe por rota/canal (login, saldo, pagamento) para identificar escopo.
Passo 2: identifique se é latência, erro ou saturação
- Latência subiu e erros ainda baixos: gargalo em dependência, fila interna, banco lento.
- Erros 5xx subiram: falha no serviço ou dependência indisponível.
- Saturação (CPU, memória, conexões, threads) subiu: falta de capacidade ou comportamento anômalo.
Passo 3: correlacione com infraestrutura
- CPU: alta sustentada pode indicar pico real, loop, criptografia intensa, compressão, ou GC.
- Memória: crescimento contínuo sugere vazamento; OOM pode derrubar instâncias.
- Rede: aumento de retransmissões/latência pode gerar timeouts e erros intermitentes.
- Disco/IO: latência de storage alta afeta banco e serviços que persistem dados.
Passo 4: verifique dependências (banco, cache, mensageria)
- Banco de dados: conexões saturadas, locks, filas de queries, latência de commit.
- Cache: queda do hit rate aumenta carga no banco e eleva latência.
- Fila: aumento de backlog/lag indica consumidores insuficientes ou erro de processamento.
Passo 5: use logs e traces para fechar a hipótese
- Nos logs, filtre pelo correlation-id e pelo período do pico.
- Procure padrões: timeouts, “connection refused”, “too many connections”, exceções de validação.
- Nos traces, identifique o span mais lento (ex.: chamada ao banco ou a um serviço externo).
Exercícios: leitura de painéis e identificação de causas prováveis
Exercício 1: pico de latência com CPU baixa
Cenário do painel: latência p95 do serviço de pagamentos subiu de 200 ms para 2,5 s; taxa de erro 5xx ainda baixa; CPU das instâncias em 25%; memória estável; tráfego normal.
Perguntas:
- Qual componente você investigaria primeiro: aplicação, rede ou banco de dados?
- Quais métricas adicionais buscaria para confirmar?
Indícios e causa provável:
- CPU baixa com latência alta sugere espera externa: banco de dados lento (locks, I/O alto), dependência externa lenta, ou rede com latência/retransmissão.
- Métricas úteis: latência de queries, pool de conexões, tempo de resposta do storage, retransmissões TCP, timeouts por dependência.
Exercício 2: aumento de 5xx e reinícios de instância
Cenário do painel: taxa de erro 5xx subiu para 8%; número de instâncias oscilando; eventos de reinício; memória cresce até o limite e cai após reinício; latência também aumenta.
Perguntas:
- Qual é a hipótese mais provável?
- Qual evidência em logs ajudaria a confirmar?
Indícios e causa provável:
- Padrão de memória crescendo e reinício indica vazamento de memória ou explosão de cache, levando a OOM e reinício automático.
- Logs: mensagens de OOM, GC excessivo, erros de alocação, aumento de payloads, endpoints específicos correlacionados.
Exercício 3: backlog em fila e timeouts no front
Cenário do painel: fila “processa-boletos” com lag crescente; consumidores com CPU alta; taxa de publicação normal; front-end começa a apresentar timeouts em consultas de status.
Perguntas:
- O problema está mais provável em rede, aplicação ou banco?
- Qual ação de mitigação imediata faz sentido?
Indícios e causa provável:
- Lag crescente com consumidores no limite sugere capacidade insuficiente de processamento ou mensagens mais pesadas/mais lentas (ex.: dependência do banco lenta).
- Mitigação: aumentar consumidores (escala horizontal), pausar funcionalidades não críticas que publicam mensagens, investigar dependência lenta do consumidor (banco/serviço externo).
Exercício 4: falha intermitente por rede
Cenário do painel: erros “connection reset” e “timeout” aparecem em picos; latência varia muito; CPU/memória normais; apenas uma zona/região apresenta problema; tráfego roteado pelo balanceador mostra queda de sucesso nessa zona.
Perguntas:
- Qual evidência aponta para rede?
- Que medida rápida reduz impacto ao usuário?
Indícios e causa provável:
- Intermitência concentrada em uma zona e erros de conexão sugerem problema de rede (link degradado, perda de pacotes, equipamento, rota).
- Mitigação: retirar a zona do balanceamento (drain), forçar failover para zonas saudáveis, abrir incidente com time de rede com métricas de perda/latência.
Checklist prático de diagnóstico (rede x aplicação x banco de dados)
Quando suspeitar de rede
- Erros intermitentes: timeout, connection reset, connection refused em picos.
- Problema concentrado por zona/região/segmento.
- Retransmissões e latência de rede aumentam antes dos erros.
Quando suspeitar de aplicação
- CPU alta, reinícios, exceções específicas em logs.
- Erro aumenta após deploy/feature flag.
- Fila interna de threads/conexões do serviço saturada.
Quando suspeitar de banco de dados
- Latência aumenta com CPU do app baixa e tempo gasto em spans de DB alto.
- Pool de conexões saturado, locks, aumento de tempo de commit.
- Storage com latência elevada e aumento de I/O wait.
// Exemplo de campos úteis em logs para correlação (conceitual){ "timestamp": "2026-01-15T10:12:33Z", "service": "pagamentos-api", "level": "ERROR", "correlation_id": "abc123", "route": "/pagamentos/confirmar", "error": "DB_TIMEOUT", "duration_ms": 2500, "downstream": "db-transacional"}
