Availability আর reliability — nines, redundancy, single point of failure আর MTTR

১ · তিনটি আলাদা প্রশ্ন — availability, reliability আর durability

মাসের প্রথম দিন, রাত ৯টা। আপনি একটি মোবাইল ব্যাংকিং অ্যাপে (কাল্পনিক) বিদ্যুৎ বিল দিতে গেলেন — পর্দায় এলো “সেবাটি সাময়িকভাবে বন্ধ”। দশ মিনিট পর আবার চেষ্টা করলেন; এবার কাজ হলো, ব্যালান্সও ঠিক আছে। এখানে তিনটি আলাদা প্রশ্ন লুকিয়ে আছে: সেবাটি যখন দরকার তখন পাওয়া যায় কি? চালু হলে না থেমে কতক্ষণ চলে? আর বন্ধ থাকার সময় আপনার টাকার হিসাব নিরাপদ ছিল কি? এরা পর্ব ২-এর non-functional requirement; এই পর্বে এদের মাপা, হিসাব করা আর নকশায় বাড়ানো শিখবেন।

Availability — সময় দিয়ে মাপবেন, না অনুরোধ দিয়ে?

Availability মানে সেবা যখন দরকার তখন ঠিকঠাক কাজ করার অনুপাত। দুইভাবে মাপা হয়:

দুটির ফল আলাদা হতে পারে। রাত ৩টার ২০ মিনিটের বিভ্রাট আর ঈদের আগের সন্ধ্যার ২০ মিনিট সময়ের হিসাবে সমান, কিন্তু দ্বিতীয়টিতে বহু গুণ বেশি মানুষ খালি হাতে ফেরেন। আবার মাত্র ৫% অনুরোধ এক ঘণ্টা ধরে ব্যর্থ হলে সেটা “চালু” না “বন্ধ”? অনুরোধভিত্তিক মাপ এই আংশিক বিভ্রাটও ধরে। Google-এর Site Reliability Engineering বই (২০১৬) দুটি মাপই ব্যাখ্যা করে, আর জানায় যে বিশ্বজুড়ে ছড়ানো সেবায় তারা সাধারণত অনুরোধভিত্তিক মাপ নেয়। কোন উত্তর “সফল” (৫০০-গোত্রের error নয়? সময়মতো এসেছে? — latency-র মাপ পর্ব ৪-এ) আর কোন অনুরোধ গোনা হবে — এই সংজ্ঞা আগে লিখে নিতে হয়।

Reliability — সময় জুড়ে না থেমে চলা

Reliability-র কঠোর সংজ্ঞা: নির্দিষ্ট সময় t জুড়ে, নির্দিষ্ট পরিবেশে সিস্টেম একবারও ব্যর্থ না হয়ে কাজ করার সম্ভাবনা R(t). ব্যর্থতার হার স্থির ধরলে (গড়ে প্রতি MTBF ঘণ্টায় একটি, অংশ ৩) R(t) = e^−t/MTBF. MTBF ৫০০ ঘণ্টা হলে এক দিনে কোনো ব্যর্থতা না হওয়ার সম্ভাবনা e^{−২৪/৫০০} ≈ ০.৯৫৩, এক সপ্তাহে মাত্র ≈ ০.৭১৫।

দুটি আলাদা কেন? একটি সার্ভিস এলোমেলো সময়ে গড়ে ঘণ্টায় একবার crash করে আর ১ সেকেন্ডে আবার চালু হয়। Availability = ৩৫৯৯ ÷ ৩৬০০ ≈ ৯৯.৯৭% — শুনতে দারুণ! কিন্তু এক ঘণ্টা না থেমে চলার সম্ভাবনা মাত্র e^−১ ≈ ০.৩৭ — আধা ঘণ্টার ভিডিও কল প্রায়ই মাঝপথে ভাঙবে। উল্টো দিকে, যে সিস্টেম প্রতি রাতে দুই ঘণ্টা রক্ষণাবেক্ষণে বন্ধ থাকে কিন্তু চালু অবস্থায় কখনো ভাঙে না, তার availability প্রায় ৯১.৭%, অথচ reliability চমৎকার। সতর্কতা: Martin Kleppmann-এর Designing Data-Intensive Applications (২০১৭)-এর মতো বইয়ে আর দৈনন্দিন কথায় “reliability” ঢিলেঢালা অর্থে — “কিছু ভুল হলেও ঠিকভাবে চলা” — ব্যবহৃত হয়।

