Làm cách nào để khuyến khích quản trị viên Windows chọn tập lệnh? [đóng cửa]


26

Khi tôi làm quản trị viên trong công việc đầu tiên của mình, tôi đã thất vọng vì các quy trình quản trị của chúng tôi với các máy chủ Windows là một loạt các điểm nhấn; chúng tôi không bao giờ có thể phù hợp với mức độ hiệu quả với các máy chủ Unix có một nhóm các kịch bản shell để tự động hóa rất nhiều công việc. Tôi sớm đọc về WSH và ADSI và lãng phí thời gian để học cách tự động hóa tôi có thể đạt được với kịch bản.

Mặc dù có một vấn đề rất lớn - hầu như không có đồng nghiệp Windows nào của tôi thực sự quan tâm đến việc học kịch bản. Họ có vẻ hài lòng với các công việc nhấp chuột thủ công và không bao giờ hào hứng với triển vọng sử dụng các tập lệnh để thực hiện công việc thay mặt họ. Tôi đấu tranh để thuyết phục họ tiếp thu các kỹ năng viết kịch bản mặc dù hiệu quả tăng rõ rệt. Tôi đã rời bỏ công việc đó để theo đuổi sự nghiệp phát triển phần mềm toàn thời gian sau đó.

Gần một thập kỷ làm việc trong các môi trường khác nhau và các khách hàng khác nhau, tôi vẫn bắt gặp các quản trị viên Windows chủ yếu sở hữu "tâm trạng" chung này, nơi họ sẽ tránh kịch bản nhiều nhất có thể. Mặc dù mức độ tiếp cận ngày càng tăng, các công nghệ máy chủ Windows đang mở ra cho kịch bản và tự động hóa. Tôi gần như chắc chắn phần lớn các quản trị viên là quản trị viên chính xác bởi vì họ hoàn toàn ghét thực hiện bất kỳ loại nhiệm vụ lập trình nào. Một số phương tiện để khuyến khích và thúc đẩy các quản trị viên rằng kịch bản có thể thực sự giúp họ về lâu dài là gì?

Câu trả lời:


21

Là một quản trị viên Unix và Windows, người thực hiện nhiều kịch bản Unix và hầu như không có kịch bản Windows, tôi nói rằng đó là một phần do sự lúng túng đáng kinh ngạc của các tiện ích và API kịch bản Windows, và khó khăn (có thể không rõ ràng một từ tốt hơn) về việc chạy mọi thứ từ xa trên máy Windows.

Ý tôi là, WTF là cái này?

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

Một phần của vấn đề, tôi nghĩ, là có một API. Trong Unix, quản trị viên chủ yếu viết kịch bản tự động hóa các tiện ích dòng lệnh mà họ đã sử dụng. Trong Windows, bạn phải sử dụng API không quen thuộc ở mọi cấp độ. Ví dụ, "mạo danh" nghĩa là gì? Đây là một khái niệm tầm thường đối với một quản trị viên Unix, người có khả năng sử dụng sudo và su và đã quen thuộc với các tập lệnh setuid. Nhưng một quản trị viên Windows dường như không quen thuộc với điều đó; họ có thể biết về "runas" (hoặc tùy chọn GUI tương đương), nhưng họ có nhiều khả năng đăng nhập với tư cách quản trị viên khi họ cần làm gì đó admin-y.

Và các tài liệu về kịch bản trong Windows là khốn khổ. Đối với một điều, đó là "ngôn ngữ được giải thích" hơn nhiều so với tập lệnh, một lần nữa bởi vì họ đang sử dụng API (không quen thuộc) và không phải là các lệnh mà họ đã quen thuộc. Nhưng tôi không nghĩ rằng tôi đã từng tìm thấy bất cứ điều gì hữu ích trong tài liệu của Microsoft mà không phải dẫn đến bằng cách tìm ai đó đã làm điều gì đó gần với những gì tôi muốn đã chỉ cho tôi đi đúng hướng. Không nơi nào có vẻ như có một danh sách những việc bạn có thể làm. Có vẻ như bạn đã phải làm quen với các phần bên trong Windows để làm những việc cơ bản nhất.

