SLA, SLO ও SLI — রিলায়েবিলিটি মেট্রিক্স

SLA, SLO & SLI — reliability metrics

৭ মিনিট পড়া মধ্যম · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এক নজরে · TL;DR

SLI হলো একটি প্রকৃত মাপা মেট্রিক (যেমন "৯৯.৯৫% রিকোয়েস্ট ২০০ms-এর মধ্যে")। SLO হলো সেই SLI-এর জন্য একটি অভ্যন্তরীণ লক্ষ্যমাত্রা (যেমন "৯৯.৯% আপটাইম")। SLA হলো একটি বাহ্যিক, প্রায়ই চুক্তিভিত্তিক প্রতিশ্রুতি — সাধারণত SLO-এর চেয়ে শিথিল রাখা হয়, যাতে দলের হাতে সমস্যা ঠিক করার মার্জিন থাকে।
Error budget = 100% − SLO। একটি ৩০-দিনের মাসে (৪৩,২০০ মিনিট) ৯৯.৯% SLO মানে ৪৩.২ মিনিট, ৯৯.৯৯% মানে ৪.৩২ মিনিট, ৯৯.৯৯৯% মানে ~২৬ সেকেন্ড অনুমোদিত ডাউনটাইম।
প্রতিটি বাড়তি "নাইন" প্রায় ১০ গুণ কড়া — তাই যতটা সম্ভব রিলায়েবল বানানোর চেয়ে, ব্যবসার আসল প্রয়োজন অনুযায়ী সঠিক SLO বেছে নেওয়াই আসল দক্ষতা।
Google SRE-এর মূল দর্শন — error budget আছে মানে ফিচার রিলিজ করার "অনুমতি" আছে; budget শেষ হলে দল রিলায়েবিলিটিতে মনোযোগ দেয়। এই কোর্সের রেট লিমিটিং (L35), সার্কিট ব্রেকার (L27), ফেইলওভার (L37), আইডেম্পোটেন্সি (L38) — সবই আসলে এই budget রক্ষা করার হাতিয়ার।

এই পাঠে যা শিখবেন

SLI, SLO ও SLA-এর সুনির্দিষ্ট সংজ্ঞা এবং একটির থেকে অন্যটি কীভাবে বের হয়
Error budget-এর গণিত — SLO থেকে অনুমোদিত ডাউনটাইম হিসাব করা
কেন SLA সবসময় SLO-এর চেয়ে শিথিল রাখা হয়, এবং কেন প্রতিটি নতুন "নাইন" এত ব্যয়বহুল
error-budget-চালিত ইঞ্জিনিয়ারিং সংস্কৃতি কীভাবে কাজ করে এবং এই কোর্সের বাকি রিলায়েবিলিটি প্যাটার্নগুলোর সাথে এর সম্পর্ক

১ · SLI, SLO ও SLA — তিনটি স্তর

"রিলায়েবিলিটি" একটি অস্পষ্ট শব্দ, যতক্ষণ না আমরা সেটাকে সংখ্যায় রূপান্তর করি। এই কাজেই তিনটি সম্পর্কিত কিন্তু আলাদা ধারণা ব্যবহার হয় — প্রতিটি আগেরটির উপর তৈরি।

SLIService Level Indicatorএকটি প্রকৃত, মাপা মেট্রিক — সিস্টেম আসলে কী পারফরম্যান্স দিচ্ছে তার সংখ্যা। যেমন "গত ৫ মিনিটে ৯৯.৯৫% রিকোয়েস্ট সফল হয়েছে"।
প্রকৃত মাপা মেট্রিক — মনিটরিং (L41) থেকে সরাসরি আসে।

SLOService Level Objectiveএকটি SLI-এর জন্য অভ্যন্তরীণ লক্ষ্যমাত্রা — "আমরা চাই এই মেট্রিক এই থ্রেশহোল্ডের উপরে থাকুক"। এটি একটি টিমের নিজস্ব প্রতিশ্রুতি, গ্রাহকের সাথে চুক্তি নয়।
একটি SLI-এর জন্য অভ্যন্তরীণ লক্ষ্য।

