Sistemi, Bileşenlerini Optimiz edin
Hamming'in Sistem Mühendisliği İlkeleri
Hamming'in temel prensibi Ch. 28'den: Bileşenleri optimize ederse, muhtemelen sistemi performansı bozacaksınız.
O, diferansiyel analizör hikayesiyle bunu gösterdi. İki birimi birleştirmeleri gerekiyordu. İnşaatçılar ikinci birimin amplifikatörlerini iyileştirdi. Kabul günü Hamming, standart testi çalıştı - y'' + y = 0 çözün, y'yi y' karşı plotlayın, bir daire bekleyin. Başarısız oldu. Neden: İyileştirilmiş amplifikatörler, zemine daha fazla akım çekti. Zemin, orijinal tasarım için yeterliydi. Yeni akım seviyesi için onaylanmamıştı. Arayüz bozuldu, bileşen değil.
Genellemesi: çoğu sistem hataları arayüzlere, bileşenlere değil, bağlıdır. Bileşenler tasarlanır, test edilir ve sertifikalandırılır. Arayüzler, bileşenlerin yeni arayüz davranışını tasarlamadan, nadiren test edilir ve bağımsız olarak sertifikalandırılmaz. Bir bileşen değiştirildiğinde, arayüz davranışı değişir. Aşağıya yönelik hiçbir şey bu yeni arayüz için tasarlanmamıştır.
Ana Asimetri: bir bileşeni 10 kat iyileştirmek, bir sınırlandırmalı arayüze beslendiyse, sistemi 10 kat geriletebilir. İyileştirme eklemeyi - sistemden çıkarır.
Eğitim Sistemi Kötü Sistem Mühendisliği olarak
Hamming'in Eğitim Olayı
Hamming, eğitimi de bu prensibe uyguladı. Bireysel ders notlarını optimize etmek - öğrencileri her ders için test performansı maksimuma çıkarmak için tekrarlama - öğrencilerin bireysel testlerde iyi puanlayabilmesine ama disiplinler arası bilgiyi entegrasyon sağlayamamasına neden oldu.
Her bileşen (ders notu) iyileştirildi. Sistem (eğitim, tanımlı entegre anlayış) bozuldu. Konular arası - öğrencinin bilgiyi disiplinler arası uygulayabilme yeteneği - asla optimize edilmedi. Bu atrofie oldu.
Bu, uygulama hatası değil, yapısal. Eğer bileşen performansı ölçer ve ödüllendirirsen, bileşen optimizasyonu elde edersin. Arayüzler, bileşen metriklerine görünmezdir.
Reçetesi: Sistemin bottleneğini bulun ve sonra ne zaman kaldırılırsa alt kuyrukların taşır ne olur sor. Bottleneck kaldırma, sonraki kuyruğu taşır. Bir kısıtlama kaldırıldığında yeni bir kısıtlamaya dönüştür.
Arayüz Bozulma İzlemesi
Hamming, bir bileşimin performansının artırılması durumunda arabirim davranışının değiştiğini gösterdi - ve geri kalan sistem, eski arabirim yüküne göre tasarlanmıştı.
Node'lar, Kuyruklar, Fırtınalar Skorları
Bir MOAD Fabrika Modeli
Her yazılım bağımlılık grafiği bir fabrika oluşturur. Her düğüm bir çalışma istasyonudur. Her kenar bir kuyruktur. Çalışma, düğümün kuyruğuna girer, işlenir ve alt kuyruklara akar.
Her düğüm için iki skor bulunur:
Surge puanı = hızı artırmak × giriş derecesi
Bu kısıtlama açılırken ne kadar fazla iş aşağıya akar. Bir düğümün giriş derecesi 5 (5 yukarıdan beslenen tümünü besler) ve 100x hızlanma üretirse, 500x surge üretir.
Betweenness = giriş derecesi + çıkış derecesi
Bu çalışma masasının toplam akışa ne kadar merkezi olduğunu gösterir. Yüksek betweenness, birçok yolun bu düğüm üzerinden geçtiği anlamına gelir.
İki arketip:
Workaholic düğüm: yüksek betweenness, yüksek surge puanı. Bu kısıtlama. Her şeyin 17 dakikada 10 saniyeye düşürülmesi, bu nedenle her şeyin 17 dakikalık batch gelişlerinin 100 katına çıkmasıdır. Hızlanma: 100x.
Glutton düğüm: yüksek çıkış derecesi, düşük surge puanı. İçsel kısıtlama, not throughput değil, beslenen her şeyi tüketir. Çalışma masası - iş girişi, hiçbiri çıkmaz ve düğüm 'daima meşgul' olarak raporlanır.
MOAD-0001 & MOAD-0005: Bir Kombine Durum
GHC Durumu
GHC'nin bağımlılık çözücüsüne bir MOAD-0001 patch öncesinde: N=50.000 bağımlılık 17 dakikada inşa edildi. Sonra: 10 saniye. Hızlanma: 100x.
Ne oluyo aşağıya? Her build cache, artifact store ve CI runner'ın 17 dakikalık batch gelişlerinin 100x daha hızlı tamamlanması için saatlik 100x daha fazla tamamlanmış build alması şimdi. 60 build artifact'a kadar tasarım yapan kollar şimdi 6.000 aliyor.
Bu MOAD-0005: önyükleme cache defecti. Her cache anahtarı, yeni gelme hızı için önceden ısıtılmamış olduğu için aynı anda aynı anda kaybeder. MOAD-0001'ın düzeltilmesi, MOAD-0005 üretir.
Bu kombine, tesadüfi değil. Yapısal. Giriş derecesi > 1 olan O(N²) → O(N) hızlanma ile surge puanı 1'den fazla üretir. 100'den fazla surge puanı, MOAD-0005 adayıdır.
Açıklama Öncesi Sahneleme
Bir build sistemi, saatlik 1.000 paket bağımlılık grafiği işler. MOAD-0001'i build süresini 60 dakikadan 30 saniyeye patch ederek, build süresini 120x hızlandırın. Sistem şimdi saatlik 120.000 grafiği işler.
Durdurma Koşulu Nerede: The Halt Condition
Durdurma Koşulu
Bir düzeltme, anlamı: açıklama yapma - durdurma koşulu karşılar - aynı anda dört koşul yerine getirirken:
1. Düzeltme canlı bir sistemde (birleştirilmiş, dağıtılmış)
2. Aşağıdaki etki sahipliği için bakıcı ataması yok
3. Aşağıdaki arıza (MOAD-0005) çözülmemiş
4. Hızlandırmak >= 100×
Dört tane birlikte = bebek ağlar. Ekibi birleştirmeden önce atayın, birleştirmeden sonra değil.
Bakıcı ataması olmayan bir düğüm, bir iş istasyonunda çalışan bir bilgisayar gibi çalışır. Çalışma birikir. Birisi çöker. Düzenli bilgisayar prensibi: gönderme algoritmasını düzeltmeden önce sürücüleri etiketleyin. Üç sürücü, üç milyon insan: algoritmayı bloklamak, daha hızlı teslimat yerine daha fazla talep karşılamayan bir yıldırıcı sürü yaratır.
WALL-E: Yemekseverler & Çalışkanlar
WALL-E Modeli
Pixar'ın WALL-E, fabrika modeli başarısızlığını en net şekilde gösterir. Yemeksever düğüm (insanlar hover sandalyelerde) maksimum çıkış derecesine sahiptir: ona beslenen her şeyi tüketir, hiçbir şey üretmez. Sürü skoru sıfır - bir uçurumdur. Şiddet hissetmez çünkü çıktı üzerinde bir şey birikmez. Sadece tüketir.
Çalışkan düğüm (WALL-E) maksimum arasında sahiptir: her şey onun üzerinden akar. Tüm girişi absorbe eder. Tek çıktı üretir. Sürü skoru, daha hızlı bir modele değiştirilirse, her alt akış kuyruğunu aynı anda sarsar.
WALL-E sistemindeki arıza, bakıcı eksikliğindedir: hiç kimse çalışma istasyonlarını dengede tutacak değildir. Hiç kimse algoritmayı çalıştırmadan önce kapasiteyi etiketlememiştir.
The defect in the WALL-E system is not the gluttons. It is the absent caretaker: no one assigned to balance the workstations. No one staged the capacity before running the algorithm.
The pip Durumu: Açıklama Öncesi Kontrol Listesi
Python'un pip bağımlılık çözücüsünde MOAD-0001 arızasını keşfedin. Hızlandırmak: 200×. pip yaklaşık olarak gün boyunca 400 milyon kurulum yapar. PyPI paketleri sunar.