Cloud migration — 6R, ধাপে ধাপে স্থানান্তর আর ঝুঁকি

১ · বাসা বদল — কেন যাবেন, আর কেন যাবেন না

ঢাকায় যাঁরা ভাড়া বাসায় থাকেন, তাঁরা জানেন ১ তারিখের বাসা বদল কেমন কাজ। সব জিনিস এক ট্রাকে তোলা যায় না। ভাঙা চেয়ার ফেলে দিতে হয়। পুরোনো ফ্রিজ বিক্রি করে নতুন কিনতে হয়। আলমারি খুলে আবার জোড়া লাগাতে হয়। আর যে রাতে বদল করছেন, সেই রাতেও রান্না চাই। Cloud migration ঠিক এই কাজ: চলতি সিস্টেমকে on-premises থেকে cloud-এ সরানো, ব্যবসা না থামিয়ে।

আগের পর্বগুলোতে আপনি cloud-এ নতুন সিস্টেম বানাতে শিখেছেন। বাস্তবে অনেক প্রকৌশলীর প্রথম কাজ হয় উল্টো: দশ বছরের পুরোনো সিস্টেম, যার নকশার কাগজ নেই, যিনি বানিয়েছিলেন তিনি চাকরি ছেড়েছেন, আর দিনে লাখ টাকার লেনদেন চলছে। সেই সিস্টেম সরানো নতুন বানানোর চেয়ে আলাদা দক্ষতা।

লক্ষ্যটি সংখ্যায় লিখুন। “আধুনিক হব” কোনো লক্ষ্য নয়। “জুনের মধ্যে data centre খালি”, “DR-এর RTO ৪ ঘণ্টা থেকে ৩০ মিনিট”, “ঈদের চূড়ায় ৩ গুণ চাপ সামলানো” লক্ষ্য। পর্ব ০৪-এর TCO হিসাবও এখানে আসে: পুরো ছবি ধরলে cloud অনেক সময় সস্তা হয় না, দ্রুত আর নমনীয় হয়। আর পুরো সরে যাওয়াও বাধ্যতামূলক নয়। পর্ব ০৩-এর hybrid cloud অনেক প্রতিষ্ঠানের স্থায়ী ঠিকানা।

ছয়টি ধাপের ছবি

Provider-দের কাঠামোয় নাম আলাদা, যেমন AWS বলে assess, mobilize আর migrate. গঠন প্রায় এক। মাঝের তিনটি ধাপ প্রতিটি wave-এ ঘুরে আসে।

২ · আগে জানুন কী আছে — discovery আর dependency

বাসা বদলের আগে কেউ আলমারি খুলে দেখেন ভেতরে কী আছে। Migration-এ এই কাজের নাম discovery. Server-এর তালিকা শুধু শুরু। জানতে হয় প্রতিটি app-এর মালিক কে, ব্যবহার কত, CPU আর disk-এর চাপ কেমন, OS আর licence কী, আর সবচেয়ে বড় কথা, কে কার সাথে কথা বলে। এই শেষ তথ্যের ছবির নাম dependency map.

কাগজের diagram প্রায়ই পুরোনো। তাই আসল প্রমাণ নিন network থেকে: firewall log, VPC flow log ধরনের নথি, ss বা netstat-এর নিয়মিত নমুনা (পর্ব ১৩), আর provider-এর discovery agent. নিচের block-এ একটি কাল্পনিক দোকানের নমুনা flow data আছে। প্রতিটি সারিতে উৎস, গন্তব্য, port, দুই সপ্তাহের connection আর MB.