Durability — ডেটা না হারানো

Durability মানে একবার “সংরক্ষিত হয়েছে” বলে নিশ্চিত করা ডেটা পরে হারিয়ে না যাওয়া — সাধারণত বলা হয় বছরে কত nine; ACID-এর D-ও একই কথা বলে। Durability আর availability স্বাধীন: ATM বন্ধ থাকলেও টাকা নিরাপদ; আবার সেবা দিব্যি চলছে কিন্তু একটি ডিস্ক নষ্ট হয়ে কারও ছবি চিরতরে হারাল। দ্বিতীয়টি অনেক বেশি ভয়ংকর — বন্ধ সেবা ফিরে আসে, হারানো ডেটা আসে না।

২ · “কয়টি nine” — অনুমোদিত downtime-এর হিসাব

Availability-কে মুখে বলা হয় nines দিয়ে: ৯৯% “দুটি nine”, ৯৯.৯% “তিনটি nine”, ৯৯.৯৯৯% “পাঁচটি nine”; ৯৯.৯৫%-কে কেউ বলেন “সাড়ে তিন nine”. হিসাব একটাই: অনুমোদিত downtime = (১ − A) × সময়কাল। এই পর্বে বছর = ৩৬৫ দিন (৮,৭৬০ ঘণ্টা = ৫,২৫,৬০০ মিনিট) আর মাস = ৩০ দিন (৪৩,২০০ মিনিট) ধরা হলো। কেউ ৩৬৫.২৫ দিনের বছর ধরেন — তখন ৯৯.৯৯%-এ ৫২.৫৬-এর বদলে প্রায় ৫২.৬০ মিনিট; চুক্তিতে কোনটি ধরা হলো তা লেখা থাকা উচিত।

নিচের ক্যালকুলেটর একই টেবিল বানায়। তালিকায় নিজের লক্ষ্যের শতাংশ বসিয়ে চালিয়ে দেখুন।

// Allowed downtime for an availability target ("nines").
// Convention: year = 365 days, month = 30 days, week = 7 days, day = 24 h.
const periods = [["year", 365 * 86400], ["month", 30 * 86400],
                 ["week", 7 * 86400], ["day", 86400]];      // seconds

function human(sec) {                       // 31536 -> "8h 45m 36s"
  if (sec >= 86400) return (sec / 86400).toFixed(2) + " days";
  const h = Math.floor(sec / 3600), m = Math.floor((sec % 3600) / 60);
  const s = +(sec % 60).toFixed(3);         // + drops trailing zeros
  return (h ? h + "h " : "") + (h || m ? m + "m " : "") + s + "s";
}

console.log("target   " + periods.map(p => p[0].padEnd(14)).join(""));
for (const pct of [99, 99.9, 99.95, 99.99, 99.999]) {
  const down = 1 - pct / 100;               // fraction of time allowed down
  const row = periods.map(([, sec]) => human(down * sec).padEnd(14));
  console.log((pct + "%").padEnd(9) + row.join(""));
}

target   year          month         week          day
99%      3.65 days     7h 12m 0s     1h 40m 48s    14m 24s
99.9%    8h 45m 36s    43m 12s       10m 4.8s      1m 26.4s
99.95%   4h 22m 48s    21m 36s       5m 2.4s       43.2s
99.99%   52m 33.6s     4m 19.2s      1m 0.48s      8.64s
99.999%  5m 15.36s     25.92s        6.048s        0.864s

৩ · MTBF, MTTR আর MTTD — availability-র ভেতরের সূত্র

শতাংশ বলে কতটা বন্ধ ছিল; নকশা বদলাতে জানতে হয় কেন। প্রতিটি সেবার জীবন একটি পালাবদল: চালু → ব্যর্থ → সারানো → আবার চালু। এর তিনটি গড় মাপ:

