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

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

4. ilegra.com

5. Sobre as nossas experiencias…

6. ~35/40 pessoas
Projeto X: Mais de 120k horas de projeto
~400 epicos
~650h de
treinamentos
SOA
120/40k horas ~140 servers
API

7. Devesenvolvimento de software antes de 2009

8. Fábrica de Software

9. 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…

10. 2009

11. 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.

12. 2 Culturas: Open Source e Software Proprietário

13. Infra - ITIL

14. Governança - ITIL

15. Lições Aprendidas: Operação não participava na contrução do pipeline de deploy -> Burocracia.

16. Lições Aprendidas: Falta de visibilidade da operação: Que versão do que, esta rodando, aonde?

17. Lições Aprendidas: Quebra de processos do OPS(ITIL) “destroyOPS”

18. 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

19. 2010 - XP

20. 2010 - Kanban

21. 2 modelos de gestão

22. 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!

23. O Valor da Cultura! Tudo é sobre visão.

24. Coaching Sessions

25. Retrospectivas

26. Dojos, Hackathons, LTs

27. Eventos Internos: Talks, Fishbowls, workshops

28. Automação e Delivery

29. Arquitetura de Software

30. The Root of All Evil |Nos não acreditamos na caixa mágica...

31. Típica arquitetura de software...
UI
+
Código de Negócio
DB
+
Código de Negócio

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. 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. Como resolvemos esses problemas?

35. SOA: Arquitetura & Orientação a Serviços / Microserviços

36. Integração de Sistemas(FAKE) VS Interoperabilidade(Unificada)
Sistema A
Sistema B
Integrador
A
B

37. SOA: Arquitetura e Orientação a Serviços
SOC
Integridade Conceitual Profiles

38. SOA: Entendendo a natureza das coisas...

39. Design Session – Arch Colaborativa

40. Branches – Muitas dores de cabeça!

41. Muitas vezes se descobre do pior jeito possível... 
BLAMELESS

42. 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?

43. 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 

44. Stress Testing

45. Profile, Tunning e Incendios, ai que o bixo pega 

46. Chaos Engineering / Failures

47. Durante o aprendisado...

48. 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?

49. 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

50. DevOps são formas de se pensar,
escrever e operar software para
atingir alto desempenho e
excelência de TI.

51. DevOps: Os 3 Lados
Gestão
Arquitetura Operação
DevOps

52. 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

53. Programa Bimodal: Linhas que promovem mudanças, não projetos!

54. 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

55. 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