#!/bin/bash
# Who talks to whom? All data below is sample text, built here.
set -euo pipefail
export LC_ALL=C
cat > flows.txt <<'EOF'
web1 shop-app 8080 18000 900
web2 shop-app 8080 17500 880
shop-app shop-db 5432 410000 7400
shop-app search 9200 26000 300
reporting shop-db 5432 1200 5100
devtest shop-db 5432 40 12
wiki shop-db 5432 300 6
mail-relay shop-app 25 900 45
EOF
cat > servers.txt <<'EOF'
attendance
devtest
mail-relay
old-cms
reporting
search
shop-app
shop-db
stock-box
web1
web2
wiki
EOF
echo "== chatty links (connections in the window, most first)"
sort -k4,4nr flows.txt | awk '$4 >= 10000 {printf "%-10s -> %-9s port %-5s %7d conns %5d MB\n",$1,$2,$3,$4,$5}'
echo "== depended on by (number of different callers)"
awk '{print $2, $1}' flows.txt | sort -u | awk '{n[$1]++} END {for (s in n) print n[s], s}' | sort -k1,1nr -k2,2
echo "== silent servers (no flow seen, ask before you decide)"
awk '{print $1; print $2}' flows.txt | sort -u > seen.txt
comm -23 servers.txt seen.txt

== chatty links (connections in the window, most first)
shop-app   -> shop-db   port 5432   410000 conns  7400 MB
shop-app   -> search    port 9200    26000 conns   300 MB
web1       -> shop-app  port 8080    18000 conns   900 MB
web2       -> shop-app  port 8080    17500 conns   880 MB
== depended on by (number of different callers)
4 shop-db
3 shop-app
1 search
== silent servers (no flow seen, ask before you decide)
attendance
old-cms
stock-box

৩ · 5R থেকে 7R — প্রতিটি app-এর জন্য একটি পথ

একটি app-এর পথ ঠিক করতে কয়েকটি প্রশ্ন ক্রমে করুন। কেউ ব্যবহার করে? আইন বা যন্ত্র কি আটকে রেখেছে? বাজারে কি একই জিনিস কেনা যায়? এটি কি ব্যবসার মূল অংশ, আর দল কি প্রস্তুত? নিচের simulator ঠিক এই ক্রমে চলে: প্রথম যে নিয়ম মেলে, সেটিই ফল। apps-এর flag বদলে আবার চালিয়ে দেখুন। effort-এর সংখ্যাগুলো আপেক্ষিক অনুমান, কোনো মাপা মান নয়।

// 6R recommender: the first rule that matches wins. Change the flags and run again.
const apps = {
  old_cms:     "unused",
  attendance:  "hardware",          // tied to a fingerprint device in the office
  mail:        "commodity",         // ordinary need, a SaaS already does it
  wiki:        "",
  devtest:     "",
  search:      "managed",           // a managed service can replace the server
  reporting:   "managed",
  shop_db:     "managed core",
  shop_app:    "core",              // core app, team not ready to redesign yet
  stock_batch: "core",
  demo_ready:  "core scale team",   // same app, if growth and skills were there
  demo_vmware: "vmware deadline",   // hypervisor estate, data-centre lease ending
};
const rules = [   // [all flags needed, or any one if split by "|"], strategy, reason
  ["unused",          "retire",     "nobody uses it, stop paying for it"],
  ["hardware|legal",  "retain",     "it cannot leave now, review later"],
  ["commodity",       "repurchase", "buy the same function as SaaS"],
  ["vmware deadline", "relocate",   "move the hypervisor as it is, fast"],
  ["core scale team", "refactor",   "the value justifies a redesign"],
  ["managed",         "replatform", "swap one layer, keep the code"],
  ["",                "rehost",     "move as it is, improve later"],
];
const effort = { retire: 0, retain: 0, repurchase: 2, relocate: 1, rehost: 1, replatform: 3, refactor: 13 };
const hit = (need, flags) => need.includes("|")
  ? need.split("|").some(n => flags.includes(n))
  : need.split(" ").filter(Boolean).every(n => flags.includes(n));
let total = 0;
for (const [name, f] of Object.entries(apps)) {
  const [, s, why] = rules.find(([need]) => hit(need, f.split(" ")));
  total += effort[s];
  console.log(name.padEnd(12), s.padEnd(11), String(effort[s]).padStart(2), why);
}
console.log("total effort, in rough relative points:", total);

