Immutable Public Rollback و Route Monitoring

1. Rollback یعنی عوض‌کردن pointer، نه بازنویسی release

اگر release شکست‌خورده را ویرایش کنیم تا «شبیه نسخه قبلی» شود، دیگر نمی‌توانیم دقیقاً ثابت کنیم چه بایت‌هایی فعال بوده‌اند. در این درس هر release هویت immutable دارد و rollback فقط یک رویداد جدید برای تغییر active_release_pointer است.

2. مرز مالکیت CON-010

CON-010 مالک خود rollback عمومی و evidence پس از switch است. CON-006 routing locale، CON-007 versioning workspace، CON-008 فرم‌ها و CON-009 canonical/redirect policy را مالک‌اند. این درس فقط evidence آن‌ها را برای recovery مصرف می‌کند.

3. هویت release را از نام deploy جدا کن

release_id و release_manifest_digest باید target دقیق را مشخص کنند. عباراتی مثل «نسخه دیروز»، «آخرین stable» یا نام یک فولدر mutable برای rollback authority کافی نیستند.

4. مدل Git فقط یک الگوی ذهنی است

Git objectها را با object ID محتوایی نام‌گذاری می‌کند و refها pointerهای نام‌دار به objectها هستند. این الگو کمک می‌کند فرق snapshot identity و pointer را بفهمیم؛ اما MAKNOW release دقیقاً Git commit یا ref نیست.

5. قبل از switch، target باید از قبل verified باشد

Rollback به releaseای که digest آن ناشناخته، verification آن ناقص یا immutable بودنش نامشخص است، rollback امن نیست. چنین targetی باید BLOCK_ROLLBACK شود، حتی اگر قدیمی و ظاهراً سالم باشد.

6. Authorization و pointer event را ثبت کن

رکورد rollback حداقل باید incident، target release/digest، authorization، pointer قبل و بعد، pointer_event_id و زمان/منشأ تصمیم را ثبت کند. تاریخچه pointer overwrite نمی‌شود؛ event جدید append می‌شود.

7. Switch موفق فقط شروع verification است

خروجی «deployment succeeded» یا تغییر pointer به release قبلی فقط control-plane را نشان می‌دهد. recovery public باید از data-plane با probe روی routeهای واقعی اثبات شود.

8. HTTP status یک بُعد است، نه کل سلامت

RFC 9110 status classها و redirect semantics را تعریف می‌کند. 200 روی route مهم است، اما ممکن است همان route محتوای release اشتباه را سرو کند؛ پس status باید کنار content identity سنجیده شود.

9. Content digest نسخه فعال را ثابت می‌کند

برای routeهای کلیدی، digest یا fingerprint محتوای مورد انتظار release rollback را با پاسخ واقعی مقایسه کن. 200 با digest متعلق به failed release باید PARTIAL_RECOVERY بماند.

10. Canonical و redirect را بعد از rollback دوباره probe کن

Google Search Central در migrationها روی بررسی redirectها، canonical annotationها و crawl/indexing errors تأکید دارد. اگر صفحه rollback شده ولی canonical یا redirect هنوز به release/URL نامعتبر اشاره می‌کند، recovery کامل نیست.

11. Locale و form probe را حذف نکن

ممکن است صفحه اصلی سالم شود اما یک locale route یا endpoint فرم خراب بماند. scope recovery باید routeهای موردنیاز را صریح نام ببرد؛ چیزی که probe نشده نباید با حدس «سالم» علامت بخورد.

12. Recovery state باید typed باشد

RECOVERY_CONFIRMED فقط وقتی مجاز است که target معتبر، event مجاز و append-only، pointer صحیح و تمام probeهای لازم در monitor window پاس باشند. در غیر این صورت PARTIAL_RECOVERY، ROLLBACK_FAILED یا BLOCK_ROLLBACK را حفظ کن.

13. Negative case: pointer درست، redirect غلط

فرض کن pointer به release R41 برگشته، statusها 200 و digest صفحه درست است، اما /old-pricing هنوز به مسیر failed release هدایت می‌شود. این مورد را success نکن؛ علت دقیق REDIRECT_MISMATCH باید باقی بماند.

14. Transfer: صفحه‌ها برگشته‌اند، فرم و یک redirect نه

در incident دوم، page routes و canonicalها سالم‌اند ولی form endpoint unhealthy است و یک redirect هنوز target قدیمی دارد. evidence pack را از نو بساز و نتیجه را تا رفع هر دو مشکل PARTIAL_RECOVERY نگه دار.

15. خروجی قابل ممیزی

Evidence Pack باید Incident، Failed Release/Digest، Rollback Target/Digest، Pointer Before/After، Authorization/Event، Expected Route Set، status/content/canonical/redirect/locale/form probes، monitor window، recovery state، reason و provenance را ثبت کند. قوی‌ترین claim فقط برای همین scope و همین evidence معتبر است.