Không phải là các tập lệnh Unix thường không giống như nhiễu dòng. Nhưng một quản trị viên Unix có thể bắt đầu với một tập lệnh không làm gì ngoài việc chạy các lệnh đơn giản mà anh ta đã biết. ("Tôi luôn phải chạy ba lệnh này liên tiếp. Nếu tôi đặt chúng trong một tệp cùng nhau, tôi có thể thực hiện nó trong một lệnh!") Và sau đó anh ấy có thể tiến triển khi anh ấy cảm thấy thoải mái với tình huống này. Ngược lại, không có cách nào để quản trị viên viết kịch bản "đăng nhập vào máy chủ với tư cách quản trị viên, nhấp vào Bắt đầu → Cài đặt → Bảng điều khiển; nhấp đúp vào Hệ thống; nhấp vào tab Tên máy tính, v.v." Vâng, bất cứ điều gì anh ta cố gắng để có thể được trình bày thông qua API ở đâu đó, nhưng không có cách nào để anh ta dần dần tìm thấy điều đó.

Vì vậy, để trả lời câu hỏi "làm thế nào chúng ta có thể khiến quản trị viên Windows thực hiện nhiều kịch bản hơn?", Câu trả lời là, làm cho kịch bản bớt xa lạ hơn. Làm thế nào để làm điều đó, tôi không biết.

Thành thật mà nói, câu trả lời nằm trong tay Microsoft. Không có lý do gì mà họ không thể có tiện ích dòng lệnh để thực hiện mọi thứ được thực hiện thông qua GUI. (Hiện tại thực sự có rất nhiều trong số chúng, nhưng chúng không được quảng cáo, chúng được ghi chép kém và chúng không nhất quán.) nút đó thực sự làm. Có một chú giải công cụ hiển thị đối tượng API đang được sửa đổi. Hoặc ghi lại nó trong cửa sổ Trợ giúp.

Không có vấn đề gì trong việc bảo vệ người dùng khỏi nội bộ, nhưng Windows dường như không thể chủ động che giấu những nội bộ đó, ngay cả với những người muốn tìm thấy chúng.


16
Ngược lại, WTF là đây? ls -1 *old* | awk '{print "mv "$1" "$1}' | sed s/old/new/2 | sh
squillman

4
Điểm hay trên thực tế là kịch bản windows - đặc biệt là VB rất khó xử cho đến khi bạn bắt đầu hiểu ra. Làm thế nào - PowerShell cũng đã đi một chặng đường dài để làm cho nó trở nên thân thiện hơn với quản trị viên. Nó gần với kịch bản Bash hơn VBS.
Zypher

2
BTW- chỉ chơi người ủng hộ của quỷ :) WMI thật xấu xí ...
squillman

1
LOL. Đầu tiên, ai sẽ làm điều đó? Thứ hai, quản trị viên ít nhất đã quen thuộc ls. Thứ ba, tôi sẽ xem xét sedawktương đối tiên tiến, và chắc chắn trong cùng lĩnh vực với các API Windows mà tôi đang nói đến. Thứ ba rưỡi, trong khi một số (nhiều) lệnh script của Unix rất phức tạp, bạn không phải bắt đầu ở đó & mdash; bạn có thể thực hiện những việc đơn giản như chỉ cần có một danh sách các lệnh bạn đã quen thuộc với & mdash; trong khi đó, nếu bạn muốn làm hầu như mọi thứ với Windows, trước tiên bạn phải có lộ trình học tập khổng lồ này. Cập nhật câu trả lời, mặc dù.
wfaulk

3
Tôi thích cách mà khi bạn làm một cái gì đó trong GUI trong Exchange 2007, nó chỉ tạo một tập lệnh PowerShell và chạy nó.
Richard Gadsden

8

Giao cho họ một nhiệm vụ thực sự chỉ có thể được thực hiện thông qua một tập lệnh - ví dụ, tôi đã từng phải tạo kịch bản cho việc tạo ra hàng trăm thư mục và quyền tùy chỉnh cho mỗi thư mục và nó phải được cập nhật HÀNG NGÀY. Nếu họ làm điều này bằng tay, đó sẽ là công việc duy nhất của họ. Tập lệnh sử dụng CACLS trong số những thứ khác để đặt lại quyền dựa trên đầu ra của tệp văn bản được phân tách, mất khoảng một ngày để hoàn thiện (tập lệnh cơ bản được thực hiện trong khoảng một giờ).

