سرور ساعتی یا ماهانه؟ نقطه‌ی سربه‌سر و ۱۰ روش کاهش هزینه

سرور ساعتی وقتی ارزان‌تر تمام می‌شود که ماشین شما واقعاً تمام ماه روشن نباشد؛ و «واقعاً» یعنی عددی که می‌شود حسابش کرد، نه حسی که می‌شود درباره‌اش بحث کرد. این راهنما فرمول نقطه‌ی سربه‌سر را می‌سازد، شش الگوی مصرف را با عدد مقایسه می‌کند و ده روش اندازه‌گیری‌شده می‌دهد.

واحد صورتحساب سرور ساعتی: چرا «ماهانه تقسیم بر ۷۳۰» جواب نمی‌دهد؟

سرور ساعتی یعنی واحد صورتحساب از «ماه» به «ساعت» تغییر می‌کند: به‌جای مبلغی ثابت در ابتدای دوره، هزینه‌ی هر ساعت روشن‌بودن ماشین از کیف پول کسر می‌شود. ماه استاندارد در این محاسبه ۷۳۰ ساعت است، اما تفاوت واقعی در تقسیم عدد نیست؛ در حق «قطع‌کردن» است.

اگر مفهوم پایه و مکانیزم کیف پول را ندیده‌اید، اول راهنمای مفهومی سرور ابری ساعتی را بخوانید؛ تمرکز این مقاله روی عدد است.

سه تفاوتی که در جدول تعرفه دیده نمی‌شود

• دانه‌بندی. در مدل ماهانه کوچک‌ترین واحدی که می‌خرید یک ماه است؛ در مدل ساعتی یک ساعت. خطای تصمیم شما به‌جای ۷۳۰ ساعت، یک ساعت هزینه دارد.
• تخفیف تعهد. اجاره‌ی ماهانه معمولاً از ضرب نرخ ساعتی در ۷۳۰ ارزان‌تر است، چون در ازای تعهد تخفیف می‌گیرید. همین تخفیف نقطه‌ی سربه‌سر را از ۷۳۰ ساعت پایین‌تر می‌کشد.
• «خاموش» در برابر «حذف». در مدل ماهانه خاموش‌کردن صرفه‌ای ندارد. در مدل ساعتی صرفه دارد اما کامل نیست؛ تا وقتی سرور وجود دارد منابعش رزرو می‌ماند و درصدی از نرخ محاسبه می‌شود.

جمع‌بندی در یک جمله: سرور ساعتی ابزار مدیریت عدم قطعیت است. هرجا نمی‌دانید تا کِی به ماشین نیاز دارید، پرداخت به‌اندازه‌ی مصرف ارزان‌تر است؛ هرجا مطمئنید ماه‌ها روشن می‌ماند، تعهد بلندمدت.

فرمول نقطه‌ی سربه‌سر: از چند ساعت به بعد ماهانه برنده می‌شود؟

نقطه‌ی سربه‌سر تعداد ساعت‌هایی است که در آن، هزینه‌ی مدل ساعتی دقیقاً با اجاره‌ی ماهانه برابر می‌شود. پاسخ به یک شرط بستگی دارد: در ساعت‌های بیکاری سرور را حذف می‌کنید یا فقط خاموش؟ اگر حذف کنید، این نقطه برابر M ÷ H است؛ اگر فقط خاموش کنید، سرور همچنان درصدی از نرخ کامل را می‌گیرد و مرز پایین‌تر می‌آید.

H را از محاسبه‌گر قیمت صفحه‌ی اصلی بردارید؛ تعرفه شناور است و همان‌جا مرجع به‌روز است. M عددِ همان پیکربندی در سرویس اجاره‌ی ماهانه‌ای است که می‌خواهید با آن مقایسه کنید — مهران هاست خودش قرارداد ماهانه ندارد، پس M ورودیِ بیرونیِ مقایسه‌ی شماست. درصد نرخ سرورِ خاموش در قوانین سرویس آمده است.

# M = monthly price of a spec, H = its full hourly rate
# k = share of H still charged while the VM is powered OFF (0 = free, 0.5 = half)
#
# case A - server is DELETED during idle hours:
#     N* = M / H
# case B - server is only POWERED OFF (it keeps existing):
#     H*n + k*H*(730-n) = M   ->   N* = (M/H - 730*k) / (1 - k)