• MTBF (mean time between failures): এই পর্বে মানে — আবার চালু হওয়ার পর থেকে পরের ব্যর্থতা পর্যন্ত গড় চালু-সময়। কঠোর reliability-প্রকৌশলে এর নাম MTTF, আর সেখানে MTBF = MTTF + MTTR (OS কোর্সের RAID পর্বে সেই সংজ্ঞা)। MTTR খুব ছোট হলে পার্থক্য প্রায় শূন্য, তবু কোনটি বোঝাচ্ছেন স্পষ্ট লিখবেন।
• MTTR (mean time to repair/recover): ব্যর্থতা শুরু থেকে সেবা আবার ঠিক হওয়া পর্যন্ত গড় সময়। “R” কোথাও repair, কোথাও recover বা restore — প্রতিষ্ঠানভেদে মাপার শুরু-শেষ আলাদা।
• MTTD (mean time to detect): ব্যর্থতা শুরু থেকে টের পাওয়া পর্যন্ত গড় সময় — MTTR-এরই প্রথম অংশ। MTTR = টের পাওয়া + কারণ খোঁজা + সারানো বা rollback + যাচাই।

শেষ আসন্ন রূপটি একটি গুরুত্বপূর্ণ সত্য দেখায়: MTTR অর্ধেক করা আর MTBF দ্বিগুণ করা হুবহু একই ফল দেয়। MTBF ৭২০ ঘণ্টা (মোটামুটি মাসে একবার), MTTR ১ ঘণ্টা হলে A = ৭২০ ÷ ৭২১ ≈ ৯৯.৮৬%, বছরে প্রায় ১২.১৫ ঘণ্টা বন্ধ। MTTR ৩০ মিনিটে নামালে ৭২০ ÷ ৭২০.৫ ≈ ৯৯.৯৩%; MTBF ১,৪৪০ ঘণ্টায় তুললেও ১,৪৪০ ÷ ১,৪৪১ ≈ ৯৯.৯৩% — একই সংখ্যা, বছরে প্রায় ৬.০৮ ঘণ্টা।

সূত্রটি কি সত্যিই মেলে? নিচের Monte Carlo simulation একটি অংশকে বহু বছর চালায়: চালু-সময় আর মেরামত-সময় এলোমেলোভাবে বেছে নেয় (গড় ৫০০ আর ২ ঘণ্টা), তারপর মোট বন্ধ-সময় গুনে availability বের করে। এলোমেলো সংখ্যা আসে নির্দিষ্ট seed-এর PRNG থেকে, তাই প্রতিবার একই ফল।

