بازگشت به کتابخانهکتابخانه15.2SRE واقعی: حادثه، Postmortem و Load Shedding
طراحی سیستم نرم‌افزاریSYSTEM DESIGNاز صفر تا تسلط
v1.0.0
01مبانی و تصویر بزرگ
02Scalability و ظرفیت
03لایه داده
04Cache، Queue و جریان
05معماری نرم‌افزار
06قابلیت اطمینان و عملیات
07متد طراحی
08Case Study های واقعی
09سیستم‌های توزیع‌شده عمیق
10مهندسی تولید: داده، امنیت و کارایی
11تمرین پیشرفته و کیس‌استادی‌های مکمل
12زیر کاپوت دیتابیس و معماری داده
13وب بلادرنگ و پروتکل‌های مدرن
14سیستم‌های توزیع‌شده پیشرفته
15SaaS ،SRE ،امنیت و شبکه پیشرفته
16طراحی سیستم در عصر AI
17Case Study های تکمیلی
LESSON 15.2فصل ۱۵SaaS ،SRE ،امنیت و شبکه پیشرفته

SRE واقعی: حادثه، Postmortem و Load Shedding

  • ~۱۴ دقیقه
  • ۴ پرسش
  • متن را انتخاب کن تا هایلایت شود

فصل ۶ ابزارها را داد (مانیتورینگ، افزونگی). این درس فرایند است: وقتی ساعت ۳ بامداد همه‌چیز می‌سوزد، تیم بالغ چه می‌کند — و مهم‌تر، چه مکانیزم‌هایی از قبل سوختن را محدود کرده است.

چرخه حیات حادثه

  • تشخیص → مهار → حل → یادگیری. در مهار، هدف «کمترین آسیب در سریع‌ترین زمان» است، نه ریشه‌یابی: rollback ،failover ،feature flag خاموش — ریشه را بعداً پیدا کن.
  • نقش‌ها روشن: Incident Commander (تصمیم و هماهنگی)، Ops (دست‌ها)، Comms (اطلاع‌رسانی به ذی‌نفعان). در حادثه بزرگ، دموکراسی وقت‌کش است.
  • Severity از پیش تعریف‌شده: SEV1 = کاربران/درآمدِ واقعی در خطر (همه بیدار)، SEV2 = افت محسوس با workaround، SEV3/4 = جزئی. هر SEV سطح پاسخ و اطلاع‌رسانی خودش را دارد.
  • On-call سالم: شیفت محدود و چرخشی، هشدار فقط برای «قابل اقدام» (فصل ۶)، و بودجه خطا (Error Budget) که حد تعادل سرعت و پایداری را روشن می‌کند.

Postmortem بدون سرزنش

  • ساختار: چه رخ داد (timeline دقیق با لاگ/متریک)، چرا رخ داد (زنجیره علت‌ها، نه «خطای انسانی» — انسان جزئی از سیستم است)، چه چیزهایی خوب کار کرد، اقدام‌های اصلاحی با مالک و مهلت.
  • Blameless به معنای بدون مسئولیت نیست؛ یعنی تحلیلِ «چرا سیستم اجازه این خطا را داد» به‌جای «چه کسی زد». اگر یک دستور rm می‌تواند دنیا را خاموش کند، تقصیر rm نیست — تقصیر سیستمی است که چنین تیغی را لبه میز گذاشته.
  • حادثه‌ای که postmortem‌اش اقدام اصلاحی ندارد، فقط تمرین نوشتن بوده.

مهار فشار قبل از فروپاشی

Load Shedding
زیر فشار افراطی، عمداً و کنترل‌شده بخشی از بار را رد کن: درخواست‌های ارزان‌اثر اول (پیشنهادگر، آمار) تا هسته (checkout) زنده بماند. 429 با Retry-After بهتر از timeout بی‌نهایت است.
Deadline Propagation
مهلت از لبه تعیین و بین فراخوانی‌ها پخش می‌شود: اگر ۲۰۰ms مهلت کلی مانده، لایه سوم نباید ۵ ثانیه صبر کند. gRPC deadline همین را استاندارد کرده.
Adaptive Concurrency
به‌جای صف ثابت، محدودکننده‌ای که با دیدن تأخیر/خطا، همزمانی را خودکار پایین می‌آورد — جلوی اشباع قبل از وقوع.

حلقه کامل را ببین: Error Budget (فصل ۶) می‌گوید چقدر شلختگی تحوّل‌پذیر است؛ هشدار SLO-محور می‌گوید کی بودجه دارد سریع می‌سوزد؛ حادثه و postmortem سیستم را اصلاح می‌کند. SRE یعنی این چرخه، نه فقط «داشبورد داشتن».

به زبان ساده

SRE یعنی برای حادثه از قبل برنامه داشته باشی: نقش‌ها روشن، مهار قبل از ریشه‌یابی، و گزارش بدون سرزنش که سیستم را اصلاح کند.

مثال واقعی

ساعت ۳ بامداد فروشگاه down است؛ فرمانده حادثه اول نسخه قبلی را برمی‌گرداند (مهار)، بعد با خونسردی و با timeline ریشه را پیدا می‌کند — نه وسط آتش، تحقیق.

دانش‌سنجی

آزمون درس

۴ Q
01
در میانه حادثه SEV1 اولویت چیست؟
02
«Blameless postmortem» یعنی؟
03
Load Shedding دقیقاً چه می‌کند؟
04
Deadline Propagation جلوی چه چیزی را می‌گیرد؟