Khi bạn bắt đầu thấy những gì bạn có thể làm với kịch bản, nó có thể là một chiến thắng lớn.


+1 Điểm tuyệt vời, có những điều không thể thực hiện được bằng cách chỉ và nhấp.
squillman

vâng, các tập lệnh tôi đã viết lại vào những ngày đó đã tự động tạo ra các thư mục, quyền của DACL, thiết lập trang IIS, v.v. Nhưng các đồng nghiệp của tôi không bị thúc đẩy bởi điều đó. Mất một trong hai tháng để tìm hiểu cách viết hàm script để trả về một ngày ở định dạng chuỗi.
icelava

PS, như bạn có thể biết, không sử dụng CACLS, sử dụng XCACLS hoặc phá vỡ thừa kế ACL của bạn.
Richard Gadsden

5

Có lần tôi đã thuê một sysadmin, người hoàn toàn từ chối thực hiện bất kỳ 'lập trình' nào, tôi đã cố gắng chỉ cho anh ta con đường dẫn đầu bằng ví dụ. Điều tốt nhất tôi có thể thoát khỏi anh ta là sử dụng mã hiện có và sửa đổi gán biến hoặc tên máy chủ. để hoàn thành công việc Một số người không bận tâm với lập trình, vì vậy bạn cần hạ thấp rào cản cho họ.

Microsoft đang thực hiện điều này. Trong SQL Server, bây giờ có thể nhấp vào nội dung trong GUI của Studio quản lý và sau đó loại bỏ tập lệnh t-sql về những gì bạn vừa thực hiện. Điều này là tuyệt vời, đặc biệt đối với các cửa sổ không nghiêng lập trình sysadmin.

Tôi đã nhận thấy rằng Trình quản lý máy ảo trung tâm hệ thống có tính năng tập lệnh xem tương tự, ngoại trừ việc nó loại bỏ tập lệnh powershell. Tôi nghĩ rằng nhiều dòng sản phẩm khác cũng đang giới thiệu này.

Làm thế nào để thúc đẩy quản trị viên vào kịch bản? Cuộc gọi khó khăn, một quản trị viên giỏi là một quản trị viên lười biếng & điều đó có nghĩa là một quản trị viên sẽ viết kịch bản nhiều nhất có thể. Một quản trị viên có thời gian nhấp vào những thứ không hiệu quả lắm! Quá tải quản trị viên của bạn với rất nhiều công việc, mà họ không có lựa chọn nào khác ngoài kịch bản.


Sao mày dám gọi tao lười thế?! Ôi, đợi đã ...
squillman

6
lười biếng là một đức tính cho sysadmin!
Nick Kavadias

Helllllll yeah!
squillman

2
Theo kinh nghiệm của tôi, hầu hết các quản trị viên chỉ tiếp tục quá tải khi nhấp thủ công và mất nhiều thời gian hơn để hoàn thành công việc của họ. :-) Tôi nghĩ rằng có nhiều loại lười biếng khác nhau, một số lười suy nghĩ và chỉ muốn nhấp chuột không suy nghĩ; một số lười biếng nhấp và suy nghĩ để giảm điều đó.
icelava

tại thời điểm bạn chỉ cho họ cách bạn có thể thay thế công việc của họ bằng một số mã, họ khóc vì xấu hổ & thay đổi cách thức của họ ... hoặc họ không trong trường hợp bạn sa thải họ.
Nick Kavadias

4

Tôi hoàn toàn đồng ý với bài viết của bạn. Thật không may, tôi không nghĩ rằng có nhiều việc có thể được thực hiện mà không có sự hỗ trợ từ ban quản lý và các quy trình thực thi bằng cách sử dụng các tập lệnh. Đưa ra một lựa chọn, mọi người sẽ luôn đi với những gì quen thuộc và những gì dễ dàng. Đôi khi, điều này có vẻ như là một điểm tiêu cực, nhưng có những lúc sự đơn giản và quen thuộc là một điểm cộng.

