DevOps em grandes empresas - Mito ou Realidade?
•Transferir como PPTX, PDF•
0 gostou•407 visualizações
O documento discute DevOps em grandes empresas, argumentando que é uma realidade e não um mito. Apresenta os principais mitos sobre DevOps e como as empresas podem adotar práticas DevOps através de três caminhos: pensamento sistêmico, ampliação de loops de feedback e cultura de experimentação contínua. Finalmente, mostra dados de pesquisas que indicam que empresas de alto desempenho adotam práticas DevOps.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (15)
Semelhante a DevOps em grandes empresas - Mito ou Realidade?
Semelhante a DevOps em grandes empresas - Mito ou Realidade? (20)
Mais de Igor Abade
Mais de Igor Abade (20)
DevOps em grandes empresas - Mito ou Realidade?
- 3. CLOUDMOT ION DevOps em grandes empresas MITO OU REALIDADE? Igor Abade V. Leite CEO, Cloud Motion Microsoft Regional Director CLOUDMOT ION
- 4. CLOUDMOT ION Por quê falar de DevOps? DEVOPS EM GRANDES EMPRESAS: MITO OU REALIDADE?
- 5. “50% das empresas na Fortune 500 no ano 2000 foram substituídas por organizações que usam tecnologia para entregar valor a seus clientes mais rápido, melhor, e mais barato. As Fortune 500 de hoje encontrarão o mesmo desafio amanhã” Innosight | Corporate Longevity: Turbulence Ahead for Large Organizations Por quê falar de DevOps?
- 6. Por quê falar de DevOps?
- 7. Por quê falar de DevOps? 2019 Accelerate State of DevOps - https://cloud.google.com/devops/state-of-devops/
- 8. CLOUDMOT ION Mitos e Verdades DEVOPS EM GRANDES EMPRESAS: MITO OU REALIDADE?
- 10. “DevOps substitui o Agile”
- 11. “DevOps é incompatível com Segurança e Compliance”
- 12. “DevOps é eliminar o time de Infraestrutura (‘NoOps’)”
- 13. “DevOps é automação, ou ‘Infraestrutura como código’”
- 14. “DevOps é só para Software Open Source”
- 15. “DevOps é só para Startups”
- 16. CLOUDMOT ION Em busca do DevOps DEVOPS EM GRANDES EMPRESAS: MITO OU REALIDADE?
- 17. A jornada é mais importante que o destino Famoso (e batido) chavão da Internet
- 18. “Os Três Caminhos” •Systems Thinking •Amplify feedback loop •Culture of continual experimentation and learning
- 19. 1º. Caminho: “Systems Thinking” ◦ Entender o fluxo de trabalho (“Understand the flow of work”) ◦ Buscar sempre aumentar o fluxo (“Always seek to increase flow”) ◦ Nunca passe defeitos conhecidos para a frente (“Never pass known defects downstream”) ◦ Nunca permitir que otimização local crie degradação global (“Never allow local optimization to create global degradation”) ◦ Alcançar uma compreensão profunda do sistema (“Achieve profound understanding of the system”)
- 20. 2º. Caminho: “Amplify feedback loop” ◦ Encurtar e amplificar os loops de feedback (“Shorten and amplify feedback loops”) ◦ Compreender e atender às necessidades do cliente (“Understand and meet the needs of the customer”) ◦ Assegurar-se de que as pessoas têm a informação que precisam (“Make sure that people have the information they need”)
- 21. 3º. Caminho: "Continual experimentation/Learning” ◦ Cultura de experimentação contínua (“Culture of continual experimentation”) ◦ Aprendizagem do fracasso (“Learning of failure”) ◦ A repetição é o pré-requisito para o domínio (“Repetition is the prerequisite for mastery”)
- 22. As quatro métricas-chave LEAD TIME DEPLOYMENT FREQUENCY MEAN TIME TO RESTORE (MTTR) CHANGE FAIL PERCENTAGE https://www.thoughtworks.com/radar/techniques/four-key-metrics
- 23. Mais métricas DevOps Data-Driven DevOps: Use Metrics to Help Guide Your Journey - Gartner May 29 2014
- 24. Cultura DevOps The five keys to a successful Google Team https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/ DevOpsCulture https://martinfowler.com/bliki/DevOpsCulture.html
- 25. CLOUDMOT ION Como estão as outras empresas? DEVOPS EM GRANDES EMPRESAS: MITO OU REALIDADE?
- 26. Accelerate State of DevOps O relatório “Accelerate State of DevOps” representa seis anos de pesquisa e dados de mais de 31.000 profissionais em todo o mundo. É a maior e mais longa pesquisa de seu tipo, proporcionando uma visão independente das práticas e capacidades que impulsionam o alto desempenho.
- 27. Demographics & Firmographics Indústria Funcionários
- 28. Demographics & Firmographics Sistemas Operacionais Departamentos
- 32. CLOUDMOT ION Dúvidas? DEVOPS EM GRANDES EMPRESAS: MITO OU REALIDADE?
- 33. Brindes #developerssergipe Ao final do evento, faremos sorteios de brindes!
Notas do Editor
- Disruption affects every industry and no company is safe – we all have heard about the now classic examples of Blockbuster being ousted by Netflix, Lyft & Uber disrupting the traditional taxi industry, and even Twitter changing how we consume news and media. Half of the companies that were on the Fortune 500 in 2000 are now gone, replaced by organizations that deliver value faster, better, and cheaper than the incumbents did – and the current Fortune 500 very much faces the same fate. Technology plays a central role in the disruptors‘ ability to execute and out innovate their competition.
- Traditional methods of delivering and operating software need re-thinking, especially in a cloud based world. A business needs to move fast and innovate But because of the manual nature of deployments and the siloed organizational structures, processes and tools – human error is inevitably introduced which leads to: High failure rates when changes are implemented and Long times to recover from outages In a bid to improve reliability in these situations, we traditionally implement further controls – via more manual processes, and approval gates. But, this doesn’t improve overall system reliability, and merely introduces: Long lead times for changes and Low deployment frequency
- DevOps não é algo novo. A palestra que marca o “nascimento” do movimento DevOps é de 2009. Conceitos como o Movimento Lean, o Manifesto Ágil, Agile Infrastructure e outros, nos quais DevOps está amparado, são ainda mais antigos. DevOps já esteve no pico do “hype” do Gartner, sim. Mas em 2015. Hoje DevOps é um modelo estabelecido e usado em empresas dos mais diversos segmentos e tamanhos em todos o mundo.
- Os princípios e práticas de DevOps são compatíveis com o Agile, com muitos observando que o DevOps é uma continuação lógica da jornada ágil iniciada em 2001. O Agile geralmente serve como um facilitador efetivo do DevOps, devido ao seu foco em equipes pequenas que entregam continuamente código de alta qualidade aos clientes. Muitas práticas de DevOps emergem se continuarmos a gerenciar nosso trabalho além do objetivo de "código potencialmente implantável" no final de cada iteração, estendendo-o para ter nosso código sempre em um estado implantável.
- Muitos vêem DevOps como um golpe no ITIL ou ITSM (IT Service Management), originalmente publicado em 1989. ITIL tem influenciado amplamente várias gerações de praticantes de operações, e é uma biblioteca de práticas em constante evolução destinada a documentar processos e práticas que sustentam as operações de TI. As práticas de DevOps podem ser feitas de modo a serem compatíveis com o processo ITIL. No entanto, para dar suporte aos prazos de execução mais curtos e às freqüências de implantação mais altas associadas ao DevOps, muitas áreas dos processos ITIL se tornam totalmente automatizadas, resolvendo muitos problemas associados aos processos de configuração e gerenciamento de Release (por exemplo, manter o CMDB atualizado). E como o DevOps requer detecção e recuperação rápidas quando ocorrerem incidentes de serviço, as disciplinas ITIL de design de serviço, incidente e gerenciamento de problemas permanecem tão relevantes quanto sempre.
- A ausência de controles tradicionais (por exemplo, segregação de responsabildiade, processos de aprovação de mudanças, revisões de segurança manual no final do projeto) podem espantar os profissionais de segurança e conformidade da informação. No entanto, isso não significa que as organizações de DevOps não tenham controles efetivos. Em vez de atividades de segurança e conformidade apenas sendo executadas no final do projeto, os controles são integrados em todas as fases do trabalho diário no ciclo de vida de desenvolvimento de software, resultando em melhores resultados de qualidade, segurança e conformidade.
- Muitos interpretam DevOps como a eliminação completa da função Operações de TI (Infraestrutura). No entanto, isso raramente é o caso. Embora a natureza do trabalho de Infraestrutura possa mudar, ele permanece tão importante quanto sempre. O pessoal de Infraestrutura passa a a colaborar muito mais cedo no ciclo de vida do software com os Desenvolvedores, que por sua vez continuam a trabalhar com Infraestrutura muito tempo depois que o código foi implantado em produção. Em vez de a Infraestrutura fazer trabalho manual que vem de tickets de suporte, DevOps oferece a produtividade aos times por meio de APIs e plataformas de autoatendimento que criam ambientes, testam e implantam código, monitoram e exibem a telemetria de produção e assim por diante. Ao fazer isso, a equipe de Infraestrutura se torna mais próxima do desenvolvimento (como QA e INFOSEC) e envolvidos no desenvolvimento de produtos, onde o produto é a plataforma que os desenvolvedores usam para testar, implantar e executar seus serviços de ti em produção de forma segura, rápida e segura.
- Embora muitos dos modelos de trabalho de DevOps exijam automação, o DevOps também requer normas culturais e uma arquitetura que permitam que as metas compartilhadas sejam alcançadas em todo o fluxo de valor de TI. Isso vai muito além de apenas automação. Como Christopher Little, um executivo de tecnologia e um dos primeiros cronistas do DevOps, escreveu, "o DevOps não é sobre automação, assim como a astronomia não é sobre telescópios."
- Embora muitas histórias de sucesso de DevOps tenham lugar em organizações que usam softwares como o stack LAMP (Linux, Apache, MySQL, PHP), alcançar resultados de DevOps é independente da tecnologia que está sendo usada. Inúmeros casos de sucesso em .NET, COBOL, Assembly de mainframe (!), SAP e sistemas embarcados (ex.: firmware HP LaserJet).
- “Unicórnios” da internet (Google, Amazon, Netflix, Etsy etc.) são pioneiros nas práticas de DevOps Ainda assim correram o risco, em algum momento, de ficarem para trás por causa dos problemas associados com organizações mais tradicionais: Lançamentos de código altamente perigosos e propensos a falhas catastrófica Incapacidade de liberar recursos rápido o suficiente para vencer a concorrência Incapacidade de escala, altos níveis de desconfiança entre Desenvolvimento e Operações, e assim por diante. No entanto, cada uma dessas organizações foi capaz de transformar sua arquitetura, práticas técnicas e cultura para criar os resultados incríveis que associamos ao DevOps.
- Systems thinking O primeiro caminho enfatiza o desempenho de todo o sistema, versus o desempenho de um silo específico de trabalho ou departamento. O trabalho pode ser tão grande quanto uma divisão (desenvolvimento ou infraestrutura) ou tão pequeno quanto um contribuidor individual (um desenvolvedor ou um administrador de sistemas). O foco é em todos os fluxos de valor de negócios, desde quando os requisitos são identificados, passando por desenvolvimento e, em seguida, chegando em produção, onde o valor é entregue ao cliente na forma de um serviço. Os resultados do primeiro caminho incluem: Nunca passar um defeito conhecido para centros de trabalho posteriores no processo Nunca permitir que otimização local crie degradação global Sempre procurar aumentar o fluxo Sempre tentar entender profundamente o sistema
- Amplify feedback loop O segundo caminho trata de criar os loops de feedback da direita para a esquerda. Como em quase qualquer iniciativa de melhoria de processo, o objetivo é encurtar e amplificar os loops de feedback, para que as correções necessárias possam ser feitas continuamente. Os resultados do segundo caminho incluem: Entender e responder a todos os clientes, internos e externos Diminuir e amplificar todos os loops de feedback Integrar conhecimento onde é necessário
- Culture of continual experimentation and learning O terceiro caminho envolve a criação de uma cultura que promove: Experimentação contínua, que exige correr riscos e aprender com o sucesso e com o fracasso Entender que repetição e prática são pré-requisitos para dominar algo Os dois itens acima têm a mesma importância e necessidade. Ambos garante. que você continua se esforçando para melhorar, mesmo que isso signifique entrar na zona de perigo. E você precisa dominar as qualificações que podem ajudar a sair da zona de perigo quando tiver ido fundo demais nela. Os resultados do terceiro caminho incluem: Alocar tempo para melhorar o trabalho diário Criar rituais que recompensam a equipe por correr riscos Introduzir falhas no sistema para aumentar a resiliência