Managed o Unmanaged VPS: Alin ang Kailangan Mo?

Managed kumpara sa unmanaged VPS: ang maikling sagot

Ang pagpili sa pagitan ng managed at unmanaged VPS ay usapin ng workload, hindi ng produkto. Sa unmanaged, ikaw ang may pananagutan sa patching, firewall, backups, monitoring, at pag-reboot nang 2am. Sa managed, provider ang gumagawa ng ilan sa mga ito para sa iyo, at malaki ang pagkakaiba ng saklaw depende sa host. Ang tanging makabuluhang paghahambing ay ang listahan ng mga task na inaalis ng bawat plan sa iyo, na inihahambing sa halaga ng sarili mong oras.

Walang standard na depinisyon ang salitang managed. Para sa isang host, ibig sabihin nito ay napo-patch ang operating system at may taong sumasagot sa ticket. Para sa iba, ibig sabihin ay naka-install ang control panel at ikaw na ang bahala sa lahat ng nasa itaas nito. Para naman sa iba, ibig sabihin ay may nakasulat na service contract na may itinakdang response time. Maaaring magkaiba sa lahat ng mahalagang aspeto ang dalawang plan na parehong gumagamit ng salitang ito, kaya basahin muna ang scope document bago tingnan ang presyo. Kung pinagpapasyahan mo pa lang kung para saan ang machine, mas magandang unang sagutin ang kung ano talaga ang magagawa mo gamit ang VPS.

Mga gawaing kailangang may mananagot

Pare-pareho ang listahan ng mga gawaing kailangan sa bawat tumatakbong server. Sa unmanaged plan, ikaw ang responsable sa buong listahan. Sa managed plan, nagbabayad ka upang maalis ang ilang item dito. Suriin ang listahan at isulat ang pangalan ng taong responsable sa tabi ng bawat item.

• Pagpapatupad ng patch sa operating system, pati ang mga reboot na kailangan ng kernel updates.
• Mga firewall rule, na kailangang manatiling tama habang nagdadagdag at nag-aalis ka ng mga serbisyo. Saklaw ng Mga pangunahing kaalaman sa ufw firewall para sa VPS ang panimulang ruleset.
• SSH access: pangangasiwa ng key, pag-disable ng password login, pag-revoke ng key kapag umalis ang isang tao, at pagkakaroon ng paraan para makapasok muli kapag na-lock out mo ang sarili mo.
• Mga backup, isang offsite copy, at isang restore na aktuwal mong naisagawa.
• Monitoring, na nangangahulugang alam mong reachable ang server, may sapat na espasyo ang disk, tumatakbo pa rin ang serbisyo, at hindi pa expired ang certificate.
• Pagsusuri ng log, pati ang pagtugon kapag may mukhang mali sa mga log na iyon.
• Service configuration para sa web server, database, reverse proxy, at queue kung gumagamit ka nito.
• Pag-renew ng certificate, pati ang pag-aayos kapag huminto sa paggana ang automatic renewal.
• Capacity, na nangangahulugang napapansin mong nauubos na ang memory bago ito mapansin ng out of memory (OOM) killer para sa iyo.
• Incident response, na nangangahulugang gising at reachable ka sa oras na hindi ikaw ang pumili.

Routine ang karamihan sa mga ito at maaaring ipagawa sa isang script. Ang incident response ang hindi maipapagawa sa script, dahil kailangan nito ng taong makapagdedesisyon. Iyan ang aktuwal na serbisyong ibinebenta ng managed plan. Kaya karamihan sa mga tanong sa checklist sa ibaba ay tungkol sa saklaw ng support, hindi sa patching.

Ano ang karaniwang hindi kasama sa managed service

Dito kadalasang nagkakaroon ng maling inaasahan ang mga buyer, kaya dapat eksakto ang saklaw. Karaniwang kasama sa managed contract ang operating system at software na in-install ng provider. Nagtatapos ang saklaw nito sa boundary ng iyong application.

