نکات کلیدی
۱. اهداف سطح سرویس (SLO) قطب‌نمای تصمیم‌گیری درباره قابلیت اطمینان
پس از آشنایی با چند راهنمایی، تعیین اهداف اولیه SLO و فرآیند بهبود آن‌ها می‌تواند ساده باشد.
اهداف سطح سرویس راهنمای اولویت‌ها هستند. اهداف سطح سرویس (SLO) در مهندسی قابلیت اطمینان سایت (SRE) اهمیت بنیادین دارند، زیرا چارچوبی مبتنی بر داده برای تصمیم‌گیری درباره تخصیص منابع مهندسی محدود فراهم می‌کنند. به جای تلاش برای دستیابی به قابلیت اطمینان ۱۰۰٪ غیرممکن، SLOها اهداف واقع‌بینانه‌ای بر اساس نیازهای کاربران و اهداف کسب‌وکار تعیین می‌کنند که به تیم‌ها امکان می‌دهد توسعه ویژگی‌ها را با کار روی قابلیت اطمینان متعادل کنند. بودجه خطا که از SLO استخراج می‌شود، میزان قابل قبول از کار افتادگی یا کاهش عملکرد را کمّی می‌کند و به‌عنوان سیگنالی روشن عمل می‌کند که نشان می‌دهد چه زمانی باید قابلیت اطمینان بر ویژگی‌های جدید اولویت یابد.
با سادگی شروع کنید و مکرراً بهبود دهید. اجرای SLOها نیازی به کمال از روز اول ندارد. ابتدا چند شاخص سطح سرویس (SLI) کلیدی که مسیرهای حیاتی کاربران را نشان می‌دهند، مانند در دسترس بودن یا تأخیر، شناسایی و اندازه‌گیری کنید. از این اندازه‌گیری‌ها برای تعیین اهداف اولیه SLO استفاده کنید، حتی اگر بر اساس عملکرد فعلی باشند. مهم‌ترین گام، جلب توافق ذی‌نفعان بر سر این اهداف و تعهد به استفاده از بودجه خطا در تصمیم‌گیری است.
SLOها تیم‌ها را توانمند می‌سازند. اهداف سطح سرویس تعریف‌شده و سیاست بودجه خطای روشن، داده‌های عینی لازم را در اختیار تیم‌های SRE و توسعه قرار می‌دهد تا در برابر درخواست‌های غیرواقع‌بینانه مقاومت کنند یا توجیهی برای سرمایه‌گذاری در پروژه‌های قابلیت اطمینان داشته باشند. این موارد مباحث ذهنی درباره «چه میزان قابلیت اطمینان کافی است» را به گفت‌وگوهای ملموس مبتنی بر تأثیر بر کاربر و ارزش کسب‌وکار تبدیل می‌کند. این درک مشترک همکاری بهتر را تقویت کرده و اطمینان می‌دهد که کار روی قابلیت اطمینان به‌درستی اولویت‌بندی می‌شود.
۲. تجربه کاربر را اندازه‌گیری کنید، نه فقط معیارهای سیستم
کاربران شما، نه ابزارهای نظارت، قابلیت اطمینان را تعیین می‌کنند.
تمرکز بر رضایت کاربر. هدف نهایی SRE تضمین رضایت کاربران از طریق ارائه خدمات قابل اعتماد است. بنابراین مهم‌ترین معیارها آن‌هایی هستند که مستقیماً تجربه کاربر را منعکس می‌کنند، نه فقط شاخص‌های سلامت داخلی سیستم. در حالی که استفاده از CPU یا فضای دیسک برای اشکال‌زدایی مفید است، این معیارها نمی‌گویند آیا کاربران واقعاً می‌توانند از سرویس شما به‌خوبی استفاده کنند یا خیر.
SLIها تجربه را ثبت می‌کنند. شاخص‌های سطح سرویس باید برای اندازه‌گیری جنبه‌هایی از سرویس انتخاب شوند که برای کاربران اهمیت بیشتری دارند. نمونه‌های رایج عبارتند از:
- در دسترس بودن (درخواست‌های موفق / کل درخواست‌ها)
- تأخیر (درخواست‌های سریع‌تر از X میلی‌ثانیه / کل درخواست‌ها)
- صحت (نتایج صحیح / کل نتایج)
- تازگی (داده‌های به‌روز شده اخیراً / کل داده‌ها)
اندازه‌گیری نزدیک به کاربر. برای ثبت دقیق تجربه کاربر، SLIها باید تا حد امکان نزدیک به کاربر اندازه‌گیری شوند. ابزارهای سمت کلاینت یا لاگ‌های بار متعادل‌کننده معمولاً منابع بهتری نسبت به لاگ‌های سرور برنامه هستند، زیرا اثرات شبکه و مشکلات رابط کاربری را نیز شامل می‌شوند. به‌طور منظم اندازه‌گیری‌های SLI را با بازخورد کاربران از طریق تیکت‌های پشتیبانی یا شبکه‌های اجتماعی مقایسه کنید تا اطمینان حاصل شود که معیارها با قابلیت اطمینان درک‌شده هم‌راستا هستند.
۳. با مهندسی، کارهای تکراری و خسته‌کننده را بی‌رحمانه حذف کنید
برای SRE، هر کار عملیاتی دستی و ساختاریافته نفرت‌انگیز است.
کارهای تکراری مانع پیشرفت‌اند. کار تکراری به معنای کار دستی، مکرر، قابل خودکارسازی و تاکتیکی است که ارزش پایدار ندارد و حداقل به اندازه سرویس پشتیبانی‌شده رشد می‌کند. در حالی که برخی کارهای عملیاتی ضروری‌اند، کار تکراری بیش از حد مانع انجام کارهای مهندسی لازم برای بهبود سیستم‌ها و کاهش کار تکراری آینده می‌شود. محدودیت ۵۰٪ کار عملیاتی (شامل کار تکراری) در گوگل مکانیزمی است برای تضمین زمان برای پروژه‌های استراتژیک.
شناسایی، اندازه‌گیری، خودکارسازی. نخستین گام برای حذف کار تکراری، شناسایی آن برای تیم و اندازه‌گیری زمان صرف‌شده روی آن است. این داده‌های عینی را برای اولویت‌بندی تلاش‌های خودکارسازی بر اساس صرفه‌جویی زمانی و بازگشت سرمایه فراهم می‌کند. فقط کار را خودکار نکنید؛ با رفع علت ریشه‌ای که نیاز به کار دستی را ایجاد می‌کند، کار تکراری را از سیستم مهندسی خارج کنید.
راهبردهای کاهش کار تکراری:
- کار تکراری را رد کنید: هزینه انجام کار را در برابر عدم انجام آن تحلیل کنید.
- پاسخ خودکار بسازید: ابزارهایی برای انجام کارهای مکرر به‌صورت برنامه‌ریزی‌شده ایجاد کنید.
- خدمات خودکار فراهم کنید: کاربران را توانمند سازید تا از طریق API یا رابط کاربری کارها را خودشان انجام دهند.
- یکنواختی را افزایش دهید: سیستم‌ها و فرآیندها را استاندارد کنید تا خودکارسازی آسان‌تر شود.
- از SLOها استفاده کنید: اجازه دهید بودجه خطا تعیین کند چه زمانی مداخله دستی لازم است.
حذف کار تکراری فرآیندی مستمر است که نیازمند حمایت مدیریت و فرهنگی است که خودکارسازی را به‌عنوان یک ویژگی ارزشمند می‌پذیرد.
۴. برای افزایش قابلیت اطمینان، طراحی را ساده نگه دارید
یک سیستم پیچیده که کار می‌کند، معمولاً از یک سیستم ساده که کار می‌کرده تکامل یافته است.
سادگی شکست را کاهش می‌دهد. سیستم‌های ساده ذاتاً قابل اعتمادترند زیرا اجزای کمتری دارند، تعاملات کمتری دارند و فهم، نگهداری و اشکال‌زدایی آن‌ها آسان‌تر است. پیچیدگی، برعکس، حالت‌های شکست بیشتری ایجاد می‌کند و حل مشکلات را دشوارتر می‌سازد.
سادگی باید از ابتدا تا انتها باشد. تلاش کنید سادگی را نه فقط در کد، بلکه در معماری سیستم، وابستگی‌ها، پیکربندی و فرآیندهای عملیاتی حفظ کنید. مهندسان SRE به دلیل دید جامع خود از سیستم در محیط تولید، موقعیت ویژه‌ای برای ترویج سادگی از ابتدا تا انتها دارند. آن‌ها را تشویق کنید که در بازبینی‌های طراحی از مراحل اولیه شرکت کنند تا ریسک‌های پیچیدگی را شناسایی و کاهش دهند.
راهبردهای بازگرداندن سادگی:
- اجزای یا ویژگی‌های غیرضروری را حذف کنید.
- فناوری‌ها و فرآیندها را در سازمان استاندارد کنید.
- بخش‌های پیچیده سیستم را به‌تدریج بازسازی کنید.
- پروژه‌های ساده‌سازی را اولویت‌بندی و حذف کد را جشن بگیرید.
- سیستم را نمودار کنید تا تعاملات پیچیده مانند تقویت یا وابستگی‌های چرخه‌ای را شناسایی کنید.
پیچیدگی یک هزینه خارجی است؛ هزینه آن اغلب بر دوش کسانی است که سیستم را اداره می‌کنند، نه کسانی که آن را ایجاد کرده‌اند. مبارزه فعال با پیچیدگی برای سلامت و پایداری بلندمدت سیستم حیاتی است.
۵. پاسخ به حادثه را به‌خوبی مدیریت کنید و از هر شکست بیاموزید
همه می‌خواهند خدماتشان همیشه روان کار کند، اما ما در دنیایی ناقص زندگی می‌کنیم که قطعی‌ها رخ می‌دهند.
ساختار، هرج‌ومرج را کاهش می‌دهد. حوادث اجتناب‌ناپذیرند. داشتن فرآیند پاسخ به حادثه تعریف‌شده، معمولاً بر اساس چارچوب‌هایی مانند سیستم فرماندهی حادثه (ICS)، برای هماهنگی تلاش‌ها، ارتباط مؤثر و حفظ کنترل در بحران ضروری است. نقش‌های روشن (فرمانده حادثه، مسئول ارتباطات، مسئول عملیات) و کانال‌های ارتباطی، سردرگمی را کاهش می‌دهند.
کاهش تأثیر را اولویت دهید. در طول حادثه، هدف اصلی توقف سریع تأثیر بر کاربران (کاهش تأثیر) است، حتی اگر علت ریشه‌ای هنوز به‌طور کامل شناخته نشده باشد. ابزارهای عمومی کاهش تأثیر (مانند بازگردانی یا تخلیه ترافیک) باید از پیش آماده باشند. تحلیل علت ریشه و رفع دائمی پس از حل حادثه انجام می‌شود.
بازنگری‌های پس از حادثه، عامل یادگیری‌اند. هر حادثه، صرف‌نظر از اندازه، فرصتی برای یادگیری است. فرهنگ بازنگری بدون سرزنش برای ایجاد اعتماد و اطمینان از شناسایی مشکلات سیستمی به جای سرزنش افراد ضروری است. بازنگری‌های خوب باید:
- واقعی و عینی باشند
- با جزئیات و تأثیر قابل اندازه‌گیری همراه باشند
- شامل اقدامات مشخص، اولویت‌بندی‌شده و مسئول‌دار باشند
- به‌طور گسترده برای یادگیری سازمانی به اشتراک گذاشته شوند
آموزش‌ها و تمرین‌های منظم پاسخ به حادثه حافظه عضلانی ایجاد کرده و تیم‌ها را برای شرایط اضطراری واقعی آماده می‌کند و زمان متوسط پاسخ (MTTR) و زمان متوسط کشف (MTTD) را کاهش می‌دهد.
۶. تغییرات و استقرارها را به‌صورت ایمن خودکار کنید (کاناری کردن)
کاناری کردن، استقرار جزئی و محدود به زمان یک تغییر در سرویس و ارزیابی آن است.
تغییر، ریسک اصلی است. تغییرات (کد، پیکربندی، داده) برای پیشرفت ضروری‌اند اما شایع‌ترین عامل بروز حادثه هستند. خودکارسازی فرآیند انتشار (CI/CD) نخستین گام است که ساخت‌های قابل تکرار و تست‌شده و استقرارهای خودکار را تضمین می‌کند. با این حال، محیط‌های تست نمی‌توانند به‌طور کامل تولید را شبیه‌سازی کنند.
کاناری کردن ریسک را کاهش می‌دهد. کاناری کردن بخشی از ترافیک تولید را به تغییر جدید اختصاص می‌دهد و تأثیر آن را پیش از استقرار کامل ارزیابی می‌کند. این امکان شناسایی نقص‌ها در محیط کنترل‌شده را فراهم می‌کند، شعاع آسیب را کاهش داده و بودجه خطا را حفظ می‌کند. اندازه و مدت زمان کاناری باید نمایانگر الگوهای ترافیک باشد و زمان کافی برای تثبیت معیارها فراهم کند.
معیارهای مرتبط را ارزیابی کنید. ارزیابی کاناری بر مقایسه معیارهای جمعیت کاناری با گروه کنترل تکیه دارد. معیارهایی را انتخاب کنید که نشانگر مشکلات قابل درک برای کاربر (مانند SLIها) باشند و به تغییر مورد آزمایش نسبت داده شوند. از معیارهایی که به‌راحتی تحت تأثیر عوامل خارجی قرار می‌گیرند یا به‌وضوح تأثیر بر کاربر را نشان نمی‌دهند، اجتناب کنید.
- کدهای بازگشتی HTTP (به‌جز خطاهای مشتری)
- صدک‌های تأخیر
- بررسی‌های صحت خاص برنامه
ارزیابی کاناری را در خط لوله انتشار خودکار خود ادغام کنید تا در صورت شکست کاناری، بازگردانی خودکار انجام شود.
۷. بار کاری را به‌صورت جامع مدیریت کنید تا سیستم‌ها مقیاس‌پذیر باشند
هیچ سرویسی ۱۰۰٪ در تمام زمان‌ها در دسترس نیست: مشتریان بی‌ملاحظه‌اند، تقاضا ممکن است پنجاه برابر شود، سرویس ممکن است در پاسخ به افزایش ترافیک سقوط کند یا لنگر ممکن است کابل ترانس‌آتلانتیک را بالا بکشد.
مدیریت بار چندوجهی است. تضمین در دسترس بودن و عملکرد سرویس تحت بارهای متغیر و غیرمنتظره نیازمند ترکیبی از راهبردهاست، نه فقط یک ابزار. تعادل بار، مقیاس خودکار و کاهش بار اجزای کلیدی هستند که باید هماهنگ کار کنند. پیکربندی نادرست تعامل آن‌ها می‌تواند منجر به شکست‌های زنجیره‌ای شود.
تعادل بار ترافیک را هدایت می‌کند. سیستم‌هایی مانند Google Cloud Load Balancing (GCLB) از تکنیک‌هایی مانند anycast و مسیریابی پیشرفته (Maglev، GFE) برای هدایت درخواست‌های کاربران به نزدیک‌ترین بک‌اند سالم با ظرفیت موجود استفاده می‌کنند. این کار تأخیر را به حداقل می‌رساند و به‌صورت شفاف از شکست‌ها عبور می‌کند.
مقیاس خودکار ظرفیت را تنظیم می‌کند. مقیاس خودکار به‌صورت پویا تعداد نمونه‌ها را بر اساس معیارهای بار (مانند استفاده CPU یا درخواست‌ها در ثانیه) افزایش یا کاهش می‌دهد. این بهینه‌سازی منابع و جذب افزایش ترافیک را ممکن می‌سازد. پیکربندی صحیح نیازمند تعیین محدودیت‌ها، مدیریت نمونه‌های ناسالم و در نظر گرفتن تأثیر بر وابستگی‌های پایین‌دستی است.
کاهش بار از اضافه بار محافظت می‌کند. وقتی سیستم‌ها فراتر از ظرفیت خود فشار می‌بینند، کاهش بار به آن‌ها اجازه می‌دهد ترافیک اضافی را به‌صورت کنترل‌شده رد کنند تا به‌جای سقوط کامل، عملکرد اصلی حفظ شود. مهم است که سیگنال‌های کاهش بار (مانند پاسخ‌های خطا) به‌درستی توسط تعادل بار و مقیاس خودکار تفسیر شوند تا از نتایج معکوس جلوگیری شود.
۸. طراحی پیکربندی برای سلامت عملیاتی اهمیت دارد
کیفیت رابط انسان-کامپیوتر در پیکربندی سیستم بر توانایی سازمان در اجرای قابل اعتماد آن سیستم تأثیر می‌گذارد.
پیکربندی یک رابط حیاتی است. پیکربندی امکان تغییر سریع رفتار سیستم بدون استقرار کد را فراهم می‌کند. طراحی آن تأثیر قابل توجهی بر کار تکراری عملیاتی، قابلیت اطمینان و توانایی پاسخ به حوادث تحت فشار دارد. پیکربندی ضعیف منجر به خطا، سردرگمی و هدررفت تلاش می‌شود.
فلسفه و مکانیک را جدا کنید. ابتدا بر فلسفه پیکربندی تمرکز کنید:
- پیکربندی از کاربران سوال می‌پرسد؛ سوالات اجباری را به حداقل برسانید.
- سوالات باید به اهداف کاربر نزدیک باشند، نه جزئیات زیرساخت.
- پیش‌فرض‌های معقول (ثابت یا پویا) ارائه دهید که برای اکثر کاربران کارآمد باشند.
- برای کاربران حرفه‌ای امکان «راه‌های فرار» برای نادیده گرفتن پیش‌فرض‌ها فراهم کنید.
مکانیک (زبان، فرمت، ابزار) باید از این فلسفه پشتیبانی کند. زبان پیکربندی (نحوه نوشتن) را از داده‌های پیکربندی (نمایش ثابت که برنامه مصرف می‌کند) جدا کنید.
ابزارها ضروری‌اند. سیستم‌های پیکربندی خوب ابزارهایی برای:
- اعتبارسنجی معنایی (بررسی معقول بودن پیکربندی)
- برجسته‌سازی نحو، بررسی قواعد و قالب‌بندی خودکار
- نسخه‌بندی، پیگیری مالکیت و ثبت تغییرات
فراهم می‌کنند. تغییرات پیکربندی را به‌صورت ایمن از طریق استقرار تدریجی اعمال کرده و قابلیت بازگردانی آسان و قابل اعتماد را تضمین کنید.
۹. سیستم‌های عملی با طراحی غیرانتزاعی بسازید
همه سیستم‌ها در نهایت باید روی کامپیوترهای واقعی در دیتاسنترهای واقعی با شبکه‌های واقعی اجرا شوند.
طراحی باید مبتنی بر واقعیت باشد. طراحی سیستم‌های بزرگ غیرانتزاعی (NALSD) فرآیندی تکراری برای طراحی سیستم‌های توزیع‌شده در مقیاس بزرگ است که ایده‌های انتزاعی را به‌طور مداوم در واقعیت ملموس ریشه‌دار می‌کند. این فرآیند طراحان را مجبور می‌کند از ابتدا محدودیت‌های دنیای واقعی مانند محدودیت‌های سخت‌افزاری، تأخیر شبکه و حوزه‌های شکست را در نظر بگیرند.
فرآیند طراحی تکراری:
۱. آیا ممکن است؟ طراحی سیستمی که اصولاً کار می‌کند، بدون توجه به محدودیت‌های عملی.
۲. آیا می‌توان بهتر کرد؟ بهینه‌سازی طراحی پایه برای کارایی.
۳. آیا عملی است؟ مقیاس‌بندی طراحی با در نظر گرفتن محدودیت‌های واقعی (هزینه، سخت‌افزار و غیره) که ممکن است نیازمند معماری توزیع‌شده باشد.
۴. آیا مقاوم است؟ طراحی برای کاهش تدریجی و مقاومت در برابر شکست اجزا یا دیتاسنتر.
۵. آیا می‌توان بهتر کرد؟ پالایش طراحی مقیاس‌یافته و مقاوم.
منابع را زود کمّی کنید. در هر مرحله، منابع مورد نیاز (CPU، RAM، دیسک، شبکه) را بر اساس فرضیات واقع‌بینانه درباره بار کاری و عملکرد اجزا برآورد کنید.
آخرین به‌روزرسانی::
نقد و بررسی
کتاب «دفترچه کار قابلیت اطمینان سایت» عمدتاً با بازخوردهای مثبت مواجه شده است و خوانندگان از رویکرد عملی و مثال‌های واقعی آن تمجید می‌کنند. بسیاری این کتاب را مکمل ارزشمندی برای کتاب اصلی SRE می‌دانند که دیدگاه‌های کاربردی درباره‌ی پیاده‌سازی شیوه‌های SRE در سازمان‌های مختلف ارائه می‌دهد. تمرکز بر موضوعاتی مانند اهداف سطح سرویس (SLO)، وظایف شیفتی و بررسی‌های پس از حادثه از نکات مورد توجه خوانندگان است. هرچند برخی نقدهایی درباره‌ی تکرار مطالب و ساده‌سازی بیش از حد در بخش‌هایی از کتاب مطرح کرده‌اند. به طور کلی، این کتاب به عنوان منبعی مفید برای علاقه‌مندان به اصول SRE شناخته می‌شود که هم جزئیات فنی و هم راهنمایی‌هایی درباره‌ی مدیریت تیم و فرهنگ سازمانی ارائه می‌کند.
Similar Books
