Alerting আর SLO — burn rate, on-call আর ভালো alert

১ · SLI, SLO আর SLA — মাপ, লক্ষ্য আর চুক্তি

রাত ৩টা। একজন প্রকৌশলীর ফোন বেজে উঠল: CPU 91%. তিনি ল্যাপটপ খুলে দেখলেন, সব ঠিক চলছে। পরের সপ্তাহে কোনো alert নেই, অথচ checkout-এ টানা দুই ঘণ্টা অনেকের টাকা কেটে গেল কিন্তু অর্ডার হলো না। প্রথমটিতে অকারণ ডাক, দ্বিতীয়টিতে আসল বিপদে নীরবতা। এই পর্ব এই দুটি সমস্যারই সমাধান।

সমাধানের শুরু একটি প্রশ্নে: ব্যবহারকারীর কাছে “ঠিক চলছে” মানে কী? সেটি মাপতে তিনটি শব্দ লাগে। শব্দগুলো প্রায় একসাথে বলা হয়, কিন্তু তিনটির কাজ আলাদা।

SLO সাধারণত SLA-র চেয়ে কড়া রাখা হয়। ওপরের উদাহরণে ৯৯.৯% বনাম ৯৯.৫%. মাঝের ফাঁকটি হলো নিরাপত্তার জায়গা: চুক্তি ভাঙার আগেই দল সতর্ক হয়। সব সেবার SLA থাকে না। অভ্যন্তরীণ সেবায় সাধারণত শুধু SLO থাকে। Cloud provider-এর SLA-র শর্ত, বাদ পড়া ঘটনা আর credit-এর হার provider-ভেদে আলাদা, তাই নিজের চুক্তি পড়ে নিতে হয়।

Error budget = ১ − SLO, সেটি আপনি পর্ব ৭-এ দেখেছেন: ৯৯.৯%, ৩০ দিন মানে ৪৩.২ মিনিটের সমতুল্য। সেটি আবার গণনা করব না। SLO-র নকশা আর budget-এর নীতির তত্ত্ব আছে System Design কোর্সের Observability পর্বে। এখানে প্রশ্নটি operational: এই budget-কে পাহারা দেবেন কীভাবে, আর ডাক দেবেন কখন।

২ · ব্যবহারকারীর চোখে SLI বাছাই

ভালো SLI শুরু হয় যন্ত্র থেকে নয়, ব্যবহারকারীর কাজ থেকে। প্রথমে একটি critical user journey বাছুন। একটি কাল্পনিক অনলাইন বাজার অ্যাপে সেগুলো হতে পারে “পণ্য খোঁজা” আর “অর্ডার শেষ করা”। তারপর প্রতিটির জন্য বলুন, “ভালো” ঘটনা কী।

এই রূপের সুবিধা হলো ফল সবসময় ০% থেকে ১০০%-এর মধ্যে, আর ১০০% মানে সবচেয়ে ভালো। ফলে বিভিন্ন সেবা একই ভাষায় তুলনা করা যায়। The Site Reliability Workbook (Google, ২০১৮) সেবার ধরন অনুযায়ী এই রকম একটি তালিকা দেয়:

কোথায় মাপবেন

একই SLI ভিন্ন জায়গায় মাপলে ভিন্ন সত্য দেখায়। Workbook একে বলে SLI-এর specification আর implementation-এর পার্থক্য: “কী মাপতে চাই” আর “কীভাবে মাপছি”।

শুরুর জন্য load balancer ভালো জায়গা। পরে দরকার হলে client-এর মাপ যোগ করুন। একটি প্রশ্ন আগে ঠিক করতে হয়: “বৈধ” কোনগুলো? ভুল পাসওয়ার্ডের 401 সাধারণত গোনা হয় না, আর bot-এর traffic বাদ দেওয়াই ভালো। কিন্তু হঠাৎ 4xx-এর ঢল একটি ভুল client release-ও হতে পারে, তাই সেটি আলাদা করে দেখা দরকার।

SLO লেখার আগে একটি কাজ করুন: গত কয়েক সপ্তাহের log থেকে SLI হিসাব করে দেখুন। ৯৯.৯৯% লক্ষ্য লিখলেন, অথচ এখনই ৯৯.৮% চলছে, তাহলে প্রথম দিনেই budget শেষ। লক্ষ্য শুরু করুন বাস্তব থেকে, পরে ব্যবহারকারীর প্রয়োজন দেখে বাড়ান বা কমান।

৩ · একটি আসল alert-এর জীবন — Prometheus থেকে Alertmanager

তত্ত্বের আগে একটি আসল alert বাজিয়ে দেখি। Prometheus metric টেনে আনে আর নিয়ম যাচাই করে। সে নিজে কাউকে ডাকে না। ডাকার কাজ Alertmanager-এর।

