SRE (د سایټ د اعتبار انجنیري) د ویب پروژو د لاسرسي وړ کولو لپاره یوه تګلاره ده. دا د DevOps لپاره یو چوکاټ ګڼل کیږي او وايي چې څنګه د DevOps کړنو پلي کولو کې بریالي شي. دا مقاله ژباړه کوي څلورم څپرکی د خدماتو د کچې موخې کتابونه د سایټ د اعتبار انجنیري د ګوګل څخه. ما دا ژباړه پخپله چمتو کړه او د څارنې پروسې په پوهیدو کې زما په خپله تجربه تکیه وکړه. په ټیلیګرام چینل کې څارنه_یې и په هابري کې وروستی پوسټ ما د ورته کتاب د شپږم څپرکي ژباړه هم د خدماتو کچې اهدافو په اړه خپره کړه.

د پیشو لخوا ژباړه. له لوستلو خوند واخلئ!

د خدماتو اداره کول ناممکن دي که چیرې پدې پوه نه وي چې کوم شاخصونه واقعیا مهم دي او څنګه یې اندازه کول او ارزونه کول. د دې پای ته رسولو لپاره، موږ خپلو کاروونکو ته د خدماتو یوه ټاکلې کچه تعریف او چمتو کوو، پرته له دې چې دوی زموږ یو داخلي API کاروي یا عامه محصول.

موږ د خدماتو کچې شاخصونو (SLIs) ، د خدماتو کچې اهدافو (SLOs) ، او د خدماتو کچې موافقتنامې (SLAs) د پوهیدو لپاره د کارونکي غوښتنې زموږ هوښیارتیا ، تجربه او پوهه کاروو. دا ابعاد هغه اصلي میټریکونه تشریح کوي چې موږ یې څارنه غواړو او که چیرې موږ نشو کولی د متوقع کیفیت خدمت چمتو کړو موږ به عکس العمل وښیو. په نهایت کې ، د سم میټریکونو غوره کول د سم عملونو لارښود کې مرسته کوي که چیرې یو څه غلط شي ، او د SRE ټیم ته د خدماتو روغتیا باور هم ورکوي.

دا څپرکی هغه طریقه بیانوي چې موږ یې د میټریک ماډلینګ، میټریک انتخاب، او میټریک تحلیل ستونزو سره د مبارزې لپاره کاروو. ډیری توضیحات به د مثالونو پرته وي، نو موږ به د اصلي ټکو د روښانه کولو لپاره د شیکسپیر خدمت د هغې پلي کولو مثال (د شکسپیر د کارونو لټون) څخه کار واخلو.

د خدمت کچه ​​اصطلاحات

ډیری لوستونکي احتمال لري د SLA مفهوم سره آشنا وي، مګر د SLI او SLO اصطلاحات د محتاط تعریف مستحق دي ځکه چې په عمومي توګه د SLA اصطالح ډیر بار شوی او د شرایطو پورې اړه لري یو شمیر معنی لري. د وضاحت لپاره، موږ غواړو دا ارزښتونه جلا کړو.

شاخصونه

SLI د خدماتو د کچې شاخص دی - د چمتو شوي خدماتو د کچې یو اړخ په احتیاط سره تعریف شوی کمیتي اندازه.

د ډیری خدماتو لپاره، کلیدي SLI د غوښتنې ځنډ په توګه ګڼل کیږي - څومره وخت نیسي چې غوښتنې ته ځواب بیرته راشي. په نورو عام SLIs کې د غلطۍ کچه شامله ده، ډیری وختونه د ټولو ترلاسه شویو غوښتنو د یوې برخې په توګه ښودل شوي، او د سیسټم له لارې، معمولا په هره ثانیه کې په غوښتنو کې اندازه کیږي. اندازه کول اکثرا راټولیږي: خام معلومات لومړی راټولیږي او بیا د بدلون نرخ، معنی، یا فیصدي ته بدلیږي.

په عین حال کې، SLI په مستقیم ډول د ګټو خدمت کچه ​​اندازه کوي، مګر ځینې وختونه یوازې یو اړونده میټریک د اندازه کولو لپاره شتون لري ځکه چې اصلي ترلاسه کول یا تشریح کول ستونزمن دي. د مثال په توګه، د پیرودونکي اړخ ځنډ اکثرا یو ډیر مناسب میټریک دی، مګر داسې وختونه شتون لري چې ځنډ یوازې په سرور کې اندازه کیدی شي.

