VPS مدیریت‌شده یا مدیریت‌نشده؛ کدام برای شماست؟

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

انتخاب بین VPS مدیریت‌شده و مدیریت‌نشده، مسئله‌ای مربوط به نیروی کار است، نه محصول. در حالت مدیریت‌نشده، مسئولیت patching، firewall، backupها، monitoring و reboot در ساعت 2 بامداد با شماست. در حالت مدیریت‌شده، ارائه‌دهنده بخشی از این کارها را برای شما انجام می‌دهد و میزان این خدمات بین میزبان‌ها تفاوت زیادی دارد. تنها مقایسه مفید، فهرست وظایفی است که هر plan از مسئولیت شما حذف می‌کند و مقایسه هزینه آن با زمان کاری خودتان است.

برای واژه managed تعریف استانداردی وجود ندارد. از نظر یک میزبان، این واژه یعنی operating system patch می‌شود و یک کارشناس به ticket پاسخ می‌دهد. از نظر میزبان دیگر، یعنی یک control panel نصب شده است و تمام امور بالاتر از آن با شماست. از نظر میزبان سوم، یعنی یک قرارداد خدمات مکتوب با زمان پاسخ مشخص. دو plan که همین واژه را دارند، ممکن است در تمام موارد مهم با یکدیگر تفاوت داشته باشند؛ بنابراین پیش از بررسی قیمت، سند محدوده خدمات را بخوانید. اگر هنوز در حال تصمیم‌گیری هستید که این ماشین اساساً برای چه کاری است، اینکه واقعاً با یک VPS چه کارهایی می‌توانید انجام دهید پرسش بهتری است که ابتدا باید پاسخ داده شود.

مواردی که باید یک نفر مسئولیت آن‌ها را بر عهده بگیرد

هر سرور در حال اجرا، فهرست یکسانی از وظایف دارد. در یک طرح مدیریت‌نشده، این فهرست بر عهده شماست. در یک طرح مدیریت‌شده، هزینه می‌کنید تا مواردی از این فهرست حذف شوند. فهرست را بررسی کنید و کنار هر مورد نام یک نفر را بنویسید.

• وصله‌گذاری سیستم‌عامل و راه‌اندازی‌های مجددی که به‌روزرسانی‌های kernel لازم دارند.
• قوانین firewall که هنگام افزودن و حذف سرویس‌ها باید صحیح نگه داشته شوند. مبانی firewall با ufw برای VPS قوانین اولیه را پوشش می‌دهد.
• دسترسی SSH: مدیریت کلیدها، غیرفعال‌کردن ورود با گذرواژه، لغو یک کلید هنگام خروج فرد از مجموعه، و داشتن راهی برای ورود دوباره وقتی دسترسی خودتان را قفل می‌کنید.
• پشتیبان‌گیری، یک نسخه در محل دیگری، و بازیابی‌ای که واقعاً آن را انجام داده‌اید.
• پایش، یعنی بدانید سرور قابل دسترسی است، دیسک فضای کافی دارد، سرویس همچنان در حال اجراست و گواهی منقضی نشده است.
• بررسی log و واکنش به زمانی که چیزی در آن logها نادرست به نظر می‌رسد.
• پیکربندی سرویس برای web server، database، reverse proxy و queue، در صورت استفاده از آن.
• تمدید گواهی و رفع مشکل زمانی که تمدید خودکار از کار می‌افتد.
• ظرفیت، یعنی پیش از آنکه قاتل out of memory (OOM) این موضوع را به‌جای شما تشخیص دهد، متوجه شوید که حافظه تمام شده است.
• پاسخ‌گویی به رخداد، یعنی در ساعتی که خودتان انتخاب نکرده‌اید بیدار و در دسترس باشید.

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

مواردی که مدیریت‌شده معمولاً شامل آن‌ها نمی‌شود

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

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

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

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

نرم‌افزاری که خودتان نصب کرده‌اید متعلق به خودتان است. اگر Docker را نصب کنید، ارائه‌دهنده معمولاً مالک میزبان است و شما مالک همه چیز داخل containerها هستید.

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

هزینه زمان خود را در برابر مابه‌التفاوت ماهانه بسنجید

