Come incoraggiare gli amministratori di Windows a raccogliere script? [chiuso]

Quando ho lavorato come amministratore nel mio primo lavoro, ero frustrato che i nostri processi amministrativi con i server Windows fossero una serie di punti e clic; non potremmo mai eguagliare il livello di efficienza con i server Unix che avevano un gruppo di script shell per automatizzare gran parte del lavoro. Presto ho letto di WSH e ADSI e non ho perso tempo a imparare quanta automazione sono riuscito a ottenere con gli script.

Tuttavia, c'era un grosso problema: quasi nessuno dei miei colleghi di Windows era davvero interessato all'apprendimento degli script. Sembravano felici con le faccende manuali che facevano clic con il mouse e non erano mai entusiasti della prospettiva di usare gli script per fare il lavoro per loro conto. Ho faticato a convincerli a acquisire competenze di scripting nonostante gli evidenti aumenti di efficienza. Ho lasciato quel lavoro alla ricerca di una carriera di sviluppo software a tempo pieno da allora in poi.

Quasi un decennio di lavoro in vari ambienti e clienti diversi, incontro ancora amministratori di Windows che possiedono principalmente questo "umore" generale in cui eviterebbero il più possibile gli script. Nonostante il crescente livello di accessibilità, le tecnologie dei server Windows si stanno aprendo per lo scripting e l'automazione. Sono quasi certo che la maggior parte degli amministratori siano amministratori proprio perché odiano assolutamente svolgere qualsiasi tipo di incarico di programmazione. Quali sono alcuni mezzi per incoraggiare e motivare gli amministratori che lo scripting può davvero aiutarli a lungo termine?

Come amministratore di Unix e Windows che fa molti scripting Unix e quasi nessun scripting Windows, direi che è in parte dovuto all'incredibile imbarazzo delle utilità e delle API di scripting di Windows e alla difficoltà (forse la non ovvietà sarebbe una parola migliore) di eseguire le cose in remoto su un computer Windows.

Voglio dire, WTF è questo?

Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

Parte del problema, credo, è che ci sia un'API. Sotto Unix, gli amministratori stanno in gran parte scrivendo l'automazione delle utility da riga di comando che già usano. Sotto Windows, devi usare questa API che non ha familiarità a tutti i livelli. Ad esempio, cosa significa "impersonare"? Questo è un concetto banale per un amministratore Unix, che probabilmente utilizzerà sudo e su e avrà già familiarità con gli script setuid. Ma è improbabile che un amministratore di Windows abbia familiarità con tutto ciò; potrebbero conoscere "runas" (o l'opzione equivalente della GUI), ma hanno molte più probabilità di accedere come amministratore quando devono fare qualcosa di amministrativo.

E la documentazione sugli script in Windows è infelice. Per prima cosa, è molto più "linguaggio interpretato" rispetto allo script, sempre perché usano un'API (non familiare) e non comandi con cui hanno già familiarità. Ma non credo di aver mai trovato nulla di utile nella documentazione di Microsoft che non sia stato portato nel trovare qualcuno che stava già facendo qualcosa di simile a quello che volevo e che mi ha indicato nella giusta direzione. Da nessuna parte sembra esserci un elenco di cose che puoi fare. È come se tu avessi già familiarità con gli interni di Windows per fare le cose più elementari.

Non che gli script Unix spesso non assomiglino al rumore di linea. Ma un amministratore Unix può iniziare con uno script che non fa altro che eseguire semplici comandi che già conosce. ("Devo sempre eseguire questi tre comandi in successione. Se li metto insieme in un file, posso farlo in un solo comando!") E poi può progredire in seguito quando si sente a suo agio con la situazione. Al contrario, non c'è modo per un amministratore di eseguire lo script "accedi al server come amministratore; fai clic su Start → Impostazioni → Pannello di controllo; fai doppio clic su Sistema; fai clic sulla scheda Nome computer; ecc." Sì, qualunque cosa stesse cercando di arrivare è probabilmente presentata attraverso un'API da qualche parte, ma non c'è modo per lui di trovarla in modo incrementale.

Quindi, per rispondere alla domanda "come possiamo convincere gli amministratori di Windows a fare più script?", La risposta è rendere lo script meno alieno. Come farlo, non lo so.

Onestamente, la risposta è nelle mani di Microsoft. Non c'è motivo per cui non possano avere un'utilità da riga di comando per fare tutto ciò che viene fatto tramite la GUI. (In realtà ce ne sono molti là fuori ora, ma non sono pubblicizzati, sono scarsamente documentati e sono incoerenti.) Inoltre non c'è motivo per cui non ci possa essere alcun suggerimento nella GUI su cosa quel pulsante lo fa davvero. Avere una descrizione comandi che mostra l'oggetto API che viene modificato. Oppure documentalo nella finestra della Guida.

Non c'è alcun problema a proteggere gli utenti dagli interni, ma Windows sembra fare di tutto per nascondere attivamente quegli interni, anche da coloro che vogliono trovarli.

Assegna loro un'attività che può davvero essere eseguita solo tramite uno script: ad esempio, una volta ho dovuto scrivere la creazione di centinaia di cartelle e autorizzazioni personalizzate per ciascuna cartella e dovevo aggiornarla QUOTIDIANAMENTE. Se lo facessero manualmente, sarebbe il loro unico lavoro. Lo script, che ha utilizzato CACLS tra l'altro per ripristinare le autorizzazioni in base all'output di un file di testo delimitato, ha impiegato circa un giorno per perfezionarsi (lo script di base è stato eseguito in circa un'ora).

