6.1 سروس لیول انڈیکیٹرز، مقاصد، اور ایرر بجٹ

جائزہ اور محرک

سائٹ ریلائیبلیٹی انجینئرنگ (SRE)، وہ نظم جس کی ابتدا Google نے کی اور جو Site Reliability Engineering کتاب میں دستاویز ہوا، نے ایسا ذخیرۂ الفاظ دیا جس پر یہ موضوع براہِ راست بنتا ہے: سروس لیول انڈیکیٹر (SLI) سروس کی صحت کا براہِ راست ناپا گیا اشارہ ہے، درخواست کی تاخیر، غلطی کی شرح، دستیابی۔ سروس لیول آبجیکٹو (SLO) اس اشارے کی ہدف حد ہے، مثلاً 99.9 فیصد درخواستیں 200 ملی سیکنڈ کے اندر کامیاب ہوں۔ اور ایرر بجٹ اجازت شدہ کمی ہے، وہ 0.1 فیصد درخواستیں جنہیں ناکام ہونے کی اجازت ہے، جسے ختم کیے جانے والے نقص کے بجائے خرچ کیے جانے والا وسیلہ سمجھا جاتا ہے جو دانستہ خطرہ مول لینے کے لیے استعمال ہو سکتا ہے: خطرناک تبدیلی بھیجنا، تجربہ چلانا، یا محض یہ قبول کرنا کہ کامل قابلِ اعتماد ہونا نہ قابلِ حصول ہے اور نہ، ایک حد کے بعد، اپنی لاگت کے قابل۔

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

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

بنیادی اصول

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

سفارشات

ایسے SLI چنیں جو صارف کے حقیقی تجربے کی عکاسی کریں

ایسے اشارے چنیں جو اصل صارف کے تجربے کے جتنا ممکن ہو قریب ناپے جائیں: درخواست کی کامیابی کی شرح اور تاخیر جو edge یا لوڈ بیلنسر پر ناپی جائے، صرف اندرونی سروس کے ہیلتھ چیک نہیں جو “صحت مند” رپورٹ کر سکتے ہیں جبکہ صارفین حقیقی مسائل کا تجربہ کر رہے ہوں۔ جو SLI ایسی چیز ناپتا ہے جو صارف کو کبھی محسوس ہی نہیں ہوتی، اندرونی جزو تکنیکی طور پر چل رہا ہو جبکہ مجموعی درخواست پھر بھی ناکام ہو، وہ غلط چیز ناپ رہا ہے چاہے اسے انسٹرومنٹ کرنا کتنا ہی آسان ہو۔

SLO کا ہدف اس پر طے کریں جو صارفین کو واقعی چاہیے، من مانے گول عدد پر نہیں

“99.99 فیصد اپ ٹائم” جیسا ہدف محض اس لیے طے کرنے کی جبلت کا مقابلہ کریں کہ وہ متاثر کن حد تک سخت لگتا ہے۔ اس کے بجائے تحقیق کریں کہ صارفین حقیقتاً کس سطح کا قابلِ اعتماد ہونا محسوس کرتے اور اس کی پروا کرتے ہیں، تاریخی واقعات کے ڈیٹا، صارف کی تحقیق، اور قابلِ اعتماد ہونے کے ہر اضافی درجے کے حصول کی ثابت شدہ لاگت سے باخبر ہو کر، کیونکہ 99.9 فیصد سے 99.99 فیصد تک جانے میں اکثر 99 فیصد سے 99.9 فیصد تک جانے سے کہیں زیادہ انجینئرنگ کی کوشش لگتی ہے، گھٹتے اور آخرکار نہ ہونے کے برابر صارف کو محسوس ہونے والے فائدے کے لیے۔

ایرر بجٹ کو خرچ کیے جانے والا وسیلہ سمجھیں جس کے ختم ہونے پر پہلے سے طے شدہ ردِعمل ہو

