SlideShare uma empresa Scribd logo
Vivenciando experiências de DevOps
além de automação de infraestrutura
Cesar Mesquita
@cmesquita00
Infrastructure Architect
Diego Pacheco
@diego_pacheco
Principal Software Architect
ilegra.com
Sobre as nossas experiencias…
~35/40 pessoas
Projeto X: Mais de 120k horas de projeto
~400 epicos
~650h de
treinamentos
SOA
120/40k horas ~140 servers
API
Devesenvolvimento de software antes de 2009
Fábrica de Software
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…
2009
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.
2 Culturas: Open Source e Software Proprietário
Infra - ITIL
Governança - ITIL
Lições Aprendidas: Operação não participava na contrução do pipeline de deploy -> Burocracia.
Lições Aprendidas: Falta de visibilidade da operação: Que versão do que, esta rodando, aonde?
Lições Aprendidas: Quebra de processos do OPS(ITIL) “destroyOPS”
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
2010 - XP
2010 - Kanban
2 modelos de gestão
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!
O Valor da Cultura! Tudo é sobre visão.
Coaching Sessions
Retrospectivas
Dojos, Hackathons, LTs
Eventos Internos: Talks, Fishbowls, workshops
Automação e Delivery
Arquitetura de Software
The Root of All Evil |Nos não acreditamos na caixa mágica...
Típica arquitetura de software...
UI
+
Código de Negócio
DB
+
Código de Negócio
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
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.
Como resolvemos esses problemas?
SOA: Arquitetura & Orientação a Serviços / Microserviços
Integração de Sistemas(FAKE) VS Interoperabilidade(Unificada)
Sistema A
Sistema B
Integrador
A
B
SOA: Arquitetura e Orientação a Serviços
SOC
Integridade Conceitual Profiles
SOA: Entendendo a natureza das coisas...
Design Session – Arch Colaborativa
Branches – Muitas dores de cabeça!
Muitas vezes se descobre do pior jeito possível... 
BLAMELESS
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?
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 
Stress Testing
Profile, Tunning e Incendios, ai que o bixo pega 
Chaos Engineering / Failures
Durante o aprendisado...
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?
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
DevOps são formas de se pensar,
escrever e operar software para
atingir alto desempenho e
excelência de TI.
DevOps: Os 3 Lados
Gestão
Arquitetura Operação
DevOps
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
Programa Bimodal: Linhas que promovem mudanças, não projetos!
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
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

Mais conteúdo relacionado

Mais procurados

Procura-se: DevOps #cpbr9
Procura-se: DevOps #cpbr9Procura-se: DevOps #cpbr9
Procura-se: DevOps #cpbr9
Camilla Gomes
 
O que é DevOps afinal?
O que é DevOps afinal?O que é DevOps afinal?
O que é DevOps afinal?
Jose Augusto Carvalho
 
Tornando se um DevOps sem perder a cabeça #SE7I2016
Tornando se um DevOps sem perder a cabeça #SE7I2016Tornando se um DevOps sem perder a cabeça #SE7I2016
Tornando se um DevOps sem perder a cabeça #SE7I2016
Camilla Gomes
 
DevOps, NoOps...afinal que raios é isso?
DevOps, NoOps...afinal que raios é isso?DevOps, NoOps...afinal que raios é isso?
DevOps, NoOps...afinal que raios é isso?
Thiago Ganzarolli
 
Cultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e develCultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e devel
Jose Augusto Carvalho
 
O que é DevOps? Introdução à abordagem pela IBM
O que é DevOps? Introdução à abordagem pela IBMO que é DevOps? Introdução à abordagem pela IBM
O que é DevOps? Introdução à abordagem pela IBM
Felipe Freire
 
