Managed बनाम Unmanaged VPS: आपके लिए क्या सही है?

Managed बनाम unmanaged VPS: संक्षिप्त उत्तर

Managed बनाम unmanaged VPS का चुनाव उत्पाद का नहीं, बल्कि श्रम का प्रश्न है। Unmanaged का अर्थ है कि patching, firewall, backups, monitoring और रात के 2 बजे reboot करने की जिम्मेदारी आपकी है। Managed का अर्थ है कि provider आपके लिए इसमें से कुछ कार्य करता है, और यह हिस्सा अलग-अलग hosts के बीच काफी भिन्न होता है। एकमात्र उपयोगी तुलना उन कार्यों की सूची है जिन्हें प्रत्येक plan आपके हाथों से ले लेता है, और इसकी तुलना आपके अपने घंटों की लागत से की जानी चाहिए।

Managed शब्द की कोई मानक परिभाषा नहीं है। एक host का अर्थ हो सकता है कि operating system को patch किया जाएगा और कोई व्यक्ति आपके ticket का उत्तर देगा। दूसरे का अर्थ हो सकता है कि एक control panel install कर दिया गया है और उसके ऊपर की हर चीज आपकी जिम्मेदारी है। तीसरे का अर्थ एक लिखित service contract हो सकता है जिसमें response time तय हो। एक ही शब्द वाले दो plans हर महत्वपूर्ण पहलू में भिन्न हो सकते हैं, इसलिए कीमत देखने से पहले scope document को पढ़ें। यदि आप अभी भी यह तय कर रहे हैं कि machine का उपयोग किस लिए करना है, तो VPS के साथ आप वास्तव में क्या कर सकते हैं यह प्रश्न पहले सुलझाना बेहतर है।

वे कार्य जिनकी जिम्मेदारी किसी न किसी को लेनी होगी

प्रत्येक चल रहे सर्वर पर कार्यों की एक समान सूची होती है। अनमैनेज्ड प्लान पर वह सूची आपकी है। मैनेज्ड प्लान पर आप उस सूची से पंक्तियों को हटाने के लिए भुगतान कर रहे होते हैं। सूची को देखें और प्रत्येक के सामने एक नाम लिखें।

• ऑपरेटिंग सिस्टम की पैचिंग, और वे रीबूट जिनकी आवश्यकता कर्नल अपडेट के लिए होती है।
• फायरवॉल नियम, जिन्हें सेवाओं को जोड़ने और हटाने के साथ सही रखा जाता है। VPS के लिए ufw फायरवॉल की बुनियादी बातें शुरुआती नियम-सेट को कवर करती हैं।
• SSH एक्सेस: की (key) हैंडलिंग, पासवर्ड लॉगिन को अक्षम करना, किसी के जाने पर की (key) को रद्द करना, और खुद को लॉक कर लेने पर वापस अंदर जाने का एक तरीका।
• बैकअप, एक ऑफसाइट कॉपी, और एक रिस्टोर जिसे आपने वास्तव में निष्पादित किया हो।
• मॉनिटरिंग, जिसका अर्थ है यह जानना कि बॉक्स पहुंच योग्य है, डिस्क में जगह है, सेवा अभी भी चल रही है, और सर्टिफिकेट की समय सीमा समाप्त नहीं हुई है।
• लॉग की समीक्षा, और जब उन लॉग्स में कुछ गलत दिखे तो उस पर प्रतिक्रिया देना।
• वेब सर्वर, डेटाबेस, रिवर्स प्रॉक्सी और यदि आप कोई कतार (queue) चलाते हैं तो उसके लिए सर्विस कॉन्फ़िगरेशन।
• सर्टिफिकेट का नवीनीकरण, और जब स्वचालित नवीनीकरण काम करना बंद कर दे तो उसकी मरम्मत।
• क्षमता, जिसका अर्थ है यह नोटिस करना कि मेमोरी समाप्त हो गई है, इससे पहले कि आउट ऑफ मेमोरी (OOM) किलर आपके लिए इसे नोटिस करे।
• घटना प्रतिक्रिया (Incident response), जिसका अर्थ है ऐसे समय में जागना और पहुंच योग्य होना जिसे आप नहीं चुनते हैं।

