SLO و بودجهٔ خطا: تعریف عددی «به‌اندازهٔ کافی خوب»

تیم آرادتیم مهندسی

بحثی که در هر سازمانی تکرار می‌شود و هیچ‌وقت به جایی نمی‌رسد:

واحد کسب‌وکار می‌گوید «سامانه باید همیشه بالا باشد». تیم فنی می‌گوید «باید روی پایداری کار کنیم». و در عمل، تا وقتی خرابی بزرگی رخ ندهد، همهٔ ظرفیت صرف قابلیت جدید می‌شود.

دلیل بی‌نتیجه ماندن این بحث ساده است: هیچ عددی روی میز نیست. هر دو طرف درست می‌گویند و هیچ‌کدام نمی‌تواند ثابت کند.

SLO آن عدد است. و بودجهٔ خطا، مکانیزمی است که آن عدد را به تصمیم تبدیل می‌کند.

سه اصطلاح، که فرقشان مهم است

سنجهٔ سطح خدمت — چیزی که اندازه می‌گیرید. مثلاً «نسبت درخواست‌هایی که در کمتر از ۵۰۰ میلی‌ثانیه پاسخ موفق گرفته‌اند».

هدف سطح خدمت (SLO) — عددی که برای آن سنجه می‌خواهید. مثلاً «۹۹٫۵٪ در هر ماه». داخلی است، هدف مهندسی، و می‌شود عوضش کرد.

توافق سطح خدمت (SLA) — تعهد قراردادی به مشتری، با جریمه. بیرونی است.

قاعدهٔ عملی: SLA همیشه شل‌تر از SLO باشد. اگر داخلی ۹۹٫۵٪ را هدف گرفته‌اید، در قرارداد ۹۹٪ ببندید. آن فاصله، فضایی است که به شما اجازه می‌دهد پیش از نقض قرارداد متوجه شوید. جنبه‌های قراردادی در پشتیبانی و SLA آمده.

چرا صد درصد جواب غلط است

سه دلیل، و هر سه فنی نیستند:

شدنی نیست. شبکه، برق، سرویس بیرونی، و خود انتشار. زنجیره‌ای از اجزا که هیچ‌کدام صد درصد نیستند.

اقتصادی نیست. فاصلهٔ ۹۹٪ تا ۹۹٫۹٪ هزینه دارد. فاصلهٔ ۹۹٫۹٪ تا ۹۹٫۹۹٪ چند برابر آن. هر رقم اضافه، هزینه را چند برابر می‌کند در حالی که تفاوتش برای کاربر کمتر و کمتر محسوس است.

کاربر تفاوتش را نمی‌بیند. اگر اپراتور تلفن همراه کاربر ماهی ده دقیقه اختلال دارد، دسترس‌پذیری ۹۹٫۹۹٪ سامانهٔ شما را کسی تجربه نمی‌کند.

پس سؤال درست این نیست که «چطور صد درصد شویم». این است که چقدر خرابی برای این کسب‌وکار قابل تحمل است، و هزینهٔ رسیدن به آن چقدر است.

عدد را چطور انتخاب کنیم

مبنای واقعی، درد کاربر است، نه رقم گرد قشنگ.

SLO ماهانه خرابی مجاز در ماه
۹۹٪ حدود ۷ ساعت
۹۹٫۵٪ حدود ۳٫۵ ساعت
۹۹٫۹٪ حدود ۴۳ دقیقه
۹۹٫۹۹٪ حدود ۴ دقیقه

این جدول را در جلسه بگذارید و بپرسید: «چهار دقیقه در ماه یعنی هیچ‌کس نمی‌تواند شب بخوابد. سه ساعت و نیم یعنی چه؟» تفاوت این گفت‌وگو با «باید همیشه بالا باشد» همه‌چیز است.

دو نکتهٔ عملی:

تفکیک به جریان کاری. ثبت سفارش و صفحهٔ گزارش مدیریتی، یک SLO ندارند. سامانه‌ای که برای همه‌چیز یک عدد دارد، یا زیادی خرج می‌کند یا زیادی قول می‌دهد.

دسترس‌پذیری تنها سنجه نیست. تأخیر و درستی هم مهم‌اند. سامانه‌ای که بالاست ولی هر درخواست هشت ثانیه طول می‌کشد، برای کاربر پایین است — که همان استدلال بودجهٔ کارایی است.