ایرر بجٹ کا حساب براہِ راست SLO سے لگائیں (30 دن میں 99.9 فیصد دستیابی کا ہدف تقریباً 43 منٹ کے مجاز ڈاؤن ٹائم کی اجازت دیتا ہے) اور اس کے مقابل خرچ مسلسل ٹریک کریں۔ پہلے سے، کسی مخصوص واقعے سے پہلے، طے کریں کہ بجٹ ختم ہونے پر کیا ہوگا: عام، مؤثر پالیسی یہ ہے کہ فیچر کا کام رک جائے اور ٹیم کی ترجیح بجٹ کی بحالی تک خودکار طور پر قابلِ اعتماد ہونے کے کام پر منتقل ہو جائے۔ یہ پہلے سے طے اصول ہر انفرادی واقعے کے دوران دباؤ میں اس سمجھوتے پر دوبارہ مقدمہ لڑنے کی ضرورت ختم کرتا ہے۔

ایرر بجٹ کو دانستہ، باخبر خطرے کے فیصلوں کے لیے استعمال کریں

صحت مند، خرچ نہ ہوا ایرر بجٹ ذخیرہ کرنے کی چیز نہیں؛ یہ معقول خطرات مول لینے کی اجازت ہے، بڑھے ہوئے مگر قابلِ قبول خطرے کے ساتھ تبدیلی بھیجنا، chaos انجینئرنگ کا تجربہ چلانا (ہم رتبہ software-engineering-guide کتاب کا chaos انجینئرنگ کا موضوع اسے براہِ راست احاطہ کرتا ہے)، یا زیادہ خطرناک فن تعمیر کی تبدیلی قبول کرنا، کیونکہ بجٹ خاص طور پر محفوظ بے ہاتھ لگا رکھنے کے بجائے دانستہ خرچ کرنے کے لیے موجود ہے۔ ایرر بجٹ جو کبھی خرچ نہ ہو اس کا مطلب یا تو حد سے زیادہ محتاط ٹیم ہے یا ایسا SLO جو حاصل شدہ اصل قابلِ اعتماد ہونے کے مقابل بہت ڈھیلا طے ہوا، دونوں تحقیق کے قابل ہیں۔

SLO کا وقتاً فوقتاً جائزہ اور نظرِ ثانی کریں، جمود پر نہیں ثبوت پر

برسوں پہلے طے شدہ SLO اب موجودہ صارف کی توقعات، نظام کے فن تعمیر، یا کاروباری ترجیحات کی عکاسی نہ کرتا ہو۔ SLO کا باقاعدہ وقفے پر جائزہ لیں، تاریخی حاصل شدہ قابلِ اعتماد ہونا، صارف کی رائے، اور یہ جانچتے ہوئے کہ آیا ہدف اب بھی بامعنی سمجھوتے کا نقطہ ہے یا تو آسانی سے پورا ہونے والا ہدف جسے کہیں اور زیادہ رفتار ممکن بنانے کو سخت کیا جا سکے، یا غیر حقیقت پسندانہ جسے ٹیم نے عملاً پورا کرنا چھوڑ دیا ہے۔

سمجھوتے: فوائد اور نقصانات

طریقہ	فوائد	نقصانات
کوئی رسمی SLO نہیں (ضمنی “جتنا ممکن ہو قابلِ اعتماد”)	قائم کرنے کا کوئی بوجھ نہیں	رفتار اور استحکام کے درمیان نہ ختم ہونے والی، بے بنیاد گفت و شنید؛ کوئی مشترکہ اصول نہیں
آرزو پر مبنی، بہت اونچا SLO (99.99 فیصد+)	قابلِ اعتماد ہونے کے بارے میں سنجیدگی کا اشارہ	اکثر غیر ضروری لاگت؛ جو صارفین واقعی محسوس کرتے ہیں اس سے آگے گھٹتا منافع
ثبوت پر مبنی، صارف کے تجربے پر مبنی SLO	حقیقی قدر کی عکاسی؛ قابلِ دفاع اور قابلِ حصول	درست طے کرنے کو حقیقی ڈیٹا اور تجزیہ درکار
پہلے سے طے شدہ ختم ہونے کے ردِعمل کے ساتھ ایرر بجٹ	ایڈہاک گفت و شنید ختم؛ معروضی، تیز فیصلہ سازی	پہلے سے طے اصول کی پاسداری کے لیے ادارہ جاتی حمایت اور نظم درکار

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

