Il tema DevOps e IaC è molto popolare e sta crescendo rapidamente. Tuttavia, la maggior parte degli autori affronta problemi puramente tecnici lungo il percorso. Descriverò i problemi specifici di una grande azienda. Non ho una soluzione: i problemi, in generale, sono fatali e risiedono nel campo della burocrazia, dell'audit e delle "competenze trasversali".
Poiché il titolo dell'articolo è così, Daenerys agirà come un gatto, passando dalla parte dell'Enterprise
Indubbiamente, ora c'è uno scontro tra vecchio e nuovo. E spesso in queste collisioni non c'è né giusto né sbagliato. È successo proprio così. Ma, per non essere infondati, inizieremo con questa schermata:
Questa è la cosiddetta Richiesta di Modifica. Vedi circa un terzo dei campi che devono essere compilati da varie directory, il resto dei campi si trova in altre schede. Tale documento deve essere compilato per poter applicare lo script al server di produzione, o caricare nuovi file e, in generale, cambiare qualcosa.
Il numero di campi è tale che ho scritto la mia piccola automazione per compilare questi campi. Inoltre, questa pagina è scritta in modo tale che nessuno strumento di automazione veda i suoi campi e l'unica soluzione possibile era utilizzare AutoIt per colpire stupidamente le coordinate con il mouse. Valuta il grado di disperazione per decidere su questo:
Quindi, prendi jenkins, chef, terraform, nexus e così via, e distribuisci con gioia tutto questo sul tuo dev. Ma è ora di inviarlo a QA, UAT e PROD. Hai un artefatto Nexus e ricevi una lettera dal DBA con qualcosa del genere:
Caro,
Primo, il tuo nesso, puoi immaginare che io non abbia accesso al tuo nesso
In secondo luogo, tutte le modifiche devono essere archiviate come Richiesta di modifica.
Devi isolare gli script SQL da Nexus e allegarli alla richiesta di modifica.
Se la modifica non è Emergency va effettuata entro 7 giorni dal rilascio (esclusivamente nel Weekend)
Quando la tua richiesta di modifica viene approvata da un gruppo di persone, il DBA eseguirà il tuo script e invierà persino uno screenshot del risultato per posta.Cordiali saluti, il tuo DBA, che lavora qui dal mainframe.
Sai cosa mi ricorda questo? Semi-automazione: il robot tiene il telaio e l'operaio lo colpisce con una mazza. Beh, davvero, a cosa serve questo Nexus, se poi tutto è fatto completamente manualmente?
Ma non incolpare l'Enterprise per questo! Ovviamente è cruento, ma tutta questa burocrazia con le richieste di modifica è forzata e proviene dai revisori. L'impresa deve lavorare in questo modo, punto. Non può farlo in nessun altro modo. E l'audit è una cosa molto conservativa. Quanto, ad esempio, è stato detto sul fatto che le password lunghe pseudo-complesse e cambiate di frequente sono un male, ma le aziende saranno l'ultimo posto in cui cambiarlo. Anche con distribuzioni e tutto il resto.
A proposito, una volta ho provato a creare un file per terraform, ma non ci sono riuscito. Mi sono imbattuto nel significato del tag "Project Accounting Billing Code", che non sono mai riuscito a scoprire: non avevo abbastanza competenze trasversali.
Non affronto nemmeno l'argomento del luddismo passivo: oh, la tua automazione minaccia la sicurezza del mio lavoro, non voglio imparare niente di nuovo, quindi saboterò silenziosamente.
Allora, quale potrebbe essere la soluzione? Il sistema ITSM ha un'API estremamente primitiva per generare automaticamente i documenti. E in generale, la maggior parte di questi sistemi proviene dai tempi dei mainframe. Forse qualcuno conosce sistemi ITSM davvero moderni? Forse qualcuno ha un'esperienza di successo nell'integrazione di DevOps moderni e burocrazia? Questo, ovviamente, non riguarda siti puramente corrotti, dove può davvero essere implementato ogni giorno, ma, ad esempio, il settore bancario, che è sotto controllo e isolamento molto forte degli ambienti superiori.
Non dimenticare che tutte le tue fantasie sono limitate all'auditing. E questo cambia tutto. Ti aspetto nei commenti!
Fonte: habr.com