Quando inizi a vedere cosa puoi fare con gli script, può essere una grande vittoria.

Una volta ho assunto un amministratore di sistema che si è completamente rifiutato di fare qualsiasi "programmazione", ho cercato di mostrargli il modo di dare l'esempio. Il meglio che potevo ottenere da lui era usare il codice esistente e modificare l'assegnazione delle variabili o il nome host ecc. per fare un lavoro. Alcune persone non sono disturbate dalla programmazione, quindi è necessario abbassare la barriera per loro.

Microsoft si sta facendo strada. In SQL Server, è stato possibile per un po 'di tempo fare clic su elementi nella GUI di Management Studio e quindi scaricare uno script t-sql di ciò che hai appena fatto. Questo è fantastico, specialmente per il sistema di Windows non molto incline alla programmazione.

Ho notato che System Center Virtual Machine Manager ha la stessa funzione di script di visualizzazione, tranne che scarica uno script PowerShell. Penso che anche molte altre linee di prodotti stiano introducendo questo.

Come motivare gli amministratori nello scripting? chiamata difficile, un buon amministratore è un amministratore pigro e questo significa un amministratore che scriverà il più possibile. Un amministratore che ha il tempo di fare clic sulle cose non è molto produttivo! Sovraccaricare i tuoi amministratori con così tanto lavoro, che non hanno altra scelta che scrivere.

Sono pienamente d'accordo con il tuo post. Sfortunatamente, non credo che ci sia molto da fare senza il supporto della gestione e dei processi in atto che impongono l' uso degli script. Con una scelta, le persone andranno sempre con ciò che è familiare e ciò che è facile. A volte, questo può sembrare un punto negativo, ma ci sono momenti in cui la semplicità e la familiarità sono un vantaggio.

Da un lato, il sistema Windows è implicitamente pensato per essere semplice / facile mentre i sistemi Unix / Linux sono molto più difficili e meno tolleranti. Quindi chi può incolpare gli amministratori per aver preso la strada della minor resistenza? Mentre tu, o io o molte altre persone potreste riconoscere il potere dello scripting, le persone alla fine impareranno in un modo o nell'altro. In genere, gli amministratori che tengono duro con gli script imparano nel modo più duro. Mi piace lavorare in modo più intelligente, ad altri potrebbe piacere solo lavorare.

Quali sono alcuni mezzi per incoraggiare e motivare gli amministratori che lo scripting può davvero aiutarli a lungo termine?

Pensavo che potresti motivare le persone, ma la realtà è che a meno che tu non ne sia responsabile , la probabilità di una "motivazione" riuscita è estremamente bassa. Il mio atteggiamento in questi giorni è: quelli che vogliono imparare, aiuterò. Non essere un venditore per un prodotto che nessuno vuole indipendentemente dal fatto che ne abbia bisogno. Quando aiuti / insegni a una sola persona motivata (per qualsiasi motivo), saranno il catalizzatore del cambiamento. Non tu. Solo i miei due centesimi.

