Những gì cần thiết cho các nhà phát triển để chạy máy chủ VM của riêng họ trong môi trường doanh nghiệp [đã đóng]

Đây kịch bản cũng đã được đăng trên SO , với những câu hỏi khác nhau cho khán giả khác nhau - và tôi rất vui vì tôi đã làm như tôi đã nhận được một số phản ứng rất tốt.

Chúng tôi đang cố gắng thực hiện một môi trường phát triển bằng cách sử dụng ảo hóa cho một nhóm nhỏ gồm 4 nhà phát triển trong một tổ chức doanh nghiệp. Điều này sẽ cho phép chúng tôi thiết lập các môi trường phát triển, thử nghiệm và phân tầng riêng biệt - cũng như cho phép truy cập vào các hệ điều hành mới là yêu cầu đối với các hệ thống hoặc công cụ mà chúng tôi đang đánh giá.

Chúng tôi đã tái sử dụng một máy thuộc loại máy trạm hiện có, đã ném vào RAM 24GB và RAID-10 và vẫn hoạt động tốt cho đến khi chúng tôi cố gắng đưa máy vào miền.

Bây giờ chúng tôi đang bắt đầu cuộc chiến mà tất cả các nhà phát triển doanh nghiệp kể từ đầu đã phải chiến đấu - cuộc chiến giành quyền kiểm soát cục bộ của một môi trường phát triển và thử nghiệm. Các quản trị viên mạng và CNTT đã đưa ra một số mối lo ngại từ "Máy chủ ESX là tiêu chuẩn doanh nghiệp" đến "máy chủ không được phép trên Vlan của máy khách" đến "[điền vào chỗ trống] không phải là bộ kỹ năng hiện đang sở hữu tổ chức CNTT địa phương hoặc doanh nghiệp ".

Chúng tôi có thể có thể biện minh cho phần cứng cấp độ sản xuất và hỗ trợ CNTT chính thức (đọc: chúng tôi có thể biện minh cho nhu cầu nếu cần, nhưng sẽ mất nhiều thời gian và liên quan đến rất nhiều vấn đề đau đầu) - nhưng có thể sẽ mất nhiều tháng để chính thức có được tài nguyên CNTT được chỉ định bằng cách coi đây là một hệ thống sản xuất - và ngay cả khi chúng tôi đã làm, chúng tôi có thể sẽ mất quyền kiểm soát cục bộ mà chúng tôi muốn.

Tôi tưởng tượng rằng nhiều bạn đã gặp khó khăn tương tự với các nhà phát triển trong doanh nghiệp của mình để kiểm soát nhà phát triển đối với các môi trường phi sản xuất, vì vậy các câu hỏi của tôi như sau:

1. Các nhà phát triển của bạn đã đưa ra những lý lẽ nào để giúp bạn vượt qua việc cho phép các loại silo này tồn tại trong các doanh nghiệp có chính sách bảo mật và mạng tiêu chuẩn có thể nói chung (và có thể hiểu được) loại trừ cơ sở hạ tầng không được quản lý (tập trung) này?
2. Đây có phải chỉ là vấn đề của các nhà phát triển đưa ra một biện minh kỹ thuật hoặc kinh doanh và đảm bảo rằng việc quản lý bản vá và AV sẽ xảy ra - hay nhiều hơn là một cuộc đấu tranh chính trị để kiểm soát và sở hữu?
3. Đưa ra lựa chọn, bạn có muốn sở hữu và hỗ trợ phần cứng / HĐH trong khi trao quyền cho quản trị viên địa phương hay để họ quản lý hoàn toàn, trong khi đảm bảo rằng họ tạo ra quản lý bản vá / AV và chịu trách nhiệm nếu họ gây ra sự cố?
4. Nếu bạn chặn thành công các nhà phát triển có quyền kiểm soát cục bộ các "máy chủ giả mạo" trên cơ sở hạ tầng của mình, thì các nhà phát triển đã thực hiện đúng hay họ (hoặc bạn) đã chuyển môi trường phát triển sang một mạng Vlan / hoàn toàn tách rời?

Một vài giả định để giới hạn phạm vi của câu hỏi này:

1. Để lặp lại, điều này là cho một môi trường phát triển - không yêu cầu tải sản xuất hoặc khả năng hỗ trợ. Không có gì có thể truy cập bên ngoài.
2. Đây không phải là một cuộc chiến thần thánh giữa Hyper-V và ESX (chúng tôi cũng sẽ ổn - nhưng Hyper-V đã được chọn vì nó "miễn phí" với MSDN cho các mục đích này [vâng, VMWare cũng có các công cụ miễn phí - nhưng quản lý tốt các công cụ thường không] và sẽ dễ dàng quản lý hơn bởi các nhà phát triển địa phương trong "Microsoft Shop") - vì vậy các đối số cho hoặc chống lại nằm ngoài phạm vi của câu hỏi này.
3. Nhóm nhà phát triển đã đảm bảo quản lý bản vá và chống vi-rút hoặc tích hợp với các hệ thống doanh nghiệp hiện có nếu CNTT sẽ hỗ trợ nó - nhưng chắc chắn trong phạm vi bạn có sẵn sàng chấp nhận điều đó hay không.

Trước hết, tôi thấy một vài lý do tại sao quản trị viên của bạn có quyền đẩy lùi:

• CNTT cũng chịu trách nhiệm báo cáo về những thứ như quản lý bản vá, phần mềm chống vi-rút, tuân thủ pci, kiểm toán bảo mật hàng năm (hoặc thường xuyên hơn), v.v. Không chỉ là vấn đề đảm bảo của bạn rằng việc này được quan tâm, mà còn có thể để chứng minh điều đó với người ngoài.

  Ví dụ, tôi điều hành mạng tại một trường đại học nhỏ và chúng tôi có một phòng thí nghiệm vật lý với một vài máy thu thập dữ liệu cho các thí nghiệm của sinh viên. Điều duy nhất họ làm là thu thập dữ liệu từ một công cụ khoa học và in ra kết quả (đến một máy in được gắn trực tiếp) để sinh viên phân tích và trao cho người hướng dẫn. Chúng không bao giờ có trên internet - ngay cả các bản cập nhật AV và Windows được áp dụng thông qua mạng cục bộ. Lý do duy nhất khiến chúng được kết nối với mạng và chạy phần mềm AV là mục đích rõ ràng là báo cáo cho phần mềm giám sát của tôi rằng chúng vẫn tồn tại và hiện tại. Thật ngớ ngẩn, vì thực tế họ sẽ an toàn hơn khi xóa kết nối mạng, nhưng trước tiên họ được trả tiền bằng một khoản trợ cấp giáo dục và vì vậy đó là những yêu cầu báo cáo của tôi.

• Dù muốn hay không, máy chủ dev của bạn là một hệ thống sản xuất theo quan điểm của các nhà phát triển. Cung cấp cho nó có thể một tháng và các nhà phát triển sẽ có một thời gian khó khăn để hoàn thành công việc nếu nó ngừng hoạt động vì các quy trình bạn sẽ thiết lập giả định rằng máy chủ có sẵn. Tránh / hạn chế các tình huống trong đó công nhân không hoạt động vì lỗi công nghệ là lý do lớn khiến các doanh nghiệp vẫn sử dụng các bộ phận CNTT tập trung.
• Nếu "Máy chủ ESX là Tiêu chuẩn doanh nghiệp", bạn cần tuân theo điều đó. Tại thời điểm này, có sự khác biệt đáng kể giữa cách hyper-v, vmware, xen và những người khác làm mọi thứ và một cỗ máy được chế tạo cho một người không thể được coi là chạy tốt trên máy kia. Nếu bạn định làm điều này, CNTT sẽ cần phải giúp quản lý nó vào một lúc nào đó và họ không muốn phải chuyển đổi nó thành vmware sau khi có một loạt lỗi trên máy có thể gây ra sự cố.
• Một ngày nào đó máy này sẽ cũ và cần bảo trì thường xuyên hơn hoặc thiết lập một chu kỳ thay thế tiêu chuẩn. Ngay cả các máy chủ mới đôi khi có bộ phận ăn mày. Tình trạng này hầu như luôn rơi vào lòng IT chỉ sau khi một cái gì đó bị hỏng khiến mọi người không thể làm việc của họ. Bằng cách chịu trách nhiệm cho máy chủ sớm, CNTT có thể thực hiện công việc tốt hơn nhiều để đảm bảo bạn tránh được việc mất điện ngoài dự kiến.
• Đây là một cá nhân, nhưng tôi có thể nói với bạn rằng điều cuối cùng tôi muốn trên mạng của mình là một máy tính để bàn khác giả dạng máy chủ. Tôi đã giải quyết đủ những năm vừa qua để kéo dài cả đời.

