Comment encourager les administrateurs Windows à choisir des scripts? [fermé]

Lorsque j'ai travaillé en tant qu'administrateur dans mon premier emploi, j'étais frustré que nos processus d'administration avec les serveurs Windows soient une série de pointer-cliquer; nous n'avons jamais pu égaler le niveau d'efficacité avec les serveurs Unix qui avaient un groupe de scripts shell pour automatiser une grande partie du travail. J'ai rapidement lu des informations sur WSH et ADSI et je n'ai pas perdu de temps à apprendre combien d'automatisation j'ai pu réaliser avec les scripts.

Il y avait cependant un énorme problème - presque aucun de mes collègues Windows n'était vraiment intéressé par l'apprentissage des scripts. Ils semblaient satisfaits des tâches de clic manuel de la souris et n'étaient jamais excités à l'idée d'utiliser des scripts pour faire le travail en leur nom. J'ai eu du mal à les convaincre d'acquérir des compétences en scripting malgré l'augmentation évidente de l'efficacité. Par la suite, j'ai quitté cet emploi pour poursuivre une carrière de développeur de logiciels à plein temps.

Presque une décennie sur le travail dans divers environnements et différents clients, je rencontre toujours des administrateurs Windows possédant principalement cette "humeur" générale où ils éviteraient autant que possible les scripts. Malgré le niveau croissant d'accessibilité, les technologies de serveur Windows s'ouvrent pour l'écriture de scripts et l'automatisation. Je suis presque certain que la majorité des administrateurs sont des administrateurs précisément parce qu'ils détestent absolument effectuer toute sorte de tâches de programmation. Quels sont les moyens d'encourager et de motiver les administrateurs pour que les scripts puissent vraiment les aider à long terme?

En tant qu'administrateur Unix et Windows qui fait beaucoup de scripts Unix et presque aucun script Windows, je dirais que cela est en partie dû à l'incroyable maladresse des utilitaires de script et des API Windows, et à la difficulté (peut-être que la non-évidence serait un meilleur mot) d'exécuter des choses à distance sur une machine Windows.

Je veux dire, WTF est-ce?

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

Une partie du problème, je pense, est qu'il y est une API. Sous Unix, les administrateurs écrivent en grande partie l'automatisation des utilitaires de ligne de commande qu'ils utilisent déjà. Sous Windows, vous devez utiliser cette API qui n'est pas familière à tous les niveaux. Par exemple, que signifie «imiter»? C'est un concept trivial pour un administrateur Unix, qui est susceptible d'utiliser sudo et su et déjà familier avec les scripts setuid. Mais il est peu probable qu'un administrateur Windows connaisse tout cela; ils connaissent peut-être les «runas» (ou l'option GUI équivalente), mais ils sont beaucoup plus susceptibles de se connecter en tant qu'administrateur lorsqu'ils ont besoin de faire quelque chose d'administrateur.

Et la documentation sur les scripts dans Windows est misérable. D'une part, c'est bien plus un «langage interprété» qu'un script, encore une fois parce qu'ils utilisent une API (peu familière) et non des commandes qu'ils connaissent déjà. Mais je ne pense pas avoir trouvé quoi que ce soit d'utile dans la documentation de Microsoft qui n'ait pas été conduit à trouver quelqu'un qui faisait déjà quelque chose de proche de ce que je voulais qui m'indiquait dans la bonne direction. Nulle part il ne semble y avoir de liste de choses que vous pouvez faire. C'est comme si vous deviez déjà vous familiariser avec les composants internes de Windows pour faire les choses les plus élémentaires.

Pas que les scripts Unix ne ressemblent pas souvent à du bruit de ligne. Mais un administrateur Unix peut commencer avec un script qui ne fait rien d'autre que d'exécuter des commandes simples qu'il connaît déjà. ("Je dois toujours exécuter ces trois commandes successivement. Si je les rassemble dans un fichier, je peux le faire en une seule commande!") Et puis il pourra plus tard progresser à mesure qu'il se familiarisera avec la situation. En revanche, il n'y a aucun moyen pour un administrateur de script "se connecter au serveur en tant qu'administrateur; cliquez sur Démarrer → Paramètres → Panneau de configuration; double-cliquez sur Système; cliquez sur l'onglet Nom de l'ordinateur, etc." Oui, tout ce qu'il essayait d'obtenir est probablement présenté quelque part via une API, mais il n'a aucun moyen de le trouver progressivement.

