Deployment আর release — container, CI/CD, blue-green, canary আর zero-downtime migration

১ · কোড থেকে production — build একবার, artifact অপরিবর্তনীয়

আপনার ল্যাপটপে কোড চলছে। এবার সেটি লাখো মানুষের কাছে পৌঁছাতে হবে — কোনো অনুরোধ না ভেঙে, আর ভুল হলে কয়েক মিনিটে ফিরে আসার পথ রেখে। এই পুরো যাত্রার নাম deployment. এই পর্বের প্রশ্ন: সিস্টেমটি কীভাবে প্রতিদিন নিরাপদে বদলানো যায়। অনেক বড় outage নকশার ত্রুটিতে নয়, একটি পরিবর্তনের মুহূর্তে শুরু হয় — নতুন কোড, নতুন config বা নতুন schema.

Build once: একটি commit থেকে একবারই একটি immutable artifact তৈরি হয় — একটি container image, একটি jar ফাইল বা একটি VM image. Test, staging আর production-এ সেই একই artifact “উন্নীত” (promote) হয়। প্রতিটি পরিবেশের জন্য আলাদা করে build করলে staging-এ যা পরীক্ষা করেছেন আর production-এ যা চলছে, সেগুলো আলাদা জিনিস — হয়তো মাঝখানে একটি library-র নতুন সংস্করণ ঢুকে পড়েছে। পরিবেশের পার্থক্য থাকবে শুধু config-এ: database-এর ঠিকানা, কতগুলো কপি, কোন feature চালু। Heroku-র প্রকৌশলীদের ২০১১ সালের দিকে লেখা Twelve-Factor App নীতিমালা এই বিভাজনকে জনপ্রিয় করে: config আসে পরিবেশ থেকে, কোডের ভেতর থেকে নয়।

আজকের সবচেয়ে প্রচলিত artifact হলো container image. Container নিজে কী — namespace আর cgroup দিয়ে ঘেরা একটি সাধারণ process — সেটি অপারেটিং সিস্টেম কোর্সের container পর্বে বিস্তারিত আছে; VM-এর সাথে তুলনা virtual machine পর্বে। এখানে আমাদের দরকার তিনটি ধারণা:

• Layer: একটি image কয়েকটি layer-এর স্তূপ — নিচে base OS-এর ফাইল, তার ওপর runtime, তারপর dependency, সবশেষে আপনার কোড। প্রতিটি layer তার বিষয়বস্তুর hash দিয়ে চেনা, তাই যে layer বদলায়নি সেটি আবার build বা আবার download করতে হয় না। কোড বদলালে শুধু ওপরের পাতলা layer নতুন।
• Tag বনাম digest: tag (যেমন shop:1.4.0 বা shop:latest) একটি নাম, যা যেকোনো সময় অন্য image-এর দিকে সরানো যায়। digest (যেমন shop@sha256:9f2c…) image-এর বিষয়বস্তুর SHA-256 hash — বিষয়বস্তু এক বিট বদলালেও digest বদলায়। তাই digest একটি প্রতিশ্রুতি, tag একটি লেবেল।
• Registry: container registry হলো image-এর গুদাম। CI image বানিয়ে সেখানে push করে, আর cluster-এর প্রতিটি যন্ত্র সেখান থেকে pull করে।

একটি Dockerfile-এ layer-এর ক্রম গুরুত্বপূর্ণ — যা কম বদলায় তা আগে, যাতে cache কাজে লাগে:

# base image pinned by digest, not by a moving tag
FROM node:20-slim@sha256:<digest>
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci              # installs the exact versions in the lockfile
COPY . .                # app code last: changes most often
USER node               # do not run as root
CMD ["node", "server.js"]

এই চিন্তার বড় রূপ immutable infrastructure: চলমান সার্ভারে ssh করে হাতে সংশোধন নয়; বদল দরকার হলে নতুন image বানিয়ে পুরোনোটি বদলে দেওয়া। হাতে সংশোধনের ফল configuration drift — দশটি “একই” সার্ভার চুপচাপ দশ রকম হয়ে যায়। Stateless সার্ভিস (পর্ব ১৩) এই নিয়মের পূর্বশর্ত: কপিটির ভেতরে মূল্যবান কিছু না থাকলেই তাকে নির্ভয়ে ফেলে দিয়ে নতুন কপি বসানো যায়।

২ · CI/CD pipeline — build, test, scan, deploy, verify

Continuous integration (CI) মানে প্রতিটি পরিবর্তন দিনে কয়েকবার মূল শাখায় মেলানো, আর প্রতিবার স্বয়ংক্রিয়ভাবে build আর test চালানো। Continuous delivery (CD) এক ধাপ এগিয়ে: প্রতিটি সফল build যেকোনো সময় production-এ পাঠানোর মতো তৈরি থাকে, শেষ সিদ্ধান্ত একজন মানুষের এক ক্লিক। Continuous deployment-এ সেই ক্লিকও নেই — সব যাচাই পাস করলে pipeline নিজেই production-এ নিয়ে যায়। Jez Humble আর David Farley-র ২০১০ সালের বই Continuous Delivery এই শব্দগুলোকে প্রতিষ্ঠিত করে।

একটি সাধারণ pipeline-এর পাঁচটি ধাপ, প্রতিটি আগেরটি ব্যর্থ হলে থেমে যায় (fail fast):

1. Build: কোড compile, dependency lockfile থেকে, image তৈরি আর digest লেখা — একবারই।
2. Test: দ্রুত unit test আগে, ধীর integration আর contract test পরে।
3. Scan আর sign: dependency-র জানা দুর্বলতা খোঁজা, উপাদানের তালিকা (SBOM) তৈরি, image-এ স্বাক্ষর — অংশ ৮-এ।
4. Deploy: image registry-তে push, তারপর cluster-কে নতুন digest জানানো — প্রথমে canary-তে।
5. Verify: deploy-এর পরে smoke test আর metric-এর তুলনা — error rate, latency, SLO (পর্ব ৫০)। “Deploy শেষ” মানে “ঠিকভাবে চলছে প্রমাণিত”, শুধু “কোড পৌঁছেছে” নয়।

