SLI, SLO, SLA ও Error Budget
- ●SLI হলো যা মাপো (measured), SLO হলো target, আর SLA হলো গ্রাহকের সাথে আইনি চুক্তি।
- ●Error Budget হলো ১০০% থেকে SLO বাদ দিয়ে যা থাকে — কতটুকু fail করার অনুমতি আছে।
- ●৯৯.৯% মানে মাসে প্রায় ৪৩ মিনিট downtime — এই budget দিয়েই release vs stability-র সিদ্ধান্ত নেওয়া হয়।
সমস্যাটা কী?
"আমাদের সিস্টেম খুব reliable" — এই বাক্যটা শুনতে ভালো, কিন্তু এর কোনো মানে নেই। কতটা reliable? কে ঠিক করে? কখন বুঝবে যে যথেষ্ট হয়েছে?
দুই দল প্রায়ই ঝগড়া করে: developer-রা চায় দ্রুত নতুন feature ছাড়তে, আর operations টিম চায় কিছুই না ভাঙুক (অর্থাৎ কম release)। এই দ্বন্দ্বের একটা data-driven সমাধান দরকার। SLI, SLO, SLA আর Error Budget — এই চারটা ধারণা reliability-কে সংখ্যায় রূপ দেয়, যাতে আবেগ নয়, data দিয়ে সিদ্ধান্ত নেওয়া যায়।
মূল ধারণা
SLI হলো একটা সংখ্যা যা মাপে service কেমন চলছে (যেমন: সফল request-এর শতকরা হার)। SLO হলো সেই SLI-র জন্য target (যেমন: ৯৯.৯%)। SLA হলো গ্রাহকের সাথে চুক্তি, যেখানে SLO ভাঙলে penalty থাকে।
সহজ মনে রাখার উপায়:
- SLI = Indicator → যা মাপো (reality)
- SLO = Objective → যা চাও (goal)
- SLA = Agreement → যা প্রতিশ্রুতি দাও (contract)
একটা গুরুত্বপূর্ণ নিয়ম: SLO সবসময় SLA-র চেয়ে কড়া হয়। যদি গ্রাহককে ৯৯.৫% (SLA) দাও, internally তুমি ৯৯.৯% (SLO) target রাখবে — যাতে কখনো SLA-র কাছাকাছি যাওয়ার আগেই alert পাও।
কীভাবে কাজ করে
SLI বেছে নেওয়া
ভালো SLI গ্রাহকের অভিজ্ঞতা প্রতিফলিত করে। সাধারণ SLI-গুলো:
| SLI ধরন | কী মাপে | উদাহরণ |
|---|---|---|
| Availability | কত % request সফল হলো | 99.95% |
| Latency | কত দ্রুত response এলো | 95% request ২০০ms-এর কম |
| Error Rate | কত % request fail | ০.০৫% |
| Throughput | কত request handle করল | 5000 req/sec |
| Durability | data হারানোর হার | 99.999999999% (11 nines) |
SLI সাধারণত ভগ্নাংশ আকারে: (ভালো ঘটনা) / (মোট ঘটনা) × 100।
SLO ঠিক করা
SLO হলো SLI-র উপর target। সব জায়গায় ১০০% target রাখা বোকামি — কারণ শেষ ০.১% reliability পেতে খরচ বিশাল বেড়ে যায়। তাই বাস্তবসম্মত target রাখো। "Nine"-গুলো বুঝে নাও:
| SLO | মাসিক allowed downtime | বছরে |
|---|---|---|
| 99% (two nines) | ~৭.৩ ঘণ্টা | ~৩.৬৫ দিন |
| 99.9% (three nines) | ~৪৩ মিনিট | ~৮.৮ ঘণ্টা |
| 99.99% (four nines) | ~৪.৩ মিনিট | ~৫২.৬ মিনিট |
| 99.999% (five nines) | ~২৬ সেকেন্ড | ~৫.৩ মিনিট |
Error Budget — সবচেয়ে শক্তিশালী ধারণা
Error Budget = ১০০% − SLO। SLO ৯৯.৯% মানে তোমার কাছে ০.১% "fail করার অনুমতি" আছে — এটাই budget। মাসে প্রায় ৪৩ মিনিট downtime তুমি "খরচ" করতে পারো।
এটা একটা allowance-এর মতো। budget বাকি থাকলে দ্রুত release করো, ঝুঁকি নাও। budget শেষ হলে freeze করে stability-তে মন দাও।
Error budget হলো মাসিক mobile data package-এর মতো। তোমার ১ GB (budget) আছে। মাসের শুরুতে data বাকি, তাই নিশ্চিন্তে YouTube দেখো (দ্রুত feature ছাড়ো)। কিন্তু মাসের শেষে যদি ৫০ MB বাকি থাকে, তখন সাবধানে চলো — শুধু জরুরি কাজ (bug fix) করো, নতুন risky কিছু নয়। data শেষ হলে speed কমে যায় (SLA ভাঙার ঝুঁকি)। তুমি data বাঁচিয়ে রাখো না বলে — বরং বুদ্ধিমানের মতো খরচ করো।
কৌশল — Error Budget দিয়ে সিদ্ধান্ত
Google-এর SRE বইয়ের মূল ধারণা: error budget দুই দলের ঝগড়া মেটায়।
- Budget বাকি আছে → দ্রুত deploy করো, নতুন feature ছাড়ো, A/B test চালাও। ঝুঁকি নেওয়ার সুযোগ আছে।
- Budget প্রায় শেষ → feature freeze, শুধু reliability fix, postmortem থেকে শেখা action item শেষ করা।
- Budget শেষ → সব নতুন release বন্ধ, all-hands stability সপ্তাহ।
এতে "কখন release করব, কখন থামব" — এই সিদ্ধান্ত আর মতের লড়াই থাকে না, সংখ্যা ঠিক করে দেয়।
কখন ব্যবহার করবে / করবে না
- প্রতিটা গুরুত্বপূর্ণ user-facing service-এর SLO থাকা উচিত। শুরুতে ২-৩টা SLI বেছে নাও (availability + latency), পরে বাড়াও।
- internal batch job বা experimental service-এ কড়া SLO দরকার নেই।
- SLA শুধু তখন করো যখন তুমি confident — কারণ এটা legal binding, ভাঙলে টাকা গুনতে হবে।
১০০% SLO target করার ভুল কখনো করো না। শেষ ০.০১% reliability পেতে খরচ exponentially বাড়ে, আর তুমি কোনো risk-ই নিতে পারবে না — কোনো নতুন release, কোনো maintenance নয়। তাছাড়া তোমার দুর্বলতা প্রায়ই তোমার নিয়ন্ত্রণের বাইরে (ISP, cloud provider, third-party API)। তাই SLO রাখো এমন জায়গায় যা গ্রাহক আসলে টের পায়।
বাস্তব উদাহরণ
একটা food-delivery app (Foodpanda-সদৃশ) ভাবো। তারা ঠিক করল:
- SLI: সফল order placement-এর হার।
- SLO: ৯৯.৯% (মাসিক budget ≈ ৪৩ মিনিট)।
- SLA: corporate client-দের জন্য ৯৯.৫%, ভাঙলে ১০% bill ছাড়।
এক মাসে একটা database migration-এ ২০ মিনিট outage হলো — budget-এর প্রায় অর্ধেক খরচ। ঐ মাসে আবার একটা buggy release ১৫ মিনিট সমস্যা করল। এখন budget প্রায় শেষ (৮ মিনিট বাকি)। SRE টিম তাই বাকি মাসে নতুন feature freeze করে দিল, শুধু bug fix চলল। ফলে SLA (৯৯.৫%) কখনো লঙ্ঘন হলো না, client penalty দিতে হলো না।
Interview-এ এক বাক্যে গুছিয়ে বলো — SLI মাপি, SLO চাই, SLA প্রতিশ্রুতি দিই; আর SLO সবসময় SLA-এর চেয়ে কড়া। তারপর error budget-এর কথা তুলে বলো এটা feature velocity আর reliability-র মধ্যে objective ভারসাম্য দেয়। ৯৯.৯% = ৪৩ মিনিট/মাস এই সংখ্যাটা মুখস্থ রাখো — interviewer প্রায়ই এটা জিজ্ঞেস করে।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. গ্রাহকের সাথে চুক্তি যেখানে লঙ্ঘন হলে টাকা ফেরত/penalty দিতে হয় — সেটা কী?
2. SLO ৯৯.৯% হলে এক মাসে (৩০ দিন) error budget প্রায় কত?
3. Error budget প্রায় শেষ হয়ে গেলে SRE টিম সাধারণত কী করে?