Những điều sysadmin mà mọi lập trình viên nên biết?

<chèn từ chối bài đăng lớn ở đây>

Một số trong số này đã được nói trước đây, nhưng nó đáng để lặp lại.

Tài liệu:

• Tài liệu mọi thứ. Nếu bạn không có, hãy cài đặt wiki dưới radar, nhưng hãy chắc chắn rằng bạn đã sao lưu nó. Bắt đầu với việc thu thập dữ kiện, và một ngày, một bức tranh lớn sẽ hình thành.

• Tạo sơ đồ cho từng đoạn logic và giữ cho chúng được cập nhật. Tôi không thể đếm số lần bản đồ mạng hoặc sơ đồ cụm chính xác đã cứu tôi.

• Giữ nhật ký xây dựng cho mỗi hệ thống, ngay cả khi nó chỉ sao chép và dán các lệnh để biết cách xây dựng nó.

• Khi xây dựng hệ thống của bạn, hãy cài đặt và định cấu hình ứng dụng của bạn, kiểm tra nó hoạt động và thực hiện điểm chuẩn của bạn. Bây giờ, lau đĩa. Nghiêm túc. 'dd' megabyte đầu tiên ở phía trước đĩa hoặc nếu không thì sẽ khiến hộp không thể khởi động. Đồng hồ đang kêu: chứng minh tài liệu của bạn có thể xây dựng lại từ đầu (hoặc, thậm chí tốt hơn, chứng minh đồng nghiệp của bạn có thể không có gì nhiều hơn tài liệu của bạn). Điều này sẽ tạo thành một nửa kế hoạch khắc phục thảm họa của bạn.

• Bây giờ bạn đã có nửa đầu kế hoạch khắc phục thảm họa, ghi lại phần còn lại; cách lấy lại trạng thái của ứng dụng của bạn (khôi phục tệp từ băng, tải lại cơ sở dữ liệu từ các bãi chứa), chi tiết nhà cung cấp/hỗ trợ, yêu cầu mạng, cách thức và nơi nhận phần cứng thay thế - bất cứ điều gì bạn có thể nghĩ về điều đó sẽ giúp hệ thống của bạn sao lưu.

Tự động hóa:

• Tự động hóa càng nhiều càng tốt. Nếu bạn phải làm một cái gì đó ba lần, hãy đảm bảo rằng lần thứ hai được dành để phát triển tự động hóa của bạn để lần thứ ba hoàn toàn tự động. Nếu bạn không thể tự động hóa nó, hãy ghi lại nó. Có những bộ tự động hóa ngoài kia - xem bạn có thể làm cho chúng hoạt động cho bạn không.

Giám sát:

• Ứng dụng là vàng nguyên chất. Việc có thể xem các giao dịch đi qua hệ thống giúp việc gỡ lỗi và xử lý sự cố trở nên dễ dàng hơn rất nhiều.

• Tạo các thử nghiệm đầu cuối để chứng minh rằng không chỉ ứng dụng còn sống mà còn thực sự làm những gì nó phải làm. Điểm là của bạn nếu nó có thể được cắm vào hệ thống giám sát cho mục đích cảnh báo. Điều này phục vụ nhiệm vụ kép; ngoài việc chứng minh ứng dụng hoạt động, nó giúp việc nâng cấp hệ thống dễ dàng hơn đáng kể (hệ thống giám sát báo cáo màu xanh lá cây, nâng cấp hoạt động, thời gian để về nhà).

• Điểm chuẩn, theo dõi và thu thập số liệu về mọi thứ lành mạnh để làm như vậy. Điểm chuẩn cho bạn biết khi nào sẽ có thứ gì đó tỏa ra khói ma thuật. Giám sát cho bạn biết khi nào nó có. Số liệu và số liệu thống kê giúp dễ dàng có được bộ dụng cụ mới (với khói ma thuật mới) thông qua quản lý.

