Jak zachęcić administratorów systemu Windows do wybrania skryptów? [Zamknięte]

Kiedy pracowałem jako administrator w mojej pierwszej pracy, byłem sfrustrowany, że nasze procesy administracyjne na serwerach Windows były serią „wskaż i kliknij”; nigdy nie dorównalibyśmy poziomowi wydajności serwerów Unix, które miały grupę skryptów powłoki automatyzujących wiele pracy. Wkrótce przeczytałem o WSH i ADSI i nie traciłem czasu na naukę, ile automatyzacji udało mi się osiągnąć dzięki skryptom.

Był jednak ogromny problem - prawie żaden z moich kolegów z Windows nie był tak naprawdę zainteresowany nauką skryptów. Wydawali się zadowoleni z ręcznego klikania myszą i nigdy nie byli podekscytowani perspektywą użycia skryptów do wykonywania pracy w ich imieniu. Walczyłem z przekonaniem ich do umiejętności pisania skryptów, pomimo widocznego wzrostu wydajności. Później porzuciłem tę pracę, aby kontynuować karierę w dziedzinie oprogramowania.

Prawie dekadę pracy w różnych środowiskach i różnych klientach wciąż napotykam administratorów Windows, którzy mają ten ogólny „nastrój”, w którym unikaliby jak największej liczby skryptów. Pomimo rosnącego poziomu dostępności technologie serwerów Windows otwierają się na skrypty i automatyzację. Jestem prawie pewien, że większość administratorów to administratorzy właśnie dlatego, że absolutnie nie znoszą wykonywania jakichkolwiek zadań programistycznych. Jakie są sposoby zachęcania i motywowania administratorów, że skrypty naprawdę mogą im pomóc na dłuższą metę?

Jako administrator systemu Unix i Windows, który wykonuje wiele skryptów uniksowych i prawie nie używa skryptów Windows, powiedziałbym, że jest to częściowo spowodowane niesamowitą niewygodnością narzędzi i interfejsów API Windows oraz trudnościami (być może nieoczywistość byłaby lepsze słowo) uruchamiania rzeczy zdalnie na komputerze z systemem Windows.

To znaczy, WTF to jest?

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

Częścią problemu, jak sądzę, jest to, że nie jest API. W systemie Unix administratorzy w dużej mierze skryptują automatyzację narzędzi wiersza polecenia, z których już korzystają. W systemie Windows musisz korzystać z tego nieznanego na każdym poziomie interfejsu API. Na przykład, co oznacza „podszywanie się”? To banalna koncepcja dla administratora systemu Unix, który prawdopodobnie używa sudo i su i zna już skrypty setuid. Ale administrator systemu Windows raczej nie zna tego; mogą wiedzieć o „runach” (lub równoważnej opcji GUI), ale znacznie bardziej prawdopodobne jest, że zalogują się jako administrator, gdy będą musieli zrobić coś administratora.

A dokumentacja dotycząca skryptów w systemie Windows jest nieszczęśliwa. Po pierwsze, jest to o wiele bardziej „język interpretowany” niż skrypt, ponieważ używają (nieznanego) interfejsu API, a nie poleceń, które już znają. Ale nie sądzę, że kiedykolwiek znalazłem coś przydatnego w dokumentacji Microsoftu, do czego nie doprowadziło to znalezienie kogoś, kto już robił coś zbliżonego do tego, co chciałem, co wskazało mi właściwy kierunek. Nigdzie nie wydaje się lista rzeczy do zrobienia. To tak, jakbyś już musiał znać wewnętrzne elementy systemu Windows, aby wykonywać najbardziej podstawowe czynności.

Nie to, że skrypty uniksowe często nie wyglądają jak szum linii. Ale administrator systemu Unix może zacząć od skryptu, który wykonuje tylko proste polecenia, które już zna. („Zawsze muszę uruchamiać te trzy polecenia po kolei. Jeśli po prostu połączę je w pliku, mogę to zrobić za pomocą jednego polecenia!”). Następnie będzie mógł robić postępy, gdy będzie mu wygodnie. W przeciwieństwie do tego, administrator nie może napisać skryptu „zaloguj się na serwerze jako administrator; kliknij Start → Ustawienia → Panel sterowania; kliknij dwukrotnie System; kliknij kartę Nazwa komputera; itp.” Tak, wszystko, do czego próbował dotrzeć, jest prawdopodobnie gdzieś prezentowane przez API, ale nie ma sposobu, aby stopniowo to znalazł.

Tak więc, aby odpowiedzieć na pytanie „w jaki sposób możemy zmusić administratorów Windows do wykonywania większej ilości skryptów?”, Odpowiedź brzmi: uczyń skrypty mniej obcymi. Jak to zrobić, nie wiem.

