Managed বনাম unmanaged VPS: কোনটি আপনার দরকার?

Managed বনাম unmanaged VPS: সংক্ষিপ্ত উত্তর

Managed এবং unmanaged VPS-এর মধ্যে বেছে নেওয়া মূলত কাজের দায়িত্বের প্রশ্ন, পণ্যের প্রশ্ন নয়। Unmanaged হলে patching, firewall, backup, monitoring এবং রাত 2টায় reboot করার দায়িত্ব আপনার। Managed হলে provider এসব কাজের কিছু অংশ আপনার হয়ে করে। তবে সেই অংশের পরিমাণ host ভেদে অনেক পরিবর্তিত হয়। কোন plan আপনার কাছ থেকে কোন কাজগুলো সরিয়ে নিচ্ছে, এবং আপনার নিজের সময়ের মূল্যের তুলনায় সেই plan-এর খরচ কত—এটাই একমাত্র কার্যকর তুলনা।

managed শব্দটির কোনো standard definition নেই। কোনো host-এ operating system patch করা হয় এবং একজন human ticket-এর উত্তর দেন। অন্য host-এ শুধু একটি control panel install করা থাকে; এর ওপরের সব দায়িত্ব আপনার। তৃতীয় ক্ষেত্রে নির্দিষ্ট response time-সহ একটি লিখিত service contract থাকতে পারে। একই শব্দযুক্ত দুটি plan গুরুত্বপূর্ণ প্রতিটি দিকেই ভিন্ন হতে পারে। তাই price দেখার আগে scope document পড়ুন। মেশিনটি আসলে কী কাজে ব্যবহার করবেন, সেটিই যদি এখনও নির্ধারণ না করে থাকেন, তাহলে VPS দিয়ে আপনি আসলে কী করতে পারেন—এই প্রশ্নের উত্তর আগে ঠিক করা বেশি গুরুত্বপূর্ণ।

যে কাজগুলোর দায়িত্ব কাউকে নিতে হবে

প্রতিটি চলমান সার্ভারে একই ধরনের কাজের তালিকা থাকে। unmanaged plan-এ সেই তালিকার দায়িত্ব আপনার। managed plan-এ আপনি অর্থ দিচ্ছেন, যাতে তালিকা থেকে কিছু কাজ বাদ দেওয়া হয়। তালিকাটি ধরে এগিয়ে প্রতিটি কাজের পাশে একজনের নাম লিখুন।

• Operating system patching এবং kernel update-এর জন্য প্রয়োজনীয় reboot।
• Firewall rule সঠিক রাখা, বিশেষ করে service যোগ ও সরানোর সময়। VPS-এর ufw firewall-এর প্রাথমিক বিষয়গুলো-তে শুরুর ruleset ব্যাখ্যা করা হয়েছে।
• SSH access: key পরিচালনা, password login বন্ধ রাখা, কেউ দল ছাড়লে তার key বাতিল করা, এবং নিজে access থেকে locked out হলে পুনরায় প্রবেশের ব্যবস্থা রাখা।
• Backup, offsite copy এবং অন্তত একবার বাস্তবে restore সম্পন্ন করা।
• Monitoring। এর অর্থ হলো box-এ পৌঁছানো যাচ্ছে কি না, disk-এ পর্যাপ্ত জায়গা আছে কি না, service এখনও চলছে কি না এবং certificate-এর মেয়াদ শেষ হয়েছে কি না জানা।
• Log review এবং সেই log-এ কিছু অস্বাভাবিক দেখালে প্রয়োজনীয় ব্যবস্থা নেওয়া।
• Web server, database, reverse proxy এবং queue ব্যবহার করলে সেটির service configuration।
• Certificate renewal এবং automatic renewal কাজ করা বন্ধ হলে তা মেরামত করা।
• Capacity। এর অর্থ হলো out of memory (OOM) killer আপনার হয়ে তা শনাক্ত করার আগেই memory শেষ হয়ে আসছে কি না বুঝতে পারা।
• Incident response। এর অর্থ হলো আপনার পছন্দের নয় এমন সময়েও জেগে থাকা এবং যোগাযোগযোগ্য থাকা।

