Status Page တည်ဆောက်နည်း - Components၊ Incidents နှင့် Uptime စစ်ဆေးခြင်း

Status page သည် သင့်အသုံးပြုသူများအား သင့်ဝန်ဆောင်မှု အလုပ်လုပ်နေသလား ဆိုတာကို နေရာတစ်ခုတည်းတွင် ပြောပြပေးသည်။ တည်ဆောက်ရန် ဝန်ဆောင်မှုအစိတ်အပိုင်းများ (website၊ API၊ payments၊ email) စာရင်း၊ အစိတ်အပိုင်းတစ်ခုချင်းစီ၏ လက်ရှိအခြေအနေ၊ အချိန်တံဆိပ်ပါသော update များပါသည့် incidents၊ ယခင် incidents မှတ်တမ်းနှင့် ပြဿနာများကို မစောင့်ဘဲ သိနိုင်ရန် subscription (ရွေးချယ်စရာ) တို့ လိုအပ်သည်။ စာမျက်နှာကိုယ်တိုင်မှာ ရိုးရှင်းပါသည်။ အရေးကြီးဆုံး ဆုံးဖြတ်ချက်မှာ ဘယ်နေရာတွင် run မလဲ ဆိုတာဖြစ်သည်။ Status page သည် သင့် app ကျသွားချိန်တွင်ပင် ဆက်ရှိနေရမည်ဖြစ်သောကြောင့် ၎င်းအကြောင်း တင်ပြသော အရာနှင့် hosting၊ database သို့မဟုတ် deploy pipeline ကို မျှဝေသင့်ပါ။

Status page ၏ ရည်ရွယ်ချက်

တစ်ခုခု ပျက်သွားသည့်အခါ အသုံးပြုသူများက အချက်သုံးချက် သိချင်သည် - ကျွန်ုပ်တစ်ယောက်တည်း ကြုံနေရတာလား၊ သင်သိနေပြီလား၊ ဘယ်အချိန် ပြင်မလဲ။ Status page သည် support tickets အများအပြား မလာဘဲ ဤအချက်သုံးချက်စလုံးကို ဖြေပေးသည်။ ထို့အပြင် ရှင်းလင်းသော ပြန်လည်ရေးသားချက်များပါသည့် မြင်သာသော incident မှတ်တမ်းသည် ပြဿနာများကို သင်မည်သို့ ကိုင်တွယ်သည်ကို ပြသကာ အချိန်ကြာလာသည်နှင့်အမျှ ယုံကြည်မှု တည်ဆောက်ပေးသည်။

၎င်းသည် changelog မဟုတ်ပါ။ Feature အသစ်များကို changelog စာမျက်နှာ တွင် ထားပါ။ Outage နှင့် ပြုပြင်ထိန်းသိမ်းမှုများကို ဤနေရာတွင် ထားပါ။

Page လိုအပ်ချက်များ

Data

Component အခြေအနေများမှာ များသောအားဖြင့် တိုတိုသော ပုံသေစာရင်းဖြစ်သည် - Operational၊ Degraded performance၊ Partial outage၊ Major outage၊ Under maintenance။

စာမျက်နှာများ

• အများပြည်သူ status စာမျက်နှာ: အလုံးစုံ banner ("All systems operational" သို့မဟုတ် အဆိုးဆုံး လက်ရှိအခြေအနေ)၊ အခြေအနေနှင့်အတူ component တစ်ခုချင်းစီ၊ update များပါသော active incident တစ်ခုခု၊ လာမည့် maintenance၊ စစ်ဆေးမှုဒေတာရှိလျှင် ရက် ၉၀ history အစင်းကြောင်း။
• Incident စာမျက်နှာ: Incident တစ်ခု၏ update အပြည့်အစုံ timeline၊ support က link ချိတ်နိုင်ရန် ကိုယ်ပိုင် URL ပါသည်။
• History: လအလိုက် ယခင် incidents။
• Subscribe: အတည်ပြုချက်နှင့် component အလိုက် ဦးစားပေးမှုပါသော email စာရင်းသွင်းခြင်း။
• Admin: incident ဖန်တီးခြင်း၊ update တင်ခြင်း၊ component အခြေအနေပြောင်းခြင်း၊ maintenance စီစဉ်ခြင်း။

ခွင့်ပြုချက်များ

လူအများက ထုတ်ဝေထားသမျှကို မြင်ရသည်။ သင့် team က သာ တင်နိုင်သည်။ ဖြစ်နိုင်လျှင် admin login ကို app ၏ main login system နှင့် သီးခြားထားပါ။ သင့် auth provider ပျက်သွားသည့် outage ကြောင့် သင့်ကိုယ်ပိုင် status page မှ ပိတ်ထားခြင်း မခံရစေရန်ဖြစ်သည်။

