Là một nhà phát triển, tôi dành phần lớn thời gian để suy nghĩ về mã, giao diện người dùng, cấu trúc dữ liệu, v.v. ứng dụng.
Đầu tiên, tôi xin lỗi. Thứ hai, những gì bạn muốn tôi, và các nhà phát triển khác mà bạn đối phó, sẽ làm khác đi? Điều gì sẽ làm cho cuộc sống của bạn dễ dàng hơn, gây ra ít vấn đề hơn, khuyến khích hợp tác và giảm sự cố, vấn đề về hiệu suất và ác mộng cấu hình?
Câu trả lời:
Hãy nhớ rằng ứng dụng của bạn có thể có nhiều trạng thái hơn lên hoặc xuống. Vẽ sơ đồ trạng thái. Hầu hết các ứng dụng có trạng thái như:
Hãy suy nghĩ về những gì xảy ra nếu hệ thống gặp sự cố trong mỗi trạng thái. Làm thế nào một sysadmin giám sát và kiểm soát chuyển trạng thái?
Phân biệt "người dùng" với SA.
Một "người dùng" cần biết cách sử dụng phần mềm của bạn. Người dùng không quan tâm đến những thứ như cách cài đặt phần mềm của bạn.
SA không quan tâm đến cách sử dụng phần mềm của bạn, nhưng cần biết một số chi tiết quan trọng về cách cài đặt phần mềm.
Viết tài liệu riêng cho từng vai trò đó, bao gồm thông tin liên quan cho từng vai trò đó.
Một trong những mong muốn của tôi là bao gồm các thông điệp thích hợp trong các trường hợp ngoại lệ và mã lỗi. Nó hoàn toàn mờ đục đối với người chưa phát triển ứng dụng JimmyNotAtHomeException: it's late!nghĩa là gì.
Tuy nhiên, một thông điệp như Unable to find jimmy - initial manual call_mother procedurelà rất hữu ích.
Truyền thông, giao tiếp, giao tiếp. Mọi vấn đề giữa một sysadmin và dev có thể luôn luôn bị theo dõi trở lại do thiếu giao tiếp. Nếu trước một dự án, các sysadins (hoặc một đại diện của nó) và các nhà phát triển đã gặp nhau và có một cuộc thảo luận khung tốt, SOOOOOOOOOO có thể tránh được nhiều vấn đề. Tôi không thể cho bạn biết có bao nhiêu thứ bị xử lý vì bạn phát triển tất cả mọi người trên một hộp chỉ để xem nó bị tắt trong prod vì ứng dụng sau đó được phân tách thành Máy chủ ứng dụng + Máy chủ DB + máy chủ giao diện, v.v. Kudos đã đưa chủ đề này lên.
Tham gia với chúng tôi sớm trong dự án. Giống như thực sự sớm, ở giai đoạn đặc tả chức năng.
Một số người khác đề cập đến việc phải cài đặt thủ công trên mọi PC, nhưng áp dụng tương tự cho các thay đổi cấu hình và cấu hình. Nếu bạn chọn lưu trữ thứ gì đó như kết nối chuỗi khách hàng và cần cập nhật chúng thường xuyên, có lẽ chúng tôi sẽ muốn giết bạn .
Chọn công nghệ có thể được quản lý và cấu hình tập trung đúng cách, vì lý do rất giống nhau. Hãy chắc chắn rằng nó tích hợp tốt với bất kỳ công cụ quản lý trung tâm nào chúng tôi sử dụng.
Luôn kiểm tra bằng mẫu số chung thấp nhất. Điều đó có nghĩa là không phải là Quản trị viên, trên hệ điều hành nguyên thủy nhất, bộ ứng dụng và trình duyệt được sử dụng phổ biến. Chúng tôi không muốn có một bản nâng cấp trình duyệt cần thiết cho tất cả người dùng của chúng tôi đã đến với chúng tôi vào phút cuối có thể.
Đừng nhảy để đổ lỗi cho chúng tôi khi mọi thứ đi sai. Trong công việc cũ của tôi mỗi khi một ứng dụng bị hỏng, các nhà phát triển sẽ lập tức chỉ tay vào chúng tôi. "Bạn đã cài đặt một bản vá mới, bạn sẽ không nâng cấp trình duyệt, bảo mật của bạn quá chặt chẽ" hoặc bất cứ điều gì. Điều này tạo ra một bầu không khí hủy diệt. Chúng tôi ở cùng một phía, thực sự, và chúng tôi muốn hợp tác với bạn để khắc phục nó, nhưng chúng tôi không thể trong những trường hợp như vậy.
Đừng là người ưu tú.
"Đừng lãng phí thời gian của tôi, anh bạn. Bạn chỉ là một con chó nhỏ, tôi viết phần mềm và bạn chỉ phục vụ nó. Vì vậy, hãy im lặng với những mối quan tâm nhỏ nhặt của bạn và làm như tôi nói, OK?"
Một nhà phát triển thực sự đã nói những lời đó với tôi một lần (1). Trong email. CC'd cho một nhóm phân phối lớn. Hàm ý rất rõ ràng: là một nhà phát triển, ông là chúa tể và là chủ nhân của toàn bộ vũ trụ phần mềm; và tôi chỉ đơn giản là một người làm việc ban ngày được thuê để giải quyết các công việc quá tầm thường để anh ta lãng phí thời gian quý báu của mình. Tất nhiên đây là một ví dụ gần như tồi tệ nhất, nhưng bạn biết đấy, tôi đã nghe thấy tiếng vang mạnh mẽ và yếu ớt của nhận xét đó từ một số nhà phát triển cả trước và kể từ (2).
Bạn có thể kiếm được nhiều tiền hơn tôi (nhưng đừng cho là vậy!). Nhưng phải có một nhóm để xây dựng, vận hành và bảo trì các hệ thống mà người dùng của chúng tôi dựa vào. Cuối cùng tất cả chúng ta phục vụ họ.
Tôi hiểu rằng công việc của bạn và kỹ năng của bạn khác với tôi. Tôi tôn trọng khả năng của bạn. Tôi hy vọng bạn sẽ trả lời câu hỏi của tôi ngay cả khi chúng có vẻ sơ đẳng và ngu ngốc đối với bạn. Tôi sẽ vui vẻ trở lại lịch sự này!
Tôi không phải là một chuyến đi quyền lực điên rồ, vì rất nhiều nhà phát triển xấu (hoặc đơn giản là không quan tâm) đã nói và suy nghĩ và đăng trên các diễn đàn khác nhau. Nhưng mối quan tâm của tôi khác với bạn, và những câu hỏi và đề xuất của tôi không phục vụ cho cái tôi của tôi. Thật vậy, công việc của tôi là làm cho bạn trông đẹp hơn, bằng cách giữ cho các ứng dụng của bạn luôn ở trạng thái chạy tốt nhất, có sẵn và đáp ứng cho tất cả người dùng. Để làm điều đó, tôi phải giữ phần còn lại của mạng và các hệ thống cũng chạy theo hình dạng đỉnh.
Tôi hoàn toàn biết rằng bạn đã gặp phải những quản trị viên ngu ngốc, điên rồ và / hoặc chỉ đơn giản là lười biếng trong quá khứ. Tôi đang cố gắng không trở thành một và không giống ai. Nếu bạn rời khỏi phòng vì khả năng này và thừa nhận nó khi bạn nhìn thấy nó, tôi khá chắc chắn rằng bạn sẽ nhận được những gì bạn cần trong khi những tên khốn kia vẫn đang loay hoay về cái lỗ đít của họ là gì.
(1) Ông cũng khẳng định rằng chương trình của mình (một công cụ để viết và quản lý các yêu cầu phần mềm) cần có đặc quyền quản trị viên tên miền để cài đặt và chạy. Đó là một rủi ro an ninh lớn .
(2) Tôi cũng đã làm việc với nhiều nhà phát triển tuyệt vời, những người có thể dạy khi cần thiết và học khi cần thiết.
Tôn trọng rằng các sysadins có một công việc phải làm, và để họ làm công việc của họ. Rất nhiều công ty có sysadins bất tài và điều này thường không thực tế. Nhưng tôi đã thấy các nhà phát triển kiêu ngạo bỏ qua lời khuyên của các nhóm hệ thống ngay cả sau khi các hệ thống đã chứng minh được năng lực của họ.
Thảo luận về thiết kế của một hệ thống mới với sysadmin. Thường có cái nhìn sâu sắc có giá trị. Các nhà phát triển thường xem các cuộc thảo luận với sysadins và đưa ra các yêu cầu ban đầu là "tối ưu hóa sớm". Tôi thực sự đã thấy người đứng đầu một nhóm phát triển nói rằng thật lãng phí thời gian của mình khi thảo luận các yêu cầu đối với các máy chủ cơ sở dữ liệu mới với sysadins và DBA, thậm chí đến mức mô tả xem đó là tải nặng hay đọc sâu, hay cần bao nhiêu dung lượng
Thảo luận về các vấn đề hiệu suất với sysadmin. Thành thật chỉ có sysadins có khả năng diễn giải chính xác các số liệu hiệu suất trên các hệ thống. Tôi đã thấy các nhà phát triển quyết định rằng Linux luôn rò rỉ bộ nhớ vì bộ nhớ miễn phí được báo cáo bởi "miễn phí" luôn giảm, ngay cả sau lần thứ 10, đầu ra của "miễn phí" được giải thích.
Đừng đưa ra kết luận mà không thảo luận với sysadmin. Tôi đã thấy các nhà phát triển bị mắc kẹt trên các lý thuyết như "cơ sở dữ liệu luôn ở dạng đĩa" (họ không biết rằng iuler thậm chí còn tồn tại), "RAID 5 nhanh hơn cho khối lượng công việc giao dịch" (dựa trên hồi ức của một hệ thống cơ sở dữ liệu đã được di chuyển từ nền tảng phần cứng này sang nền tảng khác - đó là khối lượng công việc chuyên sâu, giải pháp RAID5 có nhiều ổ đĩa nhanh hơn và trải rộng trên nhiều bộ điều khiển hơn. Nhưng họ đã quên những chi tiết này và chỉ nhớ kết luận.)
Đừng thiết kế một giải pháp cho một vấn đề hệ thống mà không thảo luận về nó với sysadins. Tôi đã làm việc trong một môi trường bệnh lý nơi các nhà phát triển sẽ thiết kế một giải pháp và yêu cầu hỗ trợ thực hiện nhỏ. Các thành viên của nhóm Unix ngoài tôi, người đứng đầu nhóm Unix và ông chủ của anh ta, muốn coi các nhà phát triển là "khách hàng", chứ không phải là đồng nghiệp đang cố gắng tạo ra một chức năng cơ sở hạ tầng tổng thể. Khách hàng luôn luôn đúng có nghĩa là không đặt câu hỏi về những gì họ đang làm hoặc tại sao. Tôi là người duy nhất khăng khăng muốn có vấn đề được mô tả để có thể xác định được giải pháp chính xác. Đừng hành động theo những cách tạo ra môi trường bệnh lý như thế này. Nó không mang lại lợi ích ròng - thay vào đó, các nhà quản lý hệ thống sẽ hành động phòng thủ và mọi người sẽ phải chịu đựng.
Bạn không còn đi học nữa. Đây là những hệ thống trong thế giới thực và chúng không hoạt động một cách lý tưởng. Ví dụ, không phải mọi thứ đều có độ trễ bằng không. Khi một sysadmin cảnh báo bạn rằng các giải pháp phân cụm chỉ dành cho mục đích chính trị và sự phức tạp thêm vào của hệ thống làm giảm độ tin cậy tổng thể, hãy nghiêm túc thực hiện. Bạn phải thiết kế cho các chế độ thất bại trong thế giới thực, ví dụ khi bạn mất máy chủ mà bạn đang nói chuyện qua TCP, kết nối có thể sẽ không được đặt lại cho bạn. Sysadmin hiểu các chế độ thất bại trong thế giới thực.
Hãy lắng nghe những gì hệ thống của bạn nói với bạn, hoặc phàn nàn với ban quản lý rằng các hệ thống của bạn không đủ năng lực và cần phải bị sa thải. Bỏ qua sysadmin của bạn không có ý nghĩa.
Xem xét cách bạn sẽ triển khai ứng dụng của bạn. Nhận ra rằng thảo luận điều này với sysadmin của bạn có ý nghĩa. Nếu bạn có 100 máy chủ giống hệt nhau, chỉ khác nhau dựa trên một tệp cấu hình duy nhất, bạn có thể muốn xem xét việc lưu trữ các bản sao chính của các tệp cấu hình này ở một vị trí trung tâm. Nhận ra mọi người sẽ tốt hơn bao nhiêu nếu ứng dụng của bạn dễ dàng triển khai lại. Nếu có sự cố với hệ thống, bạn có muốn triển khai lại dưới một phút để dự phòng không, hoặc đợi lâu trong khi hệ thống bị hỏng được sửa chữa? Nếu bạn có thể triển khai lại ứng dụng của mình, HĐH có thể được nâng cấp dễ dàng và an toàn hơn. Bạn có thể quan tâm về điều này trong tương lai.
Nếu bạn gặp sự cố mà bạn nghĩ có thể là do HĐH, hãy gọi ngay cho sysadmin để kiểm tra. Nhưng sau khi một cuộc điều tra chữ thảo cho thấy không có gì, bạn có nhiệm vụ phải giải thích vấn đề.
Hiểu rằng có một sự khác biệt giữa "trả lời chậm" và "không trả lời gì cả".
Định cấu hình và sắp xếp mọi thứ theo cách có thể dự đoán được bằng các cách có thể dự đoán để thay đổi chúng cho HĐH mà bạn đang phát triển. Điều này có nghĩa là tất cả mọi thứ. Ví dụ: OpenLDAP có một cách kỳ lạ để thực hiện loglevels; một số máy chủ IMAP nhất định thậm chí không có tệp cấu hình nhưng phải có các tùy chọn được biên dịch; một số gói muốn nội dung của chúng nằm trong một đường dẫn thư mục cụ thể, chắc chắn sẽ phá vỡ các quy ước của một hệ điều hành cụ thể. Tất cả những điều này nổi bật như mụn cóc trên các cấu hình thông thường của tôi.
Đó là một quy tắc chung, nhưng đừng cho rằng bạn đặc biệt, và do đó may mắn phá vỡ các quy ước chung về cách các gói phần mềm thường hoạt động trên nền tảng của bạn, trừ khi có một lý do rất tốt vốn có cho phần mềm của bạn yêu cầu nó. "Tôi thực sự cảm thấy điều này nên như vậy" không đủ tốt để phá vỡ thiết lập thông thường của mọi người; nó phải là một lý do kết nối với chức năng mà phần mềm của bạn đang cố gắng thực hiện.
Khi có các liên lạc giữa các máy chủ liên quan đến ứng dụng, vui lòng bao gồm ít nhất một sysadmin trong giai đoạn thiết kế. Ngoài ra, ghi lại rõ ràng sự phụ thuộc vào các dịch vụ khác: SQL, SMTP, HTTP, v.v ... Đừng khiến chúng tôi đoán bạn đang làm gì hoặc chúng tôi không thể giúp bạn khi có điều gì đó không hoạt động như bạn mong đợi.
Vui lòng cho phép triển khai phần mềm của bạn trên hàng chục hoặc hàng trăm hệ thống theo cách tự động. Nếu một tổ chức cần một gói phần mềm, sysadins gần như chắc chắn không có thời gian để cài đặt thủ công trên mỗi hộp. Nếu một tập tin cần phải có thông tin cấp phép, ghi lại cách cung cấp nó sẽ là một lợi ích lớn.
Adobe trong lịch sử đã có một số trình cài đặt là một nỗi đau thực sự để làm việc với ; Hãy nhắm cao hơn thế!
Hãy suy nghĩ về việc nhân rộng từ ngày đầu tiên. Sysadmin có thể làm nên điều kỳ diệu bằng cách ném tiền / phần cứng vào một vấn đề về hiệu năng nhưng đôi khi không có số tiền nào trong số này sẽ giúp ích - đặc biệt là nghĩ về việc khóa - đôi khi bạn không thể tự mua được vấn đề khóa. Cảm ơn đã hỏi mặc dù :)
Oh và cố gắng là 64-bit nếu có thể, và đa luồng cũng vậy :)
Thiết kế cho các hoạt động.
Ngoài mọi thứ khác ở đây ...
Mặc dù không thực tế nhưng sẽ rất hữu ích nếu các nhà phát triển buộc phải làm việc trong vai trò sản xuất sysadmin hoặc dba trước khi bị thả lỏng trên thế giới.
Vì vậy, nhiều ứng dụng chuyên dụng mà tôi xử lý không có manh mối nào về việc cài đặt trong môi trường được quản lý hoặc cam kết sự tàn bạo của thiết kế cơ sở dữ liệu.
Cuốn sách phát hành nó! có một lựa chọn tốt đẹp của những câu chuyện kinh dị về những gì có thể đi sai trong sản xuất. Đọc nó có thể cung cấp nguồn cảm hứng / ý tưởng để thiết kế với các hoạt động trong tâm trí. (Nó được viết bởi Michael Nygard, người đã làm việc ở cả hai khía cạnh phát triển và hoạt động.)
Theo kinh nghiệm của tôi, điều sẽ tạo ra sự khác biệt nhất là nếu các nhà phát triển sẽ nghĩ về việc triển khai từ ngày 1. Ngay khi bạn bắt đầu hình thành một tính năng mới trong môi trường sản xuất / khách hàng, hãy bắt đầu nghĩ về cách nó sẽ được triển khai vào đó. môi trường, và nó sẽ chạy như thế nào
Một khi họ tham gia vào quá trình phát triển, sẽ không quá muộn, nhưng có thể mất một thời gian trước khi họ có thể thay đổi quan điểm của mình đến mức đó; họ không nhận ra họ đang xem codebase một cách trừu tượng như thế nào cho đến khi buộc phải đối đầu với nó. Trong tâm trí của họ, nó chỉ là một "thành phần". Quan tâm đặc biệt là làm thế nào nó sẽ được triển khai vào một môi trường có sẵn , chạy phiên bản phần mềm trước đó (hoặc cũ hơn!). Các cuộc thảo luận triển khai có thể có tác động đáng kể đến cách điều chỉnh kiến trúc để phù hợp với tính năng mới.
Một cái gì đó tôi thích mà tôi chưa thấy là Cấu hình. Nếu bạn có một ứng dụng sử dụng bất kỳ loại tệp cấu hình nào, hãy đặt mọi thứ có thể định cấu hình.
Tại công ty của tôi, tôi đã viết một ứng dụng đơn giản sẽ xuất một phần cơ sở dữ liệu. Tuần sau tôi đã viết lại nó để cho phép một phần nhỏ được tắt. Mỗi tuần kể từ đó tôi phải viết lại các phần và xây dựng lại nó chỉ để thay đổi một tính năng nhỏ. Tôi chỉ vừa mới thêm một tập tin cấu hình xml, và bây giờ nó dễ dàng hơn để triển khai lại.
Tôi yêu tập tin cấu hình.
Tôi ước rằng các nhà phát triển sẽ tách biệt tốt hơn khỏi các nhiệm vụ QA. Tôi nghĩ rằng thật tuyệt khi nhà phát triển có thể tạo một số trường hợp thử nghiệm đơn vị cho một dự án mà anh ấy / cô ấy đang thực hiện nhưng thật tuyệt nếu những thử nghiệm đó được chuyển cho QA. Trên thực tế, thật tuyệt khi các nhà phát triển cung cấp một chút trợ giúp cho các kỹ sư QA vì cuối cùng nó mang lại lợi ích cho DEV.
Hãy chắc chắn rằng nó có thể hỗ trợ: ngoài mọi thứ khác được đề cập ở đây, hãy xem bài đăng này trên SO - https://stackoverflow.com/questions/205374/what-are-the-core-elements-to-include-in-support- tài liệu/