Repair Patch Classes, Canary و Rollback

1. مسئله: Green Test مساوی Safe Rollout نیست

یک Incident در درس قبلی reproduce شده و حالا Patch candidate داریم. اشتباه رایج این است که بعد از چند Test سبز، Patch را مستقیم روی همه کاربرها ببریم. این درس به‌جای «اعتماد به حس»، یک قرارداد Release قابل ممیزی می‌سازد: Patch Classification, Canary & Rollback Plan v1.

2. مرز درس

PLN-028 مالک Diagnostics اولیه نیست؛ reproduction_ref را از PLN-027 مصرف می‌کند. همچنین مالک Architecture مرز Venture در ARC-001 نیست. خروجی این درس فقط طبقه‌بندی Patch، Canary/Control، Observation، Promote/Abort Gate و Rollback است.

3. FACT خارجی و DESIGN داخلی

Google SRE Canary را deployment جزئی و محدود در زمان می‌داند که evaluate می‌شود تا درباره ادامه rollout تصمیم بگیریم. Kubernetes هم rollout history، rollback و canary با چند Deployment را مستند می‌کند. اما Patch classها، Thresholdها و Stateهای این درس MAKNOW DESIGN هستند.

4. Patch را قبل از Rollout طبقه‌بندی کن

حداقل کلاس‌ها: CODE، CONFIG، DEPENDENCY، DATA_SCHEMA، POLICY. اگر یک علت reproduce‌شده واقعاً به تغییر اتمیک چند Surface نیاز دارد، COMPOSITE_BOUNDED مجاز است؛ ولی دو Repair نامرتبط را در یک Canary قاطی نکن.

5. Identity: Patch، Incident و Change Set

سه هویت باید جدا اما متصل باشند: incident_id، patch_id و change_set_hash. اگر Change Set بعد از تعریف Canary تغییر کند، نتیجه قبلی دیگر Oracle نسخه جدید نیست و باید Plan دوباره evaluate شود.

6. Reproduction Reference شرط ورود است

reproduction_ref باید به Evidence قابل‌تکرارِ همان Failure اشاره کند. Unit Test جدید مفید است، اما بدون پیوند به Failure reproduce‌شده، نشان نمی‌دهد Patch همان علت را برطرف کرده است. نبود این Ref → HOLD.

7. Rollback را قبل از Canary اثبات کن

Rollback target باید Known-good و قابل شناسایی باشد؛ feasibility فقط «یک دستور داریم» نیست. باید بدانیم rollback چه چیزی را برمی‌گرداند، چه چیزی را برنمی‌گرداند و چگونه بعد از rollback صحت را verify می‌کنیم. Target نامعلوم یا rollback ناممکن → HOLD/BLOCKED.

8. Canary و Control را هم‌زمان نگه دار

Canary باید یک subset محدود باشد و Control نسخه پایدار را هم‌زمان نگه دارد تا signal attributable شود. Comparison فقط قبل/بعد از تغییر برای این Contract کافی نیست. Cohortها باید ID و Scope روشن داشته باشند.

9. Observation Window از Failure Mode می‌آید

Window عدد ثابت نیست. Failure سریع مثل crash شاید زود دیده شود؛ Failure دیررس مثل config cache drift یا queue backlog به Window طولانی‌تر نیاز دارد. Window کوتاه‌تر از زمان بروز Failure → INCONCLUSIVE/HOLD.

10. Success و Abort Signal را از قبل بنویس

Success signalها باید بگویند چه چیزی باید بهتر/پایدار بماند؛ Abort signalها باید بگویند چه چیزی فوراً Promotion را متوقف می‌کند. Average سالم نمی‌تواند یک Abort signal فعال را خنثی کند.

11. Error-budget Guard و Promotion Gate

Promotion فقط وقتی مجاز است که Window کامل شده، Success signalها پاس باشند، Abort signal فعال نباشد، Guard نقض نشده باشد و Rollback هنوز Verified باشد. هر Gate decisive است؛ رأی‌گیری اکثریت نداریم.

12. Baseline — Patch ترکیبی اما محدود

Incident INC-482 با یک dependency regression و routing condition مرتبط reproduce شده است. هر دو تغییر یک Cause و یک rollback target دارند، پس COMPOSITE_BOUNDED قابل دفاع است. Canary=5%، Control=stable 95%، Window=30m؛ Success=error-rate parity + no queue regression؛ Abort=canary error delta > 2pp یا crash. همه Gateها پاک → PROMOTE.

13. سه Shortcut خطرناک

1. دو Repair نامرتبط را در یک Canary جمع کنی → attribution از بین می‌رود و HOLD. ۲) بدون rollback target Canary را شروع کنی → HOLD. ۳) Abort signal فعال باشد ولی Average کل خوب باشد → ROLLBACK، نه Promotion.

14. Transfer — Config Patch با Failure دیررس

در Transfer، Patch فقط CONFIG است و rollback action سریع است؛ اما Failure signal بعد از حدود 120 دقیقه در cache refresh ظاهر می‌شود. Window baseline 30m دیگر معتبر نیست. Plan جدید Window=180m، post-rollback verification=180m و Abort signal متناسب با delayed cache mismatch دارد. اگر Window کامل و signalها پاک باشند، می‌تواند PROMOTE شود.

15. Lab، Assessment و Freshness

در lab/PLN-028-LAB1/learner/ دستور python run_checks.py را اجرا کن. ۸ Fixture شامل Baseline، Missing Reproduction، Missing Rollback، Abort Active، Mixed Unrelated Repairs، Stale Evidence، Short Delayed Window و Transfer هستند. FACTهای خارجی تا تاریخ درج‌شده recheck شده‌اند؛ تغییر Canonical Package نیازمند Version جدید است.