SysAdmin & Developer: Trách nhiệm [đã đóng]

Khi nói đến một cái gì đó giống như một máy chủ web sản xuất, cách thực hành tốt nhất cho trách nhiệm đối với sysadmin & developer là gì? Cụ thể, tôi đang suy nghĩ về việc cập nhật / cài đặt phần mềm. (Theo hiểu biết của tôi, nhà phát triển không nên có quyền truy cập root trên máy chủ sản xuất.)

Vì vậy, một máy chủ web sản xuất đang chạy Wordpress và nó cần được cập nhật lên phiên bản mới nhất. Ai chịu trách nhiệm giữ cho nó cập nhật?

Điều gì xảy ra nếu các nhà phát triển có các plugin bị hack tùy chỉnh hoặc các tệp lõi tùy chỉnh trên ứng dụng (trong ví dụ này là WP)?

Tôi đã thấy rằng trong hầu hết các trường hợp, nếu BẠN là người chịu trách nhiệm cho máy chủ vật lý thì tốt nhất là KHÔNG cấp quyền truy cập gốc cho nhà phát triển.

Đây là một chút của một cuộc tranh luận "chiến tranh thần thánh" vì tôi chắc chắn bạn sẽ tìm thấy các nhà phát triển không đồng ý. Cá nhân tôi đã ở cả hai phía của cuộc tranh luận đó.

Lý do CHÍNH của tôi về việc không cấp quyền truy cập gốc cho nhà phát triển (thậm chí 100% nhà phát triển đáng tin cậy) là bởi vì thường xuyên hơn không có gói nào họ cần để XYZ hoạt động chính xác. Họ tiếp tục và cài đặt nó ... hoặc cấu hình lại một cái gì đó đã có sẵn để nó hoạt động ... hoặc ... tốt ... bạn hiểu ý.

Nhiều tháng trôi qua ... máy chủ cần phải được cài đặt lại hoặc tạo lại ... và đột nhiên không ai biết tại sao "Nó hoạt động trên máy chủ cũ mà không phải máy chủ mới".

Câu trả lời tất nhiên là tài liệu bạn đang xem không bao gồm tất cả các gói và chỉnh sửa nhỏ mà các nhà phát triển đã làm để làm cho hệ thống hoạt động lần đầu tiên.

Nó có thể là một nỗi đau trong một $$ cho cả hai bên ... nhưng nếu sysadmin chịu trách nhiệm về máy chủ, gói và tài liệu ... và nhà phát triển chịu trách nhiệm phát triển và phần mềm ... Tôi nghĩ bạn ' cuối cùng sẽ thấy nó có giá trị

Nếu nhà phát triển cần một plugin tùy chỉnh, mô-đun, cấu hình, tinh chỉnh ... không có vấn đề gì ... hãy làm điều đó cho họ ... nhưng TÀI LIỆU CNTT để bạn có thể sao chép lại lần sau.

Nguyên tắc vàng : Đừng để những người không phải là quản trị viên chạm vào bất cứ điều gì bạn không muốn bị phá vỡ và bạn sẽ phải chịu trách nhiệm.

Các nhà phát triển nên có quyền truy cập vào một môi trường thử nghiệm. Khi công việc của họ đã sẵn sàng để được đưa vào máy sản xuất, nó sẽ được bàn giao cho quản trị viên hệ thống. Nếu các nhà phát triển đã hoàn thành công việc của họ và ghi lại đúng quy trình, tất cả sẽ diễn ra tốt đẹp. Nếu không, họ cần đá vào lưng vì không kiểm tra đầy đủ.

Tôi cũng đã tham gia trận chiến này. Câu trả lời của tôi là bất kỳ ai chịu trách nhiệm về thời gian hoạt động của máy chủ là người chịu trách nhiệm cho tất cả các cập nhật, thay đổi, v.v., v.v. Nobodoy khác nên có khả năng thực hiện các loại chức năng này trên máy chủ. Nếu đó là công việc của bạn để đảm bảo máy chủ hoạt động và nếu ông chủ bắt bạn phải chịu trách nhiệm và chịu trách nhiệm với máy chủ thì bạn có trách nhiệm duy trì và bảo mật nó.

Hầu hết các nhà phát triển sẽ nói với bạn rằng họ cần quyền truy cập cấp quản trị viên vào máy chủ và hầu hết họ sẽ không đồng ý với tôi, nhưng tôi là người phải khởi động lại lúc 2 giờ sáng khi bị treo, phải xây dựng lại sau một bản cập nhật không thành công, thời gian ngừng hoạt động được tính cho bộ phận của tôi, v.v., v.v. Tôi phải trả lời CIO về bất cứ điều gì ảnh hưởng đến SLA của chúng tôi, vì vậy tôi là người duy nhất có quyền truy cập cấp quản trị viên vào máy chủ và tôi m chịu trách nhiệm cho tất cả các thành phần, cập nhật, thay đổi, vv

Tôi đồng ý 100%. Dev hầu hết thời gian không nhận thức được làm thế nào mọi thứ syadmin hoạt động. Nếu họ cần bất cứ điều gì, họ yêu cầu bạn, đó là tất cả. Bạn nghĩ về cách thức và thời gian và bạn cung cấp cho họ một gói có thể sử dụng. (giống như họ cần gửi email, BẠN là người định cấu hình hậu tố). Hơn nữa, họ sẽ có xu hướng nghĩ rằng trong hầu hết các lần, quyền truy cập root sẽ khiến mọi thứ hoạt động nếu họ không thể làm điều đó với quyền truy cập bình thường. Tôi đồng ý với những người khác ở đây, họ sẽ không ở bên bạn lúc 2 giờ sáng khi bạn gặp vấn đề. Tôi đã có trường hợp vài tuần trước, một nhà phát triển muốn cập nhật wordpress của mình. Tôi đã nói với anh ta về thay đổi RTF, đối với anh ta, điều đó là vô ích, quá trình cập nhật được thực hiện thông qua một giao diện đẹp. Chà, bản cập nhật không hoạt động, tôi đã lưu ứng dụng của anh ấy, tôi đã tạo tập lệnh sao lưu không phải anh ấy. Không có tôi, anh không thể khôi phục trang.

