Làm thế nào các bạn nhỏ có thể học và sử dụng hiệu quả Puppet? [đóng cửa]

Sáu tháng trước, trong dự án phi lợi nhuận của chúng tôi, chúng tôi đã quyết định bắt đầu chuyển quản lý hệ thống sang môi trường do Puppet kiểm soát vì chúng tôi hy vọng số lượng máy chủ của chúng tôi sẽ tăng đáng kể từ nay đến một năm kể từ bây giờ.

Kể từ khi quyết định được đưa ra, các anh chàng IT của chúng tôi đã trở nên hơi khó chịu một chút quá thường xuyên. Phản đối lớn nhất của họ là:

• "Chúng tôi không phải là lập trình viên, chúng tôi là sysadins";
• Các mô-đun có sẵn trực tuyến nhưng nhiều khác nhau; bánh xe đang được phát minh lại quá thường xuyên, làm thế nào để bạn quyết định cái nào phù hợp với hóa đơn;
• Mã trong repo của chúng tôi không đủ minh bạch, để tìm ra cách thức hoạt động của một cái gì đó mà họ phải lặp lại thông qua các bảng kê khai và mô-đun mà họ có thể đã tự viết cách đây một thời gian;
• Một daemon mới yêu cầu viết một mô-đun mới, các quy ước phải tương tự như các mô-đun khác, một quá trình khó khăn;
• "Hãy chạy nó và xem nó hoạt động như thế nào"
• Hàng tấn 'phần mở rộng' hầu như không được biết đến trong các mô-đun cộng đồng: 'trocla', 'augeas', 'hiera' ... làm thế nào các hệ thống của chúng tôi có thể theo dõi?

Tôi có thể thấy lý do tại sao một tổ chức lớn sẽ gửi các sysadins của họ đến các khóa học múa rối để trở thành bậc thầy múa rối. Nhưng làm thế nào những người chơi nhỏ hơn có thể học Puppet đến một mức độ chuyên nghiệp nếu họ không tham gia các khóa học và về cơ bản học nó thông qua trình duyệt và trình soạn thảo của họ?

Tôi bắt đầu sử dụng Puppet trước khi triển khai một cơ sở hạ tầng mới và chỉ cần mua một cuốn sách ( được đánh giá cao ) về chủ đề này. Tôi không nghĩ rằng hầu hết mọi người thực sự có được đào tạo múa rối chuyên nghiệp. Tôi đã làm việc trên các ví dụ cho đến khi tôi có thể tạo ra quy trình cho môi trường của mình. Đây là tháng 12 năm 2011, vì vậy trong vài tuần, tôi đã có thể hiểu những điều cơ bản và có được một khung sản xuất. Tôi không phải là người mới trong quản lý cấu hình, có nền tảng CFEngine , nhưng nhiều mối quan tâm về hệ thống của bạn đã tạo ra tiếng vang. Tôi đã phạm sai lầm và phải tái cấu trúc nhiều lần, nhưng tôi đã làm mọi thứ hoạt động ổn thỏa.

Một vài lưu ý về quan điểm của bạn ...

• Vai trò quản trị hệ thống truyền thống đang thay đổi. Thích nghi hoặc bị bỏ lại phía sau. Tôi đã từng là một kỹ sư hệ thống thành công, nhưng tôi cũng phải trang bị lại (ví dụ như học Python). Sự tập trung vào các máy chủ riêng lẻ bị giảm đi khi sự trừu tượng hóa phần cứng thông qua ảo hóa và các dịch vụ đám mây công cộng và riêng tư có được lực kéo. Điều này có nghĩa là tự động hóa các tác vụ hệ thống và sử dụng quản lý cấu hình để giành quyền kiểm soát số lượng máy chủ lớn hơn. Thêm các khái niệm DevOps vào hỗn hợp và bạn sẽ thấy rằng các yêu cầu và yêu cầu của khách hàng / người dùng cuối đang thay đổi.

• Các mô đun con rối có sẵn trực tuyến khác nhau về kiểu dáng và cấu trúc và vâng, tôi đã thấy rất nhiều sự chồng chéo, dư thừa và các nỗ lực trùng lặp. Một nhà phát triển tôi đã làm việc cùng nói, "bạn có thể đã phát triển các công cụ của riêng mình trong thời gian bạn tìm kiếm trực tuyến cho một cái gì đó hoạt động!" Điều đó khiến tôi tạm dừng khi tôi nhận ra rằng Puppet dường như thu hút nhiều loại nhà phát triển hơn là quản trị viên đang tìm kiếm một cách thực hành tốt nhất hoặc cách tiếp cận đúng đắn .

