503 چه وعدهای میدهد، و چه چیزی را نه
یک 503 یعنی سرور دارد میگوید «من وجود دارم، شما را فهمیدم، بعداً برگرد». برخلاف یک 500، ادعا نمیکند چیزی خراب شده، و برخلاف یک 502، دربارهٔ یک گفتوگوی ناموفق با ماشینی دورتر نیست. یک رد شدن است با یک «فعلاً» ضمنی.
همین «فعلاً» است که 503 را کد درست برای نگهداری برنامهریزیشده و برای overload میکند، و کد اشتباه برای هر چیز دائمی. موتورهای جستوجو آن را موقت در نظر میگیرند و برمیگردند، که دقیقاً همان چیزی است که در حین یک استقرار میخواهید و دقیقاً همان چیزی است که روی صفحهای که بازنشسته کردهاید نمیخواهید — آن یکی 410 یا 301 است.
علت 1 — origin از ظرفیت خارج شده
هر سروری یک سقف روی کار همزمان دارد: فرزندان PHP-FPM، workerهای اپلیکیشن، کانکشنهای دیتابیس. وقتی سقف میرسد، یک استک بهدرستی پیکربندیشده بهجای پذیرفتن کار جدید و timeoutخوردن، سریع آن را با یک 503 رد میکند. این یعنی سیستم زیر فشار درست رفتار میکند، حتی اگر شبیه یک شکست به نظر برسد.
چگونه تشخیصش دهیم. 503ها ترافیک را دنبال میکنند: در اوجها ظاهر میشوند و وقتی اوج میگذرد پاک میشوند. origin شما در تمام این مدت بالاست و به یک درخواست که از یک لحظهٔ آرام میفرستید فوراً پاسخ میدهد.
چه چیزی واقعاً کمک میکند. بالابردن تعداد workerها سقف را جابهجا میکند و معمولاً تنگنا را به حافظه یا دیتابیس منتقل میکند. راهحل پایدار این است که اصلاً کار تکراری به origin نفرستید: صفحاتی را که میتوانند cache شوند cache کنید، به آنها یک TTL بهاندازهٔ کافی طولانی بدهید، و بگذارید edge اوج را جذب کند. کمپینی که یک origin را با 200 درخواست در ثانیه ذوب میکند اغلب 195 درخواست برای همان چند صفحهٔ انگشتشمار است.
علت 2 — حالت نگهداری
ابزارهای استقرار و افزونههای CMS سایت را پشت یک صفحهٔ نگهداری قرار میدهند و تا وقتی کار میکنند 503 برمیگردانند. این رفتار درستی است و کد هم همین است.
دو چیز میتواند در آن اشتباه پیش برود. اول یک حالت نگهداری است که هرگز پاک نمیشود — یک استقرار ناموفق فایل flag را سر جایش میگذارد و سایت مدتها بعد از تمامشدن کار 503 سرویس میدهد. دوم یک صفحهٔ نگهداری است که با یک 200 سرویس داده میشود، که به خزندهها میگوید اعلان نگهداری همان محتوای واقعی شماست و ارزش ایندکسشدن دارد.
اگر حالت نگهداری بیش از چند دقیقه روشن است، یک هدر Retry-After اضافه کنید. یک خط هزینه دارد و تفاوت بین خزندهای که مؤدبانه عقب میکشد و خزندهای است که تصمیم میگیرد سایت شما غیرقابلاعتماد است.
علت 3 — یک rate limit درخواست را رد کرد
Rate limiting درخواستهایی را که سریعتر از آستانهٔ پیکربندیشده میرسند رد میکند. بسته به نرمافزار و پیکربندیاش، رد شدن به شکل 429 Too Many Requests یا 503 میرسد — مثلاً nginx درخواستهای rate-limitشده را با 503 رد میکند مگر اینکه گفته شود از کد دیگری استفاده کند.
این وقتی اهمیت دارد که دارید لاگها را میخوانید: یک موج 503 که یک کلاینت، یک مسیر یا یک user agent را تحتتأثیر قرار میدهد، درحالیکه بقیهٔ چیزها عادی سرویس داده میشوند، یعنی یک rate limit دارد کارش را انجام میدهد، نه یک مشکل ظرفیت. راهحل این است که ببینید چهکسی به حد برخورد میکند. اگر یک scraper است، حد دارد کار میکند. اگر اپ موبایل خودتان است که هر ثانیه یک endpoint را poll میکند، حد درست است و اپ اشتباه است.
علت 4 — edge برای این هاستنیم originای ندارد
این همان موردی است که یک بعدازظهر را هدر میدهد، و هیچ ربطی به سرور شما ندارد.
وقتی DNS یک هاستنیم به یک edge CDN اشاره میکند اما آن هاستنیم روی edge پیکربندی نشده — حساب هنوز وجود ندارد، هاستنیم تحویل اضافه نشده، یا یک غلط تایپی رکورد را روی نام اشتباه گذاشته — edge originای برای پرسیدن ندارد. نمیتواند 502 برگرداند، چون هیچ گفتوگوی ناموفقی نبوده. 503 همراه با صفحهای که میگوید هیچ سرویسی برای این دامنه پیکربندی نشده برمیگرداند.
ترتیبی که این را تولید میکند همیشه یکسان است: کسی اول DNS را تغییر میدهد و پیکربندی پنل را بعداً تمام میکند، یا DNS را برای www تغییر میدهد درحالیکه هاستنیم بهصورت دامنهٔ خالی اضافه شده بود. سایت درست همان لحظهای که DNS منتشر میشود «قطع میشود»، origin کاملاً سالم است، و رفع مشکل یک دقیقه طول میکشد وقتی دست از نگاهکردن به ماشین اشتباه بردارید.
چگونه فوراً تشخیصش دهیم. صفحهٔ خطا را بخوانید نه فقط کد وضعیت را. صفحهٔ «سرویسی پیکربندی نشده» یک CDN غیرقابلاشتباه است و مشکل را نام میبرد. بعد بررسی کنید هاستنیم در پنل شما دقیقاً با نام رکورد DNS مطابقت دارد، از جمله www.
چه چیزی بفرستیم، و بازدیدکنندگان چه چیزی باید ببینند
اگر شما کسی هستید که 503 برمیگرداند، دو چیز آن را بسیار کمهزینهتر میکند.
Retry-After بفرستید. یا تعدادی ثانیه یا یک تاریخ HTTP. خزندهها به آن احترام میگذارند، کلاینتهای خوبنوشتهشده به آن احترام میگذارند، و یک رد شدن را به یک برنامهٔ زمانی تبدیل میکند.
چیزی انسانی سرویس دهید. صفحهٔ خطای پیشفرض proxy هیچچیز به بازدیدکننده نمیگوید و خراب به نظر میرسد. یک صفحهٔ اختصاصی با یک جمله دربارهٔ اینکه چه اتفاقی دارد میافتد، کار بسیار کمی است برای تفاوت بزرگی در اینکه یک حادثه چگونه تجربه میشود.
و اگر محتوا cacheپذیر است، یک CDN میتواند نسخهٔ cacheشده را همچنان سرویس دهد درحالیکه origin رد میکند — که تفاوت بین «سایت ده دقیقه کند بود» و «سایت ده دقیقه قطع بود» است.
پرسشهای پرتکرار
آیا 503 بهتر است یا بدتر از 502؟
پراطلاعاتتر است. یک 503 یک رد شدن عمدی است، پس چیزی در مسیر بهاندازهٔ کافی خوب کار میکند که تصمیم بگیرد. یک 502 یعنی یک گفتوگو با ماشین پشتی شکست خورده. در عمل یک 503 اغلب یک موضوع ظرفیت یا پیکربندی است که کنترلش دست شماست، و یک 502 اغلب یک origin خراب است.
آیا یک 503 به رتبهبندی جستوجوی من آسیب میزند؟
اگر واقعاً موقت باشد، نه. موتورهای جستوجو 503 را «بعداً برگرد» در نظر میگیرند، و همین است که آن را در حین نگهداری کد درستی میکند. یک 503 که روزها طول میکشد موضوع دیگری است: صفحات در نهایت کنار گذاشته میشوند. Retry-After اضافه کنید تا خزنده بداند چه انتظاری داشته باشد.
بلافاصله بعد از هدایت DNS به سمت CDN، 503 میگیرم. حالا چه کنم؟
صفحهٔ خطا را بررسی کنید. اگر میگوید هیچ سرویسی برای دامنه پیکربندی نشده، هاستنیم هنوز روی edge تنظیم نشده — origin درگیر نیست. دقیقاً همان هاستنیم را در پنل اضافه کنید، با یا بدون www تا با رکورد DNS مطابقت داشته باشد، و 503 بهمحض اینکه پیکربندی به edgeها برسد پاک میشود.
آیا میتوانم یک 503 را cache کنم؟
نباید، یا فقط برای چند ثانیه. یک 503 cacheشده بعد از رفتن علت هم به ردکردن بازدیدکنندگان ادامه میدهد. پاسخهای خطا را با یک TTL بسیار کوتاه سرویس دهید و بهمحض اعمالشدن رفع مشکل، مسیر را purge کنید.
چگونه بدون یک سرور بزرگتر جلوی 503ها زیر بار را بگیرم؟
چیزی را که به origin میرسد کم کنید. هرچه را که cacheپذیر است با یک TTL که از یک جهش ترافیک جان سالم بهدر میبرد cache کنید، مطمئن شوید cache key با پارامترهای ردیابی تکهتکه نشده، و روی endpointهایی که ترافیک خودکار جذب میکنند rate limit نگه دارید. یک سرور بزرگتر سقف را بالا میبرد؛ cache اکثر درخواستهایی را که به آن فشار میآوردند برمیدارد.