SRE (Site Reliability Engineering) ویب پروجیکٹس کی دستیابی کو یقینی بنانے کا ایک طریقہ ہے۔ اسے DevOps کے لیے ایک فریم ورک سمجھا جاتا ہے اور اس بارے میں بات کرتا ہے کہ DevOps طریقوں کو لاگو کرنے میں کامیابی کیسے حاصل کی جائے۔ اس مضمون میں ترجمہ باب 4 خدمت کی سطح کے مقاصد کتابیں سائٹ کی وشوسنییتا انجینئرنگ گوگل سے میں نے یہ ترجمہ خود تیار کیا اور نگرانی کے عمل کو سمجھنے میں اپنے تجربے پر انحصار کیا۔ ٹیلیگرام چینل میں نگرانی_یہ и Habré پر آخری پوسٹ میں نے خدمت کی سطح کے اہداف کے بارے میں اسی کتاب کے باب 6 کا ترجمہ بھی شائع کیا۔

بلی کا ترجمہ۔ پڑھنے سے لطف اندوز!

کسی سروس کا نظم کرنا ناممکن ہے اگر اس بات کی سمجھ نہ ہو کہ اصل میں کون سے اشارے اہم ہیں اور ان کی پیمائش اور تشخیص کیسے کی جائے۔ اس مقصد کے لیے، ہم اپنے صارفین کو سروس کی ایک مخصوص سطح کی وضاحت اور فراہم کرتے ہیں، قطع نظر اس کے کہ وہ ہمارے اندرونی APIs میں سے ایک استعمال کرتے ہیں یا عوامی مصنوعات۔

ہم سروس لیول انڈیکیٹرز (SLIs)، سروس لیول کے مقاصد (SLOs)، اور سروس لیول ایگریمنٹس (SLAs) کو سمجھنے کے لیے صارفین کی خواہش کے بارے میں اپنی بصیرت، تجربہ، اور سمجھ کو استعمال کرتے ہیں۔ یہ جہتیں ان اہم میٹرکس کی وضاحت کرتی ہیں جن کی ہم نگرانی کرنا چاہتے ہیں اور اگر ہم متوقع معیار کی خدمت فراہم نہیں کر سکتے ہیں تو ہم اس پر ردعمل ظاہر کریں گے۔ بالآخر، صحیح میٹرکس کا انتخاب اگر کچھ غلط ہو جاتا ہے تو صحیح اقدامات کی رہنمائی میں مدد کرتا ہے، اور SRE ٹیم کو سروس کی صحت پر اعتماد بھی فراہم کرتا ہے۔

یہ باب اس نقطہ نظر کی وضاحت کرتا ہے جسے ہم میٹرک ماڈلنگ، میٹرک سلیکشن، اور میٹرک تجزیہ کے مسائل سے نمٹنے کے لیے استعمال کرتے ہیں۔ زیادہ تر وضاحتیں مثالوں کے بغیر ہوں گی، اس لیے ہم بنیادی نکات کو واضح کرنے کے لیے شیکسپیئر سروس کو استعمال کریں گے جو اس کے نفاذ کی مثال میں بیان کی گئی ہے (شیکسپیئر کے کاموں کی تلاش)۔

سروس لیول کی اصطلاحات

بہت سے قارئین ممکنہ طور پر SLA کے تصور سے واقف ہوں گے، لیکن SLI اور SLO کی اصطلاحات محتاط تعریف کی مستحق ہیں کیونکہ عام طور پر SLA کی اصطلاح بہت زیادہ ہوتی ہے اور اس کے سیاق و سباق کے لحاظ سے متعدد معنی ہوتے ہیں۔ وضاحت کے لیے، ہم ان اقدار کو الگ کرنا چاہتے ہیں۔

بروکر

SLI ایک سروس لیول انڈیکیٹر ہے — فراہم کردہ سروس کی سطح کے ایک پہلو کا احتیاط سے بیان کردہ مقداری پیمانہ۔

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

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