• Nếu bạn không có một hệ thống giám sát, hãy thực hiện một hệ thống. Điểm thưởng nếu bạn thực sự thực hiện các bài kiểm tra đầu cuối ở trên.

Bảo vệ:

• "Chmod 777" (còn gọi là cấp tất cả quyền truy cập/đặc quyền) không bao giờ là giải pháp.

• Theo nguyên tắc 'ít nhất'; nếu nó không được cài đặt, sao chép hoặc sống trên đĩa, nó không thể bị xâm phạm. "Bồn rửa nhà bếp" Cài đặt hệ điều hành và phần mềm có thể giúp cuộc sống dễ dàng hơn trong giai đoạn xây dựng, nhưng cuối cùng bạn phải trả tiền cho việc đó.

• Biết mọi cổng mở trên máy chủ dùng để làm gì. Kiểm tra chúng thường xuyên để đảm bảo không có cái mới nào xuất hiện.

• Đừng cố gắng làm sạch một máy chủ bị xâm nhập; nó cần phải được xây dựng lại từ đầu. Xây dựng lại máy chủ dự phòng với phương tiện mới tải xuống, chỉ khôi phục dữ liệu từ các bản sao lưu (vì các tệp nhị phân có thể bị xâm phạm) hoặc sao chép Máy chủ bị xâm nhập vào nơi bị cô lập để phân tích để bạn có thể xây dựng lại trên cùng một bộ. Có cả một cơn ác mộng pháp lý xung quanh vấn đề này, vì vậy hãy đứng về phía bảo quản trong trường hợp bạn cần theo đuổi con đường hợp pháp. (Lưu ý: IANAL).

Phần cứng:

• Không bao giờ giả định bất cứ điều gì sẽ làm những gì nó nói trên hộp. Chứng minh rằng nó làm những gì bạn cần, chỉ trong trường hợp không. Bạn sẽ thấy mình nói rằng "nó gần như hoạt động" thường xuyên hơn bạn mong đợi.

• Đừng tiết kiệm quản lý phần cứng từ xa. Bảng điều khiển nối tiếp và quản lý đèn ra nên được coi là bắt buộc. Điểm thưởng cho các dải năng lượng được điều khiển từ xa cho những lúc bạn không có lựa chọn.

(Ngoài ra: Có hai cách để khắc phục sự cố vào lúc 3 giờ sáng, một cách là làm ấm, làm việc trên máy tính xách tay qua VPN trong bộ đồ ngủ của bạn, cách khác là áo khoác dày và lái xe đến trung tâm dữ liệu/văn phòng. thích hơn.)

Quản lý dự án:

• Thu hút mọi người sẽ duy trì hệ thống từ ngày đầu tiên của vòng đời dự án. Thời gian dẫn đầu về bộ dụng cụ và thời gian não có thể và sẽ gây bất ngờ, và không còn nghi ngờ gì nữa, họ sẽ (nên?) Có các tiêu chuẩn hoặc yêu cầu sẽ trở thành phụ thuộc dự án.

• Tài liệu là một phần của dự án. Bạn sẽ không bao giờ có thời gian để viết toàn bộ sau khi dự án đã bị đóng và hệ thống đã chuyển sang bảo trì, vì vậy hãy đảm bảo rằng đó là nỗ lực trong lịch trình khi bắt đầu.

• Triển khai lỗi thời theo kế hoạch vào dự án từ ngày đầu tiên và bắt đầu chu kỳ làm mới sáu tháng trước ngày tắt mà bạn đã chỉ định trong tài liệu dự án.