အဓိက ဆုံးဖြတ်ချက် - သီးခြားထားပါ

ကိုယ်တိုင်ပြုလုပ်သော status page အများစု ပျက်ကွက်ရာ နေရာဖြစ်သည်။ သင့် status page သည်-

• သင့် app နှင့် server သို့မဟုတ် hosting account တူတူပေါ်တွင် ရှိလျှင်၊
• app နှင့် database တူတူမှ ဖတ်လျှင်၊
• domain setup သို့မဟုတ် CDN configuration တူတူနောက်ကွယ်တွင် ရှိလျှင်၊
• သို့မဟုတ် pipeline တူတူဖြင့် deploy လုပ်လျှင်၊

အဲဒီအခါ outage များစွာက ၎င်းကိုပါ ဖြုတ်ချနိုင်ပြီး လူများ အလိုအပ်ဆုံးအချိန်တွင် ဖြစ်သည်။ လက်တွေ့ အဆင့်များ-

• သီးခြား hosting။ Main app နှင့် မတူသော project သို့မဟုတ် provider ။
• ကိုယ်ပိုင် subdomain ဥပမာ status.example.com၊ DNS တွင် သီးခြား ညွှန်ပြထားရန်။ domains နှင့် DNS အလုပ်လုပ်ပုံ ကို ကြည့်ပါ။
• ကိုယ်ပိုင် data။ Incidents များကို status page ၏ ကိုယ်ပိုင် storage တွင် သိမ်းပါ၊ app database တွင် မဟုတ်ပါ။
• Static fallback။ အချို့ team များက public page ကို static လုပ်ပြီး update တိုင်း ပြန် build လုပ်သဖြင့် ပျက်စီးစရာ အလွန်နည်းသည်။

လက်ဖြင့် update သို့မဟုတ် အလိုအလျောက် စစ်ဆေးခြင်း

လက်ဖြင့် (ဤနေရာမှ စပါ)

သင့် team က admin page မှ incidents တင်ပြီး component အခြေအနေများကို လက်ဖြင့် ပြောင်းပါသည်။ လက်တွေ့တွင် status page အများစု ဤနည်းဖြင့် အလုပ်လုပ်သည်၊ အကြောင်းမှာ လူ၏ ဆုံးဖြတ်ချက် ("ကတ်အချို့အတွက် payment နှေးနေသည်") သည် အလိုအလျောက် အနီရောင်အစက်တစ်ခုထက် ပိုအသုံးဝင်သောကြောင့်ဖြစ်သည်။

ပြဿနာများကို အမြန်သိရှိရန် app ကို မိနစ်တိုင်း သို့မဟုတ် ခန့်မှန်းခြေ စစ်ဆေးပြီး email၊ SMS သို့မဟုတ် chat ဖြင့် သတိပေးသော ပြင်ပ uptime monitor ကို သုံးပါ။ Monitoring ဝန်ဆောင်မှု အများအပြားတွင် အခမဲ့ tier ရှိသည်။

အလိုအလျောက်

အလိုအလျောက်ဆိုသည်မှာ တစ်ခုခုက အစိတ်အပိုင်းတစ်ခုချင်းစီကို ပုံမှန် စစ်ဆေးပြီး status ကို update လုပ်ခြင်းဖြစ်သည်။ ၎င်းအတွက် schedule ဖြင့် run သော code လိုအပ်ပြီး သင့် main app ၏ infrastructure အပြင်မှ ဖြစ်ရမည်။ အသုံးများသော ပုံစံနှစ်မျိုး-

• ပြင်ပ monitor တစ်ခုက စစ်ဆေးမှု ကျသွားသည့်အခါ သို့မဟုတ် ပြန်ကောင်းလာသည့်အခါ webhook ဖြင့် သင့် status page ကို ခေါ်ပြီး component ကို update လုပ်စေခြင်း။
• Status page ၏ ကိုယ်ပိုင် hosting ရှိ scheduled job တစ်ခုက component တစ်ခုချင်းစီကို ping လုပ်ပြီး ရလဒ်ကို မှတ်တမ်းတင်ခြင်း။ မှီခိုမီ သင့် hosting က scheduled task များကို မည်သို့ ကိုင်တွယ်သည်ကို စစ်ပါ၊ background jobs run နည်း တွင် ရွေးချယ်စရာများ ရှင်းပြထားသည်။

အလိုအလျောက် ပြောင်းလဲမှုများသည် network နှေးသည့်အခါ (တက်၊ ကျ၊ တက်) ခုန်ပေါက်နိုင်သည်။ Status ပြောင်းမီ ပျက်ကွက်မှု နှစ်ကြိမ် သို့မဟုတ် သုံးကြိမ် လိုအပ်အောင် သတ်မှတ်ပြီး major outage ကြေညာမီ လူတစ်ဦးက အတည်ပြုစေပါ။