Iyo ang sarili mong code. Ang 500 error mula sa iyong application ay hindi server fault. Kukumpirmahin ng provider na tumatakbo ang web server process at ibabalik sa iyo ang ticket. Makatuwiran ang boundary na ito. Ito rin ang pinakamalaking agwat sa pagitan ng inaasahan ng mga buyer at ng aktuwal na binili nila.

Karaniwang hindi kasama ang mga problema sa application level. Kabilang dito ang mabagal na database query, plugin na nasira matapos ang update, cache na maling na-configure, at mail queue na hindi na nagpo-process ng mga mensahe. Nasa itaas ng saklaw ang mga ito kahit ang software na nasa ilalim ng mga ito ay in-install ng provider.

Karaniwang hindi kasama ang karamihan sa data recovery. Pinoprotektahan ng backups ng provider ang buong server image ayon sa pananaw ng provider, at ginagamit ang mga ito kapag nagkaaberya ang host hardware. Bihira itong idisenyo para sa sitwasyong may nabura kang row, nakapagpatakbo ng maling migration, o nakasira ng file anim na linggo na ang nakalipas at ngayon mo lang napansin. Itanong kung gaano katagal ang retention window, kung maaaring i-restore ang isang file lang, at kung sino ang magsasagawa ng restore.

Iyo ang software na ikaw ang nag-install. Kapag nag-install ka ng Docker, karaniwang pagmamay-ari ng provider ang host, samantalang ikaw ang responsable sa lahat ng nasa loob ng containers.

Maaaring mawalan ng bisa ang support kapag nag-edit ka nang direkta. May ilang contract na nag-aalis ng isang component sa saklaw kapag direktang binago ng customer ang configuration nito. Itanong ito kung plano mong mag-tune ng anumang configuration.

Ihambing ang halaga ng sarili mong oras sa buwanang diperensya

Kunin ang dalawang quote sa harap mo at isulat ang buwanang diperensya. Iyan ang halagang sinisingil ng provider para alisin ang mga item sa listahan sa itaas. Ngayon, magtakda naman ng halaga para sa panig mo ng trade-off.

• Magkano ang halaga ng isang oras ng oras mo, at ilang oras bawat buwan ang kinakailangan ng listahang iyon kapag automated na?
• Magkano ang gastos ng isang oras na downtime para sa serbisyong tumatakbo sa server na ito?

Ang isang stable na Ubuntu box na may automatic updates at external monitoring ay nangangailangan ng kaunting routine attention. Sa karamihan ng buwan, wala itong kinakailangan. Mura ang routine work kapag script na ang namamahala rito. Ang mga interruption ang magastos, at ang mga interruption ang saklaw ng ibinebenta ng managed plan. Kung hobby project ang tumatakbo sa server, walang gastos ang outage at malinaw na unmanaged ang tamang sagot. Kung tumatanggap ito ng orders, suriing mabuti kung talagang paiikliin ng support contract ang outage, dahil kailangan pa ring basahin ng managed provider ang ticket mo, i-reproduce ang fault, at kumilos.

Lumalaki rin ang diperensya kasabay ng dami ng server. Karaniwang per server ang singil sa managed fees, samantalang isang beses lang isinusulat at pagkatapos ay kinokopya ang automation. Sa ikalawang server, nahahati ang effective cost ng script na isinulat mo para sa una. Kaya basahin ang kung paano mag-manage ng maraming Linux server bago mag-commit sa per-server fee. Para sa base numbers sa magkabilang panig ng paghahambing, ang aktuwal na buwanang gastos ng isang VPS ang nagtatakda ng minimum, at mahalaga ang trade-off sa pagitan ng VPS at dedicated server kapag sapat na ang laki ng workload para maging halos hindi na mahalaga ang managed premium.

Mga tanong na dapat itanong sa host bago magbayad para sa managed premium

Magtanong bago magbayad, at hingin ang mga sagot nang nakasulat. Hindi scope document ang isang sales page.

