O tema de DevOps e IaC é moi popular e está a desenvolverse rapidamente. Porén, a maioría dos autores tratan problemas puramente técnicos neste camiño. Vou describir os problemas característicos dunha gran empresa. Non teño unha solución: os problemas, en xeral, son mortais e atópanse na área da burocracia, a auditoría e as "habilidades suaves".
Dado que o título do artigo é así, Daenerys, que pasou ao lado de Enterprise, fará de gato.
Sen dúbida, agora hai unha colisión de vello e novo. E moitas veces nestas colisións non hai nin ben nin mal. Simplemente pasou así. Pero, para non ser infundados, comezaremos con esta pantalla:
Esta é a chamada Solicitude de Cambio. Ves preto dun terzo dos campos que hai que cubrir desde varios directorios, os campos restantes están noutros marcadores. Este documento debe cubrirse para aplicar o script ao servidor de produción, cargar novos ficheiros ou, en xeral, cambiar calquera cousa.
O número de campos é tal que escribín a miña propia pequena automatización para cubrir estes campos. Ademais, esta páxina está escrita de tal xeito que ningunha ferramenta de automatización pode ver os seus campos, e a única solución posible era usar AutoIt para facer clic co rato nas coordenadas. Avalía o teu nivel de desesperación por facelo:
Entón, tomas jenkins, chef, terraform, nexus, etc., e despréndao todo no teu desarrollador. Pero chega o momento de envialo a QA, UAT e PROD. Tes un artefacto de Nexus e recibes unha carta do DBA con algo así:
Querido,
En primeiro lugar, o teu nexo podes ter para ti. Non teño acceso ao teu Nexus
En segundo lugar, todos os cambios deben emitirse como unha solicitude de cambio.
Debe extraer os scripts SQL de Nexus e anexalos á solicitude de cambio.
Se o cambio non é de emerxencia, debe facerse 7 días antes do lanzamento (exclusivamente o fin de semana)
Cando a túa solicitude de cambio sexa aprobada por un grupo de persoas, o DBA executará o teu script e incluso enviará unha captura de pantalla do resultado por correo.Saúdos, o teu DBA que estivo traballando aquí desde os tempos do mainframe.
Sabes a que me lembra isto? Semiautomatización: o robot suxeita o cadro, e o traballador golpea con un mazo. Ben, de verdade, cal é o sentido deste Nexus se entón todo se fai completamente manualmente?
Pero a Enterprise non se debe culpar diso! É, por suposto, sanguento, pero toda esta burocracia con Solicitudes de Cambio é obrigada e procede dos auditores. A empresa debe funcionar deste xeito, punto. Non pode facelo doutro xeito. E a auditoría é algo moi conservador. Por exemplo, canto se dixo sobre o feito de que os contrasinais pseudocomplexos longos e que se cambian con frecuencia son malos, pero as empresas serán o último lugar onde se cambiará. Tamén con despregamentos e todo o demais.
Por certo, nun momento tentei crear un ficheiro para terraform, pero non funcionou. Tropecín co significado da etiqueta "Código de facturación de contabilidade do proxecto", que nunca conseguín descubrir: non tiña suficientes habilidades blandas.
Nin sequera estou asumindo o tema do luddismo pasivo: oh, a túa automatización ameaza a miña seguridade laboral, non quero aprender nada novo, así que o sabotareei en silencio.
Ben, cal podería ser a solución en principio? O sistema ITSM ten unha API moi primitiva para xerar documentos automaticamente. E, en xeral, a maioría destes sistemas veñen da época dos mainframes. Alguén coñece algún sistema ITSM verdadeiramente moderno? Alguén ten experiencia exitosa integrando DevOps modernos e burocracia? Por suposto, non estamos a falar de sitios puramente de vendas, nos que realmente pode haber un despregue todos os días, senón, por exemplo, do sector bancario, que está baixo auditoría e moi forte illamento en ambientes superiores.
Non esquezas que todas as túas fantasías están limitadas pola auditoría. E iso cambia todo. Os espero nos comentarios!
Fonte: www.habr.com