old_cms      retire       0 nobody uses it, stop paying for it
attendance   retain       0 it cannot leave now, review later
mail         repurchase   2 buy the same function as SaaS
wiki         rehost       1 move as it is, improve later
devtest      rehost       1 move as it is, improve later
search       replatform   3 swap one layer, keep the code
reporting    replatform   3 swap one layer, keep the code
shop_db      replatform   3 swap one layer, keep the code
shop_app     rehost       1 move as it is, improve later
stock_batch  rehost       1 move as it is, improve later
demo_ready   refactor    13 the value justifies a redesign
demo_vmware  relocate     1 move the hypervisor as it is, fast
total effort, in rough relative points: 29

লেখার সময়ের নাম এগুলো। পণ্যের নাম, দেশভেদে প্রাপ্যতা আর নতুন গ্রাহকের সুযোগ বদলায়, তাই ব্যবহারের আগে provider-এর docs দেখুন। পছন্দটি শেষে vendor lock-in-এও প্রভাব ফেলে: পর্ব ৭৪-এ দেখেছেন, managed service যত গভীর, সরে যাওয়া তত কঠিন।

৪ · Migration wave — এক ট্রাকে সব নয়

ঈদের আগে সদরঘাটে যেমন যাত্রীরা ক্রম মেনে লঞ্চে ওঠেন, তেমনি app-গুলো দল বেঁধে সরে। প্রতিটি দলের নাম migration wave. প্রথম wave ছোট আর কম ঝুঁকির, যাতে দল পথটি শিখে নেয়। মূল সিস্টেম আসে পরে। দুটি নিয়ম এখানে কাজ করে।

• ঘনিষ্ঠরা একসাথে: যারা খুব বেশি কথা বলে, তারা একটি move group. আলাদা করলে network-এর দেরি ঢুকে পড়ে।
• ক্রম মানা: ভিত্তি আগে। Landing zone, network, IAM, DNS আর পর্যবেক্ষণের ব্যবস্থা প্রথম app-এর আগেই তৈরি থাকে (পর্ব ৩৫)।

আরেকটি বাস্তব সীমা আছে: এক রাতে দল কতগুলো server সামলাতে পারে। নিচের planner এই তিনটি নিয়ম মানে। chatty জোড়াগুলো জুড়ে move group বানায়, তারপর প্রতি wave-এ প্রস্তুত দলগুলো সীমার মধ্যে তোলে।

// Wave planner. Rule 1: a chatty pair moves together. Rule 2: "after" goes in an earlier wave.
const apps = {   // servers, and what must already be in the cloud
  wiki: { srv: 1, after: [] },  devtest: { srv: 1, after: [] },  mail: { srv: 1, after: [] },
  search: { srv: 1, after: ["devtest"] },  reporting: { srv: 1, after: ["devtest"] },
  shop_app: { srv: 3, after: ["search", "reporting"] },
  shop_db: { srv: 2, after: [] },  stock: { srv: 1, after: [] },
};
const chatty = [["shop_app", "shop_db"], ["stock", "shop_db"]];
// Merge chatty pairs into move groups (a small union-find).
const boss = {};
for (const a in apps) boss[a] = a;
const find = a => boss[a] === a ? a : (boss[a] = find(boss[a]));
for (const [a, b] of chatty) boss[find(a)] = find(b);
const groups = {};
for (const a in apps) (groups[find(a)] ??= []).push(a);

