Macam Mana Saya Debug Production Issue Tanpa Panik, Tanpa Main Teka

How I Debug Production Issues Tanpa Panik atau Guessing

Production down bukan masalah teknikal.
Ia masalah emosi + kaedah.

Kalau anda terus:

• refresh page 20 kali

• ubah code random

• deploy tanpa faham apa rosak

itu bukan debugging. Itu main taram je 🤣.

Ini flow sebenar saya.

1. Saya Tak Sentuh Code Dulu — Saya Tengok Apa Browser Nampak

First rule: percaya apa yang sampai ke browser, bukan apa yang anda rasa berlaku.

Buka Inspect Element → Network tab.

Kita cari:

• request yang fail (400 / 401 / 403 / 419 / 500)

• request yang slow gila

• payload yang tak sama macam local

Soalan yang saya jawab dulu:

• Request ni sampai ke server ke tak?

• Response mati dekat browser atau server?

• Data yang dihantar betul ke?

Kalau Network tab dah pelik, backend confirm terlibat.

2. Lepas Itu Baru Saya Buka Laravel Log

Laravel dah tolong banyak, jangan buat dia macam tak wujud.

storage/logs/laravel.log

Saya scan ikut urutan masa:

• error time sama dengan request dalam Network tab

• exception type (Validation, Auth, Model, Query)

• function / file name yang disebut

Ini penting:

Saya tak baca semua.
Saya cari pattern, bukan ayat panjang.

Kalau error cakap:

Call to a member function on null

Saya tak fikir “kenapa null”.
Saya fikir:

“Kenapa benda ni sepatutnya wujud, tapi tak wujud?”

3. Kalau Laravel Log Senyap — Saya Terus Lompat ke Nginx Log

Bila Laravel tak jerit, selalunya server yang bisik.

Saya buka:

• access.log → request sampai atau tidak

• error.log → permission, timeout, upstream, memory

Contoh red flag:

• upstream timed out

• permission denied

• client intended to send too large body

Benda ni takkan muncul dalam Laravel log.
Kalau anda ignore Nginx log, anda debug separuh jalan.

4. Saya Zoom Masuk ke Function atau Proses Paling Hampir Dengan Bug

Ini part paling ramai skip.

Saya tanya:

• Request ni trigger function mana sebenarnya?

• Flow dia sync ke async?

• Ada job / queue / observer / event terlibat?

Saya tak trace satu app.
Saya trace satu laluan sahaja.

Contoh:

User submit form → controller → service → payment API → database update

Kalau fail, saya potong satu-satu:

• sebelum API call

• selepas API call

• sebelum save

• selepas save

Debug bukan cari bug.
Debug ialah mengecilkan kemungkinan.

5. Saya Tak Percaya “It Works on My Machine”

Production bukan local.

Beza yang selalu bunuh:

• env variable tak wujud

• cache lama

• permission storage

• queue worker mati

• config tak di-reload

So sebelum salahkan code, saya check:

• .env betul?

• php artisan config:clear

• queue jalan atau tak?

• server restart pernah dibuat atau tidak?

Penutup: Debugging Bukan Panic Skill, Tapi Thinking Skill

Orang panik sebab:

• tak ada flow

• lompat sana sini

• cuba selesaikan cepat tanpa faham punca

Saya tak genius.
Saya cuma tak teka.

Saya ikut bukti:
Browser → Log → Server → Function → Proses

Kalau anda buat benda yang sama,
production issue akan jadi routine, bukan mimpi ngeri.