ছোট ব্যাচ কেন নিরাপদ: ডাকঘরে মাসের শেষে পাঁচশো চিঠির একটি বস্তা পাঠালে একটি ভুল ঠিকানার চিঠি খুঁজে পেতে পুরো বস্তা ঘাঁটতে হয়; প্রতিদিন বিশটি পাঠালে ভুলটি কোন দিনের, তা সঙ্গে সঙ্গে বোঝা যায়। Deploy-এও তাই: তিনটি পরিবর্তনে কারণ খোঁজা সহজ, ফেরা সস্তা; তিনশোটিতে প্রতিটি deploy ভয়ের ঘটনা। Trunk-based development এই চক্র ভাঙে: সবাই দিনে অন্তত একবার মূল শাখায় (trunk) ছোট পরিবর্তন মেলান, দীর্ঘজীবী শাখা নেই; অসম্পূর্ণ feature লুকানো থাকে feature flag-এর পেছনে (অংশ ৪)।

Deploy-প্রক্রিয়া কতটা ভালো, মাপবেন কীভাবে? DevOps Research and Assessment (DORA) দলের বহু বছরের জরিপ-গবেষণা — যার সারাংশ Forsgren, Humble আর Kim-এর ২০১৮ সালের বই Accelerate — চারটি DORA metric প্রস্তাব করে। দুটি গতির, দুটি স্থিতিশীলতার:

গবেষণাটির সবচেয়ে আলোচিত দাবি: ভালো দলগুলো গতি আর স্থিতিশীলতা দুটিতেই ভালো — দুটির মধ্যে “একটি বাড়ালে অন্যটি কমে” এমন দর-কষাকষি দেখা যায়নি। তবে সাবধান: এটি জরিপভিত্তিক সম্পর্ক, আর পরের বছরের রিপোর্টগুলোতে metric-এর নাম ও সংজ্ঞা কিছুটা বদলেছে (সংস্করণভেদে মিলিয়ে নিন)। আর metric-কে লক্ষ্য বানালে মানুষ সংখ্যাটাকেই খেলায় — এটি দলের নিজের উন্নতির আয়না, দলগুলোর তুলনার মাপকাঠি নয়।

৩ · Orchestration — Kubernetes-এর মূল ধারণা আর rolling update

দশটি সার্ভারে হাতে image চালানো সম্ভব; পাঁচশোটিতে নয়। Container orchestration এই কাজ যন্ত্রের হাতে দেয়: কোন যন্ত্রে কোন container বসবে, কোনটি মরে গেলে নতুনটি কোথায়, traffic কাকে যাবে। সবচেয়ে প্রচলিত open-source orchestrator Kubernetes, যা Google ২০১৪ সালে open source করে আর যার নকশায় Google-এর ভেতরের Borg ব্যবস্থার অভিজ্ঞতা কাজে লেগেছে বলে তাঁদের প্রকাশিত paper-এ বলা আছে। এখানে ধারণার স্তরে চারটি জিনিস — নেটওয়ার্কের দিক (CNI, kube-proxy, Ingress) আছে Computer Networks কোর্সের cloud আর container নেটওয়ার্কিং পর্বে।

সবকিছুর পেছনে একটি দর্শন: আপনি “কী করতে হবে” লেখেন না, লেখেন “কেমন থাকা উচিত” — declarative নকশা। “shop-এর ১০টি কপি, এই digest-এর image” — এই কাঙ্ক্ষিত অবস্থা cluster-এর etcd-এ জমা থাকে, আর controller-গুলো একটি control loop-এ বারবার দেখে আসল অবস্থা কাঙ্ক্ষিত অবস্থার সাথে মেলে কি না; না মিললে মেলানোর পরের ছোট পদক্ষেপটি নেয়।

Rolling update-এর দুটি লাগাম: rolling deployment-এ নতুন image এলে Deployment দুটি সংখ্যা মেনে চলে। maxSurge — কাঙ্ক্ষিত সংখ্যার চেয়ে সর্বোচ্চ কতগুলো বাড়তি Pod একসাথে থাকতে পারে। maxUnavailable — কাঙ্ক্ষিত সংখ্যার চেয়ে সর্বোচ্চ কতগুলো কম প্রস্তুত Pod থাকতে পারে। লেখার সময়ের Kubernetes documentation অনুযায়ী দুটির ডিফল্ট ২৫%; শতাংশ থেকে সংখ্যা বানাতে maxSurge ওপরের দিকে আর maxUnavailable নিচের দিকে round হয়। ১০টি কপিতে তাই ৩টি বাড়তি পর্যন্ত, আর অন্তত ৮টি প্রস্তুত।

“প্রস্তুত” কে ঠিক করে? readiness probe — Pod-এর একটি ঠিকানায় নিয়মিত জিজ্ঞাসা, “এখন কি traffic নেওয়া যাবে?” নতুন Pod যতক্ষণ এই পরীক্ষায় পাস না করে, Service তাকে traffic দেয় না, আর Deployment তাকে “উপলব্ধ” ধরে না, তাই পরের পুরোনো Pod-ও সরায় না। ভাঙা image-এর rollout এভাবে নিজেই আটকে যায় — নিরাপত্তার জাল। Readiness আর liveness-এর পার্থক্য, আর probe কতটা গভীর হবে, তা পর্ব ৪৮-এর বিষয়; সাধারণ health check দেখেছেন পর্ব ১৪-এ। একটি জরুরি সতর্কতা: আটকে যাওয়া rollout লেখার সময়ের Kubernetes-এ নিজে থেকে পেছনে ফেরে না — একটি সময়সীমা পেরোলে “ব্যর্থ” চিহ্ন পড়ে, ফেরানোর কাজ আপনার বা আপনার deploy-টুলের।

