Come può un amministratore Linux migliorare le proprie capacità di scripting e automazione della shell?

Nella mia organizzazione, lavoro con un gruppo di personale del NOC, ingegneri junior in erba e una manciata di ingegneri senior; tutto con un focus su Linux. Un passo interessante nel modo in cui l'azienda sviluppa talento è che c'è un percorso dal NOC ai gradi di ingegneria senior. Vedendo il pool di talenti come un nuovo arrivato, vedo che c'è una divisione nei set di abilità che tende a crescere nel tempo ...

• Ci sono ingegneri che conoscono bene una o più tecnologie particolari e sono costantemente immersi ... ad esempio MySQL, firewall, storage SAN, bilanciamento del carico ...
• Ci sono altri che sono generalisti e possono navigare su più tecnologie.
• Tutti imparano abbastanza Linux (comandi, processi) per fare ciò di cui hanno bisogno e usare quotidianamente.

Un fattore di differenziazione tra alcuni membri del personale è la capacità di comprendere le metodologie di scripting, automazione e gestione della configurazione. Ad esempio, abbiamo due ingegneri che svolgono la maggior parte del lavoro di Amazon AWS CloudFormation e un altro che gestisce la maggior parte dell'infrastruttura Puppet . Forse un quarto degli ingegneri è abile nello scripting della shell BASH.

Guardando questo nel contesto della domanda incredibilmente alta di competenze DevOps nel mercato del lavoro , sono curioso di sapere come altre organizzazioni promuovano lo sviluppo di queste abilità e accrescono il loro talento interno. Lo scripting non sembra un concetto particolarmente insegnabile.

• In che modo un amministratore di sistema migliora il proprio scripting della shell?
• C'è ancora posto per gli ingegneri che non riescono / non riescono a tenere il passo nel paradigma DevOps?
• Dobbiamo semplicemente supporre che alcune persone rimarranno indietro con l'evoluzione di queste tecnologie? Va bene?

Ho il vantaggio di comprendere le dimensioni e la complessità del tuo ambiente. Visto che lavori per un provider di cloud / hosting, è lecito ritenere che tu abbia un gran numero di ambienti di dimensioni medio-piccole (10-100 server). Ci sono certamente attività quotidiane che vengono svolte dal jr. ingegneri e personale NOC ripetitivi (creazione di account utente, configurazione di agenti di backup, ecc.). Allo stesso modo, ci sono probabilmente alcune cose manuali che vengono fatte da sr. agli ingegneri piace installare ESXi su nuovo hardware o configurare cose come MPIO o installare moduli VMware per specifici set di hardware. Tutte queste cose possono e dovrebbero essere automatizzate.

Se il tuo personale è in grado di eseguire la maggior parte del carico di lavoro senza automatizzare, secondo me sei troppo a corto di personale. Qualsiasi personale IT in grado di lavorare per un'intera giornata costituita principalmente da processi manuali non ha motivazioni per l'automazione. Perché apprendere una nuova abilità che non è vista come necessaria e potrebbe anche essere spaventosa ? Dopotutto, la necessità è la madre se l'innovazione.

Quindi, a un certo punto della tua organizzazione, crescerai a una dimensione in cui ti romperai e cadrai a pezzi, o inizierai ad automatizzare quasi tutto ed eccellerai. Certamente, gli ingegneri senior dovrebbero guidare la carica qui, e forse anche lavorare con gli ingegneri junior e il personale NOC per automatizzare parte del loro carico di lavoro. Questo dà il jr. ingegneri l'opportunità di avere il framework di molti script con cui lavorare, che possono modificare per ogni inquilino e la nuova revisione hardware se necessario. Questo elimina il pensiero scoraggiante di "Oh mio Dio, da dove comincio?" dall'equazione e dà loro un balzo in avanti per risolvere un problema reale . Il che mi porta al mio ultimo punto. Libri ed esempi vanno bene e bene, ma c'èproblema che devono affrontare. Assegna loro un obiettivo, come se tutti i nuovi server per il tenant x dovessero avere installato alcuni moduli ESXi e quindi lavorare con loro per realizzarlo. Quindi adattare lo script per funzionare in un ambiente multi-tenant.

In che modo un amministratore di sistema migliora il proprio scripting della shell?

Da dover a, come descritto sopra.

C'è ancora posto per gli ingegneri che non riescono / non riescono a tenere il passo nel paradigma DevOps?

Certo, ci sono molte organizzazioni che non possono o non passeranno alla metodologia DevOps. Sembrano essere opzioni sempre più noiose , ma sono comunque opzioni.

Dobbiamo semplicemente supporre che alcune persone rimarranno indietro con l'evoluzione di queste tecnologie?

Come con qualsiasi nuova tecnologia, sì.

tl; dr Non avrai mai nessuno che investa davvero nell'apprendimento finché non ne vedono il valore. Se riescono a svolgere manualmente le loro attività quotidiane, allora sei troppo a corto di personale e non ci sono incentivi.

• In che modo un amministratore di sistema migliora il proprio scripting della shell?