# unitless ratio only - no currency, no real tariff:
R=500        # = M / H
K=0.5        # off-state share of the full rate
awk -v r=$R -v k=$K 'BEGIN{
  b=(r-730*k)/(1-k);
  printf "delete-when-idle: %.0f h/month (%.1f h/day)\n", r, r/30.4;
  printf "power-off-only  : %.0f h/month (%.1f h/day)\n", b, b/30.4;
}'
# delete-when-idle: 500 h/month (16.4 h/day)
# power-off-only  : 270 h/month (8.9 h/day)

تفاوت این دو خط، کل داستان است: اگر ماشین را فقط خاموش کنید، پیش از نُه ساعت کار در روز مدل ماهانه برنده شده؛ اما اگر بکاپ بگیرید و سرور را حذف کنید، تا حدود شانزده ساعت در روز هم مدل ساعتی ارزان‌تر می‌ماند.

یک ظرافت: تا وقتی سرور وجود دارد، همه‌ی منابعش — رم، پردازنده، دیسک و آی‌پی — روی سخت‌افزار میزبان رزرو می‌ماند. به همین دلیل خاموش‌کردن نرخ ساعتی را صفر نمی‌کند، بلکه به درصدی از آن کاهش می‌دهد. پس خط ساعتی عرض از مبدأ واقعی دارد.

ساعت‌های روشن‌بودن واقعی را حدس نزنید، بخوانید

تخمین‌های اشتباه از این‌جا می‌آید که فکر می‌کنیم سرور «فقط چند ساعت» روشن است، در حالی که هفته‌هاست خاموش نشده. دو راه: ریز تراکنش‌های پنل، و شمارنده‌ی کرنل:

uptime -s
# 2026-07-21 09:12:44   -> exact boot time

awk '{printf "uptime: %.1f h\n", $1/3600}' /proc/uptime
# uptime: 484.2 h        -> hours since the last power-on

یک هشدار مهم: این دو عدد فقط از آخرین روشن‌شدن می‌شمارند و با هر ریبوت صفر می‌شوند، در حالی که ریبوت جلوی محاسبه را نمی‌گیرد — فقط خاموشی می‌گیرد. پس این عدد کفِ ساعت‌های محاسبه‌شده است؛ فهرست کامل را با last -x reboot shutdown ببینید.

کدام الگوی مصرف با اجاره‌ی سرور ساعتی می‌صرفد؟ شش سناریوی واقعی

مدل ساعتی زمانی می‌صرفد که ساعت‌های روشن‌بودن ماشین از نقطه‌ی سربه‌سر کمتر بماند. جدول زیر شش الگوی رایج را با فرض «حذف سرور در دوره‌های بیکاری» و نقطه‌ی سربه‌سر ۵۰۰ ساعت در ماه مقایسه می‌کند. اگر به‌جای حذف فقط خاموش می‌کنید، مرز به حدود ۲۷۰ ساعت پایین می‌آید و ردیف کمپین فصلی روی همان مرز می‌نشیند.

یک الگوی هفتم هم هست که در جدول نمی‌گنجد، چون ساعت روشن‌بودنش از قبل معلوم نیست: سرور واسطی که برای آزمودن چند مسیر شبکه بالا می‌آید و بعد از انتخاب مسیر یا حذف می‌شود یا دائمی. معیارهای انتخاب و راه‌اندازی‌اش را در راهنمای سرور مناسب تانل آورده‌ایم؛ همین‌جا فقط بدانید که در دوره‌ی آزمون، مدل ساعتی تنها مدلی است که اجازه می‌دهد سه مسیر را امتحان کنید و بابت دوتایش پول ماه ندهید.

نمودار سربه‌سر را چطور بخوانیم؟

هزینه‌ی ماهانه خطی افقی است؛ هزینه‌ی ساعتی خطی شیب‌دار. محل تقاطع همان نقطه‌ی سربه‌سر است: سمت چپ قلمرو مدل ساعتی، سمت راست قلمرو ماهانه.

صورتحساب سرور ساعتی از چه اجزایی ساخته می‌شود؟

صورتحساب یک سرور ابری ساعتی از پنج جزء ساخته می‌شود: پردازنده، حافظه، دیسک، آی‌پی و ترافیک. نکته‌ی کلیدی این است که خاموش‌کردن هیچ‌کدام از چهار جزء اول را حذف نمی‌کند — منابعشان رزرو است — بلکه نرخ ساعتی را به درصدی از نرخ کامل کاهش می‌دهد. تنها ترافیک به زمان گره نخورده.