SLI کی ایک اور قسم جو SREs کے لیے اہم ہے وہ ہے دستیابی، یا وقت کا وہ حصہ جس کے دوران سروس استعمال کی جا سکتی ہے۔ اکثر کامیاب درخواستوں کی شرح کے طور پر بیان کیا جاتا ہے، جسے کبھی کبھی پیداوار کہا جاتا ہے۔ (زندگی بھر—یہ امکان کہ ڈیٹا کو طویل مدت تک برقرار رکھا جائے گا—ڈیٹا اسٹوریج سسٹمز کے لیے بھی اہم ہے۔) اگرچہ 100% دستیابی ممکن نہیں ہے، لیکن 100% کے قریب دستیابی اکثر قابل حصول ہوتی ہے؛ دستیابی کی قدروں کا اظہار اس طرح کیا جاتا ہے "نو" کی تعداد » دستیابی کا فیصد۔ مثال کے طور پر، 99% اور 99,999% دستیابی کو "2 نائنز" اور "5 نائنز" کا لیبل لگایا جا سکتا ہے۔ Google Compute Engine کا موجودہ بیان کردہ دستیابی کا ہدف "ساڑھے تین نو" یا 99,95% ہے۔

اہداف

ایس ایل او سروس لیول کا مقصد ہے: سروس لیول کے لیے ٹارگٹ ویلیو یا اقدار کی رینج جس کی پیمائش SLI کے ذریعے کی جاتی ہے۔ SLO کے لیے ایک عام قدر "SLI ≤ ہدف" یا "نچلی حد ≤ SLI ≤ اوپری حد" ہے۔ مثال کے طور پر، ہم یہ فیصلہ کر سکتے ہیں کہ ہم SLO کو 100 ملی سیکنڈ سے کم کی اوسط تلاش کے استفسار کی تاخیر پر سیٹ کر کے شیکسپیئر کے تلاش کے نتائج کو "تیز" واپس کریں گے۔

صحیح SLO کا انتخاب ایک پیچیدہ عمل ہے۔ سب سے پہلے، آپ ہمیشہ ایک مخصوص قدر کا انتخاب نہیں کر سکتے۔ آپ کی خدمت میں بیرونی آنے والی HTTP درخواستوں کے لیے، Query Per Second (QPS) میٹرک کا تعین بنیادی طور پر آپ کے صارفین کی آپ کی خدمت پر جانے کی خواہش سے ہوتا ہے، اور آپ اس کے لیے SLO متعین نہیں کر سکتے۔

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

ایک بار پھر، یہ اس سے کہیں زیادہ مبہم ہے جو پہلی نظر میں لگتا ہے: آپ کو QPS کو حساب سے مکمل طور پر خارج نہیں کرنا چاہیے۔ حقیقت یہ ہے کہ QPS اور لیٹنسی ایک دوسرے سے مضبوطی سے متعلق ہیں: اعلی QPS اکثر زیادہ تاخیر کا باعث بنتے ہیں، اور خدمات کو عام طور پر کارکردگی میں زبردست کمی کا سامنا کرنا پڑتا ہے جب وہ ایک خاص بوجھ کی حد تک پہنچ جاتی ہیں۔

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

معاہدے

سروس لیول کا معاہدہ آپ کے صارفین کے ساتھ ایک واضح یا مضمر معاہدہ ہوتا ہے جس میں ان کے SLO سے ملنے (یا نہ ملنے) کے نتائج شامل ہوتے ہیں۔ نتائج سب سے زیادہ آسانی سے پہچانے جاتے ہیں جب وہ مالی ہوتے ہیں — ایک رعایت یا جرمانہ — لیکن وہ دوسری شکلیں لے سکتے ہیں۔ SLOs اور SLAs کے درمیان فرق کے بارے میں بات کرنے کا ایک آسان طریقہ یہ پوچھنا ہے کہ "اگر SLOs کو پورا نہ کیا جائے تو کیا ہوگا؟" اگر کوئی واضح نتائج نہیں ہیں، تو آپ تقریباً یقینی طور پر SLO کو دیکھ رہے ہیں۔

SRE عام طور پر SLAs بنانے میں شامل نہیں ہوتا ہے کیونکہ SLAs کا کاروبار اور مصنوعات کے فیصلوں سے گہرا تعلق ہوتا ہے۔ SRE، تاہم، ناکام SLOs کے نتائج کو کم کرنے میں مدد کرنے میں شامل ہے۔ وہ SLI کا تعین کرنے میں بھی مدد کر سکتے ہیں: ظاہر ہے، معاہدے میں SLO کی پیمائش کرنے کا ایک معروضی طریقہ ہونا چاہیے یا پھر اختلاف ہو گا۔

