Desenvolvimento

17 dez, 2013

Fazendo Devops funcionar fora de Webops

Publicidade

Eu passei os últimos três anos aprendendo mais sobre devops. Fui ao Velocity, ao Devopsdays e a um monte de outras conferências que incluíam coisas de devops (como as últimas conferências OWASP EUA e a Agile deste ano). Eu tenho acompanhado fóruns devops, notícias, lido livros sobre o assunto e experimentado ferramentas devops e Entrega Contínua, conversado com pessoas inteligentes que trabalham em lojas devops de sucesso, incentivado pessoas na minha organização a adotar algumas dessas ideias e ferramentas onde elas fazem sentido. Ao procurar por práticas, padrões e tecnologias, podemos aplicá-los ao trabalho que fazemos, que está em uma empresa, o ambiente B2B.

Um problema para nós é que devops hoje ainda está em sua maior parte onde começou, enraizado no Web Ops com foco na construção e ampliação de lojas e comunidades online e serviços de cloud – exceto, talvez, em alguns fornecedores de tecnologia em que a empresa já entrou na onda devops para remarcar suas ferramentas.

Há realmente muito em uma organização empresarial de TI altamente regulada bem administrada ligada a centenas ou milhares de outras empresas que podem aprender a partir de uma startup de tecnologia tentando lançar uma nova comunidade social online ou um jogo online multiplayer, ou mesmo maior, lojas DevOps mais maduras como Etsy ou Netflix? Será que as mesmas regras e ideias se aplicam?

A resposta é: sim às vezes, mas não, nem sempre.

Existem alguns fatores importantes que separam as empresas da maioria das lojas devops hoje.

Heterogeneidade da plataforma e a necessidade de suportar sistemas legados e todas as interdependências entre os sistemas operacionais é um – você não pode fingir que pode cuidar de seus problemas de gerenciamento de configuração usando Puppet ou Chef em uma empresa que foi construída ao longo de muitos anos, através de fusões e aquisições e que tem de suportar milhares de aplicações diferentes em dezenas de plataformas tecnológicas distintas. Muitos desses apps são aplicativos de terceiros, sobre os quais você não tem controle. Algumas dessas plataformas são sistemas legados que não são mais suportados. Algumas dessas configs são únicas como flocos de neve, porque essa é a única forma de alguém fazer as coisas funcionarem.

Governança e conformidade regulamentar (e toda a papelada e aborrecimento que vem com isso) é outro. Mesmo lojas devops não lidam com suas funções de negócio do núcleo altamente reguladas, o mesmo que eles fazem com o resto de seu código (um bom exemplo é a forma como Etsy atende a conformidade com o PCI).

Há outros dois fatores importantes que separam muitas empresas, como as grandes instituições financeiras da maneira que uma loja devops funciona: a necessidade de velocidade na mudança, e o custo do fracasso.

A necessidade de velocidade

Se “como posso mudar as coisas mais rápido?” é a questão, devops parece ser a resposta.

Devops permite – e enfatiza – uma rápida mudança contínua, através da automação implacável, derrubando paredes entre desenvolvedores e operações, e por meio de práticas como a implementação contínua, na qual os desenvolvedores empurram as alterações de código para produção várias vezes ao dia.

Ser capaz de se mover tão rapidamente é importante nos estágios iniciais de concepção e desenvolvimento iterativo, para startups online que precisam construir uma massa crítica de clientes antes que fiquem sem dinheiro, e outras organizações que experimentam um hiper crescimento. Cada organização tem alguns sistemas que precisam ser mudados frequentemente, e que possam ser alterados com o mínimo de impacto: os sistemas de CRM, análise e relatórios de gestão interna, por exemplo. E, como James Urqhuart explica, otimizar a mudança faz sentido quando você precisa mudar a tecnologia muitas vezes.

Mas há outros sistemas que você não precisa ou que você não pode mudar a cada dia, a cada semana ou a cada mês: ERP e sistemas de contabilidade, manuseio de pagamento, sistemas transacionais B2B, controle industrial. Onde você não precisa e não quer executar experiências em seus clientes para testar novas funcionalidades ou constantemente aperfeiçoar os detalhes de sua experiência de usuário, pois o sistema já funciona e muitas pessoas estão dependendo de que ele funcione de certa forma, e o que é realmente importante é manter o sistema funcionando corretamente e manter os custos operacionais baixos. Ou onde a mudança é arriscada e cara por causa das exigências regulatórias e de conformidade e interdependências com outros sistemas operacionais e outras organizações. E onde o custo do fracasso é alto.

Mudar, mesmo quando você otimiza, sempre vem com o risco de fracasso. O Relatório Estado de DevOps concluiu que lojas devops de alto desempenho implementam o código 30x com mais frequência, com “o dobro da taxa de sucesso de mudança”. Por si só, esses números são impressionantes. Tomados em conjunto – eles não são bons o suficiente. Mudar mais vezes ainda significa falhar mais do que uma organização que se move mais lentamente e com mais cautela, e nem todas as organizações podem se dar ao luxo de falhar com mais frequência.

O custo do fracasso

A maioria das empresas online existe em um mundo mais simples e mais inocente, no qual a mudança é direta – é o seu código e a sua nuvem para que você possa fazer uma mudança e empurrá-lo sem se preocupar com dependências de outros sistemas e as pessoas que os utilizam, ou como coordenar um lançamento global em diferentes empresas e linhas de negócios – e onde as consequências do fracasso não são realmente altas.

