DEV VS. OPS                        Desenvolvendo para operaçãoRoberto Gaisergaiser@geekbunker.org@rgaiser                 ...
SITUAÇÃO ATUAL                 2
“SIMPLES E DE FÁCIL MANUTENÇÃO”                                  3
“ISSO FICA PARA A SEGUNDA ENTREGA”                                     4
PLANNING  O começo             5
O COMEÇO•   “É fácil, está pronto na minha    maquina”•   “Só fazer um serviço que responde    <...>”•   “Colocamos tudo j...
O QUE FAZER?               7
COMPONENTES              8
COMPONENTES• “Um      sistema é um sistema, outro sistema é outro sistema”• Automação      para criar o ambiente• Ferramen...
COMPONENTES• Benefícios   a longo prazo• Flexibilidade   para operação na alocação de recursos• “code   outlives its [deve...
LOGS       11
LOGS• Logar    tudo• Log    Driven Development• Logs   devem ser evidências de teste• Syslog• Formato    padrão• “Vou    o...
LOGS• Stack    trace não é log• Identificador   único de transação• Vários   níveis de log• Em    português• Logdeve de ser...
DEPLOY         14
DEPLOY• “É   só pegar do <...> e jogar lᔕ Aplicação    deve ser construída pensando no deploy• Resolver    dependências/...
DEPLOY• Evitar   permissões incorretas• Evitar   arquivos em caminhos errados• Evitar   versões incorretas de dependências...
TESTES         17
TESTES• Máquinasde homologação e desenvolvimento na monitoração• Usar   gráficos de monitoração como evidência de teste• Do...
TESTES• Tempo    de teste• Testar   o que não funciona• Testar   com componentes fora do ar• Quantidade    de requests esp...
TESTES• TCPDump• Número     de requests X Requests simultâneos• Evidências   de teste• Métricas   úteis, ex: tempo de resp...
SEGURANÇA            21
SEGURANÇA• Nunca     rodar como ROOT• Separar   serviços, ex: Adminstração interna• Liberdade  para Operação e Segurança u...
BANCO DE DADOS                 23
BANCO DE DADOS• Utilizar   da melhor forma possível, não porque “é mais fácil”• Separar    leitura e escrita• Utilizar    ...
BANCO DE DADOS• Usar   ORM para tudo? (Black Magic)• Otimizar   query. Se o ORM não permitir... você está fazendo errado!•...
BANCO DE DADOS• Alternar   automaticamente para um banco de Stand-by• Reconectar    automaticamente• Usar   filas, o banco ...
CONFIGURAÇÕES                27
CONFIGURAÇÕES• Fora   do jar, war, egg, gem...• Possibilita   automação• Possibilita   auditoria• Possibilita   versioname...
FALHAS         29
FALHAS• Falha   elegante e rápida• Apresentar    menos funcionalidade ao invés de “Erro 500”• Recuperação     automática• ...
BALANCEAMENTO DE CARGA                         31
BALANCEAMENTO DE                 CARGA• Aplicações     que respondam ao teste do SLB• /status   => 200• Possibilita   test...
INTERFACE PARA OPERAÇÃO                          33
INTERFACE PARA OPERAÇÃO• REST   + JSON• Ferramenta   CLI• Limpar   cache• Reconectar   no banco                          34
INTERFACE PARA OPERAÇÃO• Controlar   processamento de fila• Colocar   aplicação em “read-only”• Controlar   recebimento de ...
MONITORAÇÃO              36
MONITORAÇÃO• REST   + JSON• Ferramenta   CLI• Versão   da aplicação e das dependências• Conexões    com backend, banco, ca...
MONITORAÇÃO• Usuários   ativos• Operações     com erro, sucesso, etc• Tempo    das operações: média e desvio padrão• Tipos...
EU NÃO PRECISO SABER...                          39
VOCÊ PRECISA SABER QUE:• Existe   um sistema operacional embaixo do software• Existe   rede fora do software• Existe   sto...
DICAS• “Bringing     a knife to a gunfight”• Você   define os requisitos• “Quando    você só tem martelo, tudo é prego”• Fra...
DICAS• Discos   mentem• Memória    mente• Máquinas   falham• VM’s   mentem mais ainda• “Diminishing        returns“       ...
PERGUNTAS?             43
Dev vs. Ops
Dev vs. Ops
Dev vs. Ops
Upcoming SlideShare
Loading in …5
×

Dev vs. Ops

2,635 views
2,473 views

Published on

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

Published in: Technology, Business

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

×