SRE (مهندسی قابلیت اطمینان سایت) رویکردی برای دسترسی به پروژه های وب است. این یک چارچوب برای DevOps در نظر گرفته می شود و نحوه موفقیت در استفاده از شیوه های DevOps را می گوید. این مقاله ترجمه می کند فصل 4 اهداف سطح خدمات کتاب مهندسی قابلیت اطمینان سایت از گوگل من خودم این ترجمه را تهیه کردم و به تجربه خودم در درک فرآیندهای نظارت تکیه کردم. در کانال تلگرام monitorim_it и آخرین پست در هابره من همچنین ترجمه فصل 6 همین کتاب را درباره اهداف سطح خدمات منتشر کردم.

ترجمه گربه. از خواندن لذت ببرید!

اگر درک درستی از اینکه چه شاخص هایی واقعا مهم هستند و چگونه می توان آنها را اندازه گیری و ارزیابی کرد، مدیریت یک سرویس غیرممکن است. برای این منظور، ما بدون توجه به اینکه از یکی از APIهای داخلی ما استفاده می کنند یا یک محصول عمومی، سطح مشخصی از خدمات را به کاربران خود تعریف و ارائه می کنیم.

ما از شهود، تجربه و درک خود از تمایل کاربران برای درک شاخص‌های سطح خدمات (SLIs)، اهداف سطح خدمات (SLO) و توافق‌نامه‌های سطح خدمات (SLA) استفاده می‌کنیم. این ابعاد معیارهای اصلی را توصیف می‌کنند که می‌خواهیم نظارت کنیم و اگر نتوانیم کیفیت خدمات مورد انتظار را ارائه کنیم، به آنها واکنش نشان خواهیم داد. در نهایت، انتخاب معیارهای مناسب به هدایت اقدامات صحیح در صورت بروز مشکل کمک می کند و همچنین به تیم SRE در سلامت سرویس اطمینان می دهد.

این فصل رویکردی را که ما برای مبارزه با مشکلات مدل‌سازی متریک، انتخاب متریک و تحلیل متریک استفاده می‌کنیم، توضیح می‌دهد. بیشتر توضیحات بدون مثال خواهد بود، بنابراین ما از سرویس شکسپیر که در مثال اجرایی آن (جستجوی آثار شکسپیر) توضیح داده شده است، برای توضیح نکات اصلی استفاده خواهیم کرد.

اصطلاحات سطح خدمات

بسیاری از خوانندگان احتمالاً با مفهوم SLA آشنا هستند، اما اصطلاحات SLI و SLO سزاوار تعریف دقیق هستند زیرا به طور کلی اصطلاح SLA بیش از حد بارگذاری شده است و بسته به زمینه دارای تعدادی معانی است. برای وضوح، می خواهیم این مقادیر را از هم جدا کنیم.

شاخص

SLI یک شاخص سطح خدمات است - یک معیار کمی که با دقت تعریف شده از یک جنبه از سطح خدمات ارائه شده است.

برای اکثر سرویس‌ها، کلید SLI به عنوان تأخیر درخواست در نظر گرفته می‌شود - چه مدت طول می‌کشد تا یک پاسخ به یک درخواست بازگردانده شود. سایر SLIهای رایج عبارتند از نرخ خطا که اغلب به صورت کسری از تمام درخواست های دریافتی بیان می شود و توان عملیاتی سیستم که معمولاً بر حسب درخواست در ثانیه اندازه گیری می شود. اندازه‌گیری‌ها اغلب تجمیع می‌شوند: داده‌های خام ابتدا جمع‌آوری می‌شوند و سپس به نرخ تغییر، میانگین یا صدک تبدیل می‌شوند.

در حالت ایده‌آل، SLI مستقیماً سطح خدمات مورد علاقه را اندازه‌گیری می‌کند، اما گاهی اوقات فقط یک متریک مرتبط برای اندازه‌گیری در دسترس است، زیرا به‌دست آوردن یا تفسیر متریک اصلی دشوار است. به عنوان مثال، تأخیر سمت مشتری اغلب معیار مناسب تری است، اما مواقعی وجود دارد که تأخیر را فقط می توان در سرور اندازه گیری کرد.