পরীক্ষাটি নিচের মতো সাজানো: একটি ছোট Python app তিনটি route গোনে (/checkout, /search, /cart), একটি load container অনুরোধ পাঠায়, আর একটি নকল pager প্রতিটি webhook ছাপে। আউটপুট Docker Engine 29-এ, Prometheus v3.5.0 আর Alertmanager v0.28.1 দিয়ে একটি আসল run থেকে নেওয়া। সময়, id আর হার প্রতি run-এ আলাদা হবে। প্রকৃত নিয়মের ১ ঘণ্টা আর ৫ মিনিট অপেক্ষা না করে, এই পরীক্ষায় জানালা ছোট করা হয়েছে: ২ মিনিট আর ৩০ সেকেন্ড।

groups:
  - name: slo-recording
    rules:
      - record: route:error_ratio:rate30s
        expr: |
          sum by (service, route) (rate(http_requests_total{code="500"}[30s]))
          / sum by (service, route) (rate(http_requests_total[30s]))
      # rate2m is the same with [2m]
  - name: slo-alerts
    rules:
      - alert: FastBurn
        expr: |
          route:error_ratio:rate2m > (14.4 * 0.001)
          and route:error_ratio:rate30s > (14.4 * 0.001)
        for: 30s
        labels:
          severity: page
        annotations:
          summary: "{{ $labels.route }} is burning the error budget fast"
          runbook_url: "https://runbooks.example.com/shop/fast-burn"
      # SlowBurn: same shape, limit 1 * 0.001, severity: ticket

এখানে দুই রকম নিয়ম। Recording rule একটি হিসাব আগে করে নতুন নামে রাখে। Alert rule একটি শর্ত। for: 30s মানে শর্ত টানা ৩০ সেকেন্ড সত্য না থাকলে alert পাঠানো হবে না। ভাষাটি PromQL, যা পর্ব ৬৩-এ দেখেছেন। runbook_url-এর ঠিকানাটি কাল্পনিক।

route:
  receiver: pager
  group_by: [service, severity]
  group_wait: 10s
  group_interval: 30s
  repeat_interval: 1h
  routes:
    - matchers: ['severity="ticket"']
      receiver: ticket-queue
receivers:
  - name: pager
    webhook_configs:
      - url: http://abcl-al-pager:9000/page
        send_resolved: true
  - name: ticket-queue
    webhook_configs:
      - url: http://abcl-al-pager:9000/ticket
        send_resolved: false
inhibit_rules:
  - source_matchers: ['severity="page"']
    target_matchers: ['severity="ticket"']
    equal: [service, route]

প্রথমে দুটি ফাইলই যন্ত্রে যাচাই করা হলো (/c হলো container-এর ভেতরে ফাইলের জায়গা):

$ promtool check rules /c/rules.yml
Checking /c/rules.yml
  SUCCESS: 4 rules found

$ amtool check-config /c/alertmanager.yml
Checking '/c/alertmanager.yml'  SUCCESS
Found:
 - global config
 - route
 - 1 inhibit rules
 - 2 receivers
 - 0 templates

এবার t+৩১ সেকেন্ডে /checkout আর /search-এ ৫% error ঢোকানো হলো। একটি ছোট script প্রতি সেকেন্ডে Prometheus-এর /api/v1/alerts পড়ে, আর অবস্থা বদলালে একটি লাইন লেখে:

t+   0s (no alerts)
t+  31s <-- 5% errors injected on /checkout and /search
t+  43s SlowBurn /checkout pending; SlowBurn /search pending
t+  59s FastBurn /checkout pending; FastBurn /search pending; …
t+  75s … SlowBurn /checkout firing; SlowBurn /search firing
t+  91s FastBurn /checkout firing; FastBurn /search firing; …

নকল pager-এ যা পৌঁছাল (সময় একই ঘড়িতে আনা হয়েছে, লাইন ছোট করা):

t+  85s receiver=ticket-queue status=firing alerts=2
   SlowBurn /checkout firing runbook=…/shop/slow-burn
   SlowBurn /search firing runbook=…/shop/slow-burn
t+ 103s receiver=pager status=firing alerts=2
   FastBurn /checkout firing runbook=…/shop/fast-burn
   FastBurn /search firing runbook=…/shop/fast-burn

এবার silence. ধরুন /cart-এ একটি পরিকল্পিত কাজ চলবে। t+১৪১-এ silence বসিয়ে সেখানেও ৫% error ঢোকানো হলো। পুরো run-এ pager-এ /cart-এর একটি বার্তাও আসেনি (amtool-এর --alertmanager.url বাদ দিয়ে দেখানো):

$ amtool silence add route=/cart --duration=30m --author=rafi \
    --comment="planned cart migration"
bf1c8a30-e43b-474e-a4e9-256c0f9848aa

$ amtool alert query             # active: reaches a human
Alertname  Starts At                Summary                  State
FastBurn   2026-10-30 21:24:26 UTC  /search is burning …     active
FastBurn   2026-10-30 21:24:26 UTC  /checkout is burning …   active