• Tài liệu rất nhiều để có được một cảm giác về cách mọi thứ được kết nối. Với các định nghĩa run rẩy và thiếu một cách làm việc tiêu chuẩn , cấu trúc quản lý cấu hình của bạn thực sự là duy nhất cho môi trường của bạn. Sự minh bạch đó sẽ phải được phát triển trong.

• Tôi cho rằng việc sao chép mô-đun một cách hợp lý để chứa một daemon mới hoặc thêm một dịch vụ vào một bảng kê khai hiện có, tùy thuộc vào cách bạn tổ chức các máy chủ và vai trò của mình.

• Tôi đã dành rất nhiều thời gian để thử nghiệm trên một mục tiêu duy nhất trước khi đẩy các thay đổi sang các nhóm máy chủ lớn hơn. Chạy rối bằng tay trên một máy chủ đại diện cho phép tôi gỡ lỗi các thay đổi và đánh giá tác động của chúng. Có lẽ đó là một chút bảo thủ, nhưng nó là cần thiết.

• Tôi không chắc chắn bao nhiêu tôi phụ thuộc vào các mô-đun cộng đồng. Tôi đã phải bắt đầu sử dụng Augeas cho một số công việc , và than thở rằng đó là chức năng tôi đã được cấp trong CFEngine.

Nói chung, tôi cảm thấy như không có một tiêu chuẩn nào được xác định rõ khi nói đến Puppet. Tôi gặp khó khăn khi tìm cách tổ chức cấu trúc thư mục trên Puppetmaster của mình, hiểu cách quản lý ký chứng chỉ, nhận DNS ngược phù hợp ở mọi nơi, để Puppet mở rộng quy mô phù hợp với môi trường và hiểu khi nào nên tận dụng các mô-đun cộng đồng so với xây dựng mô-đun của riêng tôi. Đó là một sự thay đổi trong suy nghĩ và tôi thấy điều đó sẽ khiến một sysadmin hoảng loạn như thế nào. Tuy nhiên, đây cũng là giải pháp được xây dựng từ đầu, vì vậy tôi có sự sang trọng trong việc đánh giá các công cụ. Quyết định đi theo con đường này dựa trên tư duy và động lực đằng sau Con rối. Đó là giá trị nỗ lực để học một cái gì đó mới.

Hãy nhớ rằng, trang web này là một tài nguyên tốt, quá.

Trong một công việc trước đây, tôi được giao nhiệm vụ thực hiện thí điểm Con rối. Bây giờ, tôi có nền tảng lập trình, mặc dù không phải là Ruby, vì vậy tôi không gặp nhiều vấn đề như những người khác.

Tuy nhiên, thật thú vị khi lưu ý rằng các lập trình viên không có kinh nghiệm với các mô hình phi truyền thống cũng có vấn đề với Puppet, bởi vì Puppet là khai báo , không bắt buộc. Theo nghĩa này, Puppet hoạt động khá giống với bất kỳ tệp cấu hình nào: bạn nói mọi thứ sẽ như thế nào và Puppet sẽ chăm sóc phần còn lại.

Sau phi công, tôi có cơ hội đào tạo hàng tá quản trị viên khác với Puppet, cộng với việc thuyết trình về nó trong hai sự kiện. Tôi rút ra được kinh nghiệm đó là một số quản trị viên đã tham gia và một số thì không. Đây đều là những quản trị viên truyền thống, không có kỹ năng lập trình và trình độ chuyên môn khác nhau.

Một điều đặc biệt tôi nhận thấy là Puppet đòi hỏi phải thực hành liên tục . Những người được đào tạo, viết các mô-đun, và sau đó dành cả một hoặc hai tháng để làm một việc khác đã trở lại với Puppet với một chút kỹ năng hữu ích. Những người tiếp tục làm những việc nhỏ trong đó mỗi tuần không bao giờ mất khả năng.

Dựa trên hai quan sát này, tôi khuyên bạn nên đảm bảo mọi người tiếp tục thêm một số lớp Puppet, định nghĩa hoặc mô-đun mỗi tuần (tốt nhất là ít nhất hai hoặc ba lần). Những người vẫn không thể quen với nó có thể thực sự thiếu kỹ năng để làm điều đó.