نوع دیگری از SLI که برای SRE ها مهم است، در دسترس بودن یا بخشی از زمانی است که در طی آن می توان از یک سرویس استفاده کرد. اغلب به عنوان نرخ درخواست های موفق تعریف می شود که گاهی اوقات بازده نامیده می شود. (طول عمر - احتمال اینکه داده ها برای مدت زمان طولانی حفظ شوند - برای سیستم های ذخیره سازی داده ها نیز مهم است.) اگرچه 100٪ در دسترس بودن امکان پذیر نیست، دسترسی نزدیک به 100٪ اغلب قابل دستیابی است؛ مقادیر در دسترس بودن به صورت بیان می شود. تعداد "نه" » درصد در دسترس بودن. به عنوان مثال، 99٪ و 99,999٪ در دسترس بودن ممکن است به عنوان "2 نه" و "5 نه" برچسب گذاری شود. هدف فعلی اعلام شده Google Compute Engine در دسترس بودن "سه و نیم نه" یا 99,95٪ است.

اهداف

SLO یک هدف سطح خدمات است: یک مقدار هدف یا محدوده ای از مقادیر برای یک سطح خدمات که توسط SLI اندازه گیری می شود. یک مقدار نرمال برای SLO "SLI ≤ Target" یا "Low Limit ≤ SLI ≤ Upper Limit" است. برای مثال، ممکن است تصمیم بگیریم که نتایج جستجوی شکسپیر را «سریع» با تنظیم SLO روی متوسط ​​تأخیر جستجوی کمتر از 100 میلی ثانیه برگردانیم.

انتخاب SLO مناسب یک فرآیند پیچیده است. اولا، شما همیشه نمی توانید یک مقدار خاص را انتخاب کنید. برای درخواست‌های HTTP ورودی خارجی به سرویس شما، معیار Query Per Second (QPS) در درجه اول با تمایل کاربران شما برای بازدید از سرویس شما تعیین می‌شود و شما نمی‌توانید SLO برای آن تعیین کنید.

از طرف دیگر می توانید بگویید که می خواهید میانگین تاخیر برای هر درخواست کمتر از 100 میلی ثانیه باشد. تعیین چنین هدفی ممکن است شما را مجبور کند که ظاهر خود را با تاخیر کم بنویسید یا تجهیزاتی را بخرید که چنین تاخیری را فراهم می کند. (بدیهی است 100 میلی ثانیه یک عدد دلخواه است، اما بهتر است اعداد تاخیر کمتری داشته باشند. شواهدی وجود دارد که نشان می دهد سرعت های سریع بهتر از سرعت های آهسته هستند و تاخیر در پردازش درخواست های کاربران بالاتر از مقادیر خاص در واقع افراد را مجبور می کند که از آنها دوری کنند. خدمت شما.)

باز هم، این مبهم‌تر از آن چیزی است که در نگاه اول به نظر می‌رسد: شما نباید QPS را به طور کامل از محاسبه حذف کنید. واقعیت این است که QPS و تأخیر به شدت با یکدیگر مرتبط هستند: QPS بالاتر اغلب منجر به تأخیر بالاتر می‌شود و سرویس‌ها معمولاً با رسیدن به آستانه بار مشخصی کاهش شدید عملکرد را تجربه می‌کنند.

انتخاب و انتشار SLO انتظارات کاربر را در مورد نحوه عملکرد سرویس تعیین می کند. این استراتژی می‌تواند شکایات بی‌اساس علیه مالک سرویس مانند عملکرد کند را کاهش دهد. بدون SLO صریح، کاربران اغلب انتظارات خود را در مورد عملکرد مورد نظر ایجاد می کنند، که ممکن است هیچ ارتباطی با نظرات افرادی که خدمات را طراحی و مدیریت می کنند نداشته باشد. این وضعیت می‌تواند منجر به افزایش انتظارات از سرویس شود، زمانی که کاربران به اشتباه فکر می‌کنند که سرویس از آنچه که هست در دسترس‌تر خواهد بود و زمانی که کاربران معتقدند سیستم کمتر از آنچه که هست قابل اعتمادتر است، باعث بی‌اعتمادی شود.

