Когда я работал администратором на своей первой работе, я был разочарован тем, что наши процессы администрирования с серверами Windows представляли собой серию щелчков мышью; мы никогда не смогли бы сравниться по уровню эффективности с серверами Unix, у которых была группа сценариев оболочки для автоматизации большей части работы. Вскоре я прочитал о WSH и ADSI и, не теряя времени, узнал, какой степени автоматизации я смог добиться с помощью сценариев.
Однако была огромная проблема - почти никто из моих коллег по Windows не интересовался изучением сценариев. Они казались довольными рутинной работой, выполняемой вручную мышью, и никогда не были взволнованы перспективой использования скриптов для выполнения работы от их имени. Я изо всех сил пытался убедить их научиться писать сценарии, несмотря на очевидное повышение эффективности. После этого я оставил эту работу, чтобы заняться разработкой программного обеспечения на полную ставку.
Почти десять лет работы в различных средах и у разных клиентов, я все еще сталкиваюсь с администраторами Windows, в основном обладающими таким общим «настроением», когда они стараются избегать написания сценариев в максимально возможной степени. Несмотря на растущий уровень доступности, серверные технологии Windows открываются для сценариев и автоматизации. Я почти уверен, что большинство администраторов являются администраторами именно потому, что они абсолютно ненавидеть выполнение любых программных обязанностей. Какие средства поощрения и мотивации администраторов к написанию действительно может помочь им в долгосрочной перспективе?
Как администратор Unix и Windows, который много сценариев Unix и почти полное отсутствие сценариев Windows, я бы сказал, что это отчасти связано с невероятной неудобством утилит сценариев Windows и API-интерфейсов, а также с трудностью (может быть, неочевидность было бы лучше) запуска вещей удаленно на Машина Windows.
Я имею ввиду, что это за фигня?
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Я думаю, что отчасти проблема в том, что является API. В Unix администраторы в основном создают сценарии для автоматизации уже используемых утилит командной строки. Под Windows вы должны использовать этот API, который не знаком ни на одном уровне. Например, что означает «выдавать себя за другое лицо»? Это тривиальная концепция для администратора Unix, который, вероятно, будет использовать sudo и su и уже знаком со сценариями setuid. Но администратор Windows вряд ли будет знаком с этим; они могут знать о "runas" (или эквивалентном параметре графического интерфейса пользователя), но они с гораздо большей вероятностью войдут в систему как администратор, когда им нужно будет сделать что-то админское.
А документация по написанию сценариев в Windows убогая. Во-первых, это гораздо более «интерпретируемый язык», чем сценарий, опять же потому, что они используют (незнакомый) API, а не команды, с которыми они уже знакомы. Но я не думаю, что когда-либо нашел что-то полезное в документации Microsoft, к чему не привело бы поиск кого-то, кто уже делал что-то близкое к тому, что я хотел, что указывало мне в правильном направлении. Кажется, нигде нет списка того, что вы можете сделать. Как будто вы уже должны быть знакомы с внутренним устройством Windows, чтобы делать самые простые вещи.
Не то чтобы скрипты Unix не часто выглядели как линейный шум. Но администратор Unix может начать со сценария, который ничего не делает, кроме выполнения простых команд, которые он уже знает. («Мне всегда приходится запускать эти три команды подряд. Если я просто помещу их в файл вместе, я смогу сделать это в одной команде!») И затем он может позже продвигаться по мере того, как он привыкает к ситуации. Напротив, у администратора нет возможности выполнить сценарий «войти на сервер как администратор; нажмите Пуск → Настройка → Панель управления; дважды щелкните Система; щелкните вкладку Имя компьютера и т. Д.» Да, все, к чему он пытался добраться, вероятно, где-то представлено через API, но у него нет способа найти это постепенно.
Итак, чтобы ответить на вопрос «как мы можем заставить администраторов Windows делать больше сценариев?», Ответ таков: сделать сценарии менее чуждыми. Как это сделать, я не знаю.
Честно говоря, ответ в руках Microsoft. Нет причин, по которым у них не может быть утилиты командной строки, чтобы делать все, что делается через графический интерфейс. (На самом деле их сейчас много, но они не рекламируются, они плохо документированы и непоследовательны.) Также нет причин, по которым в графическом интерфейсе не могло быть какого-то намека на то, что эта кнопка действительно работает. Создайте всплывающую подсказку, показывающую изменяемый объект API. Или задокументируйте это в окне справки.
Нет проблем с защитой пользователей от внутренних компонентов, но Windows, похоже, изо всех сил старается скрыть эти внутренние компоненты даже от тех, кто хочет их найти.
Дайте им задачу, которая действительно может быть выполнена только с помощью сценария - например, однажды мне пришлось создать сценарий для создания сотен папок и настраиваемых разрешений для каждой папки, и ее нужно было обновлять ЕЖЕДНЕВНО. Если бы они делали это вручную, это была бы их единственная работа. Сценарий, который, помимо прочего, использовал CACLS для сброса разрешений на основе вывода текстового файла с разделителями, на доведение до совершенства потребовалось около суток (базовый сценарий был выполнен примерно за час).
Когда вы начинаете понимать, что можно делать со сценариями, это может быть огромной победой.
Однажды я нанял системного администратора, который наотрез отказался заниматься каким-либо «программированием». Я попытался показать ему, как подавать пример. Лучшее, что я мог от него получить, - это использовать существующий код и изменять присвоение переменных или имена хостов и т. Д. чтобы выполнить работу. Некоторых людей просто не волнует программирование, поэтому вам нужно снизить для них барьер.
Microsoft делает вклад в это. В SQL Server некоторое время можно было щелкнуть что-либо в графическом интерфейсе Management Studio, а затем выгрузить t-sql-сценарий того, что вы только что сделали. Это здорово, особенно для не очень программистского системного администратора Windows.
Я заметил, что диспетчер виртуальных машин System Center имеет ту же функцию сценария просмотра, за исключением того, что он выгружает сценарий PowerShell. Я думаю, что многие другие линейки продуктов также представляют это.
Как мотивировать админов писать скрипты? трудная задача, хороший админ - это ленивый админ, а это значит, что админ будет писать столько скриптов, сколько возможно. Администратор, у которого есть время нажимать на что-то, не очень продуктивен! Перегрузите админов такой работой, что у них нет другого выбора, кроме как писать скрипты.
Я полностью согласен с вашим постом. К сожалению, я не думаю, что многое можно сделать без поддержки со стороны руководства и процессов, которые принуждать с помощью скриптов. Если у людей есть выбор, они всегда будут выбирать то, что им знакомо и что легко. Иногда это может показаться отрицательным моментом, но бывают случаи, когда простота и знакомство - это плюс.
С одной стороны, система Windows неявно задумывалась как простая / легкая, в то время как системы Unix / Linux намного сложнее и менее снисходительны. Так кто же может винить админов в том, что они пошли по пути наименьшего сопротивления? Хотя вы, я или многие другие люди можете осознать силу сценариев, люди будут в конце концов узнать так или иначе. Обычно администраторы, которые не хотят писать сценарии, усердно учатся. Мне нравится работать умнее, другим может просто нравиться работать.
Каким образом можно поощрять и мотивировать администраторов на то, что сценарии действительно могут помочь им в долгосрочной перспективе?
Раньше я думал, что вы можете мотивировать людей, но на самом деле, если вы ответственный из них вероятность успешной «мотивации» крайне мала. Мое отношение сейчас такое: тем, кто хочет учиться, я помогу. Не продавайте продукт, который никому не нужен, независимо от того, нужен ли он им. Когда вы помогаете / учите просто один человек, который мотивирован (по какой-либо причине), они станут катализатором перемен. Не вы. Всего два цента.
Моя мантра - «Работай умнее, а не усерднее». Выполнение какого-либо процесса более нескольких раз означает, что обычно есть способ создать сценарий, чтобы он выполнялся автоматически с помощью щелчка мыши, сценария bash или другого метода. На мой взгляд, это лично освобождает меня для выполнения более важных задач, которые не являются «ручным трудом» системного администрирования.
У тех, кто хочет избежать написания сценариев, может возникнуть несколько проблем. Возможно, им нравится графический интерфейс, и они не хотят изучать командную строку или программирование. Может быть, они думают, что, создавая какие-то сценарии, они в основном снижают собственную важность. В любом случае, это не тот сотрудник, которого я хотел бы иметь, и нежелание выполнять какие-либо сценарии показывает, что это за работник. Я предпочел бы иметь решателя проблем, а не "тупого" системного администратора.
Что касается поощрения и мотивации их, я бы сказал, просто делать то же, что и вы, показывать рост производительности и то, как это может облегчить их работу. Для некоторых быть системным администратором Windows - это просто зарплата, и будет сложно мотивировать их выйти за рамки менталитета «укажи и щелкни», который работал у них последние 10 лет.
Есть пара проблем, которые вам нужно преодолеть, вы упомянули одну, что многие администраторы не хотят участвовать в программировании, даже на таком низком уровне, как создание сценариев. Другой связан с этим, и это вопрос контроля. Когда администратор выполняет задачу вручную, он точно знает, что происходит на каждом этапе. Многие администраторы могут почувствовать, что, заменяя это сценарием, они теряют контроль над процессом, особенно если они не понимают сценариев и не писали сценарий (и не хотели его писать).
Я думаю, что это больше проблема администраторов Windows, чем администраторов Unix, поскольку сценарии долгое время были важной частью администрирования Unix и, как правило, это то, что администраторы Unix учатся с самого начала, тогда как администрирование Windows и присущий ему графический интерфейс - Это приводит к тому, что процесс выполняется вручную, и создание сценариев может показаться неестественным.
К сожалению, вывести разработчиков из этой горки - тяжелая битва. Чтобы администратор по-прежнему чувствовал, что у него все под контролем, он должен понимать, что делает сценарий, и поэтому действительно нужно понимать и изучать, как писать сценарий, и единственный способ заставить их это сделать - это если они действительно понимают, что скрипты могут с ними сделать
Все хорошо, что это ускорит работу, упростит жизнь и т. Д., Но можете ли вы им это доказать? Найдите задачу, которую они ненавидят, которую они должны выполнять регулярно, и попытайтесь ее автоматизировать. Если вы сможете взять эту ужасную задачу и сделать ее скриптом в один клик, они полюбят вас, но, что более важно, они могут увидеть преимущества использования скриптов.
[вздох] Это слишком распространено в мире Windows, хотя я бы поставил под сомнение ваше заявление о том, что большинство не хочет смиряться и учиться писать скрипты. Самым лучшим, что я когда-либо делал в своей карьере системного администратора, было изучение VB и Perl, что привело к VBS, который привел к МНОГИМ другим вещам.
Если просто демонстрация их не работает для мотивации, я предпочитаю использовать один трюк: бросать тонкие заявления руководству :) Назовите это подлизыванием, если хотите, но это не так. Покажите лицам, принимающим решения, преимущества, часто они начинают распространяться в группе. Но не будь придурком.
На более тонкой ноте, трудно (если не невозможно) кого-то изменить. Подавать пример!
Это очень субъективный вопрос. Хотя я согласен с эффективностью и повышенным контролем, которые предоставляют сценарии, почему это должно быть обязательным? Почему вам нужно побуждать людей использовать сценарии только потому, что вам это нравится? Почему бы не позволить людям использовать те инструменты, которые им нравятся и которые они предпочитают?
Этот вопрос также иллюстрирует распространенное предубеждение, существующее в мире ИТ: если я не пишу сценарий, я не должен быть таким же умным или хорошим, как тот, кто пишет сценарий, и это неправильно. Я знал множество людей, которые могли писать сценарии лучше меня, но они не могли подсеть, чтобы спасти свою жизнь, или выяснить, как запустить сетевую трассировку, или настроить SQL-сервер для использования AWE, или не знали, что загружается. ini для и т. д. и т. д.
Честно говоря, к воде можно привести лошадь, но нельзя заставить ее пить.
Я пришел в качестве системного администратора в корпус морской пехоты около 10 лет назад, где есть большой разрыв между админом и кодером. Быть кодером обычно означает, что вы застряли, имея дело с веб-сайтом любимого проекта CO (мало что выполняете из своей реальной работы ...).
Из-за этого я сопротивлялся обучению программированию, но как только я решил попробовать это, у меня был взрыв.
Что касается привлечения кого-то, попробуйте использовать сценарии AD / LDAP, чтобы заманить их. (Я думаю, что это немного более доступно, чем иметь дело с WMI.) Назначьте последовательность задач, скажем, «дайте мне имена пользователей и адреса электронной почты люди в группе XYZ ».
Я написал этот фрагмент кода, чтобы найти всех пользователей, которые не были членами ни одной из указанных групп: https://github.com/gwaldo/LDAP-Inverse-Group-Membership-Report
Что касается ресурсов, обратите внимание на Microsoft Scripting Guys (у которых есть отличные статьи и руководства) и Scriptomatic2, которые мне нравятся за то, что они копаются в WMI.
Следующий вопрос: зачем им скрипт? Это определит ответ.
Предположительно, вы пишете сценарий, потому что он более эффективен. В этом случае вы можете либо показать всем остальным, либо указать руководству, что есть более эффективные способы администрирования систем, и подождать, пока они воспользуются этим преимуществом для сокращения затрат.
Кто-то с полномочиями может поручить создание сценариев, потребовав наличия сценариев для обработки большинства вещей. Насколько хорошо это будет работать, зависит от нескольких вещей; если просто так заявить, сценарии, скорее всего, останутся ужасно неадекватными и устаревшими, в то время как администраторы будут работать в обычном режиме.
Также возникает вопрос, как именно это влияет на вас. Вас это просто беспокоит, или ваша жизнь была бы лучше, если бы ваши коллеги-администраторы писали сценарии?
На самом деле у меня была другая мысль. Что касается того факта, что младшие администраторы Windows привыкли к взаимодействиям с графическим интерфейсом пользователя, возможно, было бы полезно, если бы вы начали их со сценария взаимодействия с графическим интерфейсом, например, AutoIt. Это позволит им вмешаться в создание сценариев, в то же время позволяя им использовать инструменты, которые они уже знают, вместо того, чтобы отказываться от существующих инструментов и одновременно заставлять их изучать новые инструменты и сценарии.
Затем, когда они освоятся с идеей создания сценариев в целом, они могут перейти к написанию сценариев без графического интерфейса. Тем не менее, даже если нет, автоматизация нажатий кнопок потенциально может значительно сэкономить время.
Я определил сценарии как «Документация, которая делает всю работу за вас».
Менеджер: потратьте бесчисленное количество часов на создание документации, которую сможет понять первоклассник, которая устареет к концу недели, чтобы ваши коллеги могли щелкнуть мышью по Task-X.
Сотрудник: У меня есть сценарий, который выполняет Task-X, могу я просто дать им это.
Менеджер: Конечно, после того, как вы закончите документацию, которую я только что просил, также задокументируйте свой сценарий с блок-схемой.
Я определил сценарии как «Документация, которая делает всю работу за вас».
Менеджер: потратьте бесчисленное количество часов на создание документации, которую сможет понять первоклассник, которая устареет к концу недели, чтобы ваши коллеги могли щелкнуть мышью по Task-X.
Сотрудник: У меня есть сценарий, который выполняет Task-X, могу я просто дать им это.
Менеджер: Конечно, после того, как вы закончите документацию, которую я только что просил, также задокументируйте свой сценарий с блок-схемой.
Не забывайте, что документация должна быть в виде документа MS Word, чтобы затруднить чтение с сервера.