Как побудить администраторов Windows подобрать сценарии? [закрыто]

Когда я работал администратором на своей первой работе, я был разочарован тем, что наши процессы администрирования с серверами Windows были серией «укажи и щелкни»; мы никогда не могли сравниться с уровнем эффективности с серверами Unix, которые имели группу сценариев оболочки для автоматизации большей части работы. Вскоре я прочитал о WSH и ADSI и не стал тратить время на изучение того, насколько мне удалось достичь автоматизации с помощью сценариев.

Однако возникла огромная проблема - почти никто из моих коллег по Windows не был действительно заинтересован в изучении сценариев. Они, казалось, были довольны работой по щелчку мыши вручную и никогда не были взволнованы перспективой использования сценариев для выполнения работы от их имени. Я изо всех сил пытался убедить их приобрести навыки написания сценариев, несмотря на очевидное повышение эффективности. После этого я оставил эту работу в поисках полной карьеры разработчика программного обеспечения.

Почти десять лет работая в различных средах и с разными клиентами, я все еще сталкиваюсь с администраторами Windows, которые в основном обладают этим общим «настроением», когда они максимально избегают сценариев. Несмотря на повышение уровня доступности, серверные технологии Windows открываются для сценариев и автоматизации. Я почти уверен, что большинство администраторов являются администраторами именно потому, что они совершенно не любят выполнять какие-либо обязанности по программированию. Какие есть средства для поощрения и мотивации администраторов к тому, что сценарии действительно могут помочь им в долгосрочной перспективе?

Как администратор Unix и Windows, который выполняет множество сценариев Unix и почти не использует сценарии Windows, я бы сказал, что это отчасти связано с невероятной неловкостью утилит и API-интерфейсов сценариев Windows и трудностями (возможно, неочевидность лучше сказать) удаленного запуска на Windows-машине.

Я имею в виду, WTF это?

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

Часть проблемы, я думаю, что это АНИ. Под Unix администраторы в основном пишут сценарии для автоматизации утилит командной строки, которые они уже используют. Под Windows вы должны использовать этот API, который незнаком на каждом уровне. Например, что значит «подражать»? Это тривиальная концепция для администратора Unix, который, скорее всего, использует sudo и su и уже знаком со скриптами setuid. Но администратор Windows вряд ли знаком с этим; они могут знать о «runas» (или эквивалентной опции графического интерфейса), но они с гораздо большей вероятностью будут входить в систему как администратор, когда им нужно что-то сделать admin-y.

И документация по скриптингу в Windows убогая. Во-первых, это гораздо более «интерпретируемый язык», чем сценарий, опять же, потому что они используют (незнакомый) API, а не команды, с которыми они уже знакомы. Но я не думаю, что я когда-либо нашел что-то полезное в документации Microsoft, к чему не привел поиск кого-то, кто уже делал что-то близкое к тому, что я хотел, и указывал мне правильное направление. Кажется, нигде нет списка вещей, которые вы можете сделать. Как будто вы уже должны быть знакомы с внутренними компонентами Windows, чтобы делать самые простые вещи.

Не то, чтобы Unix-скрипты не часто выглядели как шум строки. Но администратор Unix может начать со скрипта, который ничего не делает, кроме запуска простых команд, которые он уже знает. («Мне всегда нужно запускать эти три команды подряд. Если я просто соберу их в файл, я смогу сделать это одной командой!») И затем он сможет прогрессировать, когда ему станет комфортно в этой ситуации. В отличие от этого, администратор не может написать скрипт «войдите на сервер как администратор; нажмите« Пуск »→« Настройка »→« Панель управления »; дважды щелкните« Система »; щелкните вкладку« Имя компьютера »и т. Д.» Да, все, к чему он пытался добраться, вероятно, где-то представлено через API, но у него нет возможности постепенно найти это.

Итак, чтобы ответить на вопрос «как мы можем заставить администраторов Windows делать больше сценариев?», Ответ заключается в том, чтобы сделать сценарии менее чуждыми. Как это сделать, я не знаю.

