DevOps ou como estamos perdendo salários e o futuro do setor de TI

O mais triste na situação atual é que a TI está gradualmente se tornando um setor em que não há nenhuma palavra “parar” no número de tarefas por pessoa.



Ao ler as vagas, às vezes você até vê não 2 a 3 pessoas, mas uma empresa inteira em uma pessoa, todos estão com pressa, o débito técnico está crescendo, o legado antigo parece perfeito no contexto de novos produtos, porque pelo menos tem documentos e comentários no código, novo Os produtos são escritos na velocidade da luz, mas como resultado, eles não podem ser usados ​​por mais um ano após terem sido escritos, e muitas vezes este ano não traz lucro, aliás, os custos da "nuvem" são maiores do que as vendas do serviço. O dinheiro do investidor vai para a manutenção de um serviço que ainda não está funcionando, mas que já foi liberado para a rede como trabalhador.

Por exemplo: uma empresa conhecida cuja remasterização de um jogo antigo recebeu as classificações mais baixas da história do setor. Fui um dos que compraram este produto, mas mesmo agora funciona muito mal e, em teoria, não devia estar à venda desta forma. Reembolsos, avaliações em queda, um grande número de proibições de usuários em fóruns por reclamações sobre serviços. O número de patches não é surpreendente, mas assustador, mas mesmo assim - o produto não é utilizável. Se essa abordagem leva a tais resultados para uma empresa que está se desenvolvendo desde 1991, para empresas que estão apenas começando, a situação é ainda pior.



Mas examinamos os resultados dessa abordagem do lado do usuário do serviço e agora vamos examinar os problemas que os funcionários têm.



Costumo ouvir a declaração de que as equipes de DevOps não deveriam existir, que esta é uma metodologia, etc., mas o problema é que as empresas, por algum motivo, pararam de procurar nós, dba, construtores de infraestrutura e engenheiros de construção - agora é tudo um engenheiro de DevOps em uma única pessoa. Claro, ainda existem tais vagas em empresas individuais, mas são cada vez menos. Muitos chamaram isso de desenvolvimento, eu pessoalmente vejo degradação nisso, é impossível manter um bom nível de conhecimento em todas as áreas, e ao mesmo tempo conseguir trabalhar não mais que 8 horas. Naturalmente, são fantasias. Na realidade, muitos especialistas em TI são obrigados a trabalhar 12 ou 14 horas, das quais 8 são pagas. E muitas vezes sete dias por semana, porque “me deram uma tarefa, não há cais nem curvas e até o serviço custa dinheiro”, e por 1 um erro na nuvem pode, em princípio, não obter um salário em alguns meses, especialmente se você trabalhar em um IP.Na verdade, estamos perdendo a palavra nos negócios, junto com a separação de funções, cada vez mais me deparo com o fato de que os gestores entram nos processos de desenvolvimento, geralmente sem entender nada sobre eles, eles confundem os dados do negócio e o funcionamento do aplicativo, com isso o caos começa.



Quando o caos começa, a empresa quer encontrar o culpado, e aqui você precisa de um culpado universal, é difícil colocar a culpa em mais de 10 pessoas, então os gerentes combinam as posições, porque quanto mais responsabilidades um especialista tiver, mais fácil será provar sua negligência. E nas condições do Agile, encontrar o “culpado” e açoitar é a base dessa metodologia de fazer negócios em gestão. O Agile deixou a TI por muito tempo e seu conceito principal passou a ser - a exigência de resultados diários. O problema é que nem sempre um especialista altamente especializado terá um resultado diário, o que significa que será mais difícil reportar, e este é mais um motivo pelo qual a empresa deseja “especialistas em tudo”. Mas o principal motivo, claro, é a folha de pagamento - é o principal motivo de todas as mudanças, por uma questão de bônus, as pessoas concordaram em trabalhar para si mesmas e para aquele cara. Mas no final, como em outras áreas,simplesmente se tornou agora um dever, por menos pagamento por mais dos serviços prestados.



Agora você pode ver frequentemente até mesmo artigos sobre o que os desenvolvedores já devem ser capazes de implantar, devem lidar com infraestrutura ao lado de um engenheiro de DevOps, mas a que isso leva? Isso mesmo - para uma queda na qualidade dos serviços, para uma queda na qualidade dos desenvolvedores. Apenas 2 dias atrás, eu expliquei ao desenvolvedor que você pode escrever e ler em diferentes hosts, e eles me provaram com espuma pela boca que nunca viram tal coisa, aqui estão eles nas configurações orm host, port, db, user, password e pronto .... Mas o desenvolvedor sabe como executar implantações, escrever yamls .... Mas ele já se esquece dos testes de unidade e dos comentários no código.



Como resultado, vemos o seguinte - sobrecarga constante, busca de soluções para problemas fora do horário de trabalho, treinamento constante nos finais de semana, e não para aumentar a renda, mas para nos mantermos à tona. Os desenvolvedores são forçados a ajudar o engenheiro de DevOps com CI / CD e, se o desenvolvedor não tiver tempo, ele começa a costurar e os gerentes começam a socar seus cérebros e, se isso não ajudar a aumentar o desejo de trabalhar horas extras, aplique penalidades e multas, uma pessoa está procurando um novo emprego. deixando para trás uma dívida técnica do tamanho do Everest, como resultado, a dívida começa a crescer entre os incorporadores, porque eles são forçados a escrever código com menos refatoração a fim de ter tempo para ajudar o antigo ou o novo engenheiro DevOps, e os gerentes estão muito felizes com tudo, porque a pessoa culpada está lá e é imediatamente visível, o que significa que a regra básica no gerenciamento ágil é observada, a pessoa culpada é encontradaos resultados de suas chicotadas são visíveis.



Uma vez no ITGM dei uma palestra “quando aprendermos a dizer não” - os resultados foram muito reveladores. Um grande número de pessoas acredita que essa palavra é um tabu e, até que paremos de pensar assim, os problemas só aumentarão.



Parte deste artigo foi inspirada por este artigo , mas mais tarde provavelmente irei escrevê-lo em termos menos suaves.