Donc, pour répondre à la question "comment pouvons-nous amener les administrateurs Windows à faire plus de scripts?", La réponse est, rendre les scripts moins étrangers. Comment faire ça, je ne sais pas.

Honnêtement, la réponse est entre les mains de Microsoft. Il n'y a aucune raison qu'ils ne puissent pas avoir d'utilitaire de ligne de commande pour faire tout ce qui se fait via l'interface graphique. (Il y en a beaucoup en ce moment, mais ils ne sont pas annoncés, ils sont mal documentés et ils sont incohérents.) Il n'y a également aucune raison qu'il ne puisse y avoir aucune indication dans l'interface graphique sur ce bouton fait réellement. Avoir une info-bulle qui montre l'objet API qui est en cours de modification. Ou documentez-le dans la fenêtre d'aide.

Il n'y a aucun problème à protéger les utilisateurs des internes, mais Windows semble faire tout son possible pour cacher activement ces internes, même à ceux qui veulent les trouver.

Donnez-leur une tâche qui ne peut vraiment être effectuée que par le biais d'un script - par exemple, j'ai dû une fois créer la création de centaines de dossiers et des autorisations personnalisées pour chaque dossier et il fallait le mettre à jour QUOTIDIEN. S'ils devaient le faire manuellement, ce serait leur seul travail. Le script, qui utilisait CACLS entre autres pour réinitialiser les autorisations en fonction de la sortie d'un fichier texte délimité, a pris environ une journée pour se perfectionner (le script de base a été réalisé en environ une heure).

Lorsque vous commencez à voir ce que vous pouvez faire avec les scripts, cela peut être une énorme victoire.

J'ai embauché une fois un administrateur système qui a carrément refusé de faire de la «programmation». J'ai essayé de lui montrer la voie en donnant l'exemple. Le mieux que j'ai pu tirer de lui était d'utiliser le code existant et de modifier l'affectation des variables ou les noms d'hôtes ect. pour faire un travail. Certaines personnes ne sont tout simplement pas gênées par la programmation, vous devez donc abaisser la barrière pour elles.

Microsoft fait des progrès dans ce domaine. Dans SQL Server, il est possible depuis un certain temps maintenant de cliquer sur des éléments dans l'interface graphique de Management Studio, puis de vider un script t-sql de ce que vous venez de faire. C'est génial, en particulier pour les programmeurs inclinés de Windows.

J'ai remarqué que System Center Virtual Machine Manager a la même fonctionnalité de script d'affichage, sauf qu'il vide un script PowerShell. Je pense que de nombreuses autres gammes de produits introduisent également cela.

Comment motiver les administrateurs à créer des scripts? appel difficile, un bon administrateur est un administrateur paresseux et cela signifie un administrateur qui scriptera autant que possible. Un administrateur qui a le temps de cliquer sur les choses n'est pas très productif! Surchargez vos administrateurs avec tellement de travail qu'ils n'ont d'autre choix que de scénariser.

Je suis entièrement d'accord avec votre message. Malheureusement, je ne pense pas qu'il y ait beaucoup à faire sans le soutien de la direction et des processus en place qui imposent l' utilisation de scripts. Si on leur donne le choix, les gens choisiront toujours ce qui leur est familier et ce qui est facile. Parfois, cela peut sembler être un point négatif, mais il y a des moments où la simplicité et la familiarité sont un plus.

D'une part, le système Windows est implicitement censé être simple / facile tandis que les systèmes Unix / Linux sont beaucoup plus difficiles et moins indulgents. Alors, qui peut blâmer les administrateurs d'avoir pris le chemin de la moindre résistance? Bien que vous, ou moi ou de nombreuses autres personnes puissiez reconnaître le pouvoir des scripts, les gens finiront par apprendre d'une manière ou d'une autre. En règle générale, les administrateurs qui résistent aux scripts apprennent à la dure. J'aime travailler plus intelligemment, d'autres peuvent simplement aimer travailler.

Quels sont les moyens d'encourager et de motiver les administrateurs pour que les scripts puissent vraiment les aider à long terme?

Avant, je pensais que vous pouviez motiver les gens, mais en réalité, à moins que vous ne soyez en charge d'eux, la probabilité d'une "motivation" réussie est extrêmement faible. Mon attitude ces jours-ci est: ceux qui veulent apprendre, je vais aider. Ne soyez pas vendeur pour un produit dont personne ne veut, qu'il en ait besoin ou non. Lorsque vous aidez / enseignez une seule personne motivée (pour quelque raison que ce soit), elle sera le catalyseur du changement. Pas toi. Juste mes deux cents.

