Dev vs. Ops

2.919 visualizações

Publicada em

Tech Talk IG - Dez/2010
R7 - Jan/2011

Publicada em: Tecnologia, Negócios
0 comentários
19 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
2.919
No SlideShare
0
A partir de incorporações
0
Número de incorporações
47
Ações
Compartilhamentos
0
Downloads
32
Comentários
0
Gostaram
19
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Dev vs. Ops

  1. 1. DEV VS. OPS Desenvolvendo para operaçãoRoberto Gaisergaiser@geekbunker.org@rgaiser 1
  2. 2. SITUAÇÃO ATUAL 2
  3. 3. “SIMPLES E DE FÁCIL MANUTENÇÃO” 3
  4. 4. “ISSO FICA PARA A SEGUNDA ENTREGA” 4
  5. 5. PLANNING O começo 5
  6. 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. 7. O QUE FAZER? 7
  8. 8. COMPONENTES 8
  9. 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. 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. 11. LOGS 11
  12. 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. 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. 14. DEPLOY 14
  15. 15. DEPLOY• “É só pegar do <...> e jogar lᔕ Aplicação deve ser construída pensando no deploy• Resolver dependências/requisitos• Scripts de inicialização, rotacionar logs, etc 15
  16. 16. DEPLOY• Evitar permissões incorretas• Evitar arquivos em caminhos errados• Evitar versões incorretas de dependências• Deploy faz parte do desenvolvimento• Pacotes 16
  17. 17. TESTES 17
  18. 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. 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. 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. 21. SEGURANÇA 21
  22. 22. SEGURANÇA• Nunca rodar como ROOT• Separar serviços, ex: Adminstração interna• Liberdade para Operação e Segurança utilizarem redes distintas ao invés de liberar acesso até a produção• Logs de auditoria, se necessários• Regra de Apache != ACL 22
  23. 23. BANCO DE DADOS 23
  24. 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 24
  25. 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 25
  26. 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. 27. CONFIGURAÇÕES 27
  28. 28. CONFIGURAÇÕES• Fora do jar, war, egg, gem...• Possibilita automação• Possibilita auditoria• Possibilita versionamento• Flexibilidade para operação 28
  29. 29. FALHAS 29
  30. 30. 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 30
  31. 31. BALANCEAMENTO DE CARGA 31
  32. 32. 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 32
  33. 33. INTERFACE PARA OPERAÇÃO 33
  34. 34. INTERFACE PARA OPERAÇÃO• REST + JSON• Ferramenta CLI• Limpar cache• Reconectar no banco 34
  35. 35. INTERFACE PARA OPERAÇÃO• Controlar processamento de fila• Colocar aplicação em “read-only”• Controlar recebimento de requests• /status 35
  36. 36. MONITORAÇÃO 36
  37. 37. MONITORAÇÃO• REST + JSON• Ferramenta CLI• Versão da aplicação e das dependências• Conexões com backend, banco, cache, uptime, etc• /monit 37
  38. 38. 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 38
  39. 39. EU NÃO PRECISO SABER... 39
  40. 40. VOCÊ PRECISA SABER QUE:• Existe um sistema operacional embaixo do software• Existe rede fora do software• Existe storage fora do software• “Eu programo em <...>, roda em qualquer coisa”• Memória, processamento e disco são recursos finitos 40
  41. 41. DICAS• “Bringing a knife to a gunfight”• Você define os requisitos• “Quando você só tem martelo, tudo é prego”• Framework?•O universo conspira contra você 41
  42. 42. DICAS• Discos mentem• Memória mente• Máquinas falham• VM’s mentem mais ainda• “Diminishing returns“ 42
  43. 43. PERGUNTAS? 43

×