Optymalizuj system, nie jego komponenty
Pierwsza zasada inżynierii systemów Hamminga
Podstawowa zasada Hamminga z rozdz. 28: Jeśli optymalizujesz komponenty, prawdopodobnie zniszczysz wydajność całego systemu.
Hamming zilustrował to historią analizatora różniczkowego. Dwa urządzenia miały zostać połączone. Budowniczowie ulepszyli wzmacniacze w drugim urządzeniu. W dniu odbioru Hamming uruchomił standardowy test — rozwiązać y'' + y = 0, narysować y vs y', oczekiwać okręgu. Test nie powiódł się. Przyczyna: ulepszone wzmacniacze pobierały więcej prądu przez obwód uziemienia. Uziemienie było odpowiednie dla oryginalnego projektu. Nie było przystosowane do nowego poziomu prądu. Uszkodzony został interfejs, a nie komponent.
Jego uogólnienie: większość awarii systemów wynika z interfejsów, a nie z komponentów. Komponenty są projektowane, testowane i certyfikowane. Interfejsy są projektowane jako dodatek, rzadko testowane i nigdy nie certyfikowane niezależnie. Gdy komponent się zmienia, zmienia się jego zachowanie interfejsowe. Nic, co jest dalej w systemie, nie zostało zaprojektowane z myślą o tym nowym interfejsie.
Kluczowa asymetria: 10-krotna poprawa w komponencie może spowodować 10-krotne pogorszenie działania systemu, jeśli komponent zasila ograniczony interfejs. Poprawa nie dodaje — ona odejmuje.
System edukacji jako nieudana inżynieria systemów
Przypadek edukacji według Hamminga
Hamming zastosował tę zasadę do edukacji. Optymalizacja wyników w poszczególnych przedmiotach — ćwiczenie uczniów w celu maksymalizacji wyników testów z każdego przedmiotu — tworzy uczniów, którzy dobrze radzą sobie z indywidualnymi testami, ale nie potrafią integrować wiedzy między dyscyplinami.
Każdy komponent (wynik z przedmiotu) poprawia się. System (edukacja, rozumiana jako zintegrowane zrozumienie) ulega degradacji. Interfejs między przedmiotami — zdolność ucznia do stosowania wiedzy w różnych dziedzinach — nigdy nie został zoptymalizowany. Uległ atrofii.
To nie jest przypadek implementacji. To jest strukturalne. Gdy mierzysz i nagradzasz wydajność komponentów, otrzymujesz optymalizację komponentów. Interfejsy są niewidoczne dla metryk komponentowych.
Jego zalecenie: znajdź wąskie gardło w systemie, a następnie zapytaj, co się dzieje dalej, gdy je usuniesz. Usunięcie wąskiego gardła zalewa kolejkę następną. Nieograniczona optymalizacja staje się nowym ograniczeniem.
Śledzenie degradacji interfejsu
Hamming pokazał, że poprawa komponentu zmienia jego zachowanie na interfejsie — a reszta systemu została zaprojektowana wokół starego interfejsu.
Węzły, kolejki, wskaźniki przeciążenia
Model Fabryki MOAD
Każdy graf zależności oprogramowania tworzy fabrykę. Każdy węzeł to stacja robocza. Każda krawędź to kolejka. Praca trafia do kolejki węzła, jest przetwarzana i przepływa do kolejek downstream.
Dwa wyniki charakteryzują każdy węzeł:
Wynik surge = przyspieszenie × in-degree
Ile pracy zalewa dalsze etapy, gdy ten wąskie gardło zostanie usunięte. Węzeł z in-degree równym 5 (5 zależności nadrzędnych zasilających go) i przyspieszeniem 100× generuje 500× surge w dół strumienia.
Betweenness = in-degree + out-degree
Jak centralne jest to stanowisko dla całego przepływu. Wysoka wartość betweenness oznacza, że wiele ścieżek przechodzi przez ten węzeł.
Dwa archetypy:
Węzeł pracoholik: wysoka wartość betweenness, wysoki wynik surge. To jest wąskie gardło. Każda kolejka powyżej niego się zatyka z jego powodu. Usunięcie tego wąskiego gardła bez przygotowania pojemności poniżej spowoduje jednoczesne załamanie wszystkiego poniżej.
Węzeł żarłok: wysoki out-degree, niski wynik surge. Pochłania wszystko, co do niego trafia. Nie odczuwa bólu, ponieważ jego wąskie gardło jest wewnętrzne, a nie przepustowe. Maszyna, która zapomina się zatrzymać — praca wchodzi, nic nie wychodzi, a węzeł raportuje „zajęty” bez końca.
MOAD-0001 & MOAD-0005: Przypadek sprzężenia
Przypadek GHC
Przed łatką MOAD-0001 w resolverze zależności GHC: N=50 000 zależności wymagało 17 minut na zbudowanie. Po: 10 sekund. Przyspieszenie: 100×.
Co dzieje się dalej? Każdy cache buildów, magazyn artefaktów i runner CI, które dostosowały się do 17-minutowych partii, teraz otrzymują 100× więcej ukończonych buildów na godzinę. Cache’e zaprojektowane na 60 artefaktów na godzinę teraz otrzymują 6 000.
To jest MOAD-0005: defekt „cache stampede”. Każdy klucz cache’a jest pomijany jednocześnie, ponieważ żaden cache nie został wstępnie ogrzany pod nowy wskaźnik przybywania. Poprawka dla MOAD-0001 wytwarza MOAD-0005.
Sprzężenie nie jest przypadkowe. Jest strukturalne. Każde przyspieszenie O(N²) → O(N) przy in-degree > 1 generuje wynik skoku powyżej 1. Wynik skoku powyżej 100 jest kandydatem do MOAD-0005.
Staging Before Disclosure
System budowania przetwarza 1 000 grafów zależności pakietów na godzinę. Łatasz MOAD-0001 w jego algorytmie przechodzenia grafu, skracając czas budowania z 60 minut do 30 sekund — 120-krotne przyspieszenie. System przetwarza teraz 120 000 grafów na godzinę.
Kiedy przestać: Warunek zatrzymania
Warunek zatrzymania
Patch spełnia warunek zatrzymania — co oznacza: nie ujawniać — gdy wszystkie cztery warunki są spełnione jednocześnie:
1. Patch znajduje się w systemie produkcyjnym (scalone, wdrożone)
2. Brak opiekunów przypisanych do zarządzania wpływem downstream
3. Defekt downstream (MOAD-0005) nierozwiązany
4. Przyspieszenie >= 100×
Wszystkie cztery razem = dziecko płacze. Przydziel zespół przed scaleniem, nie po.
Węzeł bez opiekuna działa jak stanowisko bez pracownika. Praca się kumuluje. Ktoś się załamuje. Zasada permakomputera: nie naprawiaj algorytmu dyspozytorskiego bez przygotowania kierowców. Trzej kierowcy, trzy miliony ludzi: odblokowanie algorytmu tworzy stado nieobsłużonych żądań zamiast szybszej dostawy.
WALL-E: Obżartuchy i pracoholicy
Model WALL-E
Pixar WALL-E pokazuje w najczystszej formie awarię modelu fabrycznego. Obżartuchy na fotelach lewitujących, karmieni bez tarcia. Pracoholicy — WALL-E, EVE — umierający przy swoich stanowiskach, by utrzymać dopływ.
Węzeł obżartucha (ludzie na fotelach lewitujących) ma maksymalny out-degree: konsumuje wszystko, co do niego trafia, niczego nie produkuje. Jego wynik surge wynosi zero — jest zlewem. Nie odczuwa bólu, ponieważ nic nie kumuluje się na jego wyjściu. Po prostu konsumuje.
Węzeł pracoholika (WALL-E) ma maksymalną międzycentralność: wszystko przepływa przez niego. Absorbuje wszystkie dane wejściowe. Generuje jedyne dane wyjściowe. Jego wynik skoku, gdyby kiedykolwiek zastąpiono go szybszym modelem, zalałby jednocześnie wszystkie kolejki downstream.
Wada systemu WALL-E nie leży w żarłokach. Leży w nieobecnym opiekunie: nikt nie został przydzielony do równoważenia stacji roboczych. Nikt nie przygotował pojemności przed uruchomieniem algorytmu.
Przypadek pip: Lista kontrolna przed ujawnieniem
Odkrywasz MOAD-0001 w resolverze zależności pip w Pythonie. Zmierzona poprawa prędkości: 200×. pip działa na około 400 milionach instalacji dziennie. PyPI udostępnia pakiety.