مقدمه

نوشتهٔ Benjamin Treynor Sloss
ویرایش Betsy Beyer

«امید، استراتژی نیست.»
یک ضرب‌المثل سنتی در SRE

این حقیقتی پذیرفته‌شده است که سیستم‌ها خودشان را اداره نمی‌کنند. پس یک سیستم—به‌خصوص یک سیستم محاسباتی پیچیده با مقیاس بسیار بزرگ—چطور باید اداره شود؟

 

رویکرد Sysadmin به مدیریت سرویس

در گذشته، شرکت‌ها برای اجرای سیستم‌های محاسباتی پیچیده از Systems Administrators (Sysadmins) استفاده می‌کردند.

در این رویکرد، sysadmin‌ها مجموعه‌ای از کامپوننت‌های نرم‌افزاری موجود را کنار هم قرار می‌دهند و آن‌ها را deploy می‌کنند تا یک سرویس ایجاد شود. سپس مسئول اجرای سرویس و پاسخ‌گویی به رویدادها و تغییرات هستند. با رشد پیچیدگی و افزایش حجم ترافیک—که رویدادها و تغییرات بیشتری ایجاد می‌کند—تعداد sysadminها نیز باید افزایش یابد. به دلیل تفاوت مهارت‌های sysadmin با توسعه‌دهندگان، این دو گروه معمولاً به دو تیم مجزا تقسیم می‌شوند: Development و Operations (Ops).

رویکرد sysadmin مزایایی دارد: اجرای آن ساده است، نیروی انسانی ماهر در بازار وجود دارد و ابزارها و کامپوننت‌های آماده زیادی برای ساخت سرویس در دسترس هستند.

اما این مدل معایب و هزینه‌هایی نیز دارد:

  • هزینه‌های مستقیم: افزایش هزینه با رشد سرویس، زیرا کارها دستی هستند.

  • هزینه‌های غیرمستقیم: ناشی از تفاوت فرهنگ، انگیزه‌ها، زبان مشترک و درک ریسک بین Dev و Ops. این اختلافات می‌تواند به بی‌اعتمادی و تضاد تبدیل شود.

در مدل سنتی، تیم‌های Dev و Ops معمولاً سر سرعت Release اختلاف دارند:

  • Dev می‌خواهد سریع featureهای جدید را release کند.

  • Ops می‌خواهد سیستم پایدار باقی بماند و outage رخ ندهد، زیرا اکثر outageها حاصل تغییرات هستند.

برای مدیریت این تضاد، Ops معمولاً فرآیندهایی مثل Launch Gates، Change Reviews، Rollout Checklists ایجاد می‌کند، در حالی‌که Dev تلاش می‌کند این محدودیت‌ها را دور بزند (مثلاً با feature flag، incremental rollout، sharding و …).

 

رویکرد Google به مدیریت سرویس: Site Reliability Engineering

تضاد میان Dev و Ops اجتناب‌ناپذیر نیست. Google مدل متفاوتی را انتخاب کرده است: Site Reliability Engineering (SRE) — یعنی استخدام Software Engineers برای اجرای عملیات و نوشتن سیستم‌هایی که کارهای تکراری sysadminها را خودکار کنند.

تعریف ساده:
SRE یعنی وقتی از یک Software Engineer بخواهید یک تیم Operations طراحی کند.

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

ترکیب تیم SRE

  • ۵۰–۶۰٪: Software Engineers استخدام‌شده با معیارهای کامل Google

  • ۴۰–۵۰٪: تقریباً معادل مهندسان نرم‌افزار Google + مهارت‌های ویژه مانند
    UNIX Internals، Networking (Layer 1–3)

ویژگی مشترک:
تمایل و توانایی ساخت ابزار و سیستم برای حل مسائل پیچیده از طریق software automation.

این باعث می‌شود SREها:

  • از کار دستی به‌سرعت خسته شوند،

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

قانون ۵۰٪ Google

