سرور مجازی مدیریت شده یا مدیریت نشده؟ قبل از خرید چه بپرسیم؟

فرض کنید سایت فروشگاه ساعت یازده شب باز نمی شود. پنل سرور در دسترس است و شرکت میزبان می گوید شبکه مشکلی ندارد. حالا چه کسی باید لاگ وب سرور را بخواند، دیتابیس را بررسی کند و سایت را برگرداند؟ پاسخ همین سوال، تفاوت عملی سرور مجازی مدیریت شده و مدیریت نشده را نشان می دهد. تعداد هسته و مقدار رم مهم است، اما مسئولیت بعد از تحویل سرور هم به همان اندازه اهمیت دارد.

اگر دنبال انتخاب سریع هستید، از اینجا شروع کنید: وقتی مدیر سرور مشخصی ندارید و سرویس برای کسب و کار مهم است، مدیریت باید به شکل روشن خریداری یا تامین شود. اگر تیم فنی دارید که نگهداری، امنیت، بکاپ و واکنش به حادثه را انجام می دهد، سرویس مدیریت نشده می تواند انتخاب مناسبی باشد. واژه «مدیریت شده» به تنهایی کافی نیست؛ دامنه کار باید در قرارداد یا شرح خدمات نوشته شده باشد.

مدیریت شده یعنی چه کاری را به چه کسی می سپارید؟

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

سرور مدیریت شده هم یک استاندارد واحد با فهرست ثابت نیست. ممکن است فقط سیستم عامل و سرویس های مشخصی را پوشش دهد یا بخشی از نگهداری برنامه را هم در بر بگیرد. برای نمونه، مستندات مدیریت سرور هتزنر محدودیت های پشته نرم افزاری و دسترسی root را برای همان محصولات توضیح می دهد. این مثال نشان می دهد اختیار بیشتر و مدیریت بیشتر همیشه همزمان عرضه نمی شوند؛ نباید شرایط یک محصول را به همه VPS ها نسبت داد.

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

جدولی که بهتر است قبل از پرداخت تکمیل شود

جدول زیر را به عنوان فهرست سوال استفاده کنید، نه فهرست تعهد همه شرکت ها. ستون آخر باید برای سفارش شما جواب مکتوب داشته باشد. اگر یک کار به نفر دیگری سپرده می شود، نام تیم و راه تماس اضطراری او را هم مشخص کنید. مسئولیت مبهم، معمولا هنگام خرابی خودش را نشان می دهد.

تفاوت پشتیبانی، مانیتورینگ و رسیدگی به حادثه

داشتن امکان ثبت تیکت به معنی پایش فعال سرویس نیست. تیکت یعنی شما مسئله را گزارش می کنید؛ مانیتورینگ یعنی شاخصی بررسی می شود و برای وضعیت نامناسب هشدار می رسد. رسیدگی به حادثه مرحله دیگری است: یک نفر باید هشدار را ببیند، علت را بررسی کند و در محدوده مجاز اقدام کند. هر سه را جدا بپرسید. عبارت «پشتیبانی شبانه روزی» بدون توضیح نوع درخواست، زمان پاسخ و مسیر تشدید، اطلاعات کافی نمی دهد.

حتی زمان پاسخ اولیه با زمان حل مشکل فرق دارد. دریافت پاسخ «در حال بررسی است» لزوما به معنی بازگشت سایت نیست. بپرسید مشکل حیاتی چگونه تعریف می شود، چه کسی اولویت را تعیین می کند و اگر نفر اول نتوانست حل کند چه اتفاقی می افتد. برای رویدادهای خارج از ساعت اداری، لازم است مسیر تماس و فرد مجاز به تایید تغییر از قبل مشخص باشد.

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

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

در مثال دوم، صاحب یک فروشگاه وردپرسی فقط با پنل مدیریت سایت کار می کند. طراح سایت هم پروژه را تحویل داده و تعهد نگهداری سرور ندارد. خرید ارزان ترین VPS و واگذار کردن مسئولیت به «پشتیبانی» بدون توافق، این خلا را پر نمی کند. این فروشگاه به مسئول مشخص برای سرور نیاز دارد؛ ممکن است بسته مدیریت، قرارداد جداگانه یا سرویس میزبانی مناسب تری انتخاب کند. نام محصول باید بعد از روشن شدن این نیاز انتخاب شود.

بکاپ را با چهار سوال کوتاه روشن کنید

چه داده ای ذخیره می شود؟ نسخه کجا نگهداری می شود؟ تا چه تاریخی قابل برگشت است؟ چه کسی آن را بازیابی و نتیجه را بررسی می کند؟ این چهار جواب از جمله کلی «بکاپ داریم» مفیدتر است. snapshot ماشین، خروجی دیتابیس و نسخه فایل های سایت دامنه یکسانی ندارند. اگر فقط دیسک سیستم عامل پوشش داده می شود، دیتابیس روی فضای جدا ممکن است از قلم افتاده باشد.

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

مدیریت قرار نیست اختیار را بی صدا حذف کند

اگر برنامه شما نسخه خاصی از PHP، ماژول کرنل، Docker یا سرویس سفارشی می خواهد، پیش از سفارش مطرح کنید. ممکن است تیم مدیریت فقط یک پشته مشخص را پشتیبانی کند و تغییر خارج از آن، قرارداد را تحت تاثیر قرار دهد. این محدودیت لزوما بد نیست؛ نگهداری یک محیط تعریف شده ساده تر است. مشکل زمانی ایجاد می شود که بعد از انتقال سایت متوجه ناسازگاری شوید.

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

هزینه واقعی از عدد ماهانه بیشتر است

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

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

پیش از خرید، این پیام را برای فروشنده بفرستید

به جای درخواست «یک VPS خوب»، بنویسید چه برنامه ای دارید، چه کسی کد را نگهداری می کند، چه دسترسی هایی لازم است و در خرابی انتظار چه اقدامی دارید. فهرست نسخه ها، نیاز به دیتابیس، ظرفیت تقریبی فایل ها و پنجره مناسب نگهداری را اضافه کنید. بعد بخواهید مسئول هر ردیف جدول بالا و موارد خارج از پوشش را مکتوب اعلام کنند. اگر پاسخ فقط تکرار مشخصات سخت افزار بود، هنوز بخش مدیریت روشن نشده است.

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

سه سوال رایج پیش از انتخاب

اگر کنترل پنل نصب باشد، سرور مدیریت شده است؟

خیر. پنل ابزار انجام کار است. مسئول نگهداری پنل، سیستم عامل، بکاپ و رسیدگی به خطا باید جدا مشخص شود.

مدیریت شده همیشه برای فروشگاه بهتر است؟

به توان تیم و پوشش قرارداد بستگی دارد. وقتی مسئول فنی مشخص ندارید، باید این مسئولیت را تامین کنید؛ صرف برچسب مدیریت شده کافی نیست.

آیا می توان بعدا از مدیریت نشده به مدیریت شده رفت؟

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