• پردازنده (CPU). به‌ازای هسته‌های اختصاص‌یافته محاسبه می‌شود، نه درصد مصرف. سرور بیکار همان‌قدر هزینه دارد که پرکار باشد؛ راه کم‌کردنش «کوچک‌کردن» است، نه «کارنکردن».
• حافظه (RAM). مثل پردازنده، عدد اختصاص‌یافته ملاک است. رمی که هرگز پر نمی‌شود، هزینه‌ی خالص است.
• دیسک NVMe. فضا روی سخت‌افزار میزبان اشغال است، چه روشن چه خاموش؛ آزادشدنش فقط با حذف سرور رخ می‌دهد.
• آی‌پی عمومی. منبعی کمیاب و رزروشده است. آی‌پی اضافه معمولاً فارغ از روشن یا خاموش‌بودن ماشین با نرخ کامل محاسبه می‌شود.
• ترافیک. به گیگابایت جابه‌جاشده گره خورده، نه به زمان. سرور می‌تواند ۲۴ ساعت روشن باشد و چیزی مصرف نکند، یا در دو ساعت صدها گیگابایت.

یک آزمون یک‌باره: سرور را عمداً یک ساعت خاموش بگذارید و ریز تراکنش آن ساعت را در پنل ببینید. اختلافش با نرخ یک ساعت روشن، همان kای است که در فرمول می‌گذارید.

ده روش اندازه‌گیری‌شده برای کاهش هزینه‌ی سرور ساعتی (به ترتیب اثر)

در مدل ساعتی هزینه از سه جا نشت می‌کند: ماشینی بزرگ‌تر از نیاز، ساعت‌هایی که بی‌دلیل روشن مانده، و منابعی که بعد از پایان کار کسی سراغشان نرفته. ده روش زیر از بیشترین اثر به کمترین مرتب شده‌اند؛ چهار مورد اول بیشترین کاهش را می‌دهند.

۱) راست‌اندازه‌کردن بر اساس مصرف واقعی

بیشتر سرورها یک پله بزرگ‌تر از نیازشان ساخته می‌شوند، چون روز اول کسی مصرف واقعی را نمی‌داند. مشکل این است که htop و free -m فقط همین ثانیه را نشان می‌دهند و هیچ‌وقت جواب نمی‌دهند که «اوج این هفته چقدر بود». برای تصمیم راست‌اندازه به تاریخچه نیاز دارید؛ یک هفته بعد داده دارید، به شرطی که همان روز اول sysstat را فعال کرده باشید:

# Debian / Ubuntu
sudo apt install sysstat -y
sudo sed -i 's/^ENABLED=.*/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat

# AlmaLinux / Rocky
sudo dnf install -y sysstat
sudo systemctl enable --now sysstat sysstat-collect.timer sysstat-summary.timer

sar -r          # memory history for today
sar -u          # CPU history for today
# history files: /var/log/sysstat/ on Debian, /var/log/sa/ on RHEL family

جمع‌آوری از لحظه‌ی نصب شروع می‌شود؛ تا چند ساعت بعد sar پیام «Cannot open …» می‌دهد. قاعده‌ی تصمیم: اگر اوج مصرف رم در یک هفته زیر ۵۰ درصد و میانگین پردازنده زیر ۲۰ درصد بماند، یک پله کوچک‌تر بسازید. ملاک اوج است نه میانگین — میانگین شما را به OOM Killer می‌رساند.

۲) خاموشی زمان‌بندی‌شده با کرون

محیط تست و ماشین آموزشی دلیلی برای روشن‌ماندن ندارند. یک خط کرون ساعت‌های ماه را از ۷۳۰ به حدود ۲۰۰ می‌رساند:

# root crontab — power off at 18:00, Iranian work week (Sat–Wed)
# cron day-of-week: 0=Sun 1=Mon 2=Tue 3=Wed 4=Thu 5=Fri 6=Sat
0 18 * * 0,1,2,3,6 /usr/sbin/shutdown -h now

ایمیج‌های ابری معمولاً روی UTC تحویل می‌شوند؛ منطقه‌ی زمانی را با sudo timedatectl set-timezone Asia/Tehran اصلاح کنید. تله‌های زمان‌بندی در آموزش کرون جاب.

