Como evitar noites sem dormir, garantir que seu time consiga respirar durante incidentes e deixar o SRE do seu time feliz!
Conteúdo:
1. Índices com Concorrência: Seu SRE vai te amar <3!
- O Problema:
Imagine criar um índice em uma tabela de 500 GB em pleno horário de pico. O banco trava, as requisições começam a falhar, e o celular do SRE vibra sem parar com alertas de downtime. Ninguém quer ser essa pessoa.
- A Solução:
Use CREATE INDEX CONCURRENTLY (PostgreSQL) ou ferramentas como pt-online-schema-change (MySQL). Isso permite criar índices sem bloquear operações de escrita.
-- Exemplo no PostgreSQL: o SRE continua dormindo
CREATE INDEX CONCURRENTLY idx_pedidos_cliente ON pedidos (cliente_id);
2. Performance Insights: O "Raio-X" das Queries Lentas <3!
- O Problema:
Uma query mal otimizada consome 90% da CPU do banco. O time de desenvolvimento não sabe por onde começar, e o SRE fica no escuro, tentando adivinhar o culpado.
- A Solução:
Ative o Performance Insights no RDS. Ele mostra em tempo real:
- Queries que consomem mais CPU.
- Eventos de espera (ex: I/O, locks).
- Queries com maior latência.
Como isso Ajuda o SRE?
Diagnóstico Rápido: Identifique o problema em minutos, não em horas.
Prevenção: Antecipa gargalos antes que virmem incidentes.
Colaboração com Devs: Mostra dados concretos facilitando melhorias em conjunto.
3. Não use o Root: A arte de não ficar refém
- O Problema:
A aplicação está usando o usuário root e, durante um pico de tráfego, a CPU chega a 100%. Agora, ninguém consegue conectar ao banco para investigar… e o caos se instala.
O RDS tem um número máximo de conexões permitidas, definido pelo parâmetro max_connections (ex: PostgreSQL) ou max_user_connections (MySQL).
Se a aplicação já está usando todas as conexões disponíveis (ou a maioria), novas tentativas de login são bloqueadas — inclusive as do SRE. Ou seja, o usuário root é para privilégios maiores e emergências.
- A Solução:
Crie um usuário dedicado para a aplicação, com permissões mínimas:
-- Exemplo no PostgreSQL:
CREATE USER app_user WITH PASSWORD 'senhaSuperF0rt3!';
GRANT SELECT, INSERT ON tabela_principal TO app_user;
Como isso Ajuda o SRE?
Acesso Garantido em Crise: Mesmo se a aplicação derrubar o banco, o SRE pode conectar com uma conta privilegiada para mitigar o problema.
Segurança sem Sacrifício: Reduza o risco de ataques e de acidentes (ex: DROP TABLE acidental por um microsserviço com privilégios demais).
Essas são as dicas de hoje, são apenas 3 mas quebram MUITO o galho!
well-architected
Site Reliability Engineering (Google Livro)
Top comments (0)