Sau đó, một lần nữa, nếu Puppet bị áp đặt lên họ từ cấp cao hơn, họ có thể chỉ đơn giản là phản ứng với những gì họ cho là quản lý xâm nhập vào cách họ làm công việc của họ - thực tế là đủ. Nó có thể là trường hợp đó để họ chọn mà hệ thống quản lý cấu hình để sử dụng sẽ cải thiện tình hình. Đây là một số lựa chọn:

• TRẢ LỜI : Đây là một tính năng mới, nhưng nó dựa trên các lệnh shell và ssh, có thể lôi kéo nó vào các sysadins truyền thống.
• Đầu bếp : Có lẽ vấn đề của họ là phong cách khai báo, trong trường hợp đó, Đầu bếp sẽ tốt hơn nếu họ có kinh nghiệm về Ruby.
• SaltStack : Dựa trên Python và mã nguồn mở
• CFEngine : cũ, nhanh, truyền thống - nó có thể chiến thắng họ trên cơ sở đó.

Tôi đã sử dụng Puppet hơn hai năm trong các cửa hàng nhỏ nơi tôi là sysadmin duy nhất. Rào cản lớn nhất mà tôi gặp phải là học cách phát triển phần mềm đúng cách. Đã có một tuần trôi qua mà tôi đã không làm hỏng điều gì đó mà tôi đã nói với các nhà phát triển không được thực hiện hàng chục lần. Tôi đã kiểm tra quá nhiều mã, tôi không phá vỡ các đăng ký, tôi không gắn thẻ, tôi không phân nhánh, không chạy trình kiểm tra cú pháp, không sử dụng một tiêu chuẩn, v.v. Nếu bạn chỉ mới bắt đầu Tôi muốn giới thiệu một số điều sau đây.

1. Nhận ra bạn đang phát triển phần mềm mà bạn không biết cách làm hoặc đang làm kém. Điều này được mong đợi bởi vì nó mới.
2. Cơ sở hạ tầng dưới dạng mã là thực tế và một khi bạn vượt qua được cái bướu thì nó khá mạnh. Tôi muốn mời một số nhà phát triển, cho họ thấy quy trình phát triển hiện tại của bạn (hoặc thiếu nó), không xúc phạm khi họ nhướn mày và nghiêm túc thực hiện các đề xuất của họ. Tôi khuyên bạn nên sử dụng bất kỳ hệ thống nào và xử lý các nhà phát triển của bạn sử dụng trừ khi nó hoàn toàn không phù hợp.
3. Các mô-đun bên thứ ba rối hút 90% thời gian. Tôi đã đọc chúng. Tôi đã ăn cắp ý tưởng từ họ. Tôi sẽ không kéo chúng vào hệ thống của mình mà không chỉnh sửa lớn. Tuy nhiên tôi sẽ kéo vào stdlib con rối có thêm một số chức năng hay.
4. augeas và hiera. Học hai cái đó. Việc đầu tiên cho phép chỉnh sửa phức tạp các tập tin hiện có tại chỗ. Thứ hai là một cửa hàng dữ liệu bên ngoài.
5. Mã riêng biệt từ dữ liệu. Đây là một trong những khái niệm khó học hơn. Các giá trị mã hóa cứng như Giám sát máy chủ vào mã mô-đun của bạn là xấu. Đưa chúng vào kho lưu trữ dữ liệu (db, yaml (Hiera sử dụng mặc định này), csv, bất cứ điều gì) mà các mô-đun của bạn có thể tiêu thụ là tốt. Một ví dụ là một ứng dụng web sử dụng Mysql. Điều này cho phép là khả năng đẩy mã và dữ liệu riêng biệt. Điều này làm cho quá trình phát triển của bạn đơn giản hơn.
6. trình phân tích cú pháp xác nhận và xác nhận rối như là một phần của quy trình kiểm tra mã trước hoặc sau mã của bạn. Ngoài ra các bài kiểm tra rspec có thể là một ý tưởng tốt khi bạn tăng tốc.
7. viết một hướng dẫn phong cách / tiêu chuẩn mã và sử dụng nó. "mã cài đặt Apache ở đâu" là một vấn đề phổ biến. Nếu các mô-đun của bạn là giống nhau, nó sẽ dễ dàng.