دو پیشنهاد قیمت پیش روی خود را بررسی کنید و تفاوت ماهانه آن‌ها را یادداشت کنید. این عدد مبلغی است که ارائه‌دهنده برای حذف موارد فهرست بالا دریافت می‌کند. اکنون برای طرف خود در این معامله نیز یک ارزش تعیین کنید.

• یک ساعت از زمان شما چقدر ارزش دارد و پس از خودکارسازی، این فهرست ماهانه چند ساعت زمان می‌گیرد؟
• یک ساعت از کارافتادگی سرویس یا برنامه‌ای که روی این سرور اجرا می‌شود، چقدر هزینه دارد؟

یک سرور Ubuntu در وضعیت پایدار، با به‌روزرسانی خودکار و پایش خارجی، به توجه معمول بسیار کمی نیاز دارد. در بیشتر ماه‌ها به هیچ توجهی نیاز ندارد. پس از آن‌که یک script مسئول اجرای کارهای معمول شود، این کارها هزینه کمی دارند. وقفه‌ها بخش پرهزینه هستند و طرح مدیریت‌شده برای رسیدگی به همین وقفه‌ها ارائه می‌شود. اگر سرور یک پروژه شخصی را اجرا می‌کند، قطعی هیچ هزینه‌ای ندارد و انتخاب unmanaged بدیهی است. اگر سرور سفارش‌ها را پردازش می‌کند، با دقت بررسی کنید که آیا قرارداد پشتیبانی واقعاً قطعی را کوتاه‌تر می‌کند یا نه؛ زیرا یک ارائه‌دهنده managed همچنان باید ticket شما را بخواند، خطا را بازتولید کند و برای رفع آن اقدام کند.

این مابه‌التفاوت با تعداد سرورها نیز افزایش می‌یابد. هزینه‌های managed معمولاً به‌ازای هر سرور دریافت می‌شوند، در حالی که automation یک بار نوشته و سپس کپی می‌شود. سرور دوم هزینه مؤثر script نوشته‌شده برای سرور اول را نصف می‌کند؛ بنابراین پیش از متعهد شدن به هزینه‌ای به‌ازای هر سرور، نحوه مدیریت چند سرور Linux را مطالعه کنید. برای اعداد پایه در هر دو سوی مقایسه، هزینه واقعی ماهانه یک VPS حداقل هزینه را مشخص می‌کند و مقایسه VPS با سرور اختصاصی زمانی اهمیت پیدا می‌کند که workload آن‌قدر بزرگ باشد که هزینه اضافی managed در گرد کردن اعداد ناچیز به نظر برسد.

پرسش‌هایی که باید پیش از پرداخت هزینه مدیریت ممتاز از میزبان بپرسید

پیش از پرداخت، پرسش‌ها را مطرح کنید و پاسخ‌ها را به‌صورت کتبی بخواهید. صفحه فروش، سند محدوده خدمات نیست.

1. محدوده خدمات، وظیفه‌به‌وظیفه، چیست؟ فهرست را بخواهید، نه بروشور را.
2. آیا پشتیبانی شامل نرم‌افزارهایی می‌شود که من نصب می‌کنم، یا فقط نرم‌افزارهایی که شما نصب کرده‌اید؟
3. آیا وصله‌ها را به‌صورت خودکار نصب می‌کنید؟ آیا برای به‌روزرسانی‌های kernel بدون دریافت تأیید قبلی از من، سرور را reboot می‌کنید؟
4. اگر وصله‌ای که نصب کرده‌اید برنامه من را از کار بیندازد، مسئولیت با چه کسی است؟
5. آیا backup تهیه می‌کنید؟ این backupها کجا ذخیره می‌شوند، چه مدت نگهداری می‌شوند و چه کسی restore را انجام می‌دهد؟
6. آیا اخیراً server یکی از مشتریان را restore کرده‌اید؟ این کار چقدر طول کشیده است؟
7. زمان پاسخ‌گویی به ticket چقدر است؟ آیا این زمان در ساعت 03:00 روز یکشنبه متفاوت است؟
8. آیا دسترسی root را حفظ می‌کنم؟ آیا استفاده از آن، دامنه پشتیبانی شما را کاهش می‌دهد؟
9. هزینه به‌ازای هر server دریافت می‌شود یا هر account؟
10. اگر همکاری را پایان دهم، چه چیزهایی را با خودم می‌برم؟ انتقال setupای که داخل یک control panel اختصاصی قرار دارد، ممکن است دشوار باشد.

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

