تفاوت Sysadmin، DevOps و SRE

تاریخچه

در گذشته، همواره تقابل و فاصله‌ای میان تیم‌های توسعه نرم‌افزار (Development یا Dev) و تیم‌های عملیات و نگهداری سرورها (Operations یا Ops) وجود داشت. تیم‌های توسعه به دنبال افزودن سریع قابلیت‌های جدید به نرم‌افزار بودند، در حالی که هر تغییر جدید ریسک بروز اختلال در سرورها را به همراه داشت. از سوی دیگر، مدیران سیستم (Sysadmin) که مسئولیت پایداری سرورها را بر عهده داشتند، در برابر تغییرات مقاومت کرده و اصل «تغییر ندادن سیستم در حال کار» را مبنای کار خود قرار می‌دادند. این تضاد منافع، سرعت توسعه و ارائه محصول در سازمان‌ها را به شدت کاهش می‌داد.

درک مفاهیم با تمثیل

برای درک بهتر این مفهوم، می‌توان فرآیند تولید در یک شرکت خودروسازی را در نظر گرفت. فرض کنید تیم طراحی (Dev) یک خودروی اسپرت با سرعت بالا طراحی کرده و آن را برای نگهداری به تیم مکانیک‌ها (Ops) می‌سپارد. مکانیک‌ها پس از مشاهده استهلاک و خرابی‌های مکرر، برای حفظ پایداری، سرعت خودرو را محدود می‌کنند.

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

مفاهیم تخصصی

• مدیر سیستم (Sysadmin): مخفف System Administrator؛ نیروی متخصصی که وظایفی نظیر نصب نرم‌افزار، رفع خرابی‌ها و اعمال به‌روزرسانی‌ها را عمدتاً به صورت دستی و سنتی انجام می‌دهد.

• دواپس (DevOps): یک فرهنگ و فلسفه سازمانی است که بر یکپارچگی تیم‌های توسعه و عملیات تاکید دارد. هدف اصلی این فرهنگ، افزایش سرعت ارائه نرم‌افزار همگام با حفظ کیفیت و پایداری است.

• مهندسی قابلیت اطمینان سایت (SRE): مخفف Site Reliability Engineering؛ رویکرد اختصاصی و مهندسی‌شده شرکت Google برای پیاده‌سازی عملی فرهنگ DevOps است. بر اساس تعریف این شرکت: «SRE زمانی اتفاق می‌افتد که شما از یک مهندس نرم‌افزار بخواهید وظایف یک مدیر سیستم را انجام دهد.» در این رویکرد، مشکلات عملیاتی نظیر قطعی‌ها نه با اقدامات دستی، بلکه از طریق توسعه کد و اتوماسیون برطرف می‌شوند.

برای درک بهتر تفاوت اقدامات دستی و رویکرد مهندسی SRE، فرآیند نصب یک وب‌سرور (مانند Nginx برای نمایش صفحات وب) بر روی سرور مورد بررسی قرار می‌گیرد.

روش سنتی Sysadmin (دستی، زمان‌بر و مستعد خطای انسانی):

در این روش، مدیر سیستم ملزم است وارد تک‌تک سرورها شده و دستورات زیر را به صورت دستی وارد کند:

# ورود به سرور
ssh root@server
 
# به‌روزرسانی لیست برنامه‌ها
apt-get update
 
# نصب برنامه
apt-get install nginx
 
# روشن کردن برنامه
systemctl restart nginx

رویکرد مهندسی SRE (خودکار، قابل تکرار و مقیاس‌پذیر):

در استانداردهای مدرن، از مفهومی تحت عنوان زیرساخت به عنوان کد (Infrastructure as Code) استفاده می‌شود. در این روش، یک فایل پیکربندی ساختاریافته نظیر YAML تدوین می‌گردد تا ابزارهای اتوماسیون بتوانند آن را بدون دخالت و خطای انسانی، به صورت همزمان بر روی هزاران سرور اجرا کنند. این فایل صرفاً وضعیت نهایی مطلوب سیستم را توصیف می‌کند:

server_configuration:
  package: nginx # نام برنامه
  state: present # مطمئن شو که نصب شده است (اگر نیست، خودت نصب کن)
  service: running # مطمئن شو که در حال اجراست (اگر خاموش است، روشنش کن)

یکی از خطاهای متداول در صنعت فناوری اطلاعات، پدیده‌ای به نام Name-only SRE (تغییر نام ظاهری) است. در این حالت، مدیریت سازمان صرفاً عنوان شغلی تیم Sysadmin را به SRE تغییر می‌دهد، در حالی که اعضای تیم همچنان در حال انجام وظایف به صورت دستی و سنتی هستند.

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

در فرآیند جذب و استخدام متخصصان زیرساخت، معمولاً سناریوهای بحرانی برای سنجش دیدگاه مهندسی افراد مطرح می‌شود. فرض کنید در یک سازمان بزرگ، نرم‌افزار اصلی دارای مشکل نشت حافظه (Memory Leak) است؛ به طوری که هر ۱۲ ساعت یک‌بار منابع سرور تکمیل شده و سیستم دچار توقف کامل (Crash) می‌گردد. اگر از یک متخصص ارشد SRE درخواست شود که در شیفت‌های شبانه حضور یافته و پیش از بروز خرابی، سرورها را به صورت دستی راه‌اندازی مجدد (Restart) کند، پاسخ منطبق بر اصول مهندسی چه خواهد بود؟

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