Là một lập trình viên, chúng ta có xu hướng sử dụng sysadmin. Vài lần tôi không có một sysadmin tốt đã thực sự khiến tôi đánh giá cao những gì các bạn làm. Khi chúng ta mạo hiểm vào một môi trường không có sysadmin, bạn có thể cung cấp cho chúng ta những lời khôn ngoan nào?
Câu trả lời:
Tôi sẽ bắt đầu với:
<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:
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ì đó sẽ 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" Việc 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.
. thích hơn.)
Quản lý dự án:
Thu hút mọi người sẽ bảo 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 mua bộ công cụ 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:
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 đó là một dạng "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ể chạy 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 nghĩ rằng công việc sysadmin là điều dễ dàng bạn có thể làm trong 10 phút để triển khai ứng dụng của mình.
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 rất 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".
openssl s_client -connect target-host:portthỉnh thoảng thử ), để kết nối thủ công với các dịch vụ mạngBiế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 thật 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.
Tài liệu: không cần phải chạy, 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à tốt đẹp.
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 là "triển khai", nghĩa là kiểm tra 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ố bài kiểm tra Nagios thì họ sẽ là người bạn tốt nhất mới của tô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.
"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ủ.
(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 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 và cách thức đăng ký cũng như cách 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
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 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), đào, v.v.
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 khá nhiều đóng đinh nó. 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
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 :)
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 trên toàn.
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 nhật thực và Visual Studio và cơ sở dữ liệu trên các máy của nhà phát triển là một điều đáng lo ngại.