apiVersion: apps/v1
kind: Deployment
metadata: { name: shop }
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%          # rounds up   -> at most 3 extra pods
      maxUnavailable: 25%    # rounds down -> at least 8 ready
  selector: { matchLabels: { app: shop } }
  template:
    metadata: { labels: { app: shop } }
    spec:
      terminationGracePeriodSeconds: 30
      containers:
      - name: web
        image: registry.example.com/shop@sha256:9f2c...   # digest, not :latest
        readinessProbe:
          httpGet: { path: /ready, port: 8080 }
          periodSeconds: 5
        lifecycle:
          preStop: { exec: { command: ["sleep", "5"] } }

সংখ্যা দুটি কীভাবে capacity আর সময় বদলায়, নিজে মেপে দেখুন। নিচের সিমুলেটরে ১০টি কপি; প্রতি ৫ সেকেন্ডে controller একবার দেখে — আগে নতুন Pod বানায় (maxSurge মেনে), তারপর যতগুলো পুরোনো সরানো যায় সরায় (maxUnavailable মেনে)। প্রতিটি নতুন Pod প্রস্তুত হতে seed দিয়ে বাছা ২০ থেকে ৪০ সেকেন্ড লাগে (image pull, চালু হওয়া, warm-up).

// Rolling update of 10 replicas: how maxSurge / maxUnavailable shape capacity and time.
function mulberry32(a) { return () => { a = a + 0x6D2B79F5 | 0;
  let t = Math.imul(a ^ a >>> 15, 1 | a); t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
  return ((t ^ t >>> 14) >>> 0) / 4294967296; }; }
const N = 10, TICK = 5;                                 // controller looks every 5 s
function rollout(surge, unavail, show) {
  const rand = mulberry32(53);                          // same pod start-up times for every setting
  let old = N, t = 0, minCap = N, peak = N; const fresh = [];  // fresh = ready-at times
  while (true) {
    const ready = fresh.filter(r => r <= t).length;
    const want = Math.min(N, N + surge - old) - fresh.length;          // scale up (surge cap)
    for (let i = 0; i < want; i++) fresh.push(t + 20 + 5 * Math.floor(rand() * 5)); // 20..40 s
    const kill = Math.min(old, old + ready - (N - unavail));           // scale down (floor)
    if (kill > 0) old -= kill;
    const cap = old + ready; minCap = Math.min(minCap, cap);
    peak = Math.max(peak, old + fresh.length);
    if (show) console.log(`t=${String(t).padStart(3)}s  old ${String(old).padStart(2)}  ` +
      `new ${ready}/${fresh.length}`.padEnd(10) + `  serving ${String(cap).padStart(2)}  ` +
      "#".repeat(cap));
    if (old === 0 && ready === N) return { t, minCap, peak };
    t += TICK;
  }
}
console.log("Timeline, maxSurge=3, maxUnavailable=2 (25% of 10, rounded up / down):");
rollout(3, 2, true);
console.log("\nsurge unavail   done after  lowest serving  most pods at once");
for (const [s, u] of [[1, 0], [0, 1], [3, 2], [10, 0], [0, 10]]) {
  const r = rollout(s, u, false);
  console.log(`${String(s).padStart(4)} ${String(u).padStart(6)}  ${String(r.t).padStart(9)} s` +
    `  ${String(r.minCap).padStart(10)}/10  ${String(r.peak).padStart(12)}`);
}

Timeline, maxSurge=3, maxUnavailable=2 (25% of 10, rounded up / down):
t=  0s  old  8  new 0/3     serving  8  ########
t=  5s  old  8  new 0/5     serving  8  ########
t= 10s  old  8  new 0/5     serving  8  ########
t= 15s  old  8  new 0/5     serving  8  ########
t= 20s  old  6  new 2/5     serving  8  ########
t= 25s  old  5  new 3/7     serving  8  ########
t= 30s  old  5  new 3/8     serving  8  ########
t= 35s  old  5  new 3/8     serving  8  ########
t= 40s  old  4  new 4/8     serving  8  ########
t= 45s  old  2  new 6/9     serving  8  ########
t= 50s  old  2  new 6/10    serving  8  ########
t= 55s  old  1  new 7/10    serving  8  ########
t= 60s  old  1  new 7/10    serving  8  ########
t= 65s  old  0  new 8/10    serving  8  ########
t= 70s  old  0  new 8/10    serving  8  ########
t= 75s  old  0  new 9/10    serving  9  #########
t= 80s  old  0  new 9/10    serving  9  #########
t= 85s  old  0  new 9/10    serving  9  #########
t= 90s  old  0  new 10/10   serving 10  ##########

surge unavail   done after  lowest serving  most pods at once
   1      0        340 s          10/10            11
   0      1        345 s           9/10            10
   3      2         90 s           8/10            13
  10      0         40 s          10/10            20
   0     10         45 s           0/10            10

Infrastructure as code আর GitOps: Pod-এর বাইরের জিনিস — network, load balancer, database-এর instance, DNS — একইভাবে ফাইলে লেখা যায়: infrastructure as code (IaC). Terraform-এর মতো টুল (HashiCorp, ২০১৪) কাঙ্ক্ষিত অবস্থা পড়ে আসল অবস্থার সাথে তুলনা করে একটি “plan” দেখায় — কী তৈরি, কী বদল, কী মোছা হবে — আর অনুমোদনের পর প্রয়োগ করে। কেউ console-এ হাতে কিছু বদলালে পরের তুলনায় সেটি ধরা পড়ে: drift. GitOps (শব্দটি Weaveworks ২০১৭ সালের দিকে জনপ্রিয় করে) আরও এক ধাপ: কাঙ্ক্ষিত অবস্থার একমাত্র উৎস একটি git repository; cluster-এর ভেতরের একটি agent (Argo CD বা Flux-এর মতো টুল) repository দেখে নিজেই মেলায়। লাভ: প্রতিটি বদল একটি review করা commit, আর ফেরা মানে git revert. সতর্কতা: password বা key কখনো সরল লেখায় git-এ নয় — secret-এর ব্যবস্থাপনা পর্ব ৫২-এ।

