Your SlideShare is downloading. ×

Dev vs. Ops

2,241

Published on

Tech Talk IG - Dez/2010 …

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

Published in: Technology, Business
0 Comments
17 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,241
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
32
Comments
0
Likes
17
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. DEV VS. OPS Desenvolvendo para operaçãoRoberto Gaisergaiser@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• Resolver dependências/requisitos• Scripts de inicialização, rotacionar logs, etc 15
  • 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. 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• 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. 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 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 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. FALHAS 29
  • 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. BALANCEAMENTO DE CARGA 31
  • 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. INTERFACE PARA OPERAÇÃO 33
  • 34. INTERFACE PARA OPERAÇÃO• REST + JSON• Ferramenta CLI• Limpar cache• Reconectar no banco 34
  • 35. INTERFACE PARA OPERAÇÃO• Controlar processamento de fila• Colocar aplicação em “read-only”• Controlar recebimento de requests• /status 35
  • 36. MONITORAÇÃO 36
  • 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. 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. EU NÃO PRECISO SABER... 39
  • 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. 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. DICAS• Discos mentem• Memória mente• Máquinas falham• VM’s mentem mais ainda• “Diminishing returns“ 42
  • 43. PERGUNTAS? 43

×