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

O último artigo já causou muita indignação, acho que esse artigo não vai agradar mais a muitos, nele vou descrever como os clientes veem um engenheiro de DevOps.



Quanto mais o tempo passa, mais eu ouço que “este é o dever dos“ devups ”, solicitações ao banco de dados querem ajustar devups, adivinhe como e com quais dependências o software está saindo do codificador - devups, evpn + bgp + ipsec + geo dns + autorização de rede por certificados - devups, corrigindo erros de arquitetura e surgindo com opções sem sangue - devups, transformando um pg_dump regular em replicação síncrona - devups, sendo um psicanalista para o workshop / CEO e a equipe - devups.



Outra tendência interessante é o balanceador de carga k8s + para qualquer espirro. Não faz muito tempo, até me ofereceram para colocar o balanceador de carga no banco de dados, talvez a média de carga caia e os discos fiquem menos carregados…. K8s geralmente é um tópico separado, você pode escrever 2-3 artigos sobre os mitos associados a ele.



Cada vez mais, você pode ouvir das empresas que os desenvolvedores e engenheiros estão ficando bêbados, que o Sberbank criou uma bolha de sabão e um milagre está para acontecer e começaremos a trabalhar como pessoas comuns por 60-80 mil a partir da terceira idade. Nas regiões, é claro, isso já existe, mas tudo era triste lá, mas aqui eles já sonham com todas as cidades, exceto Moscou.



É ainda mais divertido da mesma empresa ouvir como eles são preguiçosos, histórias sobre como os funcionários são inúteis e que você precisa procurar maneiras de não planejar o trabalho, arquitetar, pensar no futuro, mas espancar código de baixa qualidade na velocidade da luz, porque então o devups “escala horizontalmente ", Sim, temos 1 consulta no banco de dados custa 15% da capacidade do hardware e 5 consultas - um colapso, e daí? A escala horizontal sem alocação de recursos nos salvará !!! - a verdade não é especificada como. Especialmente se o banco de dados tiver uma arquitetura bastante torta, por exemplo, o PostgreSQL ou Elasticsearch padrão.



Usar a tecnologia conforme pretendido? Não, é chato. Planejando a arquitetura, os esquemas de dados e seu processamento - por que é caro e lento. Mas o que fazer? Existe uma solução - contrate um devups e culpe-o por todos os pecados mortais do seu projeto, sem esquecer de acrescentar - tudo funcionou exatamente antes de você chegar. E as toras mentem, tudo funcionou !!!



Cada vez mais vejo projetos bastante interessantes e promissores morrendo, mesmo no estágio inicial, simplesmente por causa de jogos políticos. Comunico-me com o RM, que há seis meses está impedido de vender um produto que pode render à empresa bilhões de rublos por ano, mas eles constantemente colocam um raio em suas rodas. Todo mundo está procurando maneiras de fazer o desenvolvimento sem gastar nele, e a metodologia DevOps é cada vez mais percebida como uma forma de colocar um produto que não está funcionando na produção e cobrir as ombreiras com contêineres, balanceadores e stubs, mesmo que isso leve a classificações baixas e um grande número de negatividade, o principal é economizar desenvolvimento.

Como mostrou a pesquisa do artigo anterior, para a maioria dos visitantes do habr, os empregadores tentam tampar vários buracos com 1 pessoa. Naturalmente, sem compensar essas obrigações. Mas, o problema é que o próprio negócio sofre com isso. Devido aos baixos salários e à alta produtividade do trabalho em relação ao suporte financeiro e técnico, o negócio sobrevive, se, com uma gestão como a da CEI, tentassem fazer negócios no Japão ou nos Estados Unidos, já teria falido há muito tempo.



Muitas metodologias que chegaram até nós de países desenvolvidos foram completamente distorcidas. Por exemplo, Agile, Scrum, DevOps - todas as 3 metodologias exigem mudanças significativas nos processos de negócios para funcionar, mas a gestão no CIS não está preparada para isso, ele espera combinar velhos hábitos e metodologias modernas, estamos no topo da maneira antiga e você está de uma forma moderna e eficaz abaixo. É inútil implementar todas as 3 metodologias abaixo, a presença de cartões, relatórios diários, planos para 2 semanas e lançamentos para cada linha de código não significa que você implementou essas metodologias, significa que você introduziu processos de relatórios adicionais que simplesmente ajudam a encontrar o culpado e a desculpa para a alta administração. Só é mais difícil para o projeto e para as pessoas que começam a trabalhar nessas condições implementar seus planos, porque o número de relatórios está crescendo significativamente mais,do que se eles não fossem.

Agora existem alguns artigos e discursos de estranhos gerentes de TI que já se oferecem para pagar pelos resultados, quase como antes por linhas de código, tirando o tempo do trabalho para pensar na implementação, considerando que é 30-40 minutos, e então puramente escrever código. Ao mesmo tempo, dê-nos 2-3 semanas para pensar e calcular os custos e riscos para as decisões de gestão ... Como resultado, somos cada vez mais confrontados com o fato de que a qualidade dos produtos inevitavelmente diminui, é claro, este não é apenas um problema da indústria de TI, mas em nossa indústria é especialmente agudo, porque as falhas são então atribuídas a programadores que como "esbanjaram 180 milhões de rublos", I Já vi 4 projetos que, como resultado de tal processo, não cumprem suas tarefas, mas gastam 1 bilhão de rublos ou mais,mas, como resultado, especialistas de TI preguiçosos tornaram-se culpados e seus mais relatórios e procedimentos regulatórios começaram a corrigir a situação. Gerentes adicionais são contratados para fornecer funções de supervisão e a folha de pagamento para especialistas em TI é reduzida. O número de decisões que tomamos está diminuindo e a responsabilidade e a prestação de contas estão crescendo, o que leva a problemas ainda maiores.



Você precisa traçar claramente os limites da responsabilidade e minimizá-los, caso contrário, você simplesmente se torna uma vítima em qualquer jogo político.



No próximo artigo, escreverei mais sobre por que DevOps e Agile, implementados de baixo para cima, nunca serão úteis.