৪ · Deploy আর release আলাদা — feature flag আর পাঁচটি কৌশল

দুটি শব্দ প্রায়ই এক অর্থে বলা হয়, কিন্তু নকশায় এরা আলাদা। Deploy মানে নতুন কোড সার্ভারে পৌঁছে চলতে শুরু করা। Release মানে ব্যবহারকারীরা নতুন আচরণ দেখতে পাওয়া। Deploy আর release আলাদা রাখলে কোড আজ production-এ চলে যায়, কিন্তু নতুন “কিস্তিতে পেমেন্ট” বোতামটি খোলে আগামী সপ্তাহে — প্রথমে কর্মীদের জন্য, তারপর ১% গ্রাহকের জন্য, তারপর সবার জন্য। মাঝখানে কোনো নতুন deploy লাগে না।

যন্ত্রটির নাম feature flag (বা feature toggle): কোডের ভেতরে একটি শর্ত, যার মান চলমান অবস্থায় একটি config সেবা থেকে আসে — “এই ব্যবহারকারীর জন্য নতুন পথ চালু কি না”। সবচেয়ে মূল্যবান রূপটি kill switch: নতুন feature গোলমাল করলে কয়েক সেকেন্ডে বন্ধ, কোনো rollback বা নতুন build ছাড়াই। Flag-এর দাম আছে — flag debt. প্রতিটি flag কোডে দুটি পথ রাখে; দশটি flag মানে তাত্ত্বিকভাবে ১,০২৪টি সমন্বয়। তাই প্রতিটি release flag-এর একটি মালিক আর মেয়াদ থাকা দরকার: rollout শেষ হলে flag আর পুরোনো পথ দুটিই কোড থেকে মুছে ফেলা। পুরোনো flag-এর নাম নতুন কাজে আবার ব্যবহার করা বিশেষ বিপজ্জনক — ভাবনার প্রশ্ন ১-এ একটি বিখ্যাত ঘটনা।

কোড কীভাবে পুরোনো সংস্করণের জায়গা নেবে, তার পাঁচটি প্রধান কৌশল:

Blue-green-এর শক্তি তার সরলতায়: দুটি সমান দল, “blue” (এখনকার) আর “green” (নতুন)। Green পুরো প্রস্তুত আর যাচাই হলে router একটি config বদলে সব traffic green-এ পাঠায়। গোলমাল হলে একই বদল উল্টো। ধাপে ধাপে দেখুন:

ধাপ ৪ blue-green-এর দুর্বলতাও দেখায়: switch মানে সবার জন্য একসাথে। তাই অনেক দল দুটি মেশায় — green-এ প্রথমে অল্প traffic (canary), তারপর পুরো switch. আর shadow traffic-এ (traffic mirroring) আসল অনুরোধের একটি কপি নতুন সংস্করণে যায়, কিন্তু উত্তর ব্যবহারকারীর কাছে যায় না — আসল ভারে latency আর উত্তরের মিল নিরাপদে মাপা যায়। সাবধান: shadow অনুরোধ যেন টাকা না কাটে, SMS না পাঠায়, database-এ না লেখে — side effect-ওয়ালা কাজগুলো সেখানে বন্ধ বা নকল করে রাখতে হয়। কাছাকাছি ধারণা dark launch: নতুন feature-এর backend অংশ আসল ব্যবহারকারীর জন্য চালু, কিন্তু পর্দায় কিছু দেখা যায় না। Data migration-এ এর আত্মীয় shadow read.

৫ · Canary — অল্প দিয়ে শুরু, মেপে এগোনো, নিজে থেকে ফেরা

নামটি এসেছে কয়লাখনির পুরোনো প্রথা থেকে: বিষাক্ত গ্যাস মানুষের আগে ছোট ক্যানারি পাখির ওপর প্রভাব ফেলত, তাই সেটি ছিল আগাম সতর্কসংকেত। Canary release-এ নতুন সংস্করণ প্রথমে ছোট এক ভাগ traffic পায় — ধরা যাক ১%. কিছুক্ষণ (bake time) metric দেখা হয়; ঠিক থাকলে ৫%, তারপর ২৫%, তারপর সবাই। এই ধাপে ধাপে ছড়ানোর সাধারণ নাম progressive delivery.

প্রতিটি ধাপে প্রশ্ন একটি: canary কি stable-এর চেয়ে খারাপ? তাই automated canary analysis — একটি যন্ত্র কয়েকটি metric (error rate, p99 latency, CPU, ব্যবসার সংখ্যা যেমন সফল পেমেন্ট) canary আর তুলনার দলে মিলিয়ে দেখে, আর SLO-র সীমা (পর্ব ৫০) ভাঙলে বা পার্থক্য পরিসংখ্যানে অর্থবহ হলে নিজেই rollback করে। “পরিসংখ্যানে অর্থবহ” কথাটা এখানে আসল — কারণ ১% traffic মানে খুব কম অনুরোধ, আর কম অনুরোধে কয়েকটি error ভাগ্যক্রমেও আসে।

সবচেয়ে সরল পরীক্ষা two-proportion z-test. Canary-তে n_cটি অনুরোধে e_cটি error (হার p_c), stable-এ n_bটিতে e_bটি (হার p_b). দুটি দলের মোট হার p = (e_c + e_b) ÷ (n_c + n_b) ধরে নিলে, “দুটি আসলে সমান” হলে পার্থক্যের স্বাভাবিক ছড়ানো (standard error) √(p(1 − p)(1/n_c + 1/n_b)). তখন

z বড় মানে পার্থক্যটি ভাগ্যের চেয়ে বড়। এখানে নিয়ম ধরা হলো z > 2.33 হলে rollback — এক দিকের পরীক্ষায় প্রায় ১% ভুল সতর্কসংকেতের সম্ভাবনা। অনুমানগুলো স্পষ্ট রাখা দরকার: অনুরোধগুলো একে অপরের থেকে স্বাধীন (একজন ব্যবহারকারীর দশটি retry স্বাধীন নয়), আর error এত কম নয় যে সাধারণ বণ্টনের আসন্ন মান ভেঙে পড়ে। বারবার পরীক্ষায় ভুল সতর্কসংকেত সবমিলিয়ে বাড়ে। নিচের সিমুলেটরে প্রতি ধাপে মোট ৪০,০০০টি অনুরোধ (ধরা যাক, ১০ মিনিটে), stable-এর আসল error ০.৫%; তিনটি release-এর আসল error ০.৫%, ১% আর ২%.