$ amtool alert query --silenced  # a human chose this
Alertname  Starts At                Summary                  State
FastBurn   2026-10-30 21:26:36 UTC  /cart is burning …       suppressed

$ amtool alert query --inhibited # another alert covers this
Alertname  Starts At                Summary                  State
SlowBurn   2026-10-30 21:24:11 UTC  /checkout is burning …   suppressed
SlowBurn   2026-10-30 21:24:11 UTC  /search is burning …     suppressed

৪ · লক্ষণে alert, কারণে নয় — ভালো alert-এর চারটি মাপ

“CPU ৯০%”, “pod restart”, “disk ৮০%” হলো সম্ভাব্য কারণ। “Checkout-এ ৫% অনুরোধ ব্যর্থ” হলো লক্ষণ। ডাক্তার জ্বর দেখে রোগী ভর্তি করেন, প্রতিটি জীবাণু গুনে নয়। লক্ষণভিত্তিক alert-ও তাই: ব্যবহারকারী কষ্ট পেলে তবেই ডাক। Google-এর Rob Ewaschuk-এর লেখা “My Philosophy on Alerting” আর SRE বইয়ের monitoring অধ্যায় এই ধারণাকে জনপ্রিয় করে।

ব্যতিক্রমও আছে। “এই গতিতে disk ৪ ঘণ্টায় ভরবে” বা “certificate ৭ দিনে শেষ” এখনো ব্যবহারকারীকে কষ্ট দিচ্ছে না, কিন্তু এগুলো নিশ্চিত ভবিষ্যৎ লক্ষণ। এগুলো রাখুন, তবে সাধারণত ticket হিসেবে, আর সময় কম থাকলে page হিসেবে। ৩য় অংশে দেখা up বন্ধ হওয়াও তেমনই: মাপ বন্ধ হলে লক্ষণ দেখারই উপায় থাকে না।

চারটি মাপকাঠি

Alert ভালো কি মন্দ, তা তর্কে নয়, মাপে ঠিক হয়। Workbook-এর “Alerting on SLOs” অধ্যায় চারটি মাপ দেয়:

এই চারটি একে অপরকে টানে। ছোট জানালা দ্রুত ধরে, কিন্তু ক্ষণিকের ঝাঁকুনিতেও বাজে, ফলে precision কমে। লম্বা জানালায় precision বাড়ে, কিন্তু detection আর reset দুটোই ধীর হয়। পরের দুই অংশের লক্ষ্য হলো চারটিকেই একসাথে ভালো রাখা।

৫ · Burn rate — budget কত দ্রুত পুড়ছে

“Error ১%” শুনে বিপদ বোঝা যায় না। ৯৯% SLO-তে এটি ঠিক লক্ষ্যে, ৯৯.৯৯%-এ ভয়ানক। আসল প্রশ্ন: এই গতিতে চললে budget কবে ফুরোবে? এই গতির নামই burn rate.

দুটি সূত্রই সরল ভাগ-গুণ। burn rate ১ মানে ঠিক SLO-র গতিতে খরচ। ৩০ দিনের সময়কাল মানে ৭২০ ঘণ্টা। হিসাব পুরো budget-কে ১ ধরে, তাই ফল ভগ্নাংশ বা শতাংশ।

সমাধান করা হিসাব ১. SLO ৯৯.৯%, error rate ০.৫%, টানা ৬ ঘণ্টা। burn rate = ০.০০৫ ÷ ০.০০১ = ৫. খরচ = ৫ × ৬ ÷ ৭২০ = ০.০৪১৬৭, মানে budget-এর ৪.১৭%. এই গতিতে budget ফুরোবে ৭২০ ÷ ৫ = ১৪৪ ঘণ্টায়, অর্থাৎ ৬ দিনে।

সমাধান করা হিসাব ২. SLO ৯৯.৯৫%, পূর্ণ বিভ্রাট (error rate ১০০%), ৩ মিনিট। burn rate = ১ ÷ ০.০০০৫ = ২,০০০. খরচ = ২,০০০ × ৩ ÷ ৪৩,২০০ = ০.১৩৮৯, মানে ১৩.৮৯%. মাত্র ৩ মিনিটে মাসের প্রায় সাত ভাগের এক ভাগ।

Workbook-এর সুপারিশকৃত তিনটি সীমা এই সূত্র থেকেই আসে। উল্টো করে লিখলে: burn rate = খরচ × সময়কাল ÷ জানালা। নিচের প্রোগ্রাম সেই টেবিল নিজে হিসাব করে যাচাই করে। সংখ্যা বদলে আপনার SLO-র জন্য চালিয়ে দেখতে পারেন।

