Let’s travel together.

sre چیست؟ برای کسب و کار شما DevOps مناسب‌تر است یا sre ؟

زمان مطالعه: 7 دقیقه

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

در این مطلب قصد داریم بدانیم sre چیست و همچنین دو رویکرد دواپس و sre چه تفاوتی دارند؟

Sre چیست؟

sre چیست

Sre مخفف عبارت Site reliability engineering و به معنی «مهندسی قابلیت اطمینان سایت» است. به زبان ساده، معنی sre  عبارت است از یک سری قاعده و قانون که جنبه‌های مختلف مهندسی نرم افزار را با هدف مقیاس پذیرکردن و قابل اطمینان‌ کردن هر چه بیشتر سیستم‌های نرم افزاری، با مسائل زیرساختی و عملیاتی فناوری اطلاعات پیوند می‌زند.

بنابراین در پاسخ به سوال Site reliability engineering چیست، می‌توانیم بگوییم که Sre نوعی رویکرد است که طرز تفکر مهندسی نرم افزار را به وظایف و مشکلات مدیران سیستم و تیم عملیات پیوند می‌زند. هدف این رویکرد، ایجاد سیستم‌های توزیع شده و مقیاس پذیر نرم افزاری با قابلیت اطمینان بسیار بالا است.

تاریخچه sre چیست؟

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

«وقتی شما از یک مهندس نرم افزار می‌خواهید که فعالیتی زیرساختی و عملیاتی انجام دهد، نقش sre به وجود می‌آید.»

تیم sre در سازمان، زمان خود را صرف کار بر روی تماس‌های عملیاتی و سایر نرم افزارهای در حال توسعه و همچنین اضافه کردن تنظیمات و ویژگی‌های برنامه می‌کند.

علت شکل گرفتن تفکر sre چیست؟

شکل گیری تفکر sre

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

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

تیم sre از چه افرادی تشکیل شده است؟

به طور کلی تیم sre از افرادی با سابقه فعالیت در زمینه مدیریت سیستم و تیم‌های عملیاتی و همچنین دارای توان و دانش برنامه نویسی تشکیل شده است. تیم sre می‌تواند یک تیم جدید در سازمان باشد و یا از ترکیبی از تیم‌های سابق با تغییراتی در نقش‌ها و مهارتهای آن‌ها تشکیل شود.

همیشه مقداری از وقت مهندسان تیم sre به انجام «فعالیت‌های عملیاتی» مانند رسیدگی به مشکلات، تیکت‌ها، تماس‌های تلفنی، پشتیبانی‌های ضروری و… اختصاص پیدا می‌کند. درصدی دیگر از زمان آن‌ها نیز صرف خودکارسازی، بهبود، ارتقا و کار بر روی مقیاس پذیری سیستم می‌شود. خوب است بدانید که کمتر شدن سهم کارهای عملیاتی، به این معنی است که سیستم در مسیر درستی حرکت می‌کند.

شباهت‌های دو رویکرد DevOps  و sre چیست؟

شباهت دواپس و sre

هر چند که به نظر می‌رسد فلسفه DevOps و sre کاملا با هم متفاوت است، اما توجه داشته باشید که هر دو رویکرد تعاریف نسبتا یکسان و مشابهی از موفقیت دارند. این مضامین عبارتند از:

  • کاهش تعداد بخش‌های سازمانی

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

  • انتظار شکست و پذیرش آن

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

  • پشتیبانی از سیستم خودکارسازی یا اتوماسیون

خودکارسازی یکی از مهم‌ترین اهداف sre و DevOps است هر دو سیستم سعی می‌کنند با اتوماسیون بیشتر، نیاز به عملیات دستی را کمتر کنند.

  • اندازه گیری و نظارت مداوم بر مراحل پیشرفت و موفقیت

یک جریان کاری خودکار و در حال تغییر، به نظارت مستمر و مداوم نیاز دارد. چرا که دو تیم DevOps  و sre باید مطمئن شوند که در مسیر درست قرار دارند. البته توجه داشته باشید که رویکرد sre ، عملیات را به عنوان یک مشکل نرم افزاری در نظر می‌گیرد و برای اندازه‌گیری بازدهی، میزان دسترسی و… یک راه مشخص و معین ارائه می‌دهد.

  • ایجاد تغییر

هر دو رویکرد sre و DevOps به دنبال تغییر هستند. سازمان‌ها تمایل دارند که نسخه‌های نرم افزار خود را به سرعت منتشر کرده و آن را به صورت مستمر به روز رسانی کنند.

برای آشنایی با DevOps، مطلب فرآیند دواپس چیست را بخوانید.

تفاوت دو رویکرد DevOps و sre چیست؟

تفاوت sre و دواپس

هر چند این دو رویکرد، با وجود دیدگاه‌های یکسان، به هم شبیه هستند و در بعضی قسمت‌ها هم‌پوشانی دارند، اما نمی‌توانیم تفاوت‌های آن‌ها را نادیده بگیریم. اما مهم‌ترین تفاوت DevOps و sre چیست؟ در این بخش به بررسی تفاوت این دو متدولوژی خواهیم پرداخت.

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

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

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

رویکرد sre برای چه کسب و کارهایی مناسب است؟

sre برای چه کارهایی مناسب است

رویکرد sre برای کسب و کارهایی مناسب است که به مدیریت سیستم‌ها در مقیاس بزرگ نیاز دارند. شرکت‌هایی مانند  Google، Netflix، DropBox و… در هدایت و رهبری این رویکرد نقش مهمی ایفا می‌کنند. توجه داشته باشید که برای پیاده سازی موفق sre باید اطمینان داشته باشید که سازمان شما دارای افراد متخصص و با تجربه در جای مناسب است، تا تیم‌های توسعه را به شکل عملیاتی هدایت کند.

هر چند که معمولا روش sre را به عنوان یک رابطه بین توسعه و عملیات در نظر می‌گیرند، اما کسب و کارهایی که از روش sre استفاده می‌کنند، می‌توانند انتظار افزایش ROI، بهتر شدن تعاملات و روابط کاری و همچنین چابکی بیشتر را نیز داشته باشند.

دواپس یا sre ؟ کدام را انتخاب کنیم؟

کدام را انتخاب کنیم

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

همچنین بررسی کنید، به کارگیری کارمندان جدید، همکاری با ارائه دهندگان خدمات فناوری اطلاعات، اجرای فرآیندهای جدید و… چگونه و تا چه اندازه بودجه فناوری اطلاعات شما را تحت تاثیر قرار می‌دهد؟ علاوه براین، تعیین کنید که خروجی محصول شما DevOps (انتشار سریع نسخه‌های دیجیتال برای رشد درآمد) است یا sre (چارچوبی گسترده با تمرکز بر بهبود مستمر و مداوم) ؟

بنابراین نمی‌توانیم به راحتی بگوییم دواپس کارآمدتر و مناسب‌تر است یا sre ، اما به هر حال مشخص است که هر سازمانی که بخواهد در هریک از این رویکردها تغییری ایجاد کند، باید همراه با تغییرات بزرگ سازمانی، فرهنگی و تولیدی باشد.

و در انتها…

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

مطالب مشابه

ارسال نظر

آدرس ایمیل شما منتشر نخواهد شد.