Честно говоря, ответ в руках Microsoft. Нет никаких причин, по которым у них не может быть утилиты командной строки, которая делает все, что делается через графический интерфейс. (На самом деле их сейчас много, но они не рекламируются, плохо документированы и противоречивы.) Нет также причины, по которой в графическом интерфейсе не может быть никаких намеков на то, что эта кнопка на самом деле делает. Имейте подсказку, которая показывает объект API, который изменяется Или документируйте это в окне справки.

Нет проблем в защите пользователей от внутренних устройств, но Windows, кажется, старается изо всех сил активно скрывать эти внутренние устройства, даже от тех, кто хочет их найти.

Дайте им задачу, которая действительно может быть выполнена только с помощью сценария - например, мне когда-то приходилось создавать сценарии для создания сотен папок и пользовательских разрешений для каждой папки, и она должна была обновляться ЕЖЕДНЕВНО. Если бы они делали это вручную, это была бы их единственная работа. Сценарий, который, среди прочего, использовал CACLS для сброса разрешений на основе выходных данных текстового файла с разделителями, совершенствовался примерно за день (основной сценарий был выполнен примерно за час).

Когда вы начинаете видеть, что вы можете сделать с помощью сценариев, это может быть огромной победой.

Однажды я нанял системного администратора, который категорически отказывался заниматься «программированием», и я пытался показать ему, как привести пример. Лучшее, что я мог получить от него, - это использовать существующий код и изменить присвоение переменных или имена хостов и т. Д. чтобы сделать работу. Некоторые люди просто не занимаются программированием, поэтому вам нужно снизить барьер для них.

Microsoft делает на этом пути. В SQL Server уже некоторое время можно нажимать на элементы в графическом интерфейсе Management Studio и затем выводить сценарий t-sql того, что вы только что сделали. Это замечательно, особенно для не очень программируемых наклонных оконного системного администратора.

Я заметил, что System Center Virtual Machine Manager имеет ту же функцию сценария представления, за исключением того, что он выводит сценарий powershell. Я думаю, что многие другие производственные линии также представляют это.

Как мотивировать администраторов в сценарии? Сложный вызов, хороший администратор - это ленивый администратор, а это означает администратора, который будет писать скрипты как можно больше. Администратор, у которого есть время нажимать на вещи, не очень продуктивен! Перегрузите своих администраторов так много работы, что у них нет выбора, кроме как для сценариев.

Я искренне согласен с вашим постом. К сожалению, я не думаю, что можно многое сделать без поддержки со стороны руководства и процессов, которые применяют сценарии. При наличии выбора люди всегда будут идти с тем, что знакомо, а с чем легко. Временами это может показаться негативным моментом, но бывают моменты, когда простота и знакомство - это плюс.

С одной стороны, система Windows подразумевается простой / легкой, в то время как системы Unix / Linux намного сложнее и менее прощаемы. Так кто же может обвинить администраторов в том, что они пошли по пути наименьшего сопротивления? В то время как вы, я или многие другие люди можете распознать силу написания сценариев, люди, в конце концов, научатся так или иначе. Как правило, администраторы, которые воздерживаются от написания сценариев, учатся нелегко. Мне нравится работать умнее, другим просто нравится работать.

Какие есть средства для поощрения и мотивации администраторов к тому, что сценарии действительно могут помочь им в долгосрочной перспективе?

Раньше я думал, что вы можете мотивировать людей, но реальность такова, что если вы не отвечаете за них, вероятность успешной «мотивации» крайне мала. Мое отношение в эти дни таково: тем, кто хочет учиться, я помогу. Не будьте продавцом товара, который никто не хочет, независимо от того, нужен ли он ему. Когда вы помогаете / обучаете только одного человека, который мотивирован (по любой причине), они станут катализатором изменений. Не вы. Просто мои два цента.