function plan(maxServers) {
  const moved = new Set();
  let left = Object.values(groups), wave = 0;
  console.log(`--- at most ${maxServers} servers per wave`);
  while (left.length) {
    let used = 0; const now = []; wave++;
    for (const g of left) {
      const size = g.reduce((s, a) => s + apps[a].srv, 0);
      const ready = g.every(a => apps[a].after.every(d => moved.has(d) || g.includes(d)));
      if (ready && used + size <= maxServers) { now.push(g); used += size; }
    }
    if (!now.length) return console.log(`BLOCKED: ${left.map(g => g.join("+")).join(", ")}`);
    now.flat().forEach(a => moved.add(a));
    left = left.filter(g => !now.includes(g));
    console.log(`wave ${wave}: ${now.map(g => g.join("+")).join(", ")} (${used} servers)`);
  }
}
plan(6); plan(4);

--- at most 6 servers per wave
wave 1: wiki, devtest, mail (3 servers)
wave 2: search, reporting (2 servers)
wave 3: shop_app+shop_db+stock (6 servers)
--- at most 4 servers per wave
wave 1: wiki, devtest, mail (3 servers)
wave 2: search, reporting (2 servers)
BLOCKED: shop_app+shop_db+stock

ক্যালেন্ডারও দেখুন। ঈদের আগের সপ্তাহ, বেতনের দিন, বছর শেষের হিসাবের সময় মূল সিস্টেম সরানো হয় না। একে অনেক প্রতিষ্ঠানে change freeze বলে।

৫ · ডেটা সরানো — online, offline আর সময়ের হিসাব

Server নতুন করে বানানো যায়, ডেটা যায় না। ডেটা সরানোর দুটি পথ।

সময়ের হিসাব

পরীক্ষার সবচেয়ে সাধারণ ভুল: Byte আর bit গুলিয়ে ফেলা। ডেটা মাপা হয় byte-এ, লিংক bit-এ। ১ byte = ৮ bit. আর লিংকের পুরো ক্ষমতা কখনো ডেটা পায় না: protocol, অন্য traffic আর দূরত্ব কিছু খায়। একে এখানে কার্যকারিতা e বলি।

উদাহরণ ১. ১০ TB, ১০০ Mbps, e = ০.৮.

10 × 10^12 B × 8 = 8 × 10^13 bit
usable = 100 × 10^6 × 0.8 = 8 × 10^7 bit/s
time = 8 × 10^13 ÷ (8 × 10^7) = 10^6 s = 11.57 days

উদাহরণ ২, ডেটা বদলাচ্ছে। কপি চলতেই সোর্সে দিনে ২% বদলাচ্ছে, মানে ২০০ GB. এই পরিবর্তনের গতি r = 200 × 10^9 × 8 ÷ 86400 = 18.52 Mbps. লিংকের b = 80 Mbps. কপি করতে করতে নতুন পরিবর্তন জমে, তাদের পাঠাতে আরও সময়, তাতে আরও জমে। এই ধারার যোগফল সহজ:

এখানে 11.57 ÷ (1 − 18.52/80) = 11.57 ÷ 0.7685 = 15.06 দিন। সাড়ে তিন দিন বেশি। আর r ≥ b হলে হরটি শূন্য বা ঋণাত্মক: কপি কখনো ধরতেই পারবে না। ১০ TB-র ক্ষেত্রে দিনে ৮৬৪ GB বদলালে ৮০ Mbps-এর লিংক এই সীমায় পৌঁছায়।

এবার অন্য পথটি ধরুন। ধরে নিই একটি appliance-এ ৮০ TB ধরে, আনা-নেওয়া মিলিয়ে ১৪ দিন, প্রতি যন্ত্রে $৫০০, আর এক সাথে ৪টি চালানো যায়। এগুলো শেখার জন্য ধরে নেওয়া গোল সংখ্যা। আসল দাম, ধারণক্ষমতা আর বাংলাদেশে পৌঁছানোর সুযোগ provider-এর পাতায় মিলিয়ে নিন।