Một mặt, hệ thống Windows hoàn toàn có nghĩa là đơn giản / dễ dàng trong khi các hệ thống Unix / Linux khó khăn hơn nhiều và ít tha thứ hơn. Vì vậy, ai có thể đổ lỗi cho các quản trị viên đã đi theo con đường ít kháng cự nhất? Trong khi bạn, hoặc tôi hoặc nhiều người khác có thể nhận ra sức mạnh của kịch bản, mọi người cuối cùng sẽ học theo cách này hay cách khác. Thông thường, các quản trị viên nắm giữ kịch bản học một cách khó khăn. Tôi thích làm việc thông minh hơn, những người khác có thể thích làm việc.

Một số phương tiện để khuyến khích và thúc đẩy các quản trị viên rằng kịch bản có thể thực sự giúp họ về lâu dài là gì?

Tôi đã từng nghĩ bạn có thể thúc đẩy mọi người, nhưng thực tế là trừ khi bạn chịu trách nhiệm về họ, xác suất "động lực" thành công là cực kỳ thấp. Thái độ của tôi những ngày này là: những người muốn học, tôi sẽ giúp. Đừng trở thành người bán hàng cho một sản phẩm mà không ai muốn bất kể họ có cần nó hay không. Khi bạn giúp / dạy chỉ một người có động lực (vì bất kỳ lý do gì), họ sẽ là chất xúc tác cho sự thay đổi. Không phải bạn. Chỉ hai xu của tôi.


1
+1 Bạn có thể dẫn một con ngựa xuống nước ...
squillman

2
... nhưng bạn không thể làm cho anh ta trượt nước.
osij2is

@squillman: Bạn nói chính xác những gì tôi đang nghĩ. Tôi đồng ý với điều này là: Nếu bạn có một kỹ năng mà người khác thiếu, hãy sử dụng nó để tiếp thị bản thân và tiến lên (bất cứ điều gì có ý nghĩa với bạn). Giúp người khác vượt lên chắc chắn là đáng ngưỡng mộ, nhưng bạn không thể kéo họ đá và la hét.
Evan Anderson

@Evan: Bạn có nghĩ rằng việc dạy một người học sẵn sàng là mâu thuẫn để "tiếp thị bản thân và đi trước"? Nếu một trong những quản trị viên Windows muốn nhờ tôi hỗ trợ (viết kịch bản), tôi sẽ do dự khi làm như vậy nhưng cuối cùng không làm việc theo nhóm có nghĩa là sẽ giúp họ thêm một dặm? Chỉ tò mò đọc suy nghĩ của bạn.
osij2is

1
@ osij2is: Tôi có tội khi giúp "những người học sẵn sàng" vượt quá mức mà tôi chắc chắn đã lãng phí một số "cơ hội" để tính hóa đơn nhiều giờ hơn, kiếm được nhiều tiền hơn, v.v. Một trong những "nhiệm vụ" của tôi trong cuộc sống là thúc đẩy sử dụng máy tính như vậy, cuối cùng, nó có thể làm cho cuộc sống của ai đó tốt hơn. Nếu ai đó đến với tôi với mong muốn học hỏi một cách nghiêm túc, tôi sẽ hạnh phúc hơn khi truyền lại bất cứ điều gì tôi có thể. Phải nói rằng, nếu một "sửa chữa" chuyển giao kiến ​​thức là điều tôi muốn, tôi cũng có thể làm điều đó. Đôi khi nó khiến tôi buồn khi không thể "dạy một người đàn ông câu cá", nhưng nếu đó là điều mà tình huống này đòi hỏi ...
Evan Anderson

2

Một câu thần chú tôi đi là "Làm việc thông minh hơn, không khó hơn". Thực hiện bất kỳ quy trình nào nhiều hơn một vài lần có nghĩa là thường có một cách bạn có thể tạo kịch bản để thực hiện tự động với một cú nhấp chuột, tập lệnh bash hoặc phương thức khác. Theo cách tôi nhìn thấy, cá nhân này giải phóng tôi để thực hiện các nhiệm vụ quan trọng hơn mà không phải là "lao động thủ công" của quản trị hệ thống.