এগুলোর অধিকাংশই নিয়মিত কাজ এবং script-এর মাধ্যমে করা যায়। Incident response এমন একটি কাজ, যা script দিয়ে করা যায় না, কারণ এর জন্য সিদ্ধান্ত নিতে পারে এমন একজন মানুষ প্রয়োজন। managed plan-এর প্রকৃত service এটিই। তাই নিচের checklist-এ patching-এর চেয়ে support scope নিয়ে বেশি প্রশ্ন রাখা হয়েছে।

সাধারণত managed সেবায় যা অন্তর্ভুক্ত থাকে না

এখানেই ক্রেতারা প্রায়ই সমস্যায় পড়েন। তাই বিষয়টি স্পষ্টভাবে বুঝে নিন। managed contract সাধারণত operating system এবং provider যে software ইনস্টল করেছে, সেগুলোকে কভার করে। আপনার application-এর সীমারেখায় এসে এই দায়িত্ব শেষ হয়।

আপনার নিজস্ব code-এর দায়িত্ব আপনার। আপনার application থেকে আসা 500 error server fault নয়। provider নিশ্চিত করবে যে web server process চলছে, তারপর ticket-টি আপনার কাছে ফেরত পাঠাবে। এটি একটি যুক্তিসঙ্গত সীমারেখা। ক্রেতারা যা প্রত্যাশা করেন এবং বাস্তবে যা কিনেছেন, তার মধ্যে এটিই সবচেয়ে বড় ব্যবধান।

Application-level সমস্যা সাধারণত scope-এর বাইরে থাকে। ধীর database query, update-এর পরে নষ্ট হয়ে যাওয়া plugin, ভুলভাবে configured cache, অথবা draining বন্ধ হয়ে যাওয়া mail queue—provider এগুলোর নিচের software ইনস্টল করলেও এসব সমস্যা scope-এর বাইরে থাকে।

বেশিরভাগ data recovery scope-এর বাইরে থাকে। provider-এর backup পুরো server সম্পর্কে provider-এর সংরক্ষিত image রক্ষা করে এবং host hardware নষ্ট হলে ব্যবহারের জন্য তৈরি থাকে। আপনি কোনো row মুছে ফেললে, ভুল migration চালালে, অথবা ছয় সপ্তাহ আগে কোনো file নষ্ট করে আজ তা বুঝতে পারলে—এ ধরনের পরিস্থিতির জন্য এগুলো সাধারণত তৈরি থাকে না। retention window কত, একটি single file আলাদাভাবে উদ্ধার করা যায় কি না, এবং restore কে চালায়—এসব জিজ্ঞাসা করুন।

আপনার ইনস্টল করা software-এর দায়িত্ব আপনার। Docker ইনস্টল করলে provider সাধারণত host-এর দায়িত্বে থাকে, আর container-এর ভেতরের সবকিছুর দায়িত্ব আপনার।

নিজে হাতে করা edit support বাতিল করতে পারে। কিছু contract অনুযায়ী customer সরাসরি কোনো component-এর configuration edit করলে সেটি scope-এর বাইরে চলে যায়। আপনি কোনো কিছু tune করার পরিকল্পনা করলে এ বিষয়ে জিজ্ঞাসা করুন।

নিজের সময়ের মূল্য মাসিক পার্থক্যের সঙ্গে তুলনা করুন

আপনার সামনে থাকা দুটি quotation নিন এবং মাসিক পার্থক্য লিখে রাখুন। এই সংখ্যাটিই হলো provider-এর সেই কাজগুলোর জন্য নেওয়া খরচ, যেগুলো উপরের তালিকা থেকে বাদ দেয়। এখন এই বিনিময়ে আপনার পক্ষের মূল্য নির্ধারণ করুন।

• আপনার এক ঘণ্টা সময়ের মূল্য কত, এবং automation-এর পরে ওই তালিকায় মাসে কত ঘণ্টা লাগে?
• এই সার্ভারে চলা কাজটি এক ঘণ্টা downtime-এ কত খরচ করে?