Google تلاش ایک ایسی اہم سروس کی ایک مثال ہے جس میں عوامی SLA نہیں ہے: ہم چاہتے ہیں کہ ہر کوئی تلاش کو ہر ممکن حد تک مؤثر طریقے سے استعمال کرے، لیکن ہم نے دنیا کے ساتھ کسی معاہدے پر دستخط نہیں کیے ہیں۔ تاہم، تلاش کے دستیاب نہ ہونے کی صورت میں اب بھی نتائج موجود ہیں - عدم دستیابی کے نتیجے میں ہماری ساکھ میں کمی کے ساتھ ساتھ اشتہاری آمدنی میں کمی واقع ہوتی ہے۔ بہت سی دوسری Google سروسز، جیسے کہ Google for Work، کے صارفین کے ساتھ واضح سروس لیول کے معاہدے ہیں۔ قطع نظر اس کے کہ کسی خاص سروس کا SLA ہے، SLI اور SLO کی وضاحت کرنا اور سروس کو منظم کرنے کے لیے ان کا استعمال کرنا ضروری ہے۔

بہت زیادہ نظریہ - اب تجربہ کرنے کے لئے.

عملی طور پر اشارے

یہ دیکھتے ہوئے کہ ہم نے نتیجہ اخذ کیا ہے کہ سروس کی سطح کی پیمائش کرنے کے لیے مناسب میٹرکس کا انتخاب کرنا ضروری ہے، اب آپ کو کیسے معلوم ہوگا کہ سروس یا سسٹم کے لیے کون سے میٹرکس اہم ہیں؟

آپ اور آپ کے صارفین کو کیا خیال ہے؟

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

خدمات کو عام طور پر SLI کے لحاظ سے کئی حصوں میں تقسیم کیا جا سکتا ہے جو ان سے متعلقہ ہیں:

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

اشارے کا مجموعہ

بہت سے خدمت کی سطح کے اشارے سب سے زیادہ قدرتی طور پر سرور کی طرف جمع کیے جاتے ہیں، نگرانی کے نظام جیسے بورگمون (نیچے دیکھیں) کا استعمال کرتے ہوئے۔ باب 10 ٹائم سیریز ڈیٹا کی بنیاد پر الرٹس کی مشق کریں۔) یا Prometheus، یا صرف وقتاً فوقتاً لاگز کا تجزیہ کرتے ہوئے، اسٹیٹس 500 کے ساتھ HTTP جوابات کی نشاندہی کرتے ہیں۔ تاہم، کچھ سسٹمز کو کلائنٹ سائیڈ میٹرکس کلیکشن سے لیس ہونا چاہیے، کیونکہ کلائنٹ سائڈ مانیٹرنگ کی کمی کی وجہ سے متعدد مسائل غائب ہو سکتے ہیں جو متاثر ہوتے ہیں۔ صارفین، لیکن سرور سائیڈ میٹرکس کو متاثر نہیں کرتے۔ مثال کے طور پر، ہماری شیکسپیئر سرچ ٹیسٹ ایپلیکیشن کے بیک اینڈ ریسپانس لیٹنسی پر توجہ مرکوز کرنے کے نتیجے میں جاوا اسکرپٹ کے مسائل کی وجہ سے صارف کی طرف تاخیر ہو سکتی ہے: اس صورت میں، براؤزر کو صفحہ پر کارروائی کرنے میں کتنا وقت لگتا ہے اس کی پیمائش کرنا ایک بہتر میٹرک ہے۔

جمع کرنا

سادگی اور استعمال میں آسانی کے لیے، ہم اکثر خام پیمائش کو جمع کرتے ہیں۔ یہ احتیاط سے کیا جانا چاہئے.

کچھ میٹرکس آسان معلوم ہوتے ہیں، جیسے درخواستیں فی سیکنڈ، لیکن یہ بظاہر سیدھی پیمائش بھی وقت کے ساتھ ساتھ ڈیٹا کو واضح طور پر جمع کرتی ہے۔ کیا پیمائش خاص طور پر فی سیکنڈ میں ایک بار موصول ہوئی ہے یا پیمائش کا اوسط فی منٹ درخواستوں کی تعداد سے ہے؟ مؤخر الذکر آپشن درخواستوں کی بہت زیادہ فوری تعداد کو چھپا سکتا ہے جو صرف چند سیکنڈ تک جاری رہتی ہے۔ ایک ایسے نظام پر غور کریں جو 200 درخواستیں فی سیکنڈ برابر نمبروں کے ساتھ اور بقیہ وقت 0 کے ساتھ پیش کرتا ہے۔ فی سیکنڈ 100 درخواستوں کی اوسط قدر کی شکل میں ایک مستقل اور دو بار فوری بوجھ ایک ہی چیز نہیں ہیں۔ اسی طرح، اوسطاً استفسار کی تاخیر پرکشش لگ سکتی ہے، لیکن یہ ایک اہم تفصیل کو چھپاتا ہے: یہ ممکن ہے کہ زیادہ تر استفسارات تیز ہوں، لیکن بہت سے سوالات ایسے ہوں گے جو سست ہوں۔