// Network or truck? ASSUMED numbers, not real prices. Change them and run again.
const EFF = 0.8;            // share of the link that really carries data
const CHANGE = 0.02;        // share of the data that changes per day during the copy
const BOX_TB = 80;          // usable TB in one transfer appliance
const BOX_DAYS = 14;        // shipping both ways, copying, import
const BOX_COST = 500;       // $ per appliance, including courier
const LINK_DAY = 40;        // $ per day for the extra link during the copy
const days = (tb, mbps) => tb * 1e12 * 8 / (mbps * 1e6 * EFF) / 86400;

function sync(tb, mbps) {   // bulk copy, then catch up with changes
  const rate = tb * CHANGE * 1e12 * 8 / 86400;  // change rate in bits per second
  const usable = mbps * 1e6 * EFF;
  return rate >= usable ? Infinity : days(tb, mbps) / (1 - rate / usable);
}
console.log("  TB   Mbps  bulk_d  sync_d  link$ | box_d boxes  box$  winner");
for (const tb of [1, 10, 100, 500]) for (const mbps of [100, 1000, 10000]) {
  const total = sync(tb, mbps), never = total === Infinity;
  const boxes = Math.ceil(tb / BOX_TB), boxDays = BOX_DAYS * Math.ceil(boxes / 4);
  const win = never ? "box*" : total <= boxDays ? "network" : "box";
  console.log(String(tb).padStart(4), String(mbps).padStart(6), days(tb, mbps).toFixed(2).padStart(7),
    (never ? "never" : total.toFixed(2)).padStart(7),
    (never ? "-" : (total * LINK_DAY).toFixed(0)).padStart(6), "|", String(boxDays).padStart(4),
    String(boxes).padStart(5), String(boxes * BOX_COST).padStart(5), "", win);
}
console.log("* the link is slower than the changes: a box moves the bulk, but plan a freeze");
for (const mbps of [100, 1000, 10000]) {   // break-even for the bulk copy alone
  const tb = mbps * 1e6 * EFF * BOX_DAYS * 86400 / 8 / 1e12;
  console.log(`at ${mbps} Mbps the bulk copy takes ${BOX_DAYS} days at ${tb.toFixed(1)} TB`);
}

  TB   Mbps  bulk_d  sync_d  link$ | box_d boxes  box$  winner
   1    100    1.16    1.18     47 |   14     1   500  network
   1   1000    0.12    0.12      5 |   14     1   500  network
   1  10000    0.01    0.01      0 |   14     1   500  network
  10    100   11.57   15.06    602 |   14     1   500  box
  10   1000    1.16    1.18     47 |   14     1   500  network
  10  10000    0.12    0.12      5 |   14     1   500  network
 100    100  115.74   never      - |   14     2  1000  box*
 100   1000   11.57   15.06    602 |   14     2  1000  box
 100  10000    1.16    1.18     47 |   14     2  1000  network
 500    100  578.70   never      - |   28     7  3500  box*
 500   1000   57.87   never      - |   28     7  3500  box*
 500  10000    5.79    6.54    262 |   28     7  3500  network
* the link is slower than the changes: a box moves the bulk, but plan a freeze
at 100 Mbps the bulk copy takes 14 days at 12.1 TB
at 1000 Mbps the bulk copy takes 14 days at 121.0 TB
at 10000 Mbps the bulk copy takes 14 days at 1209.6 TB

খরচেরও দুটি দিক। Cloud-এ ঢোকা ডেটায় provider সাধারণত টাকা নেন না, কিন্তু বেরোনো ডেটায় egress নেন (পর্ব ৭২)। অন্য cloud থেকে সরলে তাই বিল আসে সোর্সের দিকে। এছাড়া লিংকের ভাড়া আর সমান্তরালে নতুন storage-এর বিল কপি শুরুর দিন থেকেই চলে। যন্ত্রে পাঠানো ডেটা encrypted থাকে কি না, আর চাবি কার হাতে, সেটিও দেখে নিন।

৬ · Cutover — চলন্ত গাড়ির চাকা বদল

