آمادگی سایت برای کمپین پرترافیک؛ ظرفیت تا بازیابی

پاسخ کوتاه: هشت قرارداد پیش از کمپین

خرید ظرفیت فقط یکی از کنترل‌هاست. اگر Cache key اشتباه، Query بدون Index، Retry بی‌مهار یا Lock موجودی گلوگاه باشد، یک سرور بزرگ‌تر ممکن است فقط رسیدن به شکست را چند دقیقه عقب بیندازد.

دامنه را از «صفحه بالا است» به Journey سالم ببرید

پاسخ ۲۰۰ صفحه اصلی ثابت نمی‌کند کمپین قابل فروش است. برای هر Journey، نقطه شروع، مراحل، نتیجه کسب‌وکاری و مالک را ثبت کنید.

مانیتورینگ Availability عمومی را در راهنمای ابزارهای مانیتورینگ آپتایم سایت ببینید. این مقاله بر آمادگی همان رویداد و رفتار سیستم زیر بار تمرکز دارد.

گام صفر: Campaign contract بنویسید

event_id:
window: 1405-09-01 20:50–23:30 Asia/Tehran
audience: 180,000 SMS recipients
entry_pattern: phased | scheduled | influencer-unknown
critical_journey: landing → SKU → cart → payment → confirmed order
inventory_policy: finite; reservation TTL = ...
success: confirmed_orders / eligible_sessions
guardrails: duplicate_order, payment_unknown, oversell, support_rate
freeze_start:
incident_commander:
stop_campaign_owner:
status_channel:
rollback_version:

تاریخ و ساعت را با منطقه زمانی بنویسید. در کمپین ایرانی، تبدیل اشتباه تقویم شمسی، ساعت سرور UTC، زمان پایان کد تخفیف و گزارش PSP می‌تواند رخداد را به «افت تصادفی» شبیه کند. واحد پول را نیز روشن کنید: ریال در API و تومان در UI نباید Budget یا سقف سفارش را ده‌برابر جابه‌جا کند.

Demand را از Reach به Arrival profile تبدیل کنید

تعداد دنبال‌کننده یا پیامک، Concurrency نیست. حداقل این زنجیره را بسازید:

Delivered messages
× click-through rate
× concentration in peak minute
= arrivals per peak minute

arrivals per second × average active journey duration
≈ concurrent active journeys

این تقریب برای شروع است، نه تضمین ظرفیت. Sessionها Think time دارند؛ برخی درخواست‌ها Cache می‌شوند؛ Search، Login و Checkout هزینه یکسان ندارند. از داده رویداد مشابه و بازه عدم‌قطعیت استفاده کنید.

نمونه کمپین پیامکی

فرض کنید ۱۲۰ هزار پیامک تحویل می‌شود، نرخ کلیک مورد انتظار بین ۶ تا ۱۰ درصد است و ۳۵ تا ۵۵ درصد کلیک‌ها در پنج دقیقه اول می‌آیند. به‌جای یک عدد، سناریوی Low/Base/High بسازید. سپس هر سناریو را به Mix واقعی Journey تبدیل کنید.

این درصدها Benchmark نیستند؛ نمونه مدل‌اند. Mix را از Analytics، Log و Order واقعی خودتان بسازید.

Burst، Ramp و Synchronization را مدل کنید

میانگین ساعتی پیک سه‌ثانیه‌ای را پنهان می‌کند. پیامک هم‌زمان، Countdown صفر، Push notification و پست اینفلوئنسر می‌توانند Clientها را هم‌زمان کنند. Refresh خودکار، Polling موجودی و Retry نیز بار ثانویه می‌سازند.

Profile A — Ramp:
0 → 40% load in 10 min → 100% in 20 min

Profile B — Spike:
0 → 100% in 20 sec → hold 8 min

Profile C — Soak:
70% of safe load for 2–4 h

Profile D — Recovery:
dependency fails → queues build → dependency returns → backlog drains

Ramp ظرفیت پایدار، Spike رفتار Autoscaling و Cache سرد، Soak نشت Memory/Connection و Recovery موج پس از بازگشت را نشان می‌دهد. Stress test نقطه شکست را پیدا می‌کند؛ هدفش «پاس شدن» نیست.