// Canary analysis: 1% -> 5% -> 25% of traffic, two-proportion z-test at each step.
function mulberry32(a) { return () => { a = a + 0x6D2B79F5 | 0;
  let t = Math.imul(a ^ a >>> 15, 1 | a); t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
  return ((t ^ t >>> 14) >>> 0) / 4294967296; }; }
const PER_STEP = 40000;                 // requests in one 10-minute analysis window (assumed)
const BASE_ERR = 0.005;                 // stable version: 0.5% of requests fail
const Z_LIMIT = 2.33;                   // one-sided, about 1% false-alarm chance per step
const errorsIn = (n, p, rand) => { let e = 0; for (let i = 0; i < n; i++) if (rand() < p) e++; return e; };
function analyse(label, canaryErr, seed) {
  const rand = mulberry32(seed);
  console.log(`\n${label}: canary true error rate ${(canaryErr * 100).toFixed(1)}%`);
  console.log("traffic  canary n  errs  rate    baseline n  errs  rate    z      decision");
  for (const share of [0.01, 0.05, 0.25]) {
    const nc = Math.round(PER_STEP * share), nb = PER_STEP - nc;
    const ec = errorsIn(nc, canaryErr, rand), eb = errorsIn(nb, BASE_ERR, rand);
    const pc = ec / nc, pb = eb / nb, pool = (ec + eb) / (nc + nb);
    const z = (pc - pb) / Math.sqrt(pool * (1 - pool) * (1 / nc + 1 / nb));
    const bad = z > Z_LIMIT;
    console.log(`${String(share * 100).padStart(5)}%  ${String(nc).padStart(8)}  ${String(ec).padStart(4)}  ` +
      `${(pc * 100).toFixed(2).padStart(5)}%  ${String(nb).padStart(10)}  ${String(eb).padStart(4)}  ` +
      `${(pb * 100).toFixed(2).padStart(5)}%  ${z.toFixed(2).padStart(5)}  ` +
      (bad ? "ROLLBACK" : share < 0.25 ? "continue" : "promote to 100%"));
    if (bad) return;
  }
}
analyse("Release A (healthy)", 0.005, 7);
analyse("Release B (bug doubles errors)", 0.010, 7);
analyse("Release C (bug: 4x errors)", 0.020, 7);

Release A (healthy): canary true error rate 0.5%
traffic  canary n  errs  rate    baseline n  errs  rate    z      decision
    1%       400     2   0.50%       39600   231   0.58%  -0.22  continue
    5%      2000    13   0.65%       38000   176   0.46%   1.19  continue
   25%     10000    50   0.50%       30000   158   0.53%  -0.32  promote to 100%

Release B (bug doubles errors): canary true error rate 1.0%
traffic  canary n  errs  rate    baseline n  errs  rate    z      decision
    1%       400     5   1.25%       39600   231   0.58%   1.73  continue
    5%      2000    27   1.35%       38000   176   0.46%   5.44  ROLLBACK

Release C (bug: 4x errors): canary true error rate 2.0%
traffic  canary n  errs  rate    baseline n  errs  rate    z      decision
    1%       400     7   1.75%       39600   231   0.58%   3.02  ROLLBACK

Blast radius: একটি খারাপ release কতজনকে কতক্ষণ ছোঁয়, সেটিই তার blast radius. মাপার একটি সহজ একক “user-minute” — প্রতি মিনিটে খারাপ সংস্করণে থাকা ব্যবহারকারীর সংখ্যার যোগফল। নিচের সিমুলেটরে প্রতি মিনিটে ৮০ হাজার থেকে ১ লাখ ২০ হাজার ব্যবহারকারী (seed দিয়ে বাছা); big-bang-এ মিনিট ০ থেকেই ১০০%, canary-তে ১০ মিনিট করে ১% → ৫% → ২৫% → ১০০%. Bug ধরা পড়ে N মিনিট পরে, আর ফেরাতে আরও ৫ মিনিট লাগে, যার মধ্যে গড়ে অর্ধেক ব্যবহারকারী তখনো খারাপ সংস্করণে।

// Blast radius of a bad release: user-minutes of impact, big-bang vs canary steps.
function mulberry32(a) { return () => { a = a + 0x6D2B79F5 | 0;
  let t = Math.imul(a ^ a >>> 15, 1 | a); t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
  return ((t ^ t >>> 14) >>> 0) / 4294967296; }; }
const rand = mulberry32(2026);
const active = Array.from({ length: 120 }, () => Math.round(80000 + rand() * 40000)); // users online each minute
const ROLLBACK_MIN = 5;                 // minutes from "detected" until no user is on the bad version
const bigBang = () => 1.0;              // share of users on the new version at minute m
const canary = m => m < 10 ? 0.01 : m < 20 ? 0.05 : m < 30 ? 0.25 : 1.0;
function impact(share, detectAfter) {   // sum over minutes of (users online x share on bad version)
  let total = 0;
  for (let m = 0; m < detectAfter + ROLLBACK_MIN; m++) {
    const s = m < detectAfter ? share(m) : share(detectAfter - 1) * 0.5; // rollback: about half left on average
    total += active[m] * s;
  }
  return Math.round(total);
}
console.log("users online per minute: min " + Math.min(...active) + ", max " + Math.max(...active));
console.log("detected after  big-bang user-min  canary user-min  canary / big-bang");
for (const n of [5, 15, 25, 45]) {
  const b = impact(bigBang, n), c = impact(canary, n);
  console.log(`${String(n).padStart(8)} min  ${b.toLocaleString("en-US").padStart(15)}  ` +
    `${c.toLocaleString("en-US").padStart(15)}  ${(c / b * 100).toFixed(1).padStart(14)}%`);
}