Cutover হলো সেই মুহূর্ত, যখন আসল traffic পুরোনো জায়গা ছেড়ে নতুন জায়গায় যায়। Stateless app-এ এটি সহজ, কারণ দুই পাশে একই জিনিস চলে। Database-এ কঠিন, কারণ একই মুহূর্তে দুই জায়গায় সত্য থাকা চলে না। হাতে চারটি কৌশল।

DNS-এর কথা মনে করুন (পর্ব ২৯)। Propagation কোনো push নয়। পুরোনো উত্তর cache-এ TTL শেষ না হওয়া পর্যন্ত থাকে। তাই TTL কমাতে হয় cutover-এর অন্তত এক পুরোনো TTL আগে। আর TTL কমালেও সবাই সাথে সাথে ঘোরে না: কিছু client নিজের মতো cache করে, আর connection pool পুরোনো connection ধরে রাখে। সেজন্য পুরোনো DB-তে লেখা বন্ধই থাকে। ভুল ঠিকানায় যাওয়া client তখন ব্যর্থ হয়, চুপচাপ ভুল জায়গায় লেখে না।

এবার একটি পুরো cutover দেখুন। সোর্স অফিসের PostgreSQL, লক্ষ্য cloud-এর managed PostgreSQL (পর্ব ২২), মাঝে logical replication, যা CDC-র একটি রূপ। “পরে” চাপুন, আর সারির সংখ্যা খেয়াল করুন। ঘড়ির সংখ্যা আর সব মান কাল্পনিক।

মূল কাজগুলো PostgreSQL-এ দেখতে এমন। নিচের লেখা একটি উদাহরণ, যা এই পাতায় চলে না। Publisher-এ wal_level = logical লাগে, schema আগে থেকে target-এ থাকতে হয়, আর managed DB-তে অনুমতির ধরন provider-ভেদে আলাদা।

-- Source: publish the tables
CREATE PUBLICATION shop_pub FOR ALL TABLES;

-- Target: copies existing rows, then streams changes
CREATE SUBSCRIPTION shop_sub
  CONNECTION 'host=old-db.example dbname=shop user=repl_user'
  PUBLICATION shop_pub;

-- Source: how far behind is the target, in bytes?
SELECT application_name,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes
FROM pg_stat_replication;

-- Target, at cutover: sequences are not replicated, so move them on
SELECT setval('orders_id_seq', (SELECT max(id) FROM orders) + 1000);

Dual write শুনতে সহজ: app দুই জায়গাতেই লেখে। কিন্তু দ্বিতীয় লেখা ব্যর্থ হলে? দুই লেখার ক্রম উল্টে গেলে? দুই পাশ চুপচাপ আলাদা হয়ে যায়। তাই ব্যবহার করলে একটিকে সত্যের উৎস ধরুন, আর নিয়মিত মিলিয়ে দেখুন। সাধারণত CDC বেশি নিরাপদ, কারণ সত্য থাকে একটি জায়গায়, database-এর নিজের log-এ।

Strangler fig বড় পুরোনো app-এর পথ। বট-পরিবারের একধরনের গাছ অন্য গাছকে ঘিরে ধীরে বড় হয়, আর শেষে আসল গাছটি আর থাকে না। ঠিক তেমনি সামনে একটি proxy বসে, একটি একটি path নতুন service-এ যায়, আর শেষে পুরোনো monolith বন্ধ হয়। Martin Fowler ২০০৪ সালে এই নামটি দেন। বিস্তারিত আছে System Design-এর microservices পর্বে। Traffic-এর ভাগ বাড়ানোর কৌশল পর্ব ৫৯-এর canary-র মতোই।

৭ · Rollback আর testing — ফেরার পথ আগে আঁকুন

