تست Shift-Right چیست؟ راهنمای امن Testing in Production

نسخهٔ جدید بدون خطا Deploy شده و همه تست‌های Staging سبزند؛ پنج دقیقه بعد، نرخ پرداخت «نامشخص» در یک اپراتور موبایل بالا می‌رود. مشکل فقط در ترکیب ترافیک، DNS، Feature Flag، PSP و داده‌ای دیده می‌شود که هیچ محیط آزمایشگاهی دقیقاً بازسازی نکرده بود. Shift‑right برای دیدن همین واقعیت عملیاتی است؛ اما Production آزمایشگاه آزاد نیست و کاربر واقعی نباید نقش Test fixture را بازی کند.

این راهنما نشان می‌دهد تست Shift‑Right و Testing in Production را چگونه ایمن طراحی کنیم: Monitoring، RUM، Synthetic، Canary، Feature Flag، Shadow، A/B و Chaos را از هم جدا می‌کنیم؛ پیش‌شرط، مجوز، Blast Radius، Stop Condition، Rollback و حریم خصوصی را تعریف می‌کنیم؛ سپس یک انتشار تدریجی برای سرویس تطبیق پرداخت ایرانی می‌سازیم.

تست Shift-Right چیست؟

Shift‑Right Testing انتقال همه تست‌ها به انتهای چرخه نیست. این رویکرد حلقه کیفیت را به سمت راست Pipeline ادامه می‌دهد تا رفتار Artifact مستقرشده، پیکربندی واقعی، ترافیک واقعی و وابستگی‌های عملیاتی مشاهده یا به‌صورت کنترل‌شده اعتبارسنجی شوند.

عبارت «Testing in Production» دامنه فعال‌تری دارد: Synthetic transaction، Post-deploy smoke، Canary evaluation، Shadow comparison یا Fault experiment می‌تواند در Production اجرا شود. Monitoring و Real User Monitoring معمولاً Observation هستند؛ وقتی با فرضیه، Expected result و Gate همراه شوند، ورودی Verification می‌سازند.

نیت جست‌وجو و کلیدواژه‌ها

کلیدواژهٔ اصلی «تست Shift‑Right» است. عبارت‌های مکمل شامل «تست در پروداکشن»، «Testing in Production»، «Shift Right Testing»، «Canary Testing»، «Synthetic Monitoring»، «Shadow Testing»، «Feature Flag Testing»، «Progressive Delivery»، «RUM» و «تست پس از استقرار» هستند. مخاطب QA/SDET، DevOps، SRE، توسعه‌دهنده و Release Manager است.

Shift-right مکمل Shift-left است

Shift‑left می‌پرسد «زودترین شاهد اقتصادی را کجا می‌گیریم؟» Shift‑right می‌پرسد «Artifact در سامانهٔ زنده و تحت شرایط واقعی چه رفتاری دارد؟» اولی Contract، Unit، Integration، Security و Performance را زودتر اجرا می‌کند؛ دومی فرض‌های محیطی، Rollout، عملیات و رفتار واقعی را بازخورد می‌دهد.

باگ Production باید به Test/Check/Telemetry سمت چپ تبدیل شود. اگر تیم فقط Incident را خاموش کند و Regression یا Guardrail نسازد، حلقه یادگیری بسته نشده است.

Production آخرین محیط تست نیست؛ محیط کاربر است

سه اصل مرزی:

• Production evidence جای تست پیش‌تولید را نمی‌گیرد.
• نبود شبیه‌سازی کامل Production مجوز ایجاد ریسک نامحدود نیست.
• هر فعالیت فعال باید Benefit مورد انتظارش از Harm محتمل بیشتر و در Policy مجاز باشد.

تغییرات Schema، Security control، Payment logic و Data migration باید پیش از Production شواهد کافی داشته باشند. در Production فقط شکاف‌هایی را هدف بگیرید که به پیکربندی، Scale، Traffic، Dependency یا Release mechanics وابسته‌اند.

هفت تکنیک که نباید یکی نامیده شوند

تکنیک	نوع	سؤال اصلی	اثر روی کاربر
Monitoring/APM	Observation	سامانه چه می‌کند؟	معمولاً بدون تغییر رفتار
RUM	Observation	کاربر واقعی چه تجربه‌ای دارد؟	جمع‌آوری Telemetry
Synthetic	Active verification	Journey کنترل‌شده کار می‌کند؟	ترافیک/داده تست
Canary	Deployment + evaluation	نسخه تازه سالم‌تر/هم‌سطح Control است؟	بخشی از ترافیک نسخه تازه را می‌بیند
Feature Flag	Exposure control	چه کسی قابلیت را ببیند؟	رفتار بر اساس Cohort تغییر می‌کند
A/B Test	Product experiment	کدام تجربه Outcome بهتری دارد؟	هر دو Variant عمداً نمایش داده می‌شوند
Shadow/Dark traffic	Comparison	Candidate روی ورودی مشابه چه خروجی می‌دهد؟	خروجی Candidate نباید اثر کاربری داشته باشد
Chaos/Fault injection	Resilience experiment	Steady state هنگام خرابی حفظ می‌شود؟	ریسک فعال و نیازمند مجوز بالاتر

Canary و A/B هر دو ممکن است Traffic split داشته باشند، اما هدف متفاوت است. Canary سلامت تغییر را می‌سنجد؛ A/B فرضیه محصول را روی Variantهایی می‌آزماید که هر دو باید از نظر کیفیت و امنیت قابل قبول باشند.

طبقه‌بندی ریسک فعالیت‌های Production

جدول زیر یک نمونه داخلی است، نه استاندارد جهانی. هر سازمان باید سطح و Approval خود را براساس حساسیت سامانه تعریف کند.

سطح	نمونه	حداقل کنترل
L0	مشاهده Metric/Log/Trace موجود	Access control و Data policy
L1	Synthetic خواندنی با Test tenant	شناسه تست، Rate limit، Cleanup
L2	Canary یا Feature Flag محدود	Control، Guardrail، Stop، Rollback
L3	Shadow traffic یا Synthetic نوشتنی	Side-effect isolation، Privacy review، Reconciliation
L4	Fault injection، Failover یا تغییر مالی فعال	RoE، فرمانده، Kill مستقل، Blast radius و Recovery rehearsal

افزایش سطح باید Approval و آماده‌باش بیشتری ایجاد کند. «خودکار است» به معنی «کم‌خطر است» نیست.

پیش‌شرط‌های ورود به Testing in Production

• Artifact همان Artifact تأییدشده در Pipeline است و Rebuild نشده.
• Unit، Component، Contract، Integration، Security و Performance متناسب با ریسک سبزند.
• Migration با نسخه قبل و Rollback/Roll-forward سازگار است.
• Health model و Business invariant قبل از Rollout قابل مشاهده‌اند.
• Baseline Control و Telemetry نسخه/Flag وجود دارد.
• Alert routing و On-call با یک Dry run آزموده شده‌اند.
• Stop condition، Kill switch و Recovery owner مشخص‌اند.
• Test account/data از مشتری تفکیک و Cleanup تعریف شده است.
• مجوز تغییر، Privacy/Security review و اطلاع پشتیبانی متناسب‌اند.
• هیچ ریسک Critical حل‌نشده با امید «در Production می‌فهمیم» باقی نمانده است.

این Gateها باید در معماری Continuous Testing در CI/CD ثبت شوند، نه در حافظه افراد.

قالب آماده Production Verification Plan

Experiment/verification ID:
Type: Observation | Synthetic | Canary | Shadow | A/B | Fault
Business objective:
Non-goals:
Artifact / config / flag versions:
Control and candidate:
Target population and exclusion:
Start, max duration and soak window:
Traffic/data/write scope:
Expected result:
Success metrics:
Guardrail metrics:
Stop conditions:
Blast radius limits:
Kill / rollback / roll-forward:
Telemetry and dashboard:
Data classification and retention:
Owner / incident commander / approvers:
Support communication:
Cleanup and follow-up:
Evidence location:

اگر Type «Observation» است، آن را Experiment ننامید. اگر A/B است، Hypothesis، واحد تصادفی‌سازی، Sample size و تحلیل از قبل لازم است. اگر Fault است، Runbook مهندسی آشوب نیاز دارد.

Blast Radius را چندبعدی تعریف کنید

«یک درصد ترافیک» به‌تنهایی کافی نیست. یک درصد ممکن است همه تراکنش‌های یک مشتری سازمانی یا یک منطقه حساس را شامل شود.

• Population: داخلی، Opt-in، Tenant، Region، Device، Tier.
• Traffic: درصد Request یا Session.
• Action: Read-only، ایجاد داده، پیام، پرداخت.
• Data: جدول/Topic/Partition و سطح حساسیت.
• Time: شروع، Max duration، Peak/Off-peak.
• Dependency: PSP، SMS، Email، سرویس شریک.
• Failure domain: Pod، Zone، Region یا Tenant.
• Financial bound: تعداد و سقف مبلغ/هزینه مجاز.

Targeting باید Fail-closed باشد؛ اگر Context ناقص شد، Flag به Variant امن برگردد، نه اینکه کل کاربران Candidate را ببینند.

Canary Release را چگونه ارزیابی کنیم؟

Canary یک استقرار محدود و زمان‌دار با Control است. هدف این نیست که چند دقیقه صبر کنیم و اگر کسی شکایت نکرد، ادامه دهیم. راهنمای Canary در Google SRE نیز Canary را بخشی محدود و زمان‌دار از تغییر می‌داند که با ارزیابی آن درباره ادامه Rollout تصمیم می‌گیریم.

Control و Canary باید قابل مقایسه باشند

• ترکیب Traffic، Region و Customer tier مشابه باشد.
• نسخه و Flag در Telemetry برچسب بخورد.
• Warm cache و Cold start تفکیک شود.
• Dependency مشترک، اثر متقابل را آلوده نکند.
• Window آن‌قدر طولانی باشد که رفتار مورد نظر رخ دهد.
• حجم نمونه برای Metric انتخابی کافی باشد.
• Alert فقط به Average متکی نباشد.

سه گروه Metric

گروه	نمونه	کاربرد
Technical health	Error rate، p95/p99، saturation، restart	سلامت Runtime
Business invariant	Duplicate ledger=۰، مبلغ متوازن، سفارش orphan=۰	جلوگیری از آسیب دامنه
User outcome	Payment success، abandonment، complaint	اثر تجربه/کسب‌وکار

Threshold باید از SLO، Baseline و Risk بیاید. برای طراحی p95/p99 و Load model به راهنمای تست عملکرد رجوع کنید.

Stop Condition پیش از Start نوشته می‌شود

نمونه Rule:

STOP immediately if any condition is true:
- duplicate financial ledger entries > 0
- payment mismatch > approved risk threshold
- canary 5xx rate exceeds control by agreed delta for 5 minutes
- p99 exceeds guardrail for 10 minutes
- alerting or trace correlation is unavailable
- rollback/kill control cannot be executed
- unexpected PII appears in telemetry

Pause با Rollback فرق دارد. Pause گسترش را متوقف می‌کند؛ Rollback Traffic را به Artifact قبلی برمی‌گرداند؛ Kill switch یک Capability را خاموش می‌کند؛ Roll-forward نسخه اصلاحی می‌دهد. هر کدام Owner و زمان هدف می‌خواهند.

Rollback همیشه امن نیست

Database migration، Event schema، Queue backlog و Side effect مالی ممکن است با بازگرداندن Binary قدیمی حل نشوند. طراحی امن شامل این موارد است:

• Expand→Migrate→Contract برای Schema؛
• Backward/forward compatibility پیام؛
• قابلیت خواندن داده نوشته‌شده توسط هر دو نسخه؛
• Feature disable مستقل از Deploy؛
• Reconciliation برای Side effect؛
• Roll-forward artifact از پیش‌ساخته؛
• Restore drill و Recovery time اندازه‌گیری‌شده.

تمرین Recovery باید قبل از Incident انجام شود. اگر Rollback فقط یک دکمه تست‌نشده است، Guardrail واقعی نیست.

Feature Flag: کنترل Exposure، نه تضمین کیفیت

Feature Flag می‌تواند Deployment را از Release جدا کند و Cohort کوچک بسازد. OpenFeature Evaluation Context Context و Targeting key را برای Rule، Override و Fractional evaluation مدل می‌کند.

تست‌های ضروری Flag

• Default امن هنگام قطع Provider؛
• رفتار با Context ناقص یا نامعتبر؛
• توزیع پایدار یک کاربر میان Requestها؛
• عدم نشت Variant میان Tenantها؛
• Cache و propagation delay؛
• Override و RBAC مدیریتی؛
• Audit تغییر Flag؛
• Kill switch تحت بار؛
• حذف Flag و کد مرده پس از پایان Rollout.

برای Targeting از شناسه Opaque و حداقل Context استفاده کنید. Email، موبایل، کد ملی یا نقش حساس را بی‌دلیل در Context سرویس Flag خارجی نفرستید.

Synthetic Testing با داده امن

Synthetic Check یک Journey کنترل‌شده و قابل تکرار است. بهترین طراحی، همان رابط عمومی و Authentication واقعی را استفاده می‌کند، اما Test tenant و داده مشخص دارد.

الگوی سفارش Synthetic

1. با حساب synthetic-checkout-01 و Credential چرخشی وارد شوید.
2. SKU اختصاصی تست را رزرو کنید.
3. سفارش با Header داخلی پنهان از کنترل امنیت عبور نکند؛ مسیر عادی را طی کند.
4. برای پرداخت، از روش غیرمالی/PSP تست مجاز استفاده کنید.
5. Invariant سفارش و موجودی را بررسی کنید.
6. داده با Run ID برچسب بخورد و از BI/Revenue حذف شود.
7. Cleanup با Scope دقیق و TTL اجرا شود.

چک Synthetic نباید SMS واقعی، موجودی واقعی، تسویه یا Notification مشتری را مصرف کند. اگر Side effect اجتناب‌ناپذیر است، سقف و Reconciliation لازم است.

RUM و Monitoring تست فعال نیستند

Real User Monitoring تجربه واقعی را مشاهده می‌کند؛ Latency، Error، Device و مسیر کاربر را نشان می‌دهد. Monitoring می‌تواند Anomaly را کشف کند، اما بدون Expected result و تصمیم از پیش تعریف‌شده، یک Test case محسوب نمی‌شود.

چهار سیگنال Trace، Metric، Log و Profile/Context چشم‌اندازهای متفاوت دارند. Version، Deployment ID و Flag variant را در Schema Telemetry ثبت کنید تا Candidate از Control جدا شود.

آمادگی Observability را تست کنید

• Metric و Trace در Candidate واقعاً صادر می‌شود.
• Dashboard با Traffic آزمایشی تغییر می‌کند.
• Alert در Dry run به On-call درست می‌رسد.
• Clock و Trace correlation صحیح است.
• Sampling خطای کم‌تکرار را حذف نمی‌کند.
• Telemetry outage خودش Alert دارد.
• High-cardinality label هزینه و ظرفیت را منفجر نمی‌کند.

برای تشخیص رخدادهای Production که تکرارشان کم است، راهنمای شواهد باگ متناوب الگوی Trace و فرضیه‌سازی می‌دهد.

حریم خصوصی و امنیت Telemetry

Production trace و Log ممکن است PII، Token، مبلغ یا مسیر داخلی را ثبت کند. OWASP Logging Cheat Sheet بر حذف/ماسک داده حساس، کنترل دسترسی، Retention و آزمون خود Logging تأکید می‌کند.

• Access token، رمز، کارت، کد ملی و Connection string ثبت نشود.
• شناسه کاربر در صورت نیاز Pseudonymous و Scope-limited باشد.
• Debug logging زمان‌دار، Approve‌شده و خودکار خاموش شود.
• Log injection و دسترسی Dashboard تست شود.
• Export به SaaS خارجی Data classification داشته باشد.
• Retention کمتر یا بیشتر از Policy نباشد.
• Telemetry آزمایش از داده مشتری قابل تفکیک باشد.

جزئیات Threat، RoE و Vulnerability handling را در راهنمای تست امنیت تکمیل کنید.

Shadow Testing بدون Side Effect

در Shadow، ورودی Production به Candidate کپی می‌شود اما پاسخ Candidate به کاربر بازنمی‌گردد. خطر پنهان این است که Candidate هنوز Email، Payment، DB write یا Event واقعی تولید کند.

گاردریل Shadow

• Egress به PSP، SMS، Email و Webhook مسدود باشد.
• Write به Database/Topic جدا یا Dry-run sink برود.
• Candidate Credential فقط Read یا Sandbox باشد.
• Timeout Candidate روی مسیر اصلی اثر نگذارد.
• PII پیش از Replication کمینه/Tokenize شود.
• خروجی با Comparator دامنه‌ای سنجیده شود، نه String equality کور.
• Mismatchهای قابل قبول مانند Timestamp/ID Normalize شوند.
• هزینه دوبرابر Traffic و Dependency capacity محاسبه شود.

A/B Testing برای صحت نرم‌افزار نیست

A/B برای مقایسه Outcome محصول است؛ مثلاً دو چیدمان Checkout. پیش از آزمایش، هر دو Variant باید Functional، Accessible، Secure و قابل Rollback باشند. A/B نباید برای فهمیدن این باشد که «کدام Variant Crash نمی‌کند».

• Hypothesis و Primary metric پیش‌ثبت شود.
• Guardrail metric مانند Error و Complaint تعیین شود.
• واحد Randomization با اثر شبکه‌ای سازگار باشد.
• Sample ratio mismatch پایش شود.
• Peeking و توقف فرصت‌طلبانه کنترل شود.
• چند آزمون هم‌زمان Interference نسازند.
• تأثیر روی کاربران آسیب‌پذیر و الزام رضایت بررسی شود.
• Novelty و Seasonality در تحلیل لحاظ شود.

Chaos در Production مرحله بلوغ بالا است

Fault Injection را صرفاً چون ابزار اجازه می‌دهد در Production اجرا نکنید. مهندسی آشوب امن به Hypothesis، Steady state، Control، Blast radius، Stop، Kill و Recovery مستقل نیاز دارد.

قبل از Production، همان Fault در Component، Staging یا Sandbox اجرا شود. سپس فقط اگر فرض مورد نظر وابسته به شرایط Production است و Risk/Benefit پذیرفته شده، دامنه محدود ارتقا یابد.

نمونه ایرانی: انتشار Reconciliation پرداخت نسخه ۲

Candidate قرار است Callbackهای دیررس PSP را با Ledger تطبیق دهد و وضعیت Unknown را کاهش دهد. اشتباه می‌تواند سفارش پرداخت‌شده را Failed یا دوباره Paid کند؛ بنابراین «بگذاریم ۵٪ کاربران امتحان کنند» نقطه شروع مناسبی نیست.

مرحله صفر: Evidence پیش‌تولید

• Replay داده مصنوعی و نمونه De-identified؛
• تست Duplicate، Out-of-order، Timeout و Crash؛
• Contract نسخه Event؛
• Backfill dry run؛
• Performance روی Queue lag؛
• Roll-forward/kill rehearsal.

مرحله یک: Dark deploy

Artifact در Production Deploy می‌شود اما Worker خاموش است. Config، Secret access، Connection، Schema compatibility و Telemetry با Smoke خواندنی بررسی می‌شوند.

مرحله دو: Shadow comparison

رویدادها به Candidate کپی می‌شوند؛ Candidate فقط به Shadow table می‌نویسد. خروجی paid/pending/failed با Control مقایسه می‌شود. Event و Customer ID به شناسه Opaque تبدیل و Egress مالی بسته است.

مرحله سه: Internal/Test-merchant canary

فقط Merchantهای تست و تراکنش مجاز وارد مسیر Candidate می‌شوند. Duplicate ledger باید دقیقاً صفر باشد. اختلاف وضعیت، Queue lag، p99 و Reconciliation age Guardrail دارند.

مرحله چهار: Progressive exposure

Cohortهای کوچک و از پیش تعریف‌شده افزایش می‌یابند. درصد و Soak time از حجم Traffic و زمان ظاهرشدن خطا می‌آید، نه اعداد ثابت اینترنتی. هر مرحله Health gate مستقل دارد.

مرحله پنج: Full rollout و Cleanup

پس از Rollout، Shadow sink، Flag موقت و Credential آزمایش حذف می‌شوند. Evidence ذخیره، Risk report به‌روز و Regression سمت چپ اضافه می‌شود.

Guardrailهای نمونه پرداخت

Signal	مبنای مقایسه	اقدام
Duplicate ledger	Invariant مطلق = ۰	Stop + kill + reconciliation
Status mismatch	Control و منبع PSP	Pause؛ بررسی نمونه‌ها
Unknown payment rate	Baseline هم‌زمان Control	Pause/Rollback طبق Threshold
Queue lag	SLO و ظرفیت Worker	Stop ramp؛ scale/diagnose
p99 duration	Control هم‌Cohort	Pause؛ profile candidate
Telemetry gap	Freshness SLA	Stop؛ وضعیت خاکستری

نتیجه هر مرحله باید با قالب گزارش تست و تصمیم انتشار ثبت شود؛ Dashboard زنده به‌تنهایی Audit trail کافی نیست.

Safe Deployment Pipeline

مرحله	شاهد	Gate
Build	Artifact provenance و tests	Candidate immutable
Pre-production	Functional/NFR/Security/Migration	Exit criteria
Deploy disabled	Config/health/telemetry	Smoke pass
Internal ring	Synthetic و staff traffic	Guardrails met
Canary	Control comparison	Automated analysis + approval
Progressive ramp	Technical/business/user signals	Per-stage soak
Full	SLO و incident watch	Release complete
Cleanup	Flag/test data/temp access	No orphan artifact

Azure Well-Architected Safe Deployment Practices نیز Progressive exposure، Health model، توقف فوری و آغاز Recovery هنگام تشخیص مشکل را اصول مرکزی می‌داند.

متریک‌های سالم Shift-right

• Canary detection time؛
• Time to stop و Time to recover؛
• Blast radius واقعی در برابر سقف؛
• False promotion و False rollback؛
• Guardrail coverage برای Riskهای حیاتی؛
• Telemetry freshness و correlation completeness؛
• Flag age و درصد Flagهای بدون Owner؛
• Synthetic false-positive/false-negative؛
• Production escape تبدیل‌شده به Regression؛
• User harm یا Business invariant violation.

«تعداد آزمایش Production» هدف نیست. جزئیات طراحی شاخص ضدبازی در راهنمای متریک‌های تست آمده است.

ضدالگوهای رایج

• Production as QA: انتشار کد کم‌آزمون و امید به Monitoring.
• Canary بدون Control: مقایسه Candidate با Threshold بی‌زمینه.
• درصد ثابت: ۱٪ بدون توجه به Tenant، مبلغ یا Region.
• Average only: پنهان‌کردن Tail و Cohort آسیب‌دیده.
• Shadow with writes: ارسال Side effect واقعی از Candidate.
• Flag forever: کد دوشاخه و تنظیم بدون Owner.
• Alert after start: ساخت Dashboard هنگام Incident.
• Manual rollback: Runbook تمرین‌نشده و Credential نامعتبر.
• Real customer as fixture: ساخت سفارش/پیام ناخواسته برای کاربر.
• RUM without privacy: ارسال PII و Token به Telemetry.
• A/B for broken variants: آزمون Outcome پیش از کف کیفیت.
• Chaos theater: Fault بدون Hypothesis، Stop و Recovery.

انتخاب ابزار بر اساس کنترل لازم

• Progressive delivery controller با stage، analysis و abort؛
• Feature flag platform با RBAC، audit، safe default و expiry؛
• Synthetic runner با secret management و cleanup؛
• Telemetry platform با version/flag dimension و freshness alert؛
• Shadow proxy با write suppression و sampling؛
• Experiment platform با randomization و guardrails؛
• Incident system با on-call، runbook و postmortem؛
• Evidence store با immutable snapshot و retention.

PoC باید Kill latency، Failure mode ابزار، Export، هزینه cardinality، دسترسی ایران، Data residency و Vendor exit را آزمایش کند. ابزار، مجوز اخلاقی یا Risk acceptance ایجاد نمی‌کند.

برنامه بلوغ ۳۰/۶۰/۹۰ روزه

۳۰ روز: Observation و Recovery

• Service/Business health model تعریف کنید.
• Version و Flag را در Telemetry برچسب بزنید.
• Alert و rollback را Dry run کنید.
• یک Synthetic کم‌خطر با Test tenant بسازید.

۶۰ روز: Progressive exposure

• Ring داخلی و Canary کوچک بسازید.
• Control comparison و automated pause اضافه کنید.
• Feature flag lifecycle و expiry تصویب کنید.
• Production Verification Plan را برای دو Release اجرا کنید.

۹۰ روز: Shadow و Experiment هدفمند

• یک Shadow read-only با Privacy review اجرا کنید.
• Business invariantها را به Stop condition وصل کنید.
• یک Fault کم‌خطر را از Sandbox تا Production مرحله‌بندی کنید.
• Incidentها را به Regression و Guardrail سمت چپ برگردانید.

چک‌لیست نهایی Shift-right

• نوع فعالیت Observation/Verification/Experiment روشن است.
• Business objective و Non-goal نوشته شده‌اند.
• Artifact، Config و Flag نسخه‌دارند.
• Pre-production evidence متناسب کامل است.
• Control و Target population تعریف شده‌اند.
• Blast radius در Traffic، Data، Time و Money محدود است.
• Guardrail فنی و Business invariant وجود دارد.
• Stop condition پیش از Start تصویب شده است.
• Kill، rollback و roll-forward تمرین شده‌اند.
• Telemetry تازه، قابل تفکیک و قابل اعتماد است.
• PII/Secret در Log، Trace یا Flag context نیست.
• Synthetic data از Analytics و مشتری جداست.
• Shadow هیچ Side effect واقعی ندارد.
• A/B فقط Variantهای ایمن را مقایسه می‌کند.
• Chaos دارای RoE و Recovery مستقل است.
• On-call، Support و Decision owner حاضرند.
• Cleanup، Expiry و Regression follow-up ثبت شده‌اند.

منابع معتبر

• Google SRE Workbook: Canarying Releases؛ Canary محدود، Control، ارزیابی و تصمیم Rollout.
• Microsoft Azure Well-Architected: Safe deployments؛ Progressive exposure، Health model و Recovery.
• OpenFeature Glossary؛ Targeting، Targeting key و Fractional evaluation.
• OpenTelemetry Baggage؛ Context میان سرویس‌ها و ملاحظات امنیتی انتشار داده.
• OWASP Logging Cheat Sheet؛ داده ممنوع، Integrity، Access و Retention.

جمع‌بندی

Shift‑right به معنی یافتن باگ روی کاربران نیست؛ یعنی ساختن حلقه شواهد بعد از استقرار با کمترین آسیب ممکن. Monitoring، Synthetic، Canary، Flag، Shadow، A/B و Chaos اهداف و سطح ریسک متفاوت دارند و باید با نام درست، Policy درست و Owner درست اجرا شوند.

یک برنامه امن از Evidence پیش‌تولید آغاز می‌شود، Candidate را خاموش Deploy می‌کند، Telemetry را پیش از Exposure می‌آزماید، Blast radius را چندبعدی محدود می‌کند، Control و Guardrail دارد و با Stop/Recovery خودکار جلو می‌رود. حقیقت Production ارزشمند است، اما فقط وقتی کاربر، داده و اعتماد او Guardrail اول طراحی باشند.

سوالات متداول Shift-right و تست در Production

۱. آیا Testing in Production ذاتاً خطرناک است؟

هر تغییر Production ریسک دارد. Observation غیرفعال کم‌خطرتر است و Fault injection یا تراکنش نوشتنی پرریسک‌تر. با Evidence پیشین، مجوز، Blast radius، Control، Guardrail، Stop و Recovery می‌توان ریسک را محدود کرد؛ اما صفر نمی‌شود.

۲. تفاوت Canary و A/B Testing چیست؟

Canary سلامت یک تغییر را نسبت به Control می‌سنجد تا درباره ادامه Rollout تصمیم بگیریم. A/B دو تجربه از پیش ایمن را برای سنجش Outcome محصول مقایسه می‌کند. Canary ابزار ایمنی انتشار است؛ A/B ابزار آزمایش فرضیه محصول.

۳. آیا Monitoring همان Shift-right Testing است؟

Monitoring بخش مهم Shift‑right و عمدتاً Observation است. وقتی Hypothesis، Expected، Scope و Gate از پیش تعریف شود، Metric می‌تواند شاهد Verification یا Experiment باشد. Dashboard بدون تصمیم و معیار قبلی، Test case نیست.

۴. آیا می‌توان از داده واقعی کاربر برای تست Production استفاده کرد؟

رفتار واقعی در RUM و Canary دیده می‌شود، اما جمع‌آوری و پردازش باید کمینه، مجاز و امن باشد. Synthetic از Test tenant و داده مشخص استفاده می‌کند. PII، Token و اطلاعات پرداخت نباید بی‌دلیل در Log، Trace، Shadow یا Flag context کپی شوند.

۵. اگر Rollback امن نباشد چه کنیم؟

از Schema و Event سازگار، Feature disable، Reconciliation و Roll-forward artifact استفاده کنید. قبل از Exposure، Recovery را تمرین و Stop را زودتر تنظیم کنید. اگر نه Rollback و نه Roll-forward قابل اعتماد است، فعالیت Production نباید آغاز شود.