Điều đó nói rằng, CNTT cần có thể hỗ trợ sáng kiến ​​này. Họ chỉ nói "Không" là không đủ. Thách thức họ đưa ra một giải pháp thay thế đáp ứng nhu cầu (rất thực tế) của bạn. Tình huống chính trị duy nhất ở đây là sự thay thế của họ có thể có giá nhãn dán lớn hơn (vì họ đang lên kế hoạch cho các chi phí mà bạn chưa thể thấy), và vì vậy câu hỏi sẽ là ai phải trả tiền cho nó. CNTT sẽ không muốn vì họ không dự trù ngân sách cho nó, nhưng bạn sẽ chùn bước vì gấp 6 lần số tiền bạn đã chi cho một giải pháp mà bạn hài lòng (hiện tại).

Ngoài ra, có vẻ như bạn có thể đang cố chạy trước khi bạn có thể đi bộ. Bạn muốn tân trang quá trình phát triển của bạn. Là một nhà phát triển trước đây, tôi nghĩ điều đó thật tuyệt. Nhưng đừng chỉ ném ra một loạt các VM và "môi trường" (ví dụ: dev, giai đoạn, qa, v.v.). Lập kế hoạch cho các quy trình mới sẽ như thế nào - làm thế nào các nhà phát triển sẽ hoàn thành công việc. Bạn sẽ sử dụng tích hợp liên tục? Xây dựng tự động? Sử dụng phần mềm nào để hỗ trợ họ? Các nhà phát triển sẽ được phép chuyển mã sang sản xuất hoặc dàn dựng, hoặc chỉ QA sẽ có khả năng đó? Bạn có cần một dàn riêng? Còn hai nhánh dev (một cho vNext, một cho lỗi với vC Hiện tại) thì sao?

Bạn có thể cần một máy chủ chỉ để người quản lý hoặc người quản lý phát triển có thể giải quyết tất cả, nhưng nếu vậy thì đó phải là bước đầu tiên, và việc thiết lập và thiết kế quy trình ban đầu cần được thực hiện trước khi các nhà phát triển thực hiện nó sử dụng.

1) Các nhà phát triển của bạn đã đưa ra những lý lẽ nào để giúp bạn vượt qua việc cho phép các loại silo này tồn tại trong các doanh nghiệp có chính sách bảo mật và mạng tiêu chuẩn có thể nói chung (và có thể hiểu được) loại trừ cơ sở hạ tầng không được quản lý (tập trung) này ?

Không có gì - chủ yếu là vì tôi không đóng vai trò quản lý trong tổ chức của mình nên bất kỳ "điều chính trị" nào trong số này không thực sự liên quan đến tôi. Lập luận duy nhất thực sự thuyết phục tôi là cho phép một cái gì đó rõ ràng chống lại chính sách mạng và được miễn trừ khỏi sự kiểm soát và tầm nhìn của nhóm vận hành hệ thống là một lỗ hổng không khí và một lá thư CYA từ sếp của sếp tôi.

Không phải là tôi thực sự muốn trở thành một doanh nghiệp nói "Không", chỉ là không có cách nào tốt để điều này kết thúc tốt đẹp từ quan điểm của nhóm hoạt động.

1. Chúng tôi kết thúc với các máy chủ được quản lý bởi những người có bộ kỹ năng chính không quản lý các máy chủ trên mạng, những người không có khả năng hiển thị toàn bộ mạng và không gian vấn đề liên quan. Đây không chỉ là mối quan tâm chính trị của việc "bảo vệ" sân cỏ; như một ví dụ trite tưởng tượng những gì xảy ra khi một nhà phát triển bật DHCP vì một số lý do.
2. Chúng tôi cuối cùng quản lý các máy chủ của nhóm phát triển cho họ. Điều này là lộn xộn cho lý do ngược lại. Các nhà phát triển liên tục khó chịu khi chúng tôi vá lỗi này (phá vỡ thứ mà họ biết nhưng chúng tôi không) hoặc họ đấu tranh để chúng tôi kích hoạt các tính năng vì nhiều lý do tốt mà chúng tôi không muốn kích hoạt. Điều này nhanh chóng biến thành bế tắc nơi nhóm điều hành cảm thấy gánh nặng và bị quấy rối và nhóm phát triển cảm thấy thất vọng và bị bỏ qua.
3. Có những hậu quả chính trị - bởi vì sau đó bạn phải giải thích cho bộ phận khác tại sao các nhà phát triển lại "đặc biệt" và tại sao họ được miễn chính sách mạng.