পাহাড়ে ওঠার আগে নামার পথ দেখে নিতে হয়। Migration-এ দুটি জিনিস আগে লেখা থাকে: কোন সংখ্যা দেখলে ফিরব, আর কীভাবে ফিরব। মাঝরাতে ক্লান্ত দল “আরেকটু চেষ্টা করি” বলতে চাইবে। আগে লেখা শর্ত সেই তর্ক থামায়। আর জেনে রাখুন point of no return: যে মুহূর্তের পরে নতুন লেখা পুরোনো জায়গায় নেই। Reverse replication না থাকলে সেটি cutover-এর ঠিক পরের প্রথম লেখা।

যা পরীক্ষা করতে হয়

• ডেটা: সারির সংখ্যা, টেবিল-ভিত্তিক checksum, আর ব্যবসার যোগফল, যেমন মোট বিক্রি।
• চাপ: আগের latency-কে ভিত্তি ধরে চূড়ার চাপে পরীক্ষা (পর্ব ৬৮)। Shadow traffic থাকলে আরও ভালো।
• কাজ: Smoke test, লগইন, অর্ডার, পেমেন্ট, রিপোর্ট।
• মহড়া: পুরো cutover অন্তত একবার ঘড়ি ধরে। একে dress rehearsal বলে। Rollback-ও মহড়ায় চালান।
• পুনরুদ্ধার: নতুন জায়গার backup থেকে restore করে দেখা (পর্ব ২৪)।

এবার একটি ব্যর্থ দিন দেখুন। ওপরের cutover রাত ০২:০৩-এ শেষ হয়েছিল। দিনটি মাসের ১ তারিখ। সকাল ৯টায় অফিসে রয়ে যাওয়া stock-box জেগে ওঠে। ফেরার শর্ত আগেই লেখা: error ≥ ২% টানা ৫ মিনিট।

৮ · পৌঁছে যা করবেন — নিরাপত্তা, compliance আর দল

নতুন বাসায় উঠে প্রথমে তালা বদলাতে হয়। Migration-এর সময় তাড়াহুড়োয় অনেক “সাময়িক” দরজা খোলা হয়, আর সেগুলো পরে আর বন্ধ হয় না। Shared responsibility-র সীমাও এখন আলাদা: পুরোনো firewall আর ঘরের তালা নেই, দায়িত্বের ভাগ নতুন।

• Migration-এর সাময়িক account, চাবি আর firewall নিয়ম মুছে ফেলেছি
• IAM-এ least privilege, মানুষের জন্য সাময়িক role (পর্ব ৩১)
• ডেটা rest আর transit-এ encrypted, চাবি KMS-এ (পর্ব ৩৩)
• পুরোনো সিস্টেমের password আর secret নতুন করে বানিয়েছি, code-এ কিছু নেই
• DB আর storage বাইরে থেকে খোলা নেই; audit log চালু (পর্ব ৩৪)
• প্রতিটি resource-এ owner আর cost-এর tag, budget alert চালু

Compliance যাওয়ার আগেই দেখুন, পৌঁছে নয়। ডেটা কোন দেশে থাকবে, সেটি data residency-র প্রশ্ন (পর্ব ০৫)। ব্যাংক, আর্থিক সেবা, স্বাস্থ্য বা সরকারি ডেটা নিয়ে বাংলাদেশে আলাদা নিয়ম থাকতে পারে, আর নিয়ম বদলায়ও। তাই আজকের অবস্থা নিয়ন্ত্রক সংস্থা, চুক্তি আর আইনজীবীর সাথে মিলিয়ে নিন। Provider-এর certificate থাকলেই আপনার সিস্টেম compliant হয় না।

দল অনেক সময় প্রযুক্তির চেয়ে কঠিন। যিনি দশ বছর server সামলেছেন, তিনিই সিস্টেমের সবচেয়ে বড় জ্ঞানের ভাণ্ডার। তাঁকে বাদ দিয়ে নয়, সাথে নিয়ে এগোন: প্রশিক্ষণ, ছোট দল আগে, যৌথ on-call, আর নতুন runbook. Monitoring আর alert-ও পুরোনো জায়গা থেকে নতুন জায়গায় আনুন। নইলে প্রথম রাতে কেউ জানবেন না কী ঘটছে। দুই সিস্টেম একসাথে চালাতে হবে বলে কিছুদিন দলের কাজও দ্বিগুণ হবে, এটি পরিকল্পনায় রাখুন।

