un

guest
1 / ?
back to lessons

Optimalisasi Sistem, Bukan Komponen

Aturan Pertama Hamming tentang Sistem Engineering

Prinsip inti Hamming dari Ch. 28: Jika Anda mengoptimalisasi komponen, kemungkinan besar Anda akan merusak kinerja sistem.


Dia mengilustrasikannya dengan cerita analis diferensial. Dua unit harus terhubung. Pembangun meningkatkan amplifier di unit kedua. Pada hari uji coba, Hamming menjalankan tes standar - pecahkan y'' + y = 0, plot y vs y', harapkan lingkaran. Ini gagal. Penyebabnya: amplifier yang ditingkatkan mengambil arus lebih besar melalui sirkuit grounding. Grounding sesuai untuk desain asli. Tidak dirancang untuk arus level baru. Antarmuka rusak, bukan komponen.


Generalisasinya: kebanyakan kegagalan sistem berasal dari antarmuka, bukan komponen. Komponen dirancang, diuji, disertifikasi. Antarmuka dirancang sebagai hal terakhir, diuji jarang, dan tidak pernah disertifikasi secara independen. Ketika komponen berubah, perilaku antarmukanya berubah. Tidak ada yang turunannya dirancang untuk antarmuka baru tersebut.


Kesalahan kunci: peningkatan 10× pada komponen dapat menghasilkan degradasi 10× pada sistem jika komponen mengalir ke antarmuka konstrain. Peningkatan tidak menambah - itu mengurangi.

Sistem Pendidikan sebagai Pendidikan Sistem Engineering

Kasus Hamming tentang Pendidikan

Hamming menerapkan prinsip ini pada pendidikan. Mengoptimalisasi skor subjek individu - menggali siswa untuk meningkatkan performa tes dalam setiap subjek - menghasilkan siswa yang baik dalam tes individu tetapi tidak dapat mengintegrasikan pengetahuan di antara disiplin ilmu.


Setiap komponen (skor subjek) ditingkatkan. Sistem (pendidikan, yang didefinisikan sebagai pemahaman terpadu) menurun. Antarmuka antara subjek - kemampuan siswa untuk menerapkan pengetahuan di antara domain - tidak pernah ditingkatkan. Ini atrofi.


Ini tidak terjadi oleh kebetulan implementasi. Ini adalah struktural. Ketika Anda mengukur dan menghadiahi kinerja komponen, Anda mendapatkan optmialisasi komponen. Antarmuka tidak terlihat oleh metrik komponen.


Resepnya: temukan botolnya dalam sistem, lalu tanyakan apa yang terjadi di bawah saat Anda menghapusnya. Penghapusan botol menyebabkan banjir di antrian berikutnya. Optimalisasi tidak terbatas menjadi konstrain baru.

Mengikuti Degradasi Antarmuka

Hamming menunjukkan bahwa meningkatkan komponen mengubah perilaku antarmukanya — dan sistem lain dirancang berdasarkan antarmuka lama.

Berikan contoh konkrit dari perangkat lunak di mana meningkatkan kinerja satu komponen mencetuskan masalah di hilir. Namakan komponen yang ditingkatkan, antarmuka yang terpengaruh, dan tanda peringatan yang akan muncul sebelum kegagalan hilir.

Node, Antrian, Skor Ledakan

Model Pabrik MOAD

Setiap grafik ketergantungan perangkat lunak membentuk pabrik. Setiap node adalah mesin kerja. Setiap edge adalah antrian. Kerja masuk antrian queue, diproses, dan mengalir ke antrian hilir.


Dua skor yang menggambarkan setiap node:


Factory Model DAG: workaholic node (high betweenness + surge) dan glutton node (high out-degree)

Skor Surge = kecepatan × in-degree

Berapa banyak pekerjaan yang mengalir ke bawah saat botol ini bersih. Sebuah node dengan in-degree 5 (5 dependensi upstream semuanya mengirimkannya) dan kecepatan 100× menghasilkan 500× surge downstream.


Betweenness = in-degree + out-degree

Seberapa sentral stasiun kerja ini terhadap aliran total. Betweenness tinggi berarti banyak jalur melewati node ini.


Dua arketipe:


Node pekerja: tinggi betweenness, tinggi skor surge. Ini adalah botol yang menghalangi. Setiap antrian upstream mengalami keterbelakangan karena hal ini. Keluarkan botol ini tanpa menyiapkan kapasitas downstream, dan segala sesuatu downstream akan mengalami kolaps sekaligus.


Node pemakan: tinggi out-degree, rendah skor surge. Mengkonsumsi segala yang diberikan padanya. Tidak merasakan kesakitan karena botolnya adalah internal, bukan melalui. Mesin yang lupa untuk berhenti - pekerjaan masuk, tidak ada yang keluar, dan node melaporkan 'sibuk' selamanya.