توافقات

قرارداد سطح خدمات یک قرارداد صریح یا ضمنی با کاربران شما است که شامل عواقب ملاقات (یا عدم ملاقات) SLOهای موجود در آنها می‌شود. عواقب به راحتی زمانی قابل تشخیص هستند که مالی باشند - تخفیف یا جریمه - اما می توانند اشکال دیگری داشته باشند. یک راه آسان برای صحبت در مورد تفاوت بین SLO و SLA این است که بپرسید "اگر SLO ها برآورده نشوند چه اتفاقی می افتد؟" اگر هیچ عواقب واضحی وجود نداشته باشد، تقریباً مطمئناً به SLO نگاه می کنید.

SRE معمولاً در ایجاد SLA ها دخالتی ندارد زیرا SLA ها ارتباط نزدیکی با تصمیمات تجاری و محصول دارند. با این حال، SRE در کمک به کاهش عواقب SLO های ناموفق نقش دارد. آنها همچنین می توانند به تعیین SLI کمک کنند: بدیهی است که باید یک روش عینی برای اندازه گیری SLO در توافق وجود داشته باشد وگرنه اختلاف نظر وجود خواهد داشت.

جستجوی گوگل نمونه‌ای از سرویس مهمی است که SLA عمومی ندارد: ما می‌خواهیم همه تا حد امکان از جستجو استفاده کنند، اما قراردادی با دنیا امضا نکرده‌ایم. با این حال، اگر جستجو در دسترس نباشد، همچنان عواقبی وجود دارد - در دسترس نبودن منجر به کاهش شهرت و همچنین کاهش درآمد تبلیغاتی می شود. بسیاری از سرویس‌های دیگر Google، مانند Google for Work، قراردادهای سطح خدمات صریح با کاربران دارند. صرف نظر از اینکه یک سرویس خاص دارای SLA است یا خیر، مهم است که SLI و SLO را تعریف کرده و از آنها برای مدیریت سرویس استفاده کنید.

تئوری بسیار زیادی - اکنون برای تجربه.

شاخص ها در عمل

با توجه به اینکه ما به این نتیجه رسیده‌ایم که انتخاب معیارهای مناسب برای اندازه‌گیری سطح خدمات مهم است، اکنون چگونه می‌دانید که کدام معیارها برای یک سرویس یا سیستم مهم هستند؟

شما و کاربرانتان به چه چیزی اهمیت می دهید؟

شما نیازی به استفاده از هر معیاری به عنوان SLI ندارید که بتوانید آن را در یک سیستم نظارتی ردیابی کنید. درک آنچه کاربران از یک سیستم می خواهند به شما کمک می کند چندین معیار را انتخاب کنید. انتخاب بیش از حد اندیکاتورها تمرکز بر روی شاخص های مهم را دشوار می کند، در حالی که انتخاب تعداد کم می تواند بخش های بزرگی از سیستم شما را رها کند. ما معمولاً از چندین شاخص کلیدی برای ارزیابی و درک سلامت یک سیستم استفاده می کنیم.

به طور کلی می توان خدمات را از نظر SLI به چندین بخش تقسیم کرد که به آنها مربوط می شود:

• سیستم‌های فرانت‌اند سفارشی، مانند رابط‌های جستجو برای سرویس شکسپیر از مثال ما. آنها باید در دسترس باشند، تاخیر نداشته باشند و پهنای باند کافی داشته باشند. بر این اساس، می توان سؤالاتی پرسید: آیا می توانیم به درخواست پاسخ دهیم؟ چه مدت طول کشید تا به درخواست پاسخ داده شود؟ چند درخواست قابل پردازش است؟
• سیستم های ذخیره سازی آنها برای تأخیر پاسخ کم، در دسترس بودن و دوام ارزش قائل هستند. سوالات مرتبط: خواندن یا نوشتن داده ها چقدر طول می کشد؟ آیا می توانیم در صورت درخواست به داده ها دسترسی داشته باشیم؟ آیا داده ها زمانی که به آن نیاز داریم در دسترس است؟ برای بحث مفصل درباره این مسائل به فصل 26 یکپارچگی داده ها مراجعه کنید: آنچه می خوانید همان چیزی است که می نویسید.
• سیستم‌های کلان داده مانند خطوط لوله پردازش داده به تاخیر پردازش و پرس و جو متکی هستند. سوالات مرتبط: چه مقدار داده پردازش می شود؟ از دریافت درخواست تا صدور پاسخ چقدر طول می کشد تا داده ها طی شوند؟ (برخی از قسمت های سیستم نیز ممکن است در مراحل خاصی دارای تاخیر باشند.)

مجموعه شاخص ها

بسیاری از شاخص های سطح خدمات به طور طبیعی در سمت سرور با استفاده از یک سیستم نظارتی مانند Borgmon جمع آوری می شوند (به زیر مراجعه کنید). فصل 10 هشدارها را بر اساس داده‌های سری زمانی تمرین کنید) یا Prometheus، یا به سادگی تجزیه و تحلیل دوره‌ای گزارش‌ها، شناسایی پاسخ‌های HTTP با وضعیت 500. با این حال، برخی از سیستم‌ها باید به مجموعه معیارهای سمت مشتری مجهز شوند، زیرا فقدان نظارت از سمت مشتری می‌تواند منجر به از دست دادن تعدادی از مشکلات شود که بر آن تأثیر می‌گذارد. کاربران، اما معیارهای سمت سرور را تحت تأثیر قرار نمی دهند. به عنوان مثال، تمرکز بر تأخیر پاسخ پشتیبان برنامه آزمایشی جستجوی شکسپیر ما ممکن است به دلیل مشکلات جاوا اسکریپت منجر به تأخیر در سمت کاربر شود: در این مورد، اندازه‌گیری مدت زمانی که مرورگر برای پردازش صفحه طول می‌کشد معیار بهتری است.

تجمع

برای سادگی و سهولت استفاده، ما اغلب اندازه گیری های خام را جمع آوری می کنیم. این باید با دقت انجام شود.

برخی از معیارها، مانند درخواست در ثانیه، ساده به نظر می رسند، اما حتی این اندازه گیری به ظاهر ساده به طور ضمنی داده ها را در طول زمان جمع می کند. آیا اندازه گیری به طور خاص یک بار در ثانیه دریافت می شود یا میانگین اندازه گیری بر روی تعداد درخواست ها در دقیقه است؟ گزینه دوم می تواند تعداد بسیار بالاتری از درخواست ها را که فقط چند ثانیه طول می کشد پنهان کند. سیستمی را در نظر بگیرید که 200 درخواست در ثانیه با اعداد زوج و 0 در بقیه زمان ها ارائه می دهد. ثابت به صورت مقدار متوسط ​​100 درخواست در ثانیه و دو برابر بار آنی یک چیز نیستند. به طور مشابه، متوسط ​​تأخیرهای پرس و جو ممکن است جذاب به نظر برسد، اما یک جزئیات مهم را پنهان می کند: ممکن است که اکثر پرس و جوها سریع باشند، اما بسیاری از پرس و جوها کند هستند.

بیشتر شاخص ها به جای میانگین، بهتر به عنوان توزیع در نظر گرفته می شوند. به عنوان مثال، برای تأخیر SLI، برخی از درخواست‌ها به سرعت پردازش می‌شوند، در حالی که برخی از آنها همیشه بیشتر طول می‌کشد، گاهی اوقات بسیار بیشتر. یک میانگین ساده می تواند این تاخیرهای طولانی را پنهان کند. شکل یک مثال را نشان می دهد: اگرچه یک درخواست معمولی تقریباً 50 میلی ثانیه طول می کشد تا ارائه شود، 5٪ از درخواست ها 20 برابر کندتر هستند! نظارت و هشدار فقط بر اساس تأخیر متوسط، تغییراتی را در رفتار در طول روز نشان نمی دهد، در حالی که در واقع تغییرات محسوسی در زمان پردازش برخی از درخواست ها (بالاترین خط) وجود دارد.

