sre

SRE-بخش چهارم

ریسک پذیری

ممکن است انتظار داشته باشید که گوگل سعی کند 100٪ سرویس قابل اعتماد بسازد – خدماتی که هرگز شکست نمی خورند.به نظر می رسد که گذشته از یک نقطه خاص ،افزایش قابلیت اطمینان برای یک سرویس (و کاربران آن)  بد است به جای بهتر! قابلیت اطمینان زیاد، حداکثر هزینه را دارد:  با به حداکثر رساندن ثبات، سرعت تولید ویژگی های جدید و سرعت تولید محصولات و تحویل آن به کاربران را محدود می کند، و به طور چشمگیری هزینه آنها را افزایش می دهد ، که به نوبه خود باعث کاهش تعداد ویژگی هایی می شود که یک تیم می تواند ارائه دهد. بعلاوه ، کاربران معمولاً متوجه تفاوت بین قابلیت اطمینان بالا و قابلیت اطمینان فوق العاده در یک سرویس نمی شوند ، زیرا تجربه کاربر تحت تأثیر اجزای کم اطمینان مانند شبکه تلفن همراه یا دستگاهی که با آن کار می کنن می باشد. به زبان ساده ، یک کاربر با یک تلفن هوشمند 99٪ قابل اعتماد نمی تواند تفاوت بین 99.99 و 99.999 درصد سرویس قابلیت اطمینان را تشخیص دهد! با توجه به این در نظر داشته باشید ، مهندسی قابلیت اطمینان سایت به جای به حداکثر رساندن زمان uptime، به دنبال آن است که خطر عدم در دسترس بودن را با اهداف نوآوری سریع و خدمات کارآمد متعادل کند، به طوری که رضایت کلی کاربران – با ویژگی ها ، خدمات و عملکرد -بهینه سازی شده باشد.

مدیریت ریسک

risk

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

  • هزینه منابع اضافی

هزینه مربوط به تجهیزات اضافی که مثلاً به ما اجازه می دهند تا سیستم را آفلاین کنیم برای انجام موارد نگهداری و برای قابل اطمینان بودن سیستم در زمان خرابی تجهیزات اصلی.

  • هزینه فرصت

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

در SRE ، قابلیت اطمینان بودن سرویس را تا حد زیادی با مدیریت ریسک، مدیریت می کنیم. ما ریسک را به صورت مستمر مورد بررسی قرار می دهیم و به این که بفهمیم چگونه قابلیت اطمینان بیشتر را در سیستم های Google مهندسی کنیم و سطح تحمل مناسب برای سرویس  هایی که اجرا می کنیم را شناسایی کنیم، اهمیت می دهیم. با انجام این کار می توان تجزیه و تحلیل هزینه / سود را برای تعیین این که ، به عنوان مثال ، در کجای ریسک باید جستجو ، تبلیغات ،Gmail  یا عکسها را قرار دهیم. هدف ما این است که به صورت جداگانه، ریسک پذیرفته شده توسط یک سرویس را با خطری که تجارت مایل به تحمل آن است، هماهنگ کنیم. ما تلاش می کنیم یک سرویس را به اندازه کافی قابل اعتماد کنیم، اما نه بیشتر از آن چه که نیاز است. یعنی وقتی که ما در دسترس بودن را با هدف 99.99٪ تعیین کنیم ، ما می خواهیم به آن برسیم ، اما نه زیاد: چون این کار فرصت ها را هدر می دهد برای افزودن ویژگی ها به سیستم ، پاکسازی بدهی های فنی یا کاهش عملکرد آن هزینه ها، به تعبیری ، ما هدف در دسترس بودن را با حداقل ها و حداکثر هایش در نظر میگیریم. مزیت کلیدی این قاب بندی این است که قفل ریسک پذیری صریح و متفکرانه را باز می کند.

اندازه گیری ریسک سرویس ها

measuring_risk