Google یک سقف ۵۰٪ کار عملیاتی (Ops Work) برای SRE تعریف کرده است:
مثل on-call، tickets، manual procedures.
نیم دیگر زمان باید صرف Engineering / Development شود.

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

 

مزایا و چالش‌های مدل SRE

مزایا

  • سرعت نوآوری بالا

  • پذیرش تغییر

  • نیاز به نیروی انسانی کمتر (scaling sublinear)

  • از بین رفتن شکاف Dev/Ops

  • کراس‌ترینیگ طبیعی بین تیم‌ها

چالش‌ها

  • فرایند استخدام سخت (نیاز به مهارت‌های قوی نرم‌افزار و سیستم)

  • کمبود منابع آموزشی در صنعت

  • نیاز به پشتیبانی مدیریتی قوی

  • تصمیمات سخت مثل توقف release پس از اتمام Error Budget

 

DevOps یا SRE؟

اصطلاح DevOps از ۲۰۰۸ مطرح شد و اصولی مثل:

  • مشارکت IT در کل چرخهٔ توسعه،

  • reliance بر automation،

  • استفاده از engineering practices در operations

در DevOps و SRE مشترک هستند.
می‌توان گفت:

  • DevOps = تعمیم اصول SRE برای صنایع مختلف

  • SRE = پیاده‌سازی سخت‌گیرانه و مهندسی‌شدهٔ DevOps در Google

 

اصول SRE

SRE مسئول موارد زیر است:
Availability، Latency، Performance، Efficiency، Change Management، Monitoring، Emergency Response، Capacity Planning.

۱. تمرکز پایدار بر Engineering

SRE باید کم‌تر از ۵۰٪ زمان خود را روی Ops بگذارد.
اگر تیم بیش‌ازحد Ops کار کند:

  • tickets به Dev برمی‌گردد

  • Dev به on-call چرخه اضافه می‌شود

  • تا حجم Ops دوباره به زیر ۵۰٪ برسد

۲. On-call و Incident Response

هدف: حداکثر ۲ alert در هر شیفت ۸–۱۲ ساعته
Postmortemها باید blameless باشند و حتی برای incidentهایی که alert ندادند نوشته شوند.

۳. Error Budget

راه‌حل تضاد Dev و SRE.

اگر SLO مثلاً 99.99% باشد:
Error Budget = 0.01%

این بودجه برای risk کردن در feature launch استفاده می‌شود.

Outage دیگر «بد» نیست؛ بخشی طبیعی از innovation است.

۴. Monitoring

سه خروجی معتبر:

  • Alerts → اقدام فوری انسان

  • Tickets → اقدام غیر فوری

  • Logging → جهت diagnosis

Alertها نباید نیاز به interpretation انسانی داشته باشند.

۵. Emergency Response

MTTR مهم‌ترین معیار است.
استفاده از playbook باعث ~۳ برابر بهبود MTTR می‌شود.
تمریناتی مانند Wheel of Misfortune برای آمادگی تیم اجرا می‌شود.

۶. Change Management

۷۰٪ outageها ناشی از تغییر است.
راهکار:

  • Progressive Rollout

  • Automated Rollback

  • Accurate Detection

۷. Capacity Planning

باید هم organic growth و هم inorganic growth لحاظ شود.
نیازمند load testing منظم و forecasting دقیق است.

۸. Provisioning

رابطهٔ مستقیم با capacity planning و change management دارد، ریسک‌پذیر است و باید دقیق انجام شود.

۹. Efficiency & Performance

چون SRE مسئول provisioning است، باید بر utilization نظارت کند.

SRE بر سه عامل اصلی کنترل دارد:

  • Load

  • Capacity

  • Software Efficiency

 

پایان

SRE یک تغییر اساسی نسبت به روش‌های سنتی Ops است. SRE مجموعه‌ای از اصول، روش‌ها و انگیزه‌هاست که در نهایت تبدیل به یک شاخهٔ مستقل در مهندسی نرم‌افزار شده است.