Il tema DevOps e IaC è molto popolare e si sta sviluppando rapidamente. Tuttavia, la maggior parte degli autori si concentra esclusivamente su problemi tecnici lungo questo percorso. Io descriverò i problemi caratteristici di una grande azienda. Non ho soluzioni — i problemi, in generale, sono fatali e riguardano la burocrazia, l'audit e le "soft skills".
Se il titolo dell'articolo è così, allora come promozione avremo Daenerys, che passa dalla parte dell'Enterprise.
Senza dubbio, c'è uno scontro tra il vecchio e il nuovo. E spesso in queste collisioni non ci sono né giusti né colpevoli. È andata così. Ma, per non essere vago, iniziamo con questo schermo:
Questo è il cosiddetto Change Request. Vedi circa un terzo dei campi che devono essere compilati da vari cataloghi; gli altri campi si trovano in altre schede. È necessario compilare questo documento per applicare lo script in produzione. server, o caricare nuovi file e, in generale, cambiare qualcosa.
Il numero di campi è tale che ho scritto una piccola automazione per compilare questi campi. E questa pagina è progettata in modo che nessun strumento di automazione riesca a vedere i suoi campi, e l'unica soluzione possibile è stata utilizzare AutoIt, per picchiare semplicemente il mouse sulle coordinate. Valutate il grado di disperazione per arrivare a questo:
Prendete jenkins, chef, terraform, nexus e altro, e felicemente deployate tutto questo nel vostro dev. Ma arriva il momento di inviarlo a QA, UAT e PROD. Hai l'artefatto di Nexus e ricevi una mail dal DBA con un testo simile a questo:
Gentile,
In primo luogo, non hai accesso al tuo Nexus.
In secondo luogo, tutte le modifiche devono essere formalizzate come Change Request.
Devi estrarre gli script SQL da Nexus e allegarli al Change Request.
Se la modifica non è di emergenza, deve essere fatta entro 7 giorni dal rilascio (esclusivamente nel weekend).
Quando il tuo Change Request sarà approvato da molte persone, il DBA eseguirà il tuo script e invierà anche uno screenshot del risultato via email.Cordiali saluti, il tuo DBA che lavora qui fin dai tempi dei mainframe.
Sai cosa mi ricorda? Un'semi-automazione: un robot tiene la base, mentre un lavoratore la colpisce con un martello. Dico sul serio, quale utilità ha questo Nexus, se poi tutto viene fatto completamente a mano?
Ma non si dovrebbe incolpare l'Enterprise per questo! Certo, è spietata, ma tutta questa burocrazia con le Change Requests è inevitabile e deriva dai revisori. L'Enterprise deve funzionare in questo modo, e basta. Non può fare diversamente. E la revisione è una cosa molto conservatrice. Quante volte, ad esempio, si è detto che le lunghe password pseudo-complesse e spesso cambiate sono un problema, ma le aziende saranno l'ultimo posto in cui questo cambierà. Lo stesso vale per i deployment e per tutto il resto.
A proposito, tempo fa ho cercato di creare un file per terraform, ma non ci sono riuscito. Ho avuto problemi con il valore del tag 'Project Accounting Billing Code', che non sono riuscito a scoprire — mi mancavano le soft skills.
Non ho nemmeno accennato al tema del luddisimo passivo — oh, la tua automazione minaccia la mia sicurezza lavorativa, non voglio imparare niente di nuovo, quindi inizierò a sabotare silenziosamente.
E quale potrebbe essere in linea di principio la soluzione? Il sistema ITSM ha un'API estremamente primitiva per generare automaticamente documenti. E in generale, la maggior parte di questi sistemi proviene dall'era dei mainframe. Qualcuno conosce davvero sistemi ITSM moderni? Qualcuno ha esperienza positiva nell'integrare DevOps moderni e burocrazia? Naturalmente, non stiamo parlando di siti puramente commerciali, dove può realmente esserci un deployment ogni giorno, ma, ad esempio, del settore bancario, che è sottoposto a revisori e a un'alta isolamento degli ambienti superiori.
Solo non dimenticate che tutte le vostre fantasie sono limitate dalla revisione. E questo cambia tutto. Vi aspetto nei commenti!
Fonte: habr.com