users online per minute: min 80038, max 119718
detected after  big-bang user-min  canary user-min  canary / big-bang
       5 min          728,677            7,287             1.0%
      15 min        1,668,789           44,659             2.7%
      25 min        2,679,809          248,512             9.3%
      45 min        4,695,604        2,084,030            44.4%

Rollback নাকি roll-forward? Rollback মানে আগের পরিচিত-ভালো artifact-এ ফেরা; roll-forward মানে দ্রুত একটি সংশোধন বানিয়ে সামনে এগোনো। সাধারণ নিয়ম: আগুন লাগলে আগে rollback — পরীক্ষিত পথ, মিনিটে শেষ; তারপর শান্তভাবে কারণ খোঁজা। Roll-forward তখনই, যখন ফেরা অসম্ভব বা বেশি ঝুঁকির: নতুন সংস্করণ database-এ এমন ফরম্যাটে লিখেছে যা পুরোনোটি পড়তে পারে না, queue-তে নতুন ধরনের বার্তা জমেছে, বা ঘটে যাওয়া কাজ (পাঠানো SMS, কাটা টাকা) ফেরানো যায় না। তাই release-এর আগেই জিজ্ঞেস করুন: “এখান থেকে আগেরটিতে নিরাপদে ফেরা যায়?” উত্তর “না” হলে release-টিকে ফেরানো যায় এমন ছোট ধাপে ভাঙুন — অংশ ৭-এর মতো। Backup আর বড় দুর্যোগ থেকে ফেরার পরিকল্পনা আলাদা বিষয় — পর্ব ৫১.

৬ · Zero-downtime — graceful shutdown, draining আর মানানসই API

Rolling, blue-green বা canary — সবখানে কোনো না কোনো সময় পুরোনো একটি instance বন্ধ হয়। বন্ধের মুহূর্তে যদি সে হাতের অনুরোধগুলো ফেলে দেয়, তাহলে “zero-downtime deploy” আসলে প্রতিবার কয়েকশো ভাঙা অনুরোধ। রেস্তোরাঁর একজন ওয়েটারের শিফট শেষ হলে তিনি হাতের প্লেট মাটিতে রেখে চলে যান না: আগে ম্যানেজারকে বলেন “নতুন টেবিল আর আমাকে দেবেন না”, তারপর যে টেবিলগুলোর খাবার চলছে সেগুলো শেষ করেন, তারপর বিদায়। এটিই graceful shutdown, আর load balancer-এর দিক থেকে connection draining (পর্ব ১৪)।

Kubernetes-এ একটি Pod সরানোর সময় দুটি কাজ একসাথে শুরু হয়: Pod-টিকে Service-এর তালিকা থেকে সরানো, আর Pod-কে বন্ধের সংকেত দেওয়া। প্রথমটি সব যন্ত্র আর load balancer-এ পৌঁছাতে কয়েক সেকেন্ড লাগে, তাই সংকেত পেয়েই listener বন্ধ করলে সেই কয়েক সেকেন্ডে আসা অনুরোধ ভাঙে। প্রচলিত সমাধান একটি preStop hook-এ ছোট অপেক্ষা। ধাপে ধাপে (সময় Pod মোছার আদেশ থেকে; ডিফল্ট সময়সীমা লেখার সময়ের documentation অনুযায়ী ৩০ সেকেন্ড):

let shuttingDown = false;
app.get("/ready", (req, res) => res.status(shuttingDown ? 503 : 200).end());

process.on("SIGTERM", () => {
  shuttingDown = true;                        // readiness fails: no new traffic
  server.close(() => process.exit(0));        // stop accepting; exit when in-flight are done
  server.closeIdleConnections?.();            // idle keep-alive sockets (newer Node versions)
  setTimeout(() => process.exit(1), 20000);   // hard stop: 5 s preStop + 20 s < 30 s grace
});

চালু হওয়ার দিকেও একই যত্ন: readiness তখনই “হ্যাঁ”, যখন database-সংযোগ খোলা আর দরকারি cache ভরা — cold start-এর Pod-এ পুরো ভার এলে latency লাফায়। অনেক load balancer নতুন instance-এ ধীরে ভার বাড়ায় (slow start).

দুই সংস্করণ একসাথে — মানানসই থাকতেই হবে। Rolling আর canary-তে কয়েক মিনিট থেকে কয়েক ঘণ্টা v1 আর v2 পাশাপাশি চলে: v2-এর পাঠানো বার্তা v1 পড়ে, v1-এর লেখা সারি v2 পড়ে, আর একজন ব্যবহারকারীর পরপর দুটি অনুরোধ দুই সংস্করণে যেতে পারে। তাই প্রতিটি পরিবর্তনকে দুই দিকে মানানসই হতে হয়: নতুন কোড পুরোনো ডেটা আর পুরোনো client বোঝে (backward compatibility), পুরোনো কোড নতুন ডেটা দেখে ভেঙে পড়ে না, অচেনা field ডিঙিয়ে যায় (forward compatibility). Protobuf-Avro-তে এর নিয়ম পর্ব ১২-এ, API-র সংস্করণ পর্ব ৮-এ। Mobile অ্যাপে কথাটা আরও কঠিন: পুরোনো অ্যাপ মাসের পর মাস ফোনে থেকে যায়, আর তাকে rollback করার কোনো উপায় নেই। আরেকটি সাধারণ ফাঁদ: session যদি instance-এর memory-তে থাকে, প্রতিটি deploy সবাইকে logout করায় — session বাইরে রাখার কারণ পর্ব ১৫-এ। Microservices-এ নিয়মটি আরও জরুরি (পর্ব ৪৭)।

৭ · Database migration, downtime ছাড়া — expand/contract