به عنوان یک عمل استاندارد در Google ، ما معمولاً شناسایی می کنیم یک متریک را برای نمایش ویژگی سیستمیی که می خواهیم آن را بهینه کنیم تا به بهترین وجه عمل کنیم. با تعیین هدف ، ما می توانیم عملکرد فعلی خود را ارزیابی کرده و روند بهبودها یا تخریب ها را به مرور زمان ارزیابی کنیم. یک متریک می تواند شامل فاکتورهای خاصی باشد که با در نظر گرفتن آن ها می توان پرفورمنس و قابل اطمینان بودن سرویس را افزایش داد و ریسک را کاهش داد. خرابی خدمات می تواند اثرات بالقوه زیادی از جمله نارضایتی ، آسیب یا از دست دادن کاربر، از دست دادن درآمد مستقیم یا غیرمستقیم، تأثیر در اعتبار و مطبوعات نامطلوب داشته باشد. واضح است که اندازه گیری برخی از این متریک ها بسیار سخت است. برای اینکه ما این مشکل را در بین بسیاری از انواع سیستم هایی که داریم، قابل ردیابی کنیم، بر روی downtimeهای برنامه ریزی نشده تمرکز می کنیم.

برای اکثر سرویس ها، راه ساده ی نشان دادن میزان تحمل ریسک، در نظر گرفتن downtimeهای برنامه ریزی نشده است.

availability =  uptime / (uptime + downtime)

با استفاده از این فرمول در طول زمان یک ساله، ما می توانیم میزان قابل قبول downtimeها را بدست آوریم.

در گوگل اگرچه اندازه گیری زمان برای در دسترس بودن، به علت اینکه سرویس های ما جهانی است، معنی دار نیست اما گاهی اوقات این متریک ها را در نظر می گیریم.

اما اکثر اوقات به جای استفاده از این معیارها، در دسترس بودن را با میزان موفق بودن ریکوئست ها اندازه میگریم.

availability = successful requests / total requests

برای مثال، یک سیستم که روزانه 2.5 میلیون ریکوئست را می گیرد، با هدف در دسترس بودن 99.99 درصدی، می تواند تا 250 خطا را داشته باشد.

در یک برنامه معمولی، تمام ریکوئست ها یکسان نیستند : fail شدن یک کاربر برای ثبت نام با fail شدن یک ریکوئست ایمیل نظرسنجی که در پس زمینه اجرا می شود متفاوت است.

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

تحمل ریسک سرویس ها

risk tolerance

 

این که ما تحمل ریسک یک سرویس را بشناسیم، به چه معناست؟

در یک محیط عملیاتی یا در مورد ایمنی سیستم های حیاتی، تحمل ریسک سرویس یک امر مهم است.

برای شناسایی تحمل ریسک یک سرویس، sreها باید با صاحبان محصول کار کنند، برای تبدیل اهداف تجاری به اهداف صریحی که می توانیم مهندسی کنیم.

در این مورد، اهداف تجاریی که اشاره کردیم، مستقیما بر روی عملکرد و قابلیت اطمینان سرویس های ارائه شده، تاثیر دارد.

شناسایی تحمل ریسک مصرف کننده ی سرویس ها

سطح هدف در دسترس بودن

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

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

شرایط کارکرد برنامه های گوگل را در نظر بگیرید. اکثر کاربران آن، کاربران سازمانی، برخی بزرگ و برخی کوچک هستند. این سازمان ها به برنامه های گوگل برای کارشان وابسته هستند، برای ارائه آن ها به کارمندان خود جهت انجام امور روزانشون. مثل برنامه های gmail, calender, drive و …

بنابراین خرابی سرویس های گوگل نه تنها برای گوگل بد است، بلکه برای سازمان هایی که از برنامه های گوگل استفاده می کنند نیز بد است. برای این موضوع ما در گوگل یک هدف 3 ماهه با در دسترس بودن 99.99 درصدی تعیین می کنیم و با قدرت این هدف را پیش می گیریم.

ما برای یوتیوب موارد متضادی را در نظر میگیریم. زیرا یوتیوب یک برنامه ی سازمانی نیست و ما به خاطر اینکه دائم در حال توسعه ی ویژگی های جدید برای آن هستیم، هدف در دسترس بودن کمتری را برای آن در نظر می گیریم.

انواع خرابی ها

شکل پیش بینی شده ی خرابی برای یک سرویس، یکی دیگر از موارد مهم است.

حال این سوال پیش می آید که برای سرویس ما کدام بدتر است؟ میزان کم خرابی ثابت یا قطعی گاه به گاه کامل سرویس؟

هر دو نوع خرابی ممکن است به یک میزان خطا تولید کنند اما ممکن است که تاثیرات آن ها بر تجارت بسیار متفاوت باشد.

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

در مورد اول به وضوح یک تجربه کاربری ضعیف را ارائه داده ایم و sreها باید به سرعت روی رفع مشکل کار کنند.

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

هزینه

