Production Web App Error ကို စနစ်တကျ Debug လုပ်နည်း
အသုံးပြုသူပြောသည့် symptom မှစပြီး logs၊ request ID၊ recent changes နှင့် reproducible test တို့ဖြင့် အကြောင်းရင်းကိုအဆင့်လိုက်ရှာပါမယ်။
Problem
Production error ဖြစ်ချိန်မှာ ခန့်မှန်းပြီး code များစွာတစ်ပြိုင်နက်ပြင်ခြင်းက downtime တိုးပြီး အကြောင်းရင်းကိုပိုဖုံးကွယ်စေပါတယ်။
Requirements
- Application logs သို့ဝင်ခွင့်
- Deployment history
- Local သို့မဟုတ် staging environment
Symptom နဲ့ impact ကိုတိကျအောင်ရေးပါ
“Site ပျက်တယ်” ဆိုတာမလုံလောက်ပါဘူး။ ဘယ် URL၊ ဘယ် user group၊ ဘယ်အချိန်၊ ဘယ် browser မှာ ဖြစ်တယ်၊ response status ဘာလဲဆိုတာမှတ်ပါ။ Data loss သို့မဟုတ် security impact ရှိရင် feature ကိုယာယီပိတ်ရန်စဉ်းစားပါ။
Recent changes နှင့် logs ကိုချိတ်ဖတ်ပါ
Error စဖြစ်ချိန်နဲ့ deployment၊ configuration၊ database migration၊ provider incident တို့ကို timeline ပေါ်မှာနှိုင်းယှဉ်ပါ။ Request ID သို့ correlation ID ပါရင် client error နဲ့ server log ကိုတစ်ကြောင်းတည်းချိတ်နိုင်ပါတယ်။
Hypothesis တစ်ခုစီကိုအသေးဆုံးစမ်းပါ
ဖြစ်နိုင်ခြေစာရင်းရေးပြီး အမြန်ဆုံးပယ်နိုင်မယ့်အချက်ကစပါ။ Database down လား၊ secret ပျောက်လား၊ cache stale လားဆိုတာ တစ်ခုချင်းစမ်းပါ။ တစ်ခါတည်းပြောင်းလဲမှုများစွာမလုပ်ပါနဲ့။
Evidence မရှိဘဲ fix မလုပ်ပါနှင့်
Fix မတင်မီ error ဖြစ်ရတဲ့အကြောင်းရင်းနှင့် fix ပြီးရင် ဘာ metric ပြန်ကောင်းမယ်ဆိုတာ ရှင်းလင်းပါစေ။
Recover၊ verify နှင့် postmortem လုပ်ပါ
အန္တရာယ်အနည်းဆုံး recovery က rollback ဖြစ်နိုင်ပါတယ်။ Service ပြန်လာပြီးရင် original symptom၊ error rate နဲ့ key user flow ကိုပြန်စစ်ပါ။ နောက်ဆုံးမှာ root cause၊ detection gap နဲ့ ပြန်မဖြစ်ရန် action owner တွေကိုမှတ်တမ်းတင်ပါ။
Expected result
ခန့်မှန်းပြင်ဆင်ခြင်းအစား evidence၊ timeline နှင့် verification ပါသော repeatable debugging workflow ရရှိပါမယ်။
Troubleshooting
- Logs မလုံလောက်လျှင် PII မထည့်ဘဲ structured logging နှင့် request ID ကိုထည့်ပါ။
- Local မှာပြန်မဖြစ်လျှင် production config၊ data shape နှင့် network dependency ကွာခြားချက်ကိုစစ်ပါ။
- Rollback မရလျှင် database migration backward compatibility နှင့် deployment strategy ကိုပြန်သုံးသပ်ပါ။