Oct 22, 2014
SITUAÇÃO ATUAL
2
“SIMPLES E DE FÁCIL MANUTENÇÃO”
3
“ISSO FICA PARA A SEGUNDA ENTREGA”
4
PLANNINGO começo
5
O COMEÇO
• “É fácil, está pronto na minha maquina”
• “Só fazer um serviço que responde <...>”
• “Colocamos tudo junto para facilitar”
• “Isso fica para a segunda entrega”
• “Depois a gente arruma”
• “Criamos uma <...> a mais no banco”
6
O QUE FAZER?
7
COMPONENTES
8
COMPONENTES
• “Um sistema é um sistema, outro sistema é outro sistema”
• Automação para criar o ambiente
• Ferramentas/Linguagens mais produtivas
• Isolar problemas e tornar serviços assíncronos
9
COMPONENTES
• Benefícios a longo prazo
• Flexibilidade para operação na alocação de recursos
• “code outlives its [developers] intentions”
• “All software is permanent”
10
LOGS
11
LOGS
• Logar tudo
• Log Driven Development
• Logs devem ser evidências de teste
• Syslog
• Formato padrão
• “Vou olhar no código...”
12
LOGS
• Stack trace não é log
• Identificador único de transação
• Vários níveis de log
• Em português
• Log deve de ser parte do desenvolvimento, não algo a ser acrescentado depois
13
DEPLOY
14
DEPLOY
• “É só pegar do <...> e jogar lá”
• Aplicação deve ser construída pensando no deploy
• Resolver dependências/requisitos sem criar conflitos com o repositório da distribuição
• Scripts de inicialização, rotacionar logs, etc
• Servidores de produção não tem acesso a internet
15
DEPLOY
• Evitar permissões incorretas
• Evitar arquivos em caminhos errados
• Evitar pacotes/arquivos desnecessários em produção
• Evitar versões diferentes dos mesmos módulos em caminhos diferentes
• Criar pacotes
16
TESTES
17
TESTES
•Máquinas de homologação e desenvolvimento na monitoração
• Usar gráficos de monitoração como evidência de teste
•Documentar para que outros possam reproduzir seu resultado
18
TESTES
• Tempo de teste
• Testar o que não funciona
• Testar com componentes fora do ar
•Quantidade de requests esperados em produção?
19
TESTES
• TCPDump
•Número de requests X Requests simultâneos
• Evidências de teste
•Métricas úteis, ex: tempo de resposta ao invés de CPU Idle
20
SEGURANÇA
21
SEGURANÇA
• Nunca rodar como ROOT
• Nunca colocar no sistema de versionamento informações como: credencias de acesso, logins, senhas, API Keys, etc
• Separação em componentes = Liberdade para Operação utilizar redes distintas
• Logs de auditoria, se necessários
• Regra de Apache != ACL
22
BANCO DE DADOS
23
BANCO DE DADOS
• Utilizar da melhor forma possível, não porque “é mais fácil”
• Separar leitura e escrita
• Utilizar o banco relacional para o que ele faz melhor: integridade e transação
• Envolver AD no projeto
• Stored procedure?
24
BANCO DE DADOS
• Usar ORM para tudo? (Black Magic)
•Otimizar query. Se o ORM não permitir... você está fazendo errado!
• Sua aplicação deve se adaptar ao modelo de dados
• Índices
• Atenção com colunas “auto increment” + replicação do MySQL
25
BANCO DE DADOS
• Alternar automaticamente para um banco de Stand-by
• Reconectar automaticamente
• Usar filas, o banco falha!
• Cache e Replicação: “The good, the bad and the ugly”
• “Architectural anti-patterns for data handling” - http://www.slideshare.net/gleicon
26
CONFIGURAÇÕES
27
CONFIGURAÇÕES
• Fora do jar, war, egg, gem...
• Possibilita automação
• Possibilita auditoria
• Possibilita versionamento
• Flexibilidade para operação
28
BACKUP
29
BACKUP
• “Minha aplicação precisa de backup”
•Qual a finalidade? Desastre? Restaurar um único registro?
• Teste de restore
• Segurança
• Tempo de retenção e vida útil da mídia
• dump/restore dentro da aplicação
30
FALHAS
31
FALHAS
• Falha elegante e rápida
• Apresentar menos funcionalidade ao invés de “Erro 500”
• Recuperação automática
• Conectar em múltiplos backend
•Distribuir carga
32
BALANCEAMENTO DE CARGA
33
BALANCEAMENTO DE CARGA
• Aplicações que respondam ao teste do SLB
• /status => 200
• Possibilita testar uma máquina sem que ela esteja ativa para o SLB
• Entender os algoritmos disponíveis
34
INTERFACE PARA OPERAÇÃO
35
INTERFACE PARA OPERAÇÃO
• REST + JSON
• Ferramenta CLI
• Limpar cache
• Reconectar no banco
36
INTERFACE PARA OPERAÇÃO
• Controlar processamento de fila
• Colocar aplicação em “read-only”
• Controlar recebimento de requests
• Controlar o /status
37
MONITORAÇÃO
38
MONITORAÇÃO
• REST + JSON
• Ferramenta CLI
• Versão da aplicação e das dependências
• Conexões com backend, banco, cache, uptime, etc
• /monit
39
MONITORAÇÃO
• Usuários ativos
•Operações com erro, sucesso, etc
• Tempo das operações: média e desvio padrão
• Tipos de requisição: get, post, etc
•Número de itens na fila, tempo de processamento, etc
40
EU NÃO PRECISO SABER...
41
VOCÊ PRECISA SABER QUE:
• Existe um sistema operacional embaixo do software
• Existe rede e storage fora do software
• “System” e similares somente em situações extremas ou de licença
• “Eu programo em <...>, roda em qualquer coisa”
•Memória, processamento e disco são recursos finitos
42
DICAS
• “Bringing a knife to a gunfight”
• Você define os requisitos
• “Quando você só tem martelo, tudo é prego”
• Framework?
•O universo conspira contra você
43
DICAS
•Discos mentem
•Memória mente
•Máquinas falham
• VM’s mentem mais ainda
• “Diminishing returns“
44
DICAS
• Gerar logs se a aplicação permitir, antes do restart
• Apagar incêndio = restart
• Testes simples: ping, date, route, dig e df identificam a maior parte dos problemas
45
PERGUNTAS?
46