Incident update ရေးနည်း

• စောစောပို့ပါ။ မိနစ်အနည်းငယ်အတွင်း "ဝင်ရောက်မှု ပျက်ကွက်မှု အစီရင်ခံချက်များကို စုံစမ်းနေသည်" ဟု ပြောခြင်းသည် နာရီတစ်ခုကြာမှ ပြီးပြည့်စုံသော စာတစ်စောင်ထက် ပိုကောင်းသည်။
• အသုံးပြုသူများ သတိထားမိသည့်အရာကို ပြောပါ၊ အတွင်းပိုင်းတွင် ဘာပျက်သွားသလဲ မဟုတ်ပါ။
• နောက် update အချိန်ကို ကတိပေးပြီး ထိုကတိကို ထိန်းပါ။
• ပြီးသွားသောအခါ အနှစ်ချုပ် တိုတိုဖြင့် ပိတ်ပါ - ဘာဖြစ်ခဲ့သလဲ၊ ဘယ်လောက်ကြာသလဲ၊ ဘာကို ပြောင်းလဲမည်လဲ။

အလုပ်ဖြစ်သော ပထမဆုံး prompt

Parcelio အက်ပ်အတွက် သီးခြား status page တစ်ခု တည်ဆောက်ပါ၊ status.parcelio.com တွင် သီးခြား host လုပ်ပါ။ Components - Website၊ Tracking API၊ Notifications၊ Payments၊ အခြေအနေတစ်ခုစီ Operational၊ Degraded performance၊ Partial outage၊ Major outage သို့မဟုတ် Under maintenance။ အများပြည်သူ စာမျက်နှာတွင် အဆိုးဆုံး လက်ရှိအခြေအနေကို သုံးသော အလုံးစုံ banner၊ component တစ်ခုချင်းစီ၏ အခြေအနေ၊ အချိန်တံဆိပ်ပါသော active incidents (နောက်ဆုံးက အပေါ်)၊ လာမည့် maintenance၊ လအလိုက် ယခင် incidents စာရင်း ပြပါ။ Incident တစ်ခုစီတွင် ကိုယ်ပိုင် စာမျက်နှာ ရှိပါစေ။ Password ဖြင့် ကာကွယ်ထားသော admin စာမျက်နှာတွင် incident ဖန်တီးခြင်း (ခေါင်းစဉ်၊ ထိခိုက်မှု၊ ထိခိုက်သော components)၊ update တင်ခြင်း (စာသားနှင့် အခြေအနေ Investigating၊ Identified၊ Monitoring၊ Resolved)၊ component အခြေအနေပြောင်းခြင်းနှင့် maintenance စီစဉ်ခြင်း ထည့်ပါ။ Component အမည်နှင့် up/down ကို လက်ခံသော၊ secret token ဖြင့် ကာကွယ်ထားသော POST /api/check-result endpoint တစ်ခု ထည့်ပါ၊ နောက်ဆက်တွဲ down သုံးကြိမ်ပြီးမှသာ component ကို Degraded ဟု မှတ်ပါ။ အားလုံးကို ဤ app ၏ ကိုယ်ပိုင် database တွင် သိမ်းပါ။ ရိုးရှင်း၊ တည်ငြိမ်သော ဒီဇိုင်း၊ ဖုန်းပေါ်တွင် မြန်မြန်ဖွင့်နိုင်ရမည်။

Build အဆင့်များ

1. အများပြည်သူ စာမျက်နှာနှင့် လက်ဖြင့် incidents ပါသော admin။ ဤတစ်ခုတည်းက အလုပ်လုပ်သော status page ဖြစ်သည်။
2. သီးခြား host လုပ်ပြီး subdomain ကို ညွှန်ပြပါ။
3. Incident စာမျက်နှာများနှင့် history။
4. Maintenance windows။
5. Subscriptions။ Double opt-in email စာရင်းသွင်းခြင်းနှင့် incident အသစ်/update များအတွက် အကြောင်းကြားချက်။ Email သည် provider လိုအပ်သည်၊ app မှ email ပို့နည်း ကို ကြည့်ပါ။
6. Automated status ပြောင်းလဲမှု လိုချင်လျှင် monitor webhook။
7. Drill လုပ်ပါ။ အတု incident တစ်ခု ဖန်တီးပါ၊ update တင်ပါ၊ ပိတ်ပါ၊ email များကို စစ်ပါ၊ ပြီးလျှင် ဖျက်ပါ။

အဖြစ်များသော အမှားများ