Máy chủ có tuổi thọ xác định khi chúng phù hợp để sử dụng trong sản xuất. Sự kết thúc của vòng đời này thường được định nghĩa là bất cứ khi nào nhà cung cấp bắt đầu tính phí bảo trì hàng năm nhiều hơn chi phí để làm mới bộ sản phẩm, hoặc khoảng ba năm, tùy theo thời gian nào ngắn hơn. Sau thời gian này, chúng tuyệt vời cho môi trường phát triển/thử nghiệm, nhưng bạn không nên dựa vào chúng để điều hành doanh nghiệp. Xem xét lại môi trường ở mức 2 năm rưỡi cho bạn nhiều thời gian để vượt qua các vòng quản lý và tài chính cần thiết để đặt hàng bộ mới và thực hiện chuyển đổi suôn sẻ trước khi bạn gửi bộ cũ đến nhà cung cấp lớn trên bầu trời.

Phát triển:

• Đảm bảo sự phát triển và hệ thống dàn của bạn giống với sản xuất. Các kỹ thuật ảo hóa của VM hoặc các kỹ thuật ảo hóa khác (các vùng, LDOM, các trình so sánh) giúp cho việc nhân bản sản xuất trong thế giới thực theo mọi ý nghĩa nhưng hiệu suất dễ dàng.

Sao lưu

• Dữ liệu bạn không sao lưu là dữ liệu bạn không muốn. Đây là một luật bất biến. Hãy chắc chắn rằng thực tế của bạn phù hợp với điều này.

• Sao lưu khó hơn so với vẻ ngoài của chúng; một số tệp sẽ được mở hoặc khóa, trong khi các tệp khác cần được kiểm tra để có bất kỳ hy vọng phục hồi nào và tất cả các vấn đề này cần được giải quyết. Một số gói sao lưu có tác nhân hoặc các phương pháp khác để xử lý các tệp mở/khóa, các gói khác thì không. Việc bỏ các cơ sở dữ liệu vào đĩa và sao lưu các dữ liệu đó được coi là một hình thức "bỏ cuộc", nhưng đó không phải là phương pháp duy nhất.

• Sao lưu là vô giá trị trừ khi chúng được thử nghiệm. Cứ sau vài tháng, hãy rút một cuộn băng ngẫu nhiên ra khỏi kho lưu trữ, đảm bảo rằng nó thực sự có dữ liệu trên đó và dữ liệu phù hợp.

Và quan trọng nhất...

Chọn chế độ thất bại của bạn, hoặc Murphy sẽ ... và Murphy không hoạt động theo lịch trình của bạn.

Thiết kế cho sự thất bại, ghi lại các điểm yếu được thiết kế của mỗi hệ thống, điều gì kích hoạt chúng và cách phục hồi. Nó sẽ làm cho tất cả sự khác biệt khi một cái gì đó không đúng.

Đừng cho rằng nó dễ dàng. Tôi biết nhiều lập trình viên nghĩ rằng chỉ vì họ có thể thiết lập IIS hoặc Apache trên hộp dev mà họ có thể điều hành một trang trại web. Hiểu những gì công việc liên quan và thực hiện nghiên cứu và lập kế hoạch của bạn, đừng ' Bạn chỉ nghĩ rằng công việc sysadmin là điều dễ dàng bạn có thể làm trong 10 phút để ứng dụng của bạn được triển khai.