Direto das Trincheiras: Boas e más práticas de aplicações Ruby em ambientes c...
Direto das Trincheiras: Boas e más práticas de aplicações Ruby em ambientes c...Direto das Trincheiras: Boas e más práticas de aplicações Ruby em ambientes c...
Direto das Trincheiras: Boas e más práticas de aplicações Ruby em ambientes c...
Danilo Sato
 
Como desenvolver-software
Como desenvolver-softwareComo desenvolver-software
Como desenvolver-software
Fábio Nogueira de Lucena
 
Metodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de SoftwareMetodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de Software
Adolfo Neto
 
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian FerrariDrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
Taller Negócio Digitais
 
Ecossistema ágil
Ecossistema ágilEcossistema ágil
Ecossistema ágil
Roberto Brandini
 
Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?
Igor Abade
 
Introdução ao Scrum
Introdução ao ScrumIntrodução ao Scrum
Introdução ao Scrum
Giovanni Bassi
 
Quem e dev ops
Quem e dev opsQuem e dev ops
Quem e dev ops
Andre "Ramoni" Guimaraes
 
Quebrando barreiras entre desenvolvimento e operação de software com DevOps
Quebrando barreiras entre desenvolvimento e operação de software com DevOpsQuebrando barreiras entre desenvolvimento e operação de software com DevOps
Quebrando barreiras entre desenvolvimento e operação de software com DevOps
José Alexandre Macedo
 
UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27
Hélio Medeiros
 
DevOps - A Origem
DevOps - A OrigemDevOps - A Origem
DevOps - A Origem
André Dias
 
Agile, mudando o foco
Agile, mudando o focoAgile, mudando o foco
Agile, mudando o foco
ewerttonbravo
 
DevOps I - Ambientes padronizados e Monitoramento da Aplicação | Monografia I
DevOps I - Ambientes padronizados e Monitoramento da Aplicação | Monografia IDevOps I - Ambientes padronizados e Monitoramento da Aplicação | Monografia I
DevOps I - Ambientes padronizados e Monitoramento da Aplicação | Monografia I
Alefe Variani
 
IFSP 2015 - Cultura DevOps
IFSP 2015 - Cultura DevOpsIFSP 2015 - Cultura DevOps
IFSP 2015 - Cultura DevOps
Leonardo Comelli
 

Mais procurados (20)

Procura-se: DevOps #cpbr9
Procura-se: DevOps #cpbr9Procura-se: DevOps #cpbr9
Procura-se: DevOps #cpbr9
 
O que é DevOps afinal?
O que é DevOps afinal?O que é DevOps afinal?
O que é DevOps afinal?
 
Tornando se um DevOps sem perder a cabeça #SE7I2016
Tornando se um DevOps sem perder a cabeça #SE7I2016Tornando se um DevOps sem perder a cabeça #SE7I2016
Tornando se um DevOps sem perder a cabeça #SE7I2016
 
DevOps, NoOps...afinal que raios é isso?
DevOps, NoOps...afinal que raios é isso?DevOps, NoOps...afinal que raios é isso?
DevOps, NoOps...afinal que raios é isso?
 
Cultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e develCultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e devel
 
O que é DevOps? Introdução à abordagem pela IBM
O que é DevOps? Introdução à abordagem pela IBMO que é DevOps? Introdução à abordagem pela IBM
O que é DevOps? Introdução à abordagem pela IBM
 
Direto das Trincheiras: Boas e más práticas de aplicações Ruby em ambientes c...
Direto das Trincheiras: Boas e más práticas de aplicações Ruby em ambientes c...Direto das Trincheiras: Boas e más práticas de aplicações Ruby em ambientes c...
Direto das Trincheiras: Boas e más práticas de aplicações Ruby em ambientes c...
 
Como desenvolver-software
Como desenvolver-softwareComo desenvolver-software
Como desenvolver-software
 
Metodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de SoftwareMetodologias Ágeis para o Desenvolvimento de Software
Metodologias Ágeis para o Desenvolvimento de Software
 
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian FerrariDrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
 
