Il tema di DevOps e IaC è molto popolare e si sta rapidamente sviluppando. Tuttavia, la maggior parte degli autori si concentra esclusivamente su problemi tecnici lungo questo percorso. Io descriverò invece le sfide tipiche di una grande azienda. Non ho soluzioni — i problemi, in generale, sono gravi e si trovano nell'ambito della burocrazia, dell'audit e delle "soft skills".
Dato il titolo dell'articolo, il nostro gattino sarà Daenerys, passata dalla parte dell'Enterprise.
È innegabile che stia avvenendo un conflitto tra vecchio e nuovo. Nelle collisi non ci sono né giusti né sbagliati. È andata così. Ma, per non restare sul vago, iniziamo con questo schermo:
Questo è il cosiddetto Change Request. Vedi circa un terzo dei campi che devono essere compilati da vari registri, gli altri campi si trovano in altre schede. Questo documento deve essere compilato per applicare uno 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 riempire questi campi. Questa pagina è stata creata in modo tale che nessun strumento di automazione riesca a vedere i suoi campi, e l'unica soluzione possibile è stata utilizzare AutoIt per cliccare semplicemente sulle coordinate. Valutate la misura della disperazione necessaria per arrivare a tanto:
Allora, prendete Jenkins, Chef, Terraform, Nexus e altro, e felici implementate tutto questo nel vostro ambiente di sviluppo. Ma arriva il momento di mandarlo su QA, UAT e PROD. Avete l'artefatto di Nexus e ricevete un'email dal DBA con un testo circa così:
Gentile,
In primo luogo, per accedere al vostro Nexus non ho accesso al vostro Nexus
In secondo luogo, tutte le modifiche devono essere formalizzate come Change Request.
Dovete estrarre gli script SQL dal Nexus e allegarli alla Change Request.
Se la modifica non è urgente, deve essere fatta entro 7 giorni dalla release (esclusivamente nel weekend).
Quando la vostra Change Request sarà approvata da un gran numero di persone, il DBA eseguirà il vostro script e invierà anche uno screenshot del risultato via email.Cordiali saluti, il vostro DBA che lavora qui fin dai tempi del mainframe.
Ti ricorda qualcosa? Un'automazione parziale: un robot tiene il supporto mentre un operatore lo colpisce con un martello. In effetti, che senso ha questo Nexus se poi tutto viene fatto interamente a mano?
Ma non si deve incolpare l'Enterprise! Certo, è difficile, ma tutta questa burocrazia con le Change Requests è necessaria e deriva dagli auditor. L'Enterprise deve funzionare in questo modo, non c'è alternativa. E l'audit è un aspetto molto conservativo. Per esempio, è stato detto spesso che le lunghe password pseudo-complesse e frequentemente cambiate siano una cattiva idea, ma gli enterprise saranno l'ultimo posto in cui questo cambierà. Lo stesso vale per i deploy e per tutto il resto.
A proposito, tempo fa ho provato a creare un file per terraform, ma non ci sono riuscito. Mi sono bloccato sul significato del tag ‘Project Accounting Billing Code’, che non sono riuscito a scoprire — mi sono mancati i soft skills.
Non parlo nemmeno del tema del luddismo passivo — ah, la tua automazione minaccia la mia sicurezza lavorativa, non voglio imparare nulla di nuovo, quindi farò sabotaggi silenziosi.
Quale potrebbe essere, in linea di principio, la soluzione? I sistemi ITSM hanno un'API estremamente primitiva per generare automaticamente documenti. Inoltre, la maggior parte di questi sistemi proviene dall'era dei mainframe. Qualcuno conosce realmente sistemi ITSM moderni? Qualcuno ha esperienze di successo nell'integrazione di moderni DevOps e burocrazia? Non si parla di siti esclusivamente commerciali, dove potrebbe esserci un deploy ogni giorno, ma ad esempio del settore bancario, che è sottoposto a audit e ha un isolamento molto forte degli ambienti superiori.
Ma non dimenticate che tutte le vostre fantasie sono limitate dall'audit. E questo cambia tutto. Vi aspetto nei commenti!
Fonte: habr.com