• Nhận ra rằng, dù tốt hay xấu, nhiều máy chủ và/hoặc thiết bị mạng mà họ có xu hướng rất giống trẻ em trong một gia đình thứ hai. Đây là những đứa con của họ. Họ chăm sóc chúng, giúp đỡ chúng khi chúng bị bệnh và cảnh giác chúng một cách thận trọng khi gặp rắc rối. Điều này không nên theo cách này, nhưng sau nhiều năm, nó thường là . Hãy ghi nhớ điều này khi bạn liên lạc với họ những lo lắng của bạn về thiết bị không hoạt động đúng hoặc không như mong đợi. Và nếu bạn nhận được câu trả lời mà bạn không hiểu, hãy thử lọc nó qua thế giới quan này.
• Hãy làm việc tốt. Nghe có vẻ táo tợn, nhưng nó đáng giá bằng vàng. Một ngày nào đó, bạn sẽ cần một sự ưu ái đặc biệt. Và một ngày nào đó, sysadmin đó sẽ rất vui khi ra khỏi con đường của họ để làm cho cuộc sống của bạn dễ dàng hơn một chút, chỉ một lần này thôi.
• Mối quan hệ làm việc đó đi cả hai chiều. Nếu sysadmin rất bận rộn, và bạn có thể làm cho cuộc sống dễ dàng hơn một chút bằng cách viết một kịch bản hoặc chương trình nhỏ, thì hãy làm điều đó! Họ sẽ đánh giá cao nó hơn bạn biết.
• Hãy thật rõ ràng. "Điều này thật tệ" không rõ ràng như "có một kết nối mạng không liên tục là một chút khó chịu, bất kỳ cơ hội nào bạn có thể nhìn vào nó?"
• Nếu bạn nghĩ ứng dụng của mình sẽ mở rộng quy mô, hãy hỏi quản trị viên trước giả sử nó sẽ hoạt động. Họ có thể "nhìn thấy" thứ gì đó bạn không hoặc biết điều gì đó về giới hạn hiệu suất của thiết bị bạn sẽ triển khai.
• Nếu ứng dụng của bạn cần điều chỉnh, nhưng dường như đó không phải là vấn đề về mã, hãy hỏi độc đáo về cách các máy chủ hoạt động. Sysadmin chăm sóc máy móc của họ với sự quan tâm yêu thương và không hài lòng khi họ "bị bệnh" hoặc "bị hành hạ". Yêu cầu độc đáo sẽ biến một máy ốm yếu (hoặc sửa chữa/thay thế nó).
• (như đã đề cập ở nơi khác) ghi lại các cài đặt bạn sử dụng và tại sao bạn sử dụng chúng. Chỉ cần "đặt hộp kiểm X" hoặc "dòng tệp cấu hình uncomment Y" không giúp ích. Bạn có thể thiết lập tùy chọn xóa tất cả dữ liệu của bạn trong lần khởi động lại tiếp theo cho tất cả những gì bạn biết.
• Nếu bạn không có thời gian để ghi lại cài đặt trên giấy, hãy thử ghi lại nó trong hệ thống nếu có thể. Với các tệp cấu hình, điều này gần như là thông lệ tiêu chuẩn - mọi thay đổi cài đặt sẽ được đánh dấu dữ liệu, với tên viết tắt, hiệu ứng mong đợi của cài đặt đó và lý do tại sao nó đã được thay đổi (xem điểm đạn trước). Thói quen nhỏ này đã cứu thịt xông khói của tôi hơn một lần trong thời gian khủng hoảng. "Tại sao chúng ta làm điều đó?" "Bởi vì chúng tôi bắt buộc chính sách X và cài đặt Y cung cấp cho chúng tôi hành vi chúng tôi cần cho chính sách X".
• Bia. Hoặc Cola. Hoặc thậm chí là Nước. Đồ uống luôn được hoan nghênh. Trở thành một sysadmin là công việc khát.

Bảo mật không phải là một suy nghĩ sau. Mặc dù một ứng dụng bị tấn công có thể khiến lập trình viên trông không đủ năng lực, nhưng (ít nhất) một ngày cuối tuần bị mất đã dành để xác minh, làm sạch và/hoặc khôi phục từ các bản sao lưu cho một sysadmin.

Đối với vấn đề đó, đừng coi các bản sao lưu là kiểm soát phiên bản. Chúng là để phục hồi thảm họa và không thực sự được thiết kế để khôi phục mã của bạn vì bạn đã quên những gì bạn đã thay đổi.

Và ngừng đổ lỗi một cách mù quáng Cập nhật Windows cho mã của bạn bị hỏng. Tôi không quan tâm rằng nó hoạt động đáng tiếc, cho tôi biết tại sao nó không hoạt động bây giờ - sau đó chúng ta có thể thấy đó là lỗi của ai.

