تفاوت SRE و DevOps چیست؟

ابتدا باید مفاهیم پایه دواپس را بیشتر توضیح دهیم. این واژه ترکیبی از دو کلمه توسعه (Development) و عملیات (Operation) است و به آن معنا است که هم‌زمان با توسعه خصوصیات یک محصول، تیم عملیاتی هم برای ایجاد ثبات باید در کنار تیم توسعه حضور داشته باشد. در واقع، تیم توسعه سعی دارد ویژگی‌های محصول را افزایش دهد یا موارد قبلی را بهبود ببخشد اما ایجاد تغییرات باعث ناپایداری در محصول می‌شود. ازاین‌رو، تیم عملیات هم باید تلاش خود را انجام دهد تا محصول قابل‌اطمینان شود. در دواپس، تیم‌ها بر «تحویل مستمر» محصولات دیجیتالِ کاربردی تمرکز می‌کنند. تحویل مستمر یا Continuous Delivery رویکردی در مهندسی نرم‌افزار است که تیم‌ها را قادر می‌کند نرم‌افزار تولیدشده را به روشی سریع و مطمئن برای انتشار و تحویل آماده کنند. این فرایند شامل ساخت، تست، پیکربندی و انتشار در محیط‌های مختلف تست و محیط عملیات می‌شود. به‌عبارت‌دیگر، تحویل مستمر، توانایی اعمال تغییرات در محیط عملیات در هر لحظه با روشی سریع و مطمئن و به‌طور کاملا پایدار است. این تغییرات شامل همه انواع آن از جمله تغییرات پیکربندی در نرم‌افزار، زیرساخت و پلتفرم، افزودن ویژگی‌های جدید، رفع باگ و خطاها می‌شود. این مفهوم در فارسی به «تحویل پیوسته» نیز ترجمه‌شده ‌است. در حالت عادی، روابط بین دو بخش عملیات و توسعه می‌تواند در ادامه یا نتیجه کار به یک تضاد کامل تبدیل شود. زیرا تیم عملیاتی، به تیم توسعه برای کارهایی غیر از گسترش نرم‌افزار فشار می‌آورد، مانند آزمایش و تضمین کیفیت (QA) و این ممکن است باعث برگشت به عقب‌ شود. این‌جایی است که دواپس با یک رویکرد خودکار اجازه می‌دهد تا تیم توسعه هم‌زمان که روی ارائه نرم‌افزار جدید تمرکز می‌کند، عملکرد و اصول تیم عملیاتی را هم حفظ کند. عوامل کلیدی برای ایجاد فرهنگ دواپس عبارتند از: تحویل مداوم با سرعت انتشار بالا، ایجاد رویکرد خودکار در توسعه و این‌که مسئولیت مشترکی بین توسعه و عملیات وجود دارد.

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

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

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

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

• کاهش تعداد بخش‌های مختلف

• ارائه یک ذهنیت که در آن شکست مورد انتظار و پذیرفته‌شده است

• ایجاد تغییرات تدریجی

• خودکارسازی

• نظارت بر موفقیت.

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

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

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

• پیاده‌سازی تغییرات: شرکت‌ها تمایل دارند به‌سرعت نسخه‌های نرم‌افزار خود را منتشر کرده و محصول را به‌طور مستمر به‌روزرسانی کنند. SRE و دواپس، هر دو به دنبال تغییرات هستند.

•  خودکارسازی: خودکارسازی یکی از اهداف مهم در SRE و دواپس است. هر دو سعی دارند با ارائه ابزارها و خودکارسازی بیشتر نیاز به عملیات دستی را کمتر کنند.

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

مزایای زیادی هنگام استفاده از دواپس برای سازمان‌ها ایجاد می‌شود که عبارتند از:

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

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

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

• تشویق نوآوری‌هایی که تمرکز خود را بر ادغام اصول ناب (lean) و چرخه پیاده‌سازی کوتاه‌تر گذاشته‌اند.

• یک ساختار که توانایی هماهنگ کردن و کاهش کشمکش‌ها را داشته باشد.

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

آن دسته از تجارت‌هایی که رو به‌سوی SRE می‌آورند می‌توانند انتظار افزایش ROI، بهبود روابط و چابکی بیشتر را داشته باشند. زیرا SRE به دنبال همان اصول کلیدی دواپس است. هر چند که معمولا SRE به‌عنوان یک رابطه بی‌نقص بین توسعه و عملیات دیده می‌شود. 

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

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