چه شما مهندس نرم‌افزار، مهندس DevOps، مشاور IT یا مدیر سایت باشید، مطمئن هستیم که مهندسی قابلیت اطمینان سایت برای شما جذاب و کارآمد است. به همین خاطر در این مقاله می‌خواهیم راجع به SRE یا همان مهندسی قابلیت اطمینان سایت و قواعد و نکات آن صحبت کنیم. با ما همراه باشید.
مهندسی قابلیت اطمینان سایت (Site Reliability Engineering) چیست؟
تعریف SRE زمانی ایجاد شد که Treynor Sloss، یکی از مهندسان گوگل در تلاش برای پاسخ به سوال زیر بود:
“وقتی از یک مهندس نرم‌افزار می‌خواهید تابعی از یک عملکرد را طراحی کند چه اتفاقی می‌افتد؟”
پس از این سوال، افراد بیشتری راجع به این موضوع صحبت و تعداد بیشتری پیاده‌سازی SRE را آزمایش کردند؛ تا جایی که این تعریف تبدیل به یک رشته موضوعی شد. در حال حاضر SRE یک رشته مهندسی است که به سازمان‌ها، در راستای دستیابی به درجه مناسبی از قابلیت اطمینان در سیستم‌ها و خدمات خود در طول زمان اختصاص داده می‌شود.
کلمه کلیدی در این تعریف قابلیت اطمینان است. ما به ندرت سیستم‌هایی را می‌بینیم که ۱۰۰ درصد قابل اعتماد باشند و حتی رسیدن به اطمینان ۱۰۰ درصد هم نباید هدف ما باشد. ذینفعان می‌توانند سطح قابلیت اطمینان مورد نیاز را، بر اساس نوع برنامه‌ای که مدیریت می‌شود مشخص کنند.
بهتر است برای درک بهتر تعریف اطمینان و در نتیجه مهندسی قابلیت اطمینان، برخی از اصول و شیوه‌های کلیدی SRE را بررسی کنیم.
SLI
SLIها یا شاخص‌های سطح خدمات (Service Level Indicators)، میزان سلامت خدمات شما را نشان می‌دهند. شاخص‌های زیاد و به طبع آن، راه‌های مختلفی برای ردیابی آن‌ها وجود دارد. یک SLI خوب نباید مبتنی بر داده‌های پرخطای ابزارهای نظارتی (مانیتورینگ) باشد، در عوض باید نشان دهد که یک سرویس همان طور که کاربران انتظار دارند، کار می‌کند.
به عنوان مثال یک شاخص برای سرویس شما می‌تواند این باشد که در دسترس کاربران است و کد وضعیت ۲۰۰ را برمی‌گرداند؛ نه کد خطای سرور ۵xx را.
SLO
SLOها یا شاخص‌های سطح سرویس (Service Level Indicators)، اهدافی هستند که به درک قابلیت اطمینان سرویس کمک می‌کنند. زمانی که ما شاخص‌هایی برای مشاهده نحوه عملکرد سرویس داریم، باید مشخص کنیم که چه سطحی از قابلیت اطمینان را از آن می‌خواهیم.
شما یک SLO را بر اساس چیزی تنظیم می‌کنید که می‌تواند به دقت اندازه گیری و در سیستم نظارتی شما نمایش داده شود. به عنوان مثال سرویس شما در ۹۰ درصد مواقع کد وضعیت ۲۰۰ را برمی‌گرداند؛ از این رو در دسترس کاربران است و ۹۰ درصد درخواست‌ها با موفقیت انجام می‌شود.
بودجه خطا
بودجه خطا تفاوت بین قابلیت اطمینان نظری (۱۰۰ درصدی) یک سرویس و قابلیت اطمینان مورد نیاز است. برای مثال، در پاراگراف قبل بودجه خطای شما ۱۰٪ = ۹۰ – ۱۰۰ است. این به این معناست که ما ۱۰ درصد غیر قابل اعتماد در پروژه داریم که می‌توانیم تا زمانی که بودجه آن تمام شود، از آن استفاده کنیم.
در این بازه ۱۰ درصدی، می‌توانیم روی توسعه ویژگی دیگری برای این سرویس تمرکز و آن را آزمایش کنیم و تا زمانی که ۱۰ درصد مصرف شود، در آن بودجه باقی بمانیم. توجه کنید که هنگام تعریف و تخصیص بودجه خطا، باید به اقدامات لازم در صورت اتمام بودجه و نقض SLO فکر کنید.
کالبدشکافی بی‌طرف (Blameless Postmortem)
کالبدشکافی بی‌طرف همانطور که از اسم آن پیداست، روشی برای تجزیه و تحلیل یک اتفاق نامطلوب در گذشته، بدون مقصر دانستن شخص یا عامل خاصی است. تاکید این روش بیشتر بر شکست فناوری است تا افراد خاص در پروژه. این مورد تضمین می‌کند که ما به دنبال روش‌هایی برای بهبود سیستم‌ها یا فرآیندها هستیم تا راه‌هایی برای جریمه کردن افرادی که غیر عمد در به‌‌وجود آمدن مشکل نقش داشته‌اند.
زحمت
زحمت نوعی از کار، بیشتر به صورت دستی، تکراری و بی‌ارزش است که با رشد یک خدمت گسترش پیدا می‌کند. تمرکز اصلی SRE حذف هر چه بیشتر و بهتر این شیوه از کار کردن است.
جمع‌بندی مفاهیم SRE
پس از خواندن مطالب بالا مطمئن هستیم که در مورد تفاوت DevOps و SRE و ارتباط آن‌ها با یکدیگر سوالاتی در ذهن شما به وجود آمده است. افراد در صنعت هنوز در تلاش هستند تا تفاوت‌ها را به درستی ارائه دهند، اما در نهایت می‌دانیم که این دو تعریف، رشته‌های موازی و جداگانه‌ای هستند که شامل اتوماسیون و عملیات نظارتی می‌شوند؛ این در حالی است که SRE با ذهنیت مهندسی نرم‌افزار شروع شد و نمی‌توان آن را به عنوان آینده DevOps در نظر گرفت. پس هر دو آن‌ها باید متفاوت اجرا شود.
منبع:
https://medium.com/avina-jain/sre-principles-and-practices-c12d6861e9ed
دیدگاهتان را بنویسید