Pratica, mescolata con unità. Sembra banale, ma devi voler migliorare, oltre alla pratica. Se non ti piace davvero lo scripting, puoi essere costretto a farlo per anni quando devi e non riesci mai davvero a farlo. Se non vuoi migliorare, puoi sederti accanto al miglior sceneggiatore del mondo ogni giorno al lavoro e non prendere una frazione dell'abilità che potresti avere.

Conosco quelle persone che, nonostante lavorino nell'IT, ostinatamente rifiutano di imparare qualsiasi tipo di scripting. Presto non ci sarà posto per quelle persone in questo settore. Fanno parte di una generazione morente.

( Non sto parlando di anziani, intendo che in senso figurato.: P )

• C'è ancora posto per gli ingegneri che non riescono / non riescono a tenere il passo nel paradigma DevOps?

No. Ogni cosa che fanno può essere e alla fine sarà automatizzata.

Direi che forse non avremmo mai dovuto chiamarli "ingegneri". È abbastanza brutto che l'industria IT si sia appropriata della parola "ingegnere" per noi stessi, che a mio avviso è un po 'offensiva per gli ingegneri reali che hanno trascorso anni in programmi di istruzione superiore e ottenere certificazioni legali in modo che potessero progettare ponti, grattacieli, collettori di adroni , ecc ... quelli sono i veri ingegneri.

Ma c'è una somiglianza ... Se vuoi definirti un "ingegnere" nel settore IT, questo significa almeno che crei cose. Sei creativo e colleghi i punti in modi nuovi a cui nessuno aveva mai pensato prima. Costruisci cose che nessun altro sapeva quanto sarebbe stato prezioso fino a quando non l'avrai realizzato.

Se non scrivi codice o script, non c'è modo di fare molto con i computer oltre a mantenerli e magari installare un pacchetto software o due. Magari gettare un nuovo disco rigido nel vecchio MSA. E in tal caso, ti definirei un amministratore, certo, ma non necessariamente un ingegnere. E direi che gran parte del tuo lavoro è a rischio di essere automatizzato.

• Dobbiamo semplicemente supporre che alcune persone rimarranno indietro mentre queste tecnologie evolvono?

Il mercato si adatterà. Può darsi che alcune persone non stiano facendo stipendi a 6 cifre quando non li meritano davvero, cosa che accade abbastanza in questo settore.

Trovo che la creatività, e non solo l'abilità di codifica / scripting, sia un fattore chiave. È quella creatività che devi dire a te stesso, " Oh, ehi, potrei automatizzare questo! " E quindi l'abilità entra in gioco solo dopo. Se ti ritrovi a scrivere qualcosa solo dopo che il tuo capo te l'ha detto, allora potresti non avere quell'impulso o quella creatività di cui stavo parlando ... e quelle sono due qualità che sono molto difficili, forse impossibili, da insegnare.

In che modo un amministratore di sistema migliora il proprio scripting della shell?

Come si migliora in qualcosa? Leggi libri, segui le lezioni e quindi applica i principi appresi. (O una combinazione dei metodi.) Questo è semplificato intenzionalmente poiché non c'è niente di speciale sull'apprendimento dello scripting sull'imparare a cucinare o a riparare un'auto.

C'è ancora posto per gli ingegneri che non riescono / non riescono a tenere il passo nel paradigma DevOps?

È difficile rispondere alle esigenze nell'ambito di questo sito (dove esiste un requisito per risposte chiare / definite alle domande poste). Possiamo prevederlo, ma ci sono problemi con il modello DevOps. Sento che è molto difficile per una persona essere estremamente competente in entrambe le discipline. I risparmi sui costi di un dipendente 2-per-1 sono molto interessanti per le aziende in questo momento, ma è difficile dire se questa tendenza è qui per rimanere. Certamente è a breve termine.

Dobbiamo semplicemente supporre che alcune persone rimarranno indietro con l'evoluzione di queste tecnologie?

Al ritmo attuale di come vanno le cose, sì. Molti di voi probabilmente lo stanno osservando sul proprio posto di lavoro. Dovresti assolutamente stare al passo con le offerte di lavoro e sapere quali sono le richieste del mercato. (Ci sono molte offerte di lavoro per Hadoop nella tua zona? Impara Hadoop.) Se non ti stai al passo con il mercato, rischi di rimanere indietro.

Generalmente non si inviano ingegneri junior in un ambiente di produzione complesso che è di importanza critica. Hai ingegneri senior per quello. I ranghi junior dovrebbero poter lavorare in sandbox di sviluppo / test.

Se hai bisogno di un ingegnere per Technology X e vuoi ricoprire il ruolo internamente, trova qualcuno disposto a impararlo, trova una formazione strutturata e combina i due.

Scopri quali competenze sono necessarie in un dipartimento. Trova qualcuno disposto a impararli. Insegna / Distribuisci denaro per la formazione.

C'è ancora posto per gli ingegneri che non riescono / non riescono a tenere il passo nel paradigma DevOps?

"devops" è solo una nuova parola per qualcosa che gli amministratori di sistema hanno fatto per decenni.

Dobbiamo semplicemente supporre che alcune persone rimarranno indietro con l'evoluzione di queste tecnologie?

Piuttosto il contrario. Col passare del tempo, c'è sempre più bisogno di personale tecnico. Chiunque abbia qualsiasi tipo di conoscenza tecnica e abilità tecnica avrà un posto di lavoro.