Un mantra che seguo è "Lavora in modo più intelligente, non più difficile". Fare qualsiasi processo più di un paio di volte significa che di solito c'è un modo per scriverlo per farlo automaticamente con un clic del mouse, uno script bash o un altro metodo. Per come la vedo io, questo mi libera personalmente a svolgere compiti più importanti che non sono tanto il "lavoro manuale" dell'amministrazione del sistema.

Coloro che vogliono evitare lo scripting possono avere molte cose che gli passano per la testa. Forse apprezzano l'interfaccia della GUI e non vogliono imparare la riga di comando o la programmazione. Forse pensano che scrivendo qualcosa stiano riducendo sostanzialmente la loro importanza personale. Ad ogni modo, questo non è il tipo di dipendente che vorrei avere e una riluttanza a fare qualsiasi tipo di scripting mostra che tipo di lavoratore sono. Preferirei avere un risolutore di problemi piuttosto che un amministratore di sistema "stupido".

Per quanto riguarda incoraggiarli e motivarli, direi solo di fare come stavi facendo, mostrare i guadagni in termini di produttività e come può facilitare il loro lavoro. Per alcuni, essere un amministratore di sistema di Windows è solo una busta paga, e sarà difficile motivarli a superare la mentalità punta e clicca che ha funzionato per loro negli ultimi 10 anni.

Ci sono un paio di problemi che devi superare, ne hai menzionato uno, che molti amministratori non vogliono essere coinvolti nella programmazione, anche se di basso livello come gli script. L'altro è legato a questo, ed è una questione di controllo. Quando un amministratore esegue un'attività manualmente, sa esattamente cosa sta succedendo in ogni fase. Molti amministratori possono pensare che sostituendo questo con uno script stiano perdendo il controllo sul processo, in particolare se non capiscono lo scripting e non hanno scritto lo script (e non hanno voluto scriverlo).

Penso che questo sia più un problema con gli amministratori di Windows che con quelli di Unix poiché lo scripting è stato una parte importante dell'amministrazione Unix per lungo tempo ed è generalmente qualcosa che gli amministratori di Unix imparano fin dall'inizio, dove l'amministrazione di Windows e la sua GUI intrinseca- ness porta a un processo più manuale e lo scripting può sembrare innaturale.

Sfortunatamente convincere gli sviluppatori a superare questa gobba è una dura battaglia. Affinché l'amministratore abbia ancora la sensazione di avere il controllo, devono capire cosa sta facendo lo script, quindi devono davvero capire e imparare a scrivere e l'unico modo per farlo è se lo fanno capisco davvero cosa possono fare gli script per loro

Va benissimo dicendo che renderà le cose più veloci, renderà la vita più facile ecc., Ma puoi dimostrarglielo? Trova un'attività che odiano, che devono svolgere regolarmente e cerca di automatizzarla. Se riesci a prendere questo orribile compito e renderlo uno script a singolo clic, ti adoreranno, ma soprattutto possono vedere il vantaggio dell'uso degli script.

[sospiro] Questo è troppo diffuso nel mondo di Windows, anche se metterei in dubbio la tua affermazione sulla maggioranza che non vuole fare il pony e imparare a scrivere. La cosa più grande che abbia mai fatto nella mia carriera di amministratore di sistema è stata imparare VB e Perl, che hanno portato a VBS, che ha portato MOLTE altre cose.

Se solo mostrarli non funziona per motivare, un trucco che mi piace usare è quello di lanciare dichiarazioni sottili di fronte al management :) Chiamalo succhiare se vuoi, ma non è così. Mostra ai decisori i vantaggi, spesso inizia a proliferare attraverso il gruppo. Non fare il cretino, però.

Su una nota più sottile, è difficile (se non impossibile) cambiare qualcuno. Dare l'esempio!

Questa domanda è altamente soggettiva. Sebbene io sia d'accordo con l'efficienza e il maggiore controllo forniti dallo scripting, perché deve essere un mandato? Perché devi incoraggiare le persone a usare gli script solo perché ti piace usarli? Perché non lasciare che le persone scelgano di usare gli strumenti che preferiscono e preferiscono?

