Fleet Rollout: Test→Canary→Batch→Fleet

1. نصب موفق، مجوز Fleet rollout نیست

یک release ممکن است روی یک Test node کاملاً سالم باشد و در مقیاس بزرگ به‌دلیل تفاوت سخت‌افزار، نسخه سیستم‌عامل، workload یا شبکه شکست بخورد. بنابراین command success یا گذشتن یک timer فقط evidence اجرای یک مرحله است، نه evidence کافی برای promotion. تصمیم rollout باید به release digest، cohort مشخص، health window کامل و budgetهای اعلام‌شده متصل باشد.

2. مرز مالکیت LOC-017

این درس فقط Progressive Fleet Rollout & Halt Ledger را مالک است: TEST → CANARY → BATCH → FLEET. تشخیص و reconcile کردن drift در LOC-016 است و restore/watchdog در LOC-018. اگر node بعد از rollout از desired state منحرف شد، این درس فقط evidence آن را در gate استفاده می‌کند؛ منطق reconcile را تصاحب نمی‌کند.

3. Release را قبل از هر cohort قفل کن

rollout_id به‌تنهایی کافی نیست. هر stage باید همان release_digest و release_generation مورد تأیید را حمل کند. اگر digest بین canary و batch عوض شد، evidence canary دیگر برای artifact جدید معتبر نیست؛ stage باید BLOCKED شود و rollout با binding جدید دوباره evidence بسازد.

4. TEST فقط کوچک‌ترین blast radius است

TEST برای کشف سریع failureهای بدیهی و بررسی basic health مفید است، اما نماینده تمام fleet نیست. نتیجه سالم TEST فقط اجازه می‌دهد candidate وارد CANARY شود، آن هم وقتی baseline و post-update probe ثبت شده و health window کامل باشد. TEST سالم هرگز مستقیماً FLEET را مجاز نمی‌کند.

5. CANARY را با cohort و health window تعریف کن

Canary باید selector، planned nodes، reachable nodes و observation window روشن داشته باشد. در Cloud Deploy، canary به‌صورت progressive phase قبل از stable اجرا می‌شود و analysis می‌تواند پیش از advance به phase بعدی قرار گیرد. در MAKNOW این pattern فقط مرجع است: promotion باید از evidence خود fleet شما بیاید، نه از نام محصول.

6. Disruption Budget مرز هم‌زمانی است

VM Manager امکان zone-by-zone یا concurrent-zone rollout و disruption budget را نشان می‌دهد. در قرارداد MAKNOW، disruption_budget سقف اختلال مجاز در cohort است. اگر شمار nodeهای disrupted یا failed از budget عبور کند، rollout نباید با این استدلال که «بقیه سالم‌اند» ادامه یابد؛ تصمیم باید HALT یا در صورت داشتن rollback evidence، ROLLBACK باشد.

7. BATCH باید bounded و قابل تکرار باشد

بعد از CANARY، fleet را به batchهای محدود تقسیم کن. برای هر batch همان digest، selector، health probes، failure budget و pause point را تکرار کن. Azure VM Scale Sets نیز rolling update را batch-based و متکی به health limits طراحی می‌کند؛ این فقط یک reference pattern برای کنترل batch است، نه policy آماده MAKNOW.

8. Reachable با Planned یکی نیست

planned_nodes، reachable_nodes و updated_nodes را جدا ثبت کن. node unreachable را نباید به‌صورت ضمنی از denominator حذف کرد تا نرخ موفقیت بهتر دیده شود. اگر exclusion واقعاً مجاز است، باید node، دلیل، owner و recheck point ثبت شود؛ در غیر این صورت stage برای promotion BLOCKED است.

9. Health Window باید کامل شود

یک probe سبز بلافاصله بعد از نصب می‌تواند transient باشد. health_window باید زمان و معیار خاتمه روشن داشته باشد و baseline با post-update health مقایسه شود. اگر درست قبل از پایان window یک canary unhealthy شود، positive signalهای قبلی override نمی‌کنند؛ gate باید fail شود.

10. Failure Budget با Disruption Budget فرق دارد

Disruption budget درباره حداکثر اختلال هم‌زمان است؛ failure budget درباره تعداد/نسبت failure قابل‌تحمل برای تصمیم promotion است. ممکن است concurrency کاملاً رعایت شده باشد ولی failure budget در batch دوم بشکند. آن‌وقت rollout باید متوقف یا rollback شود، نه اینکه batch سالم قبلی به‌عنوان مجوز ادامه استفاده شود.

11. Promotion یک تصمیم Evidence-driven است

PROMOTE فقط وقتی صادر می‌شود که artifact binding ثابت، cohort evidence کامل، health window تمام، updated/reachable counts سازگار، unhealthy count داخل budget و هیچ contradiction باز وجود نداشته باشد. در FLEET stage، وقتی همه evidenceهای مورد نیاز بسته شدند، state می‌تواند CONVERGED شود؛ قبل از آن fleet success ادعا نکن.

12. HALT و ROLLBACK را از قبل تعریف کن

halt_condition و rollback_target را قبل از rollout ثبت کن. HALT یعنی پیشروی متوقف می‌شود و نیاز به recheck/repair وجود دارد. ROLLBACK یعنی artifact جدید روی nodeهای تغییرکرده باید به target قبلی برگردد و rollback evidence نیز ثبت شود. rollback بدون target و verify فقط یک intent است.

13. Worked Example: canary دیرهنگام خراب می‌شود

Release R42 روی TEST سالم است. CANARY دو node دارد؛ یکی سالم می‌ماند و دیگری چند دقیقه مانده به پایان health window restartهای غیرعادی نشان می‌دهد. installer هر دو node success برگردانده، اما post-update health gate شکست خورده و failure budget صفر است. نتیجه صحیح promotion نیست؛ stage باید ROLLBACK یا HALT شود و fleet همچنان untouched بماند.

14. Failure Probeهای قطعی

چهار mutation را اجرا کن: یک canary درست قبل از بسته‌شدن health window unhealthy شود؛ ۲۰٪ یک batch unreachable بماند؛ digest بین canary و batch عوض شود؛ و در batch دوم failure budget شکسته شود. هر mutation باید state تایپ‌شده، audit_event و next action روشن تولید کند؛ هیچ‌کدام نباید با «install command موفق بود» پوشانده شوند.

15. Transfer: دو Site با connectivity ناپایدار

در Transfer، fleet بین دو site تقسیم می‌شود و Site B اتصال ناپایدار دارد. cohort size، disruption budget و pause point را دوباره محاسبه کن و unreachable nodeها را صریح نگه دار. اگر evidence Site B کامل نیست، decision baseline را کپی نکن؛ stage باید BLOCKED بماند تا recheck یا exclusion مجاز و مستند انجام شود. Contract ثابت است، اعداد و evidence با محیط جدید عوض می‌شوند.