इनमें से अधिकांश कार्य नियमित हैं और इन्हें स्क्रिप्ट को सौंपा जा सकता है। घटना प्रतिक्रिया वह कार्य है जिसे नहीं सौंपा जा सकता, क्योंकि इसके लिए ऐसे व्यक्ति की आवश्यकता होती है जो निर्णय ले सके। यही वह वास्तविक उत्पाद है जिसे एक मैनेज्ड प्लान बेचता है, और इसीलिए नीचे दी गई चेकलिस्ट पैचिंग के बजाय सपोर्ट स्कोप पर अधिक प्रश्न पूछती है।

Managed services में आमतौर पर क्या शामिल नहीं होता है

यहीं पर खरीदार अक्सर धोखा खाते हैं, इसलिए इसे स्पष्ट रूप से समझना जरूरी है। एक managed contract आमतौर पर operating system और provider द्वारा install किए गए software को कवर करता है। यह आपके application की सीमा पर समाप्त हो जाता है।

आपका अपना code आपका है। आपके application से आने वाली 500 error सर्वर की खराबी नहीं है। provider केवल यह पुष्टि करेगा कि web server process चल रही है और ticket आपको वापस सौंप देगा। यह एक उचित सीमा है। खरीदारों की अपेक्षा और जो उन्होंने खरीदा है, उसके बीच का सबसे बड़ा अंतर यही है।

Application-level की समस्याएं आमतौर पर scope से बाहर होती हैं। एक धीमी database query, update के बाद खराब हुआ plugin, गलत तरीके से configure किया गया cache, या mail queue का रुक जाना: ये सभी चीजें उस सीमा से ऊपर आती हैं, भले ही उनके नीचे का software provider ने ही install किया हो।

ज्यादातर data recovery scope से बाहर होती है। provider के backups पूरे सर्वर की image को सुरक्षित रखते हैं, और वे तब काम आते हैं जब host hardware विफल हो जाए। वे शायद ही कभी उस स्थिति के लिए बनाए जाते हैं जहाँ आपने कोई row delete कर दी हो, कोई गलत migration चलाया हो, या छह सप्ताह पहले कोई file corrupt कर दी हो और आज पता चला हो। पूछें कि retention window क्या है, क्या एक single file को restore किया जा सकता है, और restore की प्रक्रिया कौन चलाता है।

आपके द्वारा install किया गया software आपका है। यदि आप Docker install करते हैं, तो provider आमतौर पर host का मालिक होता है, जबकि containers के अंदर की हर चीज के मालिक आप होते हैं।

Manual edits support को रद्द कर सकते हैं। कुछ contracts में, यदि कोई ग्राहक सीधे configuration में बदलाव करता है, तो वह component support के scope से बाहर हो जाता है। यदि आप किसी भी चीज को tune करने की योजना बना रहे हैं, तो इस बारे में पहले पूछ लें।

अपने समय का मूल्य मासिक अंतर के सापेक्ष निर्धारित करें

अपने सामने मौजूद दो quotes लें और उनके बीच का मासिक अंतर लिखें। यह वह राशि है जो provider ऊपर दी गई सूची से कार्यों को हटाने के लिए ले रहा है। अब इस सौदे में अपने पक्ष का मूल्य निर्धारित करें।

• आपके एक घंटे के समय का मूल्य क्या है, और एक बार automate हो जाने पर उस सूची के कार्यों में प्रति माह कितने घंटे लगते हैं?
• इस सर्वर पर चल रही सेवा के लिए एक घंटे का downtime कितना महंगा पड़ता है?