اپنی ٹیم کے ساتھ زیرِ بحث لانے کے سوالات

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

2. کیا ہمارے پاس ایرر بجٹ ختم ہونے کا پہلے سے طے شدہ، متفقہ ردِعمل ہے، یا ہر بار ہونے پر سمجھوتے پر دوبارہ مقدمہ لڑا جاتا ہے؟ اگر ایماندار جواب بعد والا ہے تو اگلا واقعہ دباؤ میں بحث پر مجبور کرنے سے پہلے اس خلا کو بند کرنا قابلِ قدر ہے۔

3. کیا ہمارا ایرر بجٹ کبھی دانستہ خرچ ہوتا ہے، سوچے سمجھے خطرے کی تبدیلی یا تجربے پر، یا وہ صرف واقعات کے ذریعے اتفاقاً ہی استعمال ہوتا ہے؟ جو بجٹ کبھی دانستہ خرچ نہ ہو وہ حد سے زیادہ محتاط ٹیم کی نشاندہی کر سکتا ہے جو ان جائز مواقع کو کھو رہی ہے جنہیں ممکن بنانے کو بجٹ موجود ہے۔

4. کیا ہمارے SLI صارف کے حقیقی تجربے سے ناپے جاتے ہیں، یا اندرونی نظام کی صحت سے جو شاید صارفین کے سامنے آنے والی چیز کی عکاسی نہ کرے؟ اپنی موجودہ انسٹرومنٹیشن کو اس مخصوص فرق کے مقابل جانچیں؛ یہ دوسری صورت میں پختہ قابلِ اعتماد ہونے کے پروگراموں میں بھی عام خلا ہے۔

5. ہم نے آخری بار اپنے SLO کا موجودہ ثبوت کے مقابل جائزہ کب لیا، اور کیا کچھ بدلا ہے، صارف کی توقعات، نظام کا فن تعمیر، کاروباری ترجیحات، جو نظرِ ثانی کا جواز دے؟ اگر آپ کو حالیہ جائزہ یاد نہیں تو یہ غیر موجودگی خود بحث کے قابل ہے۔

6. ہمارے موجودہ SLO کو قابلِ اعتماد ہونے کے ایک اور “نائن” اوپر لے جانے میں ہمیں انجینئرنگ کی کوشش میں کیا لاگت آئے گی، اور کیا وہ لاگت کسی حقیقی صارف کے فائدے سے جائز ہوگی؟ یہ ٹھوس لاگت اور فائدے کی فریمنگ آرزو بمقابلہ قابلِ حصول ہونے کی کشمکش کو تجریدی ترجیح کے بجائے حقیقی اعداد میں بنیاد دینے میں مدد دیتی ہے۔

شعبے کا زاویہ

اسٹارٹ اپ۔ رسمی SLO اکثر بہت ابتدا میں غیر ضروری ہوتے ہیں، جب ٹیم قابلِ اعتماد ہونے کے مسائل کا براہِ راست اور غیر رسمی طور پر جواب دے سکتی ہے۔ کم از کم تقریباً غیر رسمی SLO اپنائیں جب آپ کے پاس اپ ٹائم پر منحصر حقیقی ادائیگی کرنے والے صارفین ہوں، کیونکہ صریح ہدف کا نظم، چاہے ڈھیلے ٹریک کیا جائے، فیچر کے دباؤ کے مقابل قابلِ اعتماد ہونے کے کام کو اکثر نوجوان کمپنیوں کے سوچنے سے جلد ترجیح دینے میں مدد دیتا ہے۔

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

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

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

مثالیں