1. Ano ang saklaw, task bawat task? Hingin ang listahan, hindi ang brochure.
2. Saklaw ba ng support ang software na ini-install ko, o ang software lang na kayo ang nag-install?
3. Awtomatiko ba kayong nag-a-apply ng patches, at nagre-reboot ba kayo para sa kernel updates nang hindi muna humihingi ng pahintulot?
4. Sino ang mananagot kung masira ang application ko dahil sa patch na inilapat ninyo?
5. Gumagawa ba kayo ng backups? Saan naka-store ang mga ito, gaano katagal itinatago, at sino ang nagsasagawa ng restore?
6. May na-restore ba kayong customer server kamakailan, at gaano ito katagal?
7. Ano ang ticket response time, at iba ba ito kapag 03:00 ng Linggo?
8. Mananatili ba sa akin ang root access, at mababawasan ba ang saklaw ng support ninyo kapag ginagamit ko ito?
9. Per server ba o per account sinisingil ang fee?
10. Kung aalis ako, ano ang madadala ko? Maaaring mahirap i-export ang setup na nakapaloob sa isang proprietary control panel.

Sinasagot ng Question 5 ang karamihan sa iba pang tanong. Kapag tiyak ang sagot ng isang host dito, ipinapakita nitong nagawa na nila ito dati. Ang malabong sagot ay nangangahulugang hindi pa nasusubukan ang restore, at ang backup na hindi pa nasusubukan ay kopya lamang. May bahagi rin tungkol sa lokasyon ang Question 5: legal na tanong din, bukod sa technical na tanong, kung saan pisikal na naka-store ang mga kopya, at tinatalakay iyon sa kung ano talaga ang mahalaga sa pagpili ng hosting country.

Ang gitnang landas: unmanaged na may automation

Karamihan sa mga technical reader ay ayaw sa alinman sa dalawang sukdulan. Gusto nila ng unmanaged plan na ipinagagawa sa machine ang mga routine na task, habang nakalaan ang sarili nilang atensyon sa mga bagay na hindi kayang husgahan ng machine. I-set up ito sa unang araw. Ang unang sampung minuto sa bagong VPS ang praktikal na panimula para sa sinumang pipili ng unmanaged, at dapat kasama rin sa unang session na iyon ang pagpapatibay ng SSH access.

Mga automatic security update

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

Dapat ay naglalaman na ang file na iyon ng APT::Periodic::Update-Package-Lists "1"; at APT::Periodic::Unattended-Upgrade "1";. Kapag nawawala ang file, o may 0 sa alinmang linya, walang tatakbo at walang ipaaalam sa iyo.

Subukan ito nang hindi binabago ang system. Tandaan na unattended-upgrades ang package, samantalang singular ang command:

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

Inililista ng output ang bawat package na sinuri nito at nagtatapos sa linyang gaya ng No packages found that can be upgraded unattended kapag walang nakabinbin. Isinusulat ang mga aktuwal na run sa /var/log/unattended-upgrades/unattended-upgrades.log, kaya doon magsuri sa halip na manghula.

Walang nagbabago kaagad matapos ang kernel update hanggang sa mag-reboot ang machine, dahil ang tumatakbong kernel ay ang kernel na nilo-load sa boot time. Lumilitaw ang file na /var/run/reboot-required kapag may nakabinbing reboot. Maaari mong bantayan ang file na iyon, o hayaan ang machine na humawak nito sa /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";

Pinipigilan ng Automatic-Reboot-WithUsers "false" ang reboot habang may naka-login, na mas ligtas sa machine na ginagamit mo nang interactive at walang silbi sa machine na walang nagla-login. Sinasaklaw ng kumpletong setup ng unattended upgrades sa Ubuntu ang syntax ng blocklist at mga opsyon para sa email.

Monitoring na tumatakbo sa ibang lugar

Hindi masasabi ng monitor na tumatakbo sa server na down ang server, dahil down din ito. Ilagay ang check sa pangalawang host o sa external service. Ang Uptime Kuma para sa status monitoring ang karaniwang self-hosted na sagot, at dapat itong nasa ibang machine kaysa sa mino-monitor nito.

