QConSP: Vivenciando dev ops para além da automação de infraestrutura

662 visualizações

Publicada em

QConSP: Vivenciando dev ops para além da automação de infraestrutura #DevOps

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
662
No SlideShare
0
A partir de incorporações
0
Número de incorporações
14
Ações
Compartilhamentos
0
Downloads
8
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

QConSP: Vivenciando dev ops para além da automação de infraestrutura

  1. 1. Cesar Mesquita @cmesquita00 Middleware Architect Diego Pacheco @diego_pacheco Software Architect | Agile Coach
  2. 2. www.ilegra.com
  3. 3. Sobre as nossas experiencias…
  4. 4. ~35/40 pessoas Projeto X: Mais de 120k horas de projeto ~400 epicos ~650h de treinamentos SOA 120/40k horas ~140 servers API
  5. 5. 6 anos atrás... No começo... +- “2008” havia o DEV e a INFRA...
  6. 6. Devesenvolvimento de software antes de 2009
  7. 7. Fábrica de Software
  8. 8. Lições Aprendidas: O que não funcionava!  Tempo de entrega muito alto.  Qualidade de software muito baixa, pouco foco em design e arquitetura.  Soluções cinza: chata, sem mobilidade, extensibilidade, padrão.  Desenvolvedores que não estavam felizes: qualidade de código.  Gerentes que não estavam felizes: negociação de custo e escopo.  Estimativas mirabolantes: UCP, Pontos de Função, Chute do analista.  Foco muito grande em processo e documentação de trabalho.  Somente testes funcionais, sem testes do desenvolvedor.  Fase HOMOLOGAÇÃO, tudo vinha a tona…
  9. 9. 2009
  10. 10. Lições Aprendidas: O que não funcionava!  Dificuldade em trabalhar sem Datas.  Dificuldade em trabalhar com PROXIES de PO.  Daily meeting perdia o valor muito rápido.  Burndown de sprint não dizia nada, foco era RELEASE.  Daily com OPS e DEV com pouco valor: Status Update.  Não trabalhar bem com dependencies  Tarefas de categorias diferentes com realidades diferentes  Incidentes de Infra no meio de estorias.  Sistemas de priorização difentes: PO VS Tickets.
  11. 11. 2 Culturas: Open Source e Software Proprietário
  12. 12. Infra - ITIL
  13. 13. Lições Aprendidas: Operação não participava na contrução do pipeline de deploy -> Burocracia.
  14. 14. Lições Aprendidas: Falta de visibilidade da operação: Que versão do que, esta rodando, aonde?
  15. 15. Lições Aprendidas: Quebra de processos do OPS(ITIL) “destroyOPS”
  16. 16. Lições Aprendidas  Quebra de times por funcoes: DBAS, sysadmins, deploy, backup  Times especificos: problemas, incidentes, changes, releases. Diversos tickets abertos pra fazer release  Inteligencia esta toda no abridor de tickers, se faltasse coisa ia dar problema  Elevado tempo para aplicacar mudanças Infra-estrutura passiva: pouco conhecimento sobre as tecnologias
  17. 17. 2010 - XP
  18. 18. 2010 - Kanban
  19. 19. 2 modelos de gestão
  20. 20. Lições Aprendidas  OPS é um contrato e DEV é outro contrato.  Quando chegava em OPS já estada tudo definido.  2 Modelos de gestão não permitiam colaboração.  Tickets rapidos / SLA  Storias rapidas / Long run  Conversa por TICKETS  Coordenação de releases: deploy X cerveja.  Alarmes de SLA  OPS que executa o ticket: ActiveMQ o que ser isso?  OPS ou DBA?  Tunning vinha depois da dor.  Banco não automatizado. E o Rollback?  Serviço UP mas por que não funciona?  Como monitorar o Sistema? Como falar com o Sistema de incidents ZABIX?  Quem disse que OPS quer codar? Ou DEV aprender coisas de operação? Cultura!
  21. 21. O Valor da Cultura! Tudo é sobre visão.
  22. 22. Trabalho Remoto
  23. 23. Coaching Sessions
  24. 24. Retrospectivas
  25. 25. Dojos, Hackathons, LTs
  26. 26. Eventos Internos: Talks, Fishbowls, workshops
  27. 27. Automação e Delivery
  28. 28. Cultura, automação e delivery #win mas... Falta mais coisas...
  29. 29. Arquitetura de Software
  30. 30. The Root of All Evil |Nos não acreditamos na caixa mágica...
  31. 31. Típica arquitetura de software... UI + Código de Negócio DB + Código de Negócio
  32. 32. Típica arquitetura de software... UI + Código de Negócio DB + Código de Negócio UI + Código de Negócio UI + Código de Negócio
  33. 33. Por que isso é um problema?  Complexidade dentro da caixa.  Arquitetura influencia a estrutura dos times de DEV e OPS.  Problemas de Escalabilidade e evolução:  Falta de flexibilidade  Dificuldade de atualizacoes de software – acomplamento  Praticamente impossível de operar: Arquiteturas monoliticas.  Disperdicio de recursos  Problemas de entendimento, saber o que esta acontecendo e por que.  Complexidade para ops tunar aplicação.  Pior experiencia do usuario: EX: Roda um report deruba aplicação.  Custo de manter o software muito alto.  Falta de janelas pra aplicar modificações, impacto de mudanças alta.
  34. 34. Como resolvemos esses problemas?
  35. 35. Middleware OK mas Database, UI, Discoverability, Design de Software, Arch?
  36. 36. Integração de Sistemas(FAKE) VS Interoperabilidade(Unificada) Sistema A Sistema B Integrador A B
  37. 37. SOA: Arquitetura e Orientação a Serviços
  38. 38. SOA: Arquitetura e Orientação a Serviços SOC Integridade Conceitual Profiles
  39. 39. SOA: Entendendo a natureza das coisas...
  40. 40. Design Session – Arch Colaborativa
  41. 41. Stress Testing
  42. 42. Sem Stress Testing: Se descobre do pior jeito possível...
  43. 43. Profile, Tunning e Incendios, ai que o bixo pega 
  44. 44. Branches – Muitas dores de cabeça!
  45. 45. Durante o aprendisado...
  46. 46. Failures  OPS restringindo que tipo de solução de Arquitetura vai ser usada.  Orientação a bancos relacionais.  Orientação a RESILIENCIA (FOCO deveria ser ANTI-FRAGILIDADE).  Monitoramento de OPS básico: UP and Down.  Estado Interno de Aplição  SOA: múltiplas dependencias, distribuicão, dados.  Dificuldade de OPS no troubleshooting. Falta de entendimento de Arquitetura complexas.  Quebra dos níveis do ITIL, tudo era escalonado a NIVEL máixmo + DEVS.  RESETS e mais RESETS  Mascaram problemas  Perca de dados importantes pro troubleshooting (estado, logs).  Resumo: ITIL é quebrado com ambientes muito complexos.  Monitoramento != Operação  Vagrant muito lento com shared folder do windows  OPS roda testes, mas DEV não pode acessar, proxy, sem poder clicar, recebendo report.  OPS gerente do DEV. OPS cobra, dev fixa.  Exforço extra: DEV vira a noite, mas cade OPS pra fazer a release? NAO, DEPLOY só no outro dia de manha.  Cade o meu *On-Push-Button-Deploy* ? Pq preciso de devops?
  47. 47. Experiências relacionadas a Arquitetura...  DEV não pode tocar, OPS faz manual, inconsistencia ambientes (Immutable Infrastructre #SQN).  Exception stack traces em scala eram complicadas pra OPS.  Tunning de performance em sistemas distribuidos é complexo:  Time outs escodem gargalos  Controle de dados pode ser traiçoeiro  Aumento de dados anula tunning anterior, tem q se fazer de novo  Configs tem tempo de vida:  Refatoring do que não é mais necessário  Se não aplica melhorias elas apodrecem  13k Threads e 2k ulimit, LA alto, RESET, CAOS do pior jeito possível.  Lanes JMS e Negação de serviço.  1 Lane  1 Por Serviço SOA  Multiplas lanes por Worker ID  DataGrid, tudo que não tem uma replica é um SPOF e vai te pegar.  Testar depois é sempre pior, workaround de operação 
  48. 48. Quick Wins: Te ajudam a fazer as cosias acontecer rápido!
  49. 49. Wins  Pipeline de deploy feito por dev e ops.  Automação de tarefas repetitivas.  Infrastrucure as a code + Immutable Infrastructure  Provisionamento de ambientes com puppet e vagrant  Melhoria no troubleshooting de OPS  Conversar sem precisar de um ticket.   Treinamento de OPS: SOA, Agile, Lean, Messageria, NoSQL.  Monitoramento Junto  Pair Programing  Exposição JMX  Integração Arquitetura de soluções com monitoramento zabix.  Stress Test pariado 100% do tempo  Setup de ambiente  Automação  Thresholds  Monitoramento  Graficos  Método cientifico  Indentificação de bottlenetcks  OPS parte da decisão de Arquitetura: Antecipação.  Com Vagrant, em 1 dia dev tem ambiente e ainda bug fixado, tudo no mesmo dia.  OPS codando  Ai sim!  Dev pensando em operação, como vai rodar, em que profile, vai escalar?
  50. 50. Cultura: Quebra de cilos e “modelos únicos”
  51. 51. SO SOA / MSA / Middleware C.D Software Architecture Build - GC C.I - Jenkins Chef - Puppet Docker - Vagrant CD Automation DevOps Completo – Ponta a Ponta Infrasructure Cloud (Ias) Data Centers Network - OS DB Middleware Srvs Tunning / Test Assessments Stress Tests Jmeter / LoadUI Tunning (DB,Srvs) Profiling OnGoing Support – N1,2,3,4 Tickets – SLAS Metrics Alerts / Monitoring Operation 24/7 Next Steps – Onde estamos indo? Cultura DevOps/Lean/Agile
  52. 52. Cesar Mesquita @cmesquita00 Middleware Architect Diego Pacheco @diego_pacheco Software Architect | Agile Coach OBRIGADO

×