MOAD-0001 & MOAD-0005: Kasus Kopling

Kasus GHC

Sebelum patch MOAD-0001 dalam pengaturan dependensi GHC: N=50,000 dependensi membutuhkan 17 menit untuk dibangun. Setelah: 10 detik. Speedup: 100×.


Apa yang terjadi di bawah? Setiap cache build, tempat penyimpanan artifact, & runner CI yang sebelumnya menyesuaikan diri untuk 17-menit batch tiba-tiba kini menerima 100× lebih banyak build selesai per jam. Cache yang dirancang untuk menghandle 60 artifact build per jam sekarang menerima 6,000.


Ini adalah MOAD-0005: kegagalan stempel cache. Setiap kunci cache terlewatkan secara bersamaan karena tidak ada cache yang dipanaskan sebelum kedatangan laju tiba baru. Perbaikan untuk MOAD-0001 memproduksi MOAD-0005.


Kopling ini tidaklah kebetulan. Ini adalah struktural. Setiap speedup O(N²) → O(N) dengan in-degree > 1 menghasilkan skor surge di atas 1. Skor surge di atas 100 adalah kandidat MOAD-0005.

Pengadaan Sebelum Pengungkapan

Sistem bangun memproses 1,000 grafik dependensi paket per jam. Anda mempatch MOAD-0001 dalam peramban grafiknya, mengurangi waktu bangun dari 60 menit menjadi 30 detik - speedup 120×. Sistem ini sekarang memproses 120,000 grafik per jam.

Namai sistem downstream yang paling berisiko terhadap MOAD-0005 setelah patch ini, dan jelaskan perbaikan yang Anda siapkan sebelum mengungkapkannya.

Kapan Berhenti: Syarat Henti

Syarat Henti

Sebuah patch memenuhi syarat henti — artinya: jangan mengungkapkan — ketika empat kondisi ini terpenuhi secara bersamaan:


1. Patch ada di sistem hidup (dimerger, dideploy)

2. Tidak ada penjaga yang ditugaskan untuk mengendalikan dampak hilir

3. Defek hilir (MOAD-0005) belum terpecahkan

4. Kenaikan kecepatan >= 100×


Semua empat bersama = bayi menangis. Tugaskan tim sebelum merge, bukan setelah.


Node tanpa penjaga berjalan seperti stasiun kerja tanpa pekerja. Kerja mengumpul. Seseorang kollaps. Prinsip komputer permana: Anda tidak memperbaiki algoritma pengiriman tanpa mengatur driver. Tiga driver, tiga juta orang: melepaskan algoritma menghasilkan pasukan guntur dari permintaan yang tidak terlayani daripada pengiriman yang lebih cepat.

WALL-E: Penikmat Lebihan & Pekerja Keras

Model WALL-E

WALL-E Pixar menggambarkan kegagalan model pabrik dalam bentuk yang paling jelas. Penikmat lebihan pada kursi melayang, diberi makan tanpa gesekan. Pekerja keras — WALL-E, EVE — mati di stasiun kerjanya untuk menjaga pakan berjalan.


Node penikmat lebihan (manusia pada kursi melayang) memiliki derajat keluar maksimum: ia mengkonsumsi segala yang diberikan kepadanya, tidak menghasilkan apa-apa. Skor lonjakanannya nol — ia adalah sumber. Ia tidak merasakan sakit karena tidak ada yang terkumpul di outputnya. Ia hanya mengkonsumsi.


Node pekerja keras (WALL-E) memiliki maksimum antara: segala sesuatu mengalir melaluinya. Ia menyerap semua input. Ia menghasilkan satu-satunya output. Jika pernah digantikan oleh model yang lebih cepat, skor lonjakanannya akan membanjiri setiap antrean hilir secara bersamaan.


Kerusakan dalam sistem WALL-E bukan penikmat lebihan. Itu adalah penjaga yang tidak ada: tidak ada yang ditugaskan untuk membalikkan stasiun kerja. Tidak ada yang mengatur kapasitas sebelum menjalankan algoritma.

Kasus pip: Daftar Persiapan Sebelum Pengungkapan

Anda menemukan MOAD-0001 dalam resolver ketergantungan pip Python. Kenaikan kecepatan yang diukur: 200×. Pip berjalan pada sekitar 400 juta instalasi per hari. PyPI melayani paket-paket tersebut.

Sebelum mengungkapkan patch ini, daftarkan tiga hal yang harus Anda konfirmasi atau mulai, dan jelaskan apa yang rusak jika Anda melewatkan setiap satu.