مسیر میانی: مدیریت‌نشده به‌همراه خودکارسازی

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

به‌روزرسانی‌های امنیتی خودکار

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

این فایل اکنون باید شامل APT::Periodic::Update-Package-Lists "1"; و APT::Periodic::Unattended-Upgrade "1"; باشد. نبودن فایل، یا وجود 0 در هر یک از دو خط، به این معناست که هیچ کاری اجرا نمی‌شود و شما نیز مطلع نخواهید شد.

بدون ایجاد تغییر در سیستم، آن را آزمایش کنید. توجه کنید که بسته unattended-upgrades است، درحالی‌که فرمان مفرد است:

sudo unattended-upgrade --dry-run --debug

خروجی همه بسته‌هایی را که بررسی کرده است فهرست می‌کند و وقتی کاری در انتظار نباشد، با خطی مانند No packages found that can be upgraded unattended پایان می‌یابد. اجراهای واقعی در /var/log/unattended-upgrades/unattended-upgrades.log ثبت می‌شوند؛ بنابراین به‌جای حدس‌زدن، آنجا را بررسی کنید.

به‌روزرسانی kernel تا زمانی که ماشین reboot نشود اثری ندارد، زیرا kernel در حال اجرا همان kernelی است که هنگام boot بارگذاری شده است. فایل /var/run/reboot-required زمانی ظاهر می‌شود که reboot در انتظار باشد. یا این فایل را پایش کنید، یا اجازه دهید ماشین آن را در /etc/apt/apt.conf.d/50unattended-upgrades مدیریت کند:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot-WithUsers "false" زمانی که کاربری وارد سیستم است، reboot را به تعویق می‌اندازد. این رفتار روی سیستمی که به‌صورت تعاملی از آن استفاده می‌کنید ایمن‌تر است و روی سیستمی که هیچ‌کس به آن وارد نمی‌شود، کاربردی ندارد. تنظیم کامل unattended upgrades در Ubuntu نحو blocklist و گزینه‌های ایمیل را پوشش می‌دهد.

پایشی که در جای دیگری اجرا می‌شود

مانیتوری که روی خود server اجرا می‌شود نمی‌تواند از کار افتادن server را به شما اطلاع دهد، زیرا خودش نیز از کار افتاده است. بررسی را روی یک میزبان دوم یا یک سرویس خارجی قرار دهید. Uptime Kuma برای پایش وضعیت پاسخ معمول برای self-hosting است و باید روی ماشینی متفاوت از سیستمی که پایش می‌کند قرار داشته باشد.

حداقل چهار مورد را پایش کنید: دسترس‌پذیری، میزان استفاده از disk، پاسخ‌گویی application روی port واقعی آن، و زمان انقضای certificate. مورد disk بیش از همه مشکل‌ساز می‌شود. یک فایل log یا database که هر روز کمی بزرگ‌تر می‌شود، ممکن است در زمانی سیستم را از کار بیندازد که هیچ نشانه دیگری آن را پیش‌بینی نکرده است. نخستین نشانه نیز اغلب سرویسی است که نمی‌تواند بنویسد و خارج می‌شود.

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

یک heartbeat نیز اضافه کنید. یک timer روی server پس از هر backup موفق یا بررسی سلامت، یک URL را فراخوانی می‌کند و monitor زمانی هشدار می‌دهد که این فراخوانی دیگر دریافت نشود. در این حالت، یک server خاموش به‌تنهایی هشدار ایجاد می‌کند؛ کاری که یک بررسی صرفاً pull-based هنگام خراب شدن مسیر شبکه نمی‌تواند انجام دهد.

