“É possível que pessoas boas, em sistemas perversamente projetados, pratiquem ocasionalmente atos de grande prejuízo contra estranhos, às vezes sem nunca perceberem.” — Ben Goldacre, Bad Pharma.
Em um acesso de raiva causado por ler mais um e-mail em que um de nossos clientes propunha a criação de uma “equipe de DevOps” de modo a “implementar” DevOps, eu tuitei que “não existe equipe de DevOps”. Como todos os slogans, este é um pouco exagerado, então aqui vai a notícia em primeira mão: o movimento de DevOps aborda a disfunção que resulta de organizações formadas por silos funcionais. Assim, a criação de outro silo funcional que se situa entre Desenvolvimento e Operações é claramente uma forma ruim (e irônica) de tentar resolver esses problemas. Em vez disso, DevOps propõe estratégias para criar uma melhor colaboração entre os silos funcionais ou acabar com eles completamente e criar equipes transfuncionais (ou alguma combinação dessas abordagens).
Por que motivo os silos funcionais são problemáticos?
Muitas vezes silos funcionais são criados em resposta a um problema (que inevitavelmente eles pioram). No começo de uma entrevista com Elisabeth Hendrickson que eu postei recentemente, ela discute o trabalho em uma empresa de produtos que estava sofrendo uma série de problemas de qualidade. Como resultado, eles contrataram um Vice-Presidente de Controle da Qualidade que criou uma divisão de Controle da Qualidade. O resultado disso, diferente do esperado, foi aumentar o número de problemas. Uma das principais causas disso foi que os desenvolvedores sentiram que eles não eram mais responsáveis pela qualidade e, em vez disso, se concentraram em enviar os seus itens para “teste” o mais rápido possível. Assim, eles prestaram menos atenção em se certificar, em primeiro lugar, de que o sistema era de alta qualidade, o que, por sua vez, colocou mais pressão sobre os testadores. Isso criou uma avalanche de perda de qualidade que se tornou cada vez pior, o que levou ao aumento da tensão sobre os testadores e assim por diante. Elisabeth escreveu isso em um artigo chamado “Better testing – worse quality?” (Melhores testes – pior qualidade?) em 2001.
O problema fundamental é este: o mau comportamento surge quando você abstrai as pessoas das consequências de suas ações. Os silos funcionais abstraem as pessoas das consequências de suas ações. No exemplo acima, os desenvolvedores são abstraídos das consequências de escrever códigos que contêm erros.
A essência da área de DevOps, creio eu, é criar um sistema em que as pessoas sejam responsabilizadas pelas consequências de suas ações – e, de fato, um sistema no qual a coisa certa a fazer também seja a coisa mais fácil a fazer.
Há duas etapas pra isso acontecer:
- Tornar as pessoas cientes das consequências de suas ações. Pode-se conseguir isso fazendo com que os desenvolvedores se alternem em equipes de operações, fazendo com que o pessoal da área de operações participe de palestras e eventos para desenvolvedores, organizando almoços seguidos de cursos, ao motivar as pessoas a escreverem blogs, ou por simplesmente almoçar com alguém que trabalha em um silo funcional diferente do seu.
- Tornar as pessoas responsáveis pelas consequências de suas ações. É aí que as coisas ficam sérias. Você pode conseguir isso fazendo com que os desenvolvedores carreguem pagers ou sejam os responsáveis pelos contratos de nível de serviço relativos aos produtos e serviços que eles criam (por exemplo, a equipe de desenvolvimento é o suporte L3 e é responsável pelo tempo operacional do serviço).
A principal razão pela qual as pessoas não conseguem passar para a etapa 2 no plano é que a maioria das grandes organizações simplesmente não é estruturada de uma forma que possibilite isso. O culpado aqui é o fato de que os esforços de desenvolvimento de software são geralmente executados como se fossem projetos de engenharia civil. Quando o projeto está concluído, o sistema é atirado por cima do muro para que a área de operações execute e mantenha como parte de um ‘esforço habitual’, e todas as pessoas na equipe do projeto são realocadas para um novo trabalho. Esse modelo de projeto é fundamentalmente falho como uma maneira de fazer desenvolvimento de software – o desenvolvimento de software deveria ser tratado, em vez disso, como desenvolvimento de produto.
A melhor maneira de todas de tornar as pessoas responsáveis pelas consequências de suas ações é criar equipes transfuncionais para cada produto ou serviço. Como Werner Vogels, Diretor de Tecnologia da Amazon, diz: “você cria, você conduz.” (Vale a pena ler essa excelente entrevista na íntegra).
Uma maneira muito ruim de tentar resolver esse problema é inserir outro nível de ação indireta entre a equipe de desenvolvimento e operações e chamá-la de “equipe de DevOps”. É isso que eu quero dizer quando estou argumentando contra a criação de uma “equipe de DevOps” – além das equipes existentes de desenvolvimento e operações – cuja tarefa é ser responsável pela implantação do sistema (essas equipes eram tradicionalmente chamadas de “Release management” antes de desenvolvimento e operações se tornarem tendência).
Por que motivo a separação de tarefas não funciona
Às vezes, as pessoas argumentam que esse modelo é impossível por causa de alguma lei ou regulamentação (por exemplo, Sarbanes-Oxley, PCI-DSS) ou de alguma convenção (ITIL, COBIT) que determina a separação de tarefas. A separação de tarefas é essencialmente a ideia de que a raposa não deve guardar o galinheiro: que a tarefa do grupo de testes ou de operações é atuar como um conjunto de pesos e contrapesos para evitar fraudes ou códigos que contenham erros criados por desenvolvedores que entram na produção.
É importante ressaltar, antes de tudo, que essa abordagem não funciona exatamente pelos motivos discutidos no artigo de Elisabeth Hendrickson. É um exemplo do que eu chamo de “área de gestão dos riscos” (por analogia com área de segurança) – assim como a segurança aeroportuária reforçada da TSA (Agência de Segurança dos Transportes dos EUA), ela “não realiza nada a um custo enorme”, dando a impressão de que você está gerenciando o risco de fazer alterações no ambiente de produção enquanto, na verdade, está piorando a situação.
Um colega meu debate um processo de gestão de mudanças (felizmente aposentado) em um grande fabricante europeu que envolve os desenvolvedores preencherem uma planilha com sete abas que depois é enviada por e-mail para um gerente de mudanças em outro país que tem de decidir se quer ou não aprová-la. O gerente de mudanças não tem ideia do que está escrito na planilha e fala com os desenvolvedores para entender se a mudança é arriscada e quais estratégias de mitigação existem. Os desenvolvedores sabem disso e fazem a mínima quantidade possível de trabalho para preencher a planilha. O gerente de mudanças sabe que os desenvolvedores não estão fazendo o trabalho mais completo com a planilha, mas não faz diferença para eles, desde que a planilha seja apresentada.
Isso não é gestão dos riscos; é um ‘teatro’ de gestão dos riscos.
E esse argumento – de que a colaboração entre silos, ou até mesmo de equipes transfuncionais, é proibido pelo regulamento ou pela “melhor prática” – é um exemplo do que nós, no setor de consultoria, chamamos de ‘cortina de fumaça’. Então permita que eu esclareça isso. Em nenhum lugar as normas Sarbanes-Oxley, ITIL e COBIT determinam a separação de tarefas. A COBIT v5 nem sequer possui um controle chamado de “separação de tarefas”. A norma PCI-DSSrealmente exige a separação de tarefas, na sua forma atual, mas isso não significa que as pessoas não possam colaborar. Eu recentemente filmei Michael Rembetsy, diretor de engenharia de operações da Etsy, falando sobre como eles implementam a separação de tarefas na Etsy para alcançar conformidade com a norma PCI-DSS.
O Papel das Operações
OK, eu menti quando eu disse que não existe equipe de DevOps.
Para que os desenvolvedores assumam responsabilidade pelos sistemas que eles criam, eles precisam de apoio da área de operações para entender como criar software confiável que possa ser continuamente implantado em uma plataforma não confiável que seja horizontalmente escalável. Eles precisam ser capazes de fazer manutenção sem assistência em ambientes e implantações. Eles precisam entender como escrever códigos passíveis de teste e manutenção. Eles precisam saber como fazer pacotes, implantação e suporte pós-implantação.
Alguém precisa apoiar os desenvolvedores nisso e se você quiser chamar as pessoas que fazem isso de “Equipe deDevOps”, por mim tudo bem. O ponto crucial é este: a “Equipe de DevOps” não é responsável pelos sistemas que são criados, nem por implantá-los, nem por escrever os scripts de versão e de implantação, e nem pelo funcionamento desses sistemas. Também não deve haver “especialistas em DevOps” nas equipes de desenvolvimento que fazem esse trabalho: isso é tarefa fundamental do desenvolvedor, assim como escrever códigos, e os desenvolvedores precisam ter a posse disso.
Eis aqui o que a Equipe de DevOps faz neste modelo:
- Cria uma plataforma que permite aos desenvolvedores fazer manutenção sem assistência em ambientes para testes e produção (e implantações para esses ambientes) e fornece métricas para a organização como um todo. Essa plataforma é um produto e a equipe que a cria está fazendo o desenvolvimento de produtos, o que (precisamente) significa que as pessoas que usam a plataforma são seus clientes.
- Fornece uma cadeia de ferramentas que os desenvolvedores podem usar para criar, testar, implantar e executar os seus sistemas.
- Treina equipes que estão trabalhando para avançar para este modelo e fornece suporte e treinamento para a plataforma e para a cadeia de ferramentas.
Realmente, tudo isso é parte do trabalho da área de operações. Mas se você quiser chamar as pessoas que fazem isso de sua “equipe de DevOps”, tudo bem também
Leitura Extra
- Eu sou totalmente a favor da gestão de mudanças, desde que de uma forma leve, conforme descrito aqui.
- Eu e minha colega Joanne Molesky escrevemos um artigo que fala sobre desenvolvimento e operações, entrega contínua e gestão de riscos em um contexto corporativo para o periódico Cutter IT Journal. Você pode baixá-lo de graça aqui.
- Eu dei uma palestra que trata de uma série dessas questões na GOTO Aarhus em 2011. Vídeo | Slides
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.