৯ · “কাল্পনিক বাজার”-এর তিন wave আর সাধারণ ব্যর্থতা

পুরো গল্পটি জুড়ি। “কাল্পনিক বাজার” একটি বানানো মাঝারি অনলাইন দোকান, কোনো আসল প্রতিষ্ঠান নয়। ঢাকার একটি ভাড়া করা ঘরে ১৪টি server. চুক্তি শেষ হবে এক বছর পরে, আর গত ঈদে সাইট দুবার বসে গেছে। সব টাকার অঙ্ক শেখার জন্য ধরে নেওয়া গোল সংখ্যা।

সাধারণ ব্যর্থতা ১ — সমস্যাসহ তুলে আনা

Rehost করলে অগোছালো script, হাতে বদলানো config, ভুল permission, ধীর query, সব সাথে আসে। Cloud কোনো সমস্যা নিজে সারায় না। তাই প্রতিটি rehost-এর সাথে একটি লেখা তালিকা রাখুন: পরে কী ঠিক হবে, কে ঠিক করবেন, কবে।

সাধারণ ব্যর্থতা ২ — আলাদা স্তরের মাঝের দেরি

একই ঘরে app আর DB-র দূরত্ব প্রায় শূন্য। আলাদা করলে প্রতিটি query-তে network-এর পুরো round trip যোগ হয়। যে app-এ এক পাতার জন্য অনেক ছোট query যায়, তাকে chatty app বলে। ধরে নিন একটি পাতায় ১২০টি query পরপর, প্রতিটিতে DB-র কাজ ১ ms, app-এর নিজের কাজ ১০০ ms. RTT-গুলো ধরে নেওয়া: ব্যবহারকারী থেকে অফিস ১০ ms, ব্যবহারকারী থেকে cloud ৫০ ms, অফিস থেকে cloud ৪০ ms, একই region-এর ভেতরে ১ ms. নিজের পথে ping বা mtr দিয়ে মেপে নিন।

সাধারণ ব্যর্থতা ৩ — খরচের চমক

ওপরের গল্পে চূড়ার মাসে বিল প্রায় দ্বিগুণ। আরও কয়েকটি চমক পরিচিত: on-premises-এর মাপেই VM বানানো, যদিও অর্ধেক অলস; ২৪ ঘণ্টা চালু dev server; replication আর log-এর data transfer; ভুলে থাকা disk আর snapshot; আর বাতিল হওয়া migration-এর “সাময়িক” bucket. Budget alert শুরুতেই রাখুন, আর পর্ব ৭৩-এর FinOps অভ্যাস wave-এর সাথে চালান।

১০ · AI-এর যুগে migration

AI একটি migration পরিকল্পনা কয়েক সেকেন্ডে লিখে দেয়, আর সেটি পড়তে দারুণ লাগে। কিন্তু সে আপনার flow data, মাসের শেষের batch বা দলের দক্ষতা দেখেনি। সে সাধারণত যে ভুলগুলো করে:

AI-এর পরিকল্পনা হাতে পেলে

• সময়ের হিসাব নিজে মিলিয়েছি, bit আর পরিবর্তন ধরে
• প্রতিটি সেবার নাম আর flag official docs-এ পেয়েছি
• ধ্বংসাত্মক কমান্ড আলাদা করে চিহ্নিত, আগে dry-run বা plan দেখেছি
• Throwaway পরিবেশে মহড়া করেছি, budget alert চালু রেখে, শেষে সব মুছেছি
• ফেরার শর্ত সংখ্যায় লেখা, rollback-ও চালিয়ে দেখেছি
• কোনো secret, আসল host বা account id prompt-এ দিইনি