Мантра, мимо которой я иду, - «Работай умнее, а не усерднее». Выполнение какого-либо процесса более чем несколько раз означает, что обычно можно написать сценарий, чтобы он выполнялся автоматически с помощью щелчка мыши, сценария bash или другого метода. На мой взгляд, это лично освобождает меня от выполнения более важных задач, которые являются не столько «ручным трудом» системного администрирования.

У тех, кто хочет избежать сценариев, может быть несколько вещей, проходящих через их голову. Возможно, им нравится интерфейс GUI и они не хотят изучать командную строку или программирование. Может быть, они думают, что, написав что-то, они в основном уменьшают свою собственную значимость. В любом случае, это не тот тип сотрудников, которого я хотел бы иметь, и нежелание делать какие-либо сценарии показывает, какой они тип работников. Я предпочел бы иметь решение проблем, а не "тупой" системный администратор.

Что касается их поощрения и мотивации, я бы сказал, просто делать то, что вы делали, показывать рост производительности и то, как это может облегчить их работу. Для некоторых быть системным администратором Windows - это просто зарплата, и им будет сложно заставить их выйти за рамки ментального подхода, который работал для них последние 10 лет.

Есть пара проблем, которые вы должны преодолеть, вы упомянули одну, что многие администраторы не хотят участвовать в программировании, даже на низком уровне, как сценарии. С этим связано другое, и это вопрос контроля. Когда администратор выполняет задачу вручную, он точно знает, что происходит на каждом этапе. Многие администраторы могут чувствовать, что, заменив это сценарием, они теряют контроль над процессом, особенно если они не понимают сценарии и не написали сценарий (и не хотели его писать).

Я думаю, что это скорее проблема для администраторов Windows, чем для Unix, так как сценарии долгое время являлись важной частью администрирования Unix и, как правило, это то, чему администраторы Unix учатся с самого начала, где они относятся к администрированию Windows и присущему ему GUI. Несс ведет к более ручному процессу, и сценарии могут показаться неестественными.

К сожалению, вытащить разработчиков из-за этого горба трудно. Чтобы администратор по-прежнему чувствовал, что контролирует ситуацию, ему необходимо понять, что делает сценарий, и поэтому ему действительно необходимо понять и научиться писать сценарии, и единственный способ заставить их сделать это, если они действительно понимаю, что сценарий может сделать с ними

Все очень хорошо говорят, что это сделает вещи быстрее, облегчит жизнь и т.д., но можете ли вы доказать это им? Найдите задачу, которую они ненавидят, которую они должны выполнять регулярно, и попробуйте автоматизировать ее. Если вы сможете выполнить эту ужасную задачу и сделать ее сценарием в один клик, они полюбят вас, но, что более важно, они могут увидеть преимущества использования сценариев.

[вздох] Это слишком распространено в мире Windows, хотя я бы усомнился в вашем утверждении о том, что большинство не желает копаться и учиться писать сценарии. Абсолютно величайшей вещью, которую я когда-либо делал в моей карьере сисадмина, было изучение VB и Perl, что привело к VBS, что привело к МНОГИМ другим вещам.

Если просто показывать их не помогает мотивировать, я бы хотел использовать один трюк, чтобы бросить тонкие утверждения перед руководством :) Называйте это сносным, если хотите, но это не так. Покажите лицам, принимающим решения, преимущества, часто это начинает распространяться через группу. Не будь придурком по этому поводу.

На более тонкой ноте трудно (если не невозможно) изменить кого-либо. Подавать пример!

Этот вопрос очень субъективен. Хотя я согласен с эффективностью и усилением контроля, который обеспечивают сценарии, почему он должен быть обязательным? Почему вы должны поощрять людей использовать сценарии только потому, что вам нравится их использовать? Почему бы не позволить людям выбрать те инструменты, которые им нравятся и которые они предпочитают?

Этот вопрос также иллюстрирует распространенную предвзятость, существующую в мире информационных технологий: если я не пишу сценарий, я не должен быть таким же умным или хорошим, как тот, кто пишет сценарий, и это неправильно. Я знал множество людей, которые могли писать лучше, чем я, но они не могли подсеть, чтобы спасти свои жизни или выяснить, как запустить трассировку сети, или настроить сервер SQL для использования AWE, или не знали, что такое загрузка. Ини файл был для и тд и тп