Szczerze mówiąc, odpowiedź należy do Microsoftu. Nie ma powodu, dla którego nie mogą mieć narzędzia wiersza polecenia do robienia wszystkiego, co jest zrobione za pomocą GUI. (W rzeczywistości jest ich teraz dużo, ale nie są reklamowane, są słabo udokumentowane i są niespójne.) Nie ma również powodu, aby w GUI nie było żadnej wskazówki, co ten przycisk faktycznie działa. Przygotuj podpowiedź, która pokazuje modyfikowany obiekt API. Lub udokumentuj to w oknie Pomoc.

Nie ma problemu z ochroną użytkowników przed elementami wewnętrznymi, ale Windows wydaje się, że aktywnie ukrywa te elementy wewnętrzne, nawet przed tymi, którzy chcą je znaleźć.

Daj im zadanie, które naprawdę można wykonać tylko za pomocą skryptu - na przykład kiedyś musiałem napisać skrypt do tworzenia setek folderów i niestandardowych uprawnień dla każdego folderu i musiałem to aktualizować CODZIENNIE. Gdyby mieli to zrobić ręcznie, byłaby to ich jedyna praca. Skrypt, który wykorzystywał CACLS między innymi do resetowania uprawnień na podstawie danych wyjściowych pliku tekstowego z ogranicznikami, zajął około dnia do perfekcji (podstawowy skrypt został wykonany w około godzinę).

Kiedy zaczniesz widzieć, co możesz zrobić ze skryptami, może to być ogromna wygrana.

Kiedyś zatrudniłem sysadmina, który wprost odmówił wykonania jakiegokolwiek „programowania”, próbowałem mu pokazać drogę, dając dobry przykład. Najlepsze, co mogłem z niego wyciągnąć, to użyć istniejącego kodu i zmodyfikować przypisanie zmiennych lub nazwę hosta ect. wykonać pracę. Niektórym ludziom po prostu nie przeszkadza programowanie, więc musisz obniżyć dla nich barierę.

Microsoft robi to w drodze. W SQL Server od jakiegoś czasu można kliknąć elementy w GUI Management Studio, a następnie zrzucić skrypt t-sql tego, co właśnie zrobiłeś. Jest to świetne, szczególnie dla niezbyt programistycznego systemu Windows.

Zauważyłem, że System Center Virtual Machine Manager ma tę samą funkcję skryptu widoku, z tym wyjątkiem, że zrzuca skrypt PowerShell. Myślę, że wiele innych linii produktów również to wprowadza.

Jak zmotywować administratorów do pisania skryptów? trudne połączenie, dobry administrator jest leniwym administratorem, a to oznacza administratora, który wykona jak najwięcej skryptów. Administrator, który ma czas na klikanie, nie jest zbyt produktywny! Przeładuj administratorów tak dużą ilością pracy, że nie mają innego wyjścia, jak tylko pisać.

Z całego serca zgadzam się z twoim postem. Niestety nie sądzę, że wiele można zrobić bez wsparcia ze strony zarządzania i istniejących procesów, które wymuszają używanie skryptów. Mając wybór, ludzie zawsze wybierają to, co znane i co łatwe. Czasami może to wydawać się punktem ujemnym, ale są chwile, kiedy prostota i znajomość są zaletą.

Z jednej strony system Windows domyślnie ma być prosty / łatwy, podczas gdy systemy Unix / Linux są znacznie trudniejsze i mniej wybaczające. Kto więc może winić administratorów za to, że obierali ścieżkę najmniejszego oporu? Podczas gdy ty, ja lub wiele innych osób możecie rozpoznać moc skryptów, ludzie w końcu nauczą się w taki czy inny sposób. Zazwyczaj administratorzy, którzy powstrzymują się od skryptów, uczą się na własnej skórze. Lubię pracować mądrzej, inni mogą po prostu lubić pracować.

Jakie są sposoby zachęcania i motywowania administratorów, że skrypty naprawdę mogą im pomóc na dłuższą metę?

Kiedyś myślałem, że możesz motywować ludzi, ale rzeczywistość jest taka, że ​​jeśli nie jesteś za nie odpowiedzialny, prawdopodobieństwo udanej „motywacji” jest bardzo niskie. Moje dzisiejsze podejście jest takie: ci, którzy chcą się uczyć, pomogę. Nie bądź sprzedawcą produktu, którego nikt nie chce, niezależnie od tego, czy go potrzebuje. Kiedy pomagasz / uczysz tylko jedną osobę zmotywowaną (z jakiegokolwiek powodu), będzie ona katalizatorem zmian. Nie ty. Tylko moje dwa centy.