// Recompute the SRE Workbook's multi-window table. SLO period: 30 days = 720 h.
const PERIOD_H = 30 * 24, SLO = 0.999, B = 1 - SLO;
const burnOf = (err, slo = SLO) => err / (1 - slo);       // error rate / (1 - SLO)
const used = (burn, hours) => burn * hours / PERIOD_H;    // burn x window / period
const pct = (x, d = 2) => (100 * x).toFixed(d) + "%";
const table = [["1 h", 1, "5 min", 14.4, "page"], ["6 h", 6, "30 min", 6, "page"],
               ["3 d", 72, "6 h", 1, "ticket"]];
console.log("long   short   burn  budget used  error > (99.9%)  empty in  action");
for (const [name, hours, short, burn, act] of table) {
  const days = PERIOD_H / burn / 24;
  console.log(name.padEnd(7) + short.padEnd(8) + String(burn).padStart(4) +
    pct(used(burn, hours), 1).padStart(13) + pct(burn * B).padStart(17) +
    (days.toFixed(2) + " d").padStart(10) + "  " + act);
}
console.log("\nbackwards: burn = budget used x period / window");
for (const [share, hours] of [[0.02, 1], [0.05, 6], [0.10, 72]])
  console.log(`  ${pct(share, 0)} in ${hours} h -> burn ${(share * PERIOD_H / hours).toFixed(1)}`);
// Detection time of the 1 h rule, starting from a clean window.
console.log("\nerror rate  burn   minutes until the 1 h rule at 14.4 fires");
for (const err of [0.01, 0.015, 0.02, 0.05, 0.10, 1]) {
  const burn = burnOf(err);
  const t = burn >= 14.4 ? (60 * 14.4 / burn).toFixed(1) : "never";
  console.log(pct(err).padStart(10) + burn.toFixed(0).padStart(6) + t.padStart(8));
}
console.log("\n1% errors under two SLOs");
for (const slo of [0.999, 0.9995]) {
  const burn = burnOf(0.01, slo), fires = burn >= 14.4;
  console.log(`  SLO ${(slo * 100).toFixed(2)}%: burn ${burn.toFixed(0)}, 14.4 rule ` +
    (fires ? `fires after ${(60 * 14.4 / burn).toFixed(1)} min` : "never fires") +
    `, budget empty in ${(PERIOD_H / burn).toFixed(0)} h`);
}

long   short   burn  budget used  error > (99.9%)  empty in  action
1 h    5 min   14.4         2.0%            1.44%    2.08 d  page
6 h    30 min     6         5.0%            0.60%    5.00 d  page
3 d    6 h        1        10.0%            0.10%   30.00 d  ticket

backwards: burn = budget used x period / window
  2% in 1 h -> burn 14.4
  5% in 6 h -> burn 6.0
  10% in 72 h -> burn 1.0

error rate  burn   minutes until the 1 h rule at 14.4 fires
     1.00%    10   never
     1.50%    15    57.6
     2.00%    20    43.2
     5.00%    50    17.3
    10.00%   100     8.6
   100.00%  1000     0.9

1% errors under two SLOs
  SLO 99.90%: burn 10, 14.4 rule never fires, budget empty in 72 h
  SLO 99.95%: burn 20, 14.4 rule fires after 43.2 min, budget empty in 36 h

৬ · Multi-window, multi-burn-rate alert

একটি মাত্র burn rate দিয়ে সব ধরা যায় না। উঁচু সীমা বড় বিভ্রাট দ্রুত ধরে, কিন্তু ধীর ফুটো দেখে না। নিচু সীমা ফুটো ধরে, কিন্তু ছোট ঝাঁকুনিতেও বাজে। তাই Workbook-এর শেষ সুপারিশ কয়েকটি সীমা, আর প্রতিটিতে দুটি জানালা। একে বলে multi-window, multi-burn-rate alert.

লম্বা জানালা বলে “ক্ষতিটি অর্থবহ”। ছোট জানালা বলে “সমস্যা এখনো চলছে”। দুটোই সীমা পেরোলে তবেই alert বাজে। Workbook-এর নিয়ম-অনুমান: ছোট জানালা লম্বাটির ১/১২. এতে precision আসে লম্বা জানালা থেকে, আর reset time আসে ছোট জানালা থেকে। ছবিতে সেটি দেখুন।

ছবির ঘটনাটি মিনিট ধরে দেখুন। ধরে নিন স্বাভাবিক সময়ে error প্রায় শূন্য। হিসাবগুলো script-এ করা।

এবার উল্টো ঘটনা: খুব ছোট একটি ফুটো, যা কোনো page ছোঁয় না, অথচ ফেলে রাখলে পুরো budget খায়।

Production-এ নিয়মগুলো Prometheus-এ দেখতে কেমন, নিচে আছে। এই ফাইলটি promtool check rules-এ পাস করেছে (SUCCESS: 3 rules found). লক্ষ্য করুন, এখানে for নেই: জানালাই সেই অপেক্ষার কাজ করে। ৩য় অংশে for ছিল শুধু তার আচরণ দেখাতে।