زیادہ تر اشارے اوسط کے بجائے تقسیم کے طور پر بہتر دیکھے جاتے ہیں۔ مثال کے طور پر، SLI لیٹنسی کے لیے، کچھ درخواستوں پر تیزی سے کارروائی کی جائے گی، جب کہ کچھ میں ہمیشہ زیادہ وقت لگے گا، کبھی کبھی بہت زیادہ۔ ایک سادہ اوسط ان طویل تاخیر کو چھپا سکتی ہے۔ اعداد و شمار ایک مثال دکھاتا ہے: اگرچہ ایک عام درخواست کو پیش کرنے میں تقریباً 50 ms کا وقت لگتا ہے، لیکن 5% درخواستیں 20 گنا سست ہوتی ہیں! صرف اوسط تاخیر کی بنیاد پر مانیٹرنگ اور الرٹ کرنا دن بھر کے رویے میں تبدیلیاں نہیں دکھاتا، جب کہ حقیقت میں کچھ درخواستوں کے پروسیسنگ کے وقت میں نمایاں تبدیلیاں ہوتی ہیں (سب سے اوپر کی لائن)۔

50، 85، 95، اور 99 پرسنٹائل سسٹم میں تاخیر۔ Y محور لوگاریتھمک فارمیٹ میں ہے۔

اشارے کے لیے پرسنٹائل کا استعمال آپ کو تقسیم کی شکل اور اس کی خصوصیات کو دیکھنے کی اجازت دیتا ہے: ایک اعلی پرسنٹائل لیول، جیسے 99 یا 99,9، بدترین قدر کو ظاہر کرتا ہے، جب کہ 50 پرسنٹائل (جسے میڈین بھی کہا جاتا ہے) سب سے زیادہ بار بار ہونے والی حالت کو ظاہر کرتا ہے۔ میٹرک رسپانس ٹائم کی تقسیم جتنی زیادہ ہوگی، اتنی ہی طویل مدتی درخواستیں صارف کے تجربے کو متاثر کرتی ہیں۔ اثر زیادہ بوجھ کے تحت اور قطاروں کی موجودگی میں بڑھایا جاتا ہے۔ صارف کے تجربے کی تحقیق سے پتہ چلتا ہے کہ لوگ عام طور پر ایک سست نظام کو ترجیح دیتے ہیں جس میں اعلی ردعمل کے وقت کے تغیرات ہوتے ہیں، اس لیے کچھ SRE ٹیمیں صرف اعلی پرسنٹائل سکور پر توجہ مرکوز کرتی ہیں، اس بنیاد پر کہ اگر میٹرک کا رویہ 99,9 پرسنٹائل پر اچھا ہے، تو زیادہ تر صارفین کو مسائل کا سامنا نہیں کرنا پڑے گا۔ .

شماریاتی غلطیوں پر نوٹ کریں۔

ہم عام طور پر اقدار کے سیٹ کے اوسط (ریاضی اوسط) کے بجائے فیصد کے ساتھ کام کرنے کو ترجیح دیتے ہیں۔ یہ ہمیں زیادہ منتشر اقدار پر غور کرنے کی اجازت دیتا ہے، جن میں اکثر اوسط سے نمایاں طور پر مختلف (اور زیادہ دلچسپ) خصوصیات ہوتی ہیں۔ کمپیوٹنگ سسٹمز کی مصنوعی نوعیت کی وجہ سے، میٹرک ویلیوز اکثر ترچھی ہوتی ہیں، مثال کے طور پر، کوئی بھی درخواست 0 ms سے کم میں جواب موصول نہیں کر سکتی، اور 1000 ms کے ٹائم آؤٹ کا مطلب ہے کہ اس سے زیادہ قدروں کے ساتھ کامیاب جوابات نہیں ہو سکتے۔ ٹائم آؤٹ کے مقابلے میں. نتیجے کے طور پر، ہم یہ قبول نہیں کر سکتے کہ وسط اور درمیانی ایک دوسرے کے قریب ہو سکتے ہیں!

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