د SLI بل ډول چې د SREs لپاره مهم دی شتون لري، یا د وخت برخه چې په ترڅ کې یې خدمت کارول کیدی شي. ډیری وختونه د بریالي غوښتنو نرخ په توګه تعریف شوي، ځینې وختونه د حاصل په نوم یادیږي. (د ژوند وخت - هغه احتمال چې ډاټا به د اوږدې مودې لپاره وساتل شي - د ډیټا ذخیره کولو سیسټمونو لپاره هم مهم دی.) که څه هم د 100٪ شتون امکان نلري، 100٪ ته نږدې شتون اکثرا د لاسته راوړلو وړ وي؛ د شتون ارزښتونه په توګه څرګند شوي. د "نهو" شمیره » د شتون سلنه. د مثال په توګه، د 99٪ او 99,999٪ شتون ممکن د "2 نو" او "5 نو" په توګه لیبل شي. د ګوګل کمپیوټ انجن اوسنی ټاکل شوی شتون هدف "درې نیم نهه" یا 99,95٪ دی.

موخې

SLO د خدماتو کچې هدف دی: د خدماتو کچې لپاره د هدف ارزښت یا د ارزښتونو لړۍ چې د SLI لخوا اندازه کیږي. د SLO لپاره نورمال ارزښت "SLI ≤ هدف" یا "لږ حد ≤ SLI ≤ لوړ حد" دی. د مثال په توګه، موږ ممکن پریکړه وکړو چې موږ به د شکسپیر لټون پایلې "چټک" ته د SLO په ترتیب کولو سره د اوسط لټون پوښتنې ځنډ ته د 100 ملی ثانیو څخه کم بیرته راستانه کړو.

د سم SLO غوره کول یوه پیچلې پروسه ده. لومړی، تاسو تل نشئ کولی یو ځانګړی ارزښت وټاکئ. ستاسو خدمت ته د خارجي راتلونکو HTTP غوښتنو لپاره، د پوښتنې فی ثانیه (QPS) میټریک په ابتدايي توګه ستاسو د کاروونکو لخوا ستاسو خدمت ته د لیدو لپاره ټاکل کیږي، او تاسو د دې لپاره SLO نشئ ټاکلی.

له بلې خوا، تاسو کولی شئ ووایئ چې تاسو غواړئ د هرې غوښتنې لپاره اوسط ځنډ د 100 ملی ثانیو څخه کم وي. د داسې هدف ټاکل ممکن تاسو دې ته اړ کړي چې خپل مخکینۍ پای د ټیټ ځنډ سره ولیکئ یا داسې تجهیزات واخلئ چې دا ډول ځنډ چمتو کوي. (100 ملی ثانوي په ښکاره ډول یو خپلسري شمیره ده، مګر دا غوره ده چې حتی د ټیټ ځنډ شمیرې هم ولري. داسې شواهد شتون لري چې وړاندیز کوي ګړندی سرعت د سست سرعت څخه غوره دی، او دا چې د کارونکي غوښتنې پروسس کولو کې ځنډ د ځانګړو ارزښتونو څخه پورته په حقیقت کې خلک مجبوروي چې لرې پاتې شي. ستاسو له خدمت څخه.)

یوځل بیا ، دا د هغه په ​​​​پرتله خورا مبهم دی چې ممکن په لومړي نظر کې ښکاري: تاسو باید په بشپړ ډول له محاسبې څخه QPS خارج نه کړئ. حقیقت دا دی چې QPS او ځنډ په کلکه یو له بل سره تړاو لري: لوړ QPS اکثرا د لوړې ځنډ لامل کیږي، او خدمات معمولا په فعالیت کې د پام وړ کمښت تجربه کوي کله چې دوی یو ټاکلی حد ته ورسیږي.

د SLO غوره کول او خپرول د کارونکي هیلې ټاکي چې څنګه به خدمت کار وکړي. دا ستراتیژي کولی شي د خدماتو مالک په وړاندې بې بنسټه شکایتونه کم کړي، لکه ورو فعالیت. د واضح SLO پرته، کاروونکي اکثرا د مطلوب فعالیت په اړه خپلې هیلې رامینځته کوي، کوم چې ممکن د خدماتو ډیزاین او اداره کولو خلکو نظرونو سره هیڅ تړاو ونلري. دا وضعیت کولی شي د خدماتو څخه د تمې لوړیدو لامل شي، کله چې کاروونکي په غلطۍ سره باور لري چې خدمت به د واقعیت په پرتله ډیر د لاسرسي وړ وي، او د بې باورۍ لامل کیږي کله چې کاروونکي باور لري چې سیسټم د هغې په پرتله لږ باوري دی.

تړونونه