Bantayan ang hindi bababa sa apat na bagay: reachability, disk usage, kung sumasagot ang application sa aktuwal nitong port, at certificate expiry. Ang disk ang madalas nakalilimot ang mga tao. Ang log file o database na bahagyang lumalaki araw-araw ay maaaring magpa-down sa machine sa oras na walang ibang nakapaghuhula, at kadalasang unang sintomas ang service na hindi makasulat at nag-e-exit.

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

Magdagdag din ng heartbeat. Tinutawagan ng timer sa server ang isang URL pagkatapos ng bawat matagumpay na backup o health check, at nag-a-alert ang monitor kapag hindi na dumarating ang tawag na iyon. Sa ganitong paraan, awtomatikong naglalabas ng alert ang tahimik na server, na hindi kayang gawin ng pull-only check kapag ang network path ang nasira.

Mga backup na kahit isang beses ay na-restore mo na

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

Minsan lang inilalabas ng restic init ang created restic repository <id> at sftp:.... Kapag pinatakbo ito laban sa repository na mayroon na, magfa-fail ito sa halip na mag-overwrite, at iyon ang gusto mong behavior. Magtabi ng kopya ng passphrase na iyon sa labas ng server: hindi mababasa ang repository kung wala ito, at walang recovery path.

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

Dapat ilista ng restic snapshots ang run na ginawa mo lamang, kasama ang petsa ngayon. Bine-verify ng restic check ang structure ng repository at inilalabas ang no errors were found. Ngayon gawin ang bahaging kadalasang nilalaktawan ng mga tao:

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

Ang file na inaasahan mo ay naroon o wala, at sampung minuto lang ang halaga ng pag-alam nito ngayon. Pagkatapos, ilagay ang run sa timer para hindi ito nakadepende sa iyo. Isulat ang /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

At ang /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

Ipinapakita ng list-timers ang susunod na run at ang natitirang oras. Ang walang laman na resulta ay nangangahulugang na-enable mo ang service sa halip na ang timer, na pinakakaraniwang pagkakamali rito. Pinapatakbo ng Persistent=true ang na-miss na job pagkatapos ng susunod na boot, kaya nakukuha pa rin ng machine na naka-off buong gabi ang backup nito. Mas malalim na tinatalakay ng Restic backups sa isang VPS ang layout at retention ng repository, at ipinapaliwanag ng systemd services at timers ang mga unit file, linya bawat linya.

Mga hindi naibibigay ng automation

Hindi nito naibibigay ang tamang paghatol. Nangyayari ang automatic reboot sa 02:00 kahit hindi maayos na makabalik ang application mo, kaya tiyaking kusang nagsisimula ang bawat service at pagkatapos ay magsagawa ng reboot habang gising ka:

systemctl is-enabled nginx docker
sudo reboot

Maaari ring mag-install ang unattended upgrade ng package na sumisira sa application mo, at walang bahagi ng pipeline ang makaaalam na nangyari iyon. Ang monitor ang makakahuli nito, kaya hindi optional ang monitor kapag automatic ang mga update. Sinasaklaw ng machine ang mga routine. Iyo pa rin ang incident.

Kailan sulit ang managed service

Maging patas sa managed service. May apat na sitwasyon kung kailan ito ang tamang piliin.

• Walang nagpapatakbo ng Linux sa team, at hindi plano ang mag-hire ng isang tao para rito.
• May compliance requirement na nagtatalaga ng partidong responsable sa patching, at hindi puwedeng kayo ang partidong iyon.
• Ang stack ay kabilang sa mga espesyalisasyon ng host, kaya nakaranas na ang support nila ng katulad na failure.
• Ang taong kung hindi man ay gagawa ng trabaho ay ang pinakamahal mong empleyado, at mas mahal ang isang oras niya kaysa sa premium para sa isang buwan.