اشارے کو معیاری بنائیں

ہم SLI کی عمومی خصوصیات کو معیاری بنانے کی تجویز کرتے ہیں تاکہ آپ کو ہر بار ان کے بارے میں قیاس آرائی نہ کرنا پڑے۔ کوئی بھی خصوصیت جو معیاری نمونوں کو پورا کرتی ہے اسے انفرادی SLI کی تفصیلات سے خارج کیا جا سکتا ہے، مثال کے طور پر:

• جمع کرنے کے وقفے: "اوسط 1 منٹ سے زیادہ"
• جمع کرنے والے علاقے: "کلسٹر میں تمام کام"
• کتنی بار پیمائش کی جاتی ہے: "ہر 10 سیکنڈ"
• کیا درخواستیں شامل ہیں: "بلیک باکس مانیٹرنگ جابز سے HTTP حاصل کریں"
• ڈیٹا کیسے حاصل کیا جاتا ہے: "سرور پر ماپا جانے والی ہماری نگرانی کا شکریہ"
• ڈیٹا تک رسائی میں تاخیر: "آخری بائٹ کا وقت"

کوشش بچانے کے لیے، ہر عام میٹرک کے لیے دوبارہ قابل استعمال SLI ٹیمپلیٹس کا ایک سیٹ بنائیں۔ وہ ہر کسی کے لیے یہ سمجھنا آسان بناتے ہیں کہ کسی مخصوص SLI کا کیا مطلب ہے۔

عملی طور پر اہداف

اس کے بارے میں سوچ کر شروع کریں (یا معلوم کریں!) کہ آپ کے صارفین کس چیز کی پرواہ کرتے ہیں، نہ کہ آپ کس چیز کی پیمائش کر سکتے ہیں۔ اکثر آپ کے صارفین جس چیز کا خیال رکھتے ہیں اس کی پیمائش کرنا مشکل یا ناممکن ہوتا ہے، لہذا آپ ان کی ضروریات کے قریب پہنچ جاتے ہیں۔ تاہم، اگر آپ صرف اس چیز سے شروع کرتے ہیں جس کی پیمائش کرنا آسان ہے، تو آپ کو کم مفید SLOs ملیں گے۔ نتیجے کے طور پر، ہم نے کبھی کبھی پایا ہے کہ ابتدائی طور پر مطلوبہ اہداف کی نشاندہی کرنا اور پھر مخصوص اشارے کے ساتھ کام کرنا اشارے منتخب کرنے اور پھر اہداف کو حاصل کرنے سے بہتر کام کرتا ہے۔

اہداف کی وضاحت کریں۔

زیادہ سے زیادہ وضاحت کے لیے، اس کی وضاحت کی جانی چاہیے کہ SLOs کی پیمائش کیسے کی جاتی ہے اور وہ کن شرائط کے تحت درست ہیں۔ مثال کے طور پر، ہم مندرجہ ذیل کہہ سکتے ہیں (دوسری لائن پہلی جیسی ہے، لیکن SLI ڈیفالٹس استعمال کرتی ہے):

• گیٹ RPC کالز کا 99% (اوسط 1 منٹ سے زیادہ) 100ms سے بھی کم وقت میں مکمل ہو جائے گا (تمام بیک اینڈ سرورز پر ماپا جاتا ہے)۔
• 99% گیٹ RPC کالز 100ms سے بھی کم وقت میں مکمل ہو جائیں گی۔

اگر کارکردگی کے منحنی خطوط کی شکل اہم ہے، تو آپ متعدد SLOs کی وضاحت کر سکتے ہیں:

• 90% گیٹ RPC کالز 1 ms سے بھی کم وقت میں مکمل ہو جاتی ہیں۔
• 99% گیٹ RPC کالز 10 ms سے بھی کم وقت میں مکمل ہو جاتی ہیں۔
• 99.9% گیٹ RPC کالز 100 ms سے بھی کم وقت میں مکمل ہو جاتی ہیں۔