Cách gỡ lỗi các sự cố mạng và xem chương trình của bạn chạy bằng các công cụ sysadmin. Là một lập trình viên bắt đầu quản trị hệ thống, tôi ngạc nhiên về việc nhiều lập trình viên bất lực trở thành một khi mạng "chỉ dừng lại".

• Wireshark, để xem mã của bạn chạy theo kiểu hộp đen, từng gói một
• Các công cụ để kết nối trực tiếp với các dịch vụ mạng: [.__.]
  • Telnet, netcat hoặc socat cho các kết nối đơn giản qua TCP hoặc UDP
  • OpenSSL cho cùng một thứ với mã hóa (gợi ý: thử openssl s_client -connect target-Host:port đôi khi), để kết nối thủ công với các dịch vụ mạng
• Dig (trong gói BIND 9) để gỡ lỗi phân giải tên
• Có thể cho biết phần nào của ngăn xếp mạng bị lỗi dựa trên thời gian và các đặc điểm khác của kết nối bị lỗi
• Có thể HTTPFox và/hoặc Fireorms

Biết cách khắc phục sự cố.

Rất dễ dàng để vượt qua sự cố (ví dụ: mạng của bạn đang làm mất liên lạc của tôi với cơ sở dữ liệu). Đó có thể là lỗi của mạng, nhưng bạn nên có nhật ký ứng dụng có lỗi, sử dụng Google hoặc SO, có thể tiết lộ sự cố trong cấu hình của ứng dụng.

Mọi người đều thích đổ lỗi cho phần cứng, hệ điều hành hoặc mạng, vì vậy nếu bạn luyện tập cẩn thận hơn một chút, bạn sẽ biến sysadmin thành một người hạnh phúc. Bởi vì, nếu không có gì khác, bạn có thể chỉ cho họ theo một hướng cụ thể về những gì có thể sai (trái ngược với việc nói "mạng của bạn tệ" hoặc một cái gì đó hữu ích không kém).

Tài liệu mọi thứ bạn có thể. Không thể cho bạn biết bao nhiêu lần sysadmin cuối cùng nghĩ rằng sẽ thật dễ thương nếu không ghi lại một cái gì đó cho 'bảo mật công việc' hoặc ai đó chỉ muốn vào và thoát ra. Giống như một lập trình viên nên để lại bình luận tốt, sysadins nên ghi lại. Một sơ đồ của cấu trúc liên kết cũng sẽ tốt đẹp.

Kế hoạch B.

Luôn có kế hoạch khắc phục thảm họa trong tâm trí khi thiết kế và phát triển giải pháp. Nhận ra những điểm thất bại duy nhất có thể dẫn đến mất điện.

Tài liệu: không cần phải thực hiện, nhưng cách ứng dụng hoạt động, một sơ đồ cho thấy các bit phù hợp như thế nào và cách kiểm tra từng thành phần khi tất cả đều sai. Dữ liệu mẫu và đầu ra là Nice.

Yêu cầu: nó dựa vào mô-đun nào? Phiên bản? HĐH?

Giám sát: các nhà phát triển lý tưởng sẽ bao gồm thông tin giám sát và kiểm tra với ứng dụng.

Nói về bao bì, BAO BÌ! Không có gì tệ hơn một "triển khai" có nghĩa là kiểm tra một bản sửa đổi mới của tệp từ VCS và sao chép nó vào một loạt các máy chủ. Quá thường xuyên, các lập trình viên không đánh giá cao sự phức tạp của việc triển khai phần mềm: có những lý do tại sao phần mềm được đóng gói, phiên bản tạo thành xương sống của hầu hết các hệ điều hành.

Nếu một nhà phát triển đến với tôi với một RPM được cài đặt lần đầu tiên với tài liệu ngắn gọn, toàn diện và một số thử nghiệm Nagios thì họ sẽ là người bạn tốt nhất mới của tôi.