backupهایی که دست‌کم یک‌بار restore کرده‌اید

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init یک‌بار created restic repository <id> at sftp:... را چاپ می‌کند. اجرای آن روی repositoryای که از قبل وجود دارد، به‌جای overwrite کردن با خطا متوقف می‌شود؛ این همان رفتاری است که می‌خواهید. یک نسخه از آن passphrase را خارج از server نگه دارید: repository بدون آن قابل خواندن نیست و هیچ مسیر بازیابی‌ای وجود ندارد.

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots باید اجرای تازه‌ای را که با تاریخ امروز انجام داده‌اید فهرست کند. restic check ساختار repository را بررسی می‌کند و no errors were found را چاپ می‌کند. اکنون بخش مهمی را انجام دهید که بیشتر افراد از آن صرف‌نظر می‌کنند:

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

فایلی که انتظارش را داشتید یا وجود دارد یا ندارد، و فهمیدن این موضوع اکنون فقط ده دقیقه زمان می‌برد. سپس اجرای کار را روی یک timer قرار دهید تا به شما وابسته نباشد. /etc/systemd/system/restic-backup.service را بنویسید:

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

و /etc/systemd/system/restic-backup.timer را:

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers اجرای بعدی و زمان باقی‌مانده را نشان می‌دهد. نتیجه خالی به این معناست که service را به‌جای timer فعال کرده‌اید؛ این رایج‌ترین اشتباه در این مرحله است. Persistent=true یک job ازدست‌رفته را پس از boot بعدی اجرا می‌کند؛ بنابراین ماشینی که شب خاموش بوده است، همچنان backup خود را دریافت می‌کند. backupهای Restic روی یک VPS درباره چیدمان repository و نگهداری نسخه‌ها توضیح بیشتری می‌دهد و serviceها و timerهای systemd فایل‌های unit را خط‌به‌خط توضیح می‌دهد.

خودکارسازی چه چیزی برای شما فراهم نمی‌کند

خودکارسازی قضاوت را فراهم نمی‌کند. یک reboot خودکار در ساعت 02:00 چه application شما به‌درستی بالا بیاید و چه نیاید، انجام می‌شود. بنابراین اطمینان حاصل کنید که هر service به‌طور خودکار شروع می‌شود، سپس زمانی که بیدار هستید عمداً reboot را انجام دهید:

systemctl is-enabled nginx docker
sudo reboot

یک unattended upgrade ممکن است packageای را نیز نصب کند که application شما را از کار بیندازد، و هیچ بخشی از این pipeline از وقوع آن مطلع نمی‌شود. این monitor شماست که آن را شناسایی می‌کند؛ به همین دلیل، پس از خودکار شدن updateها، monitor دیگر اختیاری نیست. ماشین کارهای معمول را پوشش می‌دهد. رسیدگی به incident همچنان بر عهده شماست.

زمانی که سرویس مدیریت‌شده ارزش هزینه را دارد

باید درباره گزینه مدیریت‌شده منصف بود. 4 وضعیت وجود دارد که در آن خرید این گزینه تصمیم درستی است.

• هیچ‌کس در تیم Linux را مدیریت نمی‌کند و برنامه‌ای برای استخدام فرد دیگری وجود ندارد.
• یک الزام انطباق، طرفی را مسئول اعمال patchها تعیین کرده است و آن طرف نمی‌تواند شما باشید.
• پشته نرم‌افزاری از مواردی است که میزبان در آن تخصص دارد؛ بنابراین تیم پشتیبانی آن‌ها قبلاً با خطای شما مواجه شده است.
• فردی که در غیر این صورت این کار را انجام می‌دهد، گران‌ترین کارمند شماست و هزینه 1 ساعت از وقت او از هزینه 1 ماه سرویس ممتاز بیشتر است.

سرویس مدیریت‌شده به‌طور خودکار امن‌تر نیست. طرح‌های مدیریت‌شده نسبت به مالکی که به‌درستی نظارت نمی‌کند، patchها را سریع‌تر نصب می‌کنند و این یک مزیت واقعی است. این سرویس‌ها همچنین اغلب یک control panel نصب می‌کنند؛ control panel یک برنامه بزرگِ در معرض شبکه است که صفحه ورود و سابقه آسیب‌پذیری مختص خود را دارد. این موضوع می‌تواند مصالحه‌ای منطقی باشد، اما همچنان یک مصالحه است.

