SRE مستقلا از DevOps در گوگل توسعه یافت و گوگل آن را Secret Sauce خود و نقطه تفاوت خود با رقبا میدانست، حتی پروژه Borg که بعدا با انتشار عمومی آن به Kubernetes معروف شد از محصولات رویکرد SRE است. تا اینکه عدم ارائه عمومی SRE باعث تعامل سخت تر با مشتریان شد و همزمان در Community حرکت DevOps شروع شده بود. Community به نیازمندی های تئوری SRE و اهمیت آنها پی برده بود و به دنبال پیدا نمودن روش درست پیاده سازی این مفاهیم بود، به همین دلیل دوآپس مجموعه ایی از تجربیات یا Practice هاست که سازمان های مختلف به صورت عمومی به اشتراک گذاشته اند. ( DevOps چیست )

گوگل در نهایت به این نتیجه رسید که تجربیات خود را با سایرین به اشتراک گذارد و در این زمینه چند کتاب رایگان توسط این شرکت تهیه شد.


  • کتاب Site Reliability Engineering که بیشتر رویکردی تئوری دارد
  • کتاب The Site Reliability Workbook که رویکردی عملیاتی دارد
 

 تعریف عمومی SRE به شرح زیر است

SRE is an organizational model for running online services more reliably by teams that are chartered to do reliability-focused engineering work

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

  • Release engineering
  • Change management
  • Monitoring and observability
  • Managing and learning from incidents
  • Self-service automation
  • Troubleshooting
  • Performance
  • The use of deliberate adversity − chaos engineering

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

Production Feedback Loops

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

Data-Informed

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

Appropriate Level of reliability

ارائه یک سرویس ۱۰۰٪ reliable کاریست بس مشکل و می تواند شامل هزینه های بسیاری باشد، تصمیم گیری در مودر میزان reliable بودن یک سرویس بیشتر یک تصمیم تجاری است تا فنی. زمانی که مشکلی بروز می نماید تیم SRE همیشه نقش فعالی در فرآیند Incident response ایفا می نماید و علت این موضوع تعهد این تیم به یادگیری از شکست ها و کاهش مدت زمان قطع شدن سرویسها است. SRE مکانیزمی را ارائه می دهد تا بتوان بودجه Outage ها را مدیریت و پیگیری نمود.

  • SLI یا Service level indicator: چه چیزی اندازه گیری می شود و اندازه گیری کجا اتفاق می افتد
  • SLO یا Service Level Objective: هدف یا threshold مقادیر قابل قبول SLI در یک بازه زمانی مشخص چیست

Sustainable

سرویسها نیازدارند تا یک هدف صحیح Availability بر اساس تحلیل هزنیه و مزایا داشته باشند.

کارهای مهندسی متمرکز بر Reliability

برای اینکه یک تیم به عنوان تیم SRE شناخته شود، نیاز است توجه خود را بر روی کارهایی متمرکز کند که فردا را بهتر از امروز می نماید، تمرکز بر روی کارهایی که مشکلات در پروداکشن را کاهش دهد و یا ابزارها و سیستمهایی که به قابل اطمینان بودن خدمات کمک رساند. بعضی مواقع اینکار شامل پیاده سازی CI/CD پایپلاین می شود، البته این مرحله به عنوان نقطه شروعی در نظر گرفته شده و با توجه به امکان درج انواع کارها مثل حل مشکلات طراحی و کد که باعث کاهش reliability می شوند در پایپلاین یا کار بر روی Monitoring/alerting/observability یا capacity modeling/forecasting را شروع می نماید.

بهبود تدریجی و Organizational Model

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