Як заохотити адміністраторів 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 та вже буде знайомий із встановленими сценаріями. Але адміністратор Windows навряд чи знайомий ні з чим; вони можуть знати про "рунас" (або еквівалентний варіант GUI), але вони набагато частіше входять у систему як адміністратор, коли їм потрібно щось зробити адміністратором.

А документація щодо сценаріїв у Windows жалюгідна. По-перше, це набагато більше "інтерпретована мова", ніж сценарій, знову ж таки тому, що вони використовують (незнайомий) API, а не команди, з якими вони вже знайомі. Але я не думаю, що я ніколи не знаходив нічого корисного в документації Microsoft, до якого не вдалося знайти когось, хто вже робив щось близьке до того, що я хотів, що вказувало б мені в правильному напрямку. Ніде не існує списку речей, які ти можеш зробити. Це як ви вже повинні бути знайомі з внутрішніми системами Windows, щоб зробити найосновніші речі.

Мало того, що сценарії Unix часто не схожі на шум лінії. Але адміністратор Unix може почати зі скрипту, який не робить нічого, крім запущених простих команд, які він уже знає. ("Мені завжди доводиться запускати ці три команди послідовно. Якщо я просто покладу їх у файл разом, я можу це зробити за одну команду!") І тоді він може пізніше прогресувати, коли йому стає комфортно з ситуацією. На відміну від цього, адміністратору немає можливості зробити скрипт "увійти в сервер як адміністратор; натисніть кнопку Пуск → Налаштування → Панель управління; двічі клацніть Система; Клацніть на вкладці Ім'я комп'ютера; тощо." Так, все, до чого він намагався потрапити, можливо, десь представлений через API, але немає можливості поступово його знайти.

Отже, щоб відповісти на запитання "як можна змусити адміністраторів Windows зробити більше сценаріїв?", Відповідь - зробити сценарії менш чужими. Як це зробити, я не знаю.

Чесно кажучи, відповідь знаходиться в руках Microsoft. Немає причини, що вони не можуть мати утиліту командного рядка, щоб робити все, що робиться через GUI. (Зараз насправді їх багато, але їх не рекламують, вони погано задокументовані та непослідовні.) Також немає причин, щоб у графічному інтерфейсі не було натяку на те, що ця кнопка насправді є. Майте підказку, яка показує об'єкт API, який змінюється. Або документуйте це у вікні довідки.

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

Дайте їм завдання, яке справді може бути виконано лише за допомогою скрипту - наприклад, мені одного разу довелося сценарій створення сотень папок і спеціальних дозволів для кожної папки, і її потрібно було оновлювати щодня. Якби вони це робили вручну, це було б їх єдиною роботою. Сценарій, який використовував CACLS, серед іншого, для скидання дозволів на основі виводу обмеженого текстового файлу, для вдосконалення зайняв близько доби (основний сценарій був виконаний приблизно за годину).

Коли ви почнете бачити, що ви можете зробити зі сценарієм, це може бути величезним виграшем.

Одного разу я найняв системного адміністратора, який відмовився робити будь-яке «програмування», я намагався показати йому шлях у ведучому на прикладі. Найкраще, що я міг вийти з нього, - це використовувати існуючий код та змінювати призначення змінних або хост імена ect. щоб виконати роботу. Деяких людей просто не турбує програмування, тому вам потрібно знизити бар’єр для них.

Корпорація Майкрософт займається цим. У SQL Server вже деякий час можна натиснути на речі в GUI Management Studio і потім скинути сценарій t-sql того, що ви тільки що зробили. Це чудово, особливо для не настільки програмованого нахилу windows sysadmin.

Я помітив, що менеджер віртуальної машини System Center має таку саму функцію скрипту перегляду, за винятком того, що він викидає скрипт повноважень. Я думаю, що багато інших товарних ліній також представляють це.

Як мотивувати адміністраторів до сценаріїв? жорсткий виклик, хороший адміністратор - лінивий адміністратор, а це означає, що адміністратор, який буде максимально сценарізувати. Адміністратор, який має час натискати на речі, не дуже продуктивний! Перевантажте своїх адміністраторів такою кількістю роботи, що їм не залишається іншого вибору, крім сценарію.

Я від усієї думки погоджуюся з вашим дописом. На жаль, я не думаю, що багато чого можна зробити без підтримки управління та процесів, які застосовують сценарії. Надаючи вибір, люди завжди йтимуть із тим, що знайоме та що легко. Часом це може здатися негативним моментом, але бувають випадки, коли простота і знайомство є плюсом.

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

Якими способами заохочувати та мотивувати адміністраторів, що сценарії дійсно можуть допомогти їм у довгостроковій перспективі?

Раніше я думав, що ви можете мотивувати людей, але реальність полягає в тому, що якщо ви не керуєте ними, ймовірність успішної "мотивації" вкрай низька. Моє ставлення в ці дні: тим, хто хоче вчитися, я допоможу. Не будьте продавцем товару, якого ніхто не хоче, незалежно від того, чи потрібен він. Коли ви допоможете / навчите лише мотивацію однієї людини (з будь-якої причини), вони стануть каталізатором змін. Не ти. Всього два мої копійки.

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

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

Що стосується заохочення та мотивації їх, я б сказав, щоб просто робити так, як ви робили, показати підвищення продуктивності та як це може полегшити їх роботу. Для когось адміністратор Windows - це лише зарплата, і їх буде важко мотивувати, щоб вийти за рамки менталітету "натискання та натискання", який працював на них протягом останніх 10 років.