2) Đây có phải chỉ là vấn đề của các nhà phát triển đưa ra một biện minh kỹ thuật hoặc kinh doanh và đảm bảo rằng việc quản lý bản vá và AV sẽ xảy ra - hay nhiều hơn là một cuộc đấu tranh chính trị để kiểm soát và sở hữu?

Tôi không nghĩ các nhà phát triển cần tạo ra một trường hợp kinh doanh - khá rõ ràng rằng các nhà phát triển phải phát triển và để làm được điều đó họ cần một môi trường phát triển nào đó. Đối với quản lý bản vá và AV - đó là công việc của nhóm hoạt động và chúng tôi sẽ đảm bảo rằng nó đã được thực hiện. Không phải là chúng tôi nghĩ rằng các nhà phát triển không thể làm điều đó. Chỉ là chúng tôi không tin tưởng bạn làm đúng - Quản trị viên hệ thống ở lại Quản trị viên hệ thống vì họ không tin bất cứ điều gì để làm bất cứ điều gì đúng nên không có gì là cá nhân. Tất nhiên, có một vấn đề chính trị rõ ràng về cảm giác như người khác đang "làm việc của bạn" nhưng đó không thực sự là vấn đề kỹ thuật và do đó nằm ngoài phạm vi của SF.

3) Đưa ra lựa chọn, bạn muốn sở hữu và hỗ trợ phần cứng / HĐH trong khi trao quyền quản trị viên cục bộ hay để họ quản lý hoàn toàn, đồng thời đảm bảo rằng họ tạo ra quản lý bản vá / AV và chịu trách nhiệm nếu họ gây ra các vấn đề?

Không phải vì những lý do nêu trên.

4) Nếu bạn chặn thành công các nhà phát triển có quyền kiểm soát cục bộ các "máy chủ lừa đảo" trên cơ sở hạ tầng của mình, thì các nhà phát triển đã thực hiện đúng hay họ (hoặc bạn) đã chuyển môi trường phát triển sang một mạng Vlan / hoàn toàn tách rời?

Lỗ hổng không khí. Cách tốt nhất để xử lý tình huống này là cung cấp cho các nhà phát triển môi trường của họ (và kiểm soát nó) và sau đó air-gap hoặc sử dụng một số phương pháp mạnh mẽ khác để tách nó ra khỏi mạng. Đây thực chất là cách chúng tôi xử lý wifi công cộng. Bạn muốn dịch vụ wifi? Chắc chắn rồi. Bạn trả tiền cho kết nối mạng, chúng tôi sẽ quản lý các WAP, nhưng nó sẽ không bao giờ chạm vào mạng của chúng tôi. Lấy làm tiếc. Nhu cầu của bạn là một trong hàng trăm. Có những mối quan tâm khác chúng ta phải xem xét.

Bạn không muốn tham gia vào việc nói không, bởi vì các nhà phát triển (những người đặc biệt thông minh về mặt kỹ thuật) sẽ tìm mọi cách để có được thứ họ muốn. Vì vậy, hãy cung cấp cho họ một môi trường phù hợp với nhu cầu của họ, khiến họ hài lòng và sau đó tìm cách ngăn chặn mọi thứ họ làm trong môi trường phát triển chạm vào phần còn lại của mạng lưới kinh doanh của bạn.

TL; DR: Tôi sẽ cung cấp cho bạn một máy chủ với bất kỳ nền tảng ảo hóa nào bạn muốn trên một mạng vật lý hoặc Vlan riêng biệt. Truy cập vào môi trường phát triển của bạn sẽ thông qua một máy chủ pháo đài duy nhất mà nhóm điều hành sẽ kiểm soát và giám sát. Những gì bạn làm với doanh nghiệp của bạn - Nó sẽ không được hỗ trợ nhưng chúng tôi sẽ cung cấp lời khuyên và trợ giúp khi thời gian cho phép quản trị máy chủ.