Un mantra que j'utilise est "Travailler plus intelligemment, pas plus dur". Faire n'importe quel processus plus de quelques fois signifie qu'il existe généralement un moyen de l'écrire pour le faire automatiquement avec un clic de souris, un script bash ou une autre méthode. Selon moi, cela me libère personnellement pour effectuer des tâches plus importantes qui ne sont pas tant le «travail manuel» de l'administration système.

Ceux qui veulent éviter les scripts peuvent avoir plusieurs choses en tête. Peut-être qu'ils apprécient l'interface graphique et ne veulent pas apprendre la ligne de commande ou la programmation. Peut-être pensent-ils qu'en écrivant quelque chose, ils réduisent essentiellement leur propre importance. Quoi qu'il en soit, ce n'est pas le genre d'employé que j'aimerais avoir et une réticence à faire une sorte de script montre quel type de travailleur ils sont. Je préfère avoir un résolveur de problèmes plutôt qu'un administrateur système "stupide".

En ce qui concerne les encourager et les motiver, je dirais simplement de faire comme vous, de montrer les gains de productivité et comment cela peut faciliter leur travail. Pour certains, être un administrateur système Windows n'est qu'un salaire, et il sera difficile de les motiver à dépasser la mentalité de pointer-cliquer qui a fonctionné pour eux au cours des 10 dernières années.

Il y a quelques problèmes que vous devez surmonter, vous en avez mentionné un, que beaucoup d'administrateurs ne veulent pas être impliqués dans la programmation, même aussi bas que le script. L'autre est lié à cela, et c'est une question de contrôle. Lorsqu'un administrateur effectue une tâche manuellement, il sait exactement ce qui se passe à chaque étape. De nombreux administrateurs peuvent penser qu'en remplaçant cela par un script, ils perdent le contrôle du processus, en particulier s'ils ne comprennent pas les scripts et n'ont pas écrit le script (et ne voulaient pas l'écrire).

Je pense que c'est plus un problème avec les administrateurs Windows qu'avec les administrateurs Unix, car les scripts font partie intégrante de l'administration Unix depuis longtemps et sont généralement quelque chose que les administrateurs Unix apprennent depuis le tout début, alors que l'administration Windows et son interface graphique inhérente- ness conduit à un processus plus manuel et les scripts peuvent sembler contre nature.

Malheureusement, obtenir les développeurs de cette bosse est une bataille difficile. Pour que l'administrateur se sente toujours en contrôle, il doit comprendre ce que fait le script, et donc vraiment besoin de comprendre et d'apprendre à créer un script, et la seule façon de les amener à le faire est s'ils vraiment comprendre ce que les scripts peuvent leur faire

C'est très bien de dire que cela rendra les choses plus rapides, facilitera la vie, etc., mais pouvez-vous le leur prouver? Trouvez une tâche qu'ils détestent, qu'ils doivent faire régulièrement et essayez de l'automatiser. Si vous pouvez prendre cette tâche horrible et en faire un script en un seul clic, ils vous adoreront, mais plus important encore, ils peuvent voir l'avantage d'utiliser des scripts.

[soupir] Ceci est beaucoup trop répandu dans le monde Windows, bien que je remette en question votre affirmation selon laquelle la majorité ne veut pas poney et apprendre à écrire. La plus grande chose que j'ai jamais faite au cours de ma carrière d'administrateur système a été d'apprendre VB et Perl, ce qui a conduit à VBS, qui a conduit BEAUCOUP d'autres choses.

Si juste les montrer ne fonctionne pas pour motiver, une astuce que j'aime utiliser est de jeter des déclarations subtiles devant la direction :) Appelez ça sucer si vous voulez, mais ce n'est pas le cas. Montrez aux décideurs les avantages, souvent cela commence à proliférer à travers le groupe. Ne soyez pas un imbécile à ce sujet, cependant.

Sur une note plus subtile, il est difficile (voire impossible) de changer quelqu'un. Mener par l'exemple!

Cette question est très subjective. Bien que je sois d'accord avec l'efficacité et le contrôle accru fournis par les scripts, pourquoi doit-il s'agir d'un mandat? Pourquoi devez-vous encourager les gens à utiliser les scripts simplement parce que vous aimez les utiliser? Pourquoi ne pas laisser les gens choisir d'utiliser les outils qu'ils aiment et préfèrent?