groups:
  - name: shop-slo-recording
    rules:
      - record: route:error_ratio:rate5m
        expr: |
          sum by (service, route) (rate(http_requests_total{code=~"5.."}[5m]))
          / sum by (service, route) (rate(http_requests_total[5m]))
      # একইভাবে rate30m, rate1h, rate6h, rate3d
  - name: shop-slo-alerts
    rules:
      - alert: ErrorBudgetFastBurn
        expr: |
          (route:error_ratio:rate1h > (14.4 * 0.001)
           and route:error_ratio:rate5m > (14.4 * 0.001))
          or
          (route:error_ratio:rate6h > (6 * 0.001)
           and route:error_ratio:rate30m > (6 * 0.001))
        labels:
          severity: page
        annotations:
          summary: "{{ $labels.route }}: error budget দ্রুত পুড়ছে"
          runbook_url: "https://runbooks.example.com/shop/fast-burn"
      - alert: ErrorBudgetSlowBurn
        expr: |
          route:error_ratio:rate3d > (1 * 0.001)
          and route:error_ratio:rate6h > (1 * 0.001)
        labels:
          severity: ticket
        annotations:
          summary: "{{ $labels.route }}: error budget ধীরে পুড়ছে"
          runbook_url: "https://runbooks.example.com/shop/slow-burn"

এবার নিজে পরীক্ষা করুন। নিচের evaluator ২১ দিনের প্রতি মিনিটের একটি seeded error stream বানায়, তাতে ক্ষণিকের ঝাঁকুনি আর তিনটি ঘটনা থাকে, তারপর চারটি নিয়ম চালায়। EVENTS বা seed বদলে দেখুন কোন নিয়ম কখন বাজে।

// Burn-rate alert evaluator on a seeded per-minute error stream. Edit EVENTS.
let seed = 66; function rand() {                     // mulberry32
  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) / 2 ** 32;
}
const DAY = 1440, DAYS = 21, ALLOWED = 0.001, REQ = 6000;   // SLO 99.9%, 100 req/s
const EVENTS = [{ name: "outage", start: 6 * DAY + 600, min: 45, err: 0.05 },
                { name: "bad deploy", start: 10 * DAY + 180, min: 480, err: 0.012 },
                { name: "slow leak", start: 15 * DAY, min: 2880, err: 0.002 }];
const pre = [0];                                     // prefix sum of failed requests
for (let m = 0; m < DAYS * DAY; m++) {
  let r = 0.0001;                                    // healthy background
  if (rand() < 0.002) r = 0.04;                      // one-minute blip, heals itself
  for (const e of EVENTS) if (m >= e.start && m < e.start + e.min) r = Math.max(r, e.err);
  pre.push(pre[m] + REQ * r * (0.7 + 0.6 * rand())); // noisy count around the rate
}
const burn = (m, w) => { const from = Math.max(0, m + 1 - w);
  return (pre[m + 1] - pre[from]) / ((m + 1 - from) * REQ) / ALLOWED; };
const rules = [["1h only    > 14.4", 60, 60, 14.4], ["1h and 5m  > 14.4", 60, 5, 14.4],
               ["6h and 30m > 6", 360, 30, 6], ["3d and 6h  > 1", 3 * DAY, 360, 1]];
const at = m => "d" + Math.floor(m / DAY) + " " + String(Math.floor(m % DAY / 60)).padStart(2, "0") +
  ":" + String(m % 60).padStart(2, "0");
for (const [name, long, short, limit] of rules) {
  let on = -1; const out = [];
  for (let m = 0; m < DAYS * DAY; m++) {
    const firing = m + 1 >= short && burn(m, long) > limit && burn(m, short) > limit;
    if (firing && on < 0) on = m;
    if (!firing && on >= 0) { out.push(at(on) + " to " + at(m)); on = -1; }
  }
  if (on >= 0) out.push(at(on) + " to end");
  console.log(name.padEnd(19) + out.length + " alert(s): " + (out.join(", ") || "none"));
}
for (const e of EVENTS) console.log(e.name.padEnd(11) + at(e.start) + " to " + at(e.start + e.min));
console.log("budget used: " + (100 * pre[DAYS * DAY] / (30 * DAY * REQ * ALLOWED)).toFixed(0) +
  "% of a 30-day budget");

1h only    > 14.4  1 alert(s): d6 10:16 to d6 11:28
1h and 5m  > 14.4  1 alert(s): d6 10:16 to d6 10:48
6h and 30m > 6     2 alert(s): d6 10:42 to d6 11:11, d10 05:50 to d10 11:14
3d and 6h  > 1     2 alert(s): d10 07:43 to d10 16:31, d16 07:24 to d17 03:12
outage     d6 10:00 to d6 10:45
bad deploy d10 03:00 to d10 11:00
slow leak  d15 00:00 to d17 00:00
budget used: 43% of a 30-day budget

৭ · Page না ticket — আর incident-এর পরে budget কত