بڑا ادارہ۔ ایک کلاؤڈ اسٹوریج کمپنی برسوں سے رسمی SLO کے بغیر “زیادہ سے زیادہ اپ ٹائم” کا ہدف رکھتی تھی، جس سے پروڈکٹ ٹیم (فیچرز تیزی سے بھیجنا چاہتی) اور بنیادی ڈھانچے کی ٹیم (زیادہ سے زیادہ احتیاط چاہتی) کے درمیان دائمی، غیر حل شدہ کشمکش تھی، جس پر ہر ریلیز پلاننگ میٹنگ میں نئے سرے سے مقدمہ لڑا جاتا۔ ایرر بجٹ اور پہلے سے طے شدہ پالیسی کے ساتھ 99.95 فیصد دستیابی کے رسمی SLO کو اپنانے، بجٹ ختم ہونے پر فیچر کا کام خودکار طور پر رک جاتا ہے، نے بار بار کی گفت و شنید کو مکمل طور پر حل کر دیا: دونوں ٹیمیں ایک ہی عدد دیکھ سکتی تھیں اور ایک ہی اصول پر متفق ہو سکتی تھیں، اور کمپنی نے صحت مند بجٹ کے ادوار میں بھیجی گئی فیچرز میں ناپنے کے قابل اضافہ رپورٹ کیا، ساتھ ہی اگلے سال کے دو ادوار میں جب بجٹ واقعی ختم ہوا ناپنے کے قابل، دانستہ سست روی، بالکل جیسا پالیسی کا مقصد تھا۔

حکومت۔ ایک قومی موسمیاتی سروس کا عوامی انتباہ کا نظام برسوں سے “ہمیشہ دستیاب” کی غیر رسمی توقع کے تحت چل رہا تھا، بغیر دستاویزی ہدف کے اور غیر بیان شدہ، عملاً ناممکن معیار پورا کرنے کی کوشش کرتی آن کال ٹیم پر نمایاں، غیر حل شدہ آپریشنل دباؤ کے ساتھ۔ نیا اپنایا گیا رسمی SLO، 99.9 فیصد دستیابی بمعہ واضح طور پر بتائی گئی عوامی ایرر بجٹ کی وضاحت، نے آپریشنز ٹیم کو بجٹ کے اندر منصوبہ بند دیکھ بھال کی کھڑکیاں طے کرنے کی صریح، قابلِ دفاع اجازت دی، جو پچھلی غیر بیان شدہ “ہمیشہ دستیاب” کی توقع نے سیاسی طور پر مشکل بنا رکھا تھا چاہے طویل مدتی نظام کی صحت کے لیے حقیقتاً ضروری ہو۔ ایرر بجٹ کے تصور کی عوامی طور پر براہِ راست وضاحت، اسے چھپانے کے بجائے، کو ایماندار، پختہ آپریشنل طریقے کی علامت کے طور پر خوش آمدید کہا گیا، خدمت کے معیار سے وابستگی کی کمزوری کے طور پر نہیں۔

کاروباری جواز: محرکات، ROI، اور TCO

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

ملکیت کی کل لاگت میں ثبوت پر مبنی ہدف درست طے کرنے کی تجزیاتی کوشش اور پہلے سے طے شدہ ختم ہونے کے ردِعمل کی پاسداری کا نظم شامل ہے، حتیٰ کہ کسی خاص پسندیدہ فیچر کو پھر بھی بھیجنے کے دباؤ میں بھی۔ وہ نظم کی لاگت حقیقی ہے، لیکن وہ غیر حل شدہ، دائمی گفت و شنید کی جاری لاگت سے کہیں کم ہے جو ہر پلاننگ سائیکل میں غیر معینہ مدت تک ادارہ جاتی توانائی کھاتی رہتی ہے۔

منفی نمونے اور خطرات

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

پختگی کا نمونہ

