Dlaczego książki są tak rozpowszechnione w społeczności DevOps?

Widziałem sporo blogów, które obserwuję, polecając z czasem coraz więcej książek.

Lubię czytać fikcje i nie mam niechęci do książek, ale tam, gdzie blog może być aktualizowany / przepisywany, gdy technologia porusza się na tych książkach, które zwykle ~ 20-30 £ nie mogą.

Czy w tytułach związanych z DevOps jest jakaś szczególna jakość, której brakuje w świecie online, czy też wszyscy oprócz mnie wariują?

W większości przypadków zalecane książki nie dotyczą technologii. Podczas gdy technologia się zmienia, podstawowe zasady organizacji, takie jak myślenie systemowe, przywództwo, zdrowy rozsądek itp. Nie zmieniają się tak często.

Książki takie jak The Goal , a nawet The DevOps Handbook nie wspominają o wielu technologiach na swoich stronach, ale raczej o sposobach zarządzania pracą wykonywaną przez ludzi.

Wiele problemów związanych jest z technologią, takie tematy jak mikrousługi, architektura dużych systemów, infrastruktura jako kod itp. Nie mówią o konkretnym narzędziu i / lub technologii, ale raczej o temacie architektonicznym. Dziedzina wiedzy, którą muszą znać osoby budujące duże systemy, aby poprawnie zbudować system. Ta wiedza jest rzadka, a jej wspaniałe książki są pisane na te tematy - po prostu zignoruj ​​wspomniane narzędzia lub przełóż się na ich nową reinkarnację.

Jedną z lepszych książek o tworzeniu wysokiej jakości oprogramowania (imho) jest zwinne tworzenie oprogramowania, zasady, wzorce i praktyki . I chociaż język używany w tej książce (Java) znacznie się zmienił, przykłady podane w książce są ponadczasowe i można je łatwo przetłumaczyć na dowolny inny wybrany język.

Niektóre problemy, które ruch DevOps próbuje rozwiązać, dotyczą typowych sposobów zarządzania pracą w organizacjach, co nie ma żadnego sensu. Jak często powtarzał Eliyahu Goldratt (autor The Goal ) „Zdrowy rozsądek nie jest zbyt powszechny”.

Te książki uczą zasad prawidłowego myślenia o problemach i relacjach międzyludzkich w systemie, aby cały system był ulepszony. Lekcje są stare i niestety bardzo rzadko są ludzie, którzy pracują w terenie, którzy faktycznie się ich nauczyli.

Oczywiście są też autorzy, którzy pisali książki o takim i takim fizycznym narzędziu technologicznym fizz-bang, które jest nowe i odpowiednie w tej dziedzinie, takie jak AWS, Docker, Jenkins itp. I po prostu chcą zwiększyć sprzedaż książek ... ale staram się wyklucz z tego rodzaju postów na blogu.

Jest to oznaką rosnącej dojrzałości inżynierii infrastruktury jako dziedziny lub zawodu. Jeśli weźmiesz pod uwagę jakąkolwiek bardziej tradycyjną formę inżynierii, taką jak mechaniczna, cywilna lub elektryczna, większość wiedzy to papierowa książka, czyli jak się go uczy, praktykujący inżynierowie sięgają do podręczników. Wynika to z tego, że po zrozumieniu i skodyfikowaniu podstawowych zasad szczegóły wdrożenia są specyficzne tylko dla konkretnej aplikacji lub instalacji. Możesz wziąć pod uwagę każdy artefakt inżynierski - wieżowiec lub most, silnik odrzutowy, lotniskowiec. Niezwykle wyrafinowane, wymagające wielkich umiejętności w budowie, ale zbudowane przy użyciu ogólnych zasad, które teraz są rozumiane, zmieniają się dopiero w ciągu dziesięcioleci i byłyby łatwe do zrozumienia dla inżyniera sprzed kilkudziesięciu lat.

Uszczegóławiając DevOps - naprawdę nie ma znaczenia, jeśli zaimplementujesz zarządzanie konfiguracją za pomocą CFEngine, Chef, Puppet lub czegokolwiek innego, zasady zarządzania konfiguracją są teraz wystarczająco zrozumiałe, że można je zapisać i zastosować do dowolnego rzeczywistego narzędzia.