Os desenvolvedores são de Marte, os administradores são de Vênus

As coincidências são aleatórias, e de fato foi em outro planeta...

Gostaria de compartilhar três histórias de sucesso e fracasso sobre como um desenvolvedor backend trabalha em equipe com administradores.

A primeira história.
Estúdio Web, o número de funcionários pode ser contado com uma mão. Hoje você é designer de layout, amanhã você é backender, depois de amanhã você é administrador. Por um lado, você pode ganhar uma experiência tremenda. Por outro lado, há falta de competência em todas as áreas. Ainda me lembro do primeiro dia de trabalho, ainda estou verde, o patrão fala: “massa aberta”, mas não sei o que é. A comunicação com administradores está excluída, porque você mesmo é um administrador. Vamos considerar os prós e os contras desta situação.

+ Todo o poder está em suas mãos.
+ Não há necessidade de implorar a ninguém acesso ao servidor.
+ Tempo de reação rápido em todas as direções.
+ Melhora bem as habilidades.
+ Tenha um entendimento completo da arquitetura do produto.

— Alta responsabilidade.
— Risco de interrupção da produção.
— É difícil ser um bom especialista em todas as áreas.

Não estou interessado, vamos em frente

A segunda história.
Grande empresa, grande projeto. Existe um departamento de administração com 5 a 7 funcionários e vários grupos de desenvolvimento. Quando você vem trabalhar em uma empresa assim, todo administrador pensa que você não veio aqui para trabalhar em um produto, mas para quebrar alguma coisa. Nem o NDA assinado nem a seleção na entrevista indicam o contrário. Não, esse homem veio aqui com as mãozinhas sujas para estragar a nossa produção de beijos. Portanto, com essa pessoa você precisa de um mínimo de comunicação, pelo menos você pode colocar um adesivo em resposta. Não responda perguntas sobre a arquitetura do projeto. É aconselhável não conceder acesso até que o líder da equipe solicite. E quando ele pedir, ele retribuirá com ainda menos privilégios do que eles pediram. Quase toda a comunicação com esses administradores é absorvida pelo buraco negro entre o departamento de desenvolvimento e o departamento de administração. É impossível resolver os problemas rapidamente. Mas você não pode vir pessoalmente - os administradores estão muito ocupados 24 horas por dia, 7 dias por semana. (O que você está fazendo o tempo todo?) Algumas características de desempenho:

• O tempo médio de implantação em produção é de 4 a 5 horas
• Tempo máximo de implantação em produção 9 horas
• Para um desenvolvedor, um aplicativo em produção é uma caixa preta, assim como o próprio servidor de produção. Quantos são no total?
• Baixa qualidade de lançamentos, erros frequentes
• O desenvolvedor não participa do processo de lançamento

Bem, o que eu esperava, é claro, novas pessoas não podem entrar na produção. Bem, tudo bem, tendo ganhado paciência, começamos a ganhar a confiança dos outros. Mas, por alguma razão, as coisas não são tão simples com os administradores.

Ato 1. O administrador fica invisível.
Dia do lançamento, desenvolvedor e administrador não se comunicam. O administrador não tem perguntas. Mas você entende o porquê mais tarde. O administrador é uma pessoa de princípios, não possui mensageiros, não divulga seu telefone para ninguém e não possui perfil nas redes sociais. Não tem nem foto dele em lugar nenhum, como você é cara? Ficamos sentados com o gerente responsável por cerca de 15 minutos perplexos, tentando estabelecer comunicação com esta Voyager 1, então aparece uma mensagem no e-mail corporativo informando que ele terminou. Vamos nos corresponder por correio? Por que não? Conveniente, não é? Bem, ok, vamos nos acalmar. O processo já está em andamento, não há como voltar atrás. Leia a mensagem novamente. "Terminei". O que você terminou? Onde? Onde devo procurar por você? Aqui você entende porque 4 horas para liberação é normal. Recebemos um choque de desenvolvimento, mas finalizamos o lançamento. Não há mais nenhum desejo de liberação.

