Como incentivar os administradores do Windows a escolher scripts? [fechadas]

Quando trabalhei como administrador no meu primeiro emprego, fiquei frustrado porque nossos processos de administração com servidores Windows eram uma série de apontamentos e cliques; nunca poderíamos igualar o nível de eficiência com os servidores Unix, que tinham um grupo de scripts de shell para automatizar grande parte do trabalho. Logo li sobre o WSH e o ADSI e não perdi tempo aprendendo o quanto de automação eu era capaz de obter com scripts.

Houve um problema enorme - quase nenhum dos meus colegas do Windows estava realmente interessado em aprender scripts. Eles pareciam felizes com as tarefas de clicar com o mouse manualmente e nunca estavam animados com a perspectiva de usar scripts para fazer o trabalho em seu nome. Lutei para convencê-los a adquirir habilidades de script, apesar dos evidentes aumentos de eficiência. Deixei esse emprego em busca de uma carreira de desenvolvimento de software em período integral a partir de então.

Quase uma década trabalhando em vários ambientes e clientes diferentes, ainda encontro administradores do Windows possuindo principalmente esse "clima" geral em que evitavam scripts o máximo possível. Apesar do crescente nível de acessibilidade, as tecnologias do servidor Windows estão se abrindo para scripts e automação. Estou quase certo de que a maioria dos administradores são administradores exatamente porque eles absolutamente odeiam executar qualquer tipo de tarefas de programação. Quais são alguns meios para incentivar e motivar os administradores que os scripts podem realmente ajudá-los a longo prazo?

Como administrador do Unix e do Windows que executa muitos scripts do Unix e quase nenhum script do Windows, eu diria que isso se deve em parte ao incrível constrangimento dos utilitários e APIs de script do Windows e à dificuldade (talvez não-óbvio seria uma palavra melhor) de executar as coisas remotamente em uma máquina Windows.

Quero dizer, WTF é isso?

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

Parte do problema, penso eu, é que não é uma API. No Unix, os administradores estão criando scripts para a automação dos utilitários de linha de comando que eles já usam. No Windows, você precisa usar essa API que não é familiar em todos os níveis. Por exemplo, o que significa "personificar"? Este é um conceito trivial para um administrador do Unix, que provavelmente usa sudo e su e já conhece os scripts setuid. Mas é improvável que um administrador do Windows esteja familiarizado com isso; eles podem saber sobre "runas" (ou a opção equivalente da GUI), mas são muito mais propensos a efetuar login como administrador quando precisarem fazer algo administrativo.

E a documentação sobre scripts no Windows é péssima. Por um lado, é muito mais "linguagem interpretada" do que script, novamente porque eles estão usando uma API (desconhecida) e não comandos com os quais eles já estão familiarizados. Mas acho que nunca encontrei algo útil na documentação da Microsoft que não foi levado ao encontrar alguém que já estava fazendo algo próximo ao que eu queria que me apontava na direção certa. Em nenhum lugar parece haver uma lista de coisas que você pode fazer. É como se você já estivesse familiarizado com os componentes internos do Windows para fazer as coisas mais básicas.

Não que os scripts Unix nem sempre pareçam ruído de linha. Mas um administrador do Unix pode começar com um script que não faz nada além de executar comandos simples que ele já conhece. ("Eu sempre tenho que executar esses três comandos em sucessão. Se eu os juntar em um arquivo, posso fazê-lo em um comando!") E, em seguida, ele poderá progredir mais tarde à medida que se sentir confortável com a situação. Por outro lado, não há como um administrador criar um script "faça login no servidor como administrador; clique em Iniciar → Configurações → Painel de Controle; clique duas vezes em Sistema; clique na guia Nome do Computador, etc." Sim, o que quer que ele estivesse tentando acessar provavelmente é apresentado por meio de uma API em algum lugar, mas não há como ele encontrá-lo gradualmente.

Portanto, para responder à pergunta "como podemos fazer com que os administradores do Windows executem mais scripts?", A resposta é tornar os scripts menos estranhos. Como fazer isso, eu não sei.

