Tại sao sách phổ biến trong cộng đồng DevOps?

Tôi đã thấy khá nhiều blog tôi theo dõi giới thiệu ngày càng nhiều sách theo thời gian.

Tôi thích đọc tiểu thuyết và không có ác cảm với sách nhưng nơi một blogpost có thể được cập nhật / viết lại khi công nghệ di chuyển trên những cuốn sách này thường là ~ £ 20-30 không thể.

Có một phẩm chất đặc biệt nào đối với các tựa game liên quan đến DevOps bị thiếu trong thế giới trực tuyến hay tất cả mọi người trừ tôi?

Trong hầu hết các trường hợp, những cuốn sách được đề nghị không phải là về công nghệ. Trong khi công nghệ thay đổi, các nguyên tắc cơ bản đằng sau các tổ chức như tư duy hệ thống, lãnh đạo, lẽ thường, v.v ... không thay đổi thường xuyên.

Những cuốn sách như Mục tiêu và thậm chí Sổ tay DevOps không đề cập nhiều đến công nghệ trên trang của họ mà thay vào đó là cách quản lý công việc đang được mọi người thực hiện.

Nhiều vấn đề liên quan đến công nghệ, các chủ đề như microservice, Kiến trúc hệ thống quy mô lớn, Cơ sở hạ tầng như Mã, v.v ... những điều này không nói về một công cụ và / hoặc công nghệ cụ thể mà là về một chủ đề kiến ​​trúc. Một lĩnh vực kiến ​​thức mà những người xây dựng các hệ thống lớn cần phải biết để xây dựng hệ thống một cách chính xác. Kiến thức này rất hiếm, và những cuốn sách tuyệt vời của nó được viết về những chủ đề này - chỉ cần bỏ qua các công cụ được đề cập, hoặc chuyển thành tái sinh mới của họ.

Một trong những cuốn sách hay hơn về việc tạo ra phần mềm chất lượng (imho) là Phát triển phần mềm, nguyên tắc, mô hình và thực tiễn của Agile . Và mặc dù ngôn ngữ được sử dụng trong cuốn sách này (Java) đã thay đổi khá nhiều, các ví dụ được cung cấp trong cuốn sách là vô tận và có thể dễ dàng dịch sang bất kỳ ngôn ngữ nào khác.

Một số vấn đề mà phong trào DevOps cố gắng giải quyết có liên quan đến các cách làm việc chung được quản lý trong các tổ chức không có ý nghĩa gì. Như Eliyahu Goldratt thường nói (tác giả của Mục tiêu ) "Ý thức chung không phổ biến lắm".

Những cuốn sách này dạy các nguyên tắc suy nghĩ chính xác về các vấn đề và mối quan hệ của con người trong một thiết lập hệ thống để toàn bộ hệ thống được cải thiện. Các bài học đã cũ, và thật không may, chỉ hiếm khi có những người làm việc trong lĩnh vực thực sự học chúng.

Đương nhiên, cũng có những tác giả viết sách về công cụ công nghệ fizz-bang như vậy mới và phù hợp với lĩnh vực này, như AWS hoặc Docker hoặc Jenkins hoặc bất cứ điều gì và chỉ muốn đẩy doanh số bán sách của họ ... nhưng tôi đã thử và loại trừ các loại bài đăng blog từ câu trả lời của tôi.

Đây là một dấu hiệu của sự trưởng thành ngày càng tăng của kỹ thuật cơ sở hạ tầng như một lĩnh vực hoặc một nghề nghiệp. Nếu bạn xem xét bất kỳ hình thức kỹ thuật truyền thống nào như cơ khí, dân dụng hoặc điện, phần lớn kiến ​​thức là dạng sách giấy, đó là cách nó được dạy, các kỹ sư thực hành tham khảo sách tham khảo. Đó là bởi vì một khi các nguyên tắc cơ bản được hiểu và mã hóa, các chi tiết thực hiện chỉ dành riêng cho một ứng dụng hoặc cài đặt cụ thể. Bạn có thể xem xét bất kỳ vật phẩm kỹ thuật nào - một tòa nhà chọc trời hoặc cây cầu, động cơ phản lực, tàu sân bay. Rất tinh vi, đòi hỏi kỹ năng tuyệt vời để xây dựng, nhưng được xây dựng bằng các nguyên tắc chung mà giờ đây chúng đã được hiểu, chỉ thay đổi trong suốt nhiều thập kỷ và có thể dễ hiểu đối với một kỹ sư từ nhiều thập kỷ trước.

Làm cho nó trở nên cụ thể hơn DevOps - thực sự không có vấn đề gì nếu bạn thực hiện quản lý cấu hình với CFEngine, Chef, Puppet hoặc bất cứ điều gì khác, các nguyên tắc quản lý cấu hình đã được hiểu rõ và giờ đây chúng có thể được viết ra và áp dụng cho bất kỳ công cụ thực tế nào.