Nếu bạn đến với tôi với một máy lớp máy trạm được tải vào chuồng với RAM cấp độ người tiêu dùng, ổ cứng cấp độ người tiêu dùng, PSU cấp độ người tiêu dùng và RAID cấp độ người tiêu dùng, tôi cũng sẽ từ chối đưa nó vào mạng máy chủ.

Có rất nhiều thứ bạn cần hiểu về việc đưa một cái gì đó tương tự lên Vlan máy chủ.

1. Vlan máy chủ rất có thể là một DMZ. Trong DMZ, bạn không đặt bất cứ thứ gì không được làm cứng và bảo mật. Đây chỉ là một chiếc máy bạn đưa cho họ, họ không biết bạn đã làm gì với nó. Nó cũng có nghĩa là vá và cập nhật thường xuyên, có nghĩa là được quản lý tập trung. Tôi chắc chắn sẽ không đăng nhập vào từng máy chủ không được quản lý và áp dụng các bản vá bằng tay.

2. Các thành phần trong máy đó sẽ thất bại. Tôi hứa. Trong vòng 6 hoặc 12, 24 tháng, nó sẽ tăng lên. Sau đó, các bản sao lưu ở đâu? Oh, bạn đã không thiết lập chúng? Nhưng, tôi nghĩ đó là một máy chủ? Ồ, đó là một máy chủ mà người khác cung cấp? ... và trò chơi đổ lỗi lại bắt đầu

3. Ai sẽ chịu trách nhiệm khi nó gặp sự cố và cứt vào quạt? Trong hầu hết các tổ chức "Tôi đã đưa nó cho nhà phát triển để chăm sóc" sẽ không bay.

4. Họ sẽ đặt nó ở đâu? Máy chủ là tất cả các giá được gắn trong những ngày này và đặt một tháp trong một giá làm lãng phí không gian và giá đỡ của chúng có thể không được thiết kế cho nó.

Vì vậy, bộ phận CNTT rất hợp lý khi không đưa máy tính ngẫu nhiên này vào mạng máy chủ của họ.

Tuy nhiên, đó là công việc của bộ phận CNTT để đảm bảo rằng BẠN có thể thực hiện công việc CỦA BẠN đúng cách. Họ cần đảm bảo rằng bạn có những gì bạn cần, khi bạn cần. Nếu bạn có một phần mềm mà doanh nghiệp cần tiếp tục chạy, họ phải cung cấp một nền tảng để nó chạy. Đó là mô tả công việc của họ. Nhưng bạn cần chắc chắn rằng họ có thông tin họ cần để thực hiện công việc của họ.

Nếu bạn đã đến với tôi, trong tổ chức của tôi, nói với tôi rằng bạn đang bắt đầu một dự án mới, tôi sẽ đưa cho bạn ba VM: Dev, Live và Staging. Bạn sẽ có toàn quyền quản trị đối với Dev và chúng tôi sẽ thảo luận về những gì bạn cần để thực hiện công việc của mình cho hai người kia. Nếu bạn cần quyền quản trị đầy đủ cho họ và có thể biện minh cho điều đó, thì bạn sẽ có được nó. Chúng tôi có triển khai VM của chúng tôi xuống. VMWare làm cho việc này cực kỳ đơn giản - chỉ mất khoảng 5 phút cho mỗi VM để triển khai.

Có vẻ như bộ phận CNTT của bạn phải chịu đựng những gì mà hầu hết các bộ phận CNTT trong một công ty lớn phải chịu đựng. Xây dựng các lâu đài nhỏ và bảo vệ chúng bằng cuộc sống của bạn, không cho người khác vào, hách dịch, v.v ... Là một người làm việc với các bộ phận CNTT của người khác mỗi ngày, tôi luôn thấy điều đó. Và thật là bực bội.

Thực tế cơ bản là mặc dù sự thay đổi cần phải xảy ra từ bên trong bộ phận CNTT và nó phải được bắt đầu từ phía trên chúng. Và nếu bạn có thể khiến IT nhận ra rằng họ không phải là một thế lực đối với chính họ (vì hầu hết họ không tạo ra thu nhập cho doanh nghiệp của họ thì điều này có thể là một cái tát vào mặt), và họ ở đó để hỗ trợ nhân viên hiện có và tăng cường kinh doanh, sau đó bạn sẽ thấy rằng các câu hỏi của bạn trở nên không liên quan, bởi vì mọi người sẽ được chơi những gia đình hạnh phúc.

