۰ تا ۱۰۰ راه‌اندازی سرور ابری امن و سریع

راه‌اندازی یک سرور ابری در ۵ دقیقه ممکن است، اما راه‌اندازی Production (امن، پایدار، قابل مانیتور و قابل بازیابی) یک داستان دیگر است.
این مقاله یک چک‌لیست مرحله‌ای می‌دهد تا سرور شما:

• کمتر هک‌پذیر باشد
• کند نشود
• در بحران‌ها قابل بازیابی باشد
• و هزینه‌اش از کنترل خارج نشود

لایه ۱: پایه‌های امنیت (Day 0)

۱) دسترسی SSH را استاندارد کنید

• ورود با پسورد را تا جای ممکن غیرفعال کنید و از SSH Key استفاده کنید.
• برای ادمین، یک یوزر جدید بسازید و با sudo کار کنید (با root مستقیم کار نکنید).
• دسترسی SSH را فقط به IPهای مشخص (اگر ممکن است) محدود کنید.

۲) فایروال حداقلی

فقط پورت‌های لازم را باز کنید:

• 22 (SSH) ترجیحاً محدودشده
• 80/443 (HTTP/HTTPS)
• هر سرویس دیگر فقط اگر واقعاً نیاز است (مثلاً دیتابیس را عمومی نکنید)

۳) به‌روزرسانی و پچ‌ها

• آپدیت امنیتی منظم را فعال کنید.
• کرنل/پکیج‌های حساس را جدی بگیرید (تاخیر در پچ = افزایش ریسک)

لایه ۲: پایداری و بازیابی (Backups & DR)

۴) بکاپ را “قبل از نیاز” طراحی کنید

حداقل‌ها:

• بکاپ دیتابیس (روزانه یا بیشتر، بسته به حجم تغییر)
• بکاپ فایل‌های حیاتی (uploads، کانفیگ‌ها)
• نگهداری چند نسخه (مثلاً ۷ روز + ۴ هفته)

۵) Snapshot / Image با برنامه

• اسنپ‌شات خوب است، اما جایگزین بکاپ اپلیکیشن/دیتابیس نیست.
• برای کاهش ریسک: بکاپ اپلیکیشن + بکاپ دیتابیس + Snapshot زیرساخت

۶) تست بازیابی

بکاپی که تست نشده، بکاپ نیست. ماهی یک‌بار روی یک سرور تست:

• ریستور دیتابیس
• بالا آوردن سرویس
• چک سلامت

لایه ۳: عملکرد (Performance) برای وب و API

۷) وب‌سرور و TLS درست

• Nginx یا معادلش را استاندارد کانفیگ کنید.
• HTTPS اجباری + ریدایرکت درست
• فشرده‌سازی (gzip/brotli) و کش استاتیک‌ها

۸) کش کاربردی (بدون پیچیدگی اضافی)

• اگر وردپرس/فروشگاه دارید: Page Cache + Object Cache (در صورت نیاز)
• اگر API دارید: Cache در لایه اپ یا CDN برای پاسخ‌های قابل کش

۹) دیتابیس را جداگانه جدی بگیرید

• دیتابیس را روی اینترنت عمومی نگذارید.
• ایندکس‌ها و کوئری‌های سنگین را مانیتور کنید.
• اگر رشد دارید: دیتابیس مدیریت‌شده یا حداقل سرور جدا برای DB را در نقشه راه بگذارید.

لایه ۴: مانیتورینگ، لاگ و هشدار (Observability)

۱۰) حداقل متریک‌هایی که باید داشته باشید

• CPU / RAM / Disk / Network
• Load Average
• Error Rate (۵xx) و Latency (p95/p99)
• فضای دیسک و رشد لاگ‌ها

۱۱) هشدارهای ضروری

هشدارها را طوری تنظیم کنید که “واقعاً اقدام‌پذیر” باشند:

• Disk usage > 80%
• Memory pressure بالا
• Error rate غیرعادی
• Down شدن سرویس (Healthcheck)

۱۲) لاگ‌ها را قابل جستجو کنید

حداقل:

• لاگ اپلیکیشن
• لاگ وب‌سرور
• لاگ سیستم و امنیت (auth)

لایه ۵: کنترل هزینه (FinOps سبک برای تیم کوچک)

۱۳) سه عامل اصلی افزایش هزینه

• ترافیک خروجی (Egress)
• ذخیره‌سازی و Snapshotهای انباشته
• ماشین بزرگ‌تر از نیاز (Overprovisioning)

۱۴) اصول ساده برای کنترل هزینه

• از CDN برای فایل‌های استاتیک استفاده کنید (کاهش فشار سرور + کاهش ترافیک مستقیم)
• Snapshot/Backup retention را محدود کنید
• ماهی یک‌بار “اندازه منابع” را بازبینی کنید: آیا واقعاً این CPU/RAM لازم است؟

چک‌لیست نهایی (کپی/پیست برای اجرا)

امنیت

• SSH Key فعال، پسورد محدود/غیرفعال
• یوزر غیر root + sudo
• فایروال فقط برای پورت‌های ضروری
• آپدیت‌های امنیتی فعال

پایداری

• بکاپ دیتابیس زمان‌بندی‌شده
• بکاپ فایل‌ها/کانفیگ‌ها
• Snapshot با Retention مشخص
• تست ریستور ماهانه

کارایی

• HTTPS اجباری
• کش استاتیک + فشرده‌سازی
• دیتابیس ایزوله و محافظت‌شده

Observability

• متریک‌های پایه فعال
• هشدارهای Disk/RAM/Error Rate
• لاگ‌ها قابل جستجو و نگهداری استاندارد

هزینه

• بازبینی ماهانه منابع
• کنترل Snapshot/Storage
• استفاده از CDN (در صورت نیاز)