Những người muốn tránh kịch bản có thể có một vài thứ chạy qua đầu họ. Có lẽ họ thích giao diện GUI và không muốn học dòng lệnh hoặc lập trình. Có thể họ nghĩ rằng bằng cách viết kịch bản một cái gì đó, về cơ bản họ đang làm giảm tầm quan trọng của bản thân. Dù bằng cách nào, đây không phải là loại nhân viên tôi muốn có và miễn cưỡng thực hiện bất kỳ loại kịch bản nào cho thấy họ là loại công nhân nào. Tôi thà có một người giải quyết vấn đề hơn là một quản trị viên hệ thống "ngu ngốc".

Theo như khuyến khích và thúc đẩy họ, tôi sẽ nói chỉ cần làm như bạn đang làm, cho thấy sự tăng năng suất và làm thế nào nó có thể làm cho công việc của họ dễ dàng hơn. Đối với một số người, trở thành Quản trị viên Hệ thống Windows chỉ là một khoản tiền lương và sẽ rất khó để thúc đẩy họ vượt ra khỏi tâm lý chỉ và nhấp đã làm việc cho họ trong 10 năm qua.


Ghi nhớ tốt về "người giải quyết vấn đề"; rất nhiều người tôi gặp chỉ muốn một cuốn sách hướng dẫn cho họ biết phải làm gì cho mọi vấn đề có thể hiểu được. Họ không muốn nghĩ về những gì đang xảy ra; chỉ cần đưa Bước 1 đến 23 để giải quyết vấn đề này.
icelava

Tôi có xu hướng gọi những người đó là "người đẩy nút", giống như nhân viên cổ áo xanh trong tương lai, George Jetson.
wfaulk

2

Có một vài vấn đề bạn phải khắc phục, bạn đã đề cập đến một vấn đề, đó là rất nhiều quản trị viên không muốn tham gia vào lập trình, thậm chí ở mức độ thấp như kịch bản. Cái khác liên quan đến điều này, và đây là vấn đề kiểm soát. Khi một quản trị viên đang thực hiện một nhiệm vụ bằng tay, họ biết chính xác những gì đang xảy ra ở mỗi giai đoạn. Nhiều quản trị viên có thể cảm thấy rằng bằng cách thay thế tập lệnh này bằng tập lệnh, họ sẽ mất quyền kiểm soát quy trình, đặc biệt nếu họ không hiểu về tập lệnh và không viết tập lệnh (và không muốn viết tập lệnh).

Tôi nghĩ rằng đây là một vấn đề với các quản trị viên Windows so với các quản trị viên Unix vì kịch bản đã là một phần lớn của quản trị Unix trong một thời gian dài và nói chung là điều mà các quản trị viên Unix học được từ đầu, như quản trị Windows, và GUI vốn có của nó- Ness dẫn đến một quá trình thủ công hơn và kịch bản có thể không tự nhiên.

Thật không may, có được các nhà phát triển trên cái bướu này là một trận chiến khó khăn. Để quản trị viên vẫn cảm thấy họ đang kiểm soát, họ cần hiểu kịch bản đang làm gì, và vì vậy thực sự cần phải hiểu và học cách viết kịch bản, và cách duy nhất bạn sẽ khiến họ làm điều này là nếu họ thực sự hiểu kịch bản có thể làm gì với họ

Tất cả đều nói rất rõ rằng nó sẽ làm mọi thứ nhanh hơn, làm cho cuộc sống dễ dàng hơn, nhưng bạn có thể chứng minh điều đó với họ không? Tìm một nhiệm vụ mà họ ghét, rằng họ phải thực hiện thường xuyên và thử và tự động hóa nó. Nếu bạn có thể thực hiện nhiệm vụ khủng khiếp này và biến nó thành một tập lệnh nhấp chuột duy nhất, họ sẽ yêu bạn, nhưng quan trọng hơn là họ có thể thấy được lợi ích của việc sử dụng tập lệnh.


Viết kịch bản với phản hồi tốt, có lẽ một số điều khiển tương tác nhỏ - công cụ thân thiện với người dùng ^^
Oskar Duveborn