Tại sao bạn muốn thêm nó vào miền? Nói cách khác, câu trả lời tốt hơn cho câu hỏi: Bạn có thể thiết lập một phòng thí nghiệm để làm bất cứ điều gì bạn muốn, miễn là nó không được kết nối với mạng LAN của công ty. (Nếu bạn cần truy cập internet, có thể bạn có thể có Vlan DMZ-ed; đó không phải là vấn đề, đặc biệt là nếu bạn chỉ sử dụng nó để đi ra ngoài , như để tải xuống.)

Đó là một, trong số rất nhiều câu trả lời khác nhau cho câu hỏi.

Bạn sẽ nhận được RẤT NHIỀU câu trả lời ở đây, cho và chống lại các nhà phát triển có quyền truy cập quản trị viên vào bất kỳ phần nào của môi trường (có thể chủ yếu là chống lại), nhưng đây là điểm mấu chốt:

Nhóm sysadmin được giao nhiệm vụ giữ cho các hệ thống sản xuất hoạt động, ổn định và an toàn và chịu trách nhiệm đảm bảo các hệ thống đó cung cấp các dịch vụ mà công ty đang trả tiền (vì họ đang trả tiền cho chúng) ở mức mà họ mong đợi.

Tương tự như vậy, nhóm nhà phát triển đã được giao nhiệm vụ cung cấp dịch vụ cho công ty (web, ứng dụng, v.v.), mặc dù trong một lĩnh vực khác. Chiến đấu để kiểm soát môi trường phát triển là phản tác dụng và không phục vụ mục đích hữu ích cho cả hai bên.

Tôi làm việc tại một ISV / ASP nhỏ. Chúng tôi đã có một nhà phát triển và một sysadmin (tôi). Chúng tôi có một mối quan hệ dựa trên sự tôn trọng và tin tưởng lẫn nhau. Chúng tôi cần phải làm việc như một nhóm để giúp đạt được các mục tiêu bao quát của công ty. Tôi cung cấp cho nhà phát triển đầy đủ, quyền truy cập vào môi trường dev của anh ta, bao gồm các máy trạm và máy chủ. Tôi quản lý các hệ thống dev để bảo mật, cập nhật, AV và phần cứng và nhà phát triển làm phần còn lại. Khi mã của anh ấy sẵn sàng để sản xuất, anh ấy đưa nó cho tôi, hỗ trợ tôi với bất kỳ cấu hình nào cần thiết và lùi lại. Chúng tôi cung cấp hỗ trợ lẫn nhau cho nhau.

Các nhà phát triển nên là bậc thầy của môi trường phát triển và Sysadmin nên là bậc thầy của môi trường sản xuất, trong các ranh giới hợp lý và với các kiểm tra, cân bằng và kiểm soát hợp lý. Khi một trong hai bên cần "vượt qua" thì nên hợp tác và hòa nhạc với bên "trị vì" dưới sự xem xét và hướng dẫn của họ.

Trước hết, kinh nghiệm của tôi là nghiêm túc trong một tổ chức nhỏ hơn, nhưng vấn đề này xuất hiện ở các công ty thuộc mọi quy mô, vì vậy ...

1.  What arguments have your developers made that won you over to
allow these types of silos to exist within enterprises which have
standard network and security policies in

Theo quan điểm của tôi, lập luận duy nhất mà các nhà phát triển cần đưa ra là "chúng tôi cần điều này". Nếu họ đến với tôi trước, tôi sẽ cố gắng hiểu nhu cầu của họ và xem những gì chúng tôi có thể giải quyết. Nhưng, cuối cùng, nếu họ nói "chúng tôi cần điều này", tôi sẽ cho họ lợi ích của sự nghi ngờ và tin tưởng rằng họ biết họ đang làm gì.

Nhưng đó mới chỉ là khởi đầu - đó là khía cạnh "Pro" của phương trình. "Con" là nơi chúng ta bước vào cuộc tranh cãi ...

2. Is this just a matter of the developers making a technical or
business justification