هزینه اغلب عامل اصلی در تعیین هدف در دسترس بودن مناسب برای یک سرویس است.

  • بهبود پیشنهادی در هدف در دسترس بودن : 99.9% → 99.99%
  • افزایش پیشنهادی برای در دسترس بودن : 0.09%
  • درآمد سرویس : $1M
  • مقدار بهبود در دسترس بودن : $1M * 0.0009 = $900

در این حالت ، اگر هزینه بهبود دسترسی به میزان یک عدد 9 کمتر از 900 دلار باشد، ارزش سرمایه گذاری را دارد. اگر هزینه بیشتر از 900 دلار باشد ، هزینه ها از افزایش درآمد پیش بینی شده فراتر خواهد رفت. زمانی که امکان ترجمه ساده بین قابلیت اطمینان و درآمد نداشته باشیم، تعیین این اهداف دشوارتر است. یک استراتژی مفید ممکن است در نظر گرفتن میزان خطای پس زمینه ISP ها در اینترنت باشد. ما میزان خطای پیش زمینه معمولی ISP را اندازه گیری کرده ایم که بین 0.01٪ و 1٪ متغییر است.

سایر متریک های سرویس

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

تأخیر سرویس (latency) برای سیستم های تبلیغاتی گوگل مثالی روشن است. هنگامی که Google برای اولین بار جستجوی وب را آغاز کرد ، یکی از ویژگی های اصلی این سرویس سرعت بود. هنگامی که ما AdWords را معرفی کردیم ، تبلیغاتی را در کنار نتایج جستجو نمایش می داد، که به ازای آن یک نیاز اصلی سیستم این بود که تبلیغات نباید تجربه جستجو را کند کنند. این پیش نیاز اهداف مهندسی را در هر نسل از سیستم های AdWords برانگیخته است و به عنوان یک امر تغییر ناپذیر و ثابت تلقی می شود.

AdSense، سیستم تبلیغات Google که در پاسخ به درخواست کد JavaScript که ناشران در وب سایت های خود قرار می دهند، تبلیغات متنی را ارائه می دهد، یک هدف تأخیر بسیار متفاوت است. هدف تأخیر برای AdSense جلوگیری از کاهش سرعت ارائه صفحه شخص ثالث هنگام درج تبلیغات متنی است. بنابراین هدف خاص تأخیر، به سرعت ارائه صفحه ناشر معین بستگی دارد. این بدان معناست که می توان به طور کلی آگهی های AdSense صدها میلی ثانیه آهسته تر از تبلیغات AdWords ارائه کرد.

شناسایی تحمل ریسک در خدمات زیرساختی

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

سطح هدف در دسترس بودن

Bigtable  را در نظر بگیرید ، یک سیستم ذخیره سازی توزیع شده در مقیاس گسترده برای داده های ساخت یافته. برخی از خدمات مصرف کننده داده ها را مستقیماً از Bigtable در مسیر درخواست کاربر ارائه می دهند. چنین خدماتی به تأخیر کم و قابلیت اطمینان بالا نیاز دارند. تیم های دیگر از Bigtable به عنوان مخزنی برای داده هایی استفاده می کنند که برای انجام تجزیه و تحلیل آفلاین (به عنوان مثال ، MapReduce) در آنها استفاده می کنند. این تیم ها بیشتر از قابلیت اطمینان نگران کارایی هستند. تحمل ریسک برای این دو مورد استفاده کاملاً مشخص است.

یک روش برای تأمین نیازهای هر دو مورد، مهندسی کلیه خدمات زیرساختی است تا از قابلیت اطمینان فوق العاده بالایی برخوردار باشند. با توجه به این واقعیت که این خدمات زیرساختی همچنین منابع زیادی را جمع می کنند ، چنین رویکردی در عمل معمولاً بسیار گران است. برای درک نیازهای مختلف انواع مختلف کاربران ، می توانید وضعیت درخواست صف برای هر نوع کاربر Bigtable را بررسی کنید.

انواع خرابی ها

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

هزینه

