O tema DevOps e IaC é muito popular e está se desenvolvendo rapidamente. No entanto, a maioria dos autores aborda apenas questões técnicas nesse caminho. Eu descreverei os problemas característicos de grandes empresas. Não tenho soluções — os problemas, em geral, são fatais e estão na área de burocracia, auditoria e "soft skills".
Se o título do artigo é esse, então como bode expiatório teremos Daenerys, que mudou de lado para a Enterprise.
Sem dúvida, atualmente está ocorrendo um confronto entre o antigo e o novo. E muitas vezes nessas colisões não há nem certo nem errado. Assim aconteceu. Mas, para não ser apenas retórico, vamos começar com esta tela:
Este é o chamado Change Request. Você vê cerca de um terço dos campos que precisam ser preenchidos a partir de diversos diretórios; os outros campos estão em outras abas. Esse documento precisa ser preenchido para aplicar o script em produção. servidor, ou carregar novos arquivos e, em geral, alterar qualquer coisa.
A quantidade de campos é tal que escrevi minha própria pequena automação para preenchê-los. Além disso, essa página é feita de tal modo que nenhum meio de automação consegue ver seus campos, e a única solução possível foi usar o AutoIt para simplesmente clicar com o mouse nas coordenadas. Avaliem o grau de desespero para se arriscar a fazer isso:
Então você pega Jenkins, Chef, Terraform, Nexus e outros, e alegremente implementa tudo isso no seu dev. Mas chega o momento de enviar isso para QA, UAT e PROD. Você tem o artefato Nexus e recebe um email do DBA com algo assim:
Prezado,
Primeiro, o seu Nexus você pode ter, eu não tenho acesso ao seu Nexus.
Em segundo lugar, todas as alterações devem ser formalizadas como Change Request.
Os scripts SQL precisam ser extraídos do Nexus e anexados ao Change Request.
Se a alteração não for uma Emergência, isso deve ser feito até 7 dias após o lançamento (exclusivamente no fim de semana).
Quando o seu Change Request for aprovado por várias pessoas, o DBA executará seu script e até enviará um screenshot do resultado por email.Atenciosamente, seu DBA que trabalha aqui desde a época do mainframe.
Sabe o que isso me lembra? Uma semi-automação: o robô segura a base, enquanto o trabalhador bate nela com um martelo. Realmente, qual é o sentido nesse Nexus, se depois tudo é feito completamente manualmente?
Mas não devemos culpar o Enterprise por isso! Ele é, sem dúvida, sanguinário, mas toda essa burocracia com os Change Requests é forçada e vem dos auditores. O Enterprise deve operar assim, e ponto final. Não pode ser diferente. E a auditoria é uma coisa muito conservadora. Quanto se falou, por exemplo, que senhas longas, pseudo-complexas e frequentemente alteradas são ruins, mas os enterprises serão o último lugar onde isso mudará. O mesmo vale para implantações e tudo mais.
A propósito, eu tentei criar um arquivo para terraform na época, mas não consegui. Enfrentei dificuldades com o significado da tag 'Project Accounting Billing Code', que nunca consegui descobrir — faltaram habilidades interpessoais.
Nem estou falando do tema do ludismo passivo — ah, sua automação ameaça minha segurança no emprego, não quero aprender nada novo, então vou sabotar silenciosamente.
Qual poderia ser a solução, afinal? O sistema ITSM possui uma API extremamente primitiva para gerar documentos automaticamente. E, de modo geral, a maioria desses sistemas vem desde a era dos mainframes. Alguém conhece sistemas ITSM realmente modernos? Alguém tem experiência bem-sucedida na integração de DevOps modernos com burocracia? Claro, não se trata de sites apenas voltados para vendas, onde realmente pode haver implantações diárias, mas, por exemplo, no setor bancário, que está sob auditoria e tem uma forte isolação dos ambientes superiores.
Só não se esqueçam de que todas as suas fantasias são limitadas pela auditoria. E isso muda tudo. Aguardando vocês nos comentários!
Fonte: habr.com