Tóm lại, tôi đã gặp phải tất cả những vấn đề này và hầu hết những người bạn sysadmin của tôi cũng vậy. Sẽ mất một chút thời gian để sử dụng tốt hệ thống quản lý cấu hình. Một khi bạn làm bạn sẽ tự hỏi làm thế nào bạn sống mà không có một. "Đăng nhập vào máy chủ và thực hiện thay đổi bằng tay? Ick."

Sáu tháng trước, trong dự án phi lợi nhuận của chúng tôi, chúng tôi đã quyết định bắt đầu chuyển quản lý hệ thống sang môi trường do Puppet kiểm soát vì chúng tôi hy vọng số lượng máy chủ của chúng tôi sẽ tăng đáng kể từ nay đến một năm kể từ bây giờ.

Nghe có vẻ là một ý tưởng hay để bắt đầu sớm - Puppet không chỉ là quản lý cấu hình, nó là một dạng tài liệu.

Kể từ khi quyết định được đưa ra, các anh chàng IT của chúng tôi đã trở nên hơi khó chịu một chút quá thường xuyên.

Họ cần một sự điều chỉnh thái độ.

"We're not programmers, we're sysadmins";

Một lần nữa, thái độ. Bạn -can- tạo một tập tin conf cho một máy chủ phải không? Bạn có thể dễ dàng tham gia vào công cụ templating / 'lập trình viên khi nhu cầu và sự phức tạp của bạn phát triển .

Các mô-đun có sẵn trực tuyến nhưng nhiều khác nhau; bánh xe đang được phát minh lại quá thường xuyên, làm thế nào để bạn quyết định cái nào phù hợp với hóa đơn;

Khó khăn để trả lời - Tôi luôn thích các mô-đun con rối hơn hầu hết - và ngay cả ở đó, tôi không sử dụng nhiều mô-đun đó. Phán quyết gọi cho chắc chắn. Theo tôi, một số mô-đun 'quá rườm rà'.

Mã trong repo của chúng tôi không đủ minh bạch, để tìm ra cách thức hoạt động của một cái gì đó mà họ phải lặp lại thông qua các bảng kê khai và mô-đun mà họ có thể đã tự viết cách đây một thời gian;

Điều này không giống như một vấn đề rối, nhưng vấn đề về tổ chức hoặc tài liệu nhiều hơn?

Một daemon mới yêu cầu viết một mô-đun mới, các quy ước phải tương tự như các mô-đun khác, một quá trình khó khăn;

Daemon đó có thể là một lớp nếu nó đủ đơn giản để quản lý. Tôi không chắc ý của bạn là gì bởi các quy ước, con rối thực thi các quy ước đối với bạn khá tốt phải không? Hay chúng ta đang nói dọc theo dòng định dạng mã?

"Let's just run it and see how it works"

Không phải là xấu của một ý tưởng nếu bạn thực hiện nó chậm và an toàn. Tôi vẫn bắt đầu với một VM để có được ý chính.

Hàng tấn 'phần mở rộng' hầu như không được biết đến trong các mô-đun cộng đồng: 'trocla', 'augeas', 'hiera' ... làm thế nào các hệ thống của chúng tôi có thể theo dõi?

postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, perl module .. Chọn những gì bạn muốn và sử dụng nó? Tôi đoán âm thanh này giống như một thái độ một lần nữa ...

Tôi có thể thấy lý do tại sao một tổ chức lớn sẽ gửi các sysadins của họ đến các khóa học múa rối để trở thành bậc thầy múa rối. Nhưng làm thế nào những người chơi nhỏ hơn có thể học Puppet đến một mức độ chuyên nghiệp nếu họ không tham gia các khóa học và về cơ bản học nó thông qua trình duyệt và trình soạn thảo của họ?

Tôi chưa tham gia bất kỳ khóa học nào - trong khi tôi là một lập trình viên nhiều hơn một sysadmin, tôi thấy rằng nó không cần nhiều kỹ năng lập trình để đạt được bất cứ điều gì.

Các tài liệu rối, khi làm theo là khá kỹ lưỡng. Chỉ cần chú ý đến các loại tích hợp và dành thời gian xem xét các mô-đun khác được kết hợp với nhau như thế nào. Tôi sẽ không nói rằng nó - dễ dàng, nhưng nó cũng không - dù vậy. Sẽ hơi tốn thời gian để cơ sở hạ tầng của bạn sẵn sàng cho con rối, nhưng thời gian đầu tư được đảm bảo sẽ được chi tiêu tốt khi bạn mở rộng.