Честно говоря, вы можете привести лошадь к воде, но вы не можете заставить ее пить.

Я пришел в SysAd в Корпус морской пехоты около 10 лет назад, где существует большой разрыв между тем, чтобы быть администратором и кодером. Быть программистом обычно означает, что вы застряли, имея дело с веб-сайтом любимого проекта CO (получая мало от вашей реальной работы ...).

Из-за этого я сопротивлялся обучению кодированию, но как только я решил попробовать это, у меня был взрыв.

Что касается привлечения кого-то, попробуйте использовать сценарии AD / LDAP, чтобы заманить их. (Я думаю, что это немного более доступно, чем работа с WMI.) Назначьте последовательность задач, скажем «дайте мне имена пользователей и адреса электронной почты для люди в группе XYZ ".

Я написал этот фрагмент кода, чтобы найти всех пользователей, которые не были членами ни одной из указанных групп: https://github.com/gwaldo/LDAP-Inverse-Group-Membership-Report

Что касается ресурсов, посмотрите Microsoft Scripting Guys (у которых есть отличные статьи и учебные пособия) и Scriptomatic2, которые я люблю копать в WMI.

Следующий вопрос: зачем им сценарий? Это определит ответ.

Предположительно, вы пишете сценарий, потому что он более эффективен. В этом случае вы можете либо показать всем остальным, либо указать руководству, что существуют более эффективные способы администрирования систем, и подождите, пока они не воспользуются этим в плане сокращения расходов.

Кто-то, обладающий полномочиями, может назначать сценарии, требуя наличия сценариев для обработки большинства вещей. Насколько хорошо это будет работать, зависит от нескольких вещей; если просто так сказать, сценарии, скорее всего, останутся крайне неадекватными и устаревшими, в то время как администраторы работают как обычно.

Там также вопрос, как именно это влияет на вас. Вас это беспокоит, или ваша жизнь будет лучше, если ваши коллеги-администраторы будут писать сценарии?

У меня действительно была другая мысль. В связи с тем, что младшие администраторы Windows используются для взаимодействия с графическим интерфейсом, возможно, было бы полезно, если бы вы начали их с взаимодействия сценариев с пользовательским интерфейсом, с чем-то вроде AutoIt . Это позволило бы им войти в процесс написания сценариев, в то же время позволяя им использовать уже известные им инструменты вместо того, чтобы выбрасывать свои существующие инструменты и одновременно изучать новые инструменты и сценарии.

Затем, как только они освоятся с идеей сценариев в целом, они могут перейти к сценариям без использования графического интерфейса. Однако, даже если нет, автоматизация нажатий кнопок все же может значительно сэкономить время.

Я определил сценарии как «Документация, которая сделает всю работу за вас».

Менеджер: Потратьте бесчисленное количество часов на создание документации, которая будет понятна первокласснику, которая к концу недели будет устаревшей, чтобы ваши коллеги могли щелкнуть щелчком мыши по Задаче-X.

Сотрудник: У меня есть сценарий, который выполняет задачу-X, могу я просто дать им это.

Менеджер: Конечно, после того, как вы закончите документацию, которую я только что попросил, запишите свой сценарий, а также блок-схему.

Я определил сценарии как «Документация, которая сделает всю работу за вас».

Менеджер: Потратьте бесчисленное количество часов на создание документации, которая будет понятна первокласснику, которая к концу недели будет устаревшей, чтобы ваши коллеги могли щелкнуть щелчком мыши по Задаче-X.

Сотрудник: У меня есть сценарий, который выполняет задачу-X, могу я просто дать им это.

Менеджер: Конечно, после того, как вы закончите документацию, которую я только что попросил, запишите свой сценарий, а также блок-схему.

Не забывайте, что документация должна быть в виде документа MS Word, чтобы затруднить ее чтение с сервера.