System ပြန်တက်လာပြီဆိုတာ Incident ပြီးသွားပြီလား?

“Server restart လုပ်လိုက်တော့ System ပြန်တက်လာပြီ။ ပြီးပြီလား?”

အသုံးပြုသူတွေ ပြန်ဝင်နိုင်လာတာက အရေးကြီးဆုံး ပထမအဆင့်ပါ။ ဒါပေမယ့် Service ပြန်ရလာတာနဲ့ Incident အပြီးသတ်သွားပြီလို့ မယူဆသင့်ပါဘူး။

Restart လုပ်တာက လက္ခဏာကို ခဏပျောက်စေနိုင်ပေမယ့် အကြောင်းရင်းကို မဖြေရှင်းရသေးနိုင်ပါတယ်။ Database connection ပြည့်သွားတာ၊ Memory မလုံလောက်တာ၊ Request များလွန်းတာ၊ အလုပ်တစ်ခု ထပ်ခါတလဲလဲပြေးနေတာ စတဲ့အကြောင်းရင်းက ဆက်ရှိနေရင် အချိန်အနည်းငယ်အကြာမှာ ပြန်ဖြစ်နိုင်ပါတယ်။

Incident ကို ကိုင်တွယ်ခြင်းမှာ “System ပြန်တက်အောင်လုပ်ခြင်း” နဲ့ “ဘာကြောင့်ဖြစ်ခဲ့သလဲ၊ ထပ်မဖြစ်အောင် ဘာလုပ်မလဲ” ဆိုတာ နှစ်ပိုင်းရှိပါတယ်။

ပထမဆုံး ရည်ရွယ်ချက် — Service ကို တည်ငြိမ်အောင်လုပ်ပါ

အရေးပေါ်အချိန်မှာ အကြောင်းရင်းအားလုံးကို တစ်ခါတည်းရှာဖို့ထက် သက်ရောက်မှုကို လျှော့ချပြီး အသုံးပြုသူတွေ ပြန်သုံးနိုင်အောင်လုပ်ဖို့ ဦးစားပေးရပါတယ်။

အခြေအနေအလိုက်—

• မမှန်တဲ့ Release ကို Rollback လုပ်ခြင်း
• ပြဿနာဖြစ်စေတဲ့ Feature ကို ခဏပိတ်ခြင်း
• Request များလွန်းရင် ကန့်သတ်ခြင်း
• မပြီးနိုင်တဲ့ Job ကို ခဏရပ်ခြင်း
• ကျန်းမာနေတဲ့ Instance ဆီ Traffic လွှဲခြင်း
• လိုအပ်တဲ့ Service ကို Restart လုပ်ခြင်း

စတဲ့ Recovery action တွေ အသုံးပြုနိုင်ပါတယ်။

ဒီလုပ်ဆောင်ချက်တွေက အားလုံးအတွက် တူညီတဲ့အဖြေမဟုတ်ပါဘူး။ အရေးကြီးတာက ပြောင်းလဲမှုတစ်ခုစီရဲ့ Risk ကို သိပြီး ဘယ်သူက ဘာလုပ်ခဲ့သလဲ မှတ်ထားဖို့ပါ။

Restart က ဖြေရှင်းချက်လား၊ လက္ခဏာကို ဖျောက်တာလား?

Restart လုပ်ပြီး Service ပြန်ရလာတယ်ဆိုတာ အသုံးဝင်တဲ့ သက်သေတစ်ခုပါ။ ဒါပေမယ့် Root Cause အဖြစ် မသတ်မှတ်နိုင်သေးပါဘူး။

ဥပမာ Database connection အားလုံး အသုံးပြုနေတယ်ဆိုပါစို့။ Application restart လုပ်လိုက်တဲ့အခါ connection တွေ ပြန်လွတ်ပြီး System ခဏကောင်းလာနိုင်ပါတယ်။

ဒါပေမယ့်—

• Connection ကို ပြန်မပိတ်တဲ့ Code ရှိသလား။
• Slow query ကြောင့် connection ကြာကြာကိုင်ထားသလား။
• Traffic ရုတ်တရက်များသွားသလား။
• Worker အရေအတွက်နဲ့ connection pool မကိုက်သလား။
• Database ကို တိုက်ရိုက်သုံးတဲ့ Job များ တစ်ချိန်တည်း ပြေးနေသလား။

ဆိုတာ မသိရသေးပါဘူး။

Restart အောင်မြင်ခြင်းက Recovery action အောင်မြင်တာပါ။ Root Cause တွေ့ပြီလို့ မဆိုလိုပါဘူး။

အရေးပေါ်အချိန်မှာ Evidence မပျောက်စေပါနဲ့

