Este documento discute práticas recomendadas para desenvolvimento de software levando em consideração a operação do sistema. Algumas das principais recomendações incluem: (1) projetar sistemas pensando na automação do ambiente e na facilidade de operação e manutenção, (2) registrar logs de forma padronizada e útil para depuração, (3) construir aplicações considerando os requisitos de implantação e (3) realizar testes abrangentes que simulem condições reais de produção.

1. DEV VS. OPS
Desenvolvendo para operação
Roberto Gaiser
gaiser@geekbunker.org
@rgaiser
1

2. SITUAÇÃO ATUAL
2

3. “SIMPLES E DE FÁCIL MANUTENÇÃO”
3

4. “ISSO FICA PARA A SEGUNDA ENTREGA”
4

5. PLANNING
O começo
5

6. 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

7. O QUE FAZER?
7

8. COMPONENTES
8

9. 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

10. 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

11. LOGS
11

12. LOGS
• Logar tudo
• Log Driven Development
• Logs devem ser evidências de teste
• Syslog
• Formato padrão
• “Vou olhar no código...”
12

13. LOGS
• Stack trace não é log
• Identificador único de transação
• Vários níveis de log
• Em português
• Logdeve de ser parte do desenvolvimento, não algo a ser
acrescentado depois
13

14. DEPLOY
14

15. DEPLOY
• “É só pegar do <...> e jogar lá”
• Aplicação deve ser construída pensando no deploy
• Resolverdependê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

16. 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

17. TESTES
17

18. TESTES
• Máquinasde 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

19. TESTES
• Tempo de teste
• Testar o que não funciona
• Testar com componentes fora do ar
• Quantidade de requests esperados em produção?
19

20. 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

21. SEGURANÇA
21

22. 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

23. BANCO DE DADOS
23

24. 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

25. 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

26. 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

27. CONFIGURAÇÕES
27

28. CONFIGURAÇÕES
• Fora do jar, war, egg, gem...
• Possibilita automação
• Possibilita auditoria
• Possibilita versionamento
• Flexibilidade para operação
28

29. BACKUP
29

30. 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

31. FALHAS
31

32. 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

33. BALANCEAMENTO DE CARGA
33

34. 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

35. INTERFACE PARA OPERAÇÃO
35

36. INTERFACE PARA OPERAÇÃO
• REST + JSON
• Ferramenta CLI
• Limpar cache
• Reconectar no banco
36

37. INTERFACE PARA OPERAÇÃO
• Controlar processamento de fila
• Colocar aplicação em “read-only”
• Controlar recebimento de requests
• Controlar o /status
37

38. MONITORAÇÃO
38

39. 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

40. 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

41. EU NÃO PRECISO SABER...
41

42. 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

43. 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

44. DICAS
• Discos mentem
• Memória mente
• Máquinas falham
• VM’s mentem mais ainda
• “Diminishing returns“
44

45. DICAS
• Gerar logs se a aplicação permitir, antes do restart
• Apagar incêndio = restart
simples: ping, date, route, dig e df identificam a
• Testes
maior parte dos problemas
45

46. PERGUNTAS?
46