Automatic updates এবং external monitoring-সহ স্থিতিশীল Ubuntu box-এর নিয়মিত রক্ষণাবেক্ষণে খুব কম সময় লাগে। অধিকাংশ মাসে কোনো সময়ই লাগে না। কোনো script কাজটি পরিচালনা করলে routine work-এর খরচ কমে যায়। ব্যয়বহুল বিষয় হলো interrupt, আর managed plan মূলত এই interrupt সামলানোর সুবিধাই বিক্রি করে। সার্ভারে যদি hobby project চলে, outage-এর কোনো আর্থিক ক্ষতি নেই এবং unmanaged ব্যবস্থাই স্পষ্ট পছন্দ। কিন্তু সার্ভারে যদি orders নেওয়া হয়, support contract বাস্তবে outage কমায় কি না তা ভালোভাবে যাচাই করুন। কারণ managed provider-কেও আপনার ticket পড়তে, fault পুনরায় তৈরি করতে এবং ব্যবস্থা নিতে হয়।

Server-এর সংখ্যা বাড়লে এই পার্থক্যও বাড়ে। Managed fee সাধারণত প্রতি server হিসেবে নেওয়া হয়, কিন্তু automation একবার লিখে কপি করা যায়। দ্বিতীয় server যোগ হলে প্রথম server-এর জন্য লেখা script-এর কার্যকর খরচ অর্ধেক হয়ে যায়। তাই প্রতি server-এর fee-তে সম্মত হওয়ার আগে একাধিক Linux server কীভাবে পরিচালনা করবেন দেখুন। তুলনার উভয় দিকের মূল সংখ্যার জন্য একটি VPS-এর প্রকৃত মাসিক খরচ কত ন্যূনতম ব্যয় নির্ধারণ করে। Workload যথেষ্ট বড় হলে, যখন managed premium মোট খরচের তুলনায় প্রায় উপেক্ষণীয় হয়ে যায়, তখন VPS বনাম dedicated server-এর বিনিময় গুরুত্বপূর্ণ হয়ে ওঠে।

Managed premium নেওয়ার আগে host-কে যে প্রশ্নগুলো করবেন

অর্থ পরিশোধের আগে প্রশ্ন করুন এবং উত্তরগুলো লিখিতভাবে নিন। Sales page কোনো scope document নয়।

1. কোন কোন কাজ scope-এর মধ্যে আছে? Brochure নয়, কাজভিত্তিক তালিকা চাইুন।
2. Support কি আপনার ইনস্টল করা software-এর ক্ষেত্রেও প্রযোজ্য, নাকি শুধু host-এর ইনস্টল করা software-এর জন্য?
3. তারা কি স্বয়ংক্রিয়ভাবে patch install করে? Kernel update-এর জন্য কি আপনার অনুমতি ছাড়াই reboot করে?
4. তাদের প্রয়োগ করা কোনো patch আপনার application নষ্ট করলে দায়িত্ব কার?
5. তারা কি backup নেয়? Backup কোথায় সংরক্ষিত হয়, কত দিন রাখা হয়, এবং restore কে করে?
6. তারা কি সম্প্রতি কোনো customer server restore করেছে? Restore করতে কত সময় লেগেছে?
7. Ticket-এর response time কত? রবিবার 03:00-এ কি এই সময় আলাদা?
8. আপনি কি root access behalten রাখবেন? root access ব্যবহার করলে তারা যে support দেবে, তার পরিধি কি কমে যাবে?
9. Fee কি প্রতি server অনুযায়ী, নাকি প্রতি account অনুযায়ী নেওয়া হয়?
10. আপনি service ছেড়ে গেলে কী কী সঙ্গে নিতে পারবেন? Proprietary control panel-এর ভেতরে থাকা setup export করা কঠিন হতে পারে।

Question 5 অন্য অধিকাংশ প্রশ্নের উত্তর নির্ধারণ করে। কোনো host এই প্রশ্নের সুনির্দিষ্ট উত্তর দিলে বোঝা যায়, তারা আগে কাজটি করেছে। অস্পষ্ট উত্তর মানে restore কখনও পরীক্ষা করা হয়নি, আর পরীক্ষা না করা backup শুধু একটি copy। Question 5-এর একটি location-সংক্রান্ত দিকও আছে: copy-গুলো শারীরিকভাবে কোথায় রাখা হয়, তা technical প্রশ্নের পাশাপাশি legal প্রশ্নও, এবং hosting country বাছাইয়ের সময় আসলে কোন বিষয় গুরুত্বপূর্ণ সেটি বিস্তারিত ব্যাখ্যা করে।

