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

486 visualizações

Publicada em

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

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
486
No SlideShare
0
A partir de incorporações
0
Número de incorporações
18
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

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

  1. 1. Vivenciando experiências de DevOps além de automação de infraestrutura Cesar Mesquita @cmesquita00 Infrastructure Architect Diego Pacheco @diego_pacheco Principal Software Architect
  2. 2. 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. Devesenvolvimento de software antes de 2009
  6. 6. Fábrica de Software
  7. 7. 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…
  8. 8. 2009
  9. 9. 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.
  10. 10. 2 Culturas: Open Source e Software Proprietário
  11. 11. Infra - ITIL
  12. 12. Governança - 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  Micro-silos: 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. Coaching Sessions
  23. 23. Retrospectivas
  24. 24. Dojos, Hackathons, LTs
  25. 25. Eventos Internos: Talks, Fishbowls, workshops
  26. 26. Automação e Delivery
  27. 27. Arquitetura de Software
  28. 28. The Root of All Evil |Nos não acreditamos na caixa mágica...
  29. 29. Típica arquitetura de software... UI + Código de Negócio DB + Código de Negócio
  30. 30. 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
  31. 31. 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.
  32. 32. Como resolvemos esses problemas?
  33. 33. SOA: Arquitetura & Orientação a Serviços / Microserviços
  34. 34. Integração de Sistemas(FAKE) VS Interoperabilidade(Unificada) Sistema A Sistema B Integrador A B
  35. 35. SOA: Arquitetura e Orientação a Serviços SOC Integridade Conceitual Profiles
  36. 36. SOA: Entendendo a natureza das coisas...
  37. 37. Design Session – Arch Colaborativa
  38. 38. Branches – Muitas dores de cabeça!
  39. 39. Muitas vezes se descobre do pior jeito possível...  BLAMELESS
  40. 40. Lições Aprendidas das Failures / Incidentes  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?
  41. 41. Incidentes Relacionados 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 
  42. 42. Stress Testing
  43. 43. Profile, Tunning e Incendios, ai que o bixo pega 
  44. 44. Chaos Engineering / Failures
  45. 45. Durante o aprendisado...
  46. 46. 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?
  47. 47. DevOps não é:  Um Processo  Um Metodo  Uma Metodologia  Um Framework  Um Serviço  Uma Ferramenta  Díficil de ser Certificado  Não é cargo  Não é time, nem departamento DevOps
  48. 48. DevOps são formas de se pensar, escrever e operar software para atingir alto desempenho e excelência de TI.
  49. 49. DevOps: Os 3 Lados Gestão Arquitetura Operação DevOps
  50. 50. DevOps: Os 3 Lados Gestão Arquitetura Operação DevOpsSOA Microservices Isolamento Discoverability Anti-Fragility Automação Make your tools Chaos Engineering Elastic Infrastructure Anti-Fragility Longo Prazo Bimodal Contratar os melhores O jeito IMPORTA! Nova Estrutura de Times
  51. 51. Programa Bimodal: Linhas que promovem mudanças, não projetos!
  52. 52. SO SOA / MSA / Middleware C.D Software Architecture Build - GC C.I - Jenkins Chef – Puppet - Ansible Docker - Vagrant CD Automation DevOps Completo – Ponta a Ponta Infrasructure Cloud (Ias) - AWS Automated Data Centers Network - OS NoSQL DB Middleware Srvs Tunning / Test Assessments Stress Tests Jmeter / LoadUI Tunning (DB,Srvs) Profiling Chaos / Failure OnGoing 2.0 Agile Operations Automation You Build you Run it Realtime Metrics Actions not Alerts Next Steps – Onde estamos indo? Cultura DevOps/Lean/Agile
  53. 53. Vivenciando experiências de DevOps além de automação de infraestrutura Cesar Mesquita @cmesquita00 Infrastructure Architect Diego Pacheco @diego_pacheco Principal Software Architect OBRIGADO

×