1
Tôi bắt đầu học perl ngay khi tôi nhận ra mình có thể đảm nhận một công việc thường ngày đặc biệt dài và khó chịu và tự động hóa nó. Không nhìn lại từ đó.
Twirrim

Quan điểm của tôi là tất cả những "nhiệm vụ khủng khiếp" mà họ vẫn muốn thực hiện chúng một cách thủ công. :-)
icelava

sa thải rất nhiều người trong số họ và thay thế họ bằng một quản trị viên duy nhất là một người viết kịch bản. Tôi sẽ rẻ hơn
Nick Kavadias

2

[thở dài] Đây là cách quá phổ biến trong thế giới Windows, mặc dù tôi sẽ đặt câu hỏi về tuyên bố của bạn về đa số không muốn cưỡi ngựa và học kịch bản. Điều tuyệt vời nhất tôi từng làm trong sự nghiệp sysadmin của mình là học VB và Perl, dẫn đến VBS, dẫn dắt NHIỀU thứ khác.

Nếu chỉ cho thấy chúng không có tác dụng thúc đẩy, một mẹo tôi muốn sử dụng là đưa ra những tuyên bố tinh tế trước mặt quản lý :) Hãy gọi nó là hút nếu bạn muốn, nhưng thực tế không phải vậy. Chỉ ra cho những người ra quyết định những lợi ích, thường thì nó bắt đầu sinh sôi nảy nở thông qua nhóm. Đừng là một thằng ngốc về nó, mặc dù.

Trên một ghi chú tinh tế hơn, thật khó (nếu không thể) thay đổi một ai đó. Dẫn bằng ví dụ!


5
"Bạn biết không, tôi khá chắc chắn rằng tôi có thể viết kịch bản để chúng tôi không phải tiêu tốn nhân lực liên tục để thực hiện điều đó". Những từ ngữ mạnh mẽ trước mặt quản lý :)
Twirrim

1
Tôi luôn tin rằng chỉ trong thế giới Windows, ai đó mới có thể tự gọi mình là quản trị viên mà hoàn toàn không có kiến ​​thức lập trình. Một nhận xét khác bạn có thể gửi đến là "Tại sao bạn làm điều đó bằng tay? Đó là những gì chúng tôi có máy tính cho".
John Gardeniers

Thật không may, vì từ lâu tôi đã đi vào sự nghiệp phát triển và tư vấn, các quản trị viên mà tôi gặp bây giờ chủ yếu là những khách hàng của tôi. Tôi không phải lúc nào cũng có cơ hội khiến họ trông tệ trước sự quản lý hoặc lãnh đạo CNTT của họ :-)
icelava

1

Câu hỏi này mang tính chủ quan cao. Mặc dù tôi đồng ý với tính hiệu quả và tăng cường kiểm soát mà kịch bản cung cấp, tại sao nó phải là một nhiệm vụ? Tại sao bạn cần khuyến khích mọi người sử dụng kịch bản chỉ vì bạn thích sử dụng nó? Tại sao không để mọi người chọn sử dụng các công cụ họ thích và thích?

Câu hỏi này cũng minh họa một khuynh hướng phổ biến tồn tại trong thế giới CNTT: Rằng nếu tôi không viết kịch bản thì tôi không được thông minh hay giỏi như một người làm kịch bản, và điều đó sai. Tôi đã biết nhiều người có thể viết kịch bản tốt hơn tôi, nhưng họ không thể mạng con để cứu mạng họ hoặc tìm ra cách chạy theo dõi mạng hoặc định cấu hình máy chủ SQL để sử dụng AWE hoặc không biết khởi động là gì. tập tin ini là cho, vv, vv


2
Kịch bản nên được khuyến khích bởi vì đó là một thực tiễn tốt nhất đã được chứng minh (không có gì được đề cập về việc nó là một nhiệm vụ, tôi cũng không nghĩ nó được ngụ ý). Tôi thực sự chưa thấy thiên vị "bạn không thông minh", nhưng tôi không nghi ngờ rằng nó tồn tại. Tôi sẽ dễ dàng loại bỏ những người đó như những kẻ ngốc ...
squillman