মধ্যপন্থা: unmanaged পরিকল্পনা এবং automation

বেশিরভাগ technical reader কোনো চরম অবস্থাই চান না। তারা এমন একটি unmanaged পরিকল্পনা চান, যেখানে নিয়মিত কাজগুলো machine করবে এবং machine যে বিষয়গুলোর বিচার করতে পারে না, সেগুলোর জন্য তাদের মনোযোগ সংরক্ষিত থাকবে। প্রথম দিনেই এটি সেট up করুন। unmanaged বেছে নেওয়া যেকোনো ব্যক্তির জন্য নতুন VPS-এ প্রথম দশ মিনিট হলো ব্যবহারিক শুরু, এবং একই প্রথম session-এ SSH access hardening করাও উচিত।

Automatic security updates

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

এখন ওই file-এ APT::Periodic::Update-Package-Lists "1"; এবং APT::Periodic::Unattended-Upgrade "1"; থাকা উচিত। file না থাকা, অথবা যেকোনো line-এ 0 থাকা, বোঝায় যে কিছুই চলবে না এবং আপনাকে জানানো হবে না।

system পরিবর্তন না করে এটি test করুন। মনে রাখবেন, package-টি unattended-upgrades হলেও command-টি singular:

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

output-এ বিবেচনা করা প্রতিটি package তালিকাভুক্ত হয়। কোনো pending update না থাকলে শেষে No packages found that can be upgraded unattended-এর মতো একটি line দেখা যায়। বাস্তবে চলা কাজের log /var/log/unattended-upgrades/unattended-upgrades.log-এ লেখা হয়। তাই অনুমান না করে সেখানে পরীক্ষা করুন।

kernel update কার্যকর হয় না machine reboot করা পর্যন্ত, কারণ boot-এর সময় load হওয়া kernel-ই চলমান kernel। reboot pending হলে /var/run/reboot-required file দেখা যায়। ওই file-এর উপস্থিতি monitor করুন, অথবা machine-কে /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";

কেউ logged in থাকলে Automatic-Reboot-WithUsers "false" reboot আটকে রাখে। আপনি interactive ভাবে ব্যবহার করেন এমন machine-এ এটি নিরাপদ। কেউ login করে না এমন machine-এ এটি অপ্রয়োজনীয়। Ubuntu-তে সম্পূর্ণ unattended upgrades setup-এ blocklist syntax এবং email options বিস্তারিতভাবে ব্যাখ্যা করা হয়েছে।

অন্য কোথাও চলা Monitoring

server-এ চলা monitor server down হয়েছে কি না জানাতে পারে না, কারণ monitor-ও তখন down। check-টি দ্বিতীয় host-এ বা external service-এ রাখুন। Status monitoring-এর জন্য Uptime Kuma হলো প্রচলিত self-hosted সমাধান। এটি যে machine monitor করে, তার থেকে আলাদা machine-এ থাকা উচিত।

অন্তত চারটি বিষয় monitor করুন: reachability, disk usage, application তার প্রকৃত port-এ উত্তর দিচ্ছে কি না, এবং certificate expiry। disk-ই সবচেয়ে বেশি সমস্যা তৈরি করে। প্রতিদিন অল্প অল্প করে বাড়তে থাকা log file বা database এমন সময় machine অচল করে দিতে পারে, যা অন্য কোনো লক্ষণ আগে থেকে জানায় না। প্রথম লক্ষণ প্রায়ই হয় এমন একটি service, যা লিখতে না পেরে বন্ধ হয়ে যায়।

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

এছাড়া একটি heartbeat যোগ করুন। প্রতিটি সফল backup বা health check-এর পরে server-এর একটি timer একটি URL call করবে। ওই call আসা বন্ধ হলে monitor alert দেবে। network path-ই যখন সমস্যার কারণ, তখন pull-only check তা শনাক্ত করতে পারে না। কিন্তু নীরব server নিজেই heartbeat alert তৈরি করতে পারে।

