Prós / contras de interromper um fluxo de trabalho do DevOps?

Estou tentando avaliar se é uma boa ideia sair do fluxo de trabalho no estilo devops para os dev-then-ops tradicionais (não tenho certeza do que você chama assim).

Somos um pequeno departamento para 5 pessoas, escondido em uma empresa de mídia tradicional de 4.000 funcionários (por exemplo, que não seja de software). Há dois anos, começamos a criar software para permitir que nosso departamento aumentasse significativamente nossa produção. Temos sido bem-sucedidos e a maior empresa está começando a perceber. Até o momento, somos os únicos responsáveis ​​pelo design, desenvolvimento e implantação do que se tornou uma plataforma de microsserviço da AWS com 10 serviços. Nossa equipe não se identifica como DevOps, mas sem dúvida estamos vivendo a vida do DevOps, com cada desenvolvedor intimamente familiarizado com o código e o sistema em que é executado.

Uma das perguntas que enfrentaremos em breve é ​​que "eficiências" são compartilhadas entre nós e o departamento de TI de nossa empresa controladora. Nosso proprietário do projeto geralmente prefere a terceirização do que o aprendizado interno, portanto, no nosso caso, essas eficiências provavelmente significam obter o máximo possível de trabalho de TI. Atualmente, eu diria que nossa equipe tem uma divisão de 70/30% entre a experiência em codificação e infraestrutura. O departamento de TI está solidamente na área de TI, sem cruzamento visível no desenvolvimento de software.

O proprietário do projeto (um indivíduo não técnico) espera que, ao entregar o máximo de trabalho possível à equipe de TI, veremos um aumento de ~ 1: 1 na produtividade para cada hora de trabalho que perdemos. Eu sou cético sobre isso, no entanto. Nosso produto ainda é pré-beta (apesar de já ser um ativo comercial significativo) e, em nossa experiência limitada com o departamento de TI, geralmente existem atrasos significativos para coisas tão simples quanto as alterações na permissão do sistema de arquivos.

No momento, minha solução ideal seria que o departamento de TI nos "adotasse" e nos permitisse continuar implantando nosso próprio trabalho, garantindo ao mesmo tempo que cumprimos os padrões e requisitos do escritório de TI. Não tenho certeza de quão realista é isso. Além disso, é quase a abordagem oposta que o proprietário do nosso projeto está defendendo, uma vez que adicionaria operações adicionais a curto prazo.

Em nossa situação, quais são os possíveis prós / contras de permanecer com a abordagem DevOps versus entregar a TI?

Não é uma boa ideia.

Na minha experiência, você obterá as desvantagens de ambos, enquanto as vantagens projetadas falharão em se materializar.

Especificado:

1. Você vai perder velocidade.
   A TI cumprirá seu próprio padrão. A nova tarefa (para eles) seguirá o mesmo modelo 'lento' que todo o trabalho deles agora possui. Esteja preparado, eles acharão um desafio - portanto, menos velocidade do que as ações simples padrão.
2. Você falhará ao descarregar.
   A TI se apoia em vocês para cada anomalia. Você se esforçará para acelerar a velocidade de um cara - e a próxima coisa que se repetirá agora é que, na tarefa / problema / dia seguinte, haverá um novo cara.
3. A documentação será necessária, mas não ajudará.
   Novamente, o comportamento do modelo será que manuais curtos não conseguirão capturar todas as anomalias, e textos completos não serão lidos por muito tempo. Portanto, qualquer investimento aqui será uma perda, da mesma forma o enorme esforço necessário para implementar melhorias para que suas ferramentas tenham a qualidade "encolhida".

Por último, mas não menos importante, quaisquer problemas refletirão em vocês. Tar, princípio tarbrush.

Se o exposto acima parece cínico, bem, eu tenho medo de estar lá. Repetidamente.

O que fazer em vez disso?

Faça compras no departamento de TI, encontre um candidato útil e mantenha esse cara 'emprestado' para aliviar sua carga de trabalho.

Você pode encontrar muitas das respostas no resultado da pesquisa do DevOps que você deve solicitar ao proprietário do produto para ler. Este é um documento escrito especificamente para pessoas de negócios com pouco conhecimento técnico falando nos termos que ele deve entender.

Em média, você precisará de um desenvolvedor extra para cada 4 pessoas para manter o mesmo nível de desenvolvimento de recursos (38% versus 49% de tempo gasto em novos trabalhos). Seu tempo médio para se recuperar de uma falha cairá até 25 vezes. Seu trabalho será 20% menos agradável e você terá 40% de probabilidade de recomendar seu trabalho a um amigo. Apenas esses três fatos devem ser suficientes.

O que você perderá ao se integrar à organização de TI é a parte "Dev" da sua pequena equipe de DevOps. Quando as equipes se tornam segmentadas em funções artificiais do NetOps, SysOps e Dev, você apresenta os seguintes problemas:

1. Burocracia e isolamento desnecessários - para fazer qualquer coisa, os desenvolvedores terão que enviar um ticket à TI e aguardar a implementação. Eles não poderão mais implementar e interagir com eles mesmos - incluindo e até as instâncias de Dev e QA, o que limitará a infraestrutura que eles podem codificar. Eles estão presos na barreira da VM em vez de serem capazes de codificar na pilha completa. Se o que eles enviarem para a TI parecer com o código do DevOps, eles estarão mal equipados para lidar com isso e poderão voltar às implantações manuais.
2. Negligenciar - Como alternativa, eles podem simplesmente implantá-lo como está e depois negligenciar o animal porque não sabem como interagir com ele - e não são desenvolvedores, portanto o código não é problema deles.
3. Interrupções - Um dos benefícios muitas vezes esquecidos do DevOps é a natureza programática. Claro, pode levar mais tempo para implantar esse servidor tratando-o como código, mas isso automatiza os erros humanos. O modo como ele entrou no desenvolvimento é o modo como ele entra no controle de qualidade / teste, o modo como ele entra no produto, reduzindo as interrupções. Quando os desenvolvedores perdem o acesso ao equipamento de rede, eles precisam implantar seu serviço ou a infraestrutura de computação não apenas leva mais tempo, como também introduz humanos mais falíveis que causam mais interrupções.
4. Documentação - Em alguns sentidos, o código do DevOps é auto-documentável. Você sabe como o servidor foi criado e implantado porque o código informa. Em cinco anos, quando for a hora de atualizar para o CentOS 8 ou qualquer outra coisa, ninguém saberá mais como implantar seu aplicativo - incluindo as camadas de rede, armazenamento, monitoramento e backup.

Em resumo, você deve sugerir que o proprietário do projeto leia The Mythical Man-Month para desiludir a noção de que você verá um relacionamento 1: 1 em produtividade e o The Phoenix Project, que é um bom romance (e ilustração divertida) do que é ganho e perdido usando o DevOps em linguagem não técnica para pessoas não técnicas. Se o proprietário do projeto tiver algum tipo de deslocamento, um audiolivro do Audible Project estará disponível.

Sugiro que você adote parte da equipe de TI e forneça a eles treinamento completo no novo sistema.

Depois que eles entendem o sistema completamente, faz sentido transferi-lo para eles.

Caso contrário, você se tornará um Centro de suporte para TI - e passará muito tempo combatendo os incêndios enquanto eles aprendem os meandros do novo sistema.