SLAService Level Agreementগ্রাহকের সাথে একটি বাহ্যিক, প্রায়ই চুক্তিভিত্তিক প্রতিশ্রুতি — লঙ্ঘন হলে সাধারণত আর্থিক পেনাল্টি বা ক্রেডিট দিতে হয়।
একটি বাহ্যিক, চুক্তিভিত্তিক প্রতিশ্রুতি।

সম্পর্ক এক নজরে

SLI → পরিমাপ। SLO → লক্ষ্য (SLI-এর উপর)। SLA → প্রতিশ্রুতি (সাধারণত SLO-এর চেয়ে শিথিল, যাতে দল সমস্যা লক্ষ্য করে ঠিক করার সময় পায় SLA ভাঙার আগেই)। উদাহরণ — একটি টিমের অভ্যন্তরীণ SLO হতে পারে ৯৯.৯% আপটাইম, কিন্তু গ্রাহকের সাথে SLA-তে প্রতিশ্রুতি দেওয়া হয় মাত্র ৯৯.৫% — যাতে ০.৪% মার্জিন থাকে।

SLI মাপা হয়, SLO-এর সাথে তুলনা হয়, SLA বাহ্যিক প্রতিশ্রুতি — SLO থেকেই Error Budget হিসাব হয়।

২ · Error Budget — গণিত

Error BudgetError Budget100% বিয়োগ SLO — অর্থাৎ একটি নির্দিষ্ট সময়কালে (সাধারণত এক মাস) সিস্টেমের যতটুকু "অবিশ্বস্ত" হওয়ার অনুমতি আছে। হলো 100% − SLO। একটি ৩০-দিনের মাসে মোট মিনিট = ৩০ × ২৪ × ৬০ = ৪৩,২০০ মিনিট। এই সংখ্যা থেকেই প্রতিটি SLO-এর জন্য অনুমোদিত ডাউনটাইম বের হয়।

৯৯% SLO
৪৩,২০০ × ০.০১ = ৪৩২ মিনিট/মাস (~৭.২ ঘণ্টা)

৯৯.৯% SLO ("তিন নাইন")
৪৩,২০০ × ০.০০১ = ৪৩.২ মিনিট/মাস

৯৯.৯৯% SLO ("চার নাইন")
৪৩,২০০ × ০.০০০১ = ৪.৩২ মিনিট/মাস

৯৯.৯৯৯% SLO ("পাঁচ নাইন")
৪৩,২০০ × ০.০০০০১ = ০.৪৩২ মিনিট/মাস (~২৬ সেকেন্ড)

Python

minutes_per_month = 30 * 24 * 60   # ৩০-দিনের মাস = ৪৩,২০০ মিনিট
print(f"মোট মিনিট/মাস: {minutes_per_month:,}")
print()

slo_targets = [
    ("৯৯%",       0.99),
    ("৯৯.৯%",     0.999),
    ("৯৯.৯৯%",    0.9999),
    ("৯৯.৯৯৯%",   0.99999),
]

for label, slo in slo_targets:
    error_budget_pct = (1 - slo) * 100
    allowed_minutes = minutes_per_month * (1 - slo)
    print(f"SLO {label:>10} -> error budget {error_budget_pct:>8.3f}% "
          f"-> অনুমোদিত ডাউনটাইম {allowed_minutes:>8.3f} মিনিট/মাস")

# পাঁচ-নাইনের ক্ষেত্রে মিনিট এত ছোট যে সেকেন্ডে দেখাই স্পষ্ট
five_nines_minutes = minutes_per_month * (1 - 0.99999)
print(f"\nপাঁচ-নাইন downtime সেকেন্ডে: {five_nines_minutes * 60:.2f} সেকেন্ড")

লক্ষ্য করুন — প্রতিটি বাড়তি "নাইন" আগেরটির তুলনায় প্রায় ১০ গুণ কড়া (৪৩.২ → ৪.৩২ → ০.৪৩২)। পাঁচ-নাইন মানে বছরে মাত্র ~৫ মিনিট ডাউনটাইম সহ্য করা — এই স্তরের রিলায়েবিলিটি পেতে বহু-অঞ্চল ফেইলওভার (L37), কনসেনসাস-চালিত লিডার ইলেকশন (L36) ও ব্যাপক অটোমেশন দরকার হয়, যার খরচ প্রতিটি নতুন নাইনে দ্রুত বাড়ে।