အလျင်လိုနေတဲ့အချိန်မှာ Log ဖျက်တာ၊ Container အသစ်နဲ့ အစားထိုးတာ၊ Server restart လုပ်တာတွေကြောင့် စစ်ဆေးဖို့လိုတဲ့ Evidence ပျောက်သွားနိုင်ပါတယ်။

Action မလုပ်ခင် အချိန်ရရင် အနည်းဆုံး—

• Error စတင်ဖြစ်တဲ့အချိန်
• Error message နဲ့ Request ID
• CPU၊ Memory၊ Disk နဲ့ connection count
• လတ်တလော Deploy/Configuration ပြောင်းလဲမှု
• ထိခိုက်နေတဲ့ Endpoint သို့မဟုတ် Feature
• Queue နဲ့ background job အခြေအနေ
• Application၊ Database နဲ့ Proxy log အပိုင်း
• ကိုယ်လုပ်မယ့် Recovery action

တို့ကို မှတ်ထားပါ။

စကားဝှက်၊ Access token နဲ့ ဖောက်သည်အချက်အလက်တွေကို Screenshot သို့မဟုတ် Chat group ထဲ မလိုအပ်ဘဲ မကူးပို့သင့်ပါဘူး။ Evidence ကို သတ်မှတ်ထားတဲ့ လုံခြုံတဲ့နေရာမှာ ထိန်းသိမ်းဖို့လိုပါတယ်။

“Down” နဲ့ “Recovered” ကြားမှာ Status အဆင့်တွေရှိတယ်

System တစ်ခုလုံးပိတ်သွားမှ Incident ဖြစ်တာ မဟုတ်ပါဘူး။ တချို့ Feature ပဲမရတာ၊ နှေးသွားတာနဲ့ Data နောက်ကျတာတွေ ဖြစ်နိုင်ပါတယ်။

Status	အဓိပ္ပာယ်
Investigating	ပြဿနာကို အတည်ပြုပြီး အကြောင်းရင်းနဲ့ သက်ရောက်မှုကို စစ်နေတယ်
Identified	ဖြစ်စေတဲ့အကြောင်း သို့မဟုတ် အဓိကလမ်းကြောင်းကို တွေ့ထားတယ်
Mitigating	ထိခိုက်မှုလျှော့ချဖို့ Recovery action လုပ်နေတယ်
Monitoring	Service ပြန်ရပြီး တည်ငြိမ်မှုကို စောင့်ကြည့်နေတယ်
Resolved	သတ်မှတ်ထားတဲ့ စစ်ဆေးချက်တွေ အောင်မြင်ပြီး Incident ကို ပိတ်နိုင်တယ်
Follow-up	Root Cause နဲ့ ထပ်မဖြစ်အောင်လုပ်မယ့်အလုပ်တွေ ဆက်လုပ်နေတယ်

Service တစ်ခါပြန်တက်တာနဲ့ Resolved မလုပ်ဘဲ အချိန်အနည်းငယ် Monitoring လုပ်တာ ပိုသင့်တော်နိုင်ပါတယ်။ အချိန်ဘယ်လောက်စောင့်မလဲဆိုတာ System နဲ့ Error ပုံစံအလိုက် သတ်မှတ်ရပါတယ်။

ပြန်ကောင်းလာပြီဆိုတာ ဘယ်လိုအတည်ပြုမလဲ?

Homepage ပွင့်ရုံနဲ့ လုံလောက်ချင်မှ လုံလောက်ပါမယ်။ လုပ်ငန်းအတွက် အဓိက Workflow ကို စစ်ပါ။

ဥပမာ Clinic Booking System ဆိုရင်—

1. လူနာက Booking စာမျက်နှာ ဖွင့်နိုင်သလား။
2. Booking အသစ် တင်နိုင်သလား။
3. ဝန်ထမ်း Dashboard မှာ အသစ်ဝင်လာသလား။
4. Queue နဲ့ Notification အလုပ်လုပ်သလား။
5. Database မှာ Record တစ်ကြိမ်ပဲ မှန်မှန်သိမ်းသလား။
6. Error rate နဲ့ response time ပြန်တည်ငြိမ်သလား။

Test လုပ်တဲ့အခါ Production Data ကို အန္တရာယ်မဖြစ်စေမယ့် နမူနာအကောင့်နဲ့ သတ်မှတ်ထားတဲ့ စမ်းသပ်နည်းကို သုံးသင့်ပါတယ်။

Timeline ရေးထားရင် မှတ်ဉာဏ်အပေါ် မမှီတော့ဘူး

Incident ပြီးမှ လူတိုင်းကို ပြန်မေးပြီး အချိန်ခန့်မှန်းရတာ မတိကျနိုင်ပါဘူး။ ဖြစ်နေစဉ်ကတည်းက အချိန်လိုက် မှတ်ပါ။

ဥပမာ—

