Почему книги так распространены в сообществе DevOps?

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

Я люблю читать художественную литературу и не испытываю отвращения к книгам, но там, где блог-пост может быть обновлен / переписан, когда технология продвигает эти книги, которые обычно не стоят ~ 20-30 фунтов

Есть ли какое-то определенное качество в названиях, связанных с DevOps, которых нет в онлайн-мире, или все, кроме меня, чокнутые?

В большинстве случаев рекомендуемые книги не о технологиях. Хотя технологии меняются, основные принципы, лежащие в основе организаций, такие как системное мышление, лидерство, здравый смысл и т. Д., Меняются не так часто.

В таких книгах, как The Goal и даже The DevOps Handbook , на страницах не упоминается много технологий, а скорее способы управления работой, выполняемой людьми.

Многие проблемы связаны с технологиями, такими темами, как микросервисы, архитектура больших систем, инфраструктура как код и т. Д., Речь идет не об определенном инструменте и / или технологии, а об архитектуре. Область знаний, которую люди, которые строят большие системы, должны знать для правильного построения системы. Эти знания редки, и это здорово, что книги об этих предметах написаны - просто не обращайте внимания на упомянутые инструменты или переведите их в новое воплощение.

Одна из лучших книг о создании качественного программного обеспечения (imho) - Agile Software Development, Principles, Patterns и Practices . И хотя язык, используемый в этой книге (Java), несколько продвинулся вперед, примеры, представленные в книге, вне времени и могут быть легко переведены на любой другой язык по вашему выбору.

Некоторые проблемы, которые пытается решить движение DevOps, связаны с общими способами управления работой в организациях, которые просто не имеют никакого смысла. Как часто говорил Элиягу Голдратт (автор «Цели» ), «здравый смысл не очень распространен».

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

Естественно, есть также авторы, которые написали книги о таком-то и таком-то техническом инструменте, который является новым и актуальным в данной области, например, AWS, Docker, Jenkins или что-то еще, и просто хотят увеличить продажи своих книг ... но я стараюсь и исключить подобные сообщения в блоге из моего ответа.

Это признак растущей зрелости инженерной инфраструктуры как области или профессии. Если вы рассматриваете любую из более традиционных форм техники, таких как механическая, гражданская или электрическая, основная часть знаний - это бумажная книжная форма, то есть, как ее преподают, практикующие инженеры консультируются со справочными книгами. Это связано с тем, что как только базовые принципы поняты и систематизированы, детали реализации становятся специфичными только для конкретного приложения или установки. Вы можете рассмотреть любой инженерный артефакт - небоскреб или мост, реактивный двигатель, авианосец. Чрезвычайно сложный, требующий большого мастерства в конструировании, но построенный с использованием общих принципов, которые теперь понятны, меняются только в течение десятилетий и будут понятны для инженера десятилетия назад.

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