SRE (Site Reliability Engineering) ويب پروجيڪٽس جي دستيابي کي يقيني بڻائڻ جو هڪ طريقو آهي. اهو سمجهيو ويندو آهي هڪ فريم ورڪ لاءِ DevOps ۽ ڳالهائيندو آهي ته ڪيئن DevOps عملن کي لاڳو ڪرڻ ۾ ڪاميابي حاصل ڪجي. هن مضمون ۾ ترجمو ڪتاب گوگل کان. مون ھي ترجمو پاڻ تيار ڪيو ۽ مانيٽرنگ جي عمل کي سمجھڻ ۾ پنھنجي تجربي تي ڀروسو ڪيو. ٽيليگرام چينل ۾ и مون خدمت جي سطح جي مقصدن بابت ساڳئي ڪتاب جي باب 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٪ آهي.
مقصد
هڪ SLO هڪ خدمت جي سطح جو مقصد آهي: خدمت جي سطح لاءِ حدف جي قيمت يا قدرن جي حد جيڪا SLI پاران ماپي ويندي آهي. SLO لاءِ هڪ عام قدر آهي "SLI ≤ ٽارگيٽ" يا "لوئر حد ≤ SLI ≤ اپر حد". مثال طور، اسان اهو فيصلو ڪري سگهون ٿا ته اسان شيڪسپيئر جي ڳولا جا نتيجا ”تيز“ ڏينداسين SLO کي ترتيب ڏيندي سراسري ڳولا جي پڇا ڳاڇا جي دير سان 100 ملي سيڪنڊن کان گهٽ.
صحيح SLO چونڊڻ هڪ پيچيده عمل آهي. پهرين، توهان هميشه هڪ خاص قدر نه چونڊي سگهو ٿا. توهان جي خدمت ۾ ايندڙ ايندڙ HTTP درخواستن لاءِ، سوال في سيڪنڊ (QPS) ميٽرڪ بنيادي طور تي طئي ڪيو ويندو آهي توهان جي استعمال ڪندڙن جي توهان جي خدمت تي وڃڻ جي خواهش، ۽ توهان ان لاءِ SLO مقرر نٿا ڪري سگهو.
ٻئي طرف، توهان اهو چئي سگهو ٿا ته توهان چاهيو ٿا ته هر درخواست لاء اوسط ويڪرائي 100 ملي سيڪنڊ کان گهٽ هجڻ گهرجي. اهڙو مقصد مقرر ڪرڻ توهان کي مجبور ڪري سگھي ٿو ته توهان پنهنجي فرنٽ اينڊ کي گهٽ ويڪرائي سان لکو يا سامان خريد ڪريو جيڪي اهڙي دير سان مهيا ڪن. (100 milliseconds ظاھر طور ھڪ صوابديدي نمبر آھي، پر اھو بھتر آھي ته ان کان به گھٽ ويڪرائي نمبر ھجن. اتي ثبوت آھي ته تيز رفتار سست رفتارن کان بھتر آھي، ۽ اھو دير سان صارف جي درخواستن جي پروسيسنگ ۾ ڪجھ قدرن کان مٿانهون آھي اصل ۾ ماڻھن کي پري رھڻ تي مجبور ڪري ٿو. توهان جي خدمت مان.)
ٻيهر، اهو وڌيڪ مبہم آهي انهي کان وڌيڪ اهو لڳي سگهي ٿو پهرين نظر ۾: توهان کي مڪمل طور تي حساب کان QPS کي خارج نه ڪرڻ گهرجي. حقيقت اها آهي ته QPS ۽ ويڪرائي هڪ ٻئي سان مضبوط طور تي جڙيل آهن: اعلي QPS اڪثر ڪري وڌيڪ دير جي ڪري ٿي، ۽ خدمتون عام طور تي ڪارڪردگي ۾ تيز گهٽتائي جو تجربو ڪندا آهن جڏهن اهي هڪ خاص لوڊ حد تائين پهچي ويندا آهن.
SLO کي چونڊڻ ۽ شايع ڪرڻ صارف جي اميدن کي سيٽ ڪري ٿو ته خدمت ڪيئن ڪم ڪندي. اها حڪمت عملي خدمت جي مالڪ جي خلاف بي بنياد شڪايتون گهٽائي سگهي ٿي، جهڙوڪ سست ڪارڪردگي. واضح SLO کان سواءِ، صارف اڪثر ڪري گهربل ڪارڪردگيءَ جي باري ۾ پنهنجون اميدون ٺاهيندا آهن، جن جو شايد خدمت جي ڊيزائن ۽ انتظام ڪرڻ وارن ماڻهن جي راءِ سان ڪو به واسطو نه هوندو. اها صورتحال خدمت کان وڌيل اميدن جي ڪري ٿي سگهي ٿي، جڏهن صارفين کي غلطي سان يقين آهي ته خدمت ان کان وڌيڪ رسائي هوندي جيڪا اصل ۾ آهي، ۽ بي اعتمادي جو سبب بڻجندي جڏهن صارفين کي يقين آهي ته اهو نظام اصل کان گهٽ قابل اعتماد آهي.
معاهدو
خدمت جي سطح جو معاهدو توهان جي استعمال ڪندڙن سان هڪ واضح يا غير واضح معاهدو آهي جنهن ۾ انهن ۾ شامل SLO جي ملڻ (يا نه ملڻ) جا نتيجا شامل آهن. نتيجا تمام آسانيءَ سان سڃاتا ويندا آھن جڏھن اھي مالي آھن- ھڪ رعايت يا ٺيڪ- پر اھي ٻيون شڪلون وٺي سگھن ٿا. SLOs ۽ SLAs جي وچ ۾ فرق جي باري ۾ ڳالهائڻ جو هڪ آسان طريقو اهو آهي ته "ڇا ٿيندو جيڪڏهن SLOs نه ملن؟" جيڪڏهن ڪو واضح نتيجا نه آهن، توهان تقريبن ضرور هڪ SLO تي ڏسي رهيا آهيو.
SRE عام طور تي SLAs ٺاهڻ ۾ ملوث ناهي ڇو ته SLAs ڪاروبار ۽ پيداوار جي فيصلن سان ويجھي ڳنڍيل آهن. SRE، جيتوڻيڪ، ناڪام SLOs جي نتيجن کي گھٽائڻ ۾ مدد ڪرڻ ۾ شامل آھي. اهي پڻ SLI جو تعين ڪرڻ ۾ مدد ڪري سگھن ٿا: ظاهر آهي، معاهدي ۾ SLO کي ماپڻ لاءِ هڪ مقصدي طريقو هجڻ گهرجي يا اتي اختلاف هوندو.
گوگل سرچ ھڪ اھم خدمت جو ھڪڙو مثال آھي جنھن ۾ عوامي SLA نه آھي: اسان چاھيون ٿا ته ھر ڪو سرچ کي ممڪن طور موثر انداز ۾ استعمال ڪري، پر اسان دنيا سان ڪو معاهدو نه ڪيو آھي. تنهن هوندي، اڃا به نتيجا آهن جيڪڏهن ڳولا دستياب ناهي - غير دستيابي جي نتيجي ۾ اسان جي شهرت ۾ گهٽتائي ۽ اشتهارن جي آمدني ۾ گهٽتائي. گوگل جون ٻيون ڪيتريون ئي خدمتون، جهڙوڪ گوگل فار ڪم، صارفين سان واضح خدمت سطح جا معاهدا آهن. ان کان سواءِ ته ڇا ڪنهن خاص خدمت وٽ SLA آهي، اهو ضروري آهي ته SLI ۽ SLO جي وضاحت ڪجي ۽ انهن کي استعمال ڪرڻ لاءِ خدمت کي منظم ڪجي.
تمام گهڻو نظريو - هاڻي تجربو ڪرڻ لاء.
عملي ۾ اشارا
ڏنو ويو آهي ته اسان اهو نتيجو ڪيو آهي ته خدمت جي سطح کي ماپڻ لاء مناسب ميٽرڪ چونڊڻ ضروري آهي، توهان هاڻي ڪيئن ڄاڻو ٿا ته ڪهڙي ميٽرڪ خدمت يا سسٽم لاء اهم آهي؟
توهان ۽ توهان جي صارفين کي ڇا خيال آهي؟
توهان کي هر ميٽرڪ کي SLI طور استعمال ڪرڻ جي ضرورت ناهي جيڪا توهان نگراني سسٽم ۾ ٽريڪ ڪري سگهو ٿا؛ سمجھڻ ته صارف ڇا ٿا چاھين ھڪڙي سسٽم مان توھان کي مدد ڪندي ڪيترن ئي ميٽرڪ کي چونڊڻ ۾. تمام گھڻا اشارا چونڊڻ ان کي ڏکيو بڻائي ٿو اھم اشارن تي ڌيان ڏيڻ، جڏھن ته ھڪڙو ننڍڙو انگ چونڊڻ توھان جي سسٽم جو وڏو حصو ڇڏي سگھي ٿو. اسان عام طور تي سسٽم جي صحت کي جانچڻ ۽ سمجهڻ لاءِ ڪيترائي اهم اشارا استعمال ڪندا آهيون.
خدمتون عام طور تي SLI جي لحاظ کان ڪيترن ئي حصن ۾ ورهائي سگھجن ٿيون جيڪي انھن سان لاڳاپيل آھن:
- ڪسٽم فرنٽ-اينڊ سسٽم، جيئن اسان جي مثال مان شيڪسپيئر سروس لاء ڳولا انٽرفيس. انهن کي دستياب هجڻ گهرجي، دير نه آهي ۽ ڪافي بينڊوڊٿ آهي. ان جي مطابق، سوال پڇي سگهجن ٿا: ڇا اسان درخواست جو جواب ڏئي سگھون ٿا؟ درخواست جو جواب ڏيڻ ۾ ڪيترو وقت لڳو؟ ڪيترين ئي درخواستن تي عمل ڪري سگهجي ٿو؟
- اسٽوريج سسٽم. اهي قيمت گھٽ جواب جي ويڪرائي، دستيابي، ۽ استحڪام. لاڳاپيل سوال: ڊيٽا کي پڙهڻ يا لکڻ ۾ ڪيترو وقت لڳندو آهي؟ ڇا اسان درخواست تي ڊيٽا تائين رسائي ڪري سگھون ٿا؟ ڇا ڊيٽا موجود آهي جڏهن اسان کي ضرورت آهي؟ ڏسو باب 26 ڊيٽا انٽيگرٽي: جيڪي توهان پڙهو ٿا اهو آهي جيڪو توهان لکندا آهيو انهن مسئلن جي تفصيلي بحث لاءِ.
- وڏي ڊيٽا سسٽم جهڙوڪ ڊيٽا پروسيسنگ پائپ لائنز تي ڀروسو ڪن ٿا throughput ۽ سوال پروسيسنگ ويڪرائي. لاڳاپيل سوال: ڪيترو ڊيٽا پروسيس ٿيل آهي؟ گذارش حاصل ڪرڻ کان وٺي جواب جاري ڪرڻ تائين ڊيٽا کي سفر ڪرڻ ۾ ڪيترو وقت لڳندو آهي؟ (سسٽم جي ڪجهه حصن ۾ ڪجهه مرحلن ۾ دير ٿي سگھي ٿي.)
اشارن جو مجموعو
ڪيترائي خدمت جي سطح جا اشارا سڀ کان وڌيڪ قدرتي طور تي سرور جي پاسي تي گڏ ڪيا ويا آهن، مانيٽرنگ سسٽم استعمال ڪندي جيئن ته Borgmon (هيٺ ڏسو). ) يا Prometheus، يا صرف وقتي طور تي لاگن جو تجزيو ڪرڻ، HTTP جوابن کي اسٽيٽس 500 سان سڃاڻڻ. بهرحال، ڪجهه سسٽم کي ڪلائنٽ-سائيڊ ميٽرڪ گڏ ڪرڻ سان ليس هجڻ گهرجي، ڇاڪاڻ ته ڪلائنٽ-سائيڊ مانيٽرنگ جي کوٽ سبب ڪيترن ئي مسئلن کي غائب ٿي سگهي ٿو جيڪي متاثر ڪن ٿا. استعمال ڪندڙ، پر سرور-سائڊ ميٽرڪ تي اثر انداز نه ڪندا آھن. مثال طور، اسان جي شيڪسپيئر سرچ ٽيسٽ ايپليڪيشن جي پس منظر جي جواب جي دير تي ڌيان ڏيڻ جاوا اسڪرپٽ مسئلن جي ڪري صارف جي پاسي تي دير جي نتيجي ۾ ٿي سگھي ٿي: انهي صورت ۾، ماپڻ ڪيترو وقت وٺندو آهي برائوزر صفحي کي پروسيس ڪرڻ لاء هڪ بهتر ميٽرڪ آهي.
جمع ڪرڻ
سادگي ۽ استعمال جي آسانيءَ لاءِ، اسين اڪثر خام ماپن کي گڏ ڪندا آهيون. اهو احتياط سان ڪيو وڃي.
ڪجهه ميٽرڪس سادو لڳي ٿو، جهڙوڪ درخواستون في سيڪنڊ، پر اهو به ظاهري طور تي سڌي ماپ واضح طور تي وقت سان گڏ ڊيٽا کي گڏ ڪري ٿو. ڇا ماپ خاص طور تي هڪ ڀيرو في سيڪنڊ حاصل ڪئي وئي آهي يا ماپ في منٽ جي درخواستن جي تعداد تي اوسط آهي؟ پوئين اختيار کي لڪائي سگھي ٿو تمام گھڻو فوري تعداد جي درخواستن جو جيڪو صرف چند سيڪنڊن جي آخري آھي. ھڪڙي سسٽم تي غور ڪريو جيڪو 200 درخواستون في سيڪنڊ سان گڏ نمبرن سان ۽ 0 باقي وقت سان. 100 درخواستن في سيڪنڊ جي سراسري قيمت جي صورت ۾ هڪ مستقل ۽ ٻه ڀيرا فوري لوڊ ساڳيو شيء ناهي. اهڙي طرح، سراسري پڇا ڳاڇا ڪرڻ ۾ دير ٿي سگھي ٿي پرڪشش لڳي، پر اهو هڪ اهم تفصيل لڪائي ٿو: اهو ممڪن آهي ته گهڻا سوال تيز هوندا، پر اهڙا ڪيترائي سوال هوندا جيڪي سست هوندا.
گھڻا اشارا بھتر طور ڏٺا ويندا آھن بطور اوسط جي ڀيٽ ۾. مثال طور، SLI ويڪرائي لاءِ، ڪجهه درخواستن تي جلدي عمل ڪيو ويندو، جڏهن ته ڪجهه هميشه گهڻي وقت وٺنديون، ڪڏهن گهڻو وقت. هڪ سادي اوسط انهن ڊگهي دير کي لڪائي سگهي ٿو. انگ اکر هڪ مثال ڏيکاري ٿو: جيتوڻيڪ هڪ عام درخواست لڳ ڀڳ 50 ms لڳندي آهي خدمت ڪرڻ لاء، 5٪ درخواستون 20 ڀيرا سست آهن! صرف اوسط ويڪرائي جي بنياد تي نگراني ۽ خبرداري سڄي ڏينهن ۾ رويي ۾ تبديليون نه ڏيکاريندي آهي، جڏهن حقيقت ۾ ڪجهه درخواستن جي پروسيسنگ وقت ۾ قابل ذڪر تبديليون آهن (مٿيون قطار).
50، 85، 95، ۽ 99 سيڪڙو سسٽم ويڪرائي. Y محور logarithmic فارميٽ ۾ آهي.
اشارن لاءِ پرسنٽائل استعمال ڪرڻ توهان کي تقسيم جي شڪل ۽ ان جي خاصيتن کي ڏسڻ جي اجازت ڏئي ٿي: هڪ اعلي سيڪڙو سطح، جهڙوڪ 99 يا 99,9، بدترين قدر ڏيکاري ٿو، جڏهن ته 50 سيڪڙو (جنهن کي ميڊين پڻ سڏيو ويندو آهي) ڏيکاري ٿو سڀ کان وڌيڪ بار بار جي حالت. ميٽرڪ. جوابي وقت جي ترت جيترو وڏو ٿيندو، اوترو ئي ڊگھي هلندڙ درخواستون صارف جي تجربي تي اثر انداز ٿينديون. اثر وڌو ويو آھي تيز لوڊ ھيٺ ۽ قطار جي موجودگي ۾. صارف جي تجربي جي تحقيق مان اهو ظاهر ڪيو ويو آهي ته ماڻهو عام طور تي سست سسٽم کي ترجيح ڏيندا آهن تيز جوابي وقت جي فرق سان، تنهن ڪري ڪجهه SRE ٽيمون صرف اعلي سيڪڙو اسڪور تي ڌيان ڏين ٿيون، انهي بنياد تي ته جيڪڏهن ميٽرڪ جو رويو 99,9 سيڪڙو تي سٺو آهي، اڪثر صارفين کي مشڪلاتن جو تجربو نه ٿيندو. .
شمارياتي غلطين تي نوٽ ڪريو
اسان عام طور تي قدرن جي سيٽ جي اوسط (رياضي جو مطلب) بجاءِ سيڪڙو سان ڪم ڪرڻ کي ترجيح ڏيون ٿا. هي اسان کي وڌيڪ منتشر قدرن تي غور ڪرڻ جي اجازت ڏئي ٿو، جيڪي اڪثر ڪري خاص طور تي مختلف (۽ وڌيڪ دلچسپ) خاصيتون آهن اوسط کان. ڪمپيوٽنگ سسٽم جي مصنوعي نوعيت جي ڪري، ميٽرڪ قدر اڪثر ڪري ڇڏيا ويندا آهن، مثال طور، ڪا به درخواست 0 ms کان گهٽ ۾ جواب حاصل نه ڪري سگهي ٿي، ۽ 1000 ms جي وقت ختم ٿيڻ جو مطلب آهي ته اتي ڪامياب جواب نه ٿي سگهيا آهن قدرن سان وڌيڪ وقت ختم ٿيڻ کان. نتيجي طور، اسان اهو قبول نٿا ڪري سگهون ته مطلب ۽ وچين هڪجهڙا ٿي سگهن ٿا يا هڪ ٻئي جي ويجهو!
اڳواٽ جاچڻ کان سواءِ، ۽ جيستائين ڪجهه معياري مفروضا ۽ ويجهڙائيون نه هجن، اسان محتاط آهيون ته اهو نتيجو نه ڪڍيون ته اسان جو ڊيٽا عام طور تي ورهايو وڃي ٿو. جيڪڏهن تقسيم توقع جي مطابق نه آهي، خودڪار طريقي سان جيڪو مسئلو حل ڪري ٿو (مثال طور، جڏهن اهو ٻاهر نڪرندو آهي، اهو سرور کي ٻيهر شروع ڪري ٿو اعلي درخواست جي پروسيسنگ دير سان) شايد اهو اڪثر ڪري رهيو آهي يا گهڻو ڪري ڪافي نه آهي (جيڪي ٻئي نه آهن. تمام سٺو).
معياري اشارا
اسان SLI لاءِ عام خصوصيتن کي معياري بڻائڻ جي صلاح ڏيون ٿا ته جيئن توهان کي هر وقت انهن جي باري ۾ اندازو لڳائڻ جي ضرورت نه پوي. ڪا به خصوصيت جيڪا معياري نمونن کي پورو ڪري ٿي شايد انفرادي SLI جي وضاحتن مان خارج ٿي سگھي ٿي، مثال طور:
- مجموعي وقفو: "اوسط 1 منٽ کان وڌيڪ"
- گڏ ڪرڻ وارا علائقا: ”ڪلسٽر ۾ سڀ ڪم“
- ڪيترا ڀيرا ماپون ورتيون وينديون آهن: "هر 10 سيڪنڊ"
- ڪهڙيون درخواستون شامل آهن: "بليڪ باڪس مانيٽرنگ نوڪريون مان HTTP حاصل ڪريو"
- ڊيٽا ڪيئن حاصل ڪئي وئي آهي: "سرور تي ماپيل اسان جي نگراني جي مهرباني"
- ڊيٽا تائين رسائي جي دير: "آخري بائيٽ جو وقت"
ڪوشش بچائڻ لاءِ، هر عام ميٽرڪ لاءِ ٻيهر استعمال لائق SLI ٽيمپليٽس جو هڪ سيٽ ٺاهيو؛ اهي اهو پڻ آسان بڻائين ٿا هر ڪنهن لاءِ اهو سمجهڻ ته ڪنهن خاص SLI جو مطلب ڇا آهي.
عملي ۾ مقصد
سوچڻ سان شروع ڪريو (يا ڳولهڻ!) جيڪي توهان جي صارفين جي پرواهه ڪن ٿا، نه ته توهان ڪهڙي ماپ ڪري سگهو ٿا. گهڻو ڪري جيڪي توهان جي صارفن جي خيال ۾ آهن انهن کي ماپڻ ڏکيو يا ناممڪن آهي، تنهنڪري توهان انهن جي ضرورتن جي ويجهو حاصل ڪيو. تنهن هوندي، جيڪڏهن توهان صرف ان سان شروع ڪيو جيڪو ماپ ڪرڻ آسان آهي، توهان کي گهٽ مفيد SLOs سان ختم ڪنداسين. نتيجي طور، اسان ڪڏهن ڪڏهن ڏٺو آهي ته شروعاتي طور تي گهربل مقصدن کي سڃاڻڻ ۽ پوءِ مخصوص اشارن سان ڪم ڪرڻ اشارن کي چونڊڻ ۽ پوءِ مقصد حاصل ڪرڻ کان بهتر ڪم ڪري ٿو.
پنهنجا مقصد بيان ڪريو
وڌ ۾ وڌ وضاحت لاءِ، ان کي بيان ڪيو وڃي ته SLOs کي ڪيئن ماپيو وڃي ٿو ۽ ڪھڙي حالت ۾ اھي صحيح آھن. مثال طور، اسان ھيٺين کي چئي سگھون ٿا (ٻيون لڪير پھرين وانگر آھي، پر SLI ڊفالٽ استعمال ڪري ٿو):
- 99% (اوسط 1 منٽ کان وڌيڪ) حاصل ڪريو RPC ڪالون 100ms کان گھٽ ۾ مڪمل ٿينديون (سڀني پس منظر سرورن تي ماپيل).
- 99% حاصل ڪريو RPC ڪالون 100ms کان گھٽ ۾ مڪمل ٿينديون.
جيڪڏهن ڪارڪردگي وکر جي شڪل اهم آهي، توهان ڪيترن ئي SLO جي وضاحت ڪري سگهو ٿا:
- 90% حاصل ڪريو RPC ڪالون 1 ms کان گھٽ ۾ مڪمل ٿيون.
- 99% حاصل ڪريو RPC ڪالون 10 ms کان گھٽ ۾ مڪمل ٿيون.
- 99.9% حاصل ڪريو RPC ڪالون 100 ms کان گھٽ ۾ مڪمل ٿيون.
جيڪڏهن توهان جا استعمال ڪندڙ متضاد ڪم لوڊ ٺاهي رهيا آهن: بلڪ پروسيسنگ (جنهن لاءِ ٽراپٽ اهم آهي) ۽ انٽرايڪٽو پروسيسنگ (جنهن لاءِ ويڪرائي اهم آهي)، اهو ٿي سگهي ٿو ته هر لوڊ ڪلاس لاءِ الڳ مقصد بيان ڪرڻ مناسب آهي:
- 95٪ گراهڪ جي درخواستن جي ضرورت آهي throughput. آر پي سي ڪالن جي ڳڻپ کي ترتيب ڏيو <1 s.
- 99٪ گراهڪ دير جي باري ۾ خيال رکندا آهن. RPC ڪالن جي ڳڻپ کي ٽريفڪ سان سيٽ ڪريو <1 KB ۽ هلندڙ <10 ms.
اهو اصرار ڪرڻ غير حقيقي ۽ ناپسنديده آهي ته 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 ۾ شامل ٿي سگھي ٿو ان مفروضي کي جانچڻ ته سرورز سي پي يو پابند آهن ۽ وڌيڪ سرور شامل ڪرڻ سان لوڊ ورهايو ويندو. هڪ SLO کان سواء، توهان کي خبر ناهي ته (يا جڏهن) عمل ڪرڻ لاء.
SLO سيٽ ڪريو - پوءِ صارف جون اميدون مقرر ڪيون وينديون
هڪ SLO شايع ڪرڻ سسٽم جي رويي لاءِ صارف جون اميدون سيٽ ڪري ٿو. استعمال ڪندڙ (۽ امڪاني استعمال ڪندڙ) اڪثر ڄاڻڻ چاهيندا آهن ته ڪنهن خدمت مان ڪهڙي اميد رکي ٿي اهو سمجهڻ لاءِ ته ڇا اها استعمال لاءِ موزون آهي. مثال طور، ماڻهو جيڪي فوٽو شيئرنگ ويب سائيٽ استعمال ڪرڻ چاهين ٿا شايد هڪ خدمت استعمال ڪرڻ کان پاسو ڪرڻ چاهين ٿا جيڪي ڊگهي مدت ۽ گهٽ قيمت جي بدلي ۾ ٿوري گهٽ دستيابي جو واعدو ڪري ٿي، جيتوڻيڪ ساڳي خدمت آرڪائيو رڪارڊ مينيجمينٽ سسٽم لاءِ مثالي ٿي سگهي ٿي.
پنھنجي استعمال ڪندڙن لاءِ حقيقي اميدون قائم ڪرڻ لاءِ، ھيٺ ڏنل حڪمت عملين مان ھڪڙي يا ٻئي استعمال ڪريو.
- حفاظت جي حد کي برقرار رکڻ. استعمال ڪريو ھڪڙو سخت اندروني SLO ان کان وڌيڪ جيڪو اشتهار ڏنو ويو آھي صارفين کي. اهو توهان کي موقعو ڏيندو ته انهن مسئلن تي رد عمل ظاهر ڪرڻ کان پهريان اهي ٻاهرئين طور تي ظاهر ٿيڻ. SLO بفر پڻ توهان کي اجازت ڏئي ٿو حفاظتي مارجن جڏهن رليز انسٽال ڪري رهيا آهن جيڪي سسٽم جي ڪارڪردگي تي اثرانداز ٿين ٿا ۽ انهي کي يقيني بڻائي ٿو ته سسٽم برقرار رکڻ آسان آهي بغير استعمال ڪندڙن کي مايوس ڪرڻ جي بغير.
- صارف جي اميدن کان وڌيڪ نه ڪريو. صارفين تي ٻڌل آهن جيڪي توهان پيش ڪندا آهيو، نه جيڪي توهان چئو ٿا. جيڪڏهن توهان جي خدمت جي حقيقي ڪارڪردگي بيان ڪيل SLO کان گهڻو بهتر آهي، صارف موجوده ڪارڪردگي تي ڀروسو ڪندا. توھان عمدي طور تي سسٽم کي بند ڪرڻ يا ھلڪي لوڊ ھيٺ ڪارڪردگي کي محدود ڪرڻ کان وڌيڪ انحصار کان پاسو ڪري سگھو ٿا.
اهو سمجهڻ ته هڪ سسٽم ڪيتري حد تائين اميدن تي پورو لهي ٿو اهو فيصلو ڪرڻ ۾ مدد ڪري ٿو ته ڇا سسٽم کي تيز ڪرڻ ۽ ان کي وڌيڪ پهچ ۽ لچڪدار بڻائڻ ۾ سيڙپڪاري ڪرڻ. متبادل طور تي، جيڪڏهن هڪ خدمت تمام سٺو ڪم ڪري رهي آهي، ڪجهه عملي جو وقت ٻين ترجيحن تي خرچ ڪيو وڃي، جهڙوڪ ٽيڪنيڪل قرض ادا ڪرڻ، نيون خاصيتون شامل ڪرڻ، يا نئين شين کي متعارف ڪرائڻ.
عملي طور تي معاهدو
هڪ SLA ٺاهڻ لاءِ ڪاروباري ۽ قانوني ٽيمن جي ضرورت آهي ته ان جي خلاف ورزي جا نتيجا ۽ ڏنڊ مقرر ڪن. SRE جو ڪردار SLA ۾ موجود SLOs کي ملڻ ۾ امڪاني چئلينجن کي سمجھڻ ۾ انھن جي مدد ڪرڻ آھي. SLOs ٺاهڻ لاءِ اڪثر سفارشون SLAs تي به لاڳو ٿين ٿيون. اهو حڪمت وارو آهي قدامت پسند ٿيڻ ۾ جيڪو توهان صارفين سان واعدو ڪيو آهي ڇو ته توهان وٽ جيترو وڌيڪ آهي، اوترو وڌيڪ ڏکيو آهي SLA کي تبديل ڪرڻ يا هٽائڻ جيڪو غير معقول يا ملڻ ڏکيو لڳي ٿو.
آخر تائين ترجمو پڙهڻ لاءِ مهرباني. مانيٽرنگ بابت منهنجي ٽيليگرام چينل جي رڪنيت حاصل ڪريو и .
جو ذريعو: www.habr.com