DevOps em grandes empresas - Mito ou Realidade?

Notas do Editor

• #6: 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.
• #7: 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
• #10: 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.
• #11: 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.
• #12: 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.
• #13: 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.
• #14: 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.
• #15: 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."
• #16: 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).
• #17: “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.
• #21: 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
• #22: 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
• #23: 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