Ato 2. Essa versão não.
O próximo lançamento. Com a experiência adquirida, começamos a criar listas de softwares e bibliotecas necessárias para o servidor para administradores, indicando as versões de alguns. Como sempre, recebemos um sinal de rádio fraco informando que o administrador terminou algo ali. O teste de regressão começa, o que leva cerca de uma hora. Tudo parece estar funcionando, mas há um bug crítico. Funcionalidades importantes não funcionam. As horas seguintes foram de dança com pandeiros, leitura da sorte com borra de café e uma revisão detalhada de cada trecho do código. O administrador diz que fez tudo. O aplicativo escrito por desenvolvedores desonestos não funciona, mas o servidor funciona. Alguma pergunta para ele? Ao final de uma hora, pedimos ao administrador que envie a versão da biblioteca do servidor de produção para o chat e bingo - não é a que precisamos. Pedimos ao administrador que instale a versão necessária, mas em resposta recebemos que ele não pode fazer isso devido à ausência desta versão no gerenciador de pacotes do SO. Aqui, no fundo da memória, o gestor lembra que outro administrador já havia resolvido esse problema simplesmente montando manualmente a versão necessária. Mas não, o nosso não fará isso. Os regulamentos proíbem. Karl, estamos sentados aqui há várias horas, qual é o limite de tempo?! Recebemos outro choque e de alguma forma terminamos o lançamento.

Ato 3, curto
Ticket urgente, a funcionalidade principal não funciona para um dos usuários em produção. Passamos algumas horas cutucando e verificando. Em um ambiente de desenvolvimento, tudo funciona. Há um entendimento claro de que seria uma boa ideia examinar os logs do php-fpm. Não havia sistemas de log como ELK ou Prometheus no projeto naquela época. Abrimos um ticket para o departamento de administração para que dê acesso aos logs do php-fpm no servidor. Aqui você precisa entender que estamos pedindo acesso por um motivo, você não se lembra do buraco negro e dos administradores ocupados 24 horas por dia, 7 dias por semana? Se você pedir que eles próprios olhem os registros, então esta é uma tarefa com prioridade “não nesta vida”. O ticket foi criado, recebemos uma resposta instantânea do chefe do departamento de administração: “Você não deve precisar de acesso aos logs de produção, escreva sem bugs”. Uma cortina.

Ato 4 e além
Ainda estamos coletando dezenas de problemas em produção, devido a diferentes versões de bibliotecas, software não configurado, cargas de servidor despreparadas e outros problemas. Claro, também existem bugs de código, não culparemos os administradores por todos os pecados, apenas mencionaremos mais uma operação típica desse projeto. Tivemos muitos trabalhadores em segundo plano que foram iniciados através do supervisor e alguns scripts tiveram que ser adicionados ao cron. Às vezes, esses mesmos trabalhadores paravam de trabalhar. A carga no servidor de filas cresceu na velocidade da luz e os usuários tristes olharam para o carregador giratório. Para consertar rapidamente esses trabalhadores, bastava simplesmente reiniciá-los, mas, novamente, apenas um administrador poderia fazer isso. Enquanto uma operação tão básica estava sendo realizada, um dia inteiro poderia passar. Aqui, é claro, vale a pena notar que os programadores tortos deveriam escrever trabalhadores para que não quebrassem, mas quando caírem, seria bom entender por que, o que às vezes é impossível devido à falta de acesso à produção, de claro, e como consequência, a falta de logs do desenvolvedor.

Transfiguração.
Depois de suportar tudo isso por muito tempo, junto com a equipe começamos a caminhar na direção que nos foi mais bem sucedida. Para resumir, que problemas enfrentamos?

• Falta de comunicação de qualidade entre desenvolvedores e departamento de administração
• Acontece que os administradores (!), não entendem como o aplicativo está estruturado, quais dependências ele possui e como funciona.
• Os desenvolvedores não entendem como funciona o ambiente de produção e, como resultado, não conseguem responder eficazmente aos problemas.
• O processo de implantação demora muito.
• Lançamentos instáveis.