Ecossistema ágil
Ecossistema ágilEcossistema ágil
Ecossistema ágil
 
Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?
 
Introdução ao Scrum
Introdução ao ScrumIntrodução ao Scrum
Introdução ao Scrum
 
Quem e dev ops
Quem e dev opsQuem e dev ops
Quem e dev ops
 
Quebrando barreiras entre desenvolvimento e operação de software com DevOps
Quebrando barreiras entre desenvolvimento e operação de software com DevOpsQuebrando barreiras entre desenvolvimento e operação de software com DevOps
Quebrando barreiras entre desenvolvimento e operação de software com DevOps
 
UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27UnP Eng. Software - Aula 27
UnP Eng. Software - Aula 27
 
DevOps - A Origem
DevOps - A OrigemDevOps - A Origem
DevOps - A Origem
 
Agile, mudando o foco
Agile, mudando o focoAgile, mudando o foco
Agile, mudando o foco
 
DevOps I - Ambientes padronizados e Monitoramento da Aplicação | Monografia I
DevOps I - Ambientes padronizados e Monitoramento da Aplicação | Monografia IDevOps I - Ambientes padronizados e Monitoramento da Aplicação | Monografia I
DevOps I - Ambientes padronizados e Monitoramento da Aplicação | Monografia I
 
IFSP 2015 - Cultura DevOps
IFSP 2015 - Cultura DevOpsIFSP 2015 - Cultura DevOps
IFSP 2015 - Cultura DevOps
 

Destaque

Wine.com.br - De zero a 300 milhões de faturamento na mesma plataforma
Wine.com.br - De zero a 300 milhões de faturamento na mesma plataformaWine.com.br - De zero a 300 milhões de faturamento na mesma plataforma
Wine.com.br - De zero a 300 milhões de faturamento na mesma plataforma
Paulo César M Jeveaux
 
Workshop sistema de versionamento de código - git
Workshop  sistema de versionamento de código - gitWorkshop  sistema de versionamento de código - git
Workshop sistema de versionamento de código - git
Thiago Filadelfo
 
Apresentação do SAEO na Administração Pública
Apresentação do SAEO na Administração PúblicaApresentação do SAEO na Administração Pública
Apresentação do SAEO na Administração Pública
Marco Rosner
 
Joomla!Day Brasil 2008 - FláVio Kubota - Gsoc Version Control
Joomla!Day Brasil 2008 - FláVio Kubota - Gsoc Version ControlJoomla!Day Brasil 2008 - FláVio Kubota - Gsoc Version Control
Joomla!Day Brasil 2008 - FláVio Kubota - Gsoc Version Control
Joomla!Day Brasil
 
GCS - Aula 02 - Conceitos Principais
GCS - Aula 02 - Conceitos PrincipaisGCS - Aula 02 - Conceitos Principais
GCS - Aula 02 - Conceitos Principais
Misael Santos
 
Controle de Versão e Monitoramento de Projetos com SVN + WebSVN + StatSVN
Controle de Versão e Monitoramento de Projetos com SVN + WebSVN + StatSVNControle de Versão e Monitoramento de Projetos com SVN + WebSVN + StatSVN
Controle de Versão e Monitoramento de Projetos com SVN + WebSVN + StatSVN
Felipe Queiroz
 
GCS - Aula 09 - GCS Ágil
GCS - Aula 09 - GCS ÁgilGCS - Aula 09 - GCS Ágil
GCS - Aula 09 - GCS Ágil
Misael Santos
 
Introdução ao Sistema de Controle de Versão
Introdução ao Sistema de Controle de VersãoIntrodução ao Sistema de Controle de Versão
Introdução ao Sistema de Controle de Versão
Fernando Machado
 
Controle de Mudanças com GitHub
Controle de Mudanças com GitHubControle de Mudanças com GitHub
Controle de Mudanças com GitHub
Bruno Furtado
 
