Availability, SLA ও Disaster Recovery

"আমাদের system সবসময় চালু থাকবে" এমন প্রতিশ্রুতি কেউ দিতে পারে না। Hardware নষ্ট হয়, deploy এ bug যায়, data center এ বিদ্যুৎ যায়, cloud provider এর পুরো অঞ্চল বসে যায়। তাই প্রশ্নটা "নষ্ট হবে কিনা" না, বরং "কতটা নির্ভরযোগ্য হওয়া দরকার, আর নষ্ট হলে কত দ্রুত ফিরবো"। এই অধ্যায়ে availability মাপা, SLA/SLO, redundancy আর disaster recovery।

#Availability: "কয়টা ৯"

Availability = চালু থাকার সময় ÷ মোট সময়।

প্রতিটা অতিরিক্ত "৯" এর খরচ অনেক গুণ বেশি: আরও redundancy, আরও অঞ্চল, আরও স্বয়ংক্রিয়তা, আরও মানুষ। তাই প্রথম প্রশ্ন: ব্যবসার জন্য আসলে কতটা দরকার? একটা স্কুলের রুটিন app এর জন্য 99.9% যথেষ্ট; bKash এর মতো payment এর জন্য অনেক বেশি লাগে।

#নির্ভরতার অঙ্ক

ক্রমানুসারে (series): একটা request কে যদি তিনটা অংশ পেরোতে হয়, প্রতিটা 99.9%:

মোট = 0.999 × 0.999 × 0.999 ≈ 99.7%

প্রতিটা নতুন নির্ভরতা মোট availability কমায়। ১০টা microservice এর chain এ প্রত্যেকে 99.9% হলেও মোট প্রায় 99%।

সমান্তরালে (parallel/redundant): দুইটা server এর যেকোনো একটা চালু থাকলেই চলে, প্রতিটা 99%:

দুটোই বন্ধ থাকার সম্ভাবনা = 0.01 × 0.01 = 0.0001 → মোট 99.99%

#SLI, SLO, SLA

SLA সবসময় SLO এর চেয়ে ঢিলে রাখা হয়, যাতে ভেতরের লক্ষ্য মিস করলেও চুক্তি ভাঙার আগে সতর্ক হওয়া যায়।

#Error budget

SLO 99.9% মানে মাসে ০.১% ব্যর্থ হওয়ার অনুমতি আছে (প্রায় ৪৩ মিনিট)। এই "বাজেট" খরচ করা যায়:

• বাজেট বাকি থাকলে: দ্রুত নতুন feature release করো, ঝুঁকি নাও
• বাজেট শেষ হলে: নতুন feature থামাও, নির্ভরযোগ্যতার কাজ করো

এভাবে "দ্রুত feature" বনাম "স্থিতিশীলতা" এর চিরন্তন তর্ক সংখ্যা দিয়ে মেটানো যায়।

#Single point of failure খোঁজা

Architecture এর ছবি এঁকে প্রতিটা box এর জন্য জিজ্ঞেস করো: "এটা এখনই বন্ধ হলে কী হবে?"

#Disaster recovery: RTO আর RPO

বড় বিপদ (database মুছে গেলো, পুরো অঞ্চল বন্ধ, ransomware) হলে দুইটা প্রশ্ন:

• RTO (Recovery Time Objective): কত দ্রুত আবার চালু হতে হবে? (১ ঘণ্টা? ১ দিন?)
• RPO (Recovery Point Objective): সর্বোচ্চ কতটা সময়ের data হারানো চলবে? (০? ৫ মিনিট? ২৪ ঘণ্টা?)

#Backup এর নিয়ম

• 3-2-1: ৩টা copy, ২ ধরনের মাধ্যমে, ১টা অন্য জায়গায় (অন্য অঞ্চল/অন্য account)
• Backup এ ও নিরাপত্তা: ransomware এর যুগে backup বদলানো বা মোছা যায় না এমন (immutable) রাখা
• নিয়মিত restore পরীক্ষা: যে backup থেকে কখনো restore করা হয়নি, সেটা কাজ করবে কিনা কেউ জানে না

#নির্ভরযোগ্যতার অভ্যাস

• ছোট, ঘন ঘন deploy: একসাথে ১০০টা বদলের চেয়ে ১০টা বদল ধরা আর ফেরানো সহজ
• Canary আর feature flag: নতুন জিনিস প্রথমে ৫% user এ, সমস্যা হলে flag বন্ধ
• Graceful degradation: recommendation service বন্ধ হলে home page এ "জনপ্রিয় restaurant" দেখাও, পুরো পেজ ভাঙা না
• Runbook: "Database এর disk ভরে গেলে কী করবে" ধাপে ধাপে লেখা, রাত ৩টায় ঘুম চোখে মানুষও যেন পারে
• Postmortem, দোষারোপ ছাড়া: কী হলো, কেন হলো, আবার যেন না হয় তার জন্য কী বদলাবে; ব্যক্তিকে না, প্রক্রিয়াকে ঠিক করো
• Chaos testing: ইচ্ছা করে একটা server বন্ধ করে দেখো system টেকে কিনা (staging এ শুরু করো)

#অনুশীলন

#নিজেকে যাচাই করো

99.9% availability মানে মাসে মোটামুটি কতক্ষণ বন্ধ থাকা চলে?

প্রায় ৪৩-৪৪ মিনিট (বছরে প্রায় ৮.৭৬ ঘণ্টা)।

তিনটা 99.9% এর অংশ ক্রমানুসারে থাকলে মোট availability কত হয়, কেন?

প্রায় 99.7%, কারণ request সফল হতে তিনটাকেই চালু থাকতে হবে, তাই সম্ভাবনা গুণ হয়: 0.999³।

SLO আর SLA এর পার্থক্য কী?

SLO ভেতরের লক্ষ্য। SLA customer এর সাথে চুক্তি, না মানলে ক্ষতিপূরণ দিতে হয়। SLA সাধারণত SLO এর চেয়ে ঢিলে রাখা হয়।

RTO আর RPO এর পার্থক্য কী?

RTO হলো দুর্ঘটনার পর কত দ্রুত আবার চালু হতে হবে। RPO হলো দুর্ঘটনার আগের সর্বোচ্চ কতটা সময়ের data হারানো চলবে।

Error budget কী কাজে লাগে?

SLO এর অনুমোদিত ব্যর্থতাকে "বাজেট" হিসেবে দেখায়। বাজেট বাকি থাকলে দ্রুত release আর ঝুঁকি নেওয়া যায়; শেষ হলে নতুন feature থামিয়ে নির্ভরযোগ্যতায় মনোযোগ। Feature বনাম স্থিতিশীলতার সিদ্ধান্ত সংখ্যা দিয়ে নেওয়া যায়।