Tôi ngạc nhiên khi không có câu trả lời nào trong số 17 câu trả lời ở đây bao gồm bất cứ điều gì về việc đảm bảo ứng dụng của bạn chạy khi đăng nhập với tư cách là người dùng chuẩn.

Khác với quá trình cài đặt, ứng dụng sẽ chạy tốt khi đăng nhập bằng tài khoản người dùng chuẩn.

• nói chuyện với quản trị viên của bạn cả chính thức và không chính thức về những gì bạn đang làm. Họ thường sẽ quan tâm và có thể thể hiện những tác động có thể có khi sản xuất sớm. Bạn không cần phải đồng ý, nhưng nó giúp xác định các điểm rắc rối.
• Không, bạn không thể có toàn bộ máy chủ cho riêng mình ... Nếu bạn cần, đó là một quyết định chính trị, bất kể nó có âm thanh như thế nào. Nếu bạn muốn làm việc chính trị, hãy đi thẳng.
• Phần cứng sản xuất thường trông khác với máy chủ phát triển của bạn và ngay cả trong các trang trại, thông số kỹ thuật trên máy cũng khác nhau.
• Tìm hiểu cách sản xuất được thiết lập, bởi vì bạn có thể không thể sao chép nó trên máy tính để bàn của mình, làm điều này ngăn bạn đưa ra các giả định kém.
• Chỉ vì bạn có thể lưu trữ nội dung trong bộ nhớ không có nghĩa là bạn nên chờ đợi, trước tiên hãy đợi nút cổ chai (trong kiểm tra đơn vị hoặc kiểm tra hiệu suất trước khi sản xuất)
• nếu bạn đang gắn dữ liệu vào cơ sở dữ liệu, hãy nghĩ về cách bạn có thể chia dữ liệu thành dữ liệu chỉ đọc (có thể được chia tỷ lệ theo chiều ngang) và dữ liệu đọc (thường chỉ chia theo chiều dọc).
• nếu bạn đang gắn dữ liệu vào cơ sở dữ liệu, phải thực sự là RDBMS? có những hệ thống cặp giá trị khóa khác ngoài đó có quy mô tốt hơn (netcache).
• đừng nghĩ AJAX là giải pháp cuối cùng, nó có vẻ hay, nhưng nó giới hạn khả năng giám sát và tự động hóa. Tôi không nói là không sử dụng nó, chỉ cần suy nghĩ hai lần.

OK, điều này hơi đáng chú ý nhưng:

a) Khi mã hóa, giả sử rằng cơ sở hạ tầng cơ bản có thể thất bại và không đến từ đất liền luôn hạnh phúc. Hoặc Google.

b) Chúng tôi có thể không có tài nguyên để thực hiện bất cứ điều gì như cơ sở hạ tầng mà bạn đã đọc, vì vậy hãy làm cho chúng tôi dễ dàng khi mọi thứ đi xuống. Có khả năng chúng ta biết những gì cần phải được thực hiện, nhưng vì lý do gì nó chưa xảy ra. Chúng tôi là đối tác của bạn!

c) Giống như jhs đã nói ở trên, sẽ thực sự hữu ích nếu bạn đã quen với các công cụ để khắc phục sự cố cơ sở hạ tầng, chẳng hạn như ping, traceroute (hoặc kết hợp cả hai - mtr), Dig, v.v. Điểm thưởng lớn cho thậm chí biết về Wireshark.

d) Nếu bạn lập trình một máy tính, bạn thực sự nên biết cách nó kết nối với mạng và những điều cơ bản như có thể phân tích đầu ra của ipconfig/all hoặc ifconfig. Bạn sẽ có thể có được kết nối internet của bạn và chạy với sự giúp đỡ tối thiểu.

Nếu không, tôi nghĩ rằng Avery đã đóng đinh khá nhiều. Những con quỷ làm một ít sysadmin có giá trị trọng lượng của chúng bằng vàng! Nhưng không kém, các sysadins, những người hiểu cách các nhà phát triển về mọi thứ (bao gồm cả phiên bản, v.v.) là rất cần thiết trong thời đại ngày nay.