اگر آپ کے صارفین متضاد کام کا بوجھ پیدا کرتے ہیں: بلک پروسیسنگ (جس کے لیے تھرو پٹ اہم ہے) اور انٹرایکٹو پروسیسنگ (جس کے لیے لیٹنسی اہم ہے)، ہر لوڈ کلاس کے لیے الگ الگ اہداف کی وضاحت کرنا مفید ہو سکتا ہے:

• 95% کسٹمر کی درخواستوں کو تھرو پٹ کی ضرورت ہوتی ہے۔ آر پی سی کالز کی گنتی طے کریں <1 s۔
• 99% کلائنٹس تاخیر کا خیال رکھتے ہیں۔ ٹریفک <1 KB اور چل رہی <10 ms کے ساتھ RPC کالوں کی گنتی سیٹ کریں۔

یہ اصرار کرنا غیر حقیقی اور ناپسندیدہ ہے کہ SLOs کو 100% وقت پورا کیا جائے گا: یہ نئی فعالیت اور تعیناتی کو متعارف کرانے کی رفتار کو کم کر سکتا ہے، اور مہنگے حل کی ضرورت ہے۔ اس کے بجائے، یہ بہتر ہے کہ خرابی والے بجٹ کی اجازت دی جائے - سسٹم ڈاؤن ٹائم کا فیصد جس کی اجازت دی گئی ہے - اور روزانہ یا ہفتہ وار اس قدر کی نگرانی کریں۔ اعلیٰ انتظامیہ ماہانہ یا سہ ماہی جائزہ لینا چاہتی ہے۔ (غلطی کا بجٹ کسی دوسرے SLO سے موازنہ کرنے کے لیے محض ایک SLO ہے۔)

SLO کی خلاف ورزیوں کے فیصد کا موازنہ غلطی کے بجٹ سے کیا جا سکتا ہے (باب 3 اور سیکشن دیکھیں "خرابی بجٹ کے لئے حوصلہ افزائی")، اس عمل میں ان پٹ کے طور پر استعمال ہونے والی فرق کی قدر کے ساتھ جو یہ فیصلہ کرتا ہے کہ نئی ریلیزز کو کب تعینات کرنا ہے۔

ہدف کی اقدار کا انتخاب

منصوبہ بندی کی اقدار (SLOs) کا انتخاب خالصتاً تکنیکی سرگرمی نہیں ہے کیونکہ مصنوعات اور کاروباری مفادات کو منتخب SLIs، SLOs (اور ممکنہ طور پر SLAs) میں ظاہر ہونا چاہیے۔ اسی طرح، سٹافنگ، مارکیٹ میں وقت، آلات کی دستیابی، اور فنانسنگ سے متعلق مسائل کے بارے میں معلومات کا تبادلہ کرنے کی ضرورت پڑ سکتی ہے۔ SRE کو اس گفتگو کا حصہ ہونا چاہیے اور مختلف اختیارات کے خطرات اور قابل عملیت کو سمجھنے میں مدد کرنی چاہیے۔ ہم چند سوالات کے ساتھ آئے ہیں جو مزید نتیجہ خیز بحث کو یقینی بنانے میں مدد کر سکتے ہیں:

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

سادہ رکھیں
پیچیدہ SLI حسابات سسٹم کی کارکردگی میں تبدیلیوں کو چھپا سکتے ہیں اور مسئلہ کی وجہ تلاش کرنا مشکل بنا سکتے ہیں۔

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

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

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

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

اپنی پیمائش کو کنٹرول کریں۔

SLI اور SLO کلیدی عناصر ہیں جو نظام کو منظم کرنے کے لیے استعمال ہوتے ہیں:

• SLI سسٹمز کی نگرانی اور پیمائش کریں۔
• SLI کا SLO سے موازنہ کریں اور فیصلہ کریں کہ کیا کارروائی کی ضرورت ہے۔
• اگر عمل درکار ہے تو معلوم کریں کہ مقصد کو حاصل کرنے کے لیے کیا ہونے کی ضرورت ہے۔
• اس عمل کو مکمل کریں۔

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

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

اپنے صارفین کے لیے حقیقت پسندانہ توقعات قائم کرنے کے لیے، درج ذیل میں سے ایک یا دونوں حربوں کا استعمال کریں:

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

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

عملی طور پر معاہدے

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

ترجمہ آخر تک پڑھنے کا شکریہ۔ نگرانی کے بارے میں میرے ٹیلیگرام چینل کو سبسکرائب کریں۔ نگرانی_یہ и میڈیم پر بلاگ.

ماخذ: www.habr.com