Honestamente, a resposta está nas mãos da Microsoft. Não há razão para que eles não possam ter um utilitário de linha de comando para fazer tudo o que é feito via GUI. (Na verdade, existem muitos deles por aí agora, mas não são anunciados, estão mal documentados e são inconsistentes.) Também não há razão para que não haja alguma dica na GUI sobre o que esse botão realmente faz. Tenha uma dica de ferramenta que mostra o objeto da API que está sendo modificado. Ou documente-o na janela Ajuda.

Não há problema em proteger os usuários dos internos, mas o Windows parece se esforçar para ocultar ativamente esses internos, mesmo daqueles que querem encontrá-los.

Dê a eles uma tarefa que realmente só pode ser realizada por meio de um script - por exemplo, uma vez tive que criar um script para criar centenas de pastas e permissões personalizadas para cada pasta e precisávamos atualizá-las DIARIAMENTE. Se eles fizessem isso manualmente, esse seria o único trabalho deles. O script, que usava o CACLS entre outras coisas para redefinir as permissões com base na saída de um arquivo de texto delimitado, demorou cerca de um dia para ser aperfeiçoado (o script básico foi feito em cerca de uma hora).

Quando você começa a ver o que pode fazer com scripts, pode ser uma grande vitória.

Certa vez, contratei um administrador de sistemas que se recusou a fazer qualquer 'programação' que tentei mostrar a ele como liderar pelo exemplo. O melhor que pude tirar dele foi usar o código existente e modificar a atribuição de variáveis ​​ou os nomes de host, etc. para fazer um trabalho. Algumas pessoas simplesmente não se incomodam com a programação, então você precisa diminuir a barreira para elas.

A Microsoft está entrando nisso. No SQL Server, já faz um tempo que você clica em itens na GUI do Management Studio e despeja um script t-sql do que você acabou de fazer. Isso é ótimo, especialmente para o administrador de sistemas do Windows, que não é tão inclinado à programação.

Percebi que o System Center Virtual Machine Manager possui o mesmo recurso de script de exibição, exceto que despeja um script do PowerShell. Eu acho que muitas outras linhas de produtos também estão introduzindo isso.

Como motivar os administradores para scripts? uma decisão difícil, um bom administrador é um administrador preguiçoso e isso significa um administrador que fará o script o máximo possível. Um administrador que tem tempo para clicar nas coisas não é muito produtivo! Sobrecarregar seus administradores com tanto trabalho, que eles não têm escolha a não ser criar scripts.

Concordo plenamente com o seu post. Infelizmente, acho que não há muito que possa ser feito sem o suporte do gerenciamento e dos processos que impõem o uso de scripts. Com uma escolha, as pessoas sempre seguem o que é familiar e o que é fácil. Às vezes, isso pode parecer um ponto negativo, mas há momentos em que simplicidade e familiaridade são uma vantagem.

Por um lado, o sistema Windows é implicitamente destinado a ser simples / fácil, enquanto os sistemas Unix / Linux são muito mais difíceis e menos tolerantes. Então, quem pode culpar os administradores por seguirem o caminho de menor resistência? Enquanto você, eu ou várias outras pessoas reconhecemos o poder dos scripts, as pessoas acabarão aprendendo de uma maneira ou de outra. Normalmente, os administradores que aprendem sobre scripts aprendem da maneira mais difícil. Eu gosto de trabalhar de forma mais inteligente, outros podem gostar de trabalhar.

Quais são alguns meios para incentivar e motivar os administradores que os scripts podem realmente ajudá-los a longo prazo?

Eu costumava pensar que você poderia motivar as pessoas, mas a realidade é que, a menos que você esteja encarregado delas, a probabilidade de uma "motivação" bem-sucedida é extremamente baixa. Minha atitude hoje em dia é: quem quiser aprender, eu ajudarei. Não seja um vendedor de um produto que ninguém deseja, independentemente de precisar. Quando você ajuda / ensina apenas uma pessoa motivada (por qualquer motivo), elas serão o catalisador da mudança. Você não. Apenas meus dois centavos.