تأخیر سیستم صدک 50، 85، 95 و 99. محور Y در قالب لگاریتمی است.

استفاده از صدک‌ها برای شاخص‌ها به شما امکان می‌دهد شکل توزیع و ویژگی‌های آن را ببینید: یک سطح صدک بالا، مانند 99 یا 99,9، بدترین مقدار را نشان می‌دهد، در حالی که صدک 50 (همچنین به عنوان میانه شناخته می‌شود) بیشترین حالت را نشان می‌دهد. متریک هرچه پراکندگی زمان پاسخ بیشتر باشد، درخواست‌های طولانی‌مدت بیشتری بر تجربه کاربر تأثیر می‌گذارند. اثر تحت بار زیاد و در حضور صف افزایش می یابد. تحقیقات تجربه کاربر نشان داده است که مردم عموماً سیستم کندتر با واریانس زمان پاسخگویی بالا را ترجیح می دهند، بنابراین برخی از تیم های SRE فقط بر نمرات صدک بالا تمرکز می کنند، بر این اساس که اگر رفتار یک معیار در صدک 99,9 خوب باشد، اکثر کاربران مشکلی را تجربه نخواهند کرد. .

توجه به خطاهای آماری

ما معمولاً ترجیح می‌دهیم با صدک‌ها کار کنیم تا میانگین (میانگین حسابی) مجموعه‌ای از مقادیر. این به ما امکان می دهد مقادیر پراکنده بیشتری را در نظر بگیریم، که اغلب دارای ویژگی های قابل توجهی متفاوت (و جالب تر) نسبت به میانگین هستند. با توجه به ماهیت مصنوعی سیستم‌های محاسباتی، مقادیر متریک اغلب منحرف می‌شوند، به طوری که هیچ درخواستی نمی‌تواند در کمتر از 0 میلی‌ثانیه پاسخی دریافت کند، و مهلت زمانی 1000 میلی‌ثانیه به این معنی است که نمی‌توان پاسخ‌های موفقی با مقادیر بیشتر از آن داشت. تایم اوت در نتیجه نمی توانیم بپذیریم که میانگین و میانه می توانند یکسان یا نزدیک به هم باشند!

بدون آزمایش قبلی، و مگر اینکه برخی از مفروضات و تقریب های استاندارد وجود داشته باشد، ما مراقب هستیم که نتیجه نگیریم که داده های ما به طور معمول توزیع شده اند. اگر توزیع آنطور که انتظار می رود نباشد، فرآیند اتوماسیونی که مشکل را برطرف می کند (به عنوان مثال، زمانی که موارد پرت را می بیند، سرور را با تاخیرهای پردازش درخواست بالا راه اندازی مجدد می کند) ممکن است این کار را اغلب یا به اندازه کافی انجام نمی دهد (که هر دوی اینها نیستند. خیلی خوب).

استاندارد کردن شاخص ها

توصیه می کنیم ویژگی های کلی SLI را استاندارد کنید تا مجبور نباشید هر بار در مورد آنها حدس و گمان بزنید. هر ویژگی که الگوهای استاندارد را برآورده کند ممکن است از مشخصات یک SLI منفرد حذف شود، به عنوان مثال:

• فواصل تجمع: "به طور متوسط ​​بیش از 1 دقیقه"
• مناطق تجمع: "همه وظایف در خوشه"
• تعداد دفعات اندازه گیری: "هر 10 ثانیه"
• چه درخواست هایی شامل می شود: "HTTP GET from the black box monitoring jobs"
• چگونه داده ها به دست می آیند: "با تشکر از نظارت ما بر روی سرور"
• تأخیر دسترسی به داده: "زمان تا آخرین بایت"

