ทำไมหนังสือจึงแพร่หลายในชุมชน DevOps

17

ฉันเห็นบล็อกที่ฉันติดตามแนะนำหนังสือเพิ่มมากขึ้นเรื่อย ๆ

ฉันสนุกกับการอ่านนิยายและไม่ชอบหนังสือ แต่จะสามารถอัปเดต / เขียนบล็อกใหม่ได้เมื่อเทคโนโลยีเคลื่อนที่ในหนังสือเหล่านี้ซึ่งโดยปกติจะมีราคาประมาณ£ 20-30

มีคุณภาพที่เฉพาะเจาะจงสำหรับชื่อที่เกี่ยวข้องกับ DevOps ซึ่งขาดหายไปจากโลกออนไลน์หรือทุกคนยกเว้นฉัน

culture

— Briansbum
แหล่งที่มา

1

วัตถุ DevOps ของสสารนั้นเป็นแบบอัตนัยและของเหลว ซึ่งให้โอกาสมากขึ้นสำหรับการเขียนหนังสือมากกว่าสาขาอื่น ๆ ที่จัดตั้งขึ้นมากขึ้น การอ้างอิงดังกล่าวจำนวนมากเป็นการโฆษณาธรรมดาไม่จำเป็นต้องหมายความว่าเป็นการอ้างอิงที่ต้องอ่านในฟิลด์ (แม้ว่าพวกเขาจะถูกเรียกอย่างชัดเจน)

— Dan Cornilescu

โดยทั่วไปแล้วคุณไม่รู้ว่าเป็นน้ำมันงูหรือไม่จนกว่าคุณจะซื้อมา

— corsiKa

2

หน้าที่ DevOps เริ่มต้นก่อนที่จอภาพจะเปิด :-)

— mcalex

15

ในกรณีส่วนใหญ่หนังสือที่แนะนำไม่เกี่ยวกับเทคโนโลยี ในขณะที่เทคโนโลยีเปลี่ยนแปลงหลักการพื้นฐานที่อยู่เบื้องหลังองค์กรเช่นการคิดระบบความเป็นผู้นำสามัญสำนึก ฯลฯ ไม่เปลี่ยนแปลงบ่อยนัก

หนังสือเช่นเป้าหมายและแม้กระทั่งThe DevOps Handbookไม่ได้กล่าวถึงเทคโนโลยีมากมายในหน้าของพวกเขา แต่เป็นวิธีการจัดการงานที่ทำโดยผู้คน

ปัญหามากมายเกี่ยวข้องกับเทคโนโลยีหัวข้อเช่น Microservices, Architecting ระบบขนาดใหญ่, โครงสร้างพื้นฐานเป็น Code, ฯลฯ ... สิ่งเหล่านี้ไม่ได้พูดถึงเครื่องมือเฉพาะและ / หรือเทคโนโลยี แต่เกี่ยวกับหัวข้อสถาปัตยกรรม สาขาความรู้ที่ผู้สร้างระบบขนาดใหญ่จำเป็นต้องรู้เพื่อสร้างระบบอย่างถูกต้อง ความรู้นี้หายากและหนังสือเล่มนี้เขียนขึ้นเกี่ยวกับวิชาเหล่านี้ - เพียงไม่สนใจเครื่องมือที่กล่าวถึงหรือแปลเป็นการกลับชาติมาเกิดครั้งใหม่ของพวกเขา

หนึ่งในหนังสือที่ดีขึ้นเกี่ยวกับการสร้างซอฟต์แวร์ที่มีคุณภาพ imho () เป็นเปรียวการพัฒนาซอฟท์แวหลักการรูปแบบและวิธีปฏิบัติ และในขณะที่ภาษาที่ใช้ในหนังสือเล่มนี้ (Java) ได้เคลื่อนไหวไปบ้างแล้วตัวอย่างที่ให้ไว้ในหนังสือนั้นไม่มีเวลาและสามารถแปลเป็นภาษาอื่น ๆ ที่ต้องการได้อย่างง่ายดาย

ปัญหาบางอย่างที่ขบวนการ DevOps พยายามแก้ไขนั้นมีส่วนเกี่ยวข้องกับวิธีการทั่วไปในการจัดการงานในองค์กรที่ไม่สมเหตุสมผล ดังที่ Eliyahu Goldratt พูดบ่อย ๆ (ผู้เขียนเป้าหมาย ) "สามัญสำนึกไม่ธรรมดามาก"

หนังสือเหล่านี้สอนหลักการคิดที่ถูกต้องเกี่ยวกับปัญหาและความสัมพันธ์ของมนุษย์ในการตั้งค่าระบบเพื่อปรับปรุงทั้งระบบ บทเรียนนั้นเก่าและน่าเสียดายที่ไม่ค่อยมีคนทำงานในสาขาที่เรียนรู้ได้จริง

โดยธรรมชาติแล้วยังมีนักเขียนที่เขียนหนังสือเกี่ยวกับเครื่องมือดังกล่าวและเทคโนโลยีฟองฟู่ดังกล่าวที่ใหม่และเกี่ยวข้องกับฟิลด์เช่น AWS หรือ Docker หรือ Jenkins หรืออะไรก็ตามและต้องการผลักดันยอดขายหนังสือของพวกเขา ... แต่ฉันลองและ ยกเว้นการโพสต์บล็อกประเภทนี้จากคำตอบของฉัน

— Evgeny
แหล่งที่มา

คำพูดนั้นเดิมทีเป็นวอลแตร์ฉันไม่เคยได้ยินชื่อ Goldratt นี้

— Gaius

@Gaius Goldratt กำลังพูดถึงคนฉลาดหลายคน

— Evgeny

4

นี่คือสัญญาณของการเติบโตที่ครบกำหนดของวิศวกรรมโครงสร้างพื้นฐานเป็นสาขาหรืออาชีพ หากคุณพิจารณารูปแบบทางวิศวกรรมแบบดั้งเดิมใด ๆ เพิ่มเติมเช่นเครื่องจักรกลโยธาหรือไฟฟ้าความรู้จำนวนมากคือรูปแบบหนังสือกระดาษนั่นคือวิธีการสอนวิศวกรที่ปรึกษาหนังสืออ้างอิง นั่นเป็นเพราะเมื่อหลักการพื้นฐานเข้าใจและประมวลผลแล้วรายละเอียดของการนำไปใช้จะเฉพาะกับแอปพลิเคชันหรือการติดตั้งเฉพาะเท่านั้น คุณสามารถพิจารณาสิ่งประดิษฐ์ทางวิศวกรรมใด ๆ เช่นตึกระฟ้าหรือสะพานเครื่องยนต์ไอพ่นเรือบรรทุกเครื่องบิน ซับซ้อนอย่างมหาศาลต้องการทักษะที่ดีในการสร้าง แต่สร้างขึ้นโดยใช้หลักการทั่วไปที่ตอนนี้พวกเขาเข้าใจเปลี่ยนเพียงในช่วงทศวรรษที่ผ่านมาและจะสามารถเข้าใจได้ง่ายต่อวิศวกรจากทศวรรษที่ผ่านมา

ทำให้ DevOps เฉพาะเจาะจงมากขึ้น - ไม่สำคัญว่าคุณจะใช้การจัดการการกำหนดค่าด้วย CFEngine, Chef, Puppet หรืออะไรก็ตามหลักการของการจัดการการกำหนดค่าได้ถูกเข้าใจอย่างเพียงพอแล้วในตอนนี้ที่พวกเขาสามารถเขียนและนำไปใช้กับเครื่องมือจริง ๆ

— ออกุสตุ
แหล่งที่มา