Um mantra que uso é "trabalhe de maneira mais inteligente, não mais difícil". Realizar qualquer processo mais do que algumas vezes significa que geralmente existe uma maneira de executá-lo automaticamente, com um clique do mouse, um script do bash ou outro método. Do meu ponto de vista, isso pessoalmente me libera para executar tarefas mais importantes que não são tanto o "trabalho manual" da administração do sistema.

Aqueles que desejam evitar scripts podem ter várias coisas passando pela cabeça. Talvez eles gostem da interface GUI e não queiram aprender linha de comando ou programação. Talvez eles pensem que, ao escrever algo, eles estão basicamente reduzindo sua própria importância. De qualquer forma, esse não é o tipo de funcionário que eu gostaria de ter e a relutância em fazer qualquer tipo de script mostra que tipo de funcionário eles são. Prefiro ter um solucionador de problemas do que um administrador de sistema "burro".

Quanto a encorajá-los e motivá-los, eu diria apenas para fazer o que você estava fazendo, mostrar os ganhos de produtividade e como isso pode facilitar o trabalho deles. Para alguns, ser um administrador do sistema Windows é apenas um salário e será difícil motivá-los a ir além da mentalidade de apontar e clicar que funcionou para eles nos últimos 10 anos.

Você mencionou alguns problemas a serem superados, que você mencionou, que muitos administradores não desejam envolver-se em programação, mesmo em nível tão baixo quanto os scripts. O outro está relacionado a isso, e isso é uma questão de controle. Quando um administrador está executando uma tarefa manualmente, ele sabe exatamente o que está acontecendo em cada estágio. Muitos administradores podem achar que, ao substituí-lo por um script, estão perdendo o controle sobre o processo, principalmente se não entenderem scripts e não escreverem o script (e não quiserem escrevê-lo).

Eu acho que isso é mais um problema para os administradores do Windows do que para o Unix, pois os scripts são uma grande parte da administração do Unix há muito tempo e geralmente é algo que os administradores do Unix aprendem desde o início, onde a administração do Windows e sua GUI inerente O processo leva a um processo mais manual e os scripts podem parecer não naturais.

Infelizmente, levar os desenvolvedores a esse nível é uma batalha difícil. Para que o administrador ainda sinta que está no controle, ele precisa entender o que o script está fazendo, e realmente precisa entender e aprender a script, e a única maneira de convencê-lo a fazer isso é se ele realmente entender o que o script pode fazer com eles

Está tudo muito bem dizendo que isso tornará as coisas mais rápidas, facilitará a vida etc., mas você pode provar isso a elas? Encontre uma tarefa que eles odeiam, que eles devem executar regularmente e tente automatizá-la. Se você puder executar essa tarefa horrível e transformá-la em um script de clique único, eles o amarão, mas o mais importante é que poderão ver o benefício do uso de scripts.

[suspiro] Isso é muito prevalente no mundo do Windows, embora eu questionasse sua afirmação sobre a maioria não querer pagar e aprender a escrever. A melhor coisa que já fiz na minha carreira de administrador de sistemas foi aprender VB e Perl, o que levou ao VBS, o que levou muitas outras coisas.

Se apenas mostrá-los não funciona para motivar, um truque que eu gosto de usar é lançar declarações sutis na frente da gerência :) Chame de sucção, se quiser, mas não é. Mostre aos tomadores de decisão os benefícios, geralmente ele começa a proliferar através do grupo. Não seja um idiota sobre isso, no entanto.

Em uma nota mais sutil, é difícil (se não impossível) mudar alguém. Lidere pelo exemplo!

Esta questão é altamente subjetiva. Embora eu concorde com a eficiência e o maior controle que o script oferece, por que ele precisa ser um mandato? Por que você precisa incentivar as pessoas a usar scripts apenas porque você gosta de usá-los? Por que não deixar as pessoas optarem por usar as ferramentas de que gostam e preferem?