কোড ফেরানো যায় এক মিনিটে; ডেটা নয়। আর পুরোনো আর নতুন — দুই সংস্করণের কোডই একই database-এ কথা বলে। তাই schema বদল deploy-এর সবচেয়ে ঝুঁকির অংশ। দুটি আলাদা বিপদ আছে।

বিপদ ১ — lock. অনেক ALTER TABLE কাজ চলার সময় টেবিলে একচেটিয়া lock নেয়, আর কিছু কাজ (যেমন কলামের type বদল) পুরো টেবিল নতুন করে লেখে — কোটি সারির টেবিলে মিনিট বা ঘণ্টা, এর মধ্যে সব লেখা আটকে। সূক্ষ্মতর ফাঁদ lock queue: lock পেতে ALTER যদি একটি দীর্ঘ চলমান query-র পেছনে অপেক্ষা করে, তাহলে PostgreSQL-এ তার পেছনে আসা সাধারণ SELECT-গুলোও সারিতে দাঁড়ায় — একটি “তাৎক্ষণিক” কলাম যোগও পুরো সেবা থামিয়ে দিতে পারে। প্রতিকার: lock_timeout-এর মতো ছোট সময়সীমা, ব্যর্থ হলে পরে আবার; index বানাতে PostgreSQL-এর CREATE INDEX CONCURRENTLY; আর MySQL-এ বড় টেবিলের জন্য gh-ost বা pt-online-schema-change-এর মতো online schema change টুল, যারা একটি ছায়া-টেবিলে কপি করে শেষে নাম বদলে নেয়। কোন বদল “তাৎক্ষণিক” (শুধু metadata) আর কোনটি টেবিল নতুন করে লেখে, তা database আর তার সংস্করণভেদে আলাদা — নিজের সংস্করণের documentation-এ মিলিয়ে নিন। Lock-এর মৌলিক ধারণা পর্ব ২৪-এ।

SET lock_timeout = '2s';                    -- no lock within 2 s? give up, retry later
ALTER TABLE users ADD COLUMN mobile text;   -- nullable, no default: usually metadata-only
CREATE INDEX CONCURRENTLY idx_users_mobile ON users (mobile);  -- avoids a long write lock

বিপদ ২ — মানানসইতা। ধরা যাক users টেবিলের phone কলামের নাম mobile করতে হবে। এক ধাপে RENAME করলে যে মুহূর্তে বদল হলো, তখনো চলমান সব v1 instance phone খুঁজে error পায়; আগে কোড deploy করলে নতুন কোড mobile খুঁজে পায় না। কোনো ক্রমেই এক ধাপে নিরাপদ নয়। সমাধান expand/contract (একে parallel change-ও বলা হয়): আগে প্রসারিত করুন, দুটোই কিছুদিন চালান, সব পুরোনো কোড বিদায় নিলে তবেই সংকোচন। কলাম যোগ থেকে মুছে ফেলা পর্যন্ত প্রতিটি অবস্থায় চলমান সব সংস্করণ কাজ করে:

ক্রম ভুল হলে কী হয়, সিমুলেটরে দেখুন। চারটি অ্যাপ-সংস্করণ, প্রতিটি অবস্থায় ছয়টি অনুরোধ — প্রতিটি অনুরোধ চলমান সংস্করণগুলোর একটিতে যায়, একটি সারি লেখে আর একটি এলোমেলো সারি পড়ে। FAIL মানে কলামই নেই (error), EMPTY মানে কলাম আছে কিন্তু মান খালি — নীরব ভুল:

// Rename column phone -> mobile while old and new app versions run side by side.
function mulberry32(a) { return () => { a = a + 0x6D2B79F5 | 0;
  let t = Math.imul(a ^ a >>> 15, 1 | a); t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
  return ((t ^ t >>> 14) >>> 0) / 4294967296; }; }
const APP = { v1: { w: ["phone"], r: "phone" },  v2: { w: ["phone", "mobile"], r: "phone" },
              v3: { w: ["phone", "mobile"], r: "mobile" }, v4: { w: ["mobile"], r: "mobile" } };
const STEP = { add: s => s.cols.add("mobile"), drop: s => s.cols.delete("phone"),
  rename: s => { s.cols.delete("phone"); s.cols.add("mobile");
                 s.rows.forEach(r => { r.mobile = r.phone; delete r.phone; }); },
  backfill: s => s.rows.forEach(r => { if (r.mobile == null) r.mobile = r.phone; }) };
function run(name, plan) {
  const rand = mulberry32(53), s = { cols: new Set(["phone"]), rows: [] };
  for (let i = 0; i < 4; i++) s.rows.push({ phone: "01" + Math.floor(rand() * 1e9) });
  console.log(`\n== ${name}`);
  for (const [step, versions] of plan) {
    if (STEP[step]) STEP[step](s);
    let wFail = 0, rOk = 0, rEmpty = 0, rFail = 0;
    for (let k = 0; k < 6; k++) {                        // 6 requests, random version each
      const app = APP[versions[Math.floor(rand() * versions.length)]];
      if (app.w.every(c => s.cols.has(c))) {
        const num = "01" + Math.floor(rand() * 1e9), row = {};
        app.w.forEach(c => row[c] = num); s.rows.push(row);
      } else wFail++;
      if (!s.cols.has(app.r)) rFail++;
      else { const row = s.rows[Math.floor(rand() * s.rows.length)];
             row[app.r] == null ? rEmpty++ : rOk++; }
    }
    console.log(`${(step + " [" + versions + "]").padEnd(24)} write-fail ${wFail}  read ok ${rOk}  read EMPTY ${rEmpty}  read FAIL ${rFail}`);
  }
}
run("Big-bang rename", [["rename", ["v1"]], ["deploy", ["v1", "v4"]], ["deploy", ["v4"]]]);
run("Expand/contract, backfill skipped", [["add", ["v1"]], ["deploy", ["v1", "v2"]],
  ["deploy", ["v2", "v3"]], ["deploy", ["v3"]]]);
run("Expand/contract", [["add", ["v1"]], ["deploy", ["v1", "v2"]], ["backfill", ["v2"]],
  ["deploy", ["v2", "v3"]], ["deploy", ["v3", "v4"]], ["drop", ["v4"]]]);