یکی از راه های جلب رضایت این محدودیت های رقابتی به روشی مقرون به صرفه ، تقسیم زیرساخت ها و ارائه آن در چندین سطح مستقل از خدمات است. در مثال Bigtable ، ما می توانیم دو نوع خوشه بسازیم: خوشه های کم تاخیر(low-latency) و خوشه های توان عملیاتی (throughput clusters). خوشه های کم تاخیر به گونه ای طراحی شده اند که توسط سرویس هایی استفاده می شوند که به تأخیر کم و قابلیت اطمینان بالا نیاز دارند. برای اطمینان از اندازه صف های کوتاه و برآورده سازی سختگیرانه ترین نیازهای ایزوله بودن (isolation) مشتری، سیستم Bigtable را می توان با مقدار قابل توجهی از ظرفیت ضعیف (slack) برای کاهش مغایرت و افزایش افزونگی تأمین کرد. از طرف دیگر ، خوشه های توان تولیدی می توانند بسیار به موقع و با افزونگی کمتری کار کنند و توان تولید را نسبت به زمان تاخیر بهینه کنند. در عمل، ما می توانیم این نیازها را با هزینه ای بسیار کمتر، شاید به اندازه 10 تا 50 درصد هزینه یک خوشه کم تاخیر، برآورده کنیم. با توجه به مقیاس عظیم Bigtable ، این صرفه جویی در هزینه بسیار سریع حس و قابل توجه می شود.

استراتژی اصلی در رابطه با زیرساخت، ارائه و تحویل سرویس ها به همراه تعیین دقیق سطوح آن ها است، بنابراین مشتریان می توانند هنگام ساخت سیستم های خود امکان تشخیص درست ریسک و هزینه های آن را داشته باشند. با تعیین سطح مشخص خدمات، ارائه دهندگان زیرساخت می توانند به طور موثر تفاوت هزینه ای که برای ارائه خدمات در یک سطح مشخص به مشتریان لازم است را از بین ببرند. افشای هزینه از این طریق باعث ایجاد انگیزه در مشتریان می شود تا سطح خدمات با کمترین هزینه را که هنوز هم پاسخگوی نیازهای آنها است را انتخاب کنند. به عنوان مثال، Google+ با قرار دادن داده های ضروری (critical) جهت اطمینان سازی اطلاعات کاربران در محیطی HA (همیشه در دسترس)، دیتا استور جهانی استوار (برای مثال یک سیستم جایگزین شبیه SQL مانند Spanner) در حالیکه داده های اختیاری (داده هایی که چندان ضروری نیستند اما باعث افزایش تجربه خوب کاربر می شوند) در یک پایگاه داده ارزان تر، با اطمینان کمتر، تازه تر و در نهایت سازگار (به عنوان مثال ، یک فروشگاه NoSQL با همانندسازی بیشتر مانند Bigtable).

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

مثال: زیرساخت Frontend

برای اثبات اینکه اصول ارزیابی تحمل ریسک فقط در زیرساخت های ذخیره سازی اعمال نمی شود ، کلاس بزرگ دیگری از خدمات را بررسی میکنیم: زیرساخت frontend گوگل. متشکل از پراکسی معکوس و سیستم های متعادل کننده بار است که در شبکه گوگل کار می کنند. اینها سیستم هایی هستند که ، در میان بقیه، به عنوان یکی از نقاط پایانی اتصالات کاربران نهایی هستند (به عنوان مثال ، TCP را از مرورگر کاربر خاتمه دهید). با توجه به نقش حیاتی آنها ، ما این سیستم ها را مهندسی می کنیم تا از قابلیت اطمینان بسیار بالایی برخوردار شوند. در حالی که سرویس های مصرف کننده اغلب می توانند نمایان نبودن اطمینان در backendها را محدود کنند ، این سیستم های زیرساخت چندان خوش شانس نیستند. اگر درخواستی هرگز به سرور frontend سرویس برنامه نرسد ، از بین می رود.

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

انگیزه برای بودجه های خطا

در سایر فصل های این کتاب ، چگونگی ایجاد تنش در تیم های توسعه محصول و تیم های SRE ، با توجه به اینکه به طور کلی در معیارهای مختلف ارزیابی می شوند ، بحث می شود. عملکرد توسعه محصول تا حد زیادی بر اساس سرعت محصول ارزیابی می شود که انگیزه ای برای pull کردن سریع کد جدید در اسرع وقت ایجاد می کند. در همین حال ، عملکرد SRE (بدون تعجب) بر اساس قابلیت اطمینان یک سرویس ارزیابی می شود ، که به معنای انگیزه ای برای عقب راندن در برابر نرخ بالای تغییر است. عدم تقارن اطلاعاتی بین دو تیم این تنش ذاتی را بیشتر تقویت می کند. توسعه دهندگان محصول نسبت به زمان و تلاش خود برای نوشتن و انتشار کدهای خود دید بیشتری دارند ، در حالی که SRE ها قابلیت اطمینان سرویس (و به طور کلی وضعیت تولید) را دارند.

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

