Por que o desenvolvimento se opõe às operações?

Ainda sou estudante, mas não conheço operações, e meu inglês ainda é ruim.

Minha pergunta é: Por que o desenvolvimento se opõe às operações ? Quando o desenvolvimento se opõe às operações?

O ponto do DevOps é que o desenvolvimento não deve se opor às operações, mas deve se apoiar.

Tradicionalmente, devido às implantações em cascata e às atualizações em larga escala, o desenvolvimento causava operações em vários problemas durante a implantação devido a testes inadequados, alterações nos ambientes do servidor, a lista continua. Essencialmente, as atualizações eram grandes demais para que a equipe de operações pudesse implantá-las efetivamente sem que ocorram problemas no processo. Esses problemas podem ser os motivos pelos quais você acredita que o desenvolvimento se opõe às operações .

Por outro lado, o DevOps trabalha para reduzir o tamanho da atualização, diminuir ambientes rígidos e geralmente melhorar a transferência do aplicativo entre desenvolvimento e operações, aumentando a quantidade de vezes que a transferência ocorre a cada ano. Com o aumento do número de implantações, surgem menos dores de cabeça para as operações, porque elas automatizaram uma grande quantidade de trabalho necessária para atualizar os produtos ou melhor antecipar e preparar as atualizações.

O Tldr: DevOps visa anular a teoria de que o desenvolvimento se opõe às operações , criando uma mentalidade em que as operações e o desenvolvimento trabalham juntos para implantar frequentemente produtos de maneira oportuna e facilmente reproduzível.

Acho que você já recebeu respostas abrangentes, mas disse que seu inglês não é ótimo, então tentarei fornecer uma resposta muito breve e compreensível:

• O objetivo principal do desenvolvimento é fazer alterações.
• O principal objetivo das operações é manter o ambiente estável.

Essas duas coisas entram em conflito. Dito isto, desenvolvimento e operações não devem se opor. Eles devem trabalhar juntos para garantir que ambos os objetivos sejam alcançados. Esse é o objetivo do DevOps.

A tensão entre desenvolvimento e operações geralmente é causada por desalinhamento de incentivos e tentativas de otimização dentro da equipe.

Os desenvolvedores geralmente são julgados pela velocidade e quantidade de problemas que podem solucionar e mesclados no repositório de códigos, e sua recompensa geralmente não está ligada ao código que está realmente funcionando ou funcionando corretamente. Muito menos escala, desempenho e outros fatores.

As operações geralmente são julgadas na estabilidade do ambiente e em como o código funciona na produção, mas raramente na qualidade do processo para trazer mudanças rapidamente.

Isso cria o problema em que os desenvolvedores são incentivados a criar muito código e jogá-lo por cima do muro para a equipe de operações e a equipe de operações tem incentivo para aceitar o mínimo de mudanças possível para garantir a estabilidade do ambiente.

O DevOps é, de certa forma, o conjunto de soluções para esse problema:

• Alguns deles podem ser organizacionais, onde os processos e incentivos das equipes podem mudar. Por exemplo, se o trabalho dos desenvolvedores for marcado apenas como concluído quando estiver em produção há algum tempo, não haverá problemas e a equipe de operações concorda em se apropriar do código. Da mesma forma, as operações podem ser julgadas mais pela velocidade com que o código está sendo aceito, enquanto o ambiente ainda está dentro de alguns limites de estabilidade.
• Outra parte da solução pode estar na comunicação e polinização cruzada, na qual você incorpora as pessoas da operação na equipe de desenvolvimento e vice-versa. Você quebra o muro entre essas equipes e os engenheiros do DevOps geralmente são o resultado desse tipo de ponte.
• Ferramentas de suporte a processos como Integração Contínua e Implantação Contínua são outra parte da solução, que pode aumentar a velocidade das alterações, mantendo alta qualidade e recuperação rápida do ambiente de produção em caso de problemas por reversão de código ou progresso rápido de uma correção em produção.

A maioria das organizações lida com a complexidade, dividindo sua organização em partes funcionais e exigindo que cada parte descubra como se aprimorar. Isso geralmente é chamado de abordagem "silo".

É importante entender por que essa abordagem de silo bloqueia o sucesso dos negócios e geralmente falha em melhorar a organização como um todo. E isso não afeta apenas o desenvolvimento e as operações - afeta todos os outros silos funcionais de uma grande organização, como equipe de garantia da qualidade, finanças, gerenciamento de produtos e projetos.

À medida que os gerentes de cada silo funcional são ordenados a melhorar cortando custos ou aumentando a velocidade, sua reação é frequentemente:

• Estou totalmente impressionado com a correção de problemas desde o último esforço de melhoria. Me deixe em paz.
• O que você quer que eu faça, cumpra minhas responsabilidades ou trabalhe em projetos de melhoria? Eu não tenho tempo para fazer as duas coisas.
• De novo não! Aí vem outro programa do mês.

Com essas reações típicas, qualquer executivo que inicia um pequeno esforço de melhoria raramente é recebido com entusiasmo. Os gerentes se vêem em forte concorrência com outras áreas funcionais quanto aos recursos necessários para executar suas melhorias. Portanto, não é de admirar que o comando para melhorar intensifique as batalhas multifuncionais!

Mesmo quando um gerente conclui sua parte de um projeto de melhoria, ele encontra outras áreas funcionais e outras organizações (fornecedores, prestadores de serviços, etc ...) que não fizeram seu trabalho. Isso diminui ou nega totalmente os resultados.

Essa tensão multifuncional não se limita aos esforços de melhoria. É o cerne da tomada de decisões do dia-a-dia e do julgamento da eficácia do gerenciamento em uma organização. Aqui está um exemplo da vida real:

Foi dito a um gerente financeiro: "melhore". Ele decidiu bloquear a contratação de empresas que custam mais do que o preço nominal aceito no mercado. Ele implementou a nova política e alegou ter economizado US $ 1 milhão este ano. Com desenvolvedores e TI incapazes de contratar empreiteiros para ajudá-los a usar contêineres e orquestração de contêineres, uma vez que esses empreiteiros são caros. O gerente de operações de TI da mesma empresa calculou que não melhorar sua infraestrutura estava custando à empresa bem mais de US $ 100.000 em despesas extras a cada mês. Nesse ritmo, as economias anuais na contratação de empreiteiros eram devoradas antes do final do ano.

Você pode imaginar que o relacionamento entre essas duas áreas funcionais não era exatamente amoroso.

Esses conflitos interfuncionais são direcionados pela abordagem do silo, em que a organização mede cada silo em melhoria de forma independente. Se você é um centro de custos, a melhoria significa naturalmente maior eficiência ou redução de custos dentro do seu silo.

Nesse quadro de referência, os custos são vistos como obedecendo à regra "aditiva". Os custos de cada silo somados são iguais ao custo total da organização. Portanto, os gerentes veem qualquer redução de custo em sua área como "boa", uma vez que veem uma tradução direta para economia de custos para a empresa como um todo. Nesse quadro de referência, os esforços de melhoria estão espalhados por toda parte para atacar custos e desperdícios em toda a organização.

Um ótimo exemplo quando as equipes de desenvolvimento começam a trabalhar com Agile e enviam código para o QA e Operações a cada duas semanas, em vez de trimestralmente. O controle de qualidade e as operações não estão prontos para essa alteração e são responsáveis ​​pelo relaxamento. Novamente, isso não contribui muito para o amor entre as pessoas em desenvolvimento e operações.