از RPS تنها عبور کنید: Cost هر درخواست متفاوت است

۱۰۰ درخواست تصویر Cache شده با ۱۰۰ Search پیچیده یا رزرو موجودی یکسان نیست. برای هر endpoint وزن تقریبی و Saturation resource را ثبت کنید.

CPU پایین دلیل سلامت نیست. Connection pool، file descriptor، worker، lock، queue، I/O یا یک dependency ممکن است قبل از CPU اشباع شود.

SLO رویداد و Safe operating limit

SLO را با Percentile و Business outcome بنویسید، نه «سایت سریع باشد». آستانه‌ها باید با Baseline، تحقیق کاربر و اقتصاد رویداد تعیین شوند؛ اعداد زیر صرفاً قالب‌اند.

During event window:
Landing availability ≥ target
Checkout HTTP error rate ≤ target
Checkout p95 ≤ target
Confirmed-order success rate ≥ target
Payment-unknown rate ≤ target
Duplicate-order rate = 0
Oversell rate = 0
Alert detection ≤ target minutes

حد ظرفیت تبلیغی را روی نقطه شکست نگذارید. Safe operating limit باید Headroom برای Failure یک instance، Cache miss، Variance و موج Retry داشته باشد. اگر Test تا ۱۰۰۰ Journey/min موفق و در ۱۱۵۰ غیرخطی شد، «ظرفیت ۱۱۵۰» نتیجه درستی نیست.

برای طراحی پایش Signalها، راهنمای مانیتورینگ لحظه‌ای و Observability سایت مکمل این قرارداد است.

چهار پنجره اندازه‌گیری را کنار هم بگذارید

Dashboard باید بتواند Event ID، Release، Channel، Device، Region، Journey و Dependency را فیلتر کند. High-cardinality کنترل‌نشده هزینه و اختلال مانیتورینگ می‌سازد؛ شناسه تراکنش را در Log امن نگه دارید و اطلاعات شخصی یا کارت را وارد Telemetry نکنید.

Load test را با مجوز و داده امن طراحی کنید

روی سامانه‌ای که مالک آن نیستید یا مجوز صریح ندارید بار ایجاد نکنید. PSP، پیامک، سرویس دولتی، Vendor و API شخص ثالث را در تست اصلی Mock/Stub/Sandbox کنید. تست Production باید Change ثبت‌شده، پنجره محدود، هماهنگی Provider، سقف بار و Kill switch داشته باشد.

مستندات رسمی Grafana k6 برای Load testing وب‌سایت نیز بر Test environment، چرخه تکرار و احتیاط درباره سرویس‌های ثالث تأکید می‌کند.

test_id:
authorized_by:
target_hosts:
excluded_hosts:
test_data_prefix:
max_rate:
max_duration:
stop_conditions:
on_call:
provider_notified:
cleanup_and_reconciliation:

Test data باید قابل تشخیص و قابل پاک‌سازی باشد

کاربر، سفارش، کوپن، شماره تماس و Inventory مصنوعی را Namespace کنید. پیامک یا ایمیل واقعی برای هزاران Virtual User نسازید. Orderهای آزمایشی نباید به انبار، حسابداری یا Fulfillment واقعی نشت کنند.

• شناسه‌ای مانند PERF-20260812-* برای Entityهای تست؛
• SKU و موجودی جدا یا محیط Staging هم‌حجم؛
• درگاه Sandbox یا Payment adapter کنترل‌شده؛
• Suppression برای Email/SMS/CRM؛
• Script پاک‌سازی و Reconciliation پس از تست؛
• عدم استفاده از PII مشتری واقعی در Fixture.

Workload model: نرخ ورود، نه فقط VU

اگر کمپین در هر ثانیه کاربر جدید می‌فرستد، مدلی که فقط تعداد Virtual User ثابت دارد ممکن است بار واقعی را اشتباه بازسازی کند. Arrival-rate model برای نرخ مستقل ورود مناسب است؛ VU model برای Concurrency و Journey طولانی مفید است. Think time، Abandonment و داده‌های متفاوت را مدل کنید.