[Mini-curso] Sistema de Controle de Versão
[Mini-curso] Sistema de Controle de Versão[Mini-curso] Sistema de Controle de Versão
[Mini-curso] Sistema de Controle de Versão
Marco Rosner
 
Controle de versão com GIT
Controle de versão com GITControle de versão com GIT
Controle de versão com GIT
Paulo César M Jeveaux
 
Transformando a experiência dos times de DEV, OPS & BIZ nos Sistemas Financei...
Transformando a experiência dos times de DEV, OPS & BIZ nos Sistemas Financei...Transformando a experiência dos times de DEV, OPS & BIZ nos Sistemas Financei...
Transformando a experiência dos times de DEV, OPS & BIZ nos Sistemas Financei...
especificacoes.com
 
Alm open source
Alm open sourceAlm open source
Alm open source
Bruno Souza
 
Controle de versão com Git e BitBucket
Controle de versão com Git e BitBucketControle de versão com Git e BitBucket
Controle de versão com Git e BitBucket
Marcio Barbosa
 
Android UI Fundamentals part 1
Android UI Fundamentals part 1Android UI Fundamentals part 1
Android UI Fundamentals part 1
Marcos Paulo Souza Damasceno
 
Mini aula-sublime-text-git-e-github
Mini aula-sublime-text-git-e-githubMini aula-sublime-text-git-e-github
Mini aula-sublime-text-git-e-github
Wilson Mendes
 
Controle de versão utilizando git
Controle de versão utilizando gitControle de versão utilizando git
Controle de versão utilizando git
fredmosc
 
O futuro dos WebApps com AngularJS 2.0
O futuro dos WebApps com AngularJS 2.0O futuro dos WebApps com AngularJS 2.0
O futuro dos WebApps com AngularJS 2.0
Wilson Mendes
 
Sistemas de Controle de Versão
Sistemas de Controle de VersãoSistemas de Controle de Versão
Sistemas de Controle de Versão
Jonathas Silva
 
Gerenciadores de Controle de Versão: Git, Mercurial e Bazaar
Gerenciadores de Controle de Versão: Git, Mercurial e BazaarGerenciadores de Controle de Versão: Git, Mercurial e Bazaar
Gerenciadores de Controle de Versão: Git, Mercurial e Bazaar
Ivanilton Polato
 

Destaque (20)

Wine.com.br - De zero a 300 milhões de faturamento na mesma plataforma
Wine.com.br - De zero a 300 milhões de faturamento na mesma plataformaWine.com.br - De zero a 300 milhões de faturamento na mesma plataforma
Wine.com.br - De zero a 300 milhões de faturamento na mesma plataforma
 
Workshop sistema de versionamento de código - git
Workshop  sistema de versionamento de código - gitWorkshop  sistema de versionamento de código - git
Workshop sistema de versionamento de código - git
 
Apresentação do SAEO na Administração Pública
Apresentação do SAEO na Administração PúblicaApresentação do SAEO na Administração Pública
Apresentação do SAEO na Administração Pública
 
Joomla!Day Brasil 2008 - FláVio Kubota - Gsoc Version Control
Joomla!Day Brasil 2008 - FláVio Kubota - Gsoc Version ControlJoomla!Day Brasil 2008 - FláVio Kubota - Gsoc Version Control
Joomla!Day Brasil 2008 - FláVio Kubota - Gsoc Version Control
 
GCS - Aula 02 - Conceitos Principais
GCS - Aula 02 - Conceitos PrincipaisGCS - Aula 02 - Conceitos Principais
GCS - Aula 02 - Conceitos Principais
 
Controle de Versão e Monitoramento de Projetos com SVN + WebSVN + StatSVN
Controle de Versão e Monitoramento de Projetos com SVN + WebSVN + StatSVNControle de Versão e Monitoramento de Projetos com SVN + WebSVN + StatSVN
Controle de Versão e Monitoramento de Projetos com SVN + WebSVN + StatSVN
 
GCS - Aula 09 - GCS Ágil
GCS - Aula 09 - GCS ÁgilGCS - Aula 09 - GCS Ágil
GCS - Aula 09 - GCS Ágil
 
Introdução ao Sistema de Controle de Versão
Introdução ao Sistema de Controle de VersãoIntrodução ao Sistema de Controle de Versão
Introdução ao Sistema de Controle de Versão
 
Controle de Mudanças com GitHub
Controle de Mudanças com GitHubControle de Mudanças com GitHub
Controle de Mudanças com GitHub
 
[Mini-curso] Sistema de Controle de Versão
[Mini-curso] Sistema de Controle de Versão[Mini-curso] Sistema de Controle de Versão
[Mini-curso] Sistema de Controle de Versão
 
Controle de versão com GIT
Controle de versão com GITControle de versão com GIT
Controle de versão com GIT
 
Transformando a experiência dos times de DEV, OPS & BIZ nos Sistemas Financei...
Transformando a experiência dos times de DEV, OPS & BIZ nos Sistemas Financei...Transformando a experiência dos times de DEV, OPS & BIZ nos Sistemas Financei...
Transformando a experiência dos times de DEV, OPS & BIZ nos Sistemas Financei...
 
Alm open source
Alm open sourceAlm open source
Alm open source
 
Controle de versão com Git e BitBucket
Controle de versão com Git e BitBucketControle de versão com Git e BitBucket
Controle de versão com Git e BitBucket
 
Android UI Fundamentals part 1
Android UI Fundamentals part 1Android UI Fundamentals part 1
Android UI Fundamentals part 1
 
Mini aula-sublime-text-git-e-github
Mini aula-sublime-text-git-e-githubMini aula-sublime-text-git-e-github
Mini aula-sublime-text-git-e-github
 
Controle de versão utilizando git
Controle de versão utilizando gitControle de versão utilizando git
Controle de versão utilizando git
 
O futuro dos WebApps com AngularJS 2.0
O futuro dos WebApps com AngularJS 2.0O futuro dos WebApps com AngularJS 2.0
O futuro dos WebApps com AngularJS 2.0
 
Sistemas de Controle de Versão
Sistemas de Controle de VersãoSistemas de Controle de Versão
Sistemas de Controle de Versão
 
Gerenciadores de Controle de Versão: Git, Mercurial e Bazaar
Gerenciadores de Controle de Versão: Git, Mercurial e BazaarGerenciadores de Controle de Versão: Git, Mercurial e Bazaar
Gerenciadores de Controle de Versão: Git, Mercurial e Bazaar
 

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

Introdução a DevOps e Continuous delivery agileday
Introdução a DevOps e Continuous delivery   agiledayIntrodução a DevOps e Continuous delivery   agileday
Introdução a DevOps e Continuous delivery agileday
Carlos Felippe Cardoso
 
Webinar DevOps - Encontros Ágeis
Webinar DevOps - Encontros ÁgeisWebinar DevOps - Encontros Ágeis
Webinar DevOps - Encontros Ágeis
Rodrigo R Garcia, PMP
 
Matando web forms e modernizando um grande varejista
Matando web forms e modernizando um grande varejistaMatando web forms e modernizando um grande varejista
Matando web forms e modernizando um grande varejista
José Roberto Araújo
 
XP - Extreme Programming
XP - Extreme ProgrammingXP - Extreme Programming
XP - Extreme Programming
Rodrigo Branas
 
Primeiros passos para estruturar uma equipe front-end
Primeiros passos para estruturar uma equipe front-endPrimeiros passos para estruturar uma equipe front-end
Primeiros passos para estruturar uma equipe front-end
Diego Eis
 
Clean Architecture
Clean ArchitectureClean Architecture
Clean Architecture
Rodrigo Branas
 
Metodos ageis thinkingdifferent
Metodos ageis thinkingdifferentMetodos ageis thinkingdifferent
Metodos ageis thinkingdifferent
Paulo Igor Alves Godinho
 
O futuro do arquiteto e das arquiteturas Java Enterprise
O futuro do arquiteto e das arquiteturas Java EnterpriseO futuro do arquiteto e das arquiteturas Java Enterprise
O futuro do arquiteto e das arquiteturas Java Enterprise
Globalcode
 
Apresentando o OpsWorks - Bemobi
Apresentando o OpsWorks - BemobiApresentando o OpsWorks - Bemobi
Apresentando o OpsWorks - Bemobi
Ricardo Martins ☁
 
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
Taller Negócio Digitais
 
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on AzureTDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
tdc-globalcode
 
Automação de testes para equipes agile
Automação de testes para equipes agileAutomação de testes para equipes agile
Automação de testes para equipes agile
Alini Rebonatto
 
Workshop soa, microservices e devops
Workshop soa, microservices e devopsWorkshop soa, microservices e devops
Workshop soa, microservices e devops
Diego Pacheco
 
Microservices
MicroservicesMicroservices
Microservices
Diego Pacheco
 
Arquitetura web para sistemas de negócio
Arquitetura web para sistemas de negócioArquitetura web para sistemas de negócio
Arquitetura web para sistemas de negócio
Ralph Rassweiler
 
ConnectionDay 2019 - Divinópolis - Transformação digital turbinada
ConnectionDay 2019 - Divinópolis - Transformação digital turbinadaConnectionDay 2019 - Divinópolis - Transformação digital turbinada
ConnectionDay 2019 - Divinópolis - Transformação digital turbinada
André Paulovich
 
Os príncipios por trás do DevOps
Os príncipios por trás do DevOpsOs príncipios por trás do DevOps
Os príncipios por trás do DevOps
Guilherme Cardoso
 
Tdc 2020 gerenciamento de incidente neste novo mundo
Tdc 2020   gerenciamento de incidente neste novo mundoTdc 2020   gerenciamento de incidente neste novo mundo
Tdc 2020 gerenciamento de incidente neste novo mundo
Felipe Klerk Signorini
 
Muita gestão e pouca engenharia, por onde anda o XP?
Muita gestão e pouca engenharia, por onde anda o XP?Muita gestão e pouca engenharia, por onde anda o XP?
Muita gestão e pouca engenharia, por onde anda o XP?
Cristiano Schwening
 
IPA Conhecendo XP
IPA Conhecendo XPIPA Conhecendo XP
IPA Conhecendo XP
Wildtech
 

Semelhante a Vivenciando dev ops para além da automação de infraestrutura 2.0 (20)

Introdução a DevOps e Continuous delivery agileday
Introdução a DevOps e Continuous delivery   agiledayIntrodução a DevOps e Continuous delivery   agileday
Introdução a DevOps e Continuous delivery agileday
 
Webinar DevOps - Encontros Ágeis
Webinar DevOps - Encontros ÁgeisWebinar DevOps - Encontros Ágeis
Webinar DevOps - Encontros Ágeis
 
Matando web forms e modernizando um grande varejista
Matando web forms e modernizando um grande varejistaMatando web forms e modernizando um grande varejista
Matando web forms e modernizando um grande varejista
 
XP - Extreme Programming
XP - Extreme ProgrammingXP - Extreme Programming
XP - Extreme Programming
 
Primeiros passos para estruturar uma equipe front-end
Primeiros passos para estruturar uma equipe front-endPrimeiros passos para estruturar uma equipe front-end
Primeiros passos para estruturar uma equipe front-end
 
Clean Architecture
Clean ArchitectureClean Architecture
Clean Architecture
 
Metodos ageis thinkingdifferent
Metodos ageis thinkingdifferentMetodos ageis thinkingdifferent
Metodos ageis thinkingdifferent
 
O futuro do arquiteto e das arquiteturas Java Enterprise
O futuro do arquiteto e das arquiteturas Java EnterpriseO futuro do arquiteto e das arquiteturas Java Enterprise
O futuro do arquiteto e das arquiteturas Java Enterprise
 
Apresentando o OpsWorks - Bemobi
Apresentando o OpsWorks - BemobiApresentando o OpsWorks - Bemobi
Apresentando o OpsWorks - Bemobi
 
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
Os pecados mortais de escalabilidade em Drupal e seus efeitos nos negócios - ...
 
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on AzureTDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
TDC2018SP | Trilha Arq .Net - Serverless Reactive Programming on Azure
 
Automação de testes para equipes agile
Automação de testes para equipes agileAutomação de testes para equipes agile
Automação de testes para equipes agile
 
Workshop soa, microservices e devops
Workshop soa, microservices e devopsWorkshop soa, microservices e devops
Workshop soa, microservices e devops
 
Microservices
MicroservicesMicroservices
Microservices
 
Arquitetura web para sistemas de negócio
Arquitetura web para sistemas de negócioArquitetura web para sistemas de negócio
Arquitetura web para sistemas de negócio
 
ConnectionDay 2019 - Divinópolis - Transformação digital turbinada
ConnectionDay 2019 - Divinópolis - Transformação digital turbinadaConnectionDay 2019 - Divinópolis - Transformação digital turbinada
ConnectionDay 2019 - Divinópolis - Transformação digital turbinada
 
Os príncipios por trás do DevOps
Os príncipios por trás do DevOpsOs príncipios por trás do DevOps
Os príncipios por trás do DevOps
 
Tdc 2020 gerenciamento de incidente neste novo mundo
Tdc 2020   gerenciamento de incidente neste novo mundoTdc 2020   gerenciamento de incidente neste novo mundo
Tdc 2020 gerenciamento de incidente neste novo mundo
 
Muita gestão e pouca engenharia, por onde anda o XP?
Muita gestão e pouca engenharia, por onde anda o XP?Muita gestão e pouca engenharia, por onde anda o XP?
Muita gestão e pouca engenharia, por onde anda o XP?
 
IPA Conhecendo XP
IPA Conhecendo XPIPA Conhecendo XP
IPA Conhecendo XP
 

Mais de Diego Pacheco

Naming Things Book : Simple Book Review!
Naming Things Book : Simple Book Review!Naming Things Book : Simple Book Review!
Naming Things Book : Simple Book Review!
Diego Pacheco
 
Continuous Discovery Habits Book Review.pdf
Continuous Discovery Habits  Book Review.pdfContinuous Discovery Habits  Book Review.pdf
Continuous Discovery Habits Book Review.pdf
Diego Pacheco
 
Thoughts about Shape Up
Thoughts about Shape UpThoughts about Shape Up
Thoughts about Shape Up
Diego Pacheco
 
Holacracy
HolacracyHolacracy
Holacracy
Diego Pacheco
 
AWS IAM
AWS IAMAWS IAM
AWS IAM
Diego Pacheco
 
CDKs
CDKsCDKs
Encryption Deep Dive
Encryption Deep DiveEncryption Deep Dive
Encryption Deep Dive
Diego Pacheco
 
Sec 101
Sec 101Sec 101
Sec 101
Diego Pacheco
 
Reflections on SCM
Reflections on SCMReflections on SCM
Reflections on SCM
Diego Pacheco
 
Management: Doing the non-obvious! III
Management: Doing the non-obvious! IIIManagement: Doing the non-obvious! III
Management: Doing the non-obvious! III
Diego Pacheco
 
Design is not Subjective
Design is not SubjectiveDesign is not Subjective
Design is not Subjective
Diego Pacheco
 
Architecture & Engineering : Doing the non-obvious!
Architecture & Engineering :  Doing the non-obvious!Architecture & Engineering :  Doing the non-obvious!
Architecture & Engineering : Doing the non-obvious!
Diego Pacheco
 
Management doing the non-obvious II
Management doing the non-obvious II Management doing the non-obvious II
Management doing the non-obvious II
Diego Pacheco
 
Testing in production
Testing in productionTesting in production
Testing in production
Diego Pacheco
 
Nine lies about work
Nine lies about workNine lies about work
Nine lies about work
Diego Pacheco
 
Management: doing the nonobvious!
Management: doing the nonobvious!Management: doing the nonobvious!
Management: doing the nonobvious!
Diego Pacheco
 
AI and the Future
AI and the FutureAI and the Future
AI and the Future
Diego Pacheco
 
Dealing with dependencies
Dealing  with dependenciesDealing  with dependencies
Dealing with dependencies
Diego Pacheco
 
Dealing with dependencies in tests
Dealing  with dependencies in testsDealing  with dependencies in tests
Dealing with dependencies in tests
Diego Pacheco
 
Kanban 2020
Kanban 2020Kanban 2020
Kanban 2020
Diego Pacheco
 

Mais de Diego Pacheco (20)

Naming Things Book : Simple Book Review!
Naming Things Book : Simple Book Review!Naming Things Book : Simple Book Review!
Naming Things Book : Simple Book Review!
 
Continuous Discovery Habits Book Review.pdf
Continuous Discovery Habits  Book Review.pdfContinuous Discovery Habits  Book Review.pdf
Continuous Discovery Habits Book Review.pdf
 
Thoughts about Shape Up
Thoughts about Shape UpThoughts about Shape Up
Thoughts about Shape Up
 
Holacracy
HolacracyHolacracy
Holacracy
 
AWS IAM
AWS IAMAWS IAM
AWS IAM
 
CDKs
CDKsCDKs
CDKs
 
Encryption Deep Dive
Encryption Deep DiveEncryption Deep Dive
Encryption Deep Dive
 
Sec 101
Sec 101Sec 101
Sec 101
 
Reflections on SCM
Reflections on SCMReflections on SCM
Reflections on SCM
 
Management: Doing the non-obvious! III
Management: Doing the non-obvious! IIIManagement: Doing the non-obvious! III
Management: Doing the non-obvious! III
 
Design is not Subjective
Design is not SubjectiveDesign is not Subjective
Design is not Subjective
 
Architecture & Engineering : Doing the non-obvious!
Architecture & Engineering :  Doing the non-obvious!Architecture & Engineering :  Doing the non-obvious!
Architecture & Engineering : Doing the non-obvious!
 
Management doing the non-obvious II
Management doing the non-obvious II Management doing the non-obvious II
Management doing the non-obvious II
 
Testing in production
Testing in productionTesting in production
Testing in production
 
Nine lies about work
Nine lies about workNine lies about work
Nine lies about work
 
Management: doing the nonobvious!
Management: doing the nonobvious!Management: doing the nonobvious!
Management: doing the nonobvious!
 
AI and the Future
AI and the FutureAI and the Future
AI and the Future
 
Dealing with dependencies
Dealing  with dependenciesDealing  with dependencies
Dealing with dependencies
 
Dealing with dependencies in tests
Dealing  with dependencies in testsDealing  with dependencies in tests
Dealing with dependencies in tests
 
Kanban 2020
Kanban 2020Kanban 2020
Kanban 2020
 

Último

Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Gabriel de Mattos Faustino
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
TomasSousa7
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
Momento da Informática
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
Faga1939
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
Momento da Informática
 
Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!
Jonathas Muniz
 
Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
Danilo Pinotti
 

Último (7)

Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
 
Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!
 
Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
 

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
  • 2.
  • 3.
  • 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
  • 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
  • 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
  • 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.
  • 27. Eventos Internos: Talks, Fishbowls, workshops
  • 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 
  • 45. Profile, Tunning e Incendios, ai que o bixo pega 
  • 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