Є кілька проблем, які вам доведеться подолати, ви згадали про те, що багато адміністраторів не хочуть брати участь у програмуванні, навіть настільки низькому рівні, як сценарії. Інше пов’язане з цим, і це питання контролю. Коли адміністратор виконує завдання вручну, вони точно знають, що відбувається на кожному етапі. Багато адміністраторів можуть відчути, що замінюючи це сценарієм, вони втрачають контроль над процесом, особливо якщо вони не розуміють сценарії та не написали сценарій (і не хотіли його писати).

Я думаю, що це більше проблема адміністраторів Windows, ніж Unix, оскільки сценарії вже давно є значною частиною адміністрування Unix і, як правило, адміністратори Unix дізнаються з самого початку, як адміністрація Windows, і притаманний йому GUI- ness призводить до більш ручного процесу, і сценарій може здатися неприродним.

На жаль, отримати розробників над цим горбом - це важка битва. Щоб адміністратор все ще відчував, що їм керують, їм потрібно зрозуміти, що робить сценарій, і тому насправді потрібно зрозуміти і навчитися сценарію, і єдиний спосіб, коли ви збираєтеся їх зробити це - це якщо вони дійсно розумію, що може зробити їм сценарій

Все гаразд говорять, що це полегшить ситуацію, полегшить життя тощо, але чи можете ви це довести? Знайдіть завдання, яке вони ненавидять, що їм доводиться регулярно виконувати і намагатися його автоматизувати. Якщо ви зможете взяти це жахливе завдання і зробити його сценарієм в один клік, вони вам сподобаються, але що ще важливіше, вони можуть побачити користь використання сценаріїв.

[зітхання] Це занадто поширене у світі Windows, хоча я б поставив під сумнів ваше твердження про те, що більшість не бажає підробляти і вчитися розробляти сценарії. Абсолютна найбільша річ, яку я коли-небудь робив у своїй кар'єрі сисадміна, - це вивчити VB та Perl, що призвело до VBS, що призвело до багатьох інших речей.

Якщо просто показ їх не спрацьовує мотивувати, один трюк, який я люблю використовувати, - це викидати тонкі висловлювання перед керівництвом :) Назвіть це смоктанням, якщо ви хочете, але це не так. Покажіть тим, хто приймає рішення, переваги, часто він починає поширюватися через групу. Хоч не шукай з цього приводу.

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

Це питання є високо суб'єктивним. Хоча я згоден з ефективністю та посиленим контролем, який забезпечує сценарій, чому це має бути мандат? Чому потрібно заохочувати людей до використання сценаріїв лише тому, що ви любите ним користуватися? Чому б не дозволити людям вибрати вибір інструментів, які їм подобаються та віддають перевагу?

Це питання також ілюструє загальну упередженість, що існує в світі ІТ: Якщо я не сценарію, я не повинен бути настільки розумним чи добрим, як той, хто робить сценарій, і це неправильно. Я знав безліч людей, які могли сценарію краще за мене, але вони не змогли підмережу врятувати своє життя або зрозуміти, як запустити мережевий слід, або налаштувати SQL-сервер для використання AWE, або не знали, що таке завантаження. Файл ini був для тощо, тощо.

Чесно кажучи, ви можете вести коня до води, але ви не можете змусити його пити.

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

Через це я протистояв навчанню кодувати, але одного разу, коли я вирішив спробувати, у мене був вибух.

Що стосується залучення когось, спробуйте використовувати сценарії AD / LDAP, щоб заманити їх. (Я думаю, що це трохи доступніше, ніж спілкування з WMI.) Призначте прогрес завдань, скажіть: "дайте мені імена користувачів та адреси електронної пошти люди групи XYZ ".

Я написав цей біт коду, щоб знайти всіх користувачів, які не були членами жодної із зазначених груп: https://github.com/gwaldo/LDAP-Inverse-Group-Membership-Report

Щодо ресурсів, ознайомтеся із хлопцями Microsoft Scripting Guys (які мають чудові статті та навчальні посібники) та Scriptomatic2, які я люблю копати у WMI.

Наступне питання: чому вони повинні сценаріювати? Це і визначить відповідь.

Імовірно, ви сценарій, тому що це більш ефективно. У такому випадку ви можете або показати всім іншим, або вказати керівництву, що є більш ефективні способи управління системами і чекати, коли вони скористаються цим у міру скорочення витрат.

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

Існує також питання, як саме це впливає на вас. Це вас просто турбує, чи ваше життя буде кращим, якби ваші товариші адміністратора писали речі?

У мене насправді була інша думка. Що стосується того, що молодші адміністратори Windows використовуються для взаємодії з графічним інтерфейсом, можливо, це допоможе, якщо ви розпочали їх із сценарію взаємодії з графічним інтерфейсом, з чимось на зразок AutoIt . Це дозволило б їм ступити ногою у двері щодо сценаріїв, одночасно дозволяючи використовувати інструменти, які вони вже знають, замість того, щоб викидати існуючі інструменти та змусити їх одночасно вивчати нові інструменти та сценарії.

Потім, як тільки їм сподобається ідея сценаріїв взагалі, вони можуть перейти до сценаріїв, що не є GUI. Навіть якщо це не так, однак автоматичне натискання кнопок все ще може бути значною економією часу.

Я визначив сценарії як "Документація, яка працює для вас".

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

Співробітник: У мене є сценарій, який виконує Task-X, чи можу я їм це просто дати.

Менеджер: Впевнений, що після того, як ви закінчите документацію, про яку я щойно попросив, документуйте свій сценарій також із схемою потоків.

Я визначив сценарії як "Документація, яка працює для вас".

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

Співробітник: У мене є сценарій, який виконує Task-X, чи можу я їм це просто дати.

Менеджер: Впевнений, що після того, як ви закінчите документацію, про яку я щойно попросив, документуйте свій сценарій також із схемою потоків.

Не забувайте, що документація повинна бути в документі MS Word, щоб ускладнити її читання з сервера.