প্রতিটি সংকেত মানুষকে ডেকে তোলার যোগ্য নয়। সিদ্ধান্তটি তিন ঘরের:

একটি alert page হওয়ার জন্য চারটি প্রশ্নের উত্তর “হ্যাঁ” হতে হবে: এটি কি জরুরি? এখনই কি কাজ করা সম্ভব? কাজটি কি মানুষের বিচার চায়? ব্যবহারকারীর কি সত্যিই ক্ষতি হচ্ছে? কাজটি প্রতিবার একই যান্ত্রিক ধাপ হলে সেটি alert নয়, automation-এর কাজ।

Incident মিটে গেলে পরের প্রশ্ন: budget কত বাকি? পর্ব ৭-এর নীতি এখানে কাজে লাগে। নিচের হিসাব একই সূত্র দিয়ে প্রতিটি incident-এর খরচ বের করে, আর চলমান ৩০ দিনের জানালায় বাকি budget দেখায়। সীমাগুলো একটি কাল্পনিক দলের নীতি। INCIDENTS বদলে দেখুন।

// Budget left after incidents. Edit INCIDENTS. Budget used = burn x time / period.
const SLO = 0.999, PERIOD = 30 * 1440, ALLOWED = 1 - SLO;
const INCIDENTS = [                     // day it started, minutes, error rate
  { day: 3,  min: 20,  err: 0.10 },     // bad config
  { day: 11, min: 90,  err: 0.08 },     // slow database after a deploy
  { day: 19, min: 15,  err: 1.00 },     // full outage
  { day: 26, min: 240, err: 0.01 },     // retry storm from a partner
  { day: 29, min: 120, err: 0.03 },     // cache node lost
  { day: 34, min: 30,  err: 0.60 },     // expired certificate
  { day: 45, min: 10,  err: 0.01 },     // small blip; old incidents start to leave
  { day: 52, min: 10,  err: 0.01 },
];
const usedBy = i => (i.err / ALLOWED) * i.min / PERIOD;
console.log("day  min  err%  burn  used%  left%  outage min left  state");
for (const now of INCIDENTS) {
  const inWindow = INCIDENTS.filter(i => i.day <= now.day && i.day > now.day - 30);
  const left = 1 - inWindow.reduce((s, i) => s + usedBy(i), 0);
  const state = left <= 0 ? "EMPTY: stop risky changes"
    : left < 0.25 ? "RED: reliability work first"
    : left < 0.5 ? "AMBER: canary only" : "GREEN";
  console.log(String(now.day).padStart(3) + String(now.min).padStart(5) +
    (now.err * 100).toFixed(1).padStart(6) + (now.err / ALLOWED).toFixed(0).padStart(6) +
    (usedBy(now) * 100).toFixed(1).padStart(7) + (left * 100).toFixed(1).padStart(7) +
    Math.max(0, left * ALLOWED * PERIOD).toFixed(1).padStart(17) + "  " + state);
}

day  min  err%  burn  used%  left%  outage min left  state
  3   20  10.0   100    4.6   95.4             41.2  GREEN
 11   90   8.0    80   16.7   78.7             34.0  GREEN
 19   15 100.0  1000   34.7   44.0             19.0  AMBER: canary only
 26  240   1.0    10    5.6   38.4             16.6  AMBER: canary only
 29  120   3.0    30    8.3   30.1             13.0  AMBER: canary only
 34   30  60.0   600   41.7   -6.9              0.0  EMPTY: stop risky changes
 45   10   1.0    10    0.2    9.5              4.1  RED: reliability work first
 52   10   1.0    10    0.2   44.0             19.0  AMBER: canary only

৮ · Alert fatigue, মালিকানা আর runbook

Alert fatigue মানে অতিরিক্ত alert-এ মানুষের সাড়া ভোঁতা হয়ে যাওয়া। পাড়ার যে গাড়ির alarm রোজ বাজে, তাতে কেউ আর জানালায় তাকান না। Alert-কে তাই একটি পণ্যের মতো চালান, যার মান মাপা হয়, যার মালিক আছেন।

• মাসিক হিসাব: প্রতিটি alert কতবার বেজেছে, কতবার কাজ লেগেছে, কতবার রাতে।
• মুছে ফেলার অভ্যাস: যে alert-এ কেউ কিছু করেন না, সেটি মুছুন। Postmortem-এ নতুন alert যোগ করা সহজ, পুরোনো সরানোই আসল শৃঙ্খলা।
• এক কারণে এক বার্তা: grouping আর inhibition ব্যবহার করুন।
• মালিকানা: প্রতিটি alert-এর team label থাকবে। যে দল সেবা বানায়, noise তার কাছেই যাক; তখনই সেটি ঠিক হয়।
• Code হিসেবে রাখা: Rule ফাইল Git-এ, review সহ, যেমন পর্ব ৫১-এর Infrastructure as Code.