scenario mix:
45% landing_view
25% product_browse
10% search_filter
10% add_to_cart
 7% checkout_until_sandbox
 3% login_or_otp_stub

assert:
correct response body/state
not merely HTTP 200

Response time خوب با پاسخ اشتباه موفقیت نیست. Threshold فنی را با Check صحت، Order uniqueness و Business counter همراه کنید.

Stop condition از قبل نوشته شود

تست بدون توقف خودکار می‌تواند خودش Incident باشد.

نتیجه تست: Knee و Failure mode مهم‌تر از رکورد است

نمودار Throughput، Latency و Error را روی Load قرار دهید. نقطه‌ای که Latency با افزایش کوچک بار ناگهان جهش می‌کند Knee است. سپس علت و رفتار بازیابی را ثبت کنید.

load → throughput → p50/p95/p99 → error
     → CPU/memory/worker/connection/queue/lock
     → dependency latency/error
     → business success/duplicate/unknown
     → recovery time/backlog drain

راهنمای Google SRE درباره Cascading failures و Overload هشدار می‌دهد که اشباع می‌تواند منابع را زنجیره‌ای درگیر کند و Retry یا انتقال بار به بخش سالم، شکست را بزرگ‌تر سازد.

Cache را با نسبت Offload و صحت بسنجید

هدف فقط Hit ratio بالا نیست. Cache باید بار Origin را کم کند و محتوای درست بدهد.

Warm-up را با URL و Variant واقعی انجام دهید؛ Cache stampede پس از Expiry یا Purge هم‌زمان را تست کنید. راهنمای CDN برای سرعت و امنیت سایت مالک جزئیات انتخاب و پیکربندی CDN است.

دیتابیس و State: جایی که Scale افقی کافی نیست

افزودن Web node لزوماً Lock موجودی، Connection pool یا Query بد را حل نمی‌کند. این موارد را زیر بار رصد کنید:

• Slow query و Query plan روی داده هم‌حجم Production؛
• Connection pool، wait time و timeout؛
• Lock/Deadlock روی Coupon، Inventory و Order؛
• Replica lag و Read-after-write؛
• Session storage و Sticky session؛
• Atomic reservation و Idempotency برای سفارش.

Oversell و Duplicate order حتی با Latency سبز، شکست کمپین‌اند. Correctness را Guardrail درجه یک قرار دهید.

Queue و Async: تأخیر را پنهان نکنید

Email، SMS، CRM sync، فاکتور و گزارش اغلب می‌توانند Async شوند؛ اما Queue بی‌حد، خطا را به آینده منتقل می‌کند. Rate ورود/خروج، Depth، Age قدیمی‌ترین پیام، Retry و Dead-letter را پایش کنید.

queue contract:
producer rate:
consumer capacity:
max acceptable age:
retry: bounded + exponential backoff + jitter
idempotency key:
dead-letter owner:
drain time after peak:
user-visible state:

اگر تأیید سفارش به کار Async حیاتی وابسته است، UI نباید زودتر از حقیقت «قطعی شد» بگوید. حالت Pending/Unknown و مسیر Reconciliation داشته باشید.

Dependency budget و Retry storm

برای PSP، OTP، Shipping، CRM و Inventory این ماتریس را تکمیل کنید:

Timeout بالاتر همیشه Reliability بیشتر نیست؛ Worker را طولانی‌تر اشغال می‌کند. Retry باید محدود، با Backoff و Jitter و فقط برای عملیات امن/Idempotent باشد.

Autoscaling را مانند Feature تست کنید

Autoscaling جادو یا آنی نیست. Signal، Threshold، Evaluation window، Provision time، readiness، warm-up و cooldown دارد. پرسش‌های آزمون:

• آیا Scale signal پیش از Latency/Queue بحرانی فعال می‌شود؟
• Instance جدید چه زمانی واقعاً Traffic می‌گیرد؟
• Cache و Runtime/JIT چه زمانی گرم می‌شوند؟
• DB و Dependency با اضافه‌شدن App node ظرفیت دارند؟
• Scale-in اتصال و Job درحال اجرا را قطع نمی‌کند؟
• سقف Quota، IP، Load balancer و License چیست؟