Automatic updates और external monitoring वाला एक स्थिर Ubuntu सर्वर बहुत कम नियमित ध्यान मांगता है। अधिकांश महीनों में इसकी कोई आवश्यकता नहीं होती। एक बार जब कोई script routine काम संभाल लेती है, तो वह सस्ता हो जाता है। Interrupts सबसे महंगे होते हैं, और managed plan इन्हीं interrupts को बेचने का काम करता है। यदि सर्वर पर कोई hobby project चल रहा है, तो outage की कोई लागत नहीं है और unmanaged विकल्प ही स्पष्ट उत्तर है। यदि सर्वर orders लेता है, तो गंभीरता से विचार करें कि क्या support contract वास्तव में outage को कम करता है, क्योंकि managed provider को भी आपका ticket पढ़ना होगा, fault को reproduce करना होगा और उस पर कार्रवाई करनी होगी।

यह अंतर सर्वर की संख्या के साथ भी बढ़ता है। Managed शुल्क आमतौर पर प्रति सर्वर लिया जाता है, जबकि automation एक बार लिखकर copy किया जा सकता है। दूसरा सर्वर पहले सर्वर के लिए लिखी गई script की प्रभावी लागत को आधा कर देता है, इसलिए प्रति-सर्वर शुल्क के लिए प्रतिबद्ध होने से पहले how to manage multiple Linux servers पढ़ें। तुलना के दोनों पक्षों के आधारभूत आंकड़ों के लिए, what a VPS actually costs per month न्यूनतम लागत निर्धारित करता है, और the VPS versus dedicated server trade-off तब मायने रखता है जब workload इतना बड़ा हो जाए कि managed premium एक मामूली अंतर मात्र रह जाए।

Managed premium का भुगतान करने से पहले host से पूछने योग्य प्रश्न

भुगतान करने से पहले पूछें, और उत्तर लिखित रूप में मांगें। Sales page कोई scope document नहीं होता है।

1. कार्य-दर-कार्य, scope में क्या शामिल है? Brochure नहीं, बल्कि सूची मांगें।
2. क्या support केवल आपके द्वारा install किए गए software को कवर करता है, या मेरे द्वारा install किए गए software को भी?
3. क्या आप automatic patching करते हैं, और क्या आप मुझसे पूछे बिना kernel updates के लिए reboot करते हैं?
4. यदि आपके द्वारा apply किया गया patch मेरे application को खराब कर देता है, तो इसके लिए कौन जिम्मेदार है?
5. क्या आप backups लेते हैं? वे कहाँ store किए जाते हैं, उन्हें कितने समय तक रखा जाता है, और restore कौन करता है?
6. क्या आपने हाल ही में किसी customer server को restore किया है, और इसमें कितना समय लगा?
7. Ticket response time क्या है, और क्या रविवार को 03:00 बजे यह अलग होता है?
8. क्या मेरे पास root access रहता है, और क्या इसका उपयोग करने से आपका support सीमित हो जाता है?
9. क्या शुल्क प्रति server लिया जाता है या प्रति account?
10. यदि मैं सेवा छोड़ता हूँ, तो मैं अपने साथ क्या ले जा सकता हूँ? Proprietary control panel के भीतर बना setup export करना कठिन हो सकता है।

प्रश्न 5 अन्य अधिकांश प्रश्नों का निर्णय करता है। जो host इसका सटीक उत्तर देता है, वह आपको बता रहा है कि उसने पहले ऐसा किया है। अस्पष्ट उत्तर का अर्थ है कि restore का कभी परीक्षण नहीं किया गया है, और untested backup केवल एक प्रति (copy) है। प्रश्न 5 का एक स्थान संबंधी पहलू भी है: प्रतियाँ भौतिक रूप से कहाँ स्थित हैं, यह तकनीकी प्रश्न के साथ-साथ एक कानूनी प्रश्न भी है, और hosting country चुनते समय वास्तव में क्या मायने रखता है में इसका विस्तार से वर्णन है।

मध्यम मार्ग: unmanaged और automation का मेल