KISS (Giữ cho nó đơn giản ngu ngốc) - Đừng sử dụng các công nghệ mới chỉ vì chúng ở đó vì bạn có yêu cầu đối với chúng, hãy sử dụng mức tối thiểu mà việc triển khai của bạn yêu cầu, cập nhật theo yêu cầu đừng cố gắng theo kịp sự chảy máu cạnh. Nếu bạn bắt đầu với một thiết lập cơ bản và dựa trên đó thì việc lấy đồ sẽ dễ dàng hơn khi bạn đi và họ không cần một khóa học (những thứ này có sẵn không?).

Các khu vực khác bạn có thể nhìn vào là hệ thống của bạn. Nếu họ không thể lập trình tốt, thì họ có đủ tiến bộ để triển khai lớn không, trong đó hầu hết các công việc cần phải được viết kịch bản bất kỳ công cụ nào bạn sử dụng?

Tôi cũng làm việc vì một tổ chức phi lợi nhuận và chịu trách nhiệm ban đầu mang các hộp Linux vào nhà và ngay sau đó là Puppet để quản lý chúng. Có một vài điều cụ thể mà chúng tôi đã thực hiện đã thực sự giúp mọi thứ trở nên thuận lợi.

Trước hết tôi đã cố gắng tránh xa các mô-đun của bên thứ ba. Các công cụ sẵn có xử lý 90% quản lý của chúng tôi. Tiện ích bên thứ ba lớn nhất tôi sử dụng là mô-đun tường lửa. Bất kỳ sự kiện tùy chỉnh, vv được phát triển với toàn bộ nhóm tham gia. Chúng tôi đã phát triển một mô-đun mẫu và giữ cho việc quản lý tệp, gói, dịch vụ, v.v ... tất cả được chuẩn hóa khỏi mẫu này.

Thứ hai, sau khi tiêu chuẩn hóa việc sử dụng các mô-đun sẵn có, chúng tôi bắt đầu sử dụng Git và Atlassian's Crucible - miễn phí cho lợi nhuận, bằng cách này - để thực hiện đánh giá tất cả các thay đổi cấu hình. Điều này cung cấp sự minh bạch mong muốn.

Thứ ba, tôi đã tự động thiết lập cho Puppet để các máy chủ mới có thể được thêm tự động với một bộ tùy chọn mặc định. Có một số cách để giải quyết điều này. Vì tôi đã có một môi trường Kickstart hoàn chỉnh, tôi đã chọn thêm một tập lệnh ở đó.

"Chúng tôi không phải lập trình viên, chúng tôi là hệ thống"

Thời đại của tôi đã thay đổi như thế nào, tệ hơn: một người xám như tôi được kỳ vọng sẽ trở thành một lập trình viên giỏi hơn các lập trình viên chuyên nghiệp, nếu không sẽ không bao giờ có thể vượt qua cho một quản trị viên hệ thống .

Bây giờ, chúng tôi có "quản trị viên hệ thống", về cơ bản là người dùng máy tính để bàn Windows, những người đã chuyển đổi sang Linux và không thể lập trình, và không tìm thấy bất cứ điều gì sai với điều đó.

Con voi trong phòng là lý do tại sao quản lý chịu đựng một thái độ phá hoại như vậy. Phá hoại cho ai hay cái gì? Để kinh doanh và cơ sở hạ tầng.

Quay lại chủ đề Puppet [, CFEngine, Chef]: ngay khi người ta đặt ra một giải pháp như vậy, người ta sẽ thua. Ai cũng thua. Tại sao? Bởi vì bất cứ ai nảy ra ý tưởng đều không có khả năng thiết kế quản lý cấu hình được đóng gói dưới dạng các gói hệ điều hành đẹp, sạch, Kickstart [, JumpStart, Automated Installer, AutoYaST, Ignite-UX, NIM]. Khi bạn phải sử dụng một công cụ hack tự động như Puppet (hoặc Chef hoặc CFEngine), điều đó có nghĩa là bạn thiếu thiết kế và thực hiện một quy trình, theo thiết kế đó, sẽ thực thi hoàn toàn nguyên sơ và tắt đèn hệ thống được quản lý tự động và hoàn toàn không tương tác.