৩ · কেন SLA সবসময় SLO-এর চেয়ে শিথিল

SLA ভাঙলে সাধারণত সরাসরি আর্থিক পরিণতি হয় (ক্রেডিট, রিফান্ড, চুক্তি বাতিল)। তাই ইঞ্জিনিয়ারিং টিম নিজের অভ্যন্তরীণ SLO সবসময় SLA-এর চেয়ে কড়া রাখে — যাতে সমস্যা প্রথমে SLO ভাঙে (অভ্যন্তরীণ অ্যালার্ম বাজে), দল সেটা ঠিক করার সময় পায়, এবং কাস্টমার-facing SLA কখনো না ভাঙে। এই মার্জিনই দলের "নিরাপত্তা বাফার"।

৪ · Error-Budget-চালিত ইঞ্জিনিয়ারিং সংস্কৃতি

Google-এর SRE (Site Reliability Engineering) দর্শনের মূল ধারণা — error budget থাকা মানে দলের হাতে "ঝুঁকি নেওয়ার অনুমতি" আছে। যতক্ষণ budget অবশিষ্ট, দল নতুন ফিচার দ্রুত রিলিজ করতে পারে (কিছুটা ঝুঁকি নিয়ে)। budget শেষ হয়ে গেলে, নতুন রিলিজ সাময়িকভাবে থামিয়ে পুরো ফোকাস রিলায়েবিলিটি ঠিক করায় দেওয়া হয় — এটি কোনো শাস্তিমূলক "ফ্রিজ" নয়, বরং একটি সুনির্দিষ্ট, ডেটা-চালিত রিসোর্স-বরাদ্দ সিদ্ধান্ত।

এই কোর্সের প্রায় প্রতিটি রিলায়েবিলিটি প্যাটার্নই আসলে error budget রক্ষা করার হাতিয়ার — রেট লিমিটিং (L35) ও সার্কিট ব্রেকার (L27) ক্যাসকেডিং ফেইলিওর ঠেকায়, ফেইলওভার (L37) ডাউনটাইম কমায়, আইডেম্পোটেন্সি (L38) রিট্রাই-জনিত ভুল ঠেকায়। SLO/error budget হলো সেই মাপকাঠি যা দিয়ে বোঝা যায় এই বিনিয়োগগুলো আসলেই কাজ করছে কি না।

মূল কথা · Key takeaway

SLI মাপে, SLO লক্ষ্য ঠিক করে, SLA প্রতিশ্রুতি দেয়। Error budget (100% − SLO) সেই সংখ্যাকে একটি ব্যবহারযোগ্য রিসোর্সে রূপান্তর করে — একটি দল যতক্ষণ budget-এর মধ্যে থাকে, ঝুঁকি নিতে পারে; budget শেষ হলে, স্থিতিশীলতাই অগ্রাধিকার পায়। সঠিক SLO বাছাই মানে "সর্বোচ্চ সম্ভব রিলায়েবিলিটি" নয় — বরং ব্যবসার আসল প্রয়োজনের সাথে খরচের ভারসাম্য।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ কেন SLA সবসময় SLO-এর চেয়ে "শিথিল" (কম কড়া) রাখা হয়?

কারণ SLA ভঙ্গ হলে সরাসরি আর্থিক/চুক্তিগত পরিণতি হয় — ক্রেডিট, রিফান্ড, এমনকি চুক্তি বাতিল। SLO যদি SLA-এর সমান বা তার চেয়ে শিথিল হতো, তাহলে দল সমস্যাটি টের পাওয়ার আগেই SLA ভেঙে যেতে পারত। SLO-কে SLA-এর চেয়ে কড়া রাখলে সমস্যাটি প্রথমে অভ্যন্তরীণ অ্যালার্ম হিসেবে ধরা পড়ে — দল ঠিক করার সময় পায়, গ্রাহক-facing প্রতিশ্রুতি অক্ষত থাকে।

