El tema DevOps e IaC es muy popular y se está desarrollando rápidamente. Sin embargo, la mayoría de los autores se relacionan con problemas puramente técnicos en el camino. Describiré los problemas característicos de una gran empresa. No tengo solución: los problemas, en general, son fatales y se encuentran en el campo de la burocracia, la auditoría y las "habilidades sociales".
Como el título del artículo es tal, Dineris actuará como un gato, que se ha cambiado al lado de Enterprise
Sin lugar a dudas, ahora hay un choque de lo viejo y lo nuevo. Y a menudo en estas colisiones no hay derecho, ni culpa. Simplemente sucedió. Pero, para no ser infundado, comenzaremos aquí desde esta pantalla:
Esta es la llamada solicitud de cambio. Verá aproximadamente un tercio de los campos que necesita completar desde una variedad de directorios, el resto de los campos en otras pestañas. Dicho documento debe completarse para aplicar el script al servidor de producción o para cargar nuevos archivos y, en general, cambiar algo.
El número de campos es tal que escribí mi pequeña automatización para llenar estos campos. Además, esta página está escrita para que ninguna herramienta de automatización pueda ver sus campos, y la única solución posible era usar AutoIt para golpear estúpidamente el mouse con sus coordenadas. Califique el grado de desesperación para decidir sobre esto:
Entonces, tomas jenkins, chef, terraform, nexus, etc., y lo despliegas felizmente en tu desarrollador. Pero es hora de enviar esto a QA, UAT y PROD. Tiene un artefacto Nexus y recibe una carta de DBA con aproximadamente el siguiente texto:
Querido
En primer lugar, tu nexo puedes imaginar que no tengo acceso a tu Nexus
En segundo lugar, todos los cambios deben emitirse como una Solicitud de cambio.
Scripts SQL que necesita para aislarlos Nexus y adjuntarlos a la Solicitud de cambio.
Si el cambio no es de emergencia, esto debe hacerse después de 7 días de lanzamiento (exclusivamente en fin de semana)
Cuando su solicitud de cambio envía a un grupo de personas, el DBA ejecutará su script e incluso enviará una captura de pantalla del resultado por correo.
Sinceramente, su DBA que ha estado trabajando aquí desde los días de mainframe.
¿Sabes a qué me recuerda esto? Semiautomatización: el robot sostiene la cama y el trabajador la golpea con un mazo. Bueno, de verdad, ¿de qué sirve este Nexus, si todo se hace de forma completamente manual?
¡Pero no se debe culpar a Enterprise! Él, por supuesto, es sangriento, pero toda esta burocracia con solicitudes de cambio es forzada y proviene de auditores. La empresa debe funcionar así, punto. Es imposible para él lo contrario. Y la auditoría es una cosa muy conservadora. Cuánto, por ejemplo, se dijo que las contraseñas largas seudocomplejas y frecuentemente cambiadas son malas, pero las empresas serán el último lugar para cambiarlas. También con implementaciones y todo lo demás.
Por cierto, en un momento intenté crear un archivo para terraform, pero no tuve éxito. Me topé con el valor de la etiqueta 'Código de facturación contable del proyecto', que todavía no pude descubrir: las habilidades blandas no eran suficientes.
Ni siquiera tomo el tema del ludismo pasivo. Oh, tu automatización amenaza la seguridad de mi trabajo, no quiero aprender nada nuevo, así que lo sabotearé en silencio.
Bueno, ¿y cuál podría ser una solución en principio? El sistema ITSM tiene una API extremadamente primitiva para generar documentos automáticamente. De todos modos, la mayoría de estos sistemas provienen de la época de los mainframes.
¿Quizás alguien conoce sistemas ITSM realmente modernos? ¿Alguien puede tener una experiencia exitosa integrando DevOps y burocracia modernas? Esto, por supuesto, no se trata solo de vender sitios donde realmente puede haber una implementación todos los días, sino, por ejemplo, el sector bancario, que está bajo los auditores y un aislamiento muy fuerte de entornos superiores.
Simplemente no olvide que todas sus fantasías están limitadas por la auditoría. Y eso todo cambia. Esperando por ti en los comentarios!