প্রতিটি alert-এ runbook-এর লিংক

Runbook হলো রাত ৩টায় আধা-ঘুমে পড়ার মতো ছোট নির্দেশিকা। ৩য় অংশের প্রতিটি alert-এ runbook_url ছিল, আর বার্তার সাথেই লিংকটি পৌঁছেছিল। ভালো runbook ছয়টি প্রশ্নের উত্তর দেয়:

1. এই alert-এর মানে কী, ব্যবহারকারীর ওপর প্রভাব কী?
2. কোন dashboard আগে দেখবেন?
3. সবচেয়ে সাধারণ কারণগুলো কী, আর সম্প্রতি কি deploy হয়েছে?
4. নিরাপদ প্রথম পদক্ষেপ কী: rollback, traffic সরানো, নাকি feature flag বন্ধ?
5. কখন, কাকে ডাকবেন?
6. শেষ কবে এই পাতা যাচাই করা হয়েছে, আর মালিক কে?

এবার একটি কাল্পনিক দলের এক মাসের page মাপি। স্কোরটি এই কোর্সের শেখার সূচক, শিল্পের কোনো মান নয়: precision-এ ৫০%, recall-এ ৩০%, runbook আর মালিকানায় ১০% করে ওজন। রাতের page-এর হিসাব seeded সময় থেকে আসে, আর সব সংখ্যা কাল্পনিক।

// Alert quality from a month of pages (a classroom score, not an industry standard).
let seed = 2026; function rand() {               // mulberry32
  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) / 2 ** 32;
}
// pages = sent, real = needed a human, rb / own = has a runbook / an owning team
const BEFORE = [["HighCPU", 64, 2, 0, 0], ["PodRestart", 41, 1, 0, 0],
                ["DiskOver80", 18, 3, 1, 0], ["CheckoutError", 7, 5, 1, 1]];
const AFTER = [["FastBurn", 5, 5, 1, 1], ["SlowBurn6h", 3, 2, 1, 1],
               ["DiskFullIn4h", 2, 2, 1, 1]];
function report(label, alerts, incidents, caught) {
  let pages = 0, real = 0, night = 0, rb = 0, own = 0;
  console.log(label);
  for (const [name, sent, good, hasRb, hasOwn] of alerts) {
    for (let i = 0; i < sent; i++) if (Math.floor(rand() * 24) < 7) night++;  // 00:00-06:59
    pages += sent; real += good; rb += hasRb * sent; own += hasOwn * sent;
    const p = good / sent;
    console.log("  " + name.padEnd(14) + String(sent).padStart(3) + " pages, precision " +
      (p * 100).toFixed(0).padStart(3) + "%  " + (p < 0.5 ? "FIX OR DELETE" : "keep"));
  }
  const precision = real / pages, recall = caught / incidents;
  const score = 100 * (0.5 * precision + 0.3 * recall + 0.1 * rb / pages + 0.1 * own / pages);
  console.log(`  ${pages} pages = ${(pages / 4).toFixed(1)} a week, ${night} at night`);
  console.log(`  precision ${(precision * 100).toFixed(1)}%, recall ${caught}/${incidents} = ` +
    `${(recall * 100).toFixed(0)}%, runbook ${(100 * rb / pages).toFixed(0)}%, ` +
    `owner ${(100 * own / pages).toFixed(0)}%`);
  console.log(`  score ${score.toFixed(0)} / 100`);
}
report("before (month 1)", BEFORE, 9, 6);   // 9 real incidents, 6 reached a human by page
report("after (month 3)", AFTER, 9, 8);

before (month 1)
  HighCPU        64 pages, precision   3%  FIX OR DELETE
  PodRestart     41 pages, precision   2%  FIX OR DELETE
  DiskOver80     18 pages, precision  17%  FIX OR DELETE
  CheckoutError   7 pages, precision  71%  keep
  130 pages = 32.5 a week, 40 at night
  precision 8.5%, recall 6/9 = 67%, runbook 19%, owner 5%
  score 27 / 100
after (month 3)
  FastBurn        5 pages, precision 100%  keep
  SlowBurn6h      3 pages, precision  67%  keep
  DiskFullIn4h    2 pages, precision 100%  keep
  10 pages = 2.5 a week, 6 at night
  precision 90.0%, recall 8/9 = 89%, runbook 100%, owner 100%
  score 92 / 100

৯ · On-call-এর নকশা — ন্যায্য সূচি আর paging tool

On-call মানে একজন নির্দিষ্ট সময়ে ডাক পেলে সাড়া দেওয়ার দায়িত্বে থাকেন। Rotation বা rota হলো সেই পালার সূচি। এর নকশায় তিনটি হিসাব লাগে: কতজন, কতবার, আর কত ভার।

কতজন. Google-এর Site Reliability Engineering (২০১৬) বইয়ে on-call-এ সময়ের সর্বোচ্চ ২৫% রাখার নিয়ম আছে। সব সময় primary আর secondary, দুজন থাকলে n জনের দলে একজন ২/n ভাগ সময় on-call:

কত ভার. একই বই বলে, একটি ঘটনার পুরো কাজে (ধরা, সমাধান, postmortem) গড়ে প্রায় ৬ ঘণ্টা লাগে, তাই একটি ১২ ঘণ্টার পালায় দুটি ঘটনাই বাস্তব সীমা। এগুলো Google-এর অভিজ্ঞতার সংখ্যা। আপনার দল নিজের সীমা নিজে মাপুন, তবে সীমা একটি রাখুন।

ন্যায্যতা. শুধু সপ্তাহ গুনলে হয় না। ঈদের ছুটি, রাতের page আর শুক্রবার সমান ভারী নয়।

• ছুটির দিনের পালা গুনে পালা করে দিন, আর মাসে কে কতটি রাতের page পেলেন, সেটি মাপুন।
• পালা বদলের সময় রাখুন কর্মদিনের মাঝামাঝি, আর হাতবদলে খোলা সমস্যা জানিয়ে দিন।
• রাত জাগলে পরদিন বিশ্রাম, আর on-call-এর ক্ষতিপূরণ (টাকা বা ছুটি) আগে থেকে লেখা থাকুক।
• নতুন সদস্য প্রথমে অভিজ্ঞ কারও ছায়া হয়ে থাকুন। মিথ্যা বীরত্ব নয়, ডাকতে পারাই নিয়ম।
• দুটি সময়-অঞ্চলে দল থাকলে follow-the-sun সূচি রাতের পালা প্রায় মুছে দেয়। একই বইয়ে দুই সাইটের দলের জন্য প্রতি সাইটে ন্যূনতম ৬ জনের কথা আছে।

৮ জনের কম দল হলে কী করবেন? সাড়া দেওয়ার প্রতিশ্রুতি ঢিলে করুন, page শুধু দিনের নির্দিষ্ট সময়ে রাখুন, অথবা কয়েকটি দল মিলে একটি rota বানান। ছোট দলের জন্য কঠিন সত্য হলো, ৯৯.৯৯% SLO-র দাম মানুষের ঘুম দিয়েও দিতে হয়। SLO ঠিক করার সময় এই দামও হিসাবে আনুন।

Paging tool যা করে

Alertmanager জানে কোন alert কোথায় পাঠাতে হবে, কিন্তু ফোন করে না। সেই কাজ করে paging tool: যেমন PagerDuty, Grafana-র on-call পণ্য, বা cloud-এর নিজের পথ (AWS CloudWatch alarm → SNS, Azure Monitor → action group, Google Cloud Monitoring → notification channel). পণ্য আর দাম বদলায়, তাই নাম নয়, ধারণা মনে রাখুন:

• Schedule: এই মুহূর্তে কে on-call, তার সূচি ও সাময়িক বদল।
• Acknowledge: মানুষ সাড়া দিলে ডাক বন্ধ হয়। সাড়া দিতে গড়ে যে সময় লাগে, তা MTTA.
• Escalation policy: ৫ মিনিটে সাড়া না পেলে secondary, তারপর দলনেতা।
• একাধিক পথ: App, SMS, ফোন কল। একটি পথ কাজ না করলেও ডাক পৌঁছানো চাই।

Monitoring নিজেও থামতে পারে। তাই একটি সবসময় firing থাকা “Watchdog” alert বাইরের একটি সেবায় পাঠানো হয়। সেটি থেমে গেলে বাইরের সেবা আপনাকে ডাকে। একে বলে dead man's switch.

১০ · AI-এর যুগে — alert আর SLO-র নকশা যাচাই

AI কয়েক সেকেন্ডে PromQL আর rule ফাইল লিখে দেয়। সমস্যা হলো, সে আপনার traffic, SLO বা রাতের page-এর সংখ্যা জানে না। Syntax ঠিক থাকলেও alert ভুল হতে পারে, আর সেই ভুল ধরা পড়ে রাত ৩টায় বা বিভ্রাটের নীরবতায়।

AI-এর alert ব্যবহারের আগে

• promtool check rules আর amtool check-config পাস করেছে
• Throwaway পরিবেশে ভুল ঢুকিয়ে দেখেছি alert সত্যিই বাজে আর থামে
• Threshold হাতে হিসাব করে মিলিয়েছি: burn × (১ − SLO)
• গত মাসের data-য় backtest করে দেখেছি কতবার বাজত
• প্রতিটি alert-এর মালিক, severity আর কাজ করা runbook লিংক আছে
• Scrape থেমে গেলে (up == 0) আলাদা alert আছে
• Prompt-এ কোনো secret, webhook URL বা গ্রাহকের data দিইনি
• Metric বা log জমার খরচের একটি আন্দাজ করেছি, আর Git diff পড়ে তবেই বদল চালু করেছি