تصمیم‌گیری هر بار به همان فهرست بستگی دارد. 10 کار را یادداشت کنید، زیر هر پیشنهاد مشخص کنید مسئولیت هر کار با چه کسی است، سپس این فاصله را با ارزش 1 ساعت از توجه خود مقایسه کنید. بیشتر خوانندگان فنی که این کار را انجام می‌دهند، در نهایت گزینه unmanaged را انتخاب می‌کنند و کارهای معمول را به یک timer می‌سپارند. این پاسخ قابل دفاع است، نه صرفاً پاسخی ارزان.

FAQ

تفاوت VPS مدیریت‌شده و مدیریت‌نشده چیست؟

VPS مدیریت‌نشده فقط ماشین را در اختیار شما می‌گذارد و مسئولیت patch کردن، تنظیم firewall، تهیه backup، monitor کردن و reboot پس از به‌روزرسانی kernel با شماست. در VPS مدیریت‌شده، بخشی از این کارها به provider واگذار می‌شود؛ معمولاً لایه سیستم‌عامل و نرم‌افزارهایی که provider برای شما نصب کرده است. محدوده دقیق مسئولیت را هر provider تعیین می‌کند، نه خود این اصطلاح. بنابراین، پیش از مقایسه دو قیمت، محدوده مسئولیت را برای هر کار به‌صورت مکتوب درخواست کنید.

آیا VPS مدیریت‌شده یعنی دیگر به backupهای خودم نیاز ندارم؟

خیر. backupهای provider معمولاً از image کامل server نزد provider محافظت می‌کنند و برای زمانی هستند که host از کار می‌افتد. این backupها معمولاً زمانی کمکی نمی‌کنند که فایلی را حذف کرده باشید، migration نادرستی اجرا کرده باشید یا داده‌ای را هفته‌ها پیش خراب کرده باشید و امروز متوجه آن شوید. بپرسید snapshotها چه مدت نگهداری می‌شوند، آیا امکان restore یک فایل وجود دارد و چه کسی restore را انجام می‌دهد. سپس با ابزاری مانند restic یک نسخه offsite متعلق به خودتان نگه دارید و آن را با restic restore latest --target /tmp/restore-check آزمایش کنید تا مطمئن شوید کار می‌کند.

آیا VPS مدیریت‌شده از VPS مدیریت‌نشده امن‌تر است؟

خودبه‌خود نه. یک plan مدیریت‌شده سریع‌تر از مالکی که هرگز login نمی‌کند patch می‌شود و این موضوع واقعاً ریسک را کاهش می‌دهد. بسیاری از planهای مدیریت‌شده همچنین یک control panel نصب می‌کنند. panel یک application بزرگ و در معرض شبکه است که login page و سابقه آسیب‌پذیری‌های خاص خود را دارد. یک box مدیریت‌نشده با automatic security updates، firewall بسته، SSH فقط با key و بدون سرویس اضافی در حال listening، هدف کوچک‌تری از یک box مدیریت‌شده دارای panel است.

آیا می‌توانم کار را با حالت مدیریت‌نشده شروع کنم و بعداً به حالت مدیریت‌شده تغییر دهم؟

معمولاً بله، هرچند این کار به‌ندرت با یک checkbox انجام می‌شود. Providerها معمولاً پیش از پذیرفتن مسئولیت server، آن را audit یا rebuild می‌کنند، زیرا از configurationای که نمی‌توانند ببینند پشتیبانی نمی‌کنند. بپرسید onboarding شامل چه مراحلی است، آیا به reinstall نیاز دارد و آیا تنظیماتی که خودتان انجام داده‌اید بعداً خارج از scope پشتیبانی باقی می‌ماند یا خیر.

آیا در VPS مدیریت‌شده دسترسی root را حفظ می‌کنم؟

در بیشتر planهای VPS مدیریت‌شده بله، اما دسترسی root با scope پشتیبانی ارتباط دارد. برخی providerها برای componentای که دستی ویرایش کرده‌اید، پشتیبانی را کاهش می‌دهند یا لغو می‌کنند. برخی دیگر نیز اگر یک ticket به مرحله عمیقی برسد، server را از template خودشان rebuild می‌کنند. پیش از هرگونه tuning، این قاعده را به‌صورت مکتوب دریافت کنید و فایل‌های configuration خود را در version control نگه دارید تا rebuild به‌جای یک آخرهفته، فقط یک ساعت زمان ببرد.