• درجہ 1، آغاز (Initiate): قابلِ اعتماد ہونے کے اہداف ضمنی یا آرزو پر مبنی ہیں، کوئی رسمی SLO، SLI، یا ایرر بجٹ متعین نہیں۔
• درجہ 2، ترقی (Develop): کچھ سروسز کا غیر رسمی SLO ہے، لیکن SLI صارف کے حقیقی تجربے کی عکاسی نہ کرتے ہوں اور پہلے سے طے شدہ ختم ہونے کی پالیسی نہیں۔
• درجہ 3، معیار بندی (Standardize): حقیقی صارف کے تجربے کے SLI کے ساتھ ثبوت پر مبنی SLO اور پہلے سے طے شدہ ایرر بجٹ ختم ہونے کی پالیسی اہم سروسز میں یکساں قائم ہیں۔
• درجہ 4، انتظام (Manage): ایرر بجٹ فعال اور دانستہ طور پر سوچے سمجھے خطرے مول لینے پر خرچ ہوتے ہیں، اور SLO کا باقاعدہ، ثبوت پر مبنی وقفے پر جائزہ اور نظرِ ثانی ہوتی ہے۔
• درجہ 5، ہم آہنگی (Orchestrate): SLO اور ایرر بجٹ ادارے بھر میں رفتار اور استحکام کے توازن کے مشترکہ، معروضی طریقۂ کار کے طور پر مربوط ہیں، اور ادارہ ان مخصوص فیصلوں کی نشاندہی کر سکتا ہے جو فریم ورک نے ممکن بنائے جنہیں بے بنیاد گفت و شنید اتنی مؤثر طور پر حل نہ کرتی۔

بحث کے لیے خیالات

1. کیا ہمارا موجودہ SLO ثبوت پر مبنی ہے یا آرزو پر؟
2. کیا ہمارے پاس ایرر بجٹ ختم ہونے کا پہلے سے طے شدہ ردِعمل ہے جس کی ہم دباؤ میں واقعی پاسداری کریں گے؟
3. ہم نے آخری بار صحت مند ایرر بجٹ کو سوچے سمجھے خطرے پر دانستہ کب خرچ کیا؟
4. کیا ہمارے SLI صارف کے حقیقی تجربے کو ناپتے ہیں یا آسان اندرونی ہیلتھ چیک کو؟
5. اپنا SLO ایک اور “نائن” بڑھانے میں ہمیں کیا لاگت آئے گی، اور کیا وہ لاگت جائز ہوگی؟

اہم نکات

• سروس لیول انڈیکیٹر (SLI) صارف کا حقیقی تجربہ ناپتا ہے؛ سروس لیول آبجیکٹو (SLO) اس کا ثبوت پر مبنی ہدف ہے؛ ایرر بجٹ دانستہ خرچ کی جانے والی اجازت شدہ کمی ہے۔
• 100 فیصد قابلِ اعتماد ہونا عموماً غلط ہدف ہے؛ اپنے SLO کو اس پر بنیاد دیں جو صارفین واقعی محسوس کرتے ہیں اور ہر اضافی درجے کی حقیقتاً کیا لاگت ہے۔
• ایرر بجٹ کو پہلے سے طے شدہ ختم ہونے کے ردِعمل کے ساتھ خرچ کیا جانے والا وسیلہ سمجھیں، ہر بار دباؤ میں رفتار بمقابلہ استحکام پر دوبارہ مقدمہ لڑنے کی ضرورت ختم کرتے ہوئے۔
• SLI کو صارف کے حقیقی تجربے سے ناپیں، صرف آسان اندرونی ہیلتھ چیک سے نہیں۔
• SLO کا وقتاً فوقتاً جائزہ اور نظرِ ثانی کریں، ثبوت کی بنیاد پر، کیونکہ باسی ہدف اپنی افادیت کھو دیتا ہے جب نظام اور اس کے صارفین بدلتے ہیں۔

حوالہ جات اور مزید مطالعہ

• Site Reliability Engineering: How Google Runs Production Systems, by Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds. (SLI، SLO، اور ایرر بجٹ کی تعریف کرنے والا بنیادی متن)۔
• The Site Reliability Workbook, by Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne, eds. (SLO اور ایرر بجٹ نافذ کرنے کی عملی رہنمائی)۔
• Implementing Service Level Objectives, by Alex Hidalgo (SLO کے ڈیزائن اور عملی نفاذ کے لیے جامع، عملی ماہرین پر مرکوز رہنما)۔
• Accelerate: The Science of Lean Software and DevOps, by Nicole Forsgren, Jez Humble, and Gene Kim (قابلِ اعتماد ہونے کے طریقے اور ڈیلیوری کی کارکردگی کا تعلق)۔