Capacity Advisor و Upgrade Scenarios

1. مسئله واقعی: میانگین آرام، اوج خطرناک

یک سرویس می‌تواند میانگین CPU حدود 45٪ داشته باشد و در عین حال هفته‌ای دو بار با افزایش latency و افت شدید headroom حافظه روبه‌رو شود. اگر فقط میانگین را ببینیم، ممکن است توصیه‌ی کوچک‌کردن ماشین منطقی به نظر برسد؛ اما همان تصمیم می‌تواند در burst بعدی ظرفیت را بدتر کند. در این درس «عدد راحت» را از «شاهد تصمیم‌پذیر» جدا می‌کنیم.

2. مرز این درس

مالک این درس Capacity Evidence & Upgrade Scenario Dossier v1 است. ورودی‌های performance و provenance را مصرف می‌کنیم، اما نتیجه‌ی Performance Lens درس مجاور را دوباره طراحی نمی‌کنیم. همچنین Adapter یا Policy provider را تعریف نمی‌کنیم و هیچ resize، autoscaling یا تغییر production را اجرا نمی‌کنیم. خروجی فقط یک توصیه‌ی bounded و قابل ممیزی است.

3. مدل ذهنی Capacity Advisor

زنجیره‌ی تصمیم چنین است: demand baseline → saturation signals → freshness → bottleneck hypothesis → headroom → scenario set → cost/risk comparison → recommendation state → execution authorization جداگانه. اگر هر حلقه‌ی decisive ضعیف باشد، سیستم باید INSUFFICIENT_DATA، STALE_EVIDENCE، NOT_COMPARABLE، DEFERRED یا UNKNOWN را حفظ کند.

4. Demand Window و Baseline

Baseline باید window، نوع workload، throughput، latency، CPU، memory و رشد demand را با واحد و timestamp روشن ثبت کند. میانگین بدون window معنای تصمیمی ندارد. برای workload تعاملی، window باید burstهای شناخته‌شده را ببیند؛ برای workload ماهانه، یک window هشت‌روزه ممکن است peak اصلی را اصلاً مشاهده نکند.

5. Saturation و Headroom

Utilization بالا با saturation یکی نیست. Saturation زمانی مهم می‌شود که resource به سقف نزدیک است و signalهای خدمت—مثل latency یا throughput—هم اثر آن را نشان می‌دهند. Headroom باید برای resource مرتبط با bottleneck محاسبه شود؛ CPU headroom خوب، memory saturation را خنثی نمی‌کند.

6. Burst و Seasonality

Burst profile مشخص می‌کند اوج‌ها چند بار، چه مدت و با چه دامنه‌ای رخ می‌دهند. Seasonality می‌گوید آیا window فعلی چرخه‌ی واقعی workload را پوشش داده است یا نه. Google Compute Engine فعلاً حقوق‌سایزینگ را با هشت روز داده می‌سازد و صریحاً می‌گوید spikeهای کوتاه یا کم‌تکرار می‌توانند جا بمانند؛ پس observation window یک constraint واقعی است، نه جزئیات تزئینی.

7. Bottleneck Identity

قبل از مقایسه‌ی upgradeها باید بگوییم چه چیزی bottleneck است و چرا. اگر peak memory بالاست، latency هم در همان بازه می‌شکند و CPU پایین می‌ماند، «CPU پایین» شاهد downsizing نیست؛ شواهد به bottleneck حافظه نزدیک‌ترند. اگر bottleneck قابل دفاع نیست، recommendation باید متوقف شود.

8. Autoscaling و Resource Requests

در HPA مبتنی بر resource utilization، utilization نسبت به resource request سنجیده می‌شود. اگر request مرتبط وجود نداشته باشد، metric می‌تواند برای آن Pod تعریف‌نشده باشد. بنابراین «HPA فعال است» به‌تنهایی evidence کامل ظرفیت نیست؛ ابتدا semantics metric و requestها باید معتبر باشند.

9. Freshness و Recommendation Age

هر recommendation باید last_refresh_time یا معادل آن را کنار تازه‌ترین demand event نگه دارد. Recommender گوگل می‌گوید محتوای recommendation وضعیت resource را در زمان refresh بازتاب می‌دهد. اگر بعد از آن spike مهمی رخ داده باشد، recommendation قدیمی است—even اگر هنوز در UI دیده شود.

10. Scenario Set قابل‌مقایسه

حداقل سه گزینه را روی یک evidence package مقایسه کنید: NO_CHANGE، SCALE_OUT و SCALE_UP؛ در صورت نیاز architecture change هم اضافه می‌شود. هر scenario باید change، expected capacity، expected cost، constraint، risk و rollback condition داشته باشد. سناریوهایی که با داده یا cost version متفاوت ساخته شده‌اند NOT_COMPARABLE هستند.

11. Cost، Risk و Rollback

کم‌هزینه‌ترین گزینه لزوماً بهترین نیست. گزینه باید bottleneck را هدف بگیرد، ظرفیت لازم را بدهد، constraint را نشکند و rollback عملی داشته باشد. Cost evidence هم freshness دارد؛ اگر price/cost مدل قدیمی باشد، تصمیم DEFERRED می‌شود تا سناریو دوباره محاسبه شود.

12. Decision States و Authorization

RECOMMEND یعنی شواهد برای پیشنهاد یک scenario کافی‌اند؛ OBSERVE یعنی فعلاً تغییر موجه نیست؛ INSUFFICIENT_DATA یعنی evidence decisive کم است؛ STALE_EVIDENCE یعنی داده‌ی مهم قدیمی است؛ NOT_COMPARABLE یعنی scenarioها روی مبنای مشترک نیستند؛ REJECTED یعنی scenario set نیاز را برآورده نمی‌کند. هیچ‌کدام به‌خودی‌خود execution authorization نیستند.

13. مثال کارشده

در baseline، CPU متوسط 45٪ است اما memory peak به 92٪ می‌رسد و latency از SLO عبور می‌کند. شواهد burst داخل window دیده شده، recommendation تازه است و bottleneck حافظه تأیید می‌شود. از بین scenarioها، SCALE_UP کم‌هزینه‌ترین گزینه‌ای است که headroom لازم را می‌دهد و rollback دارد؛ بنابراین نتیجه RECOMMEND است، نه اجرای خودکار.

14. Negative Cases که باید جلوی shortcut را بگیرند

چهار shortcut ممنوع است: recommendation قدیمی بعد از spike جدید؛ HPA utilization بدون resource request؛ scenarioهای تغییرکرده بدون recompute؛ و provenance مفقود. در هر چهار حالت باید state محدودتر صادر شود، نه اینکه dashboard یا vendor label به‌زور به تصمیم تبدیل شود.

15. Transfer: Batch ماهانه و خروجی قابل تحویل

حالا workload را به batch job با peak ماهانه منتقل کنید. چون peak بیرون window هشت‌روزه‌ی recommender است، baseline تعاملی قابل کپی نیست. Dossier باید INSUFFICIENT_DATA بدهد، COLLECT_BURST_EVIDENCE را پیشنهاد کند و recheck را بعد از پوشش چرخه‌ی ماهانه زمان‌بندی کند. خروجی نهایی باید evidence، scenario comparison، recommendation state و execution authorization جدا را نشان دهد.