Hindi awtomatikong mas secure ang managed service. Mas mabilis mag-apply ng patch ang managed plans kaysa sa owner na hindi maingat, at tunay na pakinabang iyon. Madalas din silang nag-i-install ng control panel, na isang malaking application na nakaharap sa network, may login page, at may sarili ring kasaysayan ng vulnerabilities. Maaaring makatuwirang trade-off iyon, pero trade-off pa rin ito.

Pareho pa rin ang listahang dapat pagbasehan sa bawat pagkakataon. Isulat ang sampung task, tukuyin kung sino ang responsable sa bawat isa sa ilalim ng bawat quote, at pagkatapos ay ihambing ang agwat sa halaga ng isang oras ng iyong atensyon. Karamihan sa mga technical reader na gumagawa nito ay nauuwi sa unmanaged setup na ang routine ay ipinapagawa sa timer, at depensableng sagot iyon—hindi lamang murang opsyon.

FAQ

Ano ang pagkakaiba ng managed at unmanaged VPS?

Ang unmanaged VPS ay nagbibigay sa iyo ng machine at wala nang iba, kaya ikaw ang responsable sa patching, firewall, backups, monitoring, at pag-reboot pagkatapos ng kernel update. Sa managed VPS, inililipat ang bahagi ng gawaing ito sa provider, karaniwang ang operating system layer at ang software na sila ang nag-install para sa iyo. Ang eksaktong saklaw ay itinatakda ng bawat provider, hindi ng label mismo. Kaya humingi ng nakasulat na saklaw para sa bawat task bago magkumpara ng dalawang presyo.

Ibig bang sabihin ng managed VPS na hindi ko na kailangan ng sarili kong backups?

Hindi. Karaniwang pinoprotektahan ng provider backups ang image ng buong server sa panig ng provider. Ginagamit ang mga ito kapag nagkaaberya ang host. Bihira itong makatulong kapag nakapag-delete ka ng file, nakapagpatakbo ng maling migration, o nakapag-corrupt ng data ilang linggo na ang nakalipas at ngayon mo lang napansin. Itanong kung gaano katagal itinatago ang snapshots, kung maaaring i-restore ang isang file lang, at kung sino ang magsasagawa ng restore. Pagkatapos, magtabi ng sarili mong offsite copy gamit ang tool gaya ng restic, at i-test ito gamit ang restic restore latest --target /tmp/restore-check para makumpirma mong gumagana ito.

Mas secure ba ang managed VPS kaysa unmanaged VPS?

Hindi dahil managed ito. Mas mabilis mag-install ng patches ang managed plan kaysa sa owner na hindi kailanman nagla-login, kaya tunay nitong binabawasan ang risk. Marami ring managed plan ang nag-i-install ng control panel. Ang panel ay isang malaking network-facing application na may sarili nitong login page at sariling kasaysayan ng vulnerabilities. Ang unmanaged box na may automatic security updates, saradong firewall, key-only SSH, at walang ibang nakikinig na serbisyo ay mas maliit na target kaysa sa managed box na nagpapatakbo ng panel.

Maaari ba akong magsimula sa unmanaged at lumipat sa managed sa hinaharap?

Karaniwan, oo, pero bihira itong simpleng checkbox. Madalas na ina-audit o nire-rebuild muna ng mga provider ang server bago nila ito panagutan, dahil hindi nila susuportahan ang configuration na hindi nila nakikita. Itanong kung ano ang kasama sa onboarding, kung kailangan nito ng reinstall, at kung mananatiling out of scope ang anumang ikaw mismo ang nag-configure.

Mananatili ba sa akin ang root access sa managed VPS?

Sa karamihan ng managed VPS plan, oo, pero magkaugnay ang root access at support scope. Binabawasan o inaalis ng ilang provider ang support para sa component na mano-mano mong in-edit. May ilan din na magre-rebuild gamit ang sarili nilang template kung umabot nang malalim ang isang ticket. Kunin ang patakarang ito nang nakasulat bago ka mag-tune ng anumang configuration, at panatilihin sa version control ang iyong configuration files para ang rebuild ay umabot lang ng isang oras sa halip na isang weekend.