O que nos fizemos?
Para cada versão, foi gerada uma lista de Notas de Versão, que incluía uma lista de trabalhos que precisam ser feitos no servidor para que a próxima versão funcione. A lista continha diversas seções, trabalhos que deveriam ser realizados pelo administrador, pelo responsável pelo lançamento e pelo desenvolvedor. Os desenvolvedores receberam acesso não root a todos os servidores de produção, o que acelerou o desenvolvimento em geral e a resolução de problemas em particular. Os desenvolvedores também entendem como funciona a produção, em quais serviços ela está dividida, onde e quanto custam as réplicas. Algumas das cargas de combate ficaram mais claras, o que sem dúvida afeta a qualidade do código. A comunicação durante o processo de liberação ocorreu no chat de um dos mensageiros instantâneos. Em primeiro lugar, tivemos um registo de todas as ações e, em segundo lugar, a comunicação ocorreu num ambiente mais próximo. Ter um histórico de ações permitiu mais de uma vez que novos funcionários resolvessem problemas com mais rapidez. É um paradoxo, mas muitas vezes isso ajudou os próprios administradores. Não vou dizer com certeza, mas me parece que os administradores começaram a entender melhor como o projeto funciona e como é escrito. Às vezes até compartilhamos alguns detalhes um com o outro. O tempo médio de lançamento foi reduzido para uma hora. Às vezes terminávamos em 30-40 minutos. O número de bugs diminuiu significativamente, senão dez vezes. É claro que outros fatores também influenciaram na redução do tempo de liberação, como os autotestes. Após cada lançamento, passamos a realizar retrospectivas. Para que toda a equipe tenha uma ideia do que há de novo, do que mudou e do que foi removido. Infelizmente, os administradores nem sempre os procuravam, bem, os administradores estão ocupados... Minha satisfação no trabalho como desenvolvedor sem dúvida aumentou. Quando você consegue resolver rapidamente quase qualquer problema da sua área de competência, você se sente no topo. Mais tarde, entenderei que até certo ponto introduzimos uma cultura devops, não completamente, claro, mas mesmo aquele início de transformação foi impressionante.

Terceira história
Comece. Um administrador, pequeno departamento de desenvolvimento. Ao chegar sou um zero completo, porque... Não tenho acesso a lugar nenhum, exceto pelo correio. Escrevemos para o administrador e solicitamos acesso. Além disso, há informações de que ele tem conhecimento do novo funcionário e da necessidade de emissão de logins/senhas. Eles dão acesso do repositório e da VPN. Por que dar acesso ao wiki, teamcity, rundesk? Coisas inúteis para uma pessoa que foi chamada para escrever toda a parte do backend. Só com o tempo ganhamos acesso a algumas ferramentas. A chegada, é claro, foi recebida com desconfiança. Estou tentando aos poucos entender como funciona a infraestrutura do projeto por meio de chats e perguntas importantes. Basicamente não reconheço nada. A produção é a mesma caixa preta de antes. Mas mais do que isso, até mesmo os servidores de teste usados ​​para testes são uma caixa preta. Não podemos fazer nada além de implantar um branch do Git lá. Também não podemos configurar nosso aplicativo como arquivos .env. O acesso para tais operações não é concedido. Você tem que implorar para alterar uma linha na configuração do seu aplicativo no servidor de teste. (Existe uma teoria de que é vital que os administradores se sintam importantes no projeto; se não forem solicitados a alterar as linhas nas configurações, eles simplesmente não serão necessários). Bem, como sempre, não é conveniente? Isso rapidamente fica chato, depois de uma conversa direta com o administrador descobrimos que os desenvolvedores nasceram para escrever códigos ruins, são indivíduos incompetentes por natureza e é melhor mantê-los longe da produção. Mas aqui também de servidores de teste, só para garantir. O conflito está aumentando rapidamente. Não há comunicação com o administrador. A situação é agravada pelo fato de ele estar sozinho. A seguir está uma imagem típica. Liberar. Certas funcionalidades não funcionam. Levamos muito tempo para descobrir o que está acontecendo, várias ideias dos desenvolvedores são lançadas no chat, mas o administrador em tal situação geralmente assume que a culpa é dos desenvolvedores. Aí ele escreve no chat, espera, eu corrigi ele. Quando solicitados a deixar uma história com informações sobre qual era o problema, recebemos desculpas tóxicas. Tipo, não enfie o nariz onde não pertence. Os desenvolvedores devem escrever código. É extremamente triste a situação em que muitos movimentos corporais em um projeto passam por uma única pessoa e só ela tem acesso para realizar as operações que todos necessitam. Essa pessoa é um gargalo terrível. Se as ideias do Devops se esforçam para reduzir o tempo de lançamento no mercado, então essas pessoas são os piores inimigos das ideias do Devops. Infelizmente, a cortina se fecha aqui.

PS Depois de falar um pouco sobre desenvolvedores versus administradores em bate-papos com pessoas, conheci pessoas que compartilharam minha dor. Mas também houve quem dissesse nunca ter encontrado nada parecido. Em uma conferência Devops, perguntei a Anton Isanin (Alfa Bank) como eles lidaram com o problema do gargalo na forma de administradores, ao que ele disse: “Nós os substituímos por botões”. Por falar nisso podcast com sua participação. Eu gostaria de acreditar que existem muito mais bons administradores do que inimigos. E sim, a imagem do início é uma correspondência real.

Fonte: www.habr.com