Ngoại trừ việc "chỉ" là một cách nói đáng kinh ngạc, vâng, nếu các nhà phát triển có thể đưa ra lời biện minh về kỹ thuật và kinh doanh, sẽ không có vấn đề gì. Những người khác ở đây và trên các lập trình viên. E (nơi câu hỏi SO của bạn đã được di chuyển) đã chỉ ra rất nhiều cạm bẫy cho thiết lập của bạn, vì vậy tôi sẽ không lặp lại chúng. Nếu bạn đưa ra một kế hoạch để đối phó với tất cả những vấn đề đó và bất kỳ vấn đề nào khác mà bộ phận CNTT của bạn nghĩ ra, và biện minh cho TẤT CẢ các chi phí, thì sẽ rất hợp lý.

3.  Given the choice, would you prefer to take ownership and support
of the hardware/OS while giving devs local admin rights,

Đây không phải là người mới bắt đầu, bạn không thể có hai nhóm với các mục tiêu và trách nhiệm khác nhau đang cố gắng quản lý cùng một hệ thống. Nó sẽ không kết thúc tồi tệ, nó sẽ bắt đầu tồi tệ và kết thúc trong sự đổ máu.

(more of 3.) ... or let them manage it entirely, while ensuring that
they institute patch management/AV and charging them with
responsibility should they cause problems?

Tôi nghĩ rằng điều này được bao phủ bởi câu trả lời của tôi cho 2.: Đây là những chi tiết kỹ thuật mà họ phải đưa ra giải pháp cho.

4.  If you successfully blocked developers from having local control
of "rogue servers" on your infrastructure, did the developers just
make due or did they (or you) move the development environment to a
disconnected VLAN/entirely separate network?

Tôi đồng ý với kce: "Air-gap"

Nếu họ có thể biện minh cho chi phí bổ sung mà họ đang đảm nhận (bằng cách trở thành quản trị viên môi trường của họ), các nhà phát triển có thể có mạng mini của riêng họ, nơi họ có quyền tự do, nhưng NHƯNG đã cách ly hoàn toàn: không có gì chạm vào phần còn lại của mạng. Vì vậy, họ phải đưa ra nhiều biện minh kỹ thuật và kinh doanh hơn, ví dụ như "chúng ta sẽ sao lưu dữ liệu quan trọng như thế nào?"

Một lần nữa, tôi phải đồng ý với kce: "Quản trị viên hệ thống ở lại Quản trị viên hệ thống vì họ không tin tưởng bất cứ điều gì đúng" Công việc của chúng tôi là xây dựng các hệ thống đáng tin cậy nhất mà chúng tôi có thể tạo ra từ các thành phần không đáng tin cậy, vì vậy mọi đề xuất bao gồm một nửa hàng tá thứ mà một sysadmin có kinh nghiệm biết là vô cùng dễ vỡ sẽ nhận được phản ứng tiêu cực mạnh mẽ.

Từ các câu trả lời và nhận xét ở đây và trên các lập trình viên. Tôi nghĩ rằng rõ ràng có những khía cạnh mà bạn chưa xem xét. Mặc dù sẽ mất nhiều thời gian hơn, tôi nghĩ bạn thực sự cần phải đi nói chuyện với các nhân viên IT của mình và trình bày những điều khác biệt: "đây là những gì chúng ta cần làm, có cách nào để tích hợp điều này vào cơ sở hạ tầng và hoạt động hiện tại không?"

Vấn đề chung, trong hàng triệu trường hợp tương tự của bạn là:

1) Trách nhiệm mờ nhạt - không có mối liên hệ trực tiếp giữa hành động của một công nhân công ty và lợi nhuận của anh ta. Anh ta được trả theo tháng, và không phải bằng hiệu ứng, mà càng khó đo lường, tổ chức càng lớn. Nó áp dụng cho bảo mật, người quản lý, v.v ... Nếu họ làm tê liệt công việc của bạn, họ không quan tâm.

2) Các nhà hoạch định chính sách và bảo mật thường có ít hoặc không có kiến ​​thức về lập trình. Họ không thể hiểu rằng họ đang làm tê liệt công việc của bạn ngay cả khi họ sẽ quan tâm (điều này thường không áp dụng).

3) Hồ sơ tâm lý ưa thích cho công việc trong an ninh là tính cách hoang tưởng hoặc rối loạn ám ảnh cưỡng chế. Những người này nhìn thấy âm mưu ở khắp mọi nơi. Nếu các nhà phát triển muốn một cái gì đó, chẳng hạn như máy chủ mới, họ chắc chắn muốn sử dụng nó để đánh cắp dữ liệu của công ty và xuất bản chúng trong WikiLeaks hoặc bán cho Triều Tiên.