Cosa serve affinché un’azienda IT abbia successo nel 2019? I relatori delle conferenze e degli incontri dicono molte parole ad alta voce che non sono sempre comprensibili alle persone normali. La lotta per i tempi di implementazione, i microservizi, l'abbandono del monolite, la trasformazione DevOps e molto, molto altro ancora. Se scartiamo la bellezza verbale e parliamo direttamente e in russo, tutto si riduce a una tesi semplice: realizzare un prodotto di alta qualità e farlo con comodità per la squadra.
Quest'ultimo è diventato di fondamentale importanza. Le aziende sono finalmente arrivate alla conclusione che un processo di sviluppo confortevole aumenta la produttività e, se tutto viene sottoposto a debug e funziona come un orologio, offre anche un certo margine di manovra in situazioni critiche. C'era una volta, per il bene di questa manovra, una certa persona intelligente ha inventato dei backup, ma il settore si sta sviluppando e siamo arrivati agli ingegneri DevOps, persone che trasformano il processo di interazione tra sviluppo e infrastruttura esterna in qualcosa di adeguato e non legato allo sciamanesimo.
Tutta questa storia "modulare" è meravigliosa, ma... È successo che alcuni amministratori furono improvvisamente soprannominati DevOps e gli stessi ingegneri DevOps iniziarono a dover possedere almeno le capacità di telepatia e chiaroveggenza.
Prima di parlare dei moderni problemi di fornitura delle infrastrutture, definiamo cosa intendiamo con questo termine. Al momento attuale, la situazione si è sviluppata in modo tale che abbiamo raggiunto la dualità di questo concetto: l'infrastruttura può essere condizionatamente esterna e condizionatamente interna.
Per infrastruttura esterna intendiamo tutto ciò che garantisce la funzionalità del servizio o prodotto che il team sta sviluppando. Si tratta di server di applicazioni o siti Web, hosting e altri servizi che garantiscono la funzionalità del prodotto.
L'infrastruttura interna comprende servizi e attrezzature utilizzati dal team di sviluppo stesso e da altri dipendenti, che solitamente sono numerosi. Si tratta di server interni di sistemi di archiviazione del codice, un task manager distribuito localmente e tutto, tutto, tutto ciò che esiste all'interno dell'intranet aziendale.
Cosa fa un amministratore di sistema in un'azienda? Oltre al lavoro di amministrazione di questa intranet aziendale, spesso si porta dietro il peso delle preoccupazioni economiche per garantire l'operatività delle apparecchiature per ufficio. L'amministratore è la stessa persona che trascinerà rapidamente una nuova unità di sistema o un laptop di riserva pronto per l'uso dalla stanza sul retro, distribuirà una nuova tastiera e gattonerà a quattro zampe attraverso gli uffici, allungando il cavo Ethernet. Un amministratore è un proprietario locale e sovrano non solo dei server interni ed esterni, ma anche di un dirigente aziendale. Sì, alcuni amministratori possono lavorare solo a livello di sistema, senza hardware. Dovrebbero essere separati in una sottoclasse separata di “amministratori di sistemi infrastrutturali”. E alcuni sono specializzati nella manutenzione esclusivamente di apparecchiature per ufficio; fortunatamente, se l'azienda conta più di cento dipendenti, il lavoro non finisce mai. Ma nessuno dei due è devop.
Chi sono i DevOps? I devops sono ragazzi che parlano dell'interazione dello sviluppo software con l'infrastruttura esterna. Più precisamente, i devop moderni sono coinvolti nei processi di sviluppo e distribuzione molto più profondamente di quanto siano mai stati coinvolti gli amministratori che si limitavano a caricare gli aggiornamenti su ftp. Uno dei compiti chiave di un ingegnere DevOps ora è garantire un processo di interazione confortevole ed efficacemente strutturato tra i team di sviluppo e l'infrastruttura del prodotto. Sono queste persone che sono responsabili dell'implementazione dei sistemi di rollback e distribuzione; sono queste persone che alleggeriscono parte del carico degli sviluppatori e si concentrano il più possibile sul loro compito estremamente importante. Allo stesso tempo, i devops non utilizzeranno mai un nuovo cavo né emetteranno un nuovo laptop dalla stanza sul retro (c) KO
Qual è il trucco?
Alla domanda “Chi è DevOps?” metà degli operatori sul campo iniziano a rispondere qualcosa del tipo "Bene, in breve, questo è l'amministratore che ..." e più avanti nel testo. Sì, una volta, quando la professione di ingegnere DevOps stava appena emergendo tra gli amministratori più talentuosi in termini di manutenzione del servizio, le differenze tra loro non erano evidenti a tutti. Ma ora, quando le funzioni di devops e admin nel team sono diventate radicalmente diverse, è inaccettabile confonderle tra loro o addirittura equipararle.
Ma cosa significa questo per le imprese?
Assumere, è tutto.
Apri un posto vacante per "Amministratore di sistema" e i requisiti elencati sono "interazione con lo sviluppo e i clienti", "sistema di consegna CI/CD", "manutenzione dei server e delle apparecchiature dell'azienda", "amministrazione dei sistemi interni" e così via SU; capisci che il datore di lavoro sta dicendo sciocchezze. Il problema è che invece di "Amministratore di sistema" il titolo del posto vacante dovrebbe essere "Ingegnere DevOps" e se questo titolo viene modificato, tutto va a posto.
Tuttavia, che impressione si ottiene leggendo un simile posto vacante? Che l'azienda è alla ricerca di un operatore multi-macchina che implementerà sia un sistema di controllo della versione che di monitoraggio e stringerà il tornado con i denti...
Ma per non aumentare il grado di tossicodipendenza nel mercato del lavoro, è sufficiente chiamare i posti vacanti con i loro nomi propri e capire chiaramente che un ingegnere DevOps e un amministratore di sistema sono due entità diverse. Ma il desiderio irrefrenabile di alcuni datori di lavoro di presentare al candidato l'elenco più ampio possibile di requisiti porta al fatto che gli amministratori di sistema “classici” smettono di capire cosa sta succedendo intorno a loro. Cosa, la professione sta mutando e loro sono al passo con i tempi?
No no e ancora una volta no. Gli amministratori dell’infrastruttura che gestiranno i server interni dell’azienda, o occuperanno posizioni di supporto L2/L3 e aiuteranno altri dipendenti, non se ne sono andati e non se ne andranno.
Questi specialisti possono diventare ingegneri DevOps? Naturalmente possono. In realtà, si tratta di un ambiente correlato che richiede competenze di amministrazione di sistema, ma oltre a ciò si aggiunge il lavoro con il monitoraggio, i sistemi di consegna e, in generale, una stretta interazione con il team di sviluppo e test.
Un altro problema DevOps
Tutto, infatti, non si limita alle sole assunzioni e alla costante confusione tra amministratori e devop. Ad un certo punto, l'azienda si è trovata ad affrontare il problema della fornitura di aggiornamenti e dell'interazione del team di sviluppo con l'infrastruttura finale.
Forse è stato quando uno zio con gli occhi scintillanti si è alzato sul palco di una conferenza e ha detto: “Lo facciamo e lo chiamiamo DevOps. Questi ragazzi risolveranno tutti i tuoi problemi” - e ha iniziato a raccontare quanto è bella la vita in azienda dopo aver implementato le pratiche DevOps.
Tuttavia, non è sufficiente assumere un ingegnere DevOps per far sì che tutto funzioni come dovrebbe. L’azienda deve subire una completa trasformazione DevOps, ovvero il ruolo e le capacità dei nostri DevOps devono essere chiaramente compresi anche da parte del team di sviluppo e test del prodotto. Abbiamo una storia “meravigliosa” su questo argomento che illustra pienamente tutta la brutalità che sta accadendo in alcuni luoghi.
Situazione. DevOps è tenuto a distribuire un sistema di rollback della versione senza approfondire realmente come funzionerà. Supponiamo che all'interno del sistema Utenti siano presenti campi separati per nome, cognome e password. Esce una nuova versione del prodotto, ma per gli sviluppatori il "rollback" è solo una bacchetta magica che risolverà tutto e non sanno nemmeno come funziona. Quindi, ad esempio, nella patch successiva gli sviluppatori hanno combinato i campi del nome e del cognome, li hanno messi in produzione, ma per qualche motivo la versione è lenta. Cosa sta succedendo? La direzione si avvicina al devops e dice "Premi l'interruttore!", ovvero gli chiede di tornare alla versione precedente. Cosa fa il devops? Viene ripristinato alla versione precedente, ma poiché gli sviluppatori non volevano capire come è stato eseguito questo ripristino, nessuno ha detto al team devops che era necessario eseguire il rollback anche del database. Di conseguenza, per noi tutto si blocca e invece di un sito Web lento, gli utenti vedono l'errore "500", perché la vecchia versione non funziona con i campi del nuovo database. Devops non lo sa. Gli sviluppatori tacciono. La direzione inizia a perdere i nervi e i soldi e si ricorda dei backup, offrendosi di ritirarli in modo che "almeno qualcosa funzioni". Di conseguenza, gli utenti perdono tutti i propri dati per un periodo di tempo.
I pazzi, ovviamente, vanno ai devops, che "non hanno creato un sistema di rollback adeguato", e a nessuno importa che gli alci in questa storia siano sviluppatori.
La conclusione è semplice: senza un approccio normale al DevOps in quanto tale, è di scarsa utilità.
La cosa principale da ricordare: un ingegnere DevOps non è un mago e senza comunicazioni di qualità e interazione bidirezionale con lo sviluppo, non riuscirà a far fronte ai suoi compiti. Gli sviluppatori non possono essere lasciati soli con i loro "problemi" o ricevere il comando "non immischiarsi con gli sviluppatori, il loro compito è programmare" e poi sperare che in un momento critico tutto funzioni come dovrebbe. Non è così che funziona.
In sostanza, DevOps è una competenza al confine tra gestione e tecnologia. Inoltre, non è affatto ovvio che in questo cocktail ci debba essere più tecnologia che gestione. Se vuoi davvero costruire processi di sviluppo più rapidi ed efficienti, devi fidarti del tuo team devops. Conosce gli strumenti giusti, ha realizzato progetti simili, sa come farlo. Aiutalo, ascolta i suoi consigli, non cercare di isolarlo in una sorta di unità autonoma. Se gli amministratori possono lavorare da soli, in questo caso i devop sono inutili, non potranno aiutarti a migliorare se tu stesso non vuoi accettare questo aiuto.
E un’ultima cosa: smettetela di offendere gli amministratori delle infrastrutture. Hanno il loro fronte di lavoro estremamente importante. Sì, un amministratore può diventare un ingegnere DevOps, ma ciò dovrebbe avvenire su richiesta della persona stessa e non sotto pressione. E non c'è niente di sbagliato nel fatto che un amministratore di sistema voglia rimanere un amministratore di sistema: questa è la sua professione separata e un suo diritto. Se vuoi intraprendere una trasformazione professionale non devi mai dimenticare che dovrai sviluppare non solo competenze tecnologiche, ma anche gestionali. Molto probabilmente, spetterà a te come leader riunire tutte queste persone e insegnare loro a comunicare nella stessa lingua.
Fonte: habr.com