Failover در SMS Gateway چیست؟ وقتی یک مسیر اپراتوری از دسترس خارج می‌شود
Failover در SMS Gateway سازوکاری است که هنگام اختلال مسیر اصلی ارسال پیامک، پیام‌های واجد شرایط را پس از تشخیص خطا و بررسی وضعیت تلاش قبلی به مسیر جایگزینِ مجاز می‌فرستد. این کار به تداوم سرویس کمک می‌کند، اما تحویل پیام را تضمین نمی‌کند. طراحی درست Failover باید میان «رد قطعی»، «پذیرش قطعی» و «وضعیت نامعلوم» فرق بگذارد تا قطعی یک مسیر به ارسال تکراری یا انباشت بی‌پایان پیام تبدیل نشود.
برای سازمانی که OTP یا اعلان عملیاتی می‌فرستد و برای Providerی که چند اتصال اپراتوری را مدیریت می‌کند، خرابی یک مسیر فقط یک خطای فنی نیست؛ ممکن است صف پیام رشد کند و زمان مفید پیام تمام شود. در این راهنما سناریوی قطع مسیر، منطق سوئیچ، کنترل Loop و شاخص‌های پایش را با یک الگوی مرجع توضیح می‌دهیم. قابلیت‌های اعلام‌شدهٔ تلیرکو را از صفحهٔ رسمی SMS Gateway می‌گیریم؛ جزئیات فعال‌سازی و عملکرد هر استقرار باید جداگانه بررسی شود.
Failover پیامک چه تفاوتی با Routing عادی دارد؟
موتور Routing برای هر پیام، مسیر مجاز و مناسب را طبق سیاست جاری انتخاب می‌کند. Failover زمانی وارد عمل می‌شود که مسیر انتخاب‌شده در دسترس نباشد، درخواست را به‌روشنی رد کند یا بر اساس شاخص‌های تعریف‌شده از مدار خارج شود. در نتیجه، Failover بخشی از سیاست مسیریابی و بازیابی است، نه یک «ارسال دوبارهٔ خودکار» برای همهٔ خطاها.
وجود دو اتصال نیز به‌تنهایی تابآوری نمی‌سازد. مسیر دوم باید برای مقصد، فرستنده و نوع پیام مجاز باشد، ظرفیت پذیرش بار جایگزین را داشته باشد و وضعیت آن مستقل پایش شود. اگر هر دو اتصال به یک جزء مشترک وابسته باشند، خرابی همان جزء می‌تواند هر دو را هم‌زمان از کار بیندازد. در راهنمای معماری SMS Gateway سازمانی جای صف، موتور مسیریابی، Adapter و پایش در کل مسیر پیام آمده است.
سناریو: مسیر اپراتوری اصلی قطع می‌شود
فرض کنید Gateway برای پیام‌های تراکنشی از مسیر «الف» استفاده می‌کند و «ب» مسیر جایگزین مجاز است. تا پیش از اختلال، پیام پس از پذیرش در صف به Adapter «الف» می‌رسد و پاسخ اولیه با شناسهٔ مسیر ثبت می‌شود. ناگهان اتصال «الف» قطع می‌شود. بخشی از پیام‌ها پیش از ارسال رد می‌شوند؛ برای بخشی دیگر پاسخ دیر می‌رسد یا اصلاً نمی‌رسد. این دو وضعیت را نباید یکسان فرض کرد.
توالی پیشنهادی در این مثال چنین است: ثبت رخداد اتصال، بررسی سلامت و ظرفیت «ب»، توقف انتخاب «الف» برای پیام‌های جدید، جداسازی پیام‌های ردشده از پیام‌های با نتیجهٔ نامعلوم، سپس انتقال کنترل‌شدهٔ گروه اول. بعد از بازیابی «الف»، بازگشت ترافیک باید تدریجی و بر اساس نتیجهٔ آزمون سلامت باشد؛ نوسان کوتاه اتصال نباید پیام‌ها را پی‌درپی میان دو مسیر جابه‌جا کند. این نمودار یک الگوی طراحی است و رفتار قطعی هیچ استقرار مشخصی را نشان نمی‌دهد.
چه خطاهایی باید Failover را فعال کنند؟
تشخیص خرابی باید از چند سیگنال استفاده کند: وضعیت نشست اتصال، پاسخ به health check، خطاهای صریح ارسال، timeout، تأخیر غیرعادی و رشد صف خروجی. در SMPP، پیام enquire_link برای بررسی دسترس‌پذیری اتصال به کار می‌رود؛ سالم بودن آن به‌تنهایی به معنی تحویل موفق پیامک نیست. سلامت واقعی مسیر را با خطاها و وضعیت‌های پیام نیز بسنجید.
| نتیجهٔ تلاش | برداشت عملیاتی | اقدام مناسب |
|---|---|---|
| رد قطعی پیش از پذیرش | پیام در مسیر اصلی ثبت نشده است | در صورت مجاز بودن، مسیر جایگزین و مهلت پیام بررسی شود |
| پذیرش با شناسهٔ مسیر | مسیر بیرونی مسئول پردازش پیام شده است | منتظر وضعیت بعدی بمانید؛ صرف قطع اتصال، مجوز ارسال دوباره نیست |
| Timeout یا پاسخ نامعلوم | ممکن است مسیر پیام را پذیرفته باشد | وضعیت را با شناسه و لاگ تطبیق دهید؛ از ارسال کور جلوگیری کنید |
| خطای دائمی پیام یا مقصد | تغییر مسیر احتمالاً علت را برطرف نمی‌کند | پیام را با دلیل روشن متوقف یا برای رسیدگی جدا کنید |
مستندات وضعیت پیام Twilio نیز میان پذیرش، صف، ارسال و تحویل تفاوت می‌گذارد. این مدل برای فهم مرزها مفید است؛ نام رویدادها و قرارداد خطا در اتصال‌های تلیرکو و اپراتورها ممکن است متفاوت باشد. سیاست Failover را بر پاسخ و DLR واقعی همان مسیر بنا کنید، نه صرفاً متن یک خطای عمومی.
سوئیچ مسیر چگونه بدون Loop و پیام تکراری انجام شود؟
سقف تلاش و مسیر جایگزین مشخص
برای هر پیام، تعداد تلاش، زمان پایان اعتبار و فهرست مسیرهای مجاز را ثبت کنید. اگر «الف» خراب است و «ب» نیز پیام را رد می‌کند، بازگشت خودکار از «ب» به «الف» بدون تغییر شرایط فقط یک Loop می‌سازد. پس از رسیدن به سقف تلاش یا پایان اعتبار، پیام باید به وضعیت نهایی یا صف رسیدگی منتقل شود. راهنمای AWS برای سامانه‌های توزیع‌شده نیز بر محدود کردن retry و فاصله‌گذاری آن با backoff و jitter تأکید می‌کند.
شناسهٔ یکتا و دفتر ثبت تلاش‌ها
یک شناسهٔ داخلی ثابت برای درخواست نگه دارید و برای هر تلاش، مسیر، زمان، پاسخ اولیه و شناسهٔ بیرونی را جدا ثبت کنید. کلید idempotency در ورودی جلوی ساخت چند درخواست داخلی برای یک رویداد را می‌گیرد. با این حال اگر مسیر بیرونی قبلاً پیام را پذیرفته باشد، کلید داخلی به‌تنهایی مانع دریافت دو پیامک توسط گیرنده نمی‌شود. برای وضعیت نامعلوم، ابتدا تطبیق رکوردها و راه استعلام قراردادی مسیر را بررسی کنید. راهنمای قابلیت اطمینان AWS نیز اهمیت idempotency را در عملیات تکرارشونده توضیح می‌دهد.
Circuit breaker و بازگشت کنترل‌شده
اگر خطاهای یک مسیر از آستانهٔ تعیین‌شده بگذرند، Circuit Breaker می‌تواند انتخاب آن مسیر را موقتاً متوقف کند تا تلاش‌های ناموفق، فشار بیشتری ایجاد نکنند. پس از دورهٔ بررسی، تعداد محدودی درخواست آزمایشی یا health check انجام می‌شود و تنها در صورت بهبود، مسیر به چرخه بازمی‌گردد. آستانه، مدت توقف و شیوهٔ آزمون باید با رفتار واقعی اتصال تنظیم شوند؛ عدد ثابت عمومی برای همهٔ اپراتورها مناسب نیست.
Failover با High Availability یکی نیست
Failover اپراتوری از خرابی یک مسیر خروجی محافظت می‌کند. High Availability موضوع گسترده‌تری است و باید ورودی API، صف، پردازش‌گر، پایگاه داده و سرویس پایش را نیز در بر بگیرد. اگر خود Gateway یا صف پیام از کار بیفتد، داشتن دو اپراتور کمکی به ادامهٔ پردازش نمی‌کند. برعکس، چند نمونهٔ Gateway بدون مسیر خروجی مستقل نیز قطعی اپراتوری را حل نمی‌کند.
برای Provider و سازمان بزرگ، نقشهٔ وابستگی را روی کاغذ بیاورید: آیا مسیرهای «الف» و «ب» از یک شبکه، مرکز داده، حساب سرویس یا تنظیمات مشترک عبور می‌کنند؟ آیا سیاست محدودیت نرخِ مسیر دوم بار منتقل‌شده را تحمل می‌کند؟ راهکار تلیرکو برای اپراتورها زمینهٔ نیاز چندمسیره را نشان می‌دهد، اما پاسخ به این پرسش‌ها باید در معماری و قرارداد پروژه ثبت شود.
چه چیزی را پایش و چگونه آزمون کنیم؟
- سلامت مسیر: نشست، پاسخ health check، خطا و تأخیر پاسخ را به تفکیک اتصال ببینید.
- زمان تشخیص و سوئیچ: از شروع اختلال تا خروج مسیر خراب از انتخاب و رسیدن پیام واجد شرایط به مسیر دوم را اندازه بگیرید.
- سن و عمق صف: نشان می‌دهد انتقال ترافیک واقعاً گلوگاه را کاهش داده یا بار را فقط جابه‌جا کرده است.
- نرخ پیام‌های نامعلوم و تکراری: اثر retry بر تجربهٔ گیرنده را نشان می‌دهد.
- وضعیت تحویل: DLR یا callback را با شناسهٔ داخلی و شناسهٔ هر تلاش تطبیق دهید. نبودن callback را با شکست تحویل یکی نگیرید.
- بازگشت مسیر اصلی: نرخ خطا و تأخیر را در زمان ورود دوبارهٔ ترافیک پایش کنید.
در آزمون عملی، قطع اتصال را در سه لحظه شبیه‌سازی کنید: پیش از ارسال، پس از ارسال ولی پیش از دریافت پاسخ، و پس از پذیرش در انتظار DLR. برای هر حالت بررسی کنید پیام گم نشده، چند بار به گیرنده نرسیده و وضعیت نهایی قابل توضیح است. قطع هم‌زمان مسیر دوم، پر شدن ظرفیت آن و پیام منقضی‌شده نیز سناریوهای لازم برای تمرین هستند. مقالهٔ گلوگاه‌های Peak Traffic برای تفکیک تأخیر صف از تأخیر مسیر کمک می‌کند.
چک‌لیست تصمیم برای طراحی Failover
- مسیرهای جایگزین واقعاً مستقل و برای هر مقصد و فرستنده مجاز هستند؟
- خطاهای قطعی، موقت و وضعیت‌های نامعلوم در قرارداد اتصال تعریف شده‌اند؟
- برای هر پیام، شناسه، مهلت اعتبار، تعداد تلاش و پاسخ هر مسیر ثبت می‌شود؟
- سقف retry، جلوگیری از Loop و قاعدهٔ بازگشت به مسیر اصلی مشخص است؟
- ظرفیت مسیر دوم با بار منتقل‌شده و ترافیک خودش آزموده شده است؟
- گزارش‌های تحویل و هشدارها پس از سوئیچ همچنان به پیام درست نگاشت می‌شوند؟
پرسش‌های رایج دربارهٔ Failover پیامک
آیا Failover تحویل پیامک را تضمین می‌کند؟
خیر. این سازوکار امکان استفاده از مسیر سالم و مجاز را هنگام اختلال فراهم می‌کند. تحویل نهایی به وضعیت گیرنده، شبکه و قواعد مسیر بیرونی هم وابسته است.
در صورت Timeout باید فوراً از مسیر دوم ارسال کنیم؟
نه همیشه. Timeout ممکن است پس از پذیرش پیام رخ داده باشد. ابتدا وضعیت تلاش قبلی را با شناسه و لاگ بررسی کنید و فقط طبق سیاست خطا و کنترل تکرار تصمیم بگیرید.
آیا داشتن دو اپراتور برای Failover کافی است؟
خیر. مجوز فرستنده، ظرفیت مسیر دوم، استقلال وابستگیها، پایش و آزمون دورهای نیز لازماند. دو اتصال که به یک نقطهٔ شکست مشترک وابستهاند تابآوری مورد انتظار را نمیدهند.
Failback چه زمانی انجام می‌شود؟
وقتی مسیر اصلی دوباره سلامت پایدار و ظرفیت لازم را نشان دهد. بازگرداندن ترافیک بهتر است کنترل‌شده باشد تا نوسان اتصال باعث جابه‌جایی پیاپی مسیر نشود.
معماری مسیر جایگزین پیامکی را بررسی کنیم
اگر ارسال‌های حیاتی، چند مسیر اپراتوری یا ترافیک سازمانی دارید، نقشهٔ اتصال‌ها، خطاهای پرتکرار و داده‌های پایش را با تیم تلیرکو مرور کنید. در بررسی معماری می‌توان مرز Failover، وضعیت‌های نامعلوم و آزمون مسیر جایگزین را روشن کرد.
منابع فنی: صفحهٔ رسمی SMS Gateway تلیرکو؛ SMPP.org، فرمان‌ها و وضعیت اتصال؛ Twilio، چرخهٔ وضعیت پیام؛ Twilio، ثبت و تطبیق وضعیت؛ AWS، Circuit Breaker؛ AWS، محدود کردن Retry؛ AWS، Idempotency. این منابع اصول عمومی طراحی‌اند، نه مشخصات قراردادی یک استقرار تلیرکو.