== Big-bang rename
rename [v1]              write-fail 6  read ok 0  read EMPTY 0  read FAIL 6
deploy [v1,v4]           write-fail 2  read ok 4  read EMPTY 0  read FAIL 2
deploy [v4]              write-fail 0  read ok 6  read EMPTY 0  read FAIL 0

== Expand/contract, backfill skipped
add [v1]                 write-fail 0  read ok 6  read EMPTY 0  read FAIL 0
deploy [v1,v2]           write-fail 0  read ok 6  read EMPTY 0  read FAIL 0
deploy [v2,v3]           write-fail 0  read ok 4  read EMPTY 2  read FAIL 0
deploy [v3]              write-fail 0  read ok 2  read EMPTY 4  read FAIL 0

== Expand/contract
add [v1]                 write-fail 0  read ok 6  read EMPTY 0  read FAIL 0
deploy [v1,v2]           write-fail 0  read ok 6  read EMPTY 0  read FAIL 0
backfill [v2]            write-fail 0  read ok 6  read EMPTY 0  read FAIL 0
deploy [v2,v3]           write-fail 0  read ok 6  read EMPTY 0  read FAIL 0
deploy [v3,v4]           write-fail 0  read ok 6  read EMPTY 0  read FAIL 0
drop [v4]                write-fail 0  read ok 6  read EMPTY 0  read FAIL 0

তিনটি ব্যবহারিক নিয়ম। প্রথমত, schema বদল আর তার ওপর নির্ভরশীল কোড কখনো একই deploy-এ নয়। দ্বিতীয়ত, migration অ্যাপ চালুর সময় নয় — পঞ্চাশটি Pod একসাথে একই ALTER চালাতে দৌড়ায়; এটি একবার চলা আলাদা job. তৃতীয়ত, বড় backfill থামানো-আবার-শুরু-করা যায় এমন background job (পর্ব ৩৭); একই ধারা (dual write → backfill → পড়া বদল) এক database থেকে আরেকটিতে বা নতুন shard-এ ডেটা সরাতেও কাজে লাগে (পর্ব ২৩)। ORM-এর migration টুলের দিক DBMS কোর্সের ORM আর migration পর্বে।

৮ · Config আর software supply chain

Config-ও কোড: timeout, pool-এর আকার, flag-এর মান, rate limit (পর্ব ৪৯) — এগুলো বদলানো কোড বদলানোর মতোই বিপজ্জনক, আর প্রকাশিত বহু postmortem-এ বড় outage-এর শুরু একটি config বদল থেকে বলে বর্ণনা আছে। তাই config-এর জন্যও একই নিয়ম: version control-এ রাখা, review, schema দিয়ে যাচাই (“timeout ঋণাত্মক হতে পারে না”), আর একসাথে সবখানে নয় — canary-র মতো ধাপে ধাপে ছড়ানো। চলমান অবস্থায় বদলানো dynamic config-এ একটি ভুল মান সেকেন্ডে সবখানে পৌঁছায়, তাই এক ক্লিকে আগের মানে ফেরার ব্যবস্থা জরুরি। Password, API key আর certificate config নয়, secret — image-এ বা git-এ নয়, আলাদা secret store থেকে চালুর সময় (পর্ব ৫২)।

Supply chain — যা আপনি লেখেননি: একটি সাধারণ সেবার image-এ আপনার নিজের কোডের চেয়ে অন্যের লেখা library অনেক বেশি। প্রতিরক্ষার মৌলিক অভ্যাসগুলো:

• Pin করা: lockfile-এ প্রতিটি dependency-র নির্দিষ্ট সংস্করণ আর তার hash (dependency pinning); base image-ও digest দিয়ে।
• উপাদানের তালিকা: প্রতিটি image-এর SBOM (software bill of materials) — কোন library, কোন সংস্করণ। SPDX আর CycloneDX প্রচলিত ফরম্যাট। নতুন দুর্বলতা প্রকাশ পেলে “কোন সেবায় এটি আছে?” — উত্তর মিনিটে।
• Scan: pipeline-এ জানা দুর্বলতার (CVE) তালিকার সাথে মেলানো, আর যতটা সম্ভব ছোট base image রাখা।
• স্বাক্ষর আর যাচাই: CI image-এ একটি digital signature দেয় (artifact signing; Sigstore-এর cosign-এর মতো টুল আছে), আর cluster শুধু বিশ্বস্ত pipeline-এর স্বাক্ষরওয়ালা image চালাতে দেয়। SLSA-র মতো কাঠামো build-এর উৎস-প্রমাণের (provenance) স্তর বর্ণনা করে — বিস্তারিত সংস্করণভেদে বদলায়।

৯ · AI-এর যুগে deployment-নকশা যাচাই

“আমার সেবার জন্য zero-downtime deploy-এর নকশা দাও” লিখলে AI মুহূর্তে পরিপাটি উত্তর দেয় — প্রায়ই “Kubernetes, Argo CD, Istio আর canary দিয়ে।” কিন্তু কয়েকটি ভুল প্রায় নিয়ম করে আসে:

AI-এর দেওয়া release-পরিকল্পনা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• Artifact একবার build হয়, manifest-এ digest আছে, আর পরিবেশভেদে শুধু config বদলায়
• Canary-র প্রতিটি ধাপে কত অনুরোধ জমবে আর কোন নিয়মে rollback, নিজে হিসাব করে মিলিয়েছি
• Database বদলের প্রতিটি অবস্থায় চলমান সব সংস্করণ ঠিক চলে, আর lock-এর ঝুঁকি documentation-এ যাচাই করেছি
• প্রতিটি ধাপ থেকে ফেরার পথ লেখা আছে, আর অন্তত একবার staging-এ rollback করে দেখেছি
• Failure-mode পর্যালোচনা করেছি: Pod মাঝপথে মরলে, canary-র metric না এলে, flag সেবা বন্ধ থাকলে কী হয়