د خدماتو کچې تړون ستاسو د کاروونکو سره یو څرګند یا ضمني تړون دی چې پکې د SLOs سره د لیدو (یا نه لیدو) پایلې شاملې دي. پایلې په اسانۍ سره پیژندل کیږي کله چې دوی مالي وي - تخفیف یا جریمه - مګر دوی کولی شي نور ډولونه واخلي. د SLOs او SLAs ترمنځ د توپیر په اړه د خبرو کولو یوه اسانه لار دا ده چې پوښتنه وکړئ "که چیرې SLOs پوره نه شي نو څه کیږي؟" که چیرې روښانه پایلې شتون ونلري، تاسو تقریبا یقینا د SLO په لټه کې یاست.

SRE عموما د SLAs په جوړولو کې دخیل ندي ځکه چې SLAs د سوداګرۍ او محصول پریکړو سره نږدې تړلي دي. په هرصورت، SRE د ناکام SLOs پایلو کمولو کې د مرستې کولو کې ښکیل دی. دوی کولی شي د SLI په ټاکلو کې هم مرسته وکړي: په څرګنده توګه، په تړون کې د SLO اندازه کولو لپاره باید یوه معقوله لاره وي یا اختلاف شتون ولري.

د ګوګل لټون د یو مهم خدمت یوه بیلګه ده چې عامه SLA نلري: موږ غواړو چې هرڅوک د امکان تر حده مؤثره لټون وکاروي، مګر موږ له نړۍ سره تړون نه دی لاسلیک کړی. په هرصورت، لاهم پایلې شتون لري که چیرې لټون شتون ونلري - د نه شتون پایله زموږ په شهرت کې کمښت او همدارنګه د اعلاناتو عاید کموي. د ګوګل ډیری نور خدمتونه، لکه د کار لپاره ګوګل، د کاروونکو سره د واضح خدماتو کچې تړونونه لري. پرته له دې چې یو ځانګړی خدمت SLA لري، دا مهمه ده چې SLI او SLO تعریف کړئ او د خدماتو اداره کولو لپاره یې وکاروئ.

ډیره تیوري - اوس تجربه کول.

په عمل کې شاخصونه

دې ته په پام سره چې موږ دې پایلې ته رسیدلي چې د خدماتو کچې اندازه کولو لپاره مناسب میټریکونه غوره کول مهم دي، تاسو اوس څنګه پوهیږئ چې کوم میټریک د خدمت یا سیسټم لپاره مهم دی؟

تاسو او ستاسو کاروونکي د څه په اړه پاملرنه کوي؟

تاسو اړتیا نلرئ هر میټریک د SLI په توګه وکاروئ چې تاسو کولی شئ د څارنې سیسټم کې تعقیب کړئ؛ پوهیدل چې کاروونکي د سیسټم څخه څه غواړي تاسو سره به د څو میترونو غوره کولو کې مرسته وکړي. د ډیرو شاخصونو غوره کول دا ستونزمن کوي ​​​​چې په مهمو شاخصونو تمرکز وکړي، پداسې حال کې چې د لږ شمیر غوره کول کولی شي ستاسو د سیسټم لویې برخې پریږدي. موږ عموما د سیسټم روغتیا ارزولو او پوهیدو لپاره ډیری کلیدي شاخصونه کاروو.

خدمتونه عموما د SLI په شرایطو کې په څو برخو ویشل کیدی شي چې د دوی سره تړاو لري:

• د ګمرک مخکښې پای سیسټمونه، لکه زموږ د مثال څخه د شکسپیر خدمت لپاره د لټون انٹرفیس. دوی باید شتون ولري، هیڅ ځنډ نلري او کافي بینډ ویت ولري. په دې اساس، پوښتنې کیدی شي: ایا موږ کولی شو غوښتنې ته ځواب ووایو؟ دې غوښتنې ته د ځواب ویلو لپاره څومره وخت نیولی؟ څومره غوښتنې پروسس کیدی شي؟
• د ذخیره کولو سیسټمونه. دوی د ټیټ غبرګون ځنډ، شتون، او دوام ته ارزښت ورکوي. اړوند پوښتنې: د معلوماتو لوستلو یا لیکلو لپاره څومره وخت نیسي؟ ایا موږ د غوښتنې پراساس ډیټا ته لاسرسی کولی شو؟ ایا معلومات شتون لري کله چې موږ ورته اړتیا لرو؟ د معلوماتو بشپړتیا 26 څپرکی وګورئ: هغه څه چې تاسو یې لوستل هغه څه دي چې تاسو یې د دې مسلو د مفصل بحث لپاره لیکئ.
• د لوی ډیټا سیسټمونه لکه د ډیټا پروسس کولو پایپ لاینونه د ټرپوټ او پوښتنو پروسس کولو ځنډ باندې تکیه کوي. اړونده پوښتنې: څومره معلومات پروسس کیږي؟ د غوښتنې ترلاسه کولو څخه د ځواب صادرولو پورې د معلوماتو سفر څومره وخت نیسي؟ (د سیسټم ځینې برخې ممکن په ځینو مرحلو کې ځنډ هم ولري.)

د شاخصونو راټولول

د خدماتو ډیری شاخصونه په طبیعي ډول د سرور اړخ کې راټول شوي، د څارنې سیسټم کاروي لکه بورګمون (لاندې وګورئ). څپرکی 10 د وخت لړۍ ډیټا پراساس خبرتیاوې تمرین کړئ) یا پرومیتیوس، یا په ساده ډول د لاګونو تحلیل کول، د HTTP ځوابونه د 500 حالت سره پیژندل. په هرصورت، ځینې سیسټمونه باید د مراجعینو اړخ میټریک راټولولو سره سمبال شي، ځکه چې د مراجعینو اړخ نظارت نشتوالی کولی شي د یو شمیر ستونزو د ورکیدو لامل شي چې اغیزه کوي. کاروونکي، مګر د سرور اړخ میټریک اغیزه نه کوي. د مثال په توګه، زموږ د شکسپیر لټون ازموینې غوښتنلیک د شاته ځواب ځنډ باندې تمرکز کول ممکن د جاواسکریپټ مسلو له امله د کارونکي اړخ کې د ځنډ لامل شي: پدې حالت کې ، دا اندازه کول چې براوزر د پاڼې پروسس کولو لپاره څومره وخت نیسي یو غوره میټریک دی.

جمع کول

د سادګۍ او کارونې اسانتیا لپاره، موږ ډیری وختونه خام اندازه راټولوو. دا باید په احتیاط سره ترسره شي.

ځینې ​​​​میټریکونه ساده ښکاري، لکه په هره ثانیه کې غوښتنې، مګر حتی دا په ښکاره توګه مستقیم اندازه اندازه د وخت په تیریدو سره په ښکاره ډول ډاټا راټولوي. ایا اندازه کول په ځانګړي ډول په یوه ثانیه کې یو ځل ترلاسه کیږي یا اندازه کول په یوه دقیقه کې د غوښتنو په شمیر کې اوسط دی؟ وروستی اختیار کولی شي د غوښتنې خورا لوړ فوري شمیر پټ کړي چې یوازې څو ثانیې دوام کوي. یو سیسټم په پام کې ونیسئ چې په هره ثانیه کې 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 څه معنی لري.

په عمل کې موخې

د هغه څه په اړه فکر کولو سره پیل کړئ (یا معلوم کړئ!) ستاسو کاروونکي د هغه څه په اړه فکر کوي چې تاسو یې اندازه کولی شئ. ډیری وختونه هغه څه چې ستاسو کاروونکي یې په اړه پاملرنه کوي اندازه کول ستونزمن یا ناممکن دي، نو تاسو د دوی اړتیاو ته نږدې شئ. په هرصورت، که تاسو یوازې د هغه څه سره پیل کړئ چې اندازه کول اسانه دي، تاسو به د لږ ګټور SLO سره پای ته ورسیږئ. د پایلې په توګه، موږ ځینې وختونه موندلي چې په پیل کې د مطلوب اهدافو پیژندل او بیا د ځانګړو شاخصونو سره کار کول د شاخصونو غوره کولو او بیا اهدافو ترلاسه کولو څخه غوره کار کوي.

اهداف تعریف کړئ

د اعظمي وضاحت لپاره، دا باید تعریف شي چې SLOs څنګه اندازه کیږي او کوم شرایط چې لاندې یې اعتبار لري. د مثال په توګه، موږ کولی شو لاندې ووایو (دویمه کرښه د لومړي سره ورته ده، مګر د SLI ډیفالټ کاروي):

• 99٪ (په اوسط ډول د 1 دقیقې څخه ډیر) د RPC تلیفونونو ترلاسه کول به له 100ms څخه په کم وخت کې بشپړ شي (په ټولو پس منظر سرورونو کې اندازه کیږي).
• د RPC زنګونو ترلاسه کولو 99٪ به له 100ms څخه لږ وخت کې بشپړ شي.

که د فعالیت منحنی شکل مهم وي، تاسو کولی شئ ډیری SLOs مشخص کړئ:

• د RPC تلیفونونو 90٪ له 1 ms څخه په کم وخت کې بشپړ شوي.
• د RPC تلیفونونو 99٪ له 10 ms څخه په کم وخت کې بشپړ شوي.
• د RPC تلیفونونو 99.9٪ له 100 ms څخه په کم وخت کې بشپړ شوي.

که ستاسو کاروونکي متضاد کاري بارونه رامینځته کړي: لوی پروسس کول (د کوم لپاره چې له لارې مهم دی) او متقابل پروسس کول (د کوم لپاره چې ځنډ مهم دی) ، دا ممکن د هر بار ټولګي لپاره جلا اهداف تعریف کړي:

• د پیرودونکو غوښتنې 95٪ د ټرپټ ته اړتیا لري. د اجرا شوي RPC کالونو شمیره ترتیب کړئ <1 s.
• 99٪ پیرودونکي د ځنډ په اړه پاملرنه کوي. د ټرافیک <1 KB او چلولو <10 ms سره د RPC تلیفونونو شمیره تنظیم کړئ.

دا غیر واقعیتي او ناغوښتل دي چې ټینګار وکړي چې SLOs به د وخت 100٪ پوره شي: دا کولی شي د نوي فعالیت او پلي کولو سرعت کم کړي، او ګران حلونو ته اړتیا لري. پرځای یې، دا غوره ده چې د غلطې بودیجې ته اجازه ورکړئ - د سیسټم د ځنډولو فیصده اجازه ورکړل شوې - او دا ارزښت هره ورځ یا اونۍ وڅارئ. لوړ مدیریت ممکن میاشتني یا درې میاشتنۍ ارزونه وغواړي. (د خطا بودیجه د بل SLO سره پرتله کولو لپاره په ساده ډول یو SLO دی.)

د SLO سرغړونو سلنه د غلطې بودیجې سره پرتله کیدی شي (درېیم څپرکی او برخه وګورئ "د تېروتنې بودیجې لپاره هڅونه")، د توپیر ارزښت سره چې پروسې ته د ننوتلو په توګه کارول کیږي چې پریکړه کوي کله چې نوي ریلیزونه ځای په ځای کړي.

د هدف ارزښتونو غوره کول

د پلان جوړونې ارزښتونو (SLOs) غوره کول خالص تخنیکي فعالیت نه دی ځکه چې د محصول او سوداګریزو ګټو له مخې باید په ټاکل شوي SLIs، SLOs (او احتمالا SLAs) کې منعکس شي. په ورته ډول، معلومات ممکن د کارمندانو، بازار ته د وخت، د تجهیزاتو شتون، او تمویل پورې اړوند مسلو په اړه تبادله ته اړتیا ولري. SRE باید د دې خبرو اترو برخه وي او د مختلف انتخابونو خطرونو او وړتیا په پوهیدو کې مرسته وکړي. موږ د یو څو پوښتنو سره راغلي یو چې ممکن د لا ګټور بحث ډاډ ترلاسه کولو کې مرسته وکړي:

د اوسني فعالیت پر بنسټ هدف مه ټاکئ.
پداسې حال کې چې د سیسټم پیاوړتیا او محدودیتونو پوهیدل مهم دي، د استدلال پرته د میټریکونو تطبیق کولی شي تاسو د سیسټم ساتلو مخه ونیسي: دا به د اهدافو ترلاسه کولو لپاره زړور هڅو ته اړتیا ولري چې د پام وړ بیا ډیزاین پرته نشي ترلاسه کیدی.

دا ساده وساتئ
پیچلي SLI محاسبې کولی شي د سیسټم فعالیت کې بدلونونه پټ کړي او د ستونزې لامل موندل ګران کړي.

د مطلق څخه ډډه وکړئ
پداسې حال کې چې دا د داسې سیسټم درلودلو لپاره لیوالتیا ده چې کولی شي د ځنډ زیاتوالي پرته د نامعلوم وخت لپاره مخ په زیاتیدونکي بار اداره کړي ، دا اړتیا غیر واقعیت لري. یو سیسټم چې دا ډول نظریاتو ته نږدې کیږي احتمال به د ډیزاین او جوړولو لپاره ډیر وخت ته اړتیا ولري، د چلولو لپاره به ګران وي، او د کاروونکو توقعاتو لپاره به خورا ښه وي څوک چې لږ څه وکړي.

د امکان تر حده لږ SLO وکاروئ
د سیسټم ځانګړتیاو ښه پوښښ یقیني کولو لپاره د کافي شمیر SLOs غوره کړئ. هغه SLOs خوندي کړئ چې تاسو یې غوره کوئ: که تاسو هیڅکله د یو ځانګړي 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