برای صرفه جویی در تلاش، مجموعه ای از الگوهای SLI قابل استفاده مجدد برای هر معیار رایج ایجاد کنید. آنها همچنین درک معنای SLI خاص را برای همه آسان تر می کنند.

اهداف در عمل

با فکر کردن (یا پیدا کردن!) در مورد آنچه کاربران شما به آن اهمیت می دهند، شروع کنید، نه آنچه را که می توانید اندازه گیری کنید. اغلب اندازه گیری آنچه کاربران شما به آن اهمیت می دهند دشوار یا غیرممکن است، بنابراین در نهایت به نیازهای آنها نزدیک می شوید. با این حال، اگر فقط با چیزهایی که اندازه گیری آسان است شروع کنید، در نهایت به SLO های کمتر مفیدی خواهید رسید. در نتیجه گاهی متوجه شده ایم که ابتدا شناسایی اهداف مورد نظر و سپس کار با شاخص های خاص بهتر از انتخاب شاخص ها و سپس دستیابی به اهداف است.

اهداف خود را مشخص کنید

برای وضوح حداکثر، باید نحوه اندازه‌گیری SLO و شرایطی که تحت آن معتبر هستند، تعریف شود. به عنوان مثال، می توانیم موارد زیر را بگوییم (خط دوم همان خط اول است، اما از پیش فرض های SLI استفاده می کند):

• 99٪ (به طور متوسط ​​بیش از 1 دقیقه) از تماس های Get RPC در کمتر از 100 میلی ثانیه (در همه سرورهای باطن اندازه گیری می شود) تکمیل می شود.
• 99٪ تماس های Get RPC در کمتر از 100 میلی ثانیه تکمیل می شود.

اگر شکل منحنی های عملکرد مهم است، می توانید چندین SLO را مشخص کنید:

• 90٪ از تماس های Get RPC در کمتر از 1 میلی ثانیه انجام می شود.
• 99٪ از تماس های Get RPC در کمتر از 10 میلی ثانیه انجام می شود.
• 99.9٪ از تماس های Get RPC در کمتر از 100 میلی ثانیه انجام می شود.

اگر کاربران شما بارهای کاری ناهمگن تولید می کنند: پردازش انبوه (که توان عملیاتی آن مهم است) و پردازش تعاملی (که تأخیر برای آن مهم است)، ممکن است ارزشمند باشد که اهداف جداگانه ای برای هر کلاس بار تعریف کنید:

• 95 درصد از درخواست های مشتری نیاز به توان عملیاتی دارند. تعداد تماس های RPC اجرا شده را <1 ثانیه تنظیم کنید.
• 99 درصد از مشتریان به تأخیر اهمیت می دهند. تعداد تماس های RPC را با ترافیک <1 کیلوبایت و در حال اجرا <10 میلی ثانیه تنظیم کنید.

این غیرواقعی و نامطلوب است که اصرار کنیم که SLO ها در 100% موارد برآورده شوند: این می تواند سرعت معرفی عملکرد و استقرار جدید را کاهش دهد و به راه حل های گران قیمت نیاز دارد. در عوض، بهتر است بودجه خطا را مجاز کنید - درصدی از زمان توقف مجاز سیستم - و این مقدار را روزانه یا هفتگی کنترل کنید. مدیریت ارشد ممکن است خواهان ارزیابی ماهانه یا فصلی باشد. (بودجه خطا به سادگی یک SLO برای مقایسه با SLO دیگر است.)

درصد تخلفات SLO را می توان با بودجه خطا مقایسه کرد (به فصل 3 و بخش مراجعه کنید "انگیزه برای بودجه های خطا")، با مقدار تفاوت به عنوان ورودی فرآیند که تصمیم می‌گیرد چه زمانی نسخه‌های جدید را استقرار کند، استفاده می‌شود.

انتخاب مقادیر هدف