Questa domanda illustra anche un pregiudizio comune che esiste nel mondo IT: che se non scrivo non devo essere intelligente o bravo come qualcuno che fa lo script, e questo è sbagliato. Ho conosciuto un sacco di persone che potevano scrivere script meglio di me, ma non potevano subnet per salvare la propria vita o capire come eseguire una traccia di rete, o configurare SQL Server per utilizzare AWE o non sapessero quale avvio. il file ini era per, ecc., ecc.

Onestamente, puoi condurre un cavallo all'acqua, ma non puoi farlo bere.

Sono arrivato come SysAd nel Corpo dei Marines circa 10 anni fa, dove c'è un ampio divario tra l'essere un amministratore e l'essere un programmatore. Essere un programmatore di solito significa che rimani bloccato a gestire il sito Web del progetto per animali domestici del CO (facendo poco del tuo vero lavoro svolto ...).

Per questo motivo, ho resistito all'apprendimento del codice, ma una volta deciso di provarlo, mi sono divertito molto.

Per quanto riguarda l'attrazione di qualcuno, prova a utilizzare gli script AD / LDAP per attirarli. (Penso che sia un po 'più accessibile rispetto a gestire WMI.) Assegna una progressione di attività, dì "dammi i nomi utente e gli indirizzi e-mail del persone nel gruppo XYZ ".

Ho scritto questo codice per trovare tutti gli utenti che non erano membri di nessuno dei gruppi specificati: https://github.com/gwaldo/LDAP-Inverse-Group-Membership-Report

Per quanto riguarda le risorse, dai un'occhiata ai Microsoft Scripting Guys (che hanno articoli e tutorial eccellenti) e Scriptomatic2, che adoro per scavare in WMI.

La prossima domanda: perché dovrebbero scrivere? Ciò determinerà la risposta.

Presumibilmente, lo script perché è più efficiente. In tal caso, puoi mostrare a tutti gli altri, oppure indicare al management che esistono modi più efficienti per amministrare i sistemi e attendere che ne traggano vantaggio in una misura di riduzione dei costi.

Qualcuno con autorità può imporre lo scripting, richiedendo che ci siano script in atto per gestire la maggior parte delle cose. Quanto bene funzionerà dipende da diverse cose; se solo dichiarato così, è probabile che gli script rimangano terribilmente inadeguati e obsoleti, mentre gli amministratori funzionano normalmente.

C'è anche la domanda su come questo ti sta influenzando. Ti dà fastidio, o sarebbe la tua vita migliore se i tuoi compagni amministrassero le cose scritte?

In realtà ho avuto un altro pensiero. In relazione al fatto che gli amministratori di Windows junior vengono utilizzati per le interazioni della GUI, forse sarebbe utile se li avessi avviati con l'interazione della GUI di scripting, con qualcosa come AutoIt . Ciò consentirebbe loro di mettere il piede sulla porta per quanto riguarda lo scripting, pur consentendo loro di utilizzare gli strumenti che già conoscono, invece di buttare via i loro strumenti esistenti e far loro imparare nuovi strumenti e scripting allo stesso tempo.

Quindi, una volta che si sentono a proprio agio con l'idea dello scripting in generale, possono passare allo scripting senza GUI. Anche se non, tuttavia, automatizzare i clic sui pulsanti può potenzialmente essere un grande risparmio di tempo.

Ho definito gli script come "Documentazione che fa il lavoro per te".

Manager: vai a dedicare innumerevoli ore alla creazione di documentazione, che un alunno di prima elementare può capire, che sarà obsoleto entro la fine della settimana, in modo che i tuoi colleghi possano fare clic su Task-X.

Dipendente: ho uno script che fa Task-X, potrei semplicemente darglielo.

Manager: Certo, dopo aver finito la documentazione che ho appena richiesto, documenta anche la tua sceneggiatura, con un diagramma di flusso.

Ho definito gli script come "Documentazione che fa il lavoro per te".

Manager: vai a dedicare innumerevoli ore alla creazione di documentazione, che un alunno di prima elementare può capire, che sarà obsoleto entro la fine della settimana, in modo che i tuoi colleghi possano fare clic su Task-X.

Dipendente: ho uno script che fa Task-X, potrei semplicemente darglielo.

Manager: Certo, dopo aver finito la documentazione che ho appena richiesto, documenta anche la tua sceneggiatura, con un diagramma di flusso.

Non dimenticare che la documentazione dovrebbe essere contenuta in un documento MS Word per complicare la lettura dal server.