SRE-بخش اول

معرفی

این حقیقت وجود دارد که سیستم ها به صورت خود به خود نمی توانند کار کنند، پس چطور یک کامپیوتر، اون هم کامپیوترهایی پیچیده در سطح بالا باید کار کنند؟

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

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

معایب و مشکلات رویکرد ادمین سیستم و جداسازی توسعه و عملیات

رویکرد ادمین سیستم و جداسازی عملیات و توسعه دو نوع هزینه دارد: هزینه های مستقیم و هزینه های غیر مستقیم

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

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

هر دو گروه باید درک کنند که نباید منافع خودشان را فقط در نظر بگیرند. هر دو گروه اغلب به خاطر فرضیات و نوع ریسک متفاوتشان همیشه در جنگ و جدل هستند. (گروه توسعه می گوید: ما می خواهیم هرچیزی را عرضه کنیم، در هر زمانی بدون هیچ مانعی. از طرف دیگر گروه عملیات می گوید: ما نمی خواهیم که هرگز چیزی را در سیستم تغییر دهیم تا زمانی که مطمئن شویم کار می کند.) گروه عملیات با ایجاد موانع و دروازه هایی برای عرضه تغییرات، تلاش می کند تا سیستم را در برابر ریسک ها ایمن سازی کند. برای مثال بررسی هایی برای عرضه تعریف می کند شامل یک چک لیست از مواردی که تا به حال باعث قطعی سیستم شده است. گروه توسعه هم برای مقابله با این موضوع عرضه های محصول را خرد می کند تا موضوع کمتری برای بررسی گروه عملیات وجود داشته باشد.

رویکرد گوگل به مدیریت سرویس

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

مهندسی قابل اطمینان سازی سایت چیست؟

SRE زمانی اتفاق می افتد که از یک مهندس نرم افزار می خواهید که یک گروه عملیات طراحی کند. در سال 2003 گوگل یک گروه متشکل از 8 مهندس نرم افزار تشکیل داد تا وظیفه ی SRE را به عهده بگیرند. گوگل ترکیب گروه SRE را به این صورت چید که 60-50 درصد گروه مهندسین نرم افزار هستند و مابقی 40-50 درصد کسانی هستند که مهارت های SRE را دارند، مهارت هایی که برای مهندسین نرم افزار نادر است. ماند کار با سیستم های یونیکس و تخصص شبکه ای.

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

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

چطور این سقف ها را اعمال کنیم؟

ما باید اطمینان حاصل کنیم که گروه SRE، 50 درصد از وقتشان را صرف تمرین و انجام کار های مربوط به توسعه می شود، برای این کار بهتر است که به یکسری از افراد کارهای عملیاتی ندهیم تا وقتشان را به توسعه بگذرانند.

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

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

Devops یا SRE ؟

اصطلاح Devops در سال 2008 در صنعت ظهور کرد و همچنان در حال گسترش می باشد. هسته ی مرکزی کار آن ها درگیر کردن فعالیت های IT در فاز های طراحی و توسعه ی سیستم، اتوماسیون کردن و به کارگیری ابزارهای کاربردی در کارهای عملیاتی می باشد. با اصول و تمرین های SRE می توان آن را تکمیل کننده ی Devops دانست.

اصول SRE

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