Optimalkan Sistem, Bukan Komponennya
Aturan Pertama Hamming dalam Sistem Engineering
Prinsip inti Hamming dari Ch. 28: Jika Anda mengoptimalkan komponen, kemungkinan besar Anda akan merusak performa sistem.
Ia mengilustrasikannya dengan kisah differential analyzer. Dua unit akan dihubungkan. Para pembuat memperbaiki amplifier pada unit kedua. Pada hari penerimaan, Hamming menjalankan tes standar — selesaikan y'' + y = 0, plot y vs y', harapkan lingkaran. Tes gagal. Penyebabnya: amplifier yang diperbaiki menarik lebih banyak arus melalui sirkuit grounding. Grounding tersebut baik untuk desain asli. Ia tidak dirancang untuk level arus baru. Antarmuka yang rusak, bukan komponennya.
Generalisasinya: sebagian besar kegagalan sistem berasal dari antarmuka, bukan komponen. Komponen dirancang, diuji, dan disertifikasi. Antarmuka dirancang sebagai pemikiran belakangan, jarang diuji, dan tidak pernah disertifikasi secara independen. Ketika sebuah komponen berubah, perilaku antarmukanya pun berubah. Tidak ada yang berada di hilir yang dirancang untuk antarmuka baru tersebut.
Asimetri kunci: peningkatan 10× pada sebuah komponen dapat menghasilkan penurunan 10× pada sistem jika komponen tersebut mengalir ke antarmuka yang terbatas. Peningkatan tersebut tidak menambah — melainkan mengurangi.
Sistem Pendidikan sebagai Kegagalan Rekayasa Sistem
Kasus Pendidikan Hamming
Hamming menerapkan prinsip ini pada pendidikan. Mengoptimalkan nilai mata pelajaran individu — melatih siswa untuk memaksimalkan performa ujian di setiap mata pelajaran — menghasilkan siswa yang mendapat nilai baik pada ujian individu tetapi tidak dapat mengintegrasikan pengetahuan lintas disiplin.
Setiap komponen (nilai mata pelajaran) mengalami peningkatan. Sistem (pendidikan, yang didefinisikan sebagai pemahaman terintegrasi) mengalami penurunan. Antarmuka antar mata pelajaran — kemampuan siswa untuk menerapkan pengetahuan lintas domain — tidak pernah dioptimalkan. Antarmuka tersebut mengalami atrofi.
Ini bukanlah kecelakaan implementasi. Ini bersifat struktural. Ketika Anda mengukur dan memberi penghargaan pada performa komponen, yang Anda dapatkan adalah optimasi komponen. Antarmuka tidak terlihat oleh metrik komponen.
Resepnya: temukan bottleneck dalam sistem, lalu tanyakan apa yang terjadi di hilir ketika Anda menghapusnya. Penghapusan bottleneck membanjiri antrian berikutnya. Optimasi yang tidak dibatasi menjadi kendala baru.
Melacak Degradasi Antarmuka
Hamming menunjukkan bahwa meningkatkan sebuah komponen mengubah perilaku antarmukanya — dan bagian lain dari sistem dirancang berdasarkan antarmuka lama.
Nodes, Queues, Surge Scores
A MOAD Factory Model
Setiap grafik dependensi perangkat lunak membentuk sebuah pabrik. Setiap node adalah workstation. Setiap edge adalah antrean. Pekerjaan masuk ke antrean node, diproses, lalu mengalir ke antrean hilir.
Dua skor yang menggambarkan setiap node:
Surge score = speedup × in-degree
Seberapa besar beban kerja yang mengalir ke downstream ketika bottleneck ini teratasi. Sebuah node dengan in-degree 5 (5 dependensi upstream yang semuanya mengarah ke node tersebut) dan speedup 100× menghasilkan surge 500× ke downstream.
Betweenness = in-degree + out-degree
Seberapa sentral workstation ini terhadap aliran total. Betweenness yang tinggi berarti banyak jalur melewati node ini. [BLOCK_TYPE SECTION/STEP]
[BLOCK_TYPE SECTION/STEP]
Dua arketipe: [BLOCK_TYPE SECTION/STEP]
[BLOCK_TYPE SECTION/STEP]
Node Workaholic: betweenness tinggi, surge score tinggi. Ini adalah bottleneck. Setiap antrean di hulu macet karena node ini. Hapus bottleneck ini tanpa menyiapkan kapasitas di hilir, dan seluruh bagian hilir akan runtuh secara bersamaan. [BLOCK_TYPE SECTION/STEP]
[BLOCK_TYPE SECTION/STEP]
Node Glutton: out-degree tinggi, surge score rendah. Mengonsumsi segala sesuatu yang diberikan kepadanya. Tidak merasakan tekanan karena bottleneck-nya bersifat internal, bukan throughput. Mesin yang lupa berhenti — pekerjaan masuk, tidak ada yang keluar, dan node terus melaporkan 'sibuk' selamanya. [BLOCK_TYPE SECTION/STEP]
MOAD-0001 & MOAD-0005: Kasus Coupling
Kasus GHC
Sebelum patch MOAD-0001 pada resolver dependensi GHC: N=50.000 dependensi membutuhkan waktu 17 menit untuk build. Setelah: 10 detik. Peningkatan kecepatan: 100×.
Apa yang terjadi di hilir? Setiap build cache, artifact store, & CI runner yang sebelumnya menyesuaikan diri dengan kedatangan batch 17 menit kini menerima 100× lebih banyak build yang selesai per jam. Cache yang dirancang untuk menangani 60 artefak build per jam kini menerima 6.000.
Ini adalah MOAD-0005: cacat cache stampede. Setiap cache key dilewatkan secara bersamaan karena tidak ada cache yang dipanaskan sebelumnya untuk laju kedatangan baru. Perbaikan untuk MOAD-0001 menghasilkan MOAD-0005.
Keterkaitan ini bukan kebetulan. Ini bersifat struktural. Setiap percepatan O(N²) → O(N) dengan in-degree > 1 menghasilkan surge score di atas 1. Surge score di atas 100 merupakan kandidat MOAD-0005.
Staging Before Disclosure
Sebuah sistem build memproses 1.000 grafik ketergantungan paket per jam. Anda menambal MOAD-0001 dalam traversal grafiknya, mengurangi waktu build dari 60 menit menjadi 30 detik — peningkatan kecepatan 120×. Sistem kini memproses 120.000 grafik per jam.
Kapan Berhenti: The Halt Condition
Kondisi Halt
Sebuah patch memenuhi kondisi halt — artinya: jangan ungkapkan — ketika keempat kondisi berikut terpenuhi secara bersamaan:
1. Patch berada di sistem live (sudah di-merge, sudah di-deploy)
2. Tidak ada caretaker yang ditugaskan untuk menangani dampak downstream
3. Cacat downstream (MOAD-0005) belum terselesaikan
4. Speedup >= 100×
Semua empat bersama = bayi menangis. Tetapkan tim sebelum menggabungkan, bukan setelah.
Node tanpa pengasuh berjalan seperti workstation tanpa pekerja. Pekerjaan menumpuk. Seseorang ambruk. Prinsip permacomputer: Anda tidak memperbaiki algoritma pengiriman tanpa menyiapkan driver. Tiga driver, tiga juta orang: membuka blokir algoritma menciptakan kawanan besar permintaan yang tidak dilayani, bukan pengiriman yang lebih cepat.
WALL-E: Rakus & Workaholic
Model WALL-E
WALL-E Pixar menggambarkan kegagalan model pabrik dalam bentuk paling jelas. Para rakus di kursi melayang, diberi makan tanpa gesekan. Para workaholic — WALL-E, EVE — mati di stasiun mereka untuk menjaga aliran tetap berjalan.
Node rakus (manusia di kursi melayang) memiliki out-degree maksimum: ia mengonsumsi segala yang diberikan kepadanya, tidak menghasilkan apa pun. Skor lonjakannya nol — ia adalah sink. Ia tidak merasakan sakit karena tidak ada yang menumpuk di output-nya. Ia hanya mengonsumsi.
Node workaholic (WALL-E) memiliki betweenness maksimum: segala sesuatu mengalir melaluinya. Ia menyerap semua input. Ia menghasilkan satu-satunya output. Skor lonjakannya, jika suatu saat digantikan oleh model yang lebih cepat, akan membanjiri setiap antrean hilir secara bersamaan.
Cacat pada sistem WALL-E bukanlah pada para glutton. Cacatnya adalah pada pengasuh yang absen: tidak ada yang ditugaskan untuk menyeimbangkan workstation. Tidak ada yang menyiapkan kapasitas sebelum menjalankan algoritma.
Kasus pip: Daftar Periksa Pra-Pengungkapan
Anda menemukan MOAD-0001 di resolver dependensi pip Python. Percepatan yang terukur: 200×. pip berjalan pada sekitar 400 juta instalasi per hari. PyPI menyajikan paket-paket tersebut.