// One component alternates UP (mean MTBF) and DOWN (mean MTTR) for many years.
// Seeded PRNG (mulberry32), so every run prints the same numbers.
function mulberry32(seed) {
  return function () {
    seed = (seed + 0x6D2B79F5) | 0;
    let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}
const rand = mulberry32(2026);
const expo = (mean) => -mean * Math.log(1 - rand());   // random time, given mean
function simulate(mtbf, mttr, years, fixedRepair) {
  const horizon = years * 8760;                         // hours
  let t = 0, down = 0, failures = 0;
  while (true) {
    t += expo(mtbf);                                    // working period
    if (t >= horizon) break;
    failures++;
    const r = fixedRepair ? mttr : expo(mttr);          // repair period
    down += Math.min(r, horizon - t);
    t += r;
  }
  return { failures, A: 1 - down / horizon };
}
const MTBF = 500, MTTR = 2;                             // hours
console.log("formula A = MTBF/(MTBF+MTTR) = " + (MTBF / (MTBF + MTTR)).toFixed(6));
console.log("years  failures  simulated A  downtime h/yr");
for (const y of [1, 10, 100, 1000]) {
  const r = simulate(MTBF, MTTR, y, false);
  console.log(String(y).padEnd(7) + String(r.failures).padEnd(10) +
              r.A.toFixed(6).padEnd(13) + ((1 - r.A) * 8760).toFixed(2));
}
const f = simulate(MTBF, MTTR, 1000, true);
console.log("repair always exactly " + MTTR + " h, 1000 years: A = " + f.A.toFixed(6));

formula A = MTBF/(MTBF+MTTR) = 0.996016
years  failures  simulated A  downtime h/yr
1      20        0.995627     38.31
10     162       0.996216     33.15
100    1728      0.996028     34.80
1000   17485     0.995996     35.07
repair always exactly 2 h, 1000 years: A = 0.996012

৪ · Series আর parallel — অংশ জুড়লে availability কত

বাস্তবের সেবা একটি অংশ নয় — DNS, load balancer, app server, database, বাইরের payment gateway মিলে একটি পথ। পুরো পথের availability-র দুটি মৌলিক নিয়ম, আর দুটিই দাঁড়িয়ে একটি অনুমানে: অংশগুলোর ব্যর্থতা স্বাধীন — একটির নষ্ট হওয়া অন্যটির সম্ভাবনা বদলায় না।

Series — সবাইকে চালু থাকতে হবে

অনুরোধ সফল হতে যদি প্রতিটি অংশকেই কাজ করতে হয় (DNS এবং LB এবং app এবং DB), সেটি series. অংশ i চালু থাকার সম্ভাবনা A_i; স্বাধীন ঘটনাগুলো একসাথে ঘটার সম্ভাবনা তাদের গুণফল, তাই:

প্রতিটি A_i ১-এর কম, তাই গুণফল প্রতিটির চেয়ে ছোট: শিকল তার দুর্বলতম কড়ির চেয়েও দুর্বল। দুটি ৯৯.৯% অংশ পরপর দিলে ৯৯.৮০ শতাংশ। মুখে মুখে হিসাবের কৌশল: unavailability U_i = ১ − A_i ছোট হলে মোট U ≈ U₁ + U₂ + … — series-এ downtime মোটামুটি যোগ হয়। তাই redundancy ছাড়া বসানো প্রতিটি নতুন অংশ — নতুন queue, নতুন microservice — পথের availability কমায়।

Parallel — যেকোনো একটি চালু থাকলেই চলে

দুটি একই রকম সার্ভারের যেকোনো একটি সেবা দিতে পারলে সেটি parallel. স্তরটি ব্যর্থ হয় কেবল সবগুলো একসাথে বন্ধ হলে। স্বাধীনতা ধরে তার সম্ভাবনা (১ − A₁)(১ − A₂)…, তাই:

দুটি ৯৯% সার্ভার: দুটিই বন্ধ থাকার সম্ভাবনা ০.০১ × ০.০১ = ০.০০০১, তাই A = ৯৯.৯৯ শতাংশ — দুটি nine থেকে চারটি! কিন্তু সূত্রে আরও দুটি অনুমান লুকানো: (১) একটি পড়লে অন্যটি সঙ্গে সঙ্গে, নির্ভুলভাবে দায়িত্ব নেয় — failover-এ সময় লাগে না; (২) টিকে থাকা একটি কপিই পুরো load সামলাতে পারে। দুটিই প্রায়ই মিথ্যা — অংশ ৫ আর ৬-এ দেখবেন।

k-of-n — capacity হিসাবে আনলে

ধরুন পিক সময়ে অন্তত ২টি সার্ভার লাগে (এমন সংখ্যা আসে পর্ব ৩-এর হিসাব থেকে), আর আছে ৩টি — এটি “৩-এর মধ্যে ২” বা N+1 গঠন (N = ২, ১টি বাড়তি)। প্রতিটির availability a হলে, n-এর মধ্যে অন্তত k টি চালু থাকার সম্ভাবনা (k-of-n):

a = ০.৯৯, n = ৩, k = ২ হলে: তিনটিই চালু ০.৯৯^৩ = ০.৯৭০২৯৯, ঠিক দুটি চালু ৩ × ০.৯৯^২ × ০.০১ = ০.০২৯৪০৩; যোগফল ০.৯৯৯৭০২। “যেকোনো একটি যথেষ্ট” হলে হতো ০.৯৯৯৯৯৯ — capacity-র শর্তে unavailability প্রায় ৩০০ গুণ।

এবার redundancy ছাড়া একটি পথ ধরে ধরে গুণ করি। “পরে” চাপুন।

৫ · পূর্ণ উদাহরণ — DNS থেকে database পর্যন্ত একটি নকশা

একটি কাল্পনিক অনলাইন বাস-টিকিট সেবা ধরুন — ঈদের আগে রাত ৮টা থেকে ১০টায় সবচেয়ে বেশি ভিড়। নকশা (ছবি ৫.১): ফোন DNS থেকে ঠিকানা জেনে নেয়; অনুরোধ যায় একজোড়া load balancer-এর ভাগ করা virtual IP-তে; সেখান থেকে তিনটি stateless app server-এর যেকোনোটিতে; সব লেখা যায় database-এর primary-তে, যার প্রতিটি পরিবর্তন standby কপিতে চলে যায় (replication, পর্ব ২২)। Availability ধরা যাক (শেখার জন্য গোল সংখ্যা): DNS ৯৯.৯৯%, প্রতিটি LB ৯৯.৯%, প্রতিটি app server ৯৯%, প্রতিটি DB সার্ভার ৯৯.৯%; পিকে অন্তত ২টি app server লাগে।

স্তর ধরে হিসাব: LB জোড়া ১ − ০.০০১^২ = ০.৯৯৯৯৯৯; app স্তর (৩-এর মধ্যে ২) ০.৯৯৯৭০২; DB জোড়া ০.৯৯৯৯৯৯; DNS ০.৯৯৯৯। চার স্তর series-এ গুণ করলে ≈ ০.৯৯৯৬০০, অর্থাৎ ৯৯.৯৬% — বছরে প্রায় ৩.৫ ঘণ্টা; redundancy ছাড়া ছিল ৯৮.৭৯ শতাংশ। কোন বাড়তি অংশ কতটা দিল, ধাপে ধাপে দেখুন — চিহ্নিত বাক্সগুলো সেই ধাপে বদলেছে:

নিচের ক্যালকুলেটরে একই হিসাব; a বা designs বদলে নিজের architecture বসাতে পারেন।

// Worked design: DNS -> LB tier -> app tier -> DB tier, all in SERIES.
// Availability of ONE component (assumed, not measured); failures independent.
const a = { dns: 0.9999, lb: 0.999, app: 0.99, db: 0.999 };

const series = (...xs) => xs.reduce((p, x) => p * x, 1);  // all must work
const parallel = (x, n) => 1 - Math.pow(1 - x, n);          // any 1 of n works
function kOfN(k, n, x) {                     // at least k of n identical parts
  let sum = 0, c = 1;                        // c = C(n, i), the binomial number
  for (let i = 0; i <= n; i++) {
    if (i >= k) sum += c * Math.pow(x, i) * Math.pow(1 - x, n - i);
    c = c * (n - i) / (i + 1);
  }
  return sum;
}
const lb2 = parallel(a.lb, 2), db2 = parallel(a.db, 2);
const designs = [   // [name, dns, lb tier, app tier, db tier]
  ["1 LB, 1 app, 1 DB", a.dns, a.lb, a.app, a.db],
  ["+2 apps (need 2 of 3)", a.dns, a.lb, kOfN(2, 3, a.app), a.db],
  ["+second LB", a.dns, lb2, kOfN(2, 3, a.app), a.db],
  ["+standby DB", a.dns, lb2, kOfN(2, 3, a.app), db2],
  ["  (if 1 of 3 apps is enough)", a.dns, lb2, parallel(a.app, 3), db2],
  ["+4th app (need 2 of 4)", a.dns, lb2, kOfN(2, 4, a.app), db2],
  ["+second DNS provider", parallel(a.dns, 2), lb2, kOfN(2, 4, a.app), db2],
];
console.log("design".padEnd(30) + "total A".padEnd(11) + "downtime/year");
for (const [name, ...tiers] of designs) {
  const A = series(...tiers), h = (1 - A) * 8760;          // hours per year
  const down = h >= 1 ? h.toFixed(2) + " h" : (h * 60).toFixed(1) + " min";
  console.log(name.padEnd(30) + ((A * 100).toFixed(4) + "%").padEnd(11) + down);
}

design                        total A    downtime/year
1 LB, 1 app, 1 DB             98.7922%   105.80 h
+2 apps (need 2 of 3)         99.7604%   20.99 h
+second LB                    99.8601%   12.25 h
+standby DB                   99.9600%   3.50 h
  (if 1 of 3 apps is enough)  99.9897%   54.1 min
+4th app (need 2 of 4)        99.9894%   55.7 min
+second DNS provider          99.9994%   3.1 min

৬ · Redundancy, failover আর single point of failure

Redundancy মানে একই কাজের জন্য বাড়তি অংশ রাখা। বাড়তি অংশ কীভাবে কাজে নামবে, তার কয়েকটি ধরন — আর প্রতিটির দাম আলাদা।

টের পাওয়া — health check আর heartbeat

কেউ ব্যর্থতা টের না পাওয়া পর্যন্ত failover শুরুই হয় না। Health check-এ load balancer বা monitor প্রতি কয়েক সেকেন্ডে সার্ভারকে জিজ্ঞেস করে (যেমন /health ঠিকানায় একটি অনুরোধ), পরপর কয়েকবার উত্তর না পেলে তাকে traffic থেকে সরায় (পর্ব ১৪)। Heartbeat-এ node নিজেই নিয়মিত “আমি বেঁচে আছি” পাঠায় (পর্ব ৪৪)। দুই ক্ষেত্রেই detection-এর সময় মোটামুটি বিরতি × কয়টি মিস হলে মৃত ঘোষণা: প্রতি ৫ সেকেন্ডে আর ৩টি মিসে প্রায় ১০–১৫ সেকেন্ড। বিরতি ছোট করলে দ্রুত ধরা পড়ে, কিন্তু নেটওয়ার্কের সামান্য ঝাঁকুনিতেই সুস্থ node-কে মৃত ভাবার ঝুঁকি বাড়ে — আর অকারণ failover নিজেই একটি বিভ্রাট। একটি ফাঁদও আছে: health check যদি database-ও যাচাই করে, DB-র এক মুহূর্তের ধীরতায় LB সব app server-কে একসাথে “অসুস্থ” ঘোষণা করতে পারে।

এবার সবচেয়ে কঠিন failover — database-এর active-passive জোড়া। ধাপগুলোর সময় যোগ করে দেখি, “স্বয়ংক্রিয়” failover-এও ব্যবহারকারী কতক্ষণ খালি হাতে থাকেন। সময়গুলো ধরা যাক; বাস্তবে সেটআপভেদে সেকেন্ড থেকে মিনিট।

Single point of failure খোঁজা

Single point of failure (SPOF) এমন একটি অংশ, যার একার ব্যর্থতায় পুরো সেবা বন্ধ। পদ্ধতি সরল কিন্তু ধৈর্যের: অনুরোধের পুরো পথ আঁকুন — প্রতিটি বাক্স আর প্রতিটি তীর — তারপর প্রতিটিকে জিজ্ঞেস করুন, “এটি একা মারা গেলে কি সেবা বন্ধ?” সার্ভার আর database সবাই দেখেন; বিপদ লুকিয়ে থাকে কম চোখে পড়া জায়গায়:

৭ · Failure domain আর correlated failure — যখন স্বাধীনতা ভেঙে পড়ে

Parallel-এর সূত্রে দুটি ৯৯.৯% সার্ভার দেয় ৯৯.৯৯৯৯ শতাংশ। কিন্তু দুটিই যদি একই rack-এ, একই বিদ্যুৎ-স্ট্রিপে থাকে? Rack-এর বিদ্যুৎ গেলে দুটিই একসাথে বন্ধ — “স্বাধীন” অনুমান মিথ্যা। এমন একসাথে ব্যর্থতাকে বলে correlated failure, আর যে সীমানার ভেতরের সবকিছু একটি ঘটনায় একসাথে পড়তে পারে, তাকে failure domain.

বেশিরভাগ বড় cloud প্রদানকারী একটি region-এর ভেতরে কয়েকটি availability zone রাখে — আলাদা বিদ্যুৎ, কুলিং আর নেটওয়ার্কসহ এক বা একাধিক ডেটা সেন্টার, যাতে একটির বিপর্যয় অন্যটিতে না ছড়ায়। নাম, দূরত্ব আর নিশ্চয়তা প্রদানকারীভেদে আলাদা; নিজের প্রদানকারীর ডকুমেন্টেশন দেখে নেবেন।

সাধারণ অংশকে আলাদা করে series-এ বসানোই correlated failure হিসাবে আনার সহজ কৌশল। ধরা যাক rack-এর বিদ্যুৎ আর switch মিলে availability ৯৯.৯৫%, প্রতিটি সার্ভার ৯৯.৯%:

• একই rack-এ দুটি সার্ভার: A = ০.৯৯৯৫ × (১ − ০.০০১^২) ≈ ০.৯৯৯৪৯৯ — প্রায় ৯৯.৯৫%, বছরে ৪.৩৯ ঘণ্টা। কাগজের ৯৯.৯৯৯৯% কোথায় গেল? Rack একাই series-এ বসে সব খেয়ে ফেলেছে।
• আলাদা rack-এ, আলাদা বিদ্যুতে: প্রতিটি পথ ০.৯৯৯৫ × ০.৯৯৯ = ০.৯৯৮৫০০৫; দুটি parallel: ১ − (০.০০১৪৯৯৫)^২ ≈ ০.৯৯৯৯৯৮ — বছরে প্রায় ১.২ মিনিট।

একই সার্ভার, একই খরচ — শুধু কোথায় বসালেন তাতে বছরে ৪ ঘণ্টার বেশি বনাম ১ মিনিট। কপিগুলোকে আলাদা failure domain-এ ছড়ানোর এই নিয়মকে বলে anti-affinity. Zone-স্তরে capacity-র হিসাবও আসে: ৩টি zone-এ সমানভাবে ছড়ানো সেবায় একটি zone হারালে বাকি দুটিকে পুরো load নিতে হয় — প্রতিটির ক্ষমতা লাগে পিকের ৫০%, মোট ১৫০%; দুটি zone হলে মোট ২০০%.

৮ · Durability-র হিসাব আর SLO — কতটা যথেষ্ট

কপির সংখ্যা আর ডেটা হারানোর সম্ভাবনা

Durability-র সবচেয়ে সরল হাতিয়ার replication factor — একটি ডেটা-খণ্ডের কয়টি কপি আলাদা ডিস্কে রাখা হবে। একটি সরল শিক্ষণ-মডেল (বাস্তব কোনো সিস্টেম নয়) দিয়ে দেখি: ডিস্ক স্বাধীনভাবে, স্থির হারে নষ্ট হয়; ধরা যাক বছরে ২% ডিস্ক নষ্ট হয় (মাঠ-গবেষণায় বছরে কয়েক শতাংশ পর্যন্ত পাওয়া গেছে — OS কোর্সের RAID পর্ব দেখুন); একটি কপি হারালে সিস্টেম R ঘণ্টায় নতুন কপি বানায়। ডেটা হারায় কেবল তখন, যখন নতুন কপি তৈরির আগেই সব কপি মারা যায়। r টি কপির জন্য হারানোর হার ≈ r! · λ^r · R^{r − 1}, যেখানে λ প্রতি ডিস্ক-ঘণ্টায় নষ্ট হওয়ার হার। যুক্তি: প্রথম ব্যর্থতা আসে r·λ হারে; মেরামতের R ঘণ্টায় বাকি r − ১টির একটি মরার সম্ভাবনা প্রায় (r − ১)·λ·R; এভাবে শেষ কপি পর্যন্ত গুণ।

// Durability of ONE chunk of data kept as r copies on r different disks.
// SIMPLE TEXTBOOK MODEL, not a real system: disks fail independently at a
// constant rate; a lost copy is re-created within R hours; the chunk is lost
// only if every copy dies before re-replication. Loss rate = r! * lambda^r * R^(r-1)
const AFR = 0.02;                              // assumed: 2% of disks fail per year
const lambda = -Math.log(1 - AFR) / 8760;      // failures per disk-hour
const fact = (n) => (n <= 1 ? 1 : n * fact(n - 1));

function lossPerYear(r, R) {
  const perHour = fact(r) * Math.pow(lambda, r) * Math.pow(R, r - 1);
  return 1 - Math.exp(-perHour * 8760);        // P(chunk lost within a year)
}
console.log("copies  repair  P(loss)/year  nines");
for (const [r, R] of [[1, 24], [2, 24], [3, 24], [3, 1], [3, 168]]) {
  const p = lossPerYear(r, R);
  console.log(String(r).padEnd(8) + (R + " h").padEnd(8) +
              p.toExponential(2).padEnd(14) + (-Math.log10(p)).toFixed(1));
}

copies  repair  P(loss)/year  nines
1       24 h    2.00e-2       1.7
2       24 h    2.24e-6       5.7
3       24 h    3.71e-10      9.4
3       1 h     6.45e-13      12.2
3       168 h   1.82e-8       7.7

পূর্ণ কপির বিকল্প erasure coding: ধরুন ডেটাকে ৬টি টুকরোয় ভাগ করে আরও ৩টি parity টুকরো বানানো হলো; ৯টির যেকোনো ৬টি থাকলেই পুরো ডেটা ফেরে। যেকোনো ৩টি হারানো সহ্য করে, অথচ জায়গা লাগে ৯ ÷ ৬ = ১.৫ গুণ — তিন কপির ৩ গুণের অর্ধেক। দাম: লেখা, পড়া আর পুনর্গঠনে বেশি হিসাব ও নেটওয়ার্ক। বিস্তারিত পর্ব ২৬-এ।

SLI, SLO, SLA আর error budget — একটি ঝলক

SLA সাধারণত SLO-র চেয়ে ঢিলা রাখা হয়, যাতে চুক্তি ভাঙার আগেই দল সতর্ক হয়। SLO থেকে আসে error budget: ১০০% − SLO. ৩০ দিনে ৯৯.৯% SLO মানে বাজেট ৪৩.২ মিনিট, বা সেই মাসে ১ কোটি অনুরোধ এলে ১০,০০০টি ব্যর্থ অনুরোধ। মাসের মাঝেই বাজেট প্রায় শেষ হলে ঝুঁকিপূর্ণ release থামিয়ে নির্ভরযোগ্যতার কাজে মন দেওয়া হয়; বাজেট বাকি থাকলে দল সাহস করে নতুন জিনিস ছাড়ে। এই চর্চা জনপ্রিয় করেছে Google-এর SRE বই (২০১৬)। SLI মাপা, alert বানানো আর বাজেটের নিয়ম চালানো — পর্ব ৫০-এ।

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

“আমার অ্যাপকে ৯৯.৯৯% available বানাও” লিখলে AI এক নিমেষে বাক্স আর তীরে ভরা নকশা দেবে। কিন্তু availability-র প্রশ্নে কিছু ভুল AI প্রায় নিয়ম করে করে:

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

• প্রতিটি সংখ্যা নিজে আবার হিসাব করেছি — series-এ গুণ, parallel-এ ব্যর্থতার গুণ ঠিক জায়গায়
• “স্বাধীন ব্যর্থতা” কোথায় ধরা হয়েছে চিহ্নিত করেছি; ভাগ করা rack, zone, config বা সংস্করণ series-এ বসিয়ে দেখেছি
• Failover-এর সময় আর বছরে কতবার — downtime-এ যোগ করেছি; একটি সার্ভার বা zone হারালে বাকিরা পুরো load নিতে পারে কি না মিলিয়েছি
• কোনো পণ্যের SLA, সীমা বা দাম অফিসিয়াল ডকুমেন্টেশনে মিলিয়েছি; AI-এর সংখ্যা হুবহু নিইনি
• প্রতিটি নতুন অংশ (queue, cache, সার্ভিস) পথের availability কমায় কি না ভেবেছি; দরকার না থাকলে বাদ দিয়েছি