Essa pergunta também ilustra um viés comum que existe no mundo da TI: que, se eu não escrevo, não devo ser tão inteligente ou tão bom quanto alguém que escreve, e isso é errado. Conheci muitas pessoas que poderiam fazer scripts melhor do que eu, mas elas não conseguiam criar sub-redes para salvar suas vidas ou descobrir como executar um rastreamento de rede ou configurar o SQL Server para usar o AWE, ou não sabiam qual inicialização. arquivo ini era para etc., etc.

Honestamente, você pode levar um cavalo à água, mas não pode fazê-lo beber.

Eu vim como um SysAd no Corpo de Fuzileiros Navais cerca de 10 anos atrás, onde há uma grande diferença entre ser um administrador e ser um codificador. Ser um Coder geralmente significa que você fica preso ao lidar com o site de projetos de animais de estimação do CO (fazendo pouco do seu trabalho real ...).

Por isso, resisti a aprender a codificar, mas depois que decidi experimentar, tive uma explosão.

Quanto a atrair alguém, tente usar o script AD / LDAP para atraí-lo. (Eu acho que é um pouco mais acessível do que lidar com o WMI.) Atribua uma progressão de tarefas, diga "me dê os nomes de usuário e endereços de email do pessoas do grupo XYZ ".

Escrevi este código para encontrar todos os usuários que não eram membros de nenhum dos grupos especificados: https://github.com/gwaldo/LDAP-Inverse-Group-Membership-Report

Quanto aos recursos, consulte o Microsoft Scripting Guys (que possui excelentes artigos e tutoriais) e o Scriptomatic2, que eu adoro pesquisar no WMI.

A próxima pergunta: por que eles deveriam roteirizar? Isso determinará a resposta.

Presumivelmente, você escreve porque é mais eficiente. Nesse caso, você pode mostrar a todos os outros ou indicar à gerência que existem maneiras mais eficientes de administrar os sistemas e esperar que eles tirem vantagem disso em uma medida de corte de custos.

Alguém com autoridade pode exigir scripts, exigindo a existência de scripts para lidar com a maioria das coisas. O quão bem isso funcionará depende de várias coisas; se apenas declarado assim, é provável que os scripts permaneçam lamentavelmente inadequados e obsoletos, enquanto os administradores funcionam normalmente.

Há também a questão de exatamente como isso está afetando você. Isso o incomoda ou sua vida seria melhor se seus colegas administradores escrevessem coisas?

Na verdade, tive outro pensamento. Em relação ao fato de os administradores juniores do Windows estarem acostumados às interações da GUI, talvez ajude se você os iniciou com a interação da GUI de script, com algo como AutoIt . Isso permitiria que eles entrassem na porta em relação ao script e, ao mesmo tempo, usassem as ferramentas que eles já conhecem, em vez de jogar fora as ferramentas existentes e fazê-las aprender novas ferramentas e scripts ao mesmo tempo.

Em seguida, quando eles se acostumarem com a idéia de criar scripts em geral, poderão passar para scripts que não sejam da GUI. Mesmo se não estiver, a automação de cliques em botões ainda pode economizar muito tempo.

Eu defini scripts como "Documentação que faz o trabalho para você".

Gerente: Vá passar inúmeras horas criando documentação, que um aluno da primeira série pode entender, que ficará obsoleta até o final da semana, para que seus colegas de trabalho cliquem com o botão direito do mouse na Tarefa-X.

Funcionário: Eu tenho um script que executa a Tarefa-X, eu poderia apenas dar isso a eles.

Gerente: Claro, depois de terminar a documentação que acabei de solicitar, documente seu script também, com um fluxograma.

Eu defini scripts como "Documentação que faz o trabalho para você".

Gerente: Vá passar inúmeras horas criando documentação, que um aluno da primeira série pode entender, que ficará obsoleta até o final da semana, para que seus colegas de trabalho cliquem com o botão direito do mouse na Tarefa-X.

Funcionário: Eu tenho um script que executa a Tarefa-X, eu poderia apenas dar isso a eles.

Gerente: Claro, depois de terminar a documentação que acabei de solicitar, documente seu script também, com um fluxograma.

Não esqueça que a documentação deve estar em um documento do MS Word para facilitar a leitura do servidor.