O tema DevOps e IaC é muito popular e está se desenvolvendo rapidamente. No entanto, a maioria dos autores se refere a problemas puramente técnicos ao longo do caminho. Vou descrever os problemas característicos de uma grande empresa. Não tenho solução - os problemas, em geral, são fatais e estão no campo da burocracia, auditoria e “soft skills”.
Como o título do artigo é esse, Dineris atuará como um gato, que mudou para o lado da Enterprise
Sem dúvida, agora há um choque entre o antigo e o novo. E muitas vezes nessas colisões não há certo, não há culpa. Apenas aconteceu. Mas, para não ser infundado, começaremos aqui a partir desta tela:
Essa é a chamada Solicitação de Mudança. Você vê cerca de um terço dos campos que precisa preencher em uma variedade de diretórios, os campos restantes em outras guias. Esse documento deve ser preenchido para aplicar o script ao servidor de produção ou fazer upload de novos arquivos e, em geral, alterar alguma coisa.
O número de campos é tal que escrevi minha pequena automação no preenchimento desses campos. Além disso, esta página foi escrita para que nenhuma ferramenta de automação possa ver seus campos, e a única solução possível era usar o AutoIt para bater estupidamente no mouse com suas coordenadas. Classifique o grau de desespero para decidir sobre isso:
Então, você pega jenkins, chef, terraform, nexus e assim por diante, e implementa tudo isso em seu desenvolvedor. Mas é hora de enviar isso para o controle de qualidade, o UAT e o PROD. Você possui um artefato Nexus e recebe uma carta do DBA com aproximadamente o seguinte texto:
Caro
Em primeiro lugar, seu nexo, você pode imaginar que eu não tenho acesso ao seu Nexus
Em segundo lugar, todas as alterações devem ser emitidas como uma Solicitação de Mudança.
Scripts SQL, você precisa isolá-los do Nexus e anexar à Solicitação de Mudança.
Se a alteração não for de emergência, isso deve ser feito após 7 dias do lançamento (exclusivamente no fim de semana)
Quando sua Solicitação de Mudança envia várias pessoas, o DBA executa seu script e até envia uma captura de tela do resultado por email.
Atenciosamente, seu DBA, que trabalha aqui desde os dias do mainframe.
Você sabe do que isso me lembra? Semi-automação: o robô segura a cama e o trabalhador bate nela com uma marreta. Bem, realmente, qual é a utilidade deste Nexus, se tudo for feito manualmente?
Mas a empresa não deve ser responsabilizada! Ele, é claro, é sangrento, mas toda essa burocracia com solicitações de mudança é forçada e vem de auditores. A empresa deve funcionar assim, ponto final. É impossível para ele o contrário. E a auditoria é uma coisa muito conservadora. Quanto, por exemplo, foi dito que senhas longas e pseudo-complexas e frequentemente alteradas são ruins, mas as empresas serão o último lugar para alterá-las. Também com implantações e tudo mais.
A propósito, tentei criar um arquivo para terraform, mas não obtive sucesso. Eu me deparei com o valor da tag 'Código de cobrança da contabilidade do projeto', que ainda não consegui descobrir - as habilidades pessoais não eram suficientes.
Eu nem entendo o tema do ludismo passivo - ah, sua automação ameaça minha segurança no trabalho, não quero aprender nada novo, então sabotarei isso silenciosamente.
Bem, e o que poderia ser uma solução em princípio? O sistema ITSM possui uma API extremamente primitiva para gerar documentos automaticamente. De qualquer forma, a maioria desses sistemas vem do tempo dos mainframes.
Talvez alguém conheça sistemas ITSM realmente modernos? Alguém pode ter experiência bem-sucedida na integração de DevOps e burocracia modernos? Obviamente, não se trata de sites que vendem apenas sites onde realmente pode haver uma implantação todos os dias, mas, por exemplo, o setor bancário, que está sob os auditores e com um isolamento muito forte de ambientes superiores.
Só não esqueça que todas as suas fantasias são limitadas pela auditoria. E isso tudo muda. Esperando por você nos comentários!