۳) داده را از عمر ماشین جدا کنید

دلیل اصلی این‌که سرورهای بی‌مصرف حذف نمی‌شوند ترس است: «اگر چیزی رویش باشد چه؟» راه‌حل، آرشیوی بیرون از سرور است:

set -euo pipefail
STAMP=$(date +%F)
DEST=/root/state ; sudo install -d -m 700 "$DEST"

sudo tar -czf "$DEST/state-$STAMP.tar.gz" /var/www /etc/nginx /etc/letsencrypt
# credentials come from ~/.my.cnf so they never land in shell history
mysqldump --single-transaction --routines --events app > "$DEST/app-$STAMP.sql"
sudo chmod 600 "$DEST"/*
scp "$DEST/state-$STAMP.tar.gz" "$DEST/app-$STAMP.sql" user@keeper:/backups/

خروجی را در /tmp نسازید؛ آن مسیر برای همه‌ی کاربران سرور خواندنی است. قدم بعدی، نگه‌داشتن داده روی دیسکی جداست: با /var/www روی دیسک دوم، بازساختن ماشین یعنی نصب دوباره‌ی سیستم‌عامل و اتصال همان دیسک. آزمون بازیابی در آموزش بکاپ‌گیری از سرور لینوکس.

۴) ترافیک خروجی را به ترتیب اثرش روی صورتحساب کم کنید

ترافیک تنها جزء صورتحساب است که با بهینه‌سازی نرم‌افزاری کم می‌شود، بدون کوچک‌کردن ماشین. پیکربندی کامل در راهنمای پهنای باند و ترافیک سرور مجازی آمده؛ اینجا ترتیب اثر مهم است:

• تصویر، اول از همه. بر اساس سند رسمی WebP گوگل، تصاویر WebP به‌طور میانگین حدود ۳۰ درصد از JPEG هم‌کیفیت و ۲۶ درصد از PNG بی‌اتلاف کوچک‌ترند؛ چون تصویر بزرگ‌ترین سهم ترافیک را دارد، همین درصد روی صورتحساب می‌نشیند.
• کش مرورگر، دوم. هدر Cache-Control بازدیدکننده‌ی برگشتی را از دانلود دوباره بی‌نیاز می‌کند. immutable را فقط روی فایلی بگذارید که نامش با هر نسخه عوض می‌شود، وگرنه نسخه‌ی جدید برای بازدیدکننده‌ی قدیمی اعمال نمی‌شود.
• فشرده‌سازی، سوم. gzip فقط روی پاسخ‌های متنی اثر دارد؛ روی JPEG و MP4 چیزی کم نمی‌کند و فقط پردازنده می‌سوزاند — که خودش پول است.

۵) ایمیج و سرویس‌های غیرلازم را حذف کنید

هر سرویسی که بی‌دلیل بالا می‌آید رم اشغال می‌کند، و رم اشغال‌شده یعنی یک پله بزرگ‌تر می‌خرید. بعد از نصب، فهرست سرویس‌های در حال اجرا را جدی نگاه کنید:

systemctl list-units --type=service --state=running
systemd-analyze blame | head -15
ps aux --sort=-%mem | head -10

sudo systemctl disable --now <service-you-do-not-need>

هر خط چه می‌گوید: list-units --state=running سرویس‌های در حال اجرا را فهرست می‌کند؛ systemd-analyze blame زمان راه‌اندازی هر یونیت در بوت را مرتب می‌کند — برای یافتن سرویس‌های بی‌دلیل، نه برای سنجش حافظه؛ و ps aux --sort=-%mem مصرف رم را نشان می‌دهد.

۶) اسنپ‌شات‌ها و بکاپ‌های فراموش‌شده را پاک کنید

اسنپ‌شات‌ها بی‌صدا هزینه می‌سازند: پیش از تغییری بزرگ ساخته می‌شوند و بعد کسی سراغشان نمی‌رود. سیاست ساده: فقط «قبل از تغییر پرریسک» و حذف در همان روز.

df -h /
sudo du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -15

journalctl --disk-usage
sudo journalctl --vacuum-time=14d        # keeps only the last 14 days of logs

# 1) list first — read the output before deleting anything
sudo find /backup -type f -name '*.tar.gz' -mtime +14 -print
# 2) only then delete
sudo find /backup -type f -name '*.tar.gz' -mtime +14 -delete

# Debian / Ubuntu — run without -y once and read the removal list
sudo apt-get autoremove --purge
sudo apt-get clean

# AlmaLinux / Rocky
sudo dnf autoremove
sudo dnf clean all

اگر داکر دارید، ایمیج‌های بلااستفاده بزرگ‌ترین مصرف‌کننده‌اند. اما docker system prune -a فقط ایمیج پاک نمی‌کند؛ همه‌ی کانتینرهای متوقف‌شده و شبکه‌های بلااستفاده را هم حذف می‌کند.

docker system df                 # where the space actually is
docker image prune -a            # unused images only — safest first step
docker builder prune             # build cache only

# system prune -a ALSO removes every stopped container and unused network:
docker ps -a                     # check this list first
docker system prune -a

۷) چند سرویس کوچک را روی یک ماشین جمع کنید

پنج سرویس کوچک — سه ربات، یک API سبک و یک سایت شخصی — روی پنج سرور جدا، پنج برابر هزینه‌ی دیسک و آی‌پی دارند، در حالی که مجموع مصرفشان از یک ماشین متوسط کمتر است. برای بارهای کم‌ریسک، تجمیع سریع‌ترین کاهش هزینه‌ی سرور است — به شرط ایزولاسیون با کانتینر.

۸) روند مصرف را ببینید، نه فقط لحظه را

غافلگیری مالی نتیجه‌ی ندیدن است. دو عدد را هفتگی ببینید: ساعت روشن‌بودن و گیگابایت ترافیک.

# Debian / Ubuntu
sudo apt install vnstat -y

# AlmaLinux / Rocky (EPEL)
sudo dnf install -y epel-release && sudo dnf install -y vnstat

sudo systemctl enable --now vnstat
vnstat -m          # monthly traffic table
vnstat -d          # daily breakdown
uptime -p          # how long this machine has been running

vnstat از لحظه‌ی نصب می‌شمارد، پس جدول ماه اول ناقص است. روند مهم‌تر از عدد است: ترافیکی که سه ماه پیاپی رشد کرده، ماه چهارم هم رشد می‌کند. داشبورد و هشدار خودکار در آموزش مانیتورینگ سرور.

۹) برای خودتان اعلان بودجه بسازید

در مدل پرداخت به‌اندازه‌ی مصرف، تنها چیزی که بین شما و صورتحساب غیرمنتظره می‌ایستد یک هشدار زودهنگام است. یک کرون هفتگی بسازید:

# /root/report.sh  (chmod 700 — keeps the token out of crontab)
#!/bin/bash
TOKEN=123456:AAyourtokenhere
CHAT=11111111
# field number differs between vnstat versions - run it once to confirm
MONTH=$(vnstat --oneline | cut -d';' -f11)   # field 11 = total traffic this month
curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" \
  -d chat_id="$CHAT" \
  --data-urlencode "text=$(hostname) | up: $(uptime -p) | traffic: $MONTH"

# root crontab — weekly report, Saturday 09:00
# 0 9 * * 6 /root/report.sh

فیلد ۱۱ خروجی vnstat --oneline مجموع ترافیک ماه جاری است؛ فیلدهای ۹ و ۱۰ دریافتی و ارسالی ماه‌اند. --data-urlencode اختیاری نیست: -d محتوا را کدگذاری نمی‌کند و پیامِ حاوی فاصله و | مخدوش می‌رسد.

۱۰) محیط‌های آزمایشیِ تمام‌شده را واقعاً حذف کنید

ساده‌ترین و کم‌اجراترین روش. وقتی آزمایشی تمام شد، ماشین را خاموش نکنید — حذفش کنید: بکاپ نهایی، اطمینان از بازیابی‌پذیر بودنش، و حذف سرور به‌همراه اسنپ‌شات‌های وابسته.

دام‌های سرور ساعتی که صورتحساب را بی‌صدا بالا می‌برند

سرور ساعتی ذاتاً ارزان نیست؛ فقط صادق است. صورتحساب همان چیزی را نشان می‌دهد که ساخته‌اید و روشن گذاشته‌اید. دفاع در برابر بیشتر دام‌های زیر از جنس عادت است، نه تنظیمات.

• سروری که یادتان رفت. ماشینی که برای یک تست دو ساعته ساخته شده و شش هفته روشن مانده. تنها دفاع مؤثر، مرور ماهانه‌ی فهرست سرورهاست.
• اسنپ‌شات یتیم. سرور حذف شده ولی اسنپ‌شات یا دیسکش مانده و فضا رزرو می‌کند. بعد از هر حذف، فهرست اسنپ‌شات‌ها را ببینید.
• جهش ترافیک بعد از انتشار. فایل حجیمی که ناگهان زیاد دانلود می‌شود می‌تواند از هزینه‌ی چند هفته سرور بیشتر شود. در Nginx دو دستور limit_rate و limit_conn جهش را به شیبی قابل‌کنترل تبدیل می‌کنند.
• بار پایدارِ بلندمدت. اگر سرویس ۲۴ ساعته و ماه‌هاست ثابت است، مدل ساعتی لزوماً ارزان‌ترین گزینه نیست.

چه زمانی اصلاً نباید سرور ساعتی بگیرید؟

سرور مجازی ساعتی برای هر پروژه‌ای بهترین انتخاب نیست. در سه موقعیت گزینه‌ی دیگری منطقی‌تر است: وقتی نیازتان یک سایت کوچک است، وقتی بار تولیدی سنگین و پایدار دارید، و وقتی وقت مدیریت سیستم‌عامل را ندارید. هزینه‌ی پنهان زمان را هم در محاسبه بیاورید.

• یک سایت وردپرسی یا شرکتی کوچک. اگر قرار نیست سرویس اختصاصی نصب کنید، میزبانی وب اشتراکی با cPanel و DirectAdmin ساده‌تر است. تفاوت دو مسیر در مقایسه‌ی هاست اشتراکی و سرور مجازی.
• سرویس تولیدی سنگین و همیشه‌روشن. وقتی بار پایدار است و از یک ماشین متوسط عبور کرده، مسیر راهکارهای سازمانی با منابع اختصاصی جواب درست‌تری می‌دهد.
• وقتی وقت مدیریت سرور را ندارید. سرور رهاشده‌ی بدون به‌روزرسانی، گران‌ترین گزینه است. معیارها در راهنمای خرید سرور مجازی آمده است.

چک‌لیست هفت‌قدمی ممیزی ماهانه‌ی هزینه‌ی سرور

ممیزی ماهانه یعنی ده دقیقه وقت برای هفت بررسی که بیشتر نشتی‌های صورتحساب را پیش از بزرگ‌شدن می‌گیرند: سرورهای بی‌صاحب، مدل اشتباه، اندازه‌ی نامتناسب، اسنپ‌شات فراموش‌شده، رشد ترافیک، دیسک در حال پرشدن و موجودی ناکافی کیف پول. آن را ابتدای هر ماه انجام دهید، نه وقتی صورتحساب غافلگیرتان کرد.

1. برای هر سرور فعال یک جمله بنویسید: «این ماشین چه می‌کند؟» هر ماشینی که جمله ندارد، کاندیدای حذف است.
2. ساعت‌های روشن‌بودن ماه گذشته را با نقطه‌ی سربه‌سر مقایسه کنید تا مدل درست را بسنجید.
3. اوج مصرف رم و پردازنده را با sar -r و sar -u ببینید و درباره‌ی یک پله تصمیم بگیرید.
4. اسنپ‌شات‌ها و بکاپ‌ها را مرور کنید و هرچه سیاست نگه‌داری ندارد حذف کنید.
5. ترافیک ماه را با vnstat -m ببینید و رشد سه ماه اخیر را بسنجید.
6. فضای دیسک را با df -h چک کنید و لاگ رشدکننده را مهار کنید.
7. موجودی کیف پول را با تخمین ماه بعد مقایسه و پیش از شروع ماه شارژ کنید.

سؤالات پرتکرار

هزینه‌ی سرور ساعتی ماه آینده را چطور تخمین بزنم؟

سه ورودی لازم دارید: نرخ ساعتی پیکربندی، ساعت‌های روشن‌بودن و حجم ترافیک. ساعت‌ها را از ریز تراکنش‌های ماه گذشته بردارید نه از حافظه‌تان، و حدود ۲۰ تا ۲۵ درصد بابت «روزهای فراموشی» به آن اضافه کنید. بعد ساعت‌های روشن را در نرخ کامل و ساعت‌های خاموش را در درصد اعلام‌شده‌ی حالت خاموش ضرب کنید و هزینه‌ی ترافیک را جداگانه رویش بیاورید — چهار جزء اول صورتحساب به زمان گره خورده‌اند و ترافیک به حجم داده. حاصل جمع را با موجودی کیف پول مقایسه کنید، نه با تعرفه‌ی تبلیغ‌شده‌ی یک ساعت.

اگر سرور را خاموش کنم، هزینه‌اش صفر می‌شود؟

نه. تا وقتی سرور وجود دارد، رم و پردازنده و دیسک و آی‌پی‌اش روی سخت‌افزار میزبان رزرو مانده‌اند؛ بنابراین خاموش‌کردن نرخ ساعتی را کاهش می‌دهد اما صفر نمی‌کند و درصد دقیقش در قوانین سرویس و ریز تراکنش‌های پنل اعلام می‌شود. برای توقف کامل هزینه باید سرور و اسنپ‌شات‌ها و دیسک‌های وابسته‌اش حذف شوند. قاعده‌ی عملی: وقفه‌ی چندروزه را خاموش کنید و برای وقفه‌ی چندهفته‌ای بکاپ بگیرید و حذف کنید.

نقطه‌ی سربه‌سر سرور ساعتی و ماهانه را چطور حساب کنم؟

اجاره‌ی ماهانه‌ی یک پیکربندی را بر نرخ ساعتی همان پیکربندی تقسیم کنید؛ نتیجه تعداد ساعت‌هایی است که دو مدل در آن برابر می‌شوند — به شرط حذف سرور در ساعت‌های بیکاری. اگر فقط خاموش می‌کنید، چون سرور خاموش هم درصدی از نرخ را می‌گیرد، این مرز پایین‌تر می‌آید؛ با نرخ خاموشیِ نصف، نقطه‌ی سربه‌سر برابر است با دو برابرِ همان نسبت منهای ۷۳۰ ساعت.

برای یک سایت همیشه‌روشن ۲۴ ساعته، اجاره‌ی سرور ساعتی به‌صرفه است؟

معمولاً نه، مگر در دوره‌ی ارزیابی. سرویسی که ماه‌ها بدون وقفه روشن است از انعطاف مدل ساعتی استفاده نمی‌کند و بهتر است بابتش هزینه ندهد. اما استفاده‌ی هوشمندانه از مدل ساعتی برای همین پروژه‌ها هم وجود دارد: پیش از تعهد بلندمدت چند روز سرور بسازید و همان چند روز را صرف اندازه‌گیری کنید — steal time، نرخ واقعی دیسک و کیفیت مسیر شبکه؛ چک‌لیست کاملش در راهنمای تست کیفیت سرور ایران آمده است. هزینه‌ی این دوره در برابر یک سال تعهد روی سرور اشتباه، تقریباً هیچ است.

چطور جلوی صورتحساب غافلگیرکننده را در مدل پرداخت به‌اندازه‌ی مصرف بگیرم؟

سه لایه کافی است. اول، مرور ماهانه‌ی فهرست سرورها و اسنپ‌شات‌ها تا هیچ منبع فراموش‌شده‌ای باقی نماند. دوم، پایش دو عدد کلیدی — ساعت‌های روشن‌بودن و ترافیک ماهانه — با uptime و vnstat. سوم، یک هشدار هفتگی خودکار با کرون. و لایه‌ی صفرم، شارژ کیف پول به‌اندازه‌ی تخمین ماه است، نه بیشتر؛ سقف موجودی خودش نقش ترمز را بازی می‌کند.

قدم بعدی

خلاصه‌ی عملی: اول مشخص کنید در ساعت‌های بیکاری سرور را حذف می‌کنید یا فقط خاموش، چون همین تصمیم مرز سربه‌سر را جابه‌جا می‌کند؛ بعد ساعت‌های روشن‌بودن واقعی را بخوانید. نرخ ساعتی به‌روز را از محاسبه‌گر قیمت بردارید و در فرمول بگذارید.

و اگر می‌خواهید فرض‌هایتان را بیازمایید — مثلاً یک پله کوچک‌تر را تست کنید — یک سرور ابری ساعتی در مهران هاست بسازید: روی KVM و دیسک NVMe در دیتاسنتر ایران، تحویل معمولاً کمتر از ۶۰ ثانیه، و پرداخت فقط بابت ساعت‌هایی که ماشین روشن بوده است.