ساعت ۱۰ صبح است و ناگهان سایت بالا نمیآید. پنل مدیریت هم کند شده یا خطا میدهد. پیام های واتساپ و تماس های مشتریان شروع میشود: «سایتتون باز نمیشه»، «پرداخت انجام شد ولی سفارش ثبت نشده»، «گوگل خطای ۵۰۰ میده». تیم داخل شرکت یا استارتاپ دور هم جمع میشود اما یک مشکل جدی وجود دارد: کسی نمیداند از کجا باید شروع کند تا هم سریع سرویس را برگرداند، هم بعد از چند ساعت دوباره زمین نخورد. این مقاله دقیقاً برای همین لحظه نوشته شده؛ یک راهنمای عملیاتی و بحران محور برای بازیابی سایت بعد از خرابی، با سه سناریوی رایج در پروژه های واقعی ایران: آپدیت نادرست، حمله یا نفوذ، و مشکل سرور یا دیتابیس.
چارچوب مشترک بازیابی سایت بعد از خرابی (قبل از ورود به سناریوها)
در بحران، وسوسه اصلی این است که «فقط درستش کن»؛ اما بدون چارچوب، معمولاً به خرابکاری دوم میرسید: لاگ ها از بین میروند، فایل ها دستکاری میشوند، و ریشه مشکل نامشخص میماند. فارغ از اینکه وردپرس دارید یا سایت سفارشی، یک روند استاندارد مشترک وجود دارد که باید در ۱۰ تا ۲۰ دقیقه اول رعایت شود.
۱۰ دقیقه اول: هدف و مرزها
- هدف را مشخص کنید: «بازگشت سرویس حیاتی» (مثلاً صفحه پرداخت یا صفحه اصلی) یا «بازگشت کامل سایت».
- نقش ها را تعیین کنید: یک نفر Incident Lead (تصمیم گیر)، یک نفر برای سرور/DevOps، یک نفر برای اپلیکیشن/وردپرس، یک نفر برای ارتباطات.
- ثبت وقایع: زمان شروع، آخرین تغییرات (Deploy/Update)، پیام خطا، اسکرین شات، و اولین فرضیه ها.
اصل طلایی: تشخیص اولیه، ایزوله سازی، سپس تصمیم Fix یا Restore
سه گام ثابت که در هر سناریو تکرار میشود:
- تشخیص اولیه: خطای ۴۰۳/۵۰۰/۵۰۲، مصرف CPU/RAM، وضعیت دیتابیس، تغییرات اخیر، لاگ وب سرور و اپلیکیشن.
- ایزوله سازی: محدود کردن سطح آسیب (خاموش کردن ورودی مشکوک، تغییر رمزها، خارج کردن یک نود از لودبالنسر، توقف کران ها).
- تصمیم بین Restore یا Fix: اگر ریسک ادامه خرابی یا آلودگی بالاست، Restore اولویت دارد؛ اگر مشکل واضح و محدود است، Fix سریع منطقی است.
نکته: اگر ساختار سایت شما از ابتدا با اصول معماری و نگهداری درست طراحی نشده باشد، همین سه گام ساده هم زمان بر میشود. در طراحی سایت وردپرس معمولاً بخش مهمی از کار، استانداردسازی بکاپ، محیط تست و مسیر استقرار است تا بازیابی به یک کار «قابل تکرار» تبدیل شود.
سناریو ۱: خرابی ناشی از آپدیت نادرست (هسته، افزونه، قالب یا Deploy)
این سناریو در ایران بسیار رایج است: یک آپدیت وردپرس یا افزونه، یا یک Deploy بدون تست روی سرور اصلی، و نتیجه میشود صفحه سفید، خطای ۵۰۰، بهم ریختن استایل ها، یا اختلال در سبد خرید. ویژگی این سناریو این است که معمولاً «نقطه شروع زمانی» مشخص است: چند دقیقه یا چند ساعت بعد از یک تغییر.
تشخیص اولیه
- آخرین تغییر را پیدا کنید: چه کسی، چه زمانی، چه چیزی را تغییر داد؟
- لاگ خطا: error_log، لاگ PHP-FPM، لاگ وب سرور.
- بررسی سریع: آیا فقط فرانت مشکل دارد یا ادمین هم؟ آیا فقط یک مسیر (مثلاً پرداخت) خراب است؟
ایزوله سازی
- اگر وردپرس است: موقتاً افزونه های جدید/آپدیت شده را غیرفعال کنید (در صورت نبود دسترسی، از طریق تغییر نام پوشه افزونه).
- اگر Deploy شده: سرویس را به نسخه قبلی Rollback کنید (در صورت داشتن نسخه بندی).
- در صورت اختلال شدید، صفحه Maintenance کوتاه و شفاف نمایش دهید تا فشار تماس ها کمتر شود.
تصمیم: Fix یا Restore؟
اگر خطا مشخص و محدود است (مثلاً یک افزونه)، Fix سریع ارزش دارد. اما اگر چند بخش شکسته، دیتابیس مهاجرت ناقص داشته، یا نمیدانید دقیقاً چه چیزی تغییر کرده، Restore مطمئن تر است.
بازیابی و تست پس از بازیابی
- Restore فایل ها و دیتابیس به آخرین بکاپ سالم (ترجیحاً بکاپ قبل از آپدیت).
- تست مسیرهای حیاتی: ورود، ثبت سفارش/فرم، پرداخت، ایمیل ها، جستجو.
- پاکسازی کش ها (اپلیکیشن/سرور/CDN) با دقت، چون ممکن است مشکل را پنهان یا تکرار کند.
چالش رایج: بکاپ دارید، اما روی همان سرور نگه داشته شده و همراه خرابی از دسترس خارج است. راه حل: بکاپ خارج از سرور اصلی و تست دوره ای فرآیند Restore.
سناریو ۲: حمله یا نفوذ (Defacement، بدافزار، ریدایرکت اسپم، دسترسی غیرمجاز)
در این سناریو، «برگرداندن سریع سایت» کافی نیست، چون ممکن است سایت دوباره آلوده شود یا اطلاعات کاربران در خطر باشد. نشانه ها میتواند شامل ریدایرکت به سایت های مشکوک، ایجاد کاربر ادمین ناشناس، تغییر فایل های هسته، ارسال ایمیل های اسپم، یا هشدار مرورگر/آنتی ویروس باشد.
تشخیص اولیه
- بررسی تغییرات اخیر در فایل ها (به ویژه فایل های ناشناس در روت و uploads).
- لاگ های ورود و فعالیت ادمین: IPها، زمان ها، تلاش های ناموفق.
- بررسی ریدایرکت ها و اسکریپت های تزریق شده در header/footer.
ایزوله سازی (اولویت شماره یک)
- سایت را موقتاً از دسترس عمومی خارج کنید یا دسترسی را محدود کنید (حداقل برای پنل مدیریت).
- تمام رمزها را تغییر دهید: هاست/SSH، دیتابیس، پنل مدیریت، کلیدهای API.
- اگر چند سایت روی یک سرور هستند، آلودگی احتمالی بین سایت ها را در نظر بگیرید.
تصمیم: Restore یا Fix؟
در نفوذ، Restore بدون پاکسازی ریشه مشکل، فقط «بازگرداندن ظاهری» است. اگر بکاپ سالم دارید، معمولاً بهترین مسیر این است: Restore از بکاپ قبل از زمان نفوذ + بستن مسیر نفوذ (Patch) + چرخش کامل credentialها. اگر زمان نفوذ مشخص نیست، Fix و پاکسازی با تحلیل دقیق لازم میشود.
بازیابی، تست و اطلاع رسانی
- Restore نسخه سالم در محیط جداگانه یا حداقل پس از پاکسازی سرور.
- به روزرسانی هسته/افزونه ها و حذف افزونه های بدون پشتیبانی.
- تست امنیتی عملی: بررسی ایجاد کاربر، آپلود فایل، تغییرات غیرمجاز، و رفتارهای ریدایرکت.
- اطلاع رسانی متناسب با سطح حادثه: اگر داده حساس درگیر بوده، متن شفاف و دقیق آماده کنید.
برای سایت های حساس (مثلاً فروشگاه یا پلتفرم آموزشی) بهتر است این موضوع از ابتدا در طراحی زیرساخت و هویت دیجیتال دیده شود؛ چون معماری دسترسی ها، ساختار صفحات و نقش ها روی ریسک نفوذ اثر مستقیم دارد. اگر در حال بازطراحی هستید، خدمات هویت دیجیتال میتواند به استانداردسازی نقش ها، پیام های ارتباطی بحران و ساختار پایدار کمک کند.
سناریو ۳: مشکل سرور یا دیتابیس (Down شدن سرویس، پر شدن دیسک، کرش دیتابیس)
گاهی مشکل اصلاً از کد یا وردپرس نیست: سرور به دلیل مصرف منابع از کار افتاده، دیسک پر شده، دیتابیس قفل کرده، یا یک تغییر شبکه/فایروال باعث ۵۰۲/۵۰۴ شده است. این سناریو در سایت های پرترافیک یا فروشگاه ها بیشتر دیده میشود، مخصوصاً وقتی مانیتورینگ و هشدار درست وجود ندارد.
تشخیص اولیه
- وضعیت سرویس ها: وب سرور، PHP-FPM/Node، دیتابیس، کش.
- منابع: CPU، RAM، Disk، Inode، تعداد کانکشن های دیتابیس.
- رویدادهای اخیر: افزایش ترافیک، کران های سنگین، کمپین تبلیغاتی، یا بات ها.
ایزوله سازی
- اگر دیسک پر است: سریعاً لاگ های حجیم را مدیریت کنید (بدون حذف کورکورانه فایل های سیستمی)، و فضای اضطراری آزاد کنید.
- اگر دیتابیس قفل است: کوئری های سنگین را شناسایی و متوقف کنید، یا موقتاً محدودیت روی برخی قابلیت ها بگذارید.
- اگر حمله ترافیکی مشکوک است: محدودسازی در لایه وب سرور/فایروال.
تصمیم: Restore یا Fix؟
در مسائل زیرساختی، Restore از بکاپ معمولاً راه حل اصلی نیست مگر اینکه دیتابیس خراب شده یا داده ها آسیب دیده باشد. در بسیاری مواقع Fix یعنی برگرداندن سرویس ها، افزایش منابع، یا حذف گلوگاه عملکردی. اگر دیتابیس corruption دارد، Restore آخرین راه قابل اتکا است.
تست پس از بازیابی
- تست پایداری ۳۰ تا ۶۰ دقیقه: خطاهای تکرارشونده، مصرف منابع، صف ایمیل/پرداخت.
- بررسی Core Web Vitals و زمان پاسخ سرور (برای پیشگیری از خرابی دوباره).
Recovery سریع در برابر Recovery پایدار: تفاوتی که هزینه واقعی را تعیین می کند
در بحران، «سریع بالا آوردن سایت» جذاب است، اما اگر تنها هدف همین باشد، معمولاً در ۲۴ تا ۷۲ ساعت آینده با خرابی دوم برمیگردید. Recovery سریع یعنی بازگرداندن دسترسی کاربر با کمترین زمان توقف. Recovery پایدار یعنی بازگرداندن سرویس به حالتی که علت ریشه ای کنترل شده و احتمال تکرار پایین آمده است.
| محور | Recovery سریع | Recovery پایدار |
|---|---|---|
| هدف | بازگشت سرویس در کوتاه ترین زمان | بازگشت سرویس + کاهش ریسک تکرار |
| تصمیم ها | راه حل های موقت، خاموش کردن قابلیت ها | اصلاح ریشه ای، استانداردسازی استقرار و بکاپ |
| ریسک | خرابی دوباره، از بین رفتن شواهد | زمان بیشتر، اما هزینه کمتر در بلندمدت |
| خروجی قابل تحویل | سایت بالا آمد | Runbook، گزارش حادثه، اقدام پیشگیرانه |
اگر سایت شما درآمدزا است (فروشگاه، جذب لید، رزرو وقت)، Recovery پایدار باید به یک استاندارد سازمانی تبدیل شود؛ یعنی بعد از هر حادثه، حداقل یک جلسه Postmortem کوتاه برگزار شود و ۳ اقدام پیشگیرانه مشخص گردد (مثلاً مانیتورینگ، محیط Stage، یا کاهش وابستگی به افزونه های پرریسک).
اطلاع رسانی و مدیریت ذی نفعان در زمان خرابی (کم حرف، دقیق، قابل پیگیری)
بخش مهمی از بازیابی سایت بعد از خرابی، خارج از کد اتفاق میافتد: مدیریت انتظارات مدیرعامل، تیم فروش، پشتیبانی و مشتریان. اگر اطلاع رسانی بی نظم باشد، فشار روانی تیم فنی بالا میرود و خطا بیشتر میشود.
قالب پیام داخلی (هر ۳۰ تا ۶۰ دقیقه)
- وضعیت: Down / Partial / Degraded
- دامنه اثر: چه بخش هایی درگیرند (پرداخت، ورود، پنل)
- اقدام انجام شده: ایزوله سازی، Rollback، Restore
- گام بعدی + زمان تخمینی
قالب پیام برای کاربران
به جای توضیح فنی، اثر را بگویید و مسیر جایگزین بدهید (مثلاً ثبت سفارش تلفنی یا فرم جایگزین). اگر حادثه امنیتی است، پیام باید با احتیاط و بر اساس سطح قطعیت منتشر شود تا هم شفاف باشد هم نادرست.
Runbook یک صفحه ای بازیابی سایت بعد از خرابی (اولویت و زمان بندی)
این Runbook برای استفاده عملی نوشته شده است. آن را در ابزار داخلی تیم یا کنار مستندات سرور نگه دارید. هدف: جلوگیری از تصمیم های هیجانی و یکسان سازی روند بازیابی.
۰ تا ۱۰ دقیقه: کنترل بحران
- یک Incident Lead تعیین کنید و یک کانال ارتباطی واحد بسازید.
- وضعیت را ثبت کنید: ساعت شروع، پیام خطا، اسکرین شات، آخرین تغییر.
- اثر را مشخص کنید: کل سایت یا فقط یک قابلیت (پرداخت/ورود/ادمین).
۱۰ تا ۳۰ دقیقه: تشخیص و ایزوله سازی
- بررسی زیرساخت: وضعیت سرویس ها، منابع، دیسک، دیتابیس.
- بررسی تغییرات: آپدیت/Deploy/افزونه جدید/تنظیمات سرور.
- ایزوله سازی: محدودسازی دسترسی ادمین، قطع مسیر مشکوک، توقف کران های پرهزینه.
۳۰ تا ۹۰ دقیقه: تصمیم Restore یا Fix و اجرای بازیابی
- اگر مشکل محدود و مشخص است: Fix کنترل شده انجام دهید و تغییرات را ثبت کنید.
- اگر مشکل مبهم یا پرریسک است: Restore از آخرین بکاپ سالم (ترجیحاً قبل از حادثه).
- اگر نفوذ محتمل است: چرخش کامل رمزها و بستن مسیر نفوذ را همزمان انجام دهید.
۹۰ تا ۱۸۰ دقیقه: تست، پایش و بازگشت به حالت پایدار
- تست مسیرهای حیاتی با چک لیست: پرداخت/فرم/ورود/ایمیل/جستجو.
- پایش لاگ و منابع برای حداقل ۶۰ دقیقه پس از بازگشت.
- اطلاع رسانی نهایی: وضعیت حل شد، اگر اثر روی سفارش ها/پرداخت ها بوده مسیر پیگیری بدهید.
تا ۴۸ ساعت بعد: پیشگیری از تکرار
- Postmortem کوتاه: علت ریشه ای، چرا کشف دیر شد، چه چیزی باید تغییر کند.
- اقدامات پیشگیرانه: مانیتورینگ، بکاپ خارج از سرور، محیط تست، محدودسازی دسترسی.
- به روزرسانی Runbook بر اساس تجربه همین حادثه.
اگر میخواهید این Runbook به جای یک متن، به بخشی از زیرساخت واقعی سایت تبدیل شود (با بکاپ قابل اتکا، محیط تست، و معماری قابل نگهداری)، میتوانید از طریق درخواست مشاوره مسیر درست را برای شرایط کسب وکار خودتان مشخص کنید.
منابع
Google SRE Book (Site Reliability Engineering) – Incident Response and Postmortem: https://sre.google/sre-book/
NIST Computer Security Incident Handling Guide (SP 800-61 Rev. 2): https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
