ایرر بجٹ اور برن ریٹ الرٹس: درست وجوہات پر جگانا

صارف کے تجربے سے آغاز کریں

زیادہ تر شور والے الرٹس وجوہات — CPU، میموری، دوبارہ شروع ہونے والا پوڈ — پر الرٹ دینے سے آتے ہیں، نہ کہ اس پر جو صارفین محسوس کرتے ہیں۔ سروس لیول انڈیکیٹر (SLI) اسے براہِ راست ناپتا ہے: درست درخواستوں میں سے کتنی اچھی رہیں۔ اچھی کا مطلب سرور ایرر کے بغیر جواب، کسی حد سے تیز جواب، یا دونوں ہو سکتا ہے۔

سروس لیول آبجیکٹو (SLO) ایک مدت میں اس تناسب کا ہدف طے کرتا ہے، مثلاً 30 دنوں میں 99.9% درخواستیں کامیاب۔ 100% تک کا فرق ایرر بجٹ ہے: یہاں 0.1% درخواستیں، یعنی مہینے میں تقریباً 43 منٹ کی مکمل بندش۔

مقررہ حد والے الرٹس کیوں ناکام ہوتے ہیں

“5 منٹ تک ایرر کی شرح 1% سے زیادہ” جیسا الرٹ بیک وقت بہت حساس اور بہت سست ہوتا ہے۔ یہ ایک مختصر اچھال پر جگا دیتا ہے جس نے بجٹ کا معمولی حصہ خرچ کیا، اور 0.5% ایرر کی اس شرح پر کبھی نہیں بجتا جو خاموشی سے ایک ہفتے میں پورا بجٹ ختم کر دیتی ہے۔

برن ریٹ اس کا حل ہے۔ یہ SLO کے مقابلے میں بجٹ خرچ ہونے کی رفتار ہے: برن ریٹ 1 پوری مدت میں ٹھیک ٹھیک بجٹ خرچ کرتا ہے؛ برن ریٹ 14.4 تیس دن کا بجٹ دو دن سے کچھ زیادہ میں ختم کر دیتا ہے۔

ملٹی ونڈو، ملٹی برن ریٹ الرٹس

Google کی SRE Workbook میں بیان کردہ طریقہ ہر برن ریٹ حد کو ایک لمبی ونڈو کے ساتھ جوڑتا ہے، جو ثابت کرتی ہے کہ مسئلہ سنجیدہ ہے، اور ایک چھوٹی ونڈو کے ساتھ، جو ثابت کرتی ہے کہ یہ اب بھی جاری ہے۔ 30 دنوں میں 99.9% SLO کے لیے ایک عام نقطۂ آغاز یہ ہے:

• جگائیں: 1 گھنٹے اور 5 منٹ دونوں میں برن ریٹ 14.4 سے زیادہ — ایک گھنٹے میں بجٹ کا 2% خرچ۔
• جگائیں: 6 گھنٹے اور 30 منٹ دونوں میں برن ریٹ 6 سے زیادہ — بجٹ کا 5% خرچ۔
• ٹکٹ: 3 دن اور 6 گھنٹے دونوں میں برن ریٹ 1 سے زیادہ — بجٹ کا 10% خرچ۔

# Fast-burn page for a 99.9% availability SLO (error budget = 0.001)
(
  sum(rate(http_requests_total{job="api", code=~"5.."}[1h]))
    / sum(rate(http_requests_total{job="api"}[1h]))
) > (14.4 * 0.001)
and
(
  sum(rate(http_requests_total{job="api", code=~"5.."}[5m]))
    / sum(rate(http_requests_total{job="api"}[5m]))
) > (14.4 * 0.001)

چھوٹی ونڈو اتنی ہی اہم ہے جتنی لمبی: جیسے ہی درستی نافذ ہوتی ہے، 5 منٹ کا تناسب گرتا ہے اور الرٹ باقی گھنٹہ بجتے رہنے کے بجائے ختم ہو جاتا ہے۔

وہ تفصیلات جو کامیابی طے کرتی ہیں

• ریکارڈنگ رولز: ہر ونڈو کا ایرر تناسب پہلے سے حساب کر لیں، تاکہ الرٹ کے اظہار ہلکے اور پڑھنے کے قابل رہیں۔
• کم ٹریفک: فی منٹ چند درخواستوں پر ایک ناکامی بڑا تناسب بن جاتی ہے۔ درخواستوں کی کم از کم تعداد لازمی کریں، یا مصنوعی پروبز سے ناپیں۔
• تاخیر کے SLO: حد سے سست درخواستوں کو خراب واقعات گنیں، ایسے ہسٹوگرام بکٹس کے ساتھ جن میں حد کی قدر شامل ہو۔
• استثنا: پہلے سے طے کریں کہ کلائنٹ ایررز اور ہیلتھ چیکس گنے جائیں گے یا نہیں، اور اسے SLO کے ساتھ لکھیں۔

بجٹ کس لیے ہے

بجٹ فیصلہ سازی کا آلہ ہے، صرف پیجر نہیں۔ جب تک یہ صحت مند ہے، ٹیم تیزی سے ریلیز کر سکتی ہے اور زیادہ خطرے والی تبدیلیاں لے سکتی ہے۔ جب یہ ختم ہو جائے تو رجحان بحال ہونے تک اعتمادیت کا کام فیچرز سے آگے رہتا ہے۔ اس پالیسی پر پروڈکٹ مالکان سے پہلی خلاف ورزی سے پہلے اتفاق کریں، اس کے دوران نہیں۔