SRE چیست؟

SRE چیست؟

SRE کلمه‌ای است که از مخفف عبارت Site Reliability Engineering حاصل شده است. معنای این عبارت، مهندسی قابل اطمینان (کنترل اطمینان) سایت تعبیر شده و در واقع هدف SRE این است که سیستم‌های نرم‌افزاری، مقیاس‌پذیری بیشتری داشته و همچنین قابل‌اطمینان‌تر شوند. یکی از مهندسین گوگل به نام آقای Ben در رابطه با مفهوم این کلمه، بیان داشته است: این کلمه زمانی پدید می‌آید که افراد از یک مهندس نرم‌افزار بخواهند عملی را که مربوط به تخصص اوست، انجام دهد.

مهندسی قابل اطمینان سایت

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

مزایای SRE چیست؟

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

قابلیت مشاهده سلامت خدمات:

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

پیوندهای قوی تر بین توسعه دهندگان و عملیات:

مهندسان قابلیت اطمینان سایت با معرفی اتوماسیون و بهبود ارتباطات که به نفع هر دو تیم است، روابط بین توسعه دهندگان و ITOs را تقویت می کنند. SRE می‌تواند ضعف‌های خط لوله انتشار را آشکار و تقویت کند و مسئولیت‌پذیری در مورد در دسترس بودن هنگام تماس و پاسخ به حادثه ایجاد کند.

نوسازی NOC:

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

سازماندهی ساختارهای حین تماس و گردش کار هشدار:

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

نمایان شدن نگرانی‌های تولید:

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

سرپرستی در تیم های مهندسی:

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

وظایف کارشناسان تیم SRE

هر شخصی که در هر تیمی باشد، با توجه به تخصص و کارایی حوزه خود، دارای وظایفی است. بحث Site Reliability Engineering نیز از این امر مستثنا نبوده و دارای کارشناسانی است که در حوزه‌های مختلف مدیریت سیستمی و عملیاتی، برنامه‌نویسی و … فعالیت‌های لازم را داشته‌اند. از جمله فعالیت‌های کارشناسان SRE می‌توان به موارد زیر اشاره نمود:

• انجام فعالیت عملیاتی.

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

• بهبود، ارتقا و کار روی سیستم جهت مقیاس‌پذیرتر شدن آن
• عملیات خودکارسازی سیستم
• نظارت بر ظرفیت، دسترس‌پذیر بودن سرویس‌های گوگل و عملکرد آن‌ها
• UP کردن سیستم‌ها از هر گونه خطا و مشکلی
• امنیت سورس کدها در مقابل حملات
• نظارت بر پرمیشن‌ها جهت دستیابی به منابع سیستم
• Refactore کردن کدها
• مالک اصلی سرویس‌هایی که هنوز ارائه نشده‌اند
• کنترل ضریب اطمینان
• گسترش مداوم دانش خود در زمینه سیستم‌ها
• انجام تغییرات لازم در سیستم به گونه‌ای ایمن

اقدامات کلیدی در مهندسی قابلیت اطمینان سایت چیست؟

تمام روش‌های SRE در جهت بهبود قابلیت اطمینان سیستم طراحی شده‌اند و می‌توانند در پنج دسته اصلی گروه‌بندی شوند:

در دسترس بودن: (Availability)

تیم SRE مسئول حفظ در دسترس بودن سیستم ها و خدمات پس از تولید هستند، با تعیین اهداف سطح سرویس (SLO)، توافق نامه های سطح خدمات (SLA) و شاخص های سطح خدمات (SLIs) برای سیستم ها. خدمات اساسی SLIها معیارهایی مانند زمان آپلود یا تأخیر درخواست را مشخص می کنند که شرکت ها از آنها برای اندازه گیری سطح خدمات ارائه شده به مشتریان استفاده می کنند. SLOها ابزارهای اندازه‌گیری عملکرد سایت یا خدمات را تعریف می‌کنند – برای مثال 99.99٪ در دسترس بودن – بر اساس آن SLIها. سپس هر دو برای ایجاد SLA مورد استفاده قرار می‌گیرند، که قابلیت اطمینان مورد انتظار سرویس و نحوه واکنش تیم را در صورت عدم تحقق آن هدف توضیح می‌دهد.

عملکرد: (Performance)

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

نظارت: (Monitoring)

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

پاسخ به حادثه:(Incident response)

تیم های SRE برای پاسخ به حادثه – بسیج یک حادثه (با مدیریت حادثه که سیستم ثبت و پیگیری حسابرسی است اشتباه گرفته نشود) بسیار مهم هستند. اعضای تیم SRE باید برای پاسخگویی، توضیح و بررسی هر گونه حادثه ای که در سیستم رخ می دهد در دسترس باشند. این ممکن است شامل ممیزی گردش کار تولید، فرآیندها، معیارهای هشدار و سایر عوامل پیرامون یک استقرار باشد. به طور معمول، تیم های SRE از یک  playbook در حال تماس برای هدایت پاسخ های خود به یک رویداد استفاده می کنند. آنها همچنین بررسی موضوع بعد از خاتمه(post-mortem)  بدون مقصر دانستن شخصی (blameless)  را تسهیل می‌کنند تا بفهمند چه چیزی باعث یک موضوع خاص شده است و چگونه می‌توان از تکرار آن جلوگیری کرد و هر گونه بهبودی را که باید انجام شود مستندسازی کرد.