2
Thế nào là chủ quan? Giống như bạn đã nói, kịch bản cải thiện hiệu quả. Không có gì sai với một công cụ hoặc quy trình bắt buộc kinh doanh làm tăng hiệu quả. Chắc chắn không có gì sai với một đồng nghiệp đang cố gắng khuyến khích người khác phát triển một kỹ năng giúp họ trở thành quản trị viên hệ thống tốt hơn.
Brian

3
@squillman, người nói rằng đó là một thực tiễn tốt nhất và bản thân nó không phải là chủ quan. Những gì thực hành tốt nhất cho tôi có thể không dành cho bạn. Có một nghiên cứu nói rằng 90% các công ty coi kịch bản là thực tiễn tốt nhất. @Brian: Ai nói nó làm cho họ quản trị hệ thống tốt hơn? Đồng nghiệp của tôi có thể viết kịch bản nhưng không thể mạng con trong khi tôi có thể mạng con nhưng không thể kịch bản, vậy ai tốt hơn? Không có ý định xúc phạm, chỉ chơi người ủng hộ của quỷ ở đây.
joeqwerty

3
@Joeqwerty: kịch bản mạnh mẽ so với điểm và nhấp vì kịch bản (chính xác) có thể thực hiện nhiều nhiệm vụ hơn trong thời gian ngắn hơn và chính xác hơn so với chúng ta, con người thấp kém có thể làm thủ công. Có lẽ cụm từ nên là: "kịch bản là một thực tiễn tốt hơn ". Đối số (người ủng hộ của quỷ) của bạn chủ quan hơn so với yêu sách. "Những gì thực hành tốt nhất cho tôi có thể không dành cho bạn." Điều đó có thể đúng, nhưng điều đó không có nghĩa đó không phải là cách thực hành tốt nhất. Điều đó có nghĩa là bạn không thể hoặc không biết cách thực hiện. Đó là một vấn đề khác nhau và của chính nó.
osij2is

2
Nhưng ý kiến ​​của bạn là sai. ;) Nghiêm túc, mặc dù, tôi nghĩ rằng tránh kịch bản cũng giống như tránh biết cách subnet. Không ai tốt cả. Ý tôi là, nếu bạn đồng ý rằng kịch bản làm tăng hiệu quả và kiểm soát, tại sao bạn lại lập luận rằng chúng ta nên đối xử bình đẳng với những người tránh nó? Nếu bạn thuê một người cày ruộng, bạn sẽ thuê anh chàng với máy kéo hay anh chàng với một con bò?
wfaulk

1

Thành thật mà nói, bạn có thể dẫn một con ngựa xuống nước, nhưng bạn không thể bắt nó uống.

Tôi đã trở thành một SysAd trong Thủy quân lục chiến khoảng 10 năm trước, nơi có một khoảng cách rộng giữa việc trở thành Quản trị viên và là một Người giải mã. Trở thành một Coder thường có nghĩa là bạn gặp khó khăn khi giao dịch với trang web dự án thú cưng của CO (hoàn thành rất ít công việc thực tế của bạn ...).

Vì điều này, tôi đã chống lại việc học viết mã, nhưng một khi tôi quyết định thử nó, tôi đã có một vụ nổ.

Theo như lôi kéo ai đó vào, hãy thử sử dụng kịch bản AD / LDAP để thu hút họ. (Tôi nghĩ rằng nó dễ truy cập hơn một chút so với xử lý WMI.) Chỉ định tiến trình của các tác vụ, nói "cho tôi tên người dùng và địa chỉ email của những người trong nhóm XYZ ".

Tôi đã viết đoạn mã này để tìm tất cả người dùng không phải là thành viên của bất kỳ nhóm nào được chỉ định: https://github.com/gwaldo/LDAP-Inverse-group-Membership-Report

Về tài nguyên, hãy xem Microsoft Scripting Guys (những người có bài viết và hướng dẫn tuyệt vời) và Scriptomatic2, thứ mà tôi yêu thích để đào sâu vào WMI.


0

Câu hỏi tiếp theo: tại sao họ nên viết kịch bản? Điều đó sẽ quyết định câu trả lời.