अधिकांश तकनीकी पाठक न तो पूरी तरह managed सेवा चाहते हैं और न ही पूरी तरह manual। वे एक unmanaged प्लान चाहते हैं जहाँ नियमित काम मशीन करे, और उनका ध्यान उन चीजों पर रहे जिन्हें मशीन नहीं समझ सकती। इसे पहले दिन ही सेट करें। नए VPS पर शुरुआती दस मिनट unmanaged विकल्प चुनने वाले किसी भी व्यक्ति के लिए व्यावहारिक शुरुआती बिंदु है, और SSH access को सुरक्षित करना उसी पहले सत्र का हिस्सा होना चाहिए।

स्वचालित सुरक्षा अपडेट

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 का मतलब है कि कोई भी अपग्रेड इंस्टॉल नहीं होगा। पहली लाइन पर 0 केवल पैकेज लिस्ट को रिफ्रेश होने से रोकता है, इसलिए अपग्रेड पुरानी लिस्ट के आधार पर चलते रहते हैं और नए सुरक्षा फिक्स ढूंढना चुपचाप बंद कर देते हैं। दोनों ही गलतियों से कोई एरर नहीं आता।

सिस्टम को बदले बिना इसका परीक्षण करें। ध्यान दें कि पैकेज unattended-upgrades है जबकि कमांड एकवचन (singular) है:

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

आउटपुट उन सभी पैकेजों को सूचीबद्ध करता है जिन पर विचार किया गया और अंत में No packages found that can be upgraded unattended and no pending auto-removals लाइन आती है जब कुछ भी पेंडिंग नहीं होता। वास्तविक रन /var/log/unattended-upgrades/unattended-upgrades.log में लिखे जाते हैं, इसलिए अनुमान लगाने के बजाय वहां जांचें।

कर्नेल अपडेट तब तक कुछ नहीं बदलता जब तक मशीन रीबूट न हो जाए, क्योंकि जो कर्नेल चल रहा है वही बूट के समय लोड हुआ था। जब रीबूट पेंडिंग होता है तो /var/run/reboot-required फाइल दिखाई देती है। या तो उस फाइल पर नजर रखें, या मशीन को /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" रीबूट को तब तक रोकता है जब तक कोई लॉग इन हो, जो उस बॉक्स पर सुरक्षित है जिसे आप इंटरैक्टिव रूप से उपयोग करते हैं, लेकिन जिस पर कोई लॉग इन नहीं करता वहां यह बेकार है। Ubuntu पर unattended upgrades का पूरा सेटअप ब्लॉकलिस्ट सिंटैक्स और ईमेल विकल्पों को कवर करता है।

कहीं और चलने वाली मॉनिटरिंग

सर्वर पर चलने वाला मॉनिटर आपको यह नहीं बता सकता कि सर्वर डाउन है, क्योंकि वह खुद भी डाउन है। चेक को दूसरे होस्ट या बाहरी सेवा पर रखें। स्टेटस मॉनिटरिंग के लिए Uptime Kuma एक सामान्य self-hosted समाधान है, और इसे उस मशीन से अलग मशीन पर होना चाहिए जिसकी यह निगरानी करता है।

कम से कम चार चीजों पर नजर रखें: पहुंच (reachability), डिस्क उपयोग, क्या एप्लिकेशन अपने वास्तविक पोर्ट पर जवाब दे रहा है, और सर्टिफिकेट की समाप्ति। डिस्क वह चीज है जो लोगों को फंसाती है। एक लॉग फाइल या डेटाबेस जो हर दिन थोड़ा बढ़ता है, वह बॉक्स को ऐसे समय में डाउन कर देता है जब कोई और चीज इसकी भविष्यवाणी नहीं कर सकती, और पहला लक्षण अक्सर यह होता है कि सर्विस लिख नहीं पाती और बंद हो जाती है।

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

एक हार्टबीट भी जोड़ें। सर्वर पर एक टाइमर हर सफल बैकअप या हेल्थ चेक के बाद एक URL को कॉल करता है, और जब वह कॉल आनी बंद हो जाती है तो मॉनिटर अलर्ट देता है। एक शांत सर्वर तब खुद ही अलर्ट पैदा करता है, जो नेटवर्क पाथ टूटने पर केवल pull-only चेक नहीं कर सकता।