အချိန်	ဖြစ်ရပ်
16:05	Monitoring မှ Error rate မြင့်ကြောင်း တွေ့
16:08	အသုံးပြုသူ ဝင်မရကြောင်း အတည်ပြု
16:15	Database connection ပြည့်နေကြောင်း တွေ့
16:22	Traffic ကန့်သတ်ပြီး Worker တချို့ ခဏရပ်
16:28	Service ပြန်ရ၊ Monitoring စတင်
16:50	အဓိက Workflow စစ်ဆေးမှု အောင်မြင်

ဒါက နမူနာ Timeline သာ ဖြစ်ပါတယ်။ အရေးကြီးတာက ဘယ်အချိန်မှာ ဘာသိခဲ့သလဲ၊ ဘာလုပ်ခဲ့သလဲနဲ့ ရလဒ်ဘာဖြစ်သလဲကို ခွဲရေးဖို့ပါ။

Root Cause နဲ့ Trigger ကို မရောပါနဲ့

Traffic ရုတ်တရက်များလာတာက Trigger ဖြစ်နိုင်ပါတယ်။ ဒါပေမယ့် Request အနည်းငယ်တိုးတာနဲ့ System ပျက်သွားရတဲ့အကြောင်းက အခြားနေရာမှာ ရှိနိုင်ပါတယ်။

Root Cause Analysis မှာ—

• ဘာဖြစ်ခဲ့သလဲ။
• ဘယ် Component က ပထမဆုံး မအောင်မြင်ခဲ့သလဲ။
• ဘာကြောင့် အခြား Component တွေဆီ ပြန့်သွားသလဲ။
• Monitoring က ဘာကြောင့် စောစောမသိခဲ့သလဲ။
• Recovery က ဘာကြောင့် ကြာခဲ့သလဲ။
• ဘယ်ကာကွယ်မှု မရှိခဲ့သလဲ သို့မဟုတ် မအလုပ်လုပ်ခဲ့သလဲ။

ကို အဆင့်လိုက်မေးပါ။

လူတစ်ယောက် “မှားနှိပ်မိတာ” ကို အဆုံးသတ်အဖြေအဖြစ် မထားသင့်ပါဘူး။ အန္တရာယ်ရှိတဲ့ Action ကို တစ်ချက်နှိပ်ရုံနဲ့ လုပ်နိုင်တာ၊ Review မလိုတာ၊ Rollback မရှိတာတွေကလည်း System design နဲ့ Process အပိုင်းက အကြောင်းရင်းတွေ ဖြစ်နိုင်ပါတယ်။

Post-incident review က အပြစ်ရှာတဲ့အစည်းအဝေး မဟုတ်ပါဘူး

Review ရဲ့ရည်ရွယ်ချက်က နောက်တစ်ကြိမ် ပိုမြန်မြန်သိနိုင်ဖို့၊ သက်ရောက်မှုလျှော့ချဖို့နဲ့ ပြန်လည်ကောင်းမွန်အောင်လုပ်ရလွယ်ဖို့ပါ။

Review မှာ—

• Incident အကျဉ်းချုပ်
• အသုံးပြုသူနဲ့ လုပ်ငန်းအပေါ် သက်ရောက်မှု
• Timeline
• Root Cause နဲ့ ပါဝင်ကူညီခဲ့တဲ့အချက်များ
• ကောင်းစွာလုပ်နိုင်ခဲ့တာ
• ပိုကောင်းအောင်လုပ်ရမယ့်အရာ
• Action Items

တို့ကို မှတ်တမ်းတင်နိုင်ပါတယ်။

မသေချာတာကို သေချာသလို မရေးပါနဲ့။ “အခုထိ မသိရသေး” ဆိုတာလည်း မှန်ကန်တဲ့အခြေအနေတစ်ခုပါ။

Action Item က “စောင့်ကြည့်မယ်” ဆိုတာထက် ပိုတိကျရမယ်

“Monitoring ကောင်းအောင်လုပ်မယ်” ဆိုတာ လုပ်ဆောင်ဖို့ မလုံလောက်သေးပါဘူး။

Action Item တစ်ခုမှာ—

• တိကျတဲ့အလုပ်
• တာဝန်ခံ
• ဦးစားပေးအဆင့်
• ပြီးရမယ့်အချိန်
• ပြီးပြီလို့ သတ်မှတ်မယ့် Acceptance criteria

ရှိသင့်ပါတယ်။

ဥပမာ—

မရှင်းတဲ့ Action	တိကျတဲ့ Action
Database ကို စောင့်ကြည့်မယ်	Connection usage 80% ကျော်ရင် Alert ပို့ပြီး Dashboard မှာ active/idle count ပြမယ်
Performance ပြင်မယ်	Slow query နှစ်ခုကို Index နဲ့ Query plan စစ်ပြီး load test အောင်မြင်ကြောင်း မှတ်တမ်းတင်မယ်
Restart မဖြစ်အောင်လုပ်မယ်	Connection leak test ထည့်ပြီး pool exhaustion ဖြစ်တဲ့ Integration test ရေးမယ်
Team ကို သင်ပေးမယ်	Recovery runbook ရေး၊ တာဝန်ခံနှစ်ဦးနဲ့ drill လုပ်ပြီး ပြန်သုံးသပ်မယ်

Action Item တွေကို သာမန် Backlog ထဲ ထည့်ပြီး မေ့မသွားအောင် Incident နဲ့ ချိတ်ထားသင့်ပါတယ်။

အားလုံးကို တစ်ခါတည်းပြင်ရမလား?

Incident တစ်ခုက တိုးတက်စရာအများကြီး ဖော်ပြနိုင်ပါတယ်။ အားလုံးကို ချက်ချင်းလုပ်ဖို့ မဖြစ်နိုင်ပါဘူး။

အောက်ပါအစီအစဉ်နဲ့ ဦးစားပေးနိုင်ပါတယ်။

1. ထပ်ဖြစ်နိုင်ခြေမြင့်ပြီး သက်ရောက်မှုကြီးတဲ့ အကြောင်းရင်း
2. စောစောသိနိုင်စေမယ့် Alert နဲ့ Monitoring
3. ထိခိုက်မှုမပြန့်အောင် ကန့်သတ်မယ့် Guardrail
4. Recovery မြန်စေမယ့် Runbook နဲ့ Automation
5. ရေရှည် Architecture ပြောင်းလဲမှု

ယာယီဖြေရှင်းချက်ကို အမြဲတမ်းဖြေရှင်းချက်လို့ မထားဘဲ Follow-up အလုပ်နဲ့ ချိတ်ထားပါ။

Incident တစ်ခုမဖြစ်ခင် ပြင်ဆင်ထားနိုင်တာများ

• အဓိက Workflow အတွက် Health check ရှိခြင်း
• Error rate၊ response time နဲ့ resource usage Alert များ
• Deploy နဲ့ Configuration ပြောင်းလဲမှု Timeline
• Backup ကို ပြန်သွင်းစမ်းထားခြင်း
• Rollback နည်းလမ်း
• တာဝန်ခံနဲ့ ဆက်သွယ်ရမယ့်လမ်းကြောင်း
• Incident မှတ်တမ်း Template
• Recovery Runbook
• Test account နဲ့ Smoke test အဆင့်များ

ဒီအရာတွေရှိရင် Incident လုံးဝမဖြစ်တော့တာ မဟုတ်ပါဘူး။ ဖြစ်လာတဲ့အခါ ခန့်မှန်းပြီးလုပ်ရတာ လျော့စေပါတယ်။

ဒီနေ့ စမ်းကြည့်ရန်

အရင်က System ပြဿနာတစ်ခုကို ပြန်စဉ်းစားပြီး မေးခွန်းလေးခု ဖြေကြည့်ပါ။

1. အသုံးပြုသူတွေ ဘာတွေ မလုပ်နိုင်ခဲ့သလဲ။
2. Service ပြန်ရအောင် ဘာလုပ်ခဲ့သလဲ။
3. Root Cause ကို ဘာသက်သေနဲ့ သတ်မှတ်ခဲ့သလဲ။
4. ထပ်ဖြစ်ရင် စောစောသိပြီး မြန်မြန်ပြန်ကောင်းဖို့ ဘာပြောင်းထားသလဲ။

အဖြေက “Restart လုပ်လိုက်တော့ရသွားတယ်” မှာပဲ ရပ်နေရင် Incident follow-up လိုအပ်နေသေးပါတယ်။

မိမိလုပ်ငန်းနဲ့ ချိတ်ဆက်ဆွေးနွေးရန်

လက်ရှိ Software မှာ ပြဿနာဖြစ်တိုင်း Restart လုပ်ပြီး ပြန်ဖြစ်လာတာကို စောင့်နေရခြင်း၊ Error ဖြစ်မှ အသုံးပြုသူပြောလာတာနဲ့ Recovery လုပ်မယ့်အဆင့် မရှင်းခြင်းတို့ ရှိနေပါက Incident response နဲ့ monitoring အကြောင်း ဆက်သွယ်မေးမြန်းရန် ကနေ System အမျိုးအစားနဲ့ ဖြစ်နေတဲ့အခက်အခဲကို ပြောပြနိုင်ပါတယ်။ ဆွေးနွေးမှုစဖို့ စကားဝှက်၊ Access token၊ ဖောက်သည်ဒေတာနဲ့ Log အပြည့်အစုံ ပေးပို့ဖို့ မလိုပါဘူး။