اصول، شیوه و مفاهیم اولیه SRE

تهیه‌کننده مقاله : ربین برزنجی

دسته بندی: عملیات
4 دقیقه زمان مطالعه
1401/08/17
0 نظر

چه شما یک مهندس نرم افزار، مهندس DevOps، مشاور فناوری اطلاعات یا یک مدیر سیستم (system admin) باشید، مطمئنا SRE (که در فارسی مهندسی قابلیت اطمینان یا مهندسی ضریب اطمینان ترجمه شده است) برای شما جذاب خواهد بود. در این مقاله در رابطه با اصول و شیوه‌های SRE و این که به طور کلی SRE چیست صحبت می‌کنیم.

مهندسی Site Reliability چیست؟

آقای Benjamin Treynor  یکی از مدیران ارشد در Google که به عنوان مبدع SRE شناخته می­شود، نقش آن را اینگونه تعریف میکند: ” نقش sre زمانی به وجود می آید که از یک مهندس نرم افزار بخواهیم، کارهای عملیاتی انجام بدهد”

نظر به مورد توجه قرار گرفتن SRE و شکل گرفتن بحث‌ها و صحبت‌های زیادی درخصوص آن، این موضوع در حال حاضر تبدیل به یک رشته و شاخه شده است. در حال حاضر Sre که مخففSite Reliability Engineering است، یک زمینه مهندسی است که به سازمان‌ها در راستای دستیابی به درجه مناسبی از قابلیت اطمینان در سیستم‌ها و خدمات خود کمک میکند.

کلمه کلیدی و عمده تمرکز در اینجا، قابلیت اطمینان یا reliable بودن است. ما به ندرت سیستم‌هایی را می‌بینیم که دارای ضریب اطمینان ۱۰۰٪  باشند و البته باید خاطر نشان کرد که براساس نوع برنامه، سیستم، خدمات، مشتری و … ممکن است اهداف حتی رسیدن به ۱۰۰% نباشد چرا که امری است با هزینه های بسیار زیاد و باید درنظر داشت که reliable بودن بیشتر یک تصمیم تجاری و بیزینسی است تا فنی و براساس رفتار ذینفعان، سطح قابلیت اطمینان مورد نظر مشخص شود.

برخی از اصول و شیوه‌های کلیدی SRE را برای درک بهتر این موضوع بررسی کنیم.

SLI

SLI ها یا نشانگرهای سطح خدمات (service level indicators) نشانگر میزان سلامت خدمات شما هستند. شاخص‌ها و راه‌های زیادی برای ردیابی آن‌ها وجود دارد. یک SLI خوب نباید مبتنی بر داده‌های پر از noise باشد، درعوض باید نشان دهد که یک سرویس همان طور که کاربران انتظار دارند، کار می‌کند. به عنوان مثال یک نشانگر برای سرویس شما می‌تواند این باشد که در دسترس کاربران است و کد وضعیت ۲۰۰ را برمی گرداند  نه یک کد خطای سرور ۵۰۰.

SLO

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

لازم به ذکر است که تیم موفق، به صورت اتفاقی یا در یک زمان و مکان خاص به وجود نمی آید و یکی از اصول و پیشنیازهای اصلی آن، تکمیل تدریجی SLOهاست.

بودجه بند خطا

 بودجه خطا تفاوت بین قابلیت اطمینان نظری یا theoretical perfect reliability  یک سرویس (۱۰۰٪) و قابلیت اطمینان مورد نیاز است. برای مثال بالا، بودجه خطای شما ۱۰۰-۹۰ = ۱۰٪ است. این بدان معناست که ما ۱۰ درصد غیر قابل اعتماد در پروژه  داریم که می توانیم تا زمانی که تمام شود از آن استفاده کنیم. می‌توانیم روی توسعه ویژگی دیگری برای این سرویس تمرکز کنیم و آن را آزمایش کنیم و تا زمانی که ۱۰٪ مصرف شود، در آن بودجه باقی بمانیم.  زمانی که از این بودجه بیشتر می‌شود و SLO نقض می‌شود، چه اقداماتی باید انجام شود؟ باید در هنگام ایجاد آن بودجه درصد خطا توافق شود.

جلسات هم اندیشی یا Blameless Postmortem

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

هوشمندانه کار کردن:

در تیمهای SRE باید به کارهایی که تغییرات دستی را به حداقل ممکن برساند، توجه ویژه داشت. این کارها را میتوان به CI/CDها و ابزارهای آن، مانیتورینگ، الرتینگ، مدیریت لاگها و … دسته بندی کرد.

نباید تاکید بر پرخطر بودن و درعین حال بی ارزش بودن تغییرات دستی در محیط عملیاتی را از قلم انداخت.

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