آماده‌سازی: (Preparation)

در نهایت، تیم‌های SRE به توسعه و تیم‌های فناوری اطلاعات کمک می‌کنند تا آمادگی بیشتری داشته باشند، درک بهتری از سلامت خدمات خود و نحوه واکنش سریع و مؤثر به حوادث به دست آورند. ادغام مهندسین قابلیت اطمینان سایت در توسعه و فناوری اطلاعات به توسعه دهندگان این امکان را می دهد تا درباره محیط تولید اطلاعات بیشتری کسب کنند و به تیم های ITOps کمک می کند تا زودتر در چرخه عمر توسعه شرکت کنند. بخش بزرگی از این تلاش شامل آماده سازی استقرار، کار با مهندسان برای اطمینان از قابل مشاهده بودن یک سرویس جدید است. نتیجه یک رویکرد فعال تر و پاسخگو به نگرانی های قابلیت اطمینان است.

“چهار سیگنال طلایی” SRE چیست؟

شیوه های SRE مستلزم مشاهده و شفافیت در همه سرویس ها و برنامه های کاربردی در یک سیستم توزیع شده است. اما اندازه گیری عملکرد و در دسترس بودن خدمات متمایز در این محیط ها پیچیده است. برای کارآمدتر کردن این فرآیند، تیم Google SRE چهار سیگنال طلایی را توسعه داد، یکی از چندین چارچوب برای نظارت بر سیستم‌های توزیع‌شده مؤثر که معیارهایی را ایجاد می‌کند که نشان‌دهنده سلامت سیستم است.

تأخیر: (Latency)

این زمانی است که برای ارائه یک درخواست طول می کشد. تیم‌ها معیاری برای نرخ تأخیر «خوب» تعریف می‌کنند و تأخیر درخواست‌های موفق در برابر درخواست‌های ناموفق را برای ردیابی سلامت سیستم نظارت می‌کنند. با ردیابی تأخیر در کل سیستم، تیم‌های SRE می‌توانند به تشخیص اینکه کدام سرویس‌ها خوب عمل نمی‌کنند و حوادث را زودتر تشخیص دهند.

ترافیک: (Traffic)

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

خطاها: (Errors)

این به میزان شکست درخواست ها اشاره دارد. تیم های SRE باید میزان خطاهای رخ داده در کل سیستم را نظارت کنند، بودجه خطا ایجاد کنند و تعیین کنند که کدام خطاها مهم ترین هستند. این به تیم ها امکان می دهد سلامت یک سرویس را از دیدگاه مشتری درک کنند و برای رفع خطاهای مکرر به سرعت پاسخ دهند.

اشباع: (Saturation)

این به ظرفیت کلی سیستم و منابعی که در دسترس است، اشاره دارد، و تیم‌های SRE را به ظرفیت یک سرویس مشخص می‌دهد. اکثر سیستم‌ها قبل از رسیدن به بهره‌برداری 100% شروع به تخریب می‌کنند، بنابراین تیم‌های SRE باید معیاری برای درصد استفاده «سالم» تعیین کنند، (یعنی معیاری که عملکرد خدمات و در دسترس بودن را برای مشتریان تضمین می‌کند).

مقایسه  نقش SRE با DevOps

بهتر است در ابتدای این قسمت تعریف مختصری از مفهوم DevOps داشته باشیم. این عبارت مخفف دو کلمه development و operations است. کلمه اول به معنای کارها و روش‌هایی است که سبب توسعه نرم‌افزار شده و کلمه دوم به معنای عملیات و کارهای فناوری اطلاعات است. ترکیب این دو با هم باید به توسعه و پیشرفت سیستم نرم‌افزاری کمک کند. در واقع DevOps به سریع اجرا شدن کدهای موجود، پیدا کردن مشکلات و رفع آن‌ها نقش به سزایی را ایفا می‌کند. می‌توان گفت DevOps جزئی از SRE است، اما با این تفاوت که در SRE جایگاه شغلی برای کسی که امور عملیاتی-زیرساختی را انجام می‌دهد، تعیین شده است. این فرد باید کلیه امور برنامه‌نویسی، علوم پایه مربوط به کامپیوتر، مراحل تست نرم‌افزار، نظارت، تنظیمات و توسعه سرویس‌ها را بداند.

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

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

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

نکته آخر:

قابلیت اطمینان را به یکی از ویژگی های توسعه نرم افزار خود تبدیل کنید افزایش و حفظ زمان کار یک مبارزه دائمی برای هر سازمانی است. اما کسب‌وکارهایی که فرآیندهای SRE مؤثری دارند، با انعطاف‌پذیری سیستم بیشتر و در نتیجه درصد بیشتری از انتشار موفقیت‌آمیز، در مقابل رقبای خود برتری دارند. هنگامی که حوادث رخ می دهد، آنها میانگین زمان سریع تری برای تصدیق و تعمیر دارند (MTTA/MTTR). زمان کمتر برای رفع مشکلات تولید به این معنی است که همه تیم ها – توسعه دهندگان، SRE و عملیات – می توانند بر ارائه ارزش تجاری در رشته های خاص خود تمرکز کنند. در نتیجه، قابلیت اطمینان به یک ویژگی توسعه نرم افزار تبدیل می شود تا مانعی برای آن.

منلع