برای رویداد زمان‌دار، Pre-scale می‌تواند از انتظار برای Signal امن‌تر باشد؛ تصمیم باید با Test و هزینه پروژه گرفته شود. راهنمای انتخاب هاست و زیرساخت سایت پرترافیک مالک مقایسه معماری و Provider است.

Overload policy: کار مفید را حفظ کنید

وقتی Demand از ظرفیت امن بیشتر شد، سیستم باید انتخاب کند؛ اگر انتخاب نکند، Queue و Timeout انتخاب تصادفی و گران انجام می‌دهند.

Graceful degradation یعنی نسخه ارزان‌تر و صادقانه، نه نمایش ۲۰۰ با داده خراب. Feature flag و Kill switch را پیش از کمپین تمرین کنید.

Load shedding، Backpressure و Queue fairness

Load shedding درخواست اضافی را زود و ارزان رد می‌کند تا بخش سالم Crash نکند. Trigger می‌تواند Queue length، in-flight request، Latency یا health ترکیبی باشد. کنترل پیچیده و تمرین‌نشده خودش ریسک است؛ Policy ساده، مشاهده‌پذیر و قابل خاموش‌کردن بسازید.

Waiting room برای Demand سالمِ بیشتر از ظرفیت مفید است، اما باید نرخ ورود، Active users، Session expiry و عدالت را تعریف کند. مستندات جاری Cloudflare Waiting Room تفاوت FIFO، Random و Passthrough را توضیح می‌دهد. این مثال توصیه قطعی Vendor نیست؛ دسترسی، هزینه، محل کاربر و نیاز عدالت را بررسی کنید.

صف منصفانه برای موجودی محدود

FIFO به ورود زودتر پاداش می‌دهد؛ Random می‌تواند توزیع فرصت را عادلانه‌تر کند. هیچ‌کدام بدون سیاست ربات، چنددستگاهی، Accessibility، Expiry و شفافیت کامل نیستند. Queue position را وعده قطعی نکنید اگر سیستم قادر به حفظ آن نیست.

WAF و Rate limit: کاربر واقعی را قربانی نکنید

Rate limit صرفاً بر IP در اینترنت همراه، CGNAT یا شبکه سازمانی می‌تواند چند کاربر را یک نفر فرض کند. Rule را بر endpoint، identity/session، رفتار، هزینه عملیات و Risk بسازید. Challenge و Block را با Log، False positive و مسیر Support آزمون کنید.

• Login/OTP: محدودیت Account + Device/IP با پیام و cooldown؛
• Search: Cache، cost cap و query complexity؛
• Cart: session-aware و ضد abuse؛
• Payment callback: Allow/verification بر پایه قرارداد PSP، نه Rule عمومی؛
• Bot: رفتار و reputation همراه امکان اعتراض/رفع خطا.

Rule جدید امنیتی درست پیش از کمپین بدون Canary می‌تواند Availability را از داخل از بین ببرد. برای Budget و کنترل‌های گسترده‌تر، راهنمای بودجه امنیت وب‌سایت را ببینید.

Frontend زیر بار نیز می‌شکند

Origin سالم ممکن است با Tagهای تبلیغاتی، Consent، A/B tool، تصویر Hero یا JavaScript خطادار Journey را متوقف کند. روی گوشی میان‌رده و اینترنت همراه ایران این موارد را بسنجید:

• Landing با Cache سرد/گرم و شبکه قطع‌و‌وصل؛
• Hydration و قابل‌کلیک شدن CTA؛
• اسکریپت ثالث کند یا Block شده؛
• Duplicate event و دوبار Submit؛
• بازگشت از PSP و حفظ State؛
• BiDi، رقم فارسی/لاتین، ریال/تومان و Countdown.

بهینه‌سازی Delivery و Main-thread در راهنمای کاهش هزینه CSS و JavaScript عمیق‌تر بررسی شده است.

Inventory و Coupon باید Correctness test داشته باشند