অন্তত একবার restore করা Backups

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:... print করে। আগে থেকেই থাকা repository-তে এটি চালালে overwrite না করে fail করে। আপনি যে আচরণটি চান, সেটিই এটি। passphrase-এর একটি copy server-এর বাইরে রাখুন। এটি ছাড়া repository পড়া যায় না এবং recovery-এর কোনো পথ নেই।

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-এ আজকের date-সহ সদ্য করা run-টি তালিকাভুক্ত হওয়া উচিত। restic check repository structure যাচাই করে এবং no errors were found print করে। এখন সেই কাজটি করুন, যা অধিকাংশ মানুষ এড়িয়ে যায়:

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

আপনি যে file আশা করেছিলেন, সেটি আছে অথবা নেই। এখন জানতে মাত্র দশ মিনিট লাগবে। এরপর run-টি একটি 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 পরবর্তী run এবং বাকি সময় দেখায়। ফলাফল খালি হলে বুঝবেন, আপনি timer-এর বদলে service enable করেছেন। এখানে এটিই সবচেয়ে সাধারণ ভুল। Persistent=true পরবর্তী boot-এর পরে missed job চালায়। তাই machine সারা রাত বন্ধ থাকলেও backup নেওয়া হবে। VPS-এ Restic backups repository layout এবং retention নিয়ে আরও বিস্তারিত আলোচনা করে, আর systemd services এবং timers unit file-গুলো line by line ব্যাখ্যা করে।

Automation যা দেয় না

এটি বিচারবোধ দেয় না। 02:00-এ automatic reboot হবে, application ঠিকভাবে ফিরে আসুক বা না আসুক। তাই প্রতিটি service নিজে থেকে start হয় কি না নিশ্চিত করুন। এরপর আপনি জেগে থাকা অবস্থায় ইচ্ছাকৃতভাবে reboot করুন:

systemctl is-enabled nginx docker
sudo reboot

unattended upgrade এমন package-ও install করতে পারে, যা application নষ্ট করে। pipeline-এর কোনো অংশই বুঝতে পারে না যে এটি ঘটেছে। আপনার monitor-ই এটি শনাক্ত করে। তাই updates automatic হলে monitor ঐচ্ছিক নয়। নিয়মিত কাজ machine সামলাবে। incident-এর দায়িত্ব এখনও আপনার।

Managed সেবা কখন খরচসাপেক্ষ হলেও যুক্তিযুক্ত

Managed সেবার দিকটিও ন্যায্যভাবে বিবেচনা করুন। 4টি পরিস্থিতিতে এটি সঠিক পছন্দ হতে পারে।

• দলের কেউ Linux পরিচালনা করেন না, এবং কাউকে নিয়োগ করার পরিকল্পনাও নেই।
• কোনো compliance requirement-এ patching-এর জন্য দায়ী পক্ষ নির্দিষ্ট করা আছে, এবং সেই দায়িত্ব আপনার হতে পারে না।
• stack-টি provider-এর বিশেষায়িত, তাই তাদের support team আপনার সমস্যার মতো failure আগেও দেখেছে।
• অন্যথায় যে কর্মী এই কাজ করতেন, তিনি আপনার সবচেয়ে ব্যয়বহুল কর্মী; তার 1 ঘণ্টার খরচ premium plan-এর 1 মাসের খরচের চেয়ে বেশি।

Managed সেবা স্বয়ংক্রিয়ভাবে বেশি নিরাপদ নয়। অমনোযোগী owner-এর তুলনায় managed plan-এ সাধারণত দ্রুত patch প্রয়োগ করা হয়, এবং এটি একটি বাস্তব সুবিধা। এগুলো প্রায়ই একটি control panel-ও install করে। এটি login page-সহ network-facing একটি বড় application, যার নিজস্ব vulnerability history রয়েছে। এই বিনিময়টি যুক্তিসঙ্গত হতে পারে, তবে এটি তবুও একটি বিনিময়।

সিদ্ধান্তটি প্রতিবার একই তালিকার ওপর নির্ভর করে। 10টি কাজ লিখে নিন। প্রতিটি quote-এর অধীনে প্রতিটি কাজের দায়িত্ব কার, তা চিহ্নিত করুন। এরপর আপনার 1 ঘণ্টার মনোযোগের মূল্য দিয়ে এই ব্যবধানের তুলনা করুন। অধিকাংশ technical reader এই হিসাব করলে শেষ পর্যন্ত unmanaged hosting বেছে নেন এবং routine কাজ timer-এর মাধ্যমে চালান। এটি কম খরচের সিদ্ধান্ত নয়; বরং যুক্তিসঙ্গতভাবে সমর্থন করা যায় এমন সিদ্ধান্ত।

