چه شما مهندس نرمافزار، مهندس 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) عملکرد سیستمها را بهینه میکند؟
مهندسی قابلیت اطمینان سایت (SRE) مسئولیت اطمینان از عملکرد قابل پیشبینی، مقیاسپذیر و پایدار سیستمها و خدمات نرمافزاری را بر عهده دارد. مهندسان SRE با ترکیب مهارتهای برنامهنویسی و عملیات، فرآیندهای تکراری و دستی را خودکار کرده و تلاش میکنند تا زحمتها (Toil) را کاهش دهند. به علاوه، آنها برای بهبود نظارت بر سلامت سیستمها و مدیریت رخدادهای پیشبینینشده راهحلهایی ارائه میکنند که در نهایت به افزایش قابلیت اطمینان منجر میشود.
مهندس SRE و Sysadmin چه تفاوتی با هم دارند؟
در حالی که مدیران سیستم (Sysadmins) سنتی وظیفه مدیریت و نگهداری زیرساختهای فناوری اطلاعات را بر عهده دارند، مهندسان SRE با دیدگاه مهندسی نرمافزار به مسائل زیرساختی مینگرند. Sysadminها معمولا تمرکز خود را بر مدیریت سرورها و انجام وظایف دستی مانند رفع اشکالهای سختافزاری و نرمافزاری میگذارند، در حالی که مهندسان SRE با خودکارسازی این فرآیندها و ایجاد ابزارهایی برای نظارت و تحلیل، کارایی و پایداری بیشتری برای سیستمها فراهم میکنند.
DevOps و SRE چه تفاوتی با هم دارند؟
DevOps و SRE هر دو به بهبود فرآیندهای توسعه و عملیات فناوری اطلاعات کمک میکنند، اما تفاوتهای کلیدی بین آنها وجود دارد. DevOps بیشتر یک فرهنگ و مجموعهای از اصول و شیوهها برای همکاری بهتر بین تیمهای توسعه و عملیات است، در حالی که SRE بهعنوان یک رویکرد عملیاتی با تمرکز بر قابلیت اطمینان، از ابزارها و فرآیندهای خاصی بهره میبرد. یکی از تفاوتهای اصلی در این است که DevOps اغلب به اهداف تحویل سریعتر کد جدید اهمیت میدهد، در حالی که SRE برای ایجاد تعادل میان سرعت توسعه و ثبات سیستمها، از مفاهیمی مانند بودجه خطا و SLO استفاده میکند.
چرا SRE برای موفقیت سازمان شما ضروری است؟
در دنیای امروز که خدمات آنلاین بهسرعت در حال رشد هستند، داشتن سیستمهای پایدار و قابل اعتماد برای سازمانها ضروری است. SRE با استفاده از روشهایی برای نظارت مؤثرتر بر عملکرد سیستمها، خودکارسازی فرآیندهای تکراری و کاهش خرابیها به سازمانها کمک میکند تا تجربه کاربری بهتری فراهم کنند. این امر به کاهش هزینههای ناشی از خرابیها، افزایش بهرهوری تیمهای توسعه و عملیات و در نهایت بهبود رضایت مشتری منجر میشود. شرکتهای بزرگی مانند گوگل و نتفلیکس از SRE برای تضمین دسترسیپذیری بالای خدمات خود استفاده میکنند.
جمعبندی مفاهیم SRE
پس از خواندن مطالب بالا مطمئن هستیم که در مورد تفاوت DevOps و SRE و ارتباط آنها با یکدیگر سوالاتی در ذهن شما به وجود آمده است. افراد در صنعت هنوز در تلاش هستند تا تفاوتها را به درستی ارائه دهند، اما در نهایت میدانیم که این دو تعریف، رشتههای موازی و جداگانهای هستند که شامل اتوماسیون و عملیات نظارتی میشوند؛ این در حالی است که SRE با ذهنیت مهندسی نرمافزار شروع شد و نمیتوان آن را به عنوان آینده DevOps در نظر گرفت. پس هر دو آنها باید متفاوت اجرا شود.
منبع:
https://medium.com/avina-jain/sre-principles-and-practices-c12d6861e9ed
دیدگاهتان را بنویسید