انتخاب ارزش‌های برنامه‌ریزی (SLO) یک فعالیت صرفاً فنی نیست، زیرا محصول و منافع تجاری باید در SLIs، SLO (و احتمالاً SLA) انتخاب شده منعکس شود. به همین ترتیب، ممکن است نیاز به تبادل اطلاعات در مورد مسائل مربوط به کارکنان، زمان ورود به بازار، در دسترس بودن تجهیزات و تامین مالی باشد. SRE باید بخشی از این گفتگو باشد و به درک خطرات و قابلیت دوام گزینه های مختلف کمک کند. ما با چند سوال مواجه شده‌ایم که ممکن است به اطمینان از بحث سازنده‌تر کمک کند:

هدفی را بر اساس عملکرد فعلی انتخاب نکنید.
در حالی که درک نقاط قوت و محدودیت های یک سیستم مهم است، انطباق معیارها بدون استدلال می تواند شما را از حفظ سیستم باز دارد: برای دستیابی به اهدافی که بدون طراحی مجدد قابل توجه نمی توان به آنها دست یافت، به تلاش های قهرمانانه نیاز دارد.

ساده باش
محاسبات پیچیده SLI می تواند تغییرات در عملکرد سیستم را پنهان کند و یافتن علت مشکل را دشوارتر کند.

از مطلق پرهیز کنید
در حالی که داشتن سیستمی وسوسه انگیز است که بتواند بار در حال رشد را بدون افزایش تأخیر تحمل کند، این نیاز غیر واقعی است. سیستمی که به چنین ایده‌آل‌هایی نزدیک می‌شود، احتمالاً به زمان زیادی برای طراحی و ساخت نیاز خواهد داشت، کارکرد آن پرهزینه است، و برای انتظارات کاربرانی که با هر چیزی کمتر انجام می‌دهند، بسیار خوب خواهد بود.

تا حد امکان از SLO های کمتری استفاده کنید
تعداد کافی SLO را برای اطمینان از پوشش خوب ویژگی های سیستم انتخاب کنید. از SLOهایی که انتخاب می‌کنید محافظت کنید: اگر هرگز نمی‌توانید با تعیین یک SLO خاص در بحثی در مورد اولویت‌ها پیروز شوید، احتمالاً ارزش در نظر گرفتن آن SLO را ندارد. با این حال، همه ویژگی های سیستم برای SLO ها قابل قبول نیستند: محاسبه سطح لذت کاربر با استفاده از SLO دشوار است.

دنبال کمال نباش
شما همیشه می توانید تعاریف و اهداف SLO ها را در طول زمان اصلاح کنید و در مورد رفتار سیستم تحت بار اطلاعات بیشتری کسب کنید. بهتر است با یک هدف شناور شروع کنید که به مرور زمان آن را اصلاح خواهید کرد تا اینکه یک هدف بیش از حد سختگیرانه را انتخاب کنید که وقتی می بینید که دست نیافتنی است باید آرام باشید.

SLOها می توانند و باید یک محرک کلیدی در اولویت بندی کار برای SREها و توسعه دهندگان محصول باشند، زیرا آنها منعکس کننده نگرانی کاربران هستند. یک SLO خوب یک ابزار اجرایی مفید برای یک تیم توسعه است. اما یک SLO با طراحی ضعیف می‌تواند منجر به کار بیهوده شود، اگر تیم تلاش‌های قهرمانانه برای دستیابی به SLO بیش از حد تهاجمی انجام دهد، یا اگر SLO خیلی پایین باشد، محصول ضعیفی داشته باشد. SLO یک اهرم قدرتمند است، از آن عاقلانه استفاده کنید.

اندازه گیری های خود را کنترل کنید

SLI و SLO عناصر کلیدی مورد استفاده برای مدیریت سیستم ها هستند:

• نظارت و اندازه گیری سیستم های SLI.
• SLI را با SLO مقایسه کنید و تصمیم بگیرید که آیا اقدامی لازم است یا خیر.
• اگر اقدامی لازم است، بفهمید برای رسیدن به هدف چه اتفاقی باید بیفتد.
• این عمل را کامل کنید.