FAQ

managed এবং unmanaged VPS-এর মধ্যে পার্থক্য কী?

unmanaged VPS-এ আপনি শুধু মেশিনটি পান, অন্য কিছু নয়। তাই patching, firewall, backup, monitoring এবং kernel update-এর পরে reboot করার দায়িত্ব আপনার। managed VPS-এ এই কাজের একটি অংশ provider-এর ওপর চলে যায়। সাধারণত operating system layer এবং তারা আপনার জন্য install করা software এই ব্যবস্থার আওতায় থাকে। সঠিক সীমা প্রতিটি provider নিজে নির্ধারণ করে; শুধু নামের ওপর নির্ভর করে না। তাই দুটি মূল্য তুলনা করার আগে কোন কাজের দায়িত্ব কার, তা লিখিতভাবে জেনে নিন।

managed VPS থাকলে কি আমার নিজস্ব backup-এর প্রয়োজন নেই?

না। Provider-এর backup সাধারণত পুরো server-এর provider-managed image সুরক্ষিত রাখে এবং host ব্যর্থ হলে ব্যবহারের জন্য থাকে। আপনি কোনো file মুছে ফেললে, ভুল migration চালালে, অথবা কয়েক সপ্তাহ আগে data নষ্ট হয়ে আজ তা বুঝতে পারলে এই backup খুব কমই কাজে আসে। snapshot কত দিন রাখা হয়, একটি নির্দিষ্ট file restore করা যায় কি না এবং restore কে সম্পন্ন করে, তা জেনে নিন। এরপর restic-এর মতো tool ব্যবহার করে নিজস্ব offsite copy রাখুন এবং restic restore latest --target /tmp/restore-check দিয়ে তা পরীক্ষা করুন, যাতে নিশ্চিত হন যে এটি কাজ করছে।

unmanaged VPS-এর চেয়ে managed VPS কি বেশি নিরাপদ?

নিজে থেকে নয়। যে owner কখনো লগ ইন করেন না, তার তুলনায় managed plan দ্রুত patch প্রয়োগ করে। এতে সত্যিই ঝুঁকি কমে। অনেক managed plan-এ control panel-ও install করা থাকে। Panel হলো network-facing একটি বড় application, যার নিজস্ব login page এবং vulnerability-এর নিজস্ব ইতিহাস রয়েছে। automatic security update চালু, firewall বন্ধ অবস্থায়, শুধু key-ভিত্তিক SSH ব্যবহৃত এবং অতিরিক্ত কিছু listening না থাকা একটি unmanaged box, panel চালানো managed box-এর তুলনায় ছোট target।

আমি কি প্রথমে unmanaged নিয়ে পরে managed-এ পরিবর্তন করতে পারি?

সাধারণত পারেন। তবে এটি খুব কম ক্ষেত্রেই শুধু একটি checkbox নির্বাচন করার মতো বিষয়। Provider-রা দায়িত্ব নেওয়ার আগে সাধারণত server audit করে বা rebuild করে। কারণ তারা এমন configuration support করবে না, যা তারা দেখতে বা যাচাই করতে পারে না। onboarding-এ কী কী অন্তর্ভুক্ত, reinstall প্রয়োজন কি না এবং পরে আপনার নিজের করা configuration-এর কোনো অংশ support scope-এর বাইরে থাকবে কি না, তা জেনে নিন।

managed VPS-এ কি root access থাকে?

বেশিরভাগ managed VPS plan-এ থাকে। তবে root access এবং support scope একে অপরের সঙ্গে সম্পর্কিত। কিছু provider আপনার হাতে পরিবর্তন করা কোনো component-এর জন্য support কমিয়ে দিতে পারে বা বাতিল করতে পারে। আবার কোনো ticket-এর তদন্ত অনেক গভীরে গেলে কিছু provider নিজেদের template থেকে server rebuild করতে পারে। কোনো configuration পরিবর্তন বা tuning করার আগে এই নিয়ম লিখিতভাবে নিন। আপনার configuration file-গুলো version control-এ রাখুন, যাতে rebuild করতে একটি weekend-এর বদলে এক ঘণ্টা লাগে।