فروش ۳۰۰ سفارش برای ۲۰۰ واحد، موفقیت ترافیکی و شکست کسب‌وکار است. Test concurrency برای Reserve/Release/Expire، پرداخت دیررس، Cancel، Refund و چند انبار بسازید.

assert:
available + reserved + sold + damaged = known stock state
one payment reference → at most one confirmed order
one coupon rule → deterministic result
expired reservation → released exactly once
late callback → reconciled, not duplicated

حقیقت موجودی و عملیات پس از Order در راهنمای موجودی، انبار، ارسال و مرجوعی دامنه عمیق‌تری دارد.

پیش از رویداد، Failure injection کنترل‌شده انجام دهید

فقط Happy path را Load test نکنید. در محیط مجاز و کنترل‌شده، Latency/Timeout یا Failure این موارد را شبیه‌سازی کنید:

• PSP و Callback دیررس؛
• SMS/OTP کند یا سهمیه تمام؛
• DB replica lag یا connection pressure؛
• Cache unavailable یا hit-ratio سقوط‌کرده؛
• Worker/consumer نصف ظرفیت؛
• یک App node یا Zone خارج از سرویس؛
• Telemetry/Log backend کند.

آزمون باید Hypothesis، Blast radius، Stop condition و Rollback داشته باشد. Chaos بی‌دامنه در Production مجوز این راهنما نیست.

Release freeze، Canary و Configuration snapshot

«هیچ تغییری ندهید» همیشه عملی نیست؛ Freeze باید استثنا، Approver و مسیر Emergency داشته باشد. این Snapshot را ثبت کنید:

release commit/image:
database migration version:
feature flags:
cache/CDN/WAF rules:
autoscaling min/max:
queue/worker count:
third-party tag versions:
campaign content/price/coupon:
rollback artifact and owner:

تغییر ضروری را روی سهم کوچک و با Business guardrail Canary کنید. Rollback باید شامل Config، Database compatibility، Asset/CDN و Flag باشد؛ فقط برگرداندن کد کافی نیست.

Runbook رخداد باید Decision table باشد

Incident commander تصمیم و ارتباط را هماهنگ می‌کند؛ افراد متعدد نباید مستقل در Production «فقط نگاه» یا تغییر کنند. الگوی نقش‌ها در منبع رسمی Google SRE Incident Management قابل مطالعه است.

سه سطح تصمیم حین کمپین

سطح زرد: نزدیک حد امن

• Freeze کامل تغییر؛ بررسی Origin offload و Queue؛
• کاهش Job/Report/Recommendation؛
• ارسال موج بعدی تبلیغ را نگه دارید؛
• Provider و Support را آماده کنید.

سطح نارنجی: SLO نقض و Journey آسیب‌دیده

• Campaign throttle/pause بر اساس اختیار از پیش‌تعریف‌شده؛
• Waiting room یا Admission control؛
• Graceful degradation و Load shedding؛
• Rollback تغییر مرتبط با Evidence.

سطح قرمز: Integrity یا Recovery در خطر

• حفظ Payment/Order/Inventory truth بر Traffic؛
• توقف قابلیت Write پرخطر و پیام شفاف؛
• Static status/fallback سبک؛
• Reconciliation قبل از بازکردن کامل.

Recovery: همه کاربران را یکباره برنگردانید

سبز شدن Health check پایان رخداد نیست. Backlog، Retry clientها، Refresh کاربران و موج تبلیغ معوق می‌تواند سیستم را دوباره بیندازد.

1. علت یا Mitigation را با Signal تأیید کنید.
2. Queue، DB lag، Payment unknown و Inventory را Reconcile کنید.
3. ورودی را تدریجی باز و SLO را در هر پله نگه دارید.
4. Jobهای غیرفعال را یکی‌یکی برگردانید.
5. Campaign را فقط با تأیید Business/Incident owner از سر بگیرید.
6. تا پایان Recovery window پایش تقویت‌شده را حفظ کنید.

صفحه اختلال و HTTP status

صفحه خطا با ظاهر زیبا و HTTP ۲۰۰ می‌تواند Monitoring و Search را گمراه کند. برای توقف بسیار کوتاه کل سایت، راهنمای جاری Google Search درباره توقف موقت سایت استفاده از ۵۰۳، هدر Retry-After، HTML ثابت و سبک، راهنمای روشن کاربر و باز نگه‌داشتن robots.txt را توضیح می‌دهد. Google محدودکردن قابلیت را بر خاموش‌کردن کامل ترجیح می‌دهد.