Mantra, którą przechodzę, brzmi: „Pracuj mądrzej, nie ciężej”. Wykonanie dowolnego procesu więcej niż kilka razy oznacza, że ​​zwykle istnieje sposób, w jaki można go wykonać za pomocą kliknięcia myszy, skryptu bash lub innej metody. Z mojego punktu widzenia osobiście uwalnia mnie to do wykonywania ważniejszych zadań, które nie są „pracą fizyczną” administracji systemem.

Ci, którzy chcą uniknąć skryptów, mogą mieć kilka rzeczy w głowie. Być może lubią interfejs GUI i nie chcą uczyć się wiersza poleceń ani programowania. Może myślą, że skryptując coś, po prostu zmniejszają swoje poczucie własnej wartości. Tak czy inaczej, nie jest to pracownik, którego chciałbym mieć, a niechęć do pisania skryptów pokazuje, jakim jest pracownikiem. Wolałbym raczej rozwiązać problem niż „głupiego” administratora systemu.

Jeśli chodzi o ich zachęcanie i motywowanie, powiedziałbym, aby po prostu robić to, co robiliście, pokazać wzrost wydajności i jak może to ułatwić ich pracę. Dla niektórych bycie administratorem systemu Windows to tylko wypłata i ciężko będzie zmotywować ich do wyjścia poza mentalność „wskaż i kliknij”, która działała dla nich przez ostatnie 10 lat.

Jest kilka problemów, które musisz przezwyciężyć, wspomniałeś o jednym, że wielu administratorów nie chce brać udziału w programowaniu, nawet na tak niskim poziomie jak pisanie skryptów. Drugi jest z tym związany i jest to kwestia kontroli. Gdy administrator wykonuje zadanie ręcznie, dokładnie wie, co dzieje się na każdym etapie. Wielu administratorów może czuć, że zastępując to skryptem, tracą kontrolę nad procesem, szczególnie jeśli nie rozumieją skryptów i nie napisali skryptu (i nie chcieli go napisać).

Myślę, że jest to bardziej problem z administratorami Windows niż z Uniksem, ponieważ skrypty są od dawna dużą częścią administracji Uniksa i ogólnie rzecz biorąc, administratorzy Unixa uczą się od samego początku, gdzie jako administracja Windows i jego nieodłączne GUI- ness prowadzi do bardziej ręcznego procesu, a skrypty mogą wydawać się nienaturalne.

Niestety pozyskanie programistów przez ten garb to ciężka bitwa. Aby administrator nadal czuł, że ma kontrolę, musi zrozumieć, co robi skrypt, a więc naprawdę musi zrozumieć i nauczyć się, jak to zrobić, a jedynym sposobem, w jaki go zmusisz, jest zrobienie tego naprawdę rozumiem, co skrypt może im zrobić

Wszystko bardzo dobrze mówi, że przyspieszy to, ułatwi życie itp., Ale czy możesz im to udowodnić? Znajdź zadanie, którego nienawidzą, które muszą wykonywać regularnie, i spróbuj je zautomatyzować. Jeśli możesz podjąć się tego okropnego zadania i uczynić go skryptem jednym kliknięciem, pokochają cię, ale co ważniejsze, mogą zobaczyć korzyści ze stosowania skryptów.

[westchnienie] Jest to zbyt powszechne w świecie Windows, chociaż kwestionowałbym twoje stwierdzenie, że większość nie chce kucać i nauczyć się pisać. Absolutnie największą rzeczą, jaką kiedykolwiek zrobiłem w mojej karierze sysadmin, było nauczenie się VB i Perla, co doprowadziło do VBS, który prowadził WIELE innych rzeczy.

Jeśli samo ich pokazanie nie działa na motywację, jedną z sztuczek, które lubię, jest rzucenie subtelnych oświadczeń przed zarządem :) Jeśli chcesz, nazwij to ssaniem, ale tak nie jest. Pokaż decydentom korzyści, które często zaczynają się rozprzestrzeniać w grupie. Nie przejmuj się tym.

Mówiąc bardziej subtelnie, zmiana kogoś jest trudna (jeśli nie niemożliwa). Dawaj dobry przykład!

To pytanie jest wysoce subiektywne. Chociaż zgadzam się z wydajnością i większą kontrolą zapewnianą przez skrypty, dlaczego musi to być mandat? Dlaczego musisz zachęcać ludzi do korzystania ze skryptów tylko dlatego, że lubisz go używać? Dlaczego nie pozwolić ludziom wybrać narzędzia, które lubią i preferują?

To pytanie ilustruje również powszechne uprzedzenie w świecie IT: że jeśli nie będę pisać skryptów, nie będę tak inteligentny ani tak dobry, jak ktoś, kto pisze skrypty, i to źle. Znałem wiele osób, które potrafiłyby pisać lepiej ode mnie, ale nie mogły podsieci, aby uratować im życie lub dowiedzieć się, jak uruchomić śledzenie sieci, skonfigurować serwer SQL do korzystania z AWE lub nie wiedziałem, co to boot. plik ini był dla itd. itd.