• App နှင့်အတူ host လုပ်ခြင်း။ အအဖြစ်များဆုံးနှင့် အပြင်းထန်ဆုံး အမှား။
• အမြဲ "All systems operational" ဟု ပြသော စာမျက်နှာ။ ပြဿနာများ တစ်ကြိမ်မှ မပြလျှင် အသုံးပြုသူများ ယုံကြည်မှု ပျောက်သွားသည်။
• အချိန်တံဆိပ် သို့မဟုတ် time zone မရှိခြင်း။ အချိန်များကို အမြဲ zone နှင့်တကွ ပြပါ။
• Admin စာမျက်နှာအတွက် main app ၏ login ကို မှီခိုခြင်း။
• Update များအကြား အသံတိတ်နေခြင်း။ "ပြောင်းလဲမှု မရှိ၊ ဆက်လုပ်နေဆဲ" ဆိုသည်မှာ မှန်ကန်သော update တစ်ခုဖြစ်သည်။
• အလိုအလျောက် status တုန်လှုပ်ခြင်း။ ပြောင်းမီ ထပ်ခါတလဲလဲ ပျက်ကွက်မှု လိုအပ်ပါစေ။

Status page ဝန်ဆောင်မှု အဆင်သင့်ရှိသော ရွေးချယ်မှု ဖြစ်သည့်အခါ

Hosted status page ဝန်ဆောင်မှုများသည် သီးခြားမှီခိုမှု ပြဿနာအတွက် တည်ဆောက်ထားသည်- ၎င်းတို့ သီးခြား infrastructure ပေါ်တွင် run ပြီး subscriber အကြောင်းကြားချက်ကို email နှင့် SMS ဖြင့် ကိုင်တွယ်ကာ မကြာခဏ monitoring နှင့် incident tool များနှင့် integration ပါသည်။ Uptime သည် သင့်ဝယ်သူများ ပေးချေသည့်အရာ တစ်စိတ်တစ်ပိုင်းဖြစ်လျှင် သို့မဟုတ် incidents အစီရင်ခံရန် စာချုပ်အရ တာဝန်ရှိလျှင် သီးသန့်ဝန်ဆောင်မှုသည် များသောအားဖြင့် တန်ဖိုးရှိသည်။ အသေးစား team အများအပြားအတွက် အခမဲ့ သို့မဟုတ် ဈေးနည်းသော tier များ ရှိသဖြင့် တည်ဆောက်မီ စစ်ဆေးပါ။

သင်က ဒီဇိုင်းနှင့် စာသားအပေါ် အပြည့်အဝ ထိန်းချုပ်လိုလျှင်၊ လိုအပ်ချက် ရိုးရှင်းလျှင် (component အနည်းငယ်၊ လက်ဖြင့် update) သို့မဟုတ် အခြားသူများအတွက် တည်ဆောက်သော product တစ်ခု၏ အစိတ်အပိုင်း ဖြစ်လျှင် ကိုယ်တိုင် တည်ဆောက်ပါ။

Mythex ဖြင့် တည်ဆောက်ခြင်း

Mythex တွင် status page ကို main app နှင့် သီးခြား project အဖြစ် တည်ဆောက်နိုင်ပြီး သီးခြား hosting နှင့် ကိုယ်ပိုင် database ရရှိသည်။ Chat တွင် ဖော်ပြပြီး live preview တွင် စစ်ဆေးကာ ထုတ်ဝေပြီး status.yourdomain.com ကဲ့သို့ subdomain ချိတ်ဆက်ပါ (custom domains သည် Pro တွင်ရှိသည်)။ ထုတ်ဝေထားသော Mythex app များနှင့် database များသည် အသုံးမပြုချိန်တွင် အိပ်ပြီး နောက်တစ်ကြိမ် ဝင်ရောက်သောအခါ နိုးလာသည်ကို သတိပြုပါ၊ ထို့ကြောင့် တိတ်ဆိတ်ပြီးနောက် ပထမဆုံး load သည် နှေးနိုင်သည်။ ရိုးရှင်း၊ ပေါ့ပါးသော စာမျက်နှာက ကူညီသည်။

Mythex က scheduled jobs ကို မှတ်တမ်းမတင်ထားသောကြောင့် အလိုအလျောက် စစ်ဆေးမှုအတွက် status page ၏ webhook endpoint ကို ခေါ်သော ပြင်ပ uptime monitor ကို သုံးပါ (webhooks recipe ကို ကြည့်ပါ)။ Subscribers ထံ email သတိပေးချက်များသည် သင့်ကိုယ်ပိုင် provider မှတစ်ဆင့် သွားပြီး key ကို project secret အဖြစ် သိမ်းထားသည် (send email recipe)။

မေးခွန်းများ