Có một xu hướng làm mờ sự khác biệt giữa dev và hoạt động. Làm cho nhà phát triển của bạn sysadins và nhà phát triển hệ thống của bạn.

Theo nghĩa này, wordpress có thể được hưởng lợi từ một số công việc về chứng minh tự động (và lập trình) của blog. Nhiều người dùng wordpress duy trì nhiều hơn một vài phiên bản WP / WPMU và việc cập nhật chúng kịp thời ít nhất là cồng kềnh.

Bạn có thể tìm thấy một cái nhìn tổng quan (và thú vị) về triết lý tại các slide Cơ sở hạ tầng Agile từ Agile 2009

Các nhà phát triển không nên có gốc rễ trong sản xuất; tất cả mọi người ngoại trừ các nhà phát triển đồng ý về điều này. Nhưng các nhà phát triển có thể sắp xếp bánh của họ và ăn nó. Tôi hơi ngạc nhiên khi không ai đề cập rõ ràng về điều này:

Một trong những khách hàng doanh nghiệp nhỏ rất lâu của tôi có một trang web với cài đặt Drupal, một số trang web WordPress, diễn đàn SMF và một vài ứng dụng web nhỏ ngẫu nhiên khác. Tôi là sysadmin hợp đồng (và vì lý do lịch sử cũng cập nhật / hack WordPress và SMF khi cần) và khách hàng của tôi có hợp đồng phát triển Drupal của riêng mình. Môi trường là một số máy ảo VMware trên một nhà cung cấp đám mây công cộng.

Các nhà phát triển thực sự muốn có quyền truy cập root và loại nhu cầu đó. Chẳng hạn, họ có trách nhiệm viết các quy tắc viết lại nginx để làm cho tất cả các công cụ Drupal tùy chỉnh của họ hoạt động. Nhưng tôi không thể cho họ quyền truy cập root trên máy chủ sản xuất và khách hàng của tôi đồng ý với tôi về điều đó.

Vì vậy, chúng tôi đã thỏa hiệp: Họ có quyền truy cập root trên máy chủ web thử nghiệm (thường giống hệt với sản xuất ngoại trừ địa chỉ IP của nó và trên cùng một đám mây). Mà, giống như sản xuất, có vvkeeper để tôi có thể thấy bất kỳ thay đổi nào họ cần thực hiện và bất kỳ gói nào họ đã cài đặt. Sau đó tôi có thể kéo các thay đổi vào sản xuất hoặc nói với họ những gì sai với bất cứ điều gì họ muốn làm. Và nếu họ thực sự thất vọng (họ chưa làm được, cảm ơn gawd) tôi có thể dễ dàng hoàn nguyên các thay đổi của họ.

Họ không có quyền truy cập nào vào máy chủ cơ sở dữ liệu sản xuất; họ thậm chí không có thông tin đăng nhập người dùng. Chỉ có khách hàng của tôi và tôi làm.

(Bản thân ứng dụng web, họ triển khai trực tiếp bằng git và nếu họ phá vỡ nó, họ sẽ sửa nó và giải thích cho khách hàng của tôi lý do tại sao họ nên tiếp tục là nhà phát triển của anh ấy. cười nhạo họ hoặc facepalm.)

Root == Quản trị hệ thống.

Người dùng == Nhà phát triển, DBA hoặc Người dùng.

Root biết không ngủ khi máy chủ ngừng hoạt động, root bảo vệ người dùng khỏi chính họ, root bảo vệ dữ liệu của người dùng khỏi mạng, root đặt sức khỏe của máy chủ lên trên tất cả người dùng. Root ass nằm trên đường dây khi máy chủ ngoại tuyến. Máy chủ hạnh phúc, root hạnh phúc!

Lý do phổ biến cho thời gian không được lên lịch: Người dùng, những thay đổi không có giấy tờ trong môi trường và tồn đọng. Máy chủ thực hiện chính xác những gì họ được bảo rằng họ không phá vỡ ngẫu nhiên. Các tin tặc bạn hỏi, không phải là, khi nào ... do đó cần phải có "root".

00:33 CDT bạn có biết các bản sao lưu và tài liệu phục hồi thảm họa của bạn ở đâu không? :-p

Sysadmin nên có quyền truy cập quản trị viên (giống như tiêu đề nói). Không ai khác cần truy cập vào máy chủ sản xuất. Nếu các nhà phát triển cần khắc phục sự cố trên hệ thống sản xuất, vấn đề đó sẽ được tái tạo trong môi trường phát triển. Nếu không, họ có thể ngồi với sysadmin và xem qua hệ thống.

Các nhà phát triển không muốn chạm vào sản xuất, nhưng đó không phải là công việc. Có công việc là viết phần mềm và giao nó cho sysadins để phát hành sản xuất. Nếu họ đã ghi lại tất cả mọi thứ (và hãy nhớ rằng trong hầu hết các tài liệu của cửa hàng là một từ bẩn thỉu) thì các bản phát hành sẽ ổn.

Trong các công ty đại chúng ở Mỹ, bạn có SOX, HIPPA, v.v. Hầu hết các quy định sai lầm này thực sự giúp ích cho lập luận này. SOX ra lệnh tách các nhiệm vụ đòi hỏi các nhà phát triển phải tiếp tục thực hiện các hệ thống sản xuất.