बैकअप जिसे आपने कम से कम एक बार रिस्टोर किया हो

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:... प्रिंट करता है। पहले से मौजूद रिपॉजिटरी पर इसे चलाने से यह ओवरराइट करने के बजाय फेल हो जाता है, जो कि आप चाहते हैं। उस पासफ्रेज की एक कॉपी सर्वर से बाहर कहीं रखें: रिपॉजिटरी उसके बिना अपठनीय है, और रिकवरी का कोई रास्ता नहीं है।

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 रिपॉजिटरी संरचना को सत्यापित करता है और no errors were found प्रिंट करता है। अब वह हिस्सा करें जिसे ज्यादातर लोग छोड़ देते हैं:

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

जिस फाइल की आपको उम्मीद थी वह या तो वहां है या नहीं है, और अभी इसका पता लगाने में दस मिनट लगते हैं। फिर रन को टाइमर पर रखें ताकि यह आप पर निर्भर न रहे। /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 अगला रन और बचा हुआ समय दिखाता है। खाली परिणाम का मतलब है कि आपने टाइमर के बजाय सर्विस को इनेबल कर दिया है, जो यहां सबसे आम गलती है। Persistent=true अगले बूट के बाद छूटे हुए जॉब को चलाता है, इसलिए जो मशीन रात भर बंद थी, उसका बैकअप भी हो जाता है। VPS पर Restic बैकअप रिपॉजिटरी लेआउट और रिटेंशन पर गहराई से चर्चा करता है, और systemd सर्विसेज और टाइमर यूनिट फाइलों को लाइन-दर-लाइन समझाता है।

ऑटोमेशन आपको क्या नहीं देता

यह आपको निर्णय लेने की क्षमता नहीं देता। 02:00 बजे एक स्वचालित रीबूट तब भी होता है चाहे आपका एप्लिकेशन सही ढंग से वापस आए या न आए, इसलिए पुष्टि करें कि हर सर्विस अपने आप शुरू होती है और फिर जानबूझकर रीबूट करें जब आप जाग रहे हों:

systemctl is-enabled nginx docker
sudo reboot

एक unattended upgrade ऐसा पैकेज भी इंस्टॉल कर सकता है जो आपके एप्लिकेशन को तोड़ दे, और पाइपलाइन में किसी को पता नहीं चलता कि क्या हुआ। आपका मॉनिटर ही इसे पकड़ता है, इसीलिए अपडेट स्वचालित होने पर मॉनिटर वैकल्पिक नहीं रह जाता। मशीन नियमित काम संभालती है। घटना (incident) अभी भी आपकी जिम्मेदारी है।

कब managed सेवा के लिए भुगतान करना उचित है

Managed सेवा के पक्ष में निष्पक्ष रहें। चार स्थितियाँ इसे सही खरीद बनाती हैं:

• टीम में कोई भी Linux नहीं चलाता है, और किसी को काम पर रखने की योजना नहीं है।
• अनुपालन (compliance) की आवश्यकता में किसी पार्टी को पैचिंग के लिए जिम्मेदार ठहराया गया है, और वह पार्टी आप नहीं हो सकते।
• stack वह है जिसमें host विशेषज्ञता रखता है, इसलिए उनके support ने आपकी विफलता को पहले भी देखा होगा।
• जो व्यक्ति अन्यथा यह काम करेगा, वह आपका सबसे महंगा कर्मचारी है, और उसका एक घंटे का समय प्रीमियम के एक महीने के खर्च से अधिक महंगा है।

Managed सेवा स्वचालित रूप से अधिक सुरक्षित नहीं होती है। Managed plans एक लापरवाह मालिक की तुलना में तेजी से पैच करते हैं, और यह एक वास्तविक लाभ है। वे अक्सर एक control panel भी install करते हैं, जो एक बड़ा network-facing application है जिसमें login page होता है और जिसका अपना vulnerability इतिहास है। यह एक उचित समझौता हो सकता है, लेकिन यह अभी भी एक समझौता ही है।