بودجهٔ خطا: جایی که SLO به تصمیم تبدیل می‌شود

اینجا مفهوم واقعاً مفید می‌شود.

اگر SLO شما ۹۹٫۵٪ است، یعنی ۰٫۵٪ خرابی مجاز است. آن ۰٫۵٪ بودجهٔ شماست — منبعی که می‌شود خرجش کرد.

و این چیزی را عوض می‌کند: خرابی دیگر شکست اخلاقی نیست، هزینه‌ای است که در ازای سرعت پرداخت می‌شود.

قاعده‌ای که از این بیرون می‌آید:

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

بودجه تمام شده؟ انتشار قابلیت جدید متوقف می‌شود و ظرفیت به پایداری می‌رود، تا دورهٔ بعد.

این قاعده، آن بحث بی‌پایان اول مقاله را با یک عدد جایگزین می‌کند. تصمیم دیگر موضوع مذاکره نیست؛ از داده می‌آید.

و شرط اجرایی‌اش این است: این قاعده باید پیش از مصرف بودجه توافق شده باشد. قاعده‌ای که وسط بحران معرفی شود، اجرا نمی‌شود.

پیش‌نیازها، که کم نیستند

SLO بدون این سه، یک عدد روی اسلاید است:

اندازه‌گیری از دید کاربر. «سرور بالا بود» با «کاربر توانست سفارش ثبت کند» یکی نیست. سنجه باید از نقطه‌ای گرفته شود که تجربهٔ واقعی را نشان دهد — پایش و لاگ و تلمتری محصول.

تعریف روشن «خطا». پاسخ ۵۰۰ خطاست. پاسخ کندِ موفق چه؟ خطای ۴۰۰ که از ورودی غلط کاربر آمده چه؟ این تعریف باید نوشته شود، وگرنه هر ماه بحث می‌شود.

پنجرهٔ زمانی ثابت. ماهانه یا سی‌روزهٔ لغزان. بدون پنجرهٔ مشخص، عدد قابل مقایسه نیست.

اشتباه‌های رایج

SLO برای هر چیزی که قابل اندازه‌گیری است. سه تا پنج تا برای کل سامانه. بیست SLO یعنی هیچ‌کدام دنبال نمی‌شود.

عددی که هیچ‌وقت نقض نمی‌شود. SLOای که سه سال است سبز است، یا خیلی شل است یا اندازه‌گیری‌اش غلط. بودجه‌ای که خرج نمی‌شود، بودجه نیست.

نبود پیامد. اگر بودجه تمام شود و هیچ اتفاقی نیفتد، کل ساختار تزیین است. پیامد لازم نیست تنبیه باشد؛ فقط باید از پیش توافق‌شده باشد.

اشتباه گرفتن با مدیریت رخداد. SLO می‌گوید چقدر خرابی قابل قبول است؛ مدیریت رخداد می‌گوید وقتی رخ داد چه کنیم. هر دو لازم است و جای هم را نمی‌گیرند.

اگر می‌خواهید کوچک شروع کنید

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

سه ماه اندازه بگیرید و هیچ تصمیمی نگیرید — فقط ببینید عدد واقعی چقدر است. تقریباً همیشه با حدس اولیه فاصله دارد، و همان فاصله ارزشمندترین چیزی است که در سه ماه اول به دست می‌آورید.

بعد از آن، دربارهٔ سرعت انتشار با داده حرف بزنید، نه با حس.

پروژه یا ایده‌ای دارید؟

متخصصین ما آماده برگزاری یک جلسه مشاوره رایگان هستند.

مشاوره رایگان

پروژه‌تان را با هم بررسی کنیم

جلسهٔ اول رایگان است و معمولاً همان یک جلسه روشن می‌کند پروژه چقدر کار دارد.

چطور با شما تماس بگیریم؟

برای هماهنگی سریع‌تر — اگر تماس تلفنی را ترجیح نمی‌دهید، همان شماره را در پیام‌رسان پیام می‌دهیم.

راه دوم برای رساندن پاسخ — اگر تلفن در دسترس نبود، ایمیل می‌زنیم.

در حال ارسال…

درخواست شما ثبت شد.

همکاران ما پیام شما را می‌بینند و با شما تماس می‌گیرند.