SRE-بخش دوم

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

همانطور که در بخش اول صحبت شد برای sreها یک سقف 50 درصدی برای زمان کارشان در نظر گرفته شده و بقیه زمان آنها بهتر است که روی مهارت های کد زنی آنها در پروژه ها گذرانده شود. این کار با مانیتور کردن کارهای عملیاتی sre و هدایت کارها و تیکت های مربوط به توسعه دهندگان به خودشان امکان پذیر است. و این قضیه ثابت می کنه که اتومات کردن کارها چقدر می تونه موثر باشه در کم کردن کارها چه در سمت توسعه دهندگان و چه سمت sre و با همین اتومات کردن می شه که کارهای عملیاتی زیادی رو کم کرد تا بتوان به مهارت های کد زدنی پرداخت.

هنگامی که صحبت از کار عملیاتی می شود، sreها باید یک شیفت 8 ساعته ی on-call داشته باشند و در شیفت خود ماکسیمم تا دو رویداد رو دریافت کنند. این باعث می شود تا زمان کافی برای رفع سریع مشکل و برگرداندن سرویس به حالت قبل و یادگیری از آن را داشته باشند. اما اگر رویداد ها بیشتر شوند باعث می شود که نتواند به آن درست رسیدگی کنند و ازمشکلات پیش آمده چیزی یاد بگیرند.

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

پیروی از حداکثر سرعت تغییرات بدون نقض کردن SLO سرویس ها

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

در کل برای هر سرویس یا سیستم، هدف قرار دادن قابلیت اطمینان 100 درصد درست نیست، به خاطر اینکه هیچ کاربری نمی توانمد تفاوت بین یک سیستم 100 درصد در دسترس را با 99.999 درصد تشخیص دهد. در مسیر بین کاربر و سرویس، بسیار سیستم های دیگر موجود می باشد مثل ( لپتاپشون، وای فای خونشون، شرکت سرویس دهنده اینترنتشون و …) و آن سیستم ها جمعا بسیار کمتر از 99.999 درصد در دسترس می باشند. بدین ترتیب تفاوت حاشیه ای بین 99.999 درصد و 100 درصد گم می شود در میان در دسترس نبودن های دیگر و کاربر هیچ منفعتی از تلاش عظیم مورد نیاز برای اضافه کردن 0.001 درصد مابقی در دسترس بودن، نمی برد.

اگر که هدف 100 درصد قابل اطمینان بودن برای سیستم، اشتباه است، پس هدف قابل اطمینان بودن درست برای سیستم چیست؟

این یک سوال فنی نیست در کل، یک سوال از دید تولید است، که برای جواب بهش باید سوال های زیر را در نظر گرفت :

• کاربر با چه میزان از در دسترس بودن راضی است، با توجه به نحوه استفاده آن ها از محصول؟
• چه گزینه هایی برای کاربرانی که ناراضی هستند از در دسترس بودن محصول، موجود است؟
• چه اتفاقی برای استفاده کاربر از محصول در میزان دسترسی های مختلف می افتد؟

بیزینس و محصول باید هدف در دسترس بودن سیستم را تعیین کند. سرویسی که 99.999 درصد در دسترس است، 0.001 درصد در دسترس نیست.  که این 0.001 درصد از در دسترس نبودن می شود بودجه ی خطای سرویس. ما می توانیم ین بودجه ی خطا را برای هرچیز که بخواهیم خرج کنیم تا زمانی که زیاده روی نکنیم.

پس ما چطور این بودجه ی خطا رو خرج کنیم؟

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

نحوه ی استفاده از بودجه ی خطا، تداخل ساختاری بین توسعه و sre را حل میکند.

مانیتورینگ

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

سه نوع مورد قبول خروجی مانیتورینگ وجود دارد:

• هشدارها :

مشخص می کند که یک فرد نیاز است تا سریعا واکنشی نشان دهد در پاسخ به چیزی که در حال رخ دادن است یا اینکه رخ داده است، به منظور بهبود وضعیت.

• تیکت ها :

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

• لاگ زدن :

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

پاسخ اضطراری

قابلیت اطمینان تابعی از زمان متوسط تا شکست و زمان متوسط تا تعمیر است. مهمترین معیار در ارزیابی اثربخشی موارد پاسخ اضطراری این است که چقدر سریع گروه پاسخ دهی می تواند سلامت سیستم را برگردانند.

افراد تاخیر ایجاد می کنند. حتی اگر یک سیستم معین شکست واقعی بیشتری را تجربه کند، سیستمی که می تواند از موارد اضطراریی که نیاز به مداخله انسان دارد جلوگیری کند، HA بیشتری نسبت به سیستمی که نیازمند مداخله عملی دارد، دارد.

مدیریت تغییرات

sre به این دست پیدا کرده است که 70 درصد از قطع شدن ها مربوط به تغییرات زنده در سیستم است. اتوماتیک سازی بهترین روش موجود در این زمینه برای انجام موارد زیر می باشد:

•  اجرای برنامه های متناوب عرضه به بیرون
•  شناسایی سریع و دقیق مشکلات
•  بازگردانی سریع تغییرات در هنگام بروز مشکل

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

پیش بینی تقاضا و برنامه ریزی ظرفیت

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

چند مرحله اجباری است در برنامه ریزی ظرفیت:

• یک پیش بینی دقیق تقاضا، که فراتر از زمان برای کسب ظرفیت مورد نظر است
• ادغام دقیق منابع تقاضا در پیش بینی تقاضا
• تست لود منظم سیستم (سرورها، دیسک ها و غیره) به اندازه ظرفیت سرویس

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

تامین کنندگی

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

کارایی و عملکرد

زمانی که مسئله مالی مهم باشد، استفاده کارآمد از منابع نیز مهم است. به دلیل اینکه sre مسئول کنترل تامین می باشد، باید در هر کاری که مربوط به سودمندی است مشارکت کند ، سودمندی تابعی است از اینکه سرویس ارائه شده چگونه کار می کند و تامین می شود.

استفاده از منابع تابعی است از لود، ظرفیت و کارآمدی نرم افزار. Sreها لود را حدس می زنند، ظرفیت را تامین می کنند و نرم افزار را تنظیم می کنند. این سه کار، بزرگترین قسمت از کارآمدی سرویس هستند.

سیستم های نرم افزاری هر چه لود بر روی شان زیاد شود، کندتر می شوند. کندی در سرویس مساوی است با ضرر ظرفیتی. Sreها باید یک سرعت پاسخ دهی مشخص به عنوان هدف برای تامین ظرفیت در نظر بگیرند و به پرفورمنس سرویس اهمیت بدهند.

تیم های sre و توسعه، سرویس را مانیتور و تنظیم می کنند تا پرفورمنس آن را بهبود دهند، برای کارآمدی بیشتر.

پایان شروع 

قابل اطمینان سازی سایت یک زنگ تفریح قابل توجه را نشان می دهد از best practice های سازمان ها برای مدیریت سرویس های بزرگ و خسته کننده. به عنوان یک مهندس نرم افزار، این همان چیزی است که می خواهیم تا وقت خودمان را بگذاریم تا تسک های تکرار شونده را انجام دهیم.

مجموعه ای از اصول ، مجموعه ای از اقدامات ، مجموعه ای از مشوق ها و زمینه ای برای تلاش در مهندسی نرم افزار. بقیه کتاب به طور دقیق مسیر  sreرا بررسی می کند