Чому книги так поширені в спільноті DevOps?

Я бачив досить багато блогів, за якими слідкую, рекомендуючи все більше і більше книг з часом.

Мені подобається читати художню літературу і не маю ніякої відрази до книг, але там, де блоґпост можна оновити / переписати, коли техніка рухається до цих книг, які зазвичай ~ 20-30 фунтів не можуть.

Чи є якась особливість якості для назв, пов'язаних з DevOps, яких не вистачає в Інтернеті, або це все, окрім мене, горіхи?

У більшості випадків рекомендовані книги не стосуються технології. Хоча технологія змінюється, основні принципи, що стоять за такими організаціями, як системне мислення, лідерство, здоровий глузд тощо ..., не змінюються так часто.

Книги, такі як «Ціль» і навіть «Посібник з DevOps» , не згадують про багато технологій на своїх сторінках, а про способи управління роботою, яку виконують люди.

Багато проблем пов'язані з технологіями, такі теми, як мікросервіси, архітектура масштабних систем, інфраструктура як код тощо ... вони не говорять про конкретний інструмент та / або технології, а про архітектурну тему. Сфера знань, яку повинні знати люди, які будують великі системи, щоб правильно побудувати систему. Ці знання рідкісні, і великі книги, написані з цих предметів - просто ігноруйте згадані інструменти або перекладіть їх на нове перевтілення.

Однією з кращих книг про створення якісного програмного забезпечення (imho) є Agile Development Software, Principles, Patterns, and Practices . І хоча мова, що використовується в цій книзі (Java), досить зрушилася, приклади, наведені в книзі, є позачасовими і їх можна легко перекласти на будь-яку іншу мову на вибір.

Деякі проблеми, які намагається вирішити рух DevOps, пов'язані із загальними способами управління роботою в організаціях, які просто не мають сенсу. Як часто говорив Еліяху Голдрат (автор "Цілі" ) "Здоровий глузд не дуже поширений".

Ці книги вчать принципам правильного мислення щодо проблем та людських стосунків у системі, щоб покращити всю систему. Уроки давні, і, на жаль, лише рідко трапляються люди, які працюють на місцях, які насправді їх вивчили.

Природно, є також автори, які писали книги про подібний та подібний технологічний інструмент fizz-bang, який є новим і актуальним у цій галузі, як AWS, Docker чи Jenkins, або будь-що, і просто хочуть підштовхнути свої продажі книг ... але я намагаюся і виключити подібні публікації в блозі з моєї відповіді.

Це ознака зростаючої зрілості інфраструктурного машинобудування як галузі чи професії. Якщо ви розглядаєте будь-яку з більш традиційних інженерних форм, таких як механічна, цивільна або електрична, основна частина знань - це паперова форма книги, саме тому її навчають, практикуючі інженери консультуються з довідниками. Це тому, що після того, як основні принципи будуть зрозумілі та кодифіковані, деталі реалізації конкретні лише для конкретного додатка чи установки. Ви можете розглянути будь-який інженерний артефакт - хмарочос або міст, реактивний двигун, авіаносець. Надзвичайно складна, що вимагає великої майстерності для побудови, але побудована на основі загальних принципів, які тепер, як вони зрозуміли, змінюються лише протягом десятиліть, і це було б зрозуміло інженеру з десятиліть тому.

Зробити це більш специфічним для DevOps - це насправді не має значення, якщо ви керуєте керуванням конфігурацією за допомогою CFEngine, Chef, Puppet або чогось іншого, принципи управління конфігурацією досить добре зрозуміли, що тепер вони можуть бути записані та застосовані до будь-якого фактичного інструменту.