به عنوان مثال، اگر مرحله 2 نشان می دهد که درخواست در حال اتمام است و اگر کاری انجام نشود ظرف چند ساعت SLO را می شکند، مرحله 3 ممکن است شامل آزمایش این فرضیه باشد که سرورها محدود به CPU هستند و افزودن سرورهای بیشتر بار را توزیع می کند. بدون SLO، نمی دانید که آیا (یا چه زمانی) اقدامی انجام دهید.

تنظیم SLO - سپس انتظارات کاربر تنظیم خواهد شد
انتشار SLO انتظارات کاربر را برای رفتار سیستم تعیین می کند. کاربران (و کاربران بالقوه) اغلب می خواهند بدانند که از یک سرویس چه انتظاری دارند تا بفهمند که آیا برای استفاده مناسب است یا خیر. به عنوان مثال، افرادی که مایل به استفاده از یک وب‌سایت اشتراک‌گذاری عکس هستند، ممکن است بخواهند از استفاده از سرویسی که طول عمر و هزینه کم را در ازای در دسترس بودن کمی کمتر می‌دهد، اجتناب کنند، حتی اگر همان سرویس برای یک سیستم مدیریت سوابق بایگانی ایده‌آل باشد.

برای ایجاد انتظارات واقع بینانه برای کاربران خود، از یک یا هر دو تاکتیک زیر استفاده کنید:

• حاشیه ایمنی را حفظ کنید. از یک SLO داخلی سختگیرانه تر از آنچه برای کاربران تبلیغ می شود استفاده کنید. این به شما این فرصت را می دهد که قبل از اینکه مشکلات در خارج قابل مشاهده باشند، به آنها واکنش نشان دهید. بافر SLO همچنین به شما این امکان را می‌دهد که هنگام نصب نسخه‌هایی که بر عملکرد سیستم تأثیر می‌گذارند، حاشیه ایمنی داشته باشید و اطمینان حاصل کنید که نگهداری از سیستم آسان است بدون اینکه نیازی به ناامید کردن کاربران به دلیل خرابی باشد.
• از انتظارات کاربر فراتر نروید. کاربران بر اساس آنچه شما ارائه می دهید، نه آنچه شما می گویید. اگر عملکرد واقعی سرویس شما بسیار بهتر از SLO اعلام شده باشد، کاربران بر عملکرد فعلی تکیه خواهند کرد. شما می توانید با خاموش کردن عمدی سیستم یا محدود کردن عملکرد تحت بارهای سبک از وابستگی بیش از حد جلوگیری کنید.

درک اینکه یک سیستم چقدر انتظارات را برآورده می کند، به تصمیم گیری در مورد سرمایه گذاری در افزایش سرعت سیستم و قابل دسترس تر کردن و انعطاف پذیرتر کردن آن کمک می کند. از طرف دیگر، اگر خدماتی خیلی خوب عمل می کند، مقداری از زمان کارکنان باید صرف اولویت های دیگر شود، مانند پرداخت بدهی فنی، افزودن ویژگی های جدید، یا معرفی محصولات جدید.

توافقات در عمل

ایجاد SLA مستلزم آن است که تیم های تجاری و حقوقی عواقب و مجازات های نقض آن را تعریف کنند. نقش SRE کمک به آنها برای درک چالش های احتمالی در مواجهه با SLOهای موجود در SLA است. بیشتر توصیه ها برای ایجاد SLO در مورد SLA نیز اعمال می شود. عاقلانه است که در وعده‌هایی که به کاربران می‌دهید محافظه‌کار باشید، زیرا هرچه تعداد بیشتری داشته باشید، تغییر یا حذف SLA‌هایی که به نظر غیرمنطقی یا سخت‌تر به نظر می‌رسند دشوارتر می‌شود.

ممنون که ترجمه را تا آخر خواندید. در کانال تلگرام من در مورد نظارت عضو شوید monitorim_it и وبلاگ در مدیوم.

منبع: www.habr.com