Szczerze mówiąc, możesz doprowadzić konia do wody, ale nie możesz zmusić go do picia.

Pojawiłem się jako SysAd w Marine Corps około 10 lat temu, gdzie istnieje duża luka między byciem administratorem a byciem koderem. Bycie koderem zazwyczaj oznacza, że ​​utkniesz w kontakcie ze stroną internetową projektu zwierzaka CO (mało wykonujesz swoją rzeczywistą pracę ...).

Z tego powodu oparłem się nauce kodowania, ale kiedy postanowiłem spróbować, świetnie się bawiłem.

Jeśli chodzi o przyciąganie kogoś, spróbuj użyć skryptu AD / LDAP, aby go zwabić. (Myślę, że jest to trochę bardziej dostępne niż zajmowanie się WMI.) Przydziel postęp zadań, powiedz „podaj mi nazwy użytkowników i adresy e-mail ludzie w grupie XYZ ”.

Napisałem ten fragment kodu, aby znaleźć wszystkich użytkowników, którzy nie byli członkami żadnej z określonych grup: https://github.com/gwaldo/LDAP-Inverse-Group-Membership-Report

Jeśli chodzi o zasoby, sprawdź Microsoft Scripting Guys (z doskonałymi artykułami i samouczkami) i Scriptomatic2, które uwielbiam zagłębiać się w WMI.

Następne pytanie: dlaczego mają pisać? To określi odpowiedź.

Prawdopodobnie piszesz, ponieważ jest bardziej wydajny. W takim przypadku możesz albo pokazać wszystkim innym, albo wskazać kierownictwu, że istnieją bardziej wydajne sposoby administrowania systemami i poczekać, aż wykorzystają to w celu obniżenia kosztów.

Osoba upoważniona może zlecić skrypty, wymagając, aby istniały skrypty do obsługi większości rzeczy. To, jak dobrze to zadziała, zależy od kilku rzeczy; jeśli tylko tak powiedziano, skrypty prawdopodobnie pozostaną żałośnie nieodpowiednie i przestarzałe, podczas gdy administratorzy będą działać normalnie.

Jest także pytanie, jak dokładnie to na ciebie wpływa. Czy to ci przeszkadza, czy może twoje życie byłoby lepsze, gdyby Twoi koledzy administrowali skryptami?

Właściwie miałem inną myśl. W związku z tym, że młodsi administratorzy Windows są przyzwyczajeni do interakcji z GUI, być może pomogłoby to, gdybyś zaczął od interakcji ze skryptem GUI, z czymś takim jak AutoIt . Pozwoliłoby im to postawić stopę w drzwiach, jeśli chodzi o pisanie skryptów, jednocześnie pozwalając im korzystać z narzędzi, które już znają, zamiast wyrzucać istniejące narzędzia i zmuszać ich do nauki nowych narzędzi i pisania skryptów w tym samym czasie.

Następnie, kiedy już zaznajomią się z ogólną ideą skryptowania, mogą przejść do skryptowania bez GUI. Nawet jeśli nie, automatyzacja kliknięć przycisków może potencjalnie znacznie zaoszczędzić czas.

Zdefiniowałem skrypty jako „Dokumentację, która działa dla Ciebie”.

Kierownik: Idź, spędzając niezliczone godziny na tworzeniu dokumentacji, którą pierwsza równiarka może zrozumieć, która będzie nieaktualna do końca tygodnia, aby Twoi współpracownicy kliknęli kliknięcie w Zadanie X.

Pracownik: Mam skrypt, który wykonuje Zadanie X, czy mógłbym im to tylko dać.

Kierownik: Pewnie, po zakończeniu dokumentacji, o którą właśnie poprosiłem, udokumentuj również swój skrypt za pomocą schematu blokowego.

Zdefiniowałem skrypty jako „Dokumentację, która działa dla Ciebie”.

Kierownik: Idź, spędzając niezliczone godziny na tworzeniu dokumentacji, którą pierwsza równiarka może zrozumieć, która będzie nieaktualna do końca tygodnia, aby Twoi współpracownicy kliknęli kliknięcie w Zadanie X.

Pracownik: Mam skrypt, który wykonuje Zadanie X, czy mógłbym im to tylko dać.

Kierownik: Pewnie, po zakończeniu dokumentacji, o którą właśnie poprosiłem, udokumentuj również swój skrypt za pomocą schematu blokowego.

Nie zapominaj, że dokumentacja powinna znajdować się w dokumencie MS Word, aby utrudnić odczytanie go z serwera.