Kształtująca się synteza „dobrych praktyk”, praktycznego i wspieranego naukowo usystematyzowania (stąd inżynieria) podejścia do utrzymania systemów złożonych w obszarze IT. Chodzi o radzenie sobie/zarządzanie złożonością więc lepszą nazwą wydaje się inżynieria złożoności. Określa jakościową zmianę pomiędzy „klasycznym” podejściem inżynierskim w procesie wytwórczym (rozumianym jako implementacja projektu systemu) a utrzymaniem systemu. Powstaje złożoność, która jest efektem oddziaływania wielu różnorodnych, współzależnych i współpracujących elementów. Dlatego system zaczyna żyć własnym życiem i wymaga zmiany tradycyjnego podejścia (koncepcja/projekt/implementacja). Zaczynamy go traktować bardziej jako system naturalny niż zaprojektowany. Weryfikujemy niekoniecznie szczegółowo walidując, eksperymentujemy a nie testujemy. Przestajemy kompulsywnie poprawiać projekt/kod szukając niespójności czy „redukując” złożoność. Często redukcja złożoności jest pozorna a pracochłonne poszukiwanie luk w projekcie pozostaje w sprzeczności ze zdrowym rozsądkiem (nazywanym w celach naukowych 😊zasadą 80/20). Warto zauważyć, że Inżynieria chaosu jest praktycznym wariantem odpowiedzi na złożoność systemów istotnie odmiennym niż „filozofująca” i słabo zoperacjonalizowana „antykruchość”😊. (Przepraszam za eufemistyczny bełkot, ale w ten sposób powstrzymuję się od antytalebistycznych dygresji). Jeśli uznacie mój wywód za ogólnikową, wręcz pozbawioną sensu, systemową „pierdologię” 😊, to tym bardziej - zajrzyjcie do książki. Relacjonując w duuuużym uproszczeniu przyjmujemy, że kluczem do stabilnego funkcjonowania systemu jest umiejętne reagowanie na zdarzenia zakłócające. Budujemy więc sprawny, skalowalny zespól utrzymaniowy. Zdobywa on doświadczenia w reagowaniu na zakłócenia, które często sami automatycznie generujemy na produkcji!!!. Produktem jest doświadczenie indywidualne i zespołowe oraz tworzone scenariusze ograniczania szkód i sprawnego przywracania działania. Warto zauważyć, że tak tworzony system techniczno-społeczny działa jak specyficzny złożony układ adaptacyjny i wyraźnie nawiązuje do idei DevOps. Oczywiście, jak na „inżynierskość” przystało (rozumianą w opozycji do jałowego teoretyzowania),książka zawiera część praktyczną w formie kilku pogłębionych studiów przypadków.
Niestety istotną wadą książki jest jakość tłumaczenia. Tłumaczka przepuściła tekst przez lingwistyczny translator ale niestety go nie zredagowała. To spory kłopot dla czytelnika, bo opisywana dyscyplina dopiero się kształtuje. Niekiedy wpadki translacyjne to tylko humorystyczny przerywnik, ale kilka razy musiałem zajrzeć do oryginału, żeby zrozumieć opisywane zagadnienia. Jedna z najgorzej przetłumaczonych książek jakie znam ale nie obniżyłem za to oceny.

Kształtująca się synteza „dobrych praktyk”, praktycznego i wspieranego naukowo usystematyzowania (stąd inżynieria) podejścia do utrzymania systemów złożonych w obszarze IT. Chodzi o radzenie sobie/zarządzanie złożonością więc lepszą nazwą wydaje się inżynieria złożoności. Określa jakościową zmianę pomiędzy „klasycznym” podejściem inżynierskim w procesie wytwórczym...