Se você não está cobrando nada (Facebook, Twitter), ou quase nada (Netflix) dos clientes para usarem seu serviço, e se o custo do fracasso para os clientes não é muito (eles têm que esperar um pouco para dizer às pessoas que seu gatinho apenas espirrou ou para postar uma foto de seu peixe ou assistir a um filme), então ninguém tem o direito de esperar muito quando algo dá errado.

É um mundo completamente diferente para o das empresas de serviços financeiros, no qual o fracasso nem sempre é uma opção – e “falhar rápido, falhar muitas vezes” funciona no estágio inicial de desenvolvimento, quando os clientes ainda não estão usando a sua tecnologia.

Eu ouvi de um executivo de tecnologia em um banco que Etsy (ou qualquer empresa de web) não foi um esforço “sério” , que o seu banco trabalha com “dinheiro sério”, o que significa que eles não podem “brincar” como as empresas web fazem. Eu também vi empresas web sujarem a empresa, porque eles são “mimados” com a sua base de usuários pequena e ambientes de trabalho não 24×7.

Até que haja um entendimento comum entre os grupos, a troca saudável e madura de ideias e conceitos vai ser lenta. John Allspaw, entrevista, Is the Entrerprise Ready for DevOps?

Esse executivo bancário, ainda que não tenha sido diplomático, está certo.

O custo e os riscos envolvidos em uma falha têm várias ordens de magnitude diferentes entre um banco e uma empresa web, até mesmo algo tão grande como Etsy. Em uma apresentação no final de 2012, o CTO da Etsy se gabou de que eles lidando com “dinheiro real” , de “US$ 1k por minuto” na época. Enquanto isso é dinheiro real para clientes reais no Etsy (e tenho certeza de que esse número é maior agora), é insignificante em comparação com o valor das operações com que qualquer grande instituição financeira lida.

Não existem erros que uma empresa como a Etsy ou mesmo o Facebook poderia cometer que poderiam ser comparados ao impacto de uma falha do sistema de um grande banco, ou um processador de cartão de crédito ou uma grande bolsa de valores, câmara de compensação financeira corretora, ou alguma outra grande instituição financeira.

Isso não é apenas por causa do alto valor das transações envolvido nesses sistemas. É também por causa da reação em cadeia que essas falhas têm sobre outras instituições nos sistemas dos sistemas nacionais e internacionais em que essas organizações operam – o impacto sobre o parceiro e o sistemas dos clientes, e sobre os seus clientes e parceiros, e assim por diante. Os custos dessas falhas podem ser executados em milhões ou centenas de milhões de dólares, muito mais se você incluir os custos de oportunidade perdidas e os custos downstream de responder à falha (incluindo os custos de TI para atualizar ou substituir todo o sistema, o que é uma resposta comum a uma grande falha), não importa o custo subsequente de maior supervisão regulamentar que muitas vezes é exigido em toda uma indústria depois de uma falha no sistema de alto perfil.

Problemas dessa escala simplesmente não acontecem quando um e-business online ou rede social falha, mesmo se falhar espetacularmente. É um inconveniente para os clientes, e é um custo real para o negócio online, mas as falhas não são em cascata para outras empresas e indústrias, a não ser talvez se a infraestrutura AWS da Amazon falhar de forma significativa e as empresas online que dependem dela sejam deixadas em suspensão, que o parece acontecer um par de vezes a cada ano.

Não é o suficiente para que muitas empresas e plataformas B2B ainda menores otimizem MTTR e se esforcem mais da próxima vez ou aceitem que roll-back é um mito e que “homens de verdade apenas rolam para a frente” – e das contínuas histórias de fracassos de alto perfil em organizações online isso não é suficiente para as organizações devops quando atingem um certo tamanho também.

Mas você ainda pode aprender muito com Devops

Não é que devops não irá funcionar na empresa. Mas não o devops como é descrito na maior parte até agora. Devops exagera o “tudo precisa mudar mais rápido e com mais frequência “, e simplifica alguns dos outros problemas que muitas organizações enfrentam se não o fizerem ou não puderem executar tudo na nuvem. Mas ainda há muito que aprender com os líderes devps, mesmo se suas histórias, prioridades, limitações e situações de negócios não combinem.

Podemos certamente aprender com eles sobre como executar uma presença escalável na Web e sobre como mover coisas para a nuvem.

Podemos aprender a tirar mais do risco e do custo de gerenciamento de mudanças, simplificando e padronizando as configurações sempre que possível e simplificando e automatizando testes e etapas de implementação, tanto quanto possível – mesmo que não vá mudar as coisas todos os dias.

Mas, por agora, provavelmente a coisa mais valiosa que devops traz para aqueles de nós que não trabalham nas lojas Web online não são ferramentas ou práticas. É que o devops está criando novas razões e mais oportunidades para dev, Ops e gestão se envolverem uns com os outros, à medida que eles tentam descobrir o que é devops e como isso faz sentido em nossas organizações.

Para ter desenvolvedores, gerentes e Ops falando juntos de gerenciamento de configuração e como melhorar a liberação, a implementação, o alerta de tempo de execução, o monitoramento de aplicativos e o tempo de execução de exames de saúde, e como desenvolvedores e Ops podem aprender com os fracassos juntos. Fazer desenvolvedores e Ops pensarem sobre esses problemas e tentar resolvê-los em conjunto, de forma colaborativa e construtiva, como ITIL certamente nunca o fez. Passar mais tempo na resolução de problemas e menos tempo com a burocracia dispendiosa e fanfarrona. Isso tem que ser uma coisa boa.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2013/10/making-devops-work-outside-of-webops.html