Điều này dường như đang được phát sóng vào lúc này, tôi đã nhận thấy nhiều cuộc thảo luận về mối quan hệ giữa các nhà phát triển trong blog - hãy xem

Giữ Twitter Twittering

Phân vùng và Chiến tranh

Thử nghiệm đầu tiên trong hoạt động

Sao lưu Sao lưu Sao lưu .... Kiểm tra sao lưu .... Luôn sẵn sàng quay lại

Điều này có thể chỉ áp dụng cho những lập trình viên mới bắt đầu, nhưng tôi giải quyết một vài điều trong mỗi dự án với một số lập trình viên.

1. "Nó hoạt động trên máy của tôi" chưa bao giờ là một tuyên bố hợp lệ. Lập trình viên có trách nhiệm tạo ra một chương trình cài đặt để sử dụng trên máy chủ hoặc ít nhất là ghi lại mọi kết nối và dll và bổ trợ sẽ được yêu cầu trên máy chủ.

2. (Tôi đã nghe điều này nhiều lần, vì vậy xin đừng cười) Tôi chạy exe trên máy chủ từ máy của tôi và nó hoạt động. Nhưng, khi tôi chạy nó trên máy chủ (Citrix, Terminal Server, v.v.) thì nó không hoạt động. Vui lòng hiểu dll's và ocx và bất cứ điều gì khác mà chương trình của bạn yêu cầu và nơi họ đăng ký cũng như cách thức chương trình của bạn sử dụng chúng.

Những điều này có vẻ đơn giản, nhưng tôi đối phó với nó liên tục.

Brian

Rằng không một nhóm hoặc chức năng nào là 'tốt hơn' so với nhóm khác và không ai yêu cầu 'bộ não lớn hơn' so với nhau. Tôi đã thấy cả hai bên đều nhận được sự ưu ái trong công ty của bên kia - tất cả các bạn đều cố gắng đạt được cùng một mục tiêu - tập trung vào những điểm tương đồng này chứ không phải thực tế là bạn sử dụng các công cụ khác nhau.

Kiến trúc sư cơ sở hạ tầng đã trở thành lập trình viên, có thể muốn quay trở lại giao dịch đó trong tương lai :)

1. Nói chuyện với nhau, sớm và thường xuyên. Xem xét thiết kế với những người sẽ quản lý cơ sở hạ tầng, ứng dụng của bạn sẽ được triển khai (nếu bạn biết đó sẽ là ai).
2. Không mất dữ liệu là có thể, nhưng đó là trách nhiệm được chia sẻ bởi các nhà phát triển và hệ thống. Một lần nữa, nói chuyện với nhau có thể giúp đỡ ở đây.
3. Nhân viên cơ sở hạ tầng của bạn nên tham gia vào việc xác định các yêu cầu phi chức năng.
4. Sắp xếp bia (khi công việc đã hoàn thành) và pizza (trong khi chúng tôi đang làm việc). Bằng cách nào đó, sự hiện diện của loại thực phẩm đó ảnh hưởng đến khả năng của chúng tôi để làm cho các hộp cpu 32 nhỏ xinh của chúng tôi làm bất cứ điều gì bạn muốn chúng làm :)

Là một người từng là quản trị viên hệ thống cho các nhà phát triển và là một nhà phát triển, lời khuyên đưa ra ở đây không chỉ là vàng, mà nên là một phần của tài liệu tuyển dụng cho các nhà phát triển mới cho các công ty.

Một điều mà tôi chưa từng thấy (chưa) giải thích là các nhà phát triển thực sự nên biết các sản phẩm mà họ sẽ sử dụng để tạo ra các chương trình mà họ được trả tiền. Số lần tôi phải giải thích và định cấu hình máy chủ Apache, cài đặt Eclipse và Visual Studio và cơ sở dữ liệu trên các máy phát triển là một điều đáng lo ngại.