این توصیه مجوز بازگرداندن ۵۰۳ طولانی نیست. Duration، Scope و بازگشت را مانیتور کنید. صفحه Status باید از Failure domain اصلی جدا باشد و زمان به‌روزرسانی، اثر، اقدام کاربر و کانال پشتیبانی را صادقانه نشان دهد.

چک‌لیست T-۱۴ تا T+۲

Definition of Ready برای Go/No-Go

[ ] Demand range and spike profile approved
[ ] Critical journeys and business truth tested
[ ] Safe operating limit has headroom
[ ] Ramp + spike + soak + recovery evidence stored
[ ] Third parties mocked; limited E2E verified
[ ] Correctness: duplicate/oversell/payment-unknown guarded
[ ] Cache/CDN/WAF/autoscaling rules can roll back
[ ] Queue/backpressure/degrade/shed paths exercised
[ ] Dashboards and synthetic journeys visible
[ ] Incident roles, campaign-stop authority and contacts confirmed
[ ] Status/503/Retry-After path verified
[ ] Rollback and post-recovery reconciliation rehearsed

اگر مورد حیاتی Evidence ندارد، پاسخ «احتمالاً خوب است» Go محسوب نمی‌شود. Risk acceptance باید نام، علت، اثر، کنترل موقت و تاریخ انقضا داشته باشد.

خطاهای رایج آمادگی کمپین

• تبدیل Reach به RPS با یک ضریب ثابت؛
• تست فقط Homepage یا فقط HTTP ۲۰۰؛
• یکسان‌گرفتن VU، Concurrency، Arrival rate و RPS؛
• Load test روی PSP/SMS بدون مجوز؛
• Benchmark بدون داده خود سیستم؛
• اعلام Capacity روی نقطه شکست بدون Headroom؛
• Autoscaling بدون آزمون Warm-up و DB؛
• Queue بدون Max age/Dead letter/Drain plan؛
• Retry فوری و نامحدود؛
• Cache سبد/حساب یا Price/Stock قدیمی؛
• WAF فقط-IP برای کاربران CGNAT؛
• مانیتورینگ CPU بدون Business outcome؛
• Deploy یا Tag تبلیغاتی دقیقه آخر؛
• چند نفر با تغییر هم‌زمان در Incident؛
• بازکردن کامل Traffic بلافاصله پس از Health سبز؛
• Postmortem بدون Action owner و Retest.

منابع و وضعیت زمانی

این مقاله در ۲۱ مرداد ۱۴۰۵ / ۱۲ اوت ۲۰۲۶ بازبینی شده است. منابع رسمی برای اصول پایدار انتخاب شده‌اند، اما Version ابزار، قابلیت Provider و وضعیت سرویس‌های قابل‌دسترسی در ایران تغییر می‌کند؛ پیش از رویداد مستندات و قرارداد جاری خود را بررسی کنید.

• Grafana k6: طراحی و اجرای Load test وب‌سایت؛
• Google SRE: Overload، Cascading failure و Incident management؛
• Cloudflare: روش‌های Queue در Waiting Room؛
• Google Search Central: توقف کوتاه، ۵۰۳ و Retry-After.

جمع‌بندی: برای موفقیت هم Plan کنید

کمپین پرترافیک Failure ناشناخته نیست؛ یک Launch با Demand نامطمئن است. Arrival را مدل کنید، Journey و Truth را بسنجید، Safe capacity را زیر نقطه غیرخطی بگذارید، Failure و Recovery را تمرین کنید و هنگام فشار کار مفید را آگاهانه حفظ کنید.

خروجی حرفه‌ای یک عدد «چند کاربر هم‌زمان» نیست؛ بسته‌ای از Test evidence، Capacity envelope، Dashboard، Overload policy، Runbook، Rollback و Reconciliation است که Marketing، Product، Operations و Engineering آن را با هم امضا می‌کنند.