تحمل خطای نرم افزار

چقدر نرم افزار را در برابر حوادث غیرمترقبه سخت(hardened) می کنیم؟ خیلی کم ، و ما یک محصول شکننده و غیرقابل استفاده داریم. خیلی زیاد ، و ما محصولی داریم که هیچ کس نمی خواهد از آن استفاده کند (اما این محصول بسیار پایدار اجرا می شود).

آزمایش کردن

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

فرکانس فشار (push)

هر push خطرناک است. در مقایسه با انجام کارهای دیگر ، چقدر باید در کاهش این خطر کار کنیم؟

مدت و اندازه canary

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

معمولاً بین تیم های موجود نوعی تعادل غیررسمی در مورد مرز ریسک / تلاش ایجاد شده است. متأسفانه ، به ندرت می توان اثبات کرد که این تعادل بهینه است. همچنین چنین تصمیماتی نباید تحت تأثیر سیاست ، ترس یا امید باشد. (در واقع ، شعار غیررسمی Google SRE “امید یک استراتژی نیست.”) درعوض ، هدف ما تعریف معیاری عینی است که مورد توافق هر دو طرف باشد و بتواند برای هدایت مذاکرات به روشی تکرار پذیر مورد استفاده قرار گیرد. هرچه تصمیم مبتنی بر داده بیشتر باشد ، بهتر است.

شکل گیری بودجه خطای شما

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

تمرین ما به شرح زیر است:

  • مدیریت محصول یک SLO را تعریف می کند که انتظاراتی را تعیین میکند از اینکه سرویس ها در هر کوارتر به چه میزان باید up باشند.
  • زمان واقعی uptime توسط شخص ثالث خنثی اندازه گیری می شود: سیستم مانیتورینگ.
  • تفاوت بین این دو عدد “بودجه” میزان “غیر قابل اعتماد بودن” برای باقی مانده کوارتر را تعیین میکند.
  • تا زمانی که زمان uptime اندازه گیری شده بالاتر از SLO باشد – به عبارت دیگر، تا زمانی که بودجه خطایی باقی مانده باشد – می توان نسخه های جدید را push کرد.

به عنوان مثال ، تصور کنید که SLO یک سرویس به طور موفقیت آمیز 99.999٪ از کل درخواست ها را در هر کوارتر ارائه می دهد. این بدان معنی است که بودجه خطای سرویس برای سه ماهه معادل 0.001٪ شکست است. اگر مشکلی باعث شود ما 0.0002٪ درخواستهای مورد انتظار برای کوارتر را از کار بیندازیم ، این مشکل 20٪ بودجه خطای کوارتر سرویس را خرج می کند.

فواید

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

بسیاری از محصولات از این حلقه کنترل برای مدیریت سرعت انتشار استفاده می کنند: تا زمانی که SLO های سیستم برآورده شوند ، انتشار ها می توانند ادامه داشته باشند. اگر تخلفات SLO به اندازه کافی برای صرف بودجه خطا اتفاق بیفتد ، انتشار محصول به طور موقت متوقف می شود و منابع اضافی برای آزمایش و توسعه سیستم سرمایه گذاری می شود تا سیستم را مقاوم تر کند ، عملکرد آن را بهبود بخشد و غیره. رویکردهای ظریف و م thanثرتری نسبت به این تکنیک روشن و خاموش ساده در دسترس است: به عنوان مثال ، 2 هنگامی که بودجه خطای نقض SLO نزدیک به مصرف است ، کاهش سرعت انتشار و یا بازگرداندن آنها.
رویکردهای ظریف و موثرتری نسبت به این تکنیک روشن و خاموش ساده در دسترس است: به عنوان مثال، هنگامی که بودجه خطای نقض SLO نزدیک به مصرف حداکثری است ، سرعت انتشار و یا بازگرداندن آنها را کاهش میدهیم.

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

چه اتفاقی می افتد اگر قطع شدن شبکه یا خرابی مرکز داده SLO اندازه گیری شده را کاهش دهد؟ چنین رویدادهایی بودجه خطا را نیز در پی دارد. در نتیجه ، ممکن است تعداد pushهای جدید برای باقیمانده کوارتر کاهش یابد. کل تیم از این کاهش حمایت می کنند زیرا همه افراد مسئولیت به روز بودن را دارند.

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

0 دیدگاه در “SRE-بخش چهارمافزودن → خودتان

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *