Upgrade to Pro — share decks privately, control downloads, hide ads and more …

O DevOps Acabou (FiqueEmCasaConf 2020)

O DevOps Acabou (FiqueEmCasaConf 2020)

Palestra apresentada dia 20 de abril de 2020 no FiqueEmCasaConf - https://github.com/linuxtips/FiqueEmCasaConf. Conceituamos o que é o DevOps, como surgiu, características, as vantagens e dificuldades de implementar, erros e o que não é DevOps. Mostramos qual o DevOps que tem que ter vida longa e qual o DevOps que deveria acabar.

Avatar for Wellington F. Silva

Wellington F. Silva

April 20, 2020
Tweet

More Decks by Wellington F. Silva

Other Decks in Technology

Transcript

  1. Wellington F. Silva contato: @_wsilva nicks: wsilva, boina, tom, fisi*

    funções: pai, tec. telecom, programador, sysadmin, docker community leader, instrutor, escritor, zend certified engineer, docker certified associate, certified kubernetes administrator * deprecation in favor of Well
  2. #FiqueEmCasa • Esqueça as visitas, faça videocalls • Ajude galera

    do risco • Maior CUIDADO do mundo quando for ter contato
  3. #FiqueEmCasa • Esqueça as visitas, faça videocalls • Ajude galera

    do risco • Maior CUIDADO do mundo quando for ter contato • Deixa a rua para quem precisa: logística, bombeiros, ambulâncias, polícia, abastecimento, etc
  4. #FiqueEmCasa • Esqueça as visitas, faça videocalls • Ajude galera

    do risco • Maior CUIDADO do mundo quando for ter contato • Deixa a rua para quem precisa: logística, bombeiros, ambulâncias, polícia, abastecimento, etc • Cuidado com sua saúde (mental tbm) pegue leve com todos (isso inclui você)
  5. Agenda • História do DevOps (O que é DevOps?) •

    Padrões, falhas e benefícios • Importância do DevOps
  6. O que é DevOps? • 2007 na Bélgica • Migração

    de datacenter • Encarregado de testar
  7. O que é DevOps? • 2007 na Bélgica • Migração

    de datacenter • Encarregado de testar • Frustrado - brigas entre devs e sysadmins
  8. O que é DevOps? Agosto 2008 - Agile Conference -

    Toronto Birds of a feather Agile Infrastructure Andrew Clay Schafer
  9. O que é DevOps? Agosto 2008 - Agile Conference -

    Toronto Birds of a feather Agile Infrastructure Andrew Clay Schafer Patrick Debois
  10. O que é DevOps? • Se encontram nos corredores do

    evento • Trocaram altas ideias
  11. O que é DevOps? • Se encontram nos corredores do

    evento • Trocaram altas ideias • Resolvem fundar o grupo: “Agile System Administration” [1]
  12. O que é DevOps? Junho 2009 - Velocity 10 deploys

    per day [2] https://youtu.be/LdOe18KhtT4 John Allspaw Paul Hammond
  13. O que é DevOps? • Patrick pelo Twitter elogia a

    apresentação e lamenta não ter visto ao vivo
  14. O que é DevOps? • Patrick pelo Twitter elogia a

    apresentação e lamenta não ter visto ao vivo • Paul Nasrat "tweeta" sugerindo fazer uma Velocity Belga
  15. O que é DevOps? • Patrick pelo Twitter elogia a

    apresentação e lamenta não ter visto ao vivo • Paul Nasrat "tweeta" sugerindo fazer uma Velocity Belga • Evento foi dias 30 e 31 de outubro de 2009 em Ghent na Bélgica
  16. O que é DevOps? • Patrick pelo Twitter elogia a

    apresentação e lamenta não ter visto ao vivo • Paul Nasrat "tweeta" sugerindo fazer uma Velocity Belga • Evento foi dias 30 e 31 de outubro de 2009 em Ghent na Bélgica • Agile Systems Administrators Conference DevOpsDays [3]
  17. O que é DevOps? • Cerca de 60 Developers, SysAdmins,

    Gerentes vieram de vários cantos do "mundo".
  18. O que é DevOps? • Cerca de 60 Developers, SysAdmins,

    Gerentes vieram de vários cantos do "mundo". • Após evento preferiram não definir manifesto DevOps e deixar aberto.
  19. O que é DevOps? • Cerca de 60 Developers, SysAdmins,

    Gerentes vieram de vários cantos do "mundo". • Após evento preferiram não definir manifesto DevOps e deixar aberto. Compreensível: ~
  20. O que é DevOps? • Cerca de 60 Developers, SysAdmins,

    Gerentes vieram de vários cantos do "mundo". • Após evento preferiram não definir manifesto DevOps e deixar aberto. Compreensível: ~ • Continuaram a trocar ideia pelo Twitter usando #devops
  21. O que é DevOps? • Em 2010 DevOpsDays rolou em

    Sydney, Montain View (USA), São Paulo (Brasil) e Hamburgo
  22. O que é DevOps? • Em 2010 DevOpsDays rolou em

    Sydney, Montain View (USA), São Paulo (Brasil) e Hamburgo • Vários meetups e conferences seguiram aparecendo solidificando uma comunidade
  23. O que é DevOps? • Em 2010 DevOpsDays rolou em

    Sydney, Montain View (USA), São Paulo (Brasil) e Hamburgo • Vários meetups e conferences seguiram aparecendo solidificando uma comunidade • Novas ferramentas criadas com esse novo foco 1ª foi Vagrant em 2011
  24. Antes do DevOps ITIL na moda: • Muito estruturado (silos),

    desconfiança entre as gerências. • Burocrático e caro para entregar valor
  25. Antes do DevOps Wall of confusion • Ninguém assume culpa,

    aponta para o outro • Não há compartilhamento de conhecimento entre as áreas
  26. Antes do DevOps Wall of confusion • Ninguém assume culpa,

    aponta para o outro • Não há compartilhamento de conhecimento entre as áreas • Não há empatia
  27. Antes do DevOps Wall of confusion • Ninguém assume culpa,

    aponta para o outro • Não há compartilhamento de conhecimento entre as áreas • Não há empatia • Geralmente é um detalhe de configuração ou algo parecido
  28. Antes do DevOps Desalinhamento de objetivos • Meta para Devs:

    entrega de funcionalidades • Meta para Sysadmins: uptime e resiliencia dos servidores
  29. Antes do DevOps Desalinhamento de objetivos • Meta para Devs:

    entrega de funcionalidades • Meta para Sysadmins: uptime e resiliencia dos servidores • São jogados um contra os outros.
  30. Primeira Maximiza o fluxo • Torna o trabalho visível •

    Diminui o tamanho do entregável • Limita o WIP (Work in Progress)
  31. Primeira Maximiza o fluxo • Torna o trabalho visível •

    Diminui o tamanho do entregável • Limita o WIP (Work in Progress) • Elimina desperdícios
  32. Primeira Maximiza o fluxo • Torna o trabalho visível •

    Diminui o tamanho do entregável • Limita o WIP (Work in Progress) • Elimina desperdícios • Identifica e reduz gargalos
  33. Segunda Usa a entrega como aprendizado • Encurta o ciclo

    de feedback • Gera e incorpora aprendizado
  34. Segunda Usa a entrega como aprendizado • Encurta o ciclo

    de feedback • Gera e incorpora aprendizado • Falha rápido para não impactar customers
  35. Terceira Ciclo completo • Testes e experimentos em todas as

    partes do fluxo • Aprendizado pelas falhas
  36. Terceira Ciclo completo • Testes e experimentos em todas as

    partes do fluxo • Aprendizado pelas falhas • Aprendizado pela prática e repetição
  37. Terceira Ciclo completo • Testes e experimentos em todas as

    partes do fluxo • Aprendizado pelas falhas • Aprendizado pela prática e repetição • Aumento da resiliência
  38. CALMS - Culture • Pessoas e processos • Sem cultura

    as demais ações falham. • Imprescindível as pessoas confiarem umas nas outras
  39. CALMS - Automation • Traz velocidade • Elimina erros de

    processos manuais s • Diminui time to market, tempo de detecção e recuperação (MTTR) ⏰
  40. CALMS - Automation • Traz velocidade • Elimina erros de

    processos manuais s • Diminui time to market, tempo de detecção e recuperação (MTTR) ⏰ • Mudanças naturalmente rastreadas e auditáveis
  41. CALMS - Automation • Traz velocidade • Elimina erros de

    processos manuais s • Diminui time to market, tempo de detecção e recuperação (MTTR) ⏰ • Mudanças naturalmente rastreadas e auditáveis • Aumento de confiança nas entregas
  42. CALMS - Lean • Eliminar desperdícios • Visibilidade do todo

    • Limita WIP • Melhora o fluxo de entregas
  43. CALMS - Measure • Sem medir como descobrir o que

    melhorar • Identifica gargalos
  44. CALMS - Measure • Sem medir como descobrir o que

    melhorar • Identifica gargalos • Telemetria (performance, logs)
  45. CALMS - Measure • Sem medir como descobrir o que

    melhorar • Identifica gargalos • Telemetria (performance, logs) • Pessoas e Processos
  46. CALMS - Sharing • Processo de loop back • Melhora

    o fluxo de comunicação • Aprendizado gera conhecimento
  47. CALMS - Sharing • Processo de loop back • Melhora

    o fluxo de comunicação • Aprendizado gera conhecimento • Conhecimento é espalhado
  48. ICE - Complexity • Sistemas são complexos • Mesmos simples

    blogs tem subsistemas para garantir que o conteúdo esteja disponível
  49. ICE - Complexity • Sistemas são complexos • Mesmos simples

    blogs tem subsistemas para garantir que o conteúdo esteja disponível • Sistemas quebram
  50. ICE - Complexity • Sistemas são complexos • Mesmos simples

    blogs tem subsistemas para garantir que o conteúdo esteja disponível • Sistemas quebram • Sistemas estão em constantes mudanças
  51. Por que DevOps? State of DevOps Report • Pesquisa feita

    há alguns anos com pessoas relacionadas
  52. Por que DevOps? State of DevOps Report • Pesquisa feita

    há alguns anos com pessoas relacionadas • Identifica e compara empresas high- performance e low-performance
  53. Por que DevOps? No report de 2018, empresas high-performance vs

    low-performance • 46 vezes mais deploys
  54. Por que DevOps? No report de 2018, empresas high-performance vs

    low-performance • 46 vezes mais deploys • Depoy lead time 2555 vezes mais rápido
  55. Por que DevOps? No report de 2018, empresas high-performance vs

    low-performance • 46 vezes mais deploys • Deploy lead time 2555 vezes mais rápido • 7 vezes menos falhas
  56. Por que DevOps? No report de 2018, empresas high-performance vs

    low-performance • 46 vezes mais deploys • Depoy lead time 2555 vezes mais rápido • 7 vezes menos falhas • MTTR 2604 vezes mais rápido
  57. Falhas - Time DevOps Time onde as pessoas • Conhecem

    todas ferramentas e tecnologias • Podem fazer qualquer coisa nas máquinas
  58. Falhas - Time DevOps Time onde as pessoas • Conhecem

    todas ferramentas e tecnologias • Podem fazer qualquer coisa nas máquinas Mas
  59. Falhas - Time DevOps Time onde as pessoas • Conhecem

    todas ferramentas e tecnologias • Podem fazer qualquer coisa nas máquinas Mas • Não desenvolvem as aplicações
  60. Falhas - Time DevOps Time onde as pessoas • Conhecem

    todas ferramentas e tecnologias • Podem fazer qualquer coisa nas máquinas Mas • Não desenvolvem as aplicações s • Nem colocam elas nos servidores
  61. Falhas - Time DevOps Time onde as pessoas • Conhecem

    todas ferramentas e tecnologias • Podem fazer qualquer coisa nas máquinas Mas • Não desenvolvem as aplicações s • Nem colocam elas nos servidores ¯\_(ツ)_/¯
  62. Falhas - Ferramentas • Puppet • Chef • Ansible •

    Vagrant • Terraform • Packer • Docker • Jenkins • Kubernetes • ELK O que essas ferramentas tem em comum?
  63. Falhas - Ferramentas • Jira • Clubhouse • Trello •

    Slack • Mattermost • PagerDuty • New Relic • Datadog • Gitlab • Github E essas ferramentas?
  64. 7 Erros Mortais 1. Trabalho invisível 2. Gerencia de toil

    3. Conhecimento em tribos 4. Desalinhamento de incentivos
  65. 7 Erros Mortais 5. Design organizacional incongruente 6. Gerencia de

    complexidade 7. Teatro de segurança e conformidades
  66. A Importância DevOps: • Não é produto • Não é

    especificação • Não é um emprego • Não é ferramenta
  67. A Importância DevOps • É de praticantes para praticantes •

    É cunhada e pela comunidade • É descentralizado • É aberto a todos • É inclusivo (papéis, gêneros, etnias, crenças, etc…)
  68. A Importância Resumindo: • Movimento baseado em troca de experiências

    (cases de sucesso e de fracasso) • Startups geralmente já saem na frente • Fazer a mudança em ambiente enterprise tipo grandes corporações é bem mais complicado • Cultura de disputa ao invés de colaboração é muito irraizada em grandes corporações
  69. A Importância As boas consequências : • Melhora das entrega

    nas empresas onde essas pessoas envolvidas trabalham
  70. A Importância As boas consequências : • Melhora das entrega

    nas empresas onde essas pessoas envolvidas trabalham • Menos tempo entre o Aha e o K-ching (entre a ideia e a entrega, time to market)
  71. A Importância As boas consequências : • Melhora das entrega

    nas empresas onde essas pessoas envolvidas trabalham • Menos tempo entre o Aha e o K-ching (entre a ideia e a entrega, time to market) • Empresas mais resilientes e mais velozes
  72. A Importância As más consequências : • Empresas passaram a

    perceber e querer o DevOps. • Outras se apoderam e tentam vender DevOps
  73. A Importância As más consequências : • Empresas passaram a

    perceber e querer o DevOps. • Outras se apoderam e tentam vender DevOps • Sem entender muitas acabam cometendo as falhas já comentadas durante adoção
  74. Referências • [1] https://groups.google.com/forum/#!forum/agile-system-administration • [2] https://youtu.be/LdOe18KhtT4 • [3] https://devopsdays.org

    • [4] https://itrevolution.com/the-three-ways-principles-underpinning-devops/ • [5] https://blog.chef.io/2010/07/16/what-devops-means-to-me/ • [6] http://radar.oreilly.com/2015/01/devops-keeps-it-cool-with-ice.html • [7] https://puppet.com/resources/whitepaper/state-of-devops-report • [8] https://www.youtube.com/watch?v=QQL4WAd5b6E e https:// www.slideshare.net/botchagalupe/the-7-deadly-diseases-of-devops-2019 • https://www.fernandoike.com • https://caylent.com/2018-state-devops-reports/ • https://courses.edx.org/courses/course-v1:LinuxFoundationX+LFS161x+2T2016/ course • http://slides.com/nir0s/ • https://xebialabs.com/periodic-table-of-devops-tools/ • https://landing.google.com/sre/sre-book/toc/