Một điểm quan trọng là, nếu bạn cần phải có Múa rối hoặc một số giải pháp như vậy để sửa một ai đó hack hệ thống hoặc cấu hình ứng dụng bằng tay, mà cũng đi trở lại không có kinh nghiệm để thiết kế một quá trình, và trong quá trình đó một khuôn khổ mà cấu hình được đóng gói thành các thành phần riêng biệt. Trong thực tế, bất cứ ai thực hiện Puppet và tương tự, không có khái niệm về chủ sở hữu thành phần, bản phát hành, quản lý cấu hình, Mô hình trưởng thành khả năng. Điều này đang nhanh chóng phát triển thành một vấn đề rất nghiêm trọng trong ngành.

Làm việc với Puppet cũng giúp tôi học được Ruby, thứ đã thay thế Bash làm ngôn ngữ công cụ hệ thống mặc định của tôi. "

Tại sao Ruby cần thiết, khi quản lý cấu hình toàn diện, toàn diện có thể được gói gọn trong các phần cài đặt sẵn, postinstall, preremove và postremove của các gói hệ điều hành, chỉ bằng cách sử dụng các chương trình shell Bourne, AWK và sed? Rằng ai đó sẽ đi vào thời gian học một ngôn ngữ bí truyền của Ruby, và một phương ngữ trong bối cảnh của Puppet, là hoàn toàn không cần thiết. Vấn đề quản lý cấu hình có thể dễ dàng giải quyết (và để dí dỏm, đã được giải quyết) với các chương trình shell và AWK, và một chút sed (1) ở đây và ở đó như một chất keo.

Thật là một cảm giác tuyệt vời khi thấy bảng kê khai rối của bạn cấu hình toàn bộ máy hoặc dịch vụ mới từ đầu.

Thật tuyệt vời khi thấy nó được thực hiện bởi Kickstart, AutoYaST hoặc JumpStart, không có một dòng mã nào và có thể truy vấn hệ điều hành bằng cách sử dụng các công cụ tích hợp, mà không cần bất kỳ phần mềm bí mật hoặc phần mềm bổ sung nào , không cần máy chủ-máy khách kiến trúc được yêu cầu (SSH là tốt hơn, tốt hơn nhiều) và thấy hệ điều hành của bạn nhận thức được từng thay đổi được thực hiện cho nó.

5. Mã số từ dữ liệu. Đây là một trong những khái niệm khó học hơn. Các giá trị mã hóa cứng như Giám sát máy chủ vào mã mô-đun của bạn là xấu. Đưa chúng vào kho lưu trữ dữ liệu (db, yaml (Hiera sử dụng mặc định này), csv, bất cứ điều gì) mà các mô-đun của bạn có thể tiêu thụ là tốt. Một ví dụ là một ứng dụng web sử dụng Mysql. Điều này cho phép là khả năng đẩy mã và dữ liệu riêng biệt. Điều này làm cho quá trình phát triển của bạn đơn giản hơn.

... Hoặc bạn chỉ có thể tạo mẫu các tệp cấu hình của mình bằng các biến shell, thậm chí backquote (ví dụ ls -1 ...) và viết tập lệnh shell sử dụng AWK để gọi eval (1) và mở rộng tất cả các biến trong mẫu, từ đó tận dụng chính xác mạnh mẽ như vậy trình phân tích cú pháp mà shell đã tích hợp sẵn. Tại sao làm cho nó phức tạp, khi nó có thể thực sự, thực sự đơn giản? Bạn sẽ lưu trữ các giá trị cấu hình ở đâu? Tại sao, bất cứ nơi nào bạn muốn, chẳng hạn như các tệp pkginfo (4) hoặc cơ sở dữ liệu như Oracle hoặc khá nhiều ở mọi nơi . Không cần các giải pháp ultracomplex. Thư viện mà tôi đề cập ở trên có thể chỉ đơn giản là có nguồn gốc từ các phần cài đặt trước hoặc cài đặt sau trong các gói hệ điều hành, do đó loại bỏ trùng lặp và tận dụng một đoạn mã trung tâm ...

Nhưng trên hết, tôi thấy rằng trích dẫn trên là một ví dụ về thế hệ quản trị viên hệ thống tiếp theo cần dạy kèm không phải bởi quản trị viên hệ thống, mà bởi các kỹ sư hệ thống . Tìm cho mình một chú chó xám và đăng nhập như một người học việc.