SLA, SLI ও SLO: reliability-এর লক্ষ্য
SLA, SLI, SLO, and Error Budgets
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- SLI, SLO ও SLA আলাদা করা
- User-centric success ratio সংজ্ঞায়িত করা
- Error budget দিয়ে release সিদ্ধান্ত নেওয়া
সমস্যা দিয়ে শুরু
Server dashboard সবুজ, কিন্তু payment API-এর timeout-এ customer order শেষ করতে পারছেন না। Team uptime বলছে ১০০ শতাংশ, user বলছেন দোকান বন্ধ। Reliability metric component নয়, user-এর গুরুত্বপূর্ণ কাজকে প্রকাশ করা দরকার। একই সঙ্গে সব ব্যর্থ request সমান নয়: client validation error আর server failure আলাদা করতে denominator ও success criteria আগে লিখতে হবে।
সহজ করে বুঝি
SLI service-এর পরিমাপ, যেমন eligible checkout-এর সফল অনুপাত। SLO সেই measure-এর নির্দিষ্ট window-এ লক্ষ্য। SLA customer-facing commitment এবং remedy-এর চুক্তি; internal SLO-এর সমার্থক নয়। Error budget হলো allowed bad outcome-এর পরিমাণ। Request-based budget total eligible request-এর সঙ্গে বদলায়; time-based downtime budget আলাদা। লক্ষ্য business প্রয়োজন ও observed baseline থেকে স্থির করুন।
পরিচিত একটি উপমা
বাসের timetable হলো promise, actual arrival record হলো measurement, আর মাসে কতবার দেরি সহনীয় সেই লক্ষ্য হলো SLO-এর মতো। Bus engine চলছে কি না শুধু দেখলে যাত্রী সময়মতো পৌঁছালেন কি না বোঝা যায় না।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart LR R[Eligible user journeys] --> M[Measure good and total] M --> I[SLI ratio] I --> O[SLO over window] O --> B[Remaining error budget] B --> D[Release and reliability decisions]
প্রথমে eligible event define করুন। Good ও total event থেকে SLI আসে। Window-এর target-এর সঙ্গে compare করে budget consumption দেখা যায়। দ্রুত budget burn হলে incident response বা release pause হতে পারে। Planned maintenance বাদ দিলে user impact আড়াল হচ্ছে কি না লিখুন। Low traffic-এ অল্প failure-ই বড় percentage করতে পারে।
PHP ও Laravel-এ প্রয়োগ
Laravel console calculation fragment; values illustrative, production metric collection নয়। Good event total-এর subset এবং window একই ধরে নেওয়া হয়েছে। বাস্তব counter-এ bounded labels, duplicate counting prevention এবং monitoring gap policy দরকার। শতাংশ দেখিয়ে missing data healthy ধরবেন না।
$total = 100000;
$good = 99940;
$target = 0.999;
$allowedBad = $total * (1 - $target);
$observedBad = $total - $good;
$remaining = $allowedBad - $observedBad;
$sli = $total > 0 ? $good / $total : null;সুবিধা, সীমাবদ্ধতা ও trade-off
SLO engineering priority-কে user impact-এর সঙ্গে যুক্ত করে। অতি কঠিন target প্রচুর cost বাড়ায়; অতি ঢিলা target degradation স্বাভাবিক করে ফেলে। Aggregate availability minority tenant-এর severe issue লুকাতে পারে। Checkout, search এবং background notification-এর আলাদা objective দরকার হতে পারে। SLA legal document হওয়ায় its terms business owner-এর সঙ্গে review করতে হবে।
সাধারণ ভুল
- SLI-তে শুধু server uptime নেওয়া।
- ৯৯.৯ শতাংশ সব workload-এর স্বাভাবিক সঠিক target ধরে নেওয়া।
- Missing telemetry-কে zero error ধরা।
আরও একটু গভীরে
Latency SLI-তে threshold-এর নিচে completed request good কি না define করুন; average latency slow tail লুকায়। Multi-window burn-rate alert fast এবং sustained problem ধরতে পারে। Budget exhausted হলে blanket feature ban না করে agreed policy অনুযায়ী risk কমান। Rolling window ও calendar window আলাদা behavior দেয়। Dashboard-এ definition, source এবং exclusion প্রকাশ করলে disagreement কমে।
মনে রাখুন
SLI মাপে, SLO লক্ষ্য দেয়, SLA চুক্তি করে; error budget user-visible reliability ও পরিবর্তনের ঝুঁকি মেলায়।
নিজে চেষ্টা করুন
Laravel checkout-এর eligibility এবং success criteria লিখুন। Provider timeout, invalid coupon, user cancel ও telemetry outage কোন category হবে ঠিক করুন। উদাহরণ data দিয়ে request-based budget হিসাব করে release policy প্রস্তাব করুন।
নিজের বোঝা যাচাই করুন
1. SLI ও SLO পার্থক্য?
SLI observed measure; SLO সেই measure-এর target ও time window। Definition ছাড়া percentage অর্থহীন।
2. SLA কি internal target?
SLA customer commitment ও remedy-এর চুক্তি। Internal target প্রায়ই তার আগে margin রেখে design করা হয়।
3. Budget কি সবসময় মিনিট?
না। Request-based budget bad eligible event-এর সংখ্যা; time-based availability ভিন্ন মাপ। Unit একসঙ্গে মেশাবেন না।
4. Average latency যথেষ্ট?
না। Tail-এ user কষ্ট পেতে পারেন। Threshold-based success বা percentileসহ distribution দেখুন।
5. Missing data healthy?
না। Telemetry uncertainty আলাদা signal। Measurement gap policy না থাকলে reliability অতিরঞ্জিত হতে পারে।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।