Có lẽ, bạn kịch bản bởi vì nó hiệu quả hơn. Trong trường hợp đó, bạn có thể chỉ cho mọi người thấy hoặc chỉ ra cho ban quản lý rằng có nhiều cách hiệu quả hơn để quản trị hệ thống và chờ họ tận dụng lợi thế đó trong một biện pháp cắt giảm chi phí.

Ai đó có thẩm quyền có thể ủy thác kịch bản, bằng cách yêu cầu phải có kịch bản để xử lý hầu hết mọi việc. Làm thế nào điều này sẽ làm việc tốt phụ thuộc vào một số điều; nếu chỉ tuyên bố như vậy thì các kịch bản có khả năng vẫn còn thiếu thốn và lỗi thời, trong khi các quản trị viên làm việc như bình thường.

Ngoài ra còn có câu hỏi chính xác làm thế nào điều này ảnh hưởng đến bạn. Có phải nó chỉ làm phiền bạn, hoặc cuộc sống của bạn sẽ tốt hơn nếu các quản trị viên của bạn viết kịch bản?


Hiệu quả chính là quản trị viên lãng phí thời gian của họ để thực hiện các công việc thủ công lặp đi lặp lại trên nhiều máy - vòng quay dài hơn - có thể ảnh hưởng đến lịch trình phát triển của chúng tôi (luôn luôn không bao giờ là đủ).
icelava

1
và đừng quên rằng các tác vụ thủ công dễ bị lỗi.
John Gardeniers

0

Tôi thực sự đã có một suy nghĩ khác. Liên quan đến thực tế là các quản trị viên Windows cơ sở được sử dụng để tương tác GUI, có thể nó sẽ hữu ích nếu bạn bắt đầu chúng với kịch bản tương tác GUI, với một cái gì đó như AutoIt . Điều này sẽ cho phép họ đặt chân vào cửa liên quan đến việc viết kịch bản trong khi vẫn cho phép họ sử dụng các công cụ mà họ đã biết, thay vì vứt bỏ các công cụ hiện có của họ và khiến họ học các công cụ mới và viết kịch bản cùng một lúc.

Sau đó, một khi họ cảm thấy thoải mái với ý tưởng về kịch bản nói chung, họ có thể chuyển sang kịch bản không phải GUI. Mặc dù nếu không, mặc dù, tự động bấm vào nút vẫn có thể có khả năng tiết kiệm thời gian lớn.


0

Tôi đã định nghĩa các tập lệnh là "Tài liệu thực hiện công việc cho bạn."

Người quản lý: Dành vô số thời gian để tạo tài liệu, mà một học sinh đầu tiên có thể hiểu, sẽ hết hạn vào cuối tuần, để đồng nghiệp của bạn nhấp vào nhấp chuột thông qua Nhiệm vụ-X.

Nhân viên: Tôi có một kịch bản thực hiện Nhiệm vụ-X, tôi có thể đưa cho họ kịch bản đó không.

Quản lý: Chắc chắn, sau khi bạn đã hoàn thành tài liệu tôi vừa yêu cầu, hãy ghi lại kịch bản của bạn, với một biểu đồ dòng chảy.


0

Tôi đã định nghĩa các tập lệnh là "Tài liệu thực hiện công việc cho bạn."

Người quản lý: Dành vô số thời gian để tạo tài liệu, mà một học sinh đầu tiên có thể hiểu, sẽ hết hạn vào cuối tuần, để đồng nghiệp của bạn nhấp vào nhấp chuột thông qua Nhiệm vụ-X.

Nhân viên: Tôi có một kịch bản thực hiện Nhiệm vụ-X, tôi có thể đưa cho họ kịch bản đó không.

Quản lý: Chắc chắn, sau khi bạn đã hoàn thành tài liệu tôi vừa yêu cầu, hãy ghi lại kịch bản của bạn, với một biểu đồ dòng chảy.

Đừng quên rằng tài liệu phải có trong tài liệu MS Word để làm phức tạp việc đọc nó từ máy chủ.


Tôi quên yêu cầu đó.
Nathan Hartley
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.