Cette question illustre également un parti pris commun qui existe dans le monde informatique: que si je ne fais pas de script, je ne dois pas être aussi intelligent ou aussi bon que quelqu'un qui fait du script, et c'est faux. J'ai connu beaucoup de gens qui pouvaient mieux écrire que moi, mais ils ne pouvaient pas créer de sous-réseau pour sauver leur vie ou comprendre comment exécuter une trace réseau, ou configurer SQL Server pour utiliser AWE, ou ne savaient pas ce que le démarrage. fichier ini était pour, etc., etc.

Honnêtement, vous pouvez conduire un cheval à l'eau, mais vous ne pouvez pas le faire boire.

Je suis arrivé en tant que SysAd dans le Corps des Marines il y a environ 10 ans, où il y a un grand écart entre être un administrateur et être un codeur. Être codeur signifie généralement que vous êtes coincé avec le site Web du projet pour animaux de compagnie du commandant (en obtenant peu de votre travail réel ...).

Pour cette raison, j'ai résisté à l'apprentissage du code, mais une fois que j'ai décidé de l'essayer, je me suis éclaté.

Pour ce qui est d'attirer quelqu'un, essayez d'utiliser des scripts AD / LDAP pour les attirer. (Je pense que c'est un peu plus accessible que de traiter avec WMI.) Attribuez une progression des tâches, dites "donnez-moi les noms d'utilisateur et les adresses e-mail des personnes du groupe XYZ ".

J'ai écrit ce morceau de code pour trouver tous les utilisateurs qui n'étaient membres d'aucun des groupes spécifiés: https://github.com/gwaldo/LDAP-Inverse-Group-Membership-Report

En ce qui concerne les ressources, consultez les Microsoft Scripting Guys (qui ont d'excellents articles et tutoriels) et Scriptomatic2, que j'aime pour creuser dans WMI.

La question suivante: pourquoi devraient-ils script? Cela déterminera la réponse.

Vraisemblablement, vous scriptez parce que c'est plus efficace. Dans ce cas, vous pouvez montrer à tout le monde ou signaler à la direction qu'il existe des moyens plus efficaces d'administrer les systèmes et attendre qu'ils en profitent dans une mesure de réduction des coûts.

Une personne autorisée peut exiger des scripts, en exigeant qu'il y ait des scripts en place pour gérer la plupart des choses. La façon dont cela fonctionnera dépend de plusieurs choses; s'ils sont simplement déclarés ainsi, les scripts resteront probablement inadéquats et obsolètes, tandis que les administrateurs fonctionnent normalement.

Il y a aussi la question de savoir exactement comment cela vous affecte. Cela vous dérange-t-il simplement, ou votre vie serait-elle meilleure si vos collègues administrateurs écrivaient des choses?

J'avais en fait une autre pensée. En ce qui concerne le fait que les administrateurs Windows juniors sont habitués aux interactions GUI, il serait peut-être utile de les démarrer avec une interaction GUI de script, avec quelque chose comme AutoIt . Cela leur permettrait de mettre la main à la pâte en ce qui concerne les scripts tout en leur permettant d'utiliser les outils qu'ils connaissent déjà, au lieu de jeter leurs outils existants et de leur faire apprendre de nouveaux outils et scripts en même temps.

Ensuite, une fois qu'ils se familiarisent avec l'idée de script en général, ils peuvent passer à un script non GUI. Même si ce n'est pas le cas, cependant, l'automatisation des clics sur les boutons peut encore potentiellement vous faire gagner beaucoup de temps.

J'ai défini les scripts comme «une documentation qui fait le travail pour vous».

Manager: allez passer d'innombrables heures à créer de la documentation, qu'un premier correcteur peut comprendre, qui sera périmée d'ici la fin de la semaine, pour que vos collègues cliquent de près via Task-X.

Employé: J'ai un script qui fait Task-X, pourrais-je simplement leur donner cela.

Manager: Bien sûr, après avoir terminé la documentation que je viens de demander, documentez également votre script, avec un organigramme.

J'ai défini les scripts comme «une documentation qui fait le travail pour vous».

Manager: allez passer d'innombrables heures à créer de la documentation, qu'un premier correcteur peut comprendre, qui sera périmée d'ici la fin de la semaine, pour que vos collègues cliquent de près via Task-X.

Employé: J'ai un script qui fait Task-X, pourrais-je simplement leur donner cela.

Manager: Bien sûr, après avoir terminé la documentation que je viens de demander, documentez également votre script, avec un organigramme.

N'oubliez pas que la documentation doit être dans un document MS Word afin de compliquer la lecture à partir du serveur.