প্র ০২ এক অতিরিক্ত "নাইন" (৯৯.৯% থেকে ৯৯.৯৯%) যোগ করা কেন এত ব্যয়বহুল হয়ে ওঠে?

প্রতিটি নতুন নাইন error budget-কে প্রায় ১০ গুণ কমিয়ে দেয় (৪৩.২ মিনিট থেকে ৪.৩২ মিনিটে)। এই স্তরের রিলায়েবিলিটি পেতে বহু-অঞ্চল রেপ্লিকেশন ও ফেইলওভার (L37), স্বয়ংক্রিয় লিডার ইলেকশন (L36), ব্যাপক মনিটরিং/অ্যালার্টিং (L41) ও ২৪/৭ অন-কল টিম দরকার হয় — এই বিনিয়োগ রৈখিকভাবে না বেড়ে দ্রুতগতিতে বাড়ে, তাই প্রতিটি নতুন নাইনের প্রান্তিক ব্যয় আগেরটির চেয়ে অনেক বেশি (diminishing returns)।

প্র ০৩ Error budget "শেষ হয়ে গেলে" একটি দল কী করে, এবং এটি কেন একটি শাস্তিমূলক "ফিচার ফ্রিজ" নয়?

Error budget শেষ হলে দল সাময়িকভাবে ঝুঁকিপূর্ণ নতুন রিলিজ থামিয়ে পুরো মনোযোগ রিলায়েবিলিটি সমস্যাগুলো ঠিক করায় দেয় — যতক্ষণ না budget (rolling window-এ) আবার কিছুটা পুনরুদ্ধার হয়। এটি শাস্তি নয়, বরং একটি পূর্বনির্ধারিত, ডেটা-চালিত নীতি — ঠিক যেভাবে রেট লিমিটার (L35, L44) একটি নির্দিষ্ট থ্রেশহোল্ডের পর স্বয়ংক্রিয়ভাবে ট্রাফিক সীমিত করে, error budget নীতিও একইভাবে স্বয়ংক্রিয়ভাবে অগ্রাধিকার বদলায়।

অনুশীলন

হিসাব করুন: একটি সিস্টেমের SLO ৯৯.৯৫%। একটি ৩০-দিনের মাসে (৪৩,২০০ মিনিট) অনুমোদিত ডাউনটাইম মিনিটে হিসাব করুন, এবং সেকেন্ডেও রূপান্তর করুন।

Error budget = 100% − 99.95% = 0.05% = 0.0005। অনুমোদিত ডাউনটাইম = ৪৩,২০০ × ০.০০০৫ = ২১.৬ মিনিট/মাস। সেকেন্ডে = ২১.৬ × ৬০ = ১,২৯৬ সেকেন্ড। এটি ৯৯.৯% (৪৩.২ মিনিট) ও ৯৯.৯৯% (৪.৩২ মিনিট)-এর মাঝামাঝি, যেমনটা প্রত্যাশিত।
চিন্তা করুন: একটি সিস্টেমের SLA প্রতিশ্রুতি ৯৯.৫%, কিন্তু অভ্যন্তরীণ SLO রাখা হয় ৯৯.৯%। যদি একমাসে প্রকৃত পারফরম্যান্স ৯৯.৭% হয়, তাহলে SLA ভঙ্গ হয়েছে কি? SLO?

SLA (৯৯.৫%) ভঙ্গ হয়নি — ৯৯.৭% > ৯৯.৫%, তাই গ্রাহকের কাছে কোনো চুক্তিভঙ্গ নেই। কিন্তু অভ্যন্তরীণ SLO (৯৯.৯%) মিস হয়েছে — ৯৯.৭% < ৯৯.৯%। এটাই ঠিক সেই ০.৪% মার্জিনের কাজ — দল এখন অভ্যন্তরীণভাবে সতর্ক হবে এবং সমস্যাটি ঠিক করবে, যদিও গ্রাহক এখনও কিছু টের পায়নি — SLA ভাঙার আগেই সমস্যা ধরা পড়ল।