O DevOps Acabou (Startup Summit 2019)

O DevOps Acabou (Startup Summit 2019)

Palestra apresentada dia 15 de agosto de 2019 no Start Summit 2019 em Florianópolis-SC (https://summit.sebrae.com.br/). Conceituamos o que é o DevOps, como surgiu, características, as vantagens e dificuldades de implementar, erros e o que não é DevOps. Mostramos o DevOps que tem que ter vida longa e o DevOps que tem que acabar.

280fecb4f048de5ecf36bec281609ea4?s=128

Wellington F. Silva

August 15, 2019
Tweet

Transcript

  1. 2.

    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 e docker certified associate * deprecation in favor of Well
  2. 3.

    Agenda • O que realmente é DevOps • Padrões, falhas

    e benefícios • Importância do DevOps
  3. 8.
  4. 9.

    O que é DevOps? • 2007 na Bélgica ! •

    Migração de datacenter • Encarregado de testar
  5. 10.

    O que é DevOps? • 2007 na Bélgica ! •

    Migração de datacenter • Encarregado de testar • Frustrado - brigas entre devs e sysadmins
  6. 12.
  7. 13.

    O que é DevOps? Agosto 2008 - Agile Conference -

    Toronto " Birds of a feather Agile Infrastructure Andrew Clay Schafer
  8. 14.

    O que é DevOps? Agosto 2008 - Agile Conference -

    Toronto " Birds of a feather Agile Infrastructure Andrew Clay Schafer Patrick Debois
  9. 17.

    O que é DevOps? • Se encontram nos corredores do

    evento • Trocaram altas ideias
  10. 18.

    O que é DevOps? • Se encontram nos corredores do

    evento • Trocaram altas ideias • Resolvem fundar o grupo: “Agile System Administration” [1]
  11. 19.

    O que é DevOps? Junho 2009 - Velocity 10 deploys

    per day [2] https://youtu.be/LdOe18KhtT4 John Allspaw Paul Hammond
  12. 20.

    O que é DevOps? • Patrick pelo Twitter elogia a

    apresentação e lamenta não ter visto ao vivo
  13. 21.

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

    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 !
  15. 23.

    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]
  16. 24.
  17. 25.
  18. 26.
  19. 27.

    O que é DevOps? • Cerca de 60 Developers, SysAdmins,

    Gerentes vieram de vários cantos do mundo.
  20. 28.

    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: ! ~
  21. 29.

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

    O que é DevOps? • Em 2010 DevOpsDays rolou em

    Sydney, Montain View (USA), São Paulo (Brasil) e Hamburgo
  23. 31.

    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
  24. 32.

    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
  25. 35.
  26. 36.

    Antes do DevOps ITIL na moda: • Muito estruturado (silos),

    desconfiança entre as gerências. • Burocrático e caro para entregar valor
  27. 48.

    Antes do DevOps Wall of confusion • Ninguém assume culpa,

    aponta para o outro • Não há compartilhamento de conhecimento entre as áreas
  28. 49.

    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
  29. 50.

    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
  30. 53.

    Antes do DevOps Desalinhamento de objetivos • Meta para Devs:

    entrega de funcionalidades • Meta para Sysadmins: uptime e resiliencia dos servidores
  31. 54.

    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.
  32. 62.

    Primeira Maximiza o fluxo • Torna o trabalho visível •

    Diminui o tamanho do entregável • Limita o WIP (Work in Progress)
  33. 63.

    Primeira Maximiza o fluxo • Torna o trabalho visível •

    Diminui o tamanho do entregável • Limita o WIP (Work in Progress) • Elimina desperdícios
  34. 64.

    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
  35. 69.

    Segunda Usa a entrega como aprendizado • Encurta o ciclo

    de feedback • Gera e incorpora aprendizado
  36. 70.

    Segunda Usa a entrega como aprendizado • Encurta o ciclo

    de feedback • Gera e incorpora aprendizado • Falha rápido para não impactar customers
  37. 75.

    Terceira Ciclo completo • Testes e experimentos em todas as

    partes do fluxo • Aprendizado pelas falhas
  38. 76.

    Terceira Ciclo completo • Testes e experimentos em todas as

    partes do fluxo • Aprendizado pelas falhas • Aprendizado pela prática e repetição
  39. 77.

    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
  40. 82.

    CALMS - Culture • Pessoas e processos • Sem cultura

    as demais ações falham. • Imprescindível as pessoas confiarem umas nas outras
  41. 85.

    CALMS - Automation • Traz velocidade • Elimina erros de

    processos manuais • Diminui time to market, tempo de detecção e recuperação (MTTR) ⏰
  42. 86.

    CALMS - Automation • Traz velocidade • Elimina erros de

    processos manuais • Diminui time to market, tempo de detecção e recuperação (MTTR) ⏰ • Mudanças naturalmente rastreadas e auditáveis
  43. 87.

    CALMS - Automation • Traz velocidade • Elimina erros de

    processos manuais • 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
  44. 91.

    CALMS - Lean • Eliminar desperdícios • Visibilidade do todo

    • Limita WIP • Melhora o fluxo de entregas
  45. 93.

    CALMS - Measure • Sem medir como descobrir o que

    melhorar • Identifica gargalos
  46. 94.

    CALMS - Measure • Sem medir como descobrir o que

    melhorar • Identifica gargalos • Telemetria (performance, logs)
  47. 95.

    CALMS - Measure • Sem medir como descobrir o que

    melhorar • Identifica gargalos • Telemetria (performance, logs) • Pessoas e Processos
  48. 98.

    CALMS - Sharing • Processo de loop back • Melhora

    o fluxo de comunicação • Aprendizado gera conhecimento
  49. 99.

    CALMS - Sharing • Processo de loop back • Melhora

    o fluxo de comunicação • Aprendizado gera conhecimento • Conhecimento é espalhado
  50. 106.

    ICE - Complexity • Sistemas são complexos • Mesmos simples

    blogs tem subsistemas para garantir que o conteúdo esteja disponível
  51. 107.

    ICE - Complexity • Sistemas são complexos • Mesmos simples

    blogs tem subsistemas para garantir que o conteúdo esteja disponível • Sistemas quebram
  52. 108.

    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
  53. 113.

    Por que DevOps? State of DevOps Report • Pesquisa feita

    há alguns anos com pessoas relacionadas
  54. 114.

    Por que DevOps? State of DevOps Report • Pesquisa feita

    há alguns anos com pessoas relacionadas • Identifica e compara empresas high- performance e low-performance
  55. 116.

    Por que DevOps? Último report de 2018, empresas high- performance

    vs low-performance • 46 vezes mais deploys
  56. 117.

    Por que DevOps? Último report de 2018, empresas high- performance

    vs low-performance • 46 vezes mais deploys • Depoy lead time 2555 vezes mais rápido
  57. 118.

    Por que DevOps? Último 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
  58. 119.

    Por que DevOps? Último 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
  59. 131.
  60. 132.

    Falhas - Time DevOps Time onde as pessoas • Conhecem

    todas ferramentas e tecnologias • Podem fazer qualquer coisa nas máquinas
  61. 133.

    Falhas - Time DevOps Time onde as pessoas • Conhecem

    todas ferramentas e tecnologias • Podem fazer qualquer coisa nas máquinas Mas
  62. 134.

    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
  63. 135.

    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 • Nem colocam elas nos servidores
  64. 136.

    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 • Nem colocam elas nos servidores ¯\_(ツ)_/¯
  65. 137.

    Falhas - Ferramentas • Puppet • Chef • Ansible •

    Vagrant • Terraform • Packer • Docker • Jenkins • Kubernetes • ELK O que essas ferramentas tem em comum?
  66. 141.

    Falhas - Ferramentas • Jira • Clubhouse • Trello •

    Slack • Mattermost • PagerDuty • New Relic • Datadog • Gitlab • Github E essas ferramentas?
  67. 150.

    7 Erros Mortais 1. Trabalho invisível 2. Gerencia de toil

    3. Conhecimento em tribos 4. Desalinhamento de incentivos
  68. 153.

    7 Erros Mortais 5. Design organizacional incongruente 6. Gerencia de

    complexidade 7. Teatro de segurança e conformidades
  69. 155.

    A Importância DevOps: • Não é produto • Não é

    especificação • Não é um emprego • Não é ferramenta (ou conjunto)
  70. 156.

    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…)
  71. 157.

    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
  72. 160.

    A Importância As boas consequências : • Melhora das entrega

    nas empresas onde essas pessoas envolvidas trabalham
  73. 161.

    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)
  74. 162.

    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
  75. 165.

    A Importância As más consequências : • Empresas passaram a

    perceber e querer o DevOps. • Outras se apoderam e tentam vender DevOps
  76. 166.

    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
  77. 168.

    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/
  78. 169.