निर्णय हर बार उसी सूची पर निर्भर करता है। दस कार्यों को लिखें, प्रत्येक quote के तहत चिह्नित करें कि कौन किसका मालिक है, फिर उस अंतर की तुलना करें कि आपके ध्यान का एक घंटा कितना मूल्यवान है। अधिकांश तकनीकी पाठक जो ऐसा करते हैं, वे अंततः unmanaged विकल्प चुनते हैं और दिनचर्या को एक timer को सौंप देते हैं, और यह एक सस्ता उत्तर होने के बजाय एक तर्कसंगत उत्तर है।

FAQ

Managed और unmanaged VPS में क्या अंतर है?

Unmanaged VPS आपको केवल मशीन देता है, इसलिए patching, firewall, backups, monitoring और kernel update के बाद reboot की जिम्मेदारी आपकी होती है। Managed VPS इस काम का कुछ हिस्सा provider को सौंप देता है, आमतौर पर operating system layer और उनके द्वारा install किए गए software के लिए। सटीक सीमा शब्द के बजाय प्रत्येक provider द्वारा तय की जाती है, इसलिए दो कीमतों की तुलना करने से पहले लिखित में कार्य-दर-कार्य scope के बारे में पूछें।

क्या managed VPS का मतलब है कि मुझे अपने backups की आवश्यकता नहीं है?

नहीं। Provider के backups आमतौर पर पूरे सर्वर की image को सुरक्षित रखते हैं और तब काम आते हैं जब host विफल हो जाता है। यदि आपने कोई फ़ाइल डिलीट कर दी है, गलत migration चलाया है, या हफ़्तों पहले डेटा corrupt हो गया था और आज पता चला है, तो वे शायद ही मदद कर पाएंगे। पूछें कि snapshots कितने समय तक रखे जाते हैं, क्या एक single फ़ाइल को restore किया जा सकता है, और restore कौन करता है। फिर restic जैसे tool के साथ अपनी offsite copy रखें, और इसे restic restore latest --target /tmp/restore-check के साथ test करें ताकि आप जान सकें कि यह काम करता है।

क्या managed VPS, unmanaged VPS से अधिक सुरक्षित है?

स्वयं में नहीं। एक managed plan उस मालिक की तुलना में तेज़ी से patch करता है जो कभी login नहीं करता, जो वास्तव में जोखिम को कम करता है। कई managed plans एक control panel भी install करते हैं, और एक panel अपने login page और vulnerabilities के इतिहास के साथ network के सामने रहने वाला एक बड़ा application है। automatic security updates, बंद firewall, केवल key-based SSH और बिना किसी अतिरिक्त listening service वाला unmanaged box, panel चलाने वाले managed box की तुलना में एक छोटा target होता है।

क्या मैं unmanaged से शुरुआत करके बाद में managed पर switch कर सकता हूँ?

आमतौर पर हाँ, हालाँकि यह शायद ही कभी केवल एक checkbox होता है। Provider आमतौर पर जिम्मेदारी लेने से पहले सर्वर का audit या उसे rebuild करते हैं, क्योंकि वे ऐसी configuration का समर्थन नहीं करेंगे जिसे वे देख नहीं सकते। पूछें कि onboarding में क्या शामिल है, क्या इसके लिए reinstall की आवश्यकता है, और क्या आपके द्वारा configure की गई कोई चीज़ बाद में scope से बाहर रहती है।

क्या मेरे पास managed VPS पर root access रहता है?

अधिकांश managed VPS plans पर आपके पास यह होता है, लेकिन root access और support scope एक-दूसरे को प्रभावित करते हैं। कुछ providers आपके द्वारा हाथ से edit किए गए component के लिए support कम कर देते हैं या समाप्त कर देते हैं, और यदि ticket बहुत गंभीर हो तो कुछ अपने स्वयं के template से rebuild कर देते हैं। कुछ भी tune करने से पहले वह नियम लिखित में प्राप्त करें, और अपनी configuration files को version control में रखें ताकि rebuild में सप्ताहांत के बजाय केवल एक घंटा लगे।