Rollback Strategy များ — Rolling, Blue-Green, Canary

နားလည်ထားရမယ့် အချက်

Version အသစ်တစ်ခုကို deploy လုပ်နိုင်ပြီဆိုတာနဲ့ ဒါကို ဘေးကင်းစွာ ထုတ်ဖော်ပြီး ဘာမှားရင် ပြန်ဆွဲယူနိုင်ဖို့ နည်းလမ်းတစ်ခု လိုအပ်ပါတယ်။ Real-world rollout pattern အများစုကို strategy သုံးခုက ဖုံးလွှမ်းပါတယ်။

Rolling deployment သည် instance အဟောင်းများကို instance အသစ်များဖြင့် အနည်းငယ်စီ တဖြည်းဖြည်း အစားထိုးသွားပြီး app ကို တစ်လျှောက်လုံး အသုံးပြုနိုင်စေသည်။ tradeoff မှာ version အဟောင်းနှင့်အသစ် အတိုတောင်းစီ တွဲရှိနေသောကြောင့် compatible မဖြစ်ပါက အန္တရာယ်ရှိနိုင်ခြင်းဖြစ်သည်။

Blue-green deployment သည် environment အပြည့်နှစ်ခု ထိန်းသိမ်းသည် — Blue က လက်ရှိ production version၊ Green က traffic အစစ်ကို Blue ဆက်ထောက်ပံ့နေစဉ် parallel တွင် စမ်းသပ်နေသော version အသစ်ဖြစ်သည်။ Green ကျန်းမာသည်ဟု ထင်ရသည်နှင့် traffic ကို တစ်ပြိုင်နက် ပြောင်းလိုက်သည်၊ ပြဿနာရှိပါက Blue ဆီသို့ ချက်ချင်း ပြန်ပြောင်းသည်။

Canary deployment သည် user အစစ် ရာနှုန်းအနည်းငယ် — ဥပမာ 5% — ကို version အသစ်ဆီ ပထမဆုံး ပို့ပြီး error rate နှင့် performance ကို ကြည့်ရှုပြီးမှသာ version အသစ် ကောင်းမွန်ကြောင်း သက်သေပြသည့်အခါ အဆင့်ဆင့် ရာခိုင်နှုန်း တိုးမြှင့်ပေးသည်။

THREE ROLLOUT / ROLLBACK PATTERNS
---------------------------------
ROLLING DEPLOYMENT
  [old][old][old][old]  -> replace one at a time ->
  [new][old][old][old] -> [new][new][old][old] -> ...
  rollback = replace new->old again, same way, takes time

BLUE-GREEN DEPLOYMENT
  BLUE (current, live) <---- traffic
  GREEN (new, tested in parallel, not yet live)
  switch:  traffic ----> GREEN   (all at once)
  rollback: traffic ----> BLUE   (instant, Blue still running)

CANARY DEPLOYMENT
  stage 1:  95% old  /  5% new   -- watch error rate
  stage 2:  75% old  / 25% new   -- watch error rate
  stage 3:   0% old  /100% new   -- fully rolled out
  rollback: new% -> 0 at any stage once errors spike

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

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

Platform တစ်ခု ရွေးချယ်ချိန်တွင် 'code အသစ် deploy လုပ်နိုင်လား' ဆိုတာသာမက 'ဒီမှာ rollback က တကယ်ဘယ်လိုဖြစ်မလဲ၊ ဘယ်လောက်မြန်မလဲ' ဆိုတာလည်း မေးပါ။

Pattern တစ်ခုတည်းသာ support လုပ်တဲ့ platform တစ်ခုသည်လည်း ထို pattern က သင်လိုအပ်သော သတိထားမှုအဆင့်နှင့် ကိုက်ညီပါက ကောင်းမွန်နိုင်ပါသေးသည် — မှန်ကန်သောရွေးချယ်မှုသည် traffic volume၊ deploy မှားရင် ဘယ်လောက်ကုန်ကျမလဲ၊ budget က infrastructure ထပ်လုပ်ခြင်းကို ဘယ်လောက်ခံနိုင်သလဲပေါ်တွင် မူတည်ပါသည်။

• Rolling, blue-green, canary တို့သည် rollout risk ကို မတူညီစွာ ကိုင်တွယ်သော pattern သုံးမျိုးဖြစ်သည်
• ဘာမှ universal အနိုင်ရသည်မဟုတ်ပါ — platform support, cost, traffic risk ပေါ်မူတည်ပြီး ရွေးချယ်ရသည်
• Rollback မြန်နှုန်းသည် ဘယ် pattern အသုံးပြုနေသလဲပေါ် လုံးဝမူတည်နေသောကြောင့် platform ရွေးချယ်ချိန်တွင် မေးရမည့် မေးခွန်းဖြစ်သည်

အတူတူ စမ်းရေးကြည့်မယ်

function simulateCanaryRollout(startPercent, stepSchedule, errorRateAtStage, errorThreshold) {
  let currentPercent = startPercent;
  const log = [];

  for (let i = 0; i < errorRateAtStage.length; i++) {
    const errorRate = errorRateAtStage[i];
    log.push({ stage: i + 1, canaryPercent: currentPercent, errorRate });

    if (errorRate > errorThreshold) {
      log.push({ stage: i + 1, decision: "ROLLBACK", reason: `error rate ${errorRate} exceeded threshold ${errorThreshold}` });
      return { finalPercent: 0, rolledBack: true, log };
    }

    // Error rate is acceptable at this stage: move to the next step, if any.
    if (i < stepSchedule.length) {
      currentPercent = stepSchedule[i];
    }
  }

  return { finalPercent: currentPercent, rolledBack: false, log };
}

// Scenario A: a healthy rollout that completes.
const healthy = simulateCanaryRollout(
  5,
  [25, 50, 100],
  [0.2, 0.3, 0.25, 0.2],
  1.0
);
console.log("Healthy rollout:", JSON.stringify(healthy, null, 2));

// Scenario B: errors spike partway through and trigger a rollback.
const risky = simulateCanaryRollout(
  5,
  [25, 50, 100],
  [0.3, 4.8],
  1.0
);
console.log("Risky rollout:", JSON.stringify(risky, null, 2));

Healthy rollout: finalPercent 100, rolledBack false, stage 4 ခုလုံး error rate threshold အောက်ရှိသည်။
Risky rollout: stage 2 ၏ error rate 4.8 သည် threshold 1.0 ထက်ကျော်သောကြောင့် rolledBack true, finalPercent 0 ဖြစ်သည်

Martin Fowler: BlueGreenDeployment — Cloud Providers & Platforms