VPS Terkelola atau Tidak: Mana yang Anda Butuhkan?

VPS terkelola vs tidak terkelola: jawaban singkat

Memilih antara VPS terkelola dan tidak terkelola adalah persoalan beban kerja, bukan persoalan produk. Pada VPS tidak terkelola, Anda bertanggung jawab atas penerapan patch, firewall, pencadangan, pemantauan, dan reboot pada pukul 2 pagi. Pada VPS terkelola, penyedia menangani sebagian tugas tersebut untuk Anda. Besarnya cakupan layanan itu sangat berbeda antar-host. Perbandingan yang berguna hanyalah daftar tugas yang diambil alih oleh setiap paket, dibandingkan dengan biaya waktu Anda sendiri.

Tidak ada definisi standar untuk istilah terkelola. Pada satu host, sistem operasi diperbarui dengan patch dan seseorang menjawab tiket. Pada host lain, control panel dipasang, tetapi segala sesuatu di atasnya menjadi tanggung jawab Anda. Pada host ketiga, layanan tersebut dicantumkan dalam kontrak layanan tertulis dengan waktu respons tertentu. Dua paket yang menggunakan istilah yang sama dapat berbeda dalam semua hal penting. Karena itu, baca dokumen cakupan layanan sebelum membaca harganya. Jika Anda masih menentukan tujuan mesin tersebut, apa yang sebenarnya dapat Anda lakukan dengan VPS adalah pertanyaan yang sebaiknya dijawab terlebih dahulu.

Hal yang harus ditangani seseorang

Setiap server yang berjalan memiliki daftar tugas yang sama. Pada paket tanpa pengelolaan, daftar itu menjadi tanggung jawab Anda. Pada paket terkelola, Anda membayar agar beberapa tugas dalam daftar tersebut ditangani pihak lain. Periksa daftar berikut dan tuliskan nama penanggung jawab di samping setiap tugas.

• Patching sistem operasi dan reboot yang diperlukan oleh pembaruan kernel.
• Aturan firewall yang harus tetap benar saat Anda menambahkan dan menghapus layanan. Dasar-dasar firewall ufw untuk VPS membahas aturan awal.
• Akses SSH: pengelolaan key, penonaktifan login dengan password, pencabutan key ketika seseorang keluar, serta cara untuk kembali masuk ketika Anda terkunci di luar.
• Backup, salinan di lokasi lain, dan proses restore yang benar-benar pernah Anda lakukan.
• Monitoring, yang berarti memastikan server dapat dijangkau, disk masih memiliki ruang, layanan masih berjalan, dan sertifikat belum kedaluwarsa.
• Peninjauan log dan respons ketika ada sesuatu dalam log tersebut yang terlihat tidak benar.
• Konfigurasi layanan untuk web server, database, reverse proxy, dan queue jika Anda menggunakannya.
• Perpanjangan sertifikat dan perbaikan ketika perpanjangan otomatis berhenti berfungsi.
• Kapasitas, yang berarti mengetahui bahwa memori hampir habis sebelum out of memory (OOM) killer mendeteksinya untuk Anda.
• Respons insiden, yang berarti tetap siaga dan dapat dihubungi pada waktu yang tidak Anda tentukan sendiri.

Sebagian besar tugas tersebut bersifat rutin dan dapat diserahkan kepada script. Respons insiden berbeda karena memerlukan seseorang yang dapat mengambil keputusan. Itulah layanan utama yang dijual oleh paket terkelola. Karena itu, checklist di bagian bawah memusatkan sebagian besar pertanyaannya pada cakupan dukungan, bukan pada patching.

Hal-hal yang biasanya tidak termasuk dalam layanan terkelola

Di sinilah pembeli sering dirugikan, jadi pastikan rinciannya jelas. Kontrak layanan terkelola biasanya mencakup sistem operasi dan perangkat lunak yang dipasang oleh penyedia. Cakupannya berhenti pada batas aplikasi Anda.

Kode Anda sendiri adalah tanggung jawab Anda. Error 500 dari aplikasi Anda bukan kerusakan server. Penyedia akan mengonfirmasi bahwa proses server web sedang berjalan, lalu mengembalikan tiket tersebut kepada Anda. Batas tanggung jawab ini wajar. Namun, ini juga merupakan kesenjangan terbesar antara harapan pembeli dan layanan yang sebenarnya dibeli.

Masalah pada tingkat aplikasi biasanya tidak termasuk dalam cakupan. Kueri database yang lambat, plugin yang rusak setelah pembaruan, cache yang salah dikonfigurasi, atau antrean email yang berhenti diproses: semua ini berada di luar cakupan, meskipun penyedia memasang perangkat lunak yang mendasarinya.

Sebagian besar pemulihan data tidak termasuk dalam cakupan. Cadangan penyedia melindungi citra seluruh server menurut penyedia dan ditujukan untuk menangani kegagalan perangkat keras host. Cadangan tersebut jarang dirancang untuk menangani situasi ketika Anda menghapus satu baris, menjalankan migrasi yang salah, atau merusak file enam minggu lalu dan baru menyadarinya hari ini. Tanyakan durasi retensi, apakah satu file dapat dipulihkan, dan siapa yang menjalankan pemulihan.

Perangkat lunak yang Anda pasang adalah tanggung jawab Anda. Jika Anda memasang Docker, penyedia umumnya bertanggung jawab atas host, sedangkan Anda bertanggung jawab atas semua hal di dalam container.

Perubahan konfigurasi secara manual dapat membatalkan dukungan. Beberapa kontrak mengeluarkan suatu komponen dari cakupan setelah pelanggan mengubah konfigurasinya secara langsung. Tanyakan hal ini jika Anda berencana menyesuaikan konfigurasi apa pun.

Nilai waktu Anda berdasarkan selisih bulanan

Bandingkan kedua penawaran di depan Anda, lalu catat selisih bulanannya. Angka itu adalah biaya yang dikenakan provider untuk menghapus item-item dari daftar di atas. Sekarang, tentukan nilai dari sisi Anda dalam pertukaran ini.

• Berapa nilai satu jam waktu Anda, dan berapa jam per bulan yang diperlukan daftar tersebut setelah diotomatisasi?
• Berapa biaya satu jam downtime bagi layanan yang berjalan di server ini?

Server Ubuntu yang stabil, dengan pembaruan otomatis dan monitoring eksternal, memerlukan sangat sedikit perhatian rutin. Pada sebagian besar bulan, server tersebut tidak memerlukan perhatian sama sekali. Pekerjaan rutin menjadi murah setelah ditangani oleh script. Interupsi adalah bagian yang mahal, dan managed plan menjual penanganan interupsi tersebut. Jika server menjalankan proyek hobi, outage tidak menimbulkan biaya dan unmanaged adalah pilihan yang jelas. Jika server menerima pesanan, pertimbangkan dengan saksama apakah support contract benar-benar mempersingkat outage, karena managed provider tetap harus membaca ticket Anda, mereproduksi masalah, lalu menanganinya.

Selisih tersebut juga meningkat seiring jumlah server. Managed fee biasanya dikenakan per server, sedangkan automation ditulis sekali lalu disalin. Server kedua mengurangi separuh biaya efektif script yang Anda tulis untuk server pertama. Karena itu, baca cara mengelola beberapa server Linux sebelum berkomitmen pada biaya per server. Untuk angka dasar di kedua sisi perbandingan, biaya VPS sebenarnya per bulan menetapkan batas bawah, dan perbandingan VPS dengan dedicated server menjadi penting setelah workload cukup besar sehingga biaya premium managed hanya menjadi pembulatan kecil.

Pertanyaan yang perlu diajukan kepada host sebelum membayar layanan premium terkelola

Ajukan pertanyaan sebelum membayar, dan minta jawabannya secara tertulis. Halaman penjualan bukan dokumen cakupan layanan.

1. Apa saja yang termasuk dalam cakupan layanan, tugas demi tugas? Minta daftarnya, bukan brosur.
2. Apakah dukungan mencakup perangkat lunak yang saya instal, atau hanya perangkat lunak yang Anda instal?
3. Apakah Anda memasang patch secara otomatis, dan apakah Anda melakukan reboot untuk pembaruan kernel tanpa meminta persetujuan saya terlebih dahulu?
4. Siapa yang bertanggung jawab jika patch yang Anda terapkan merusak aplikasi saya?
5. Apakah Anda membuat backup? Di mana backup tersebut disimpan, berapa lama disimpan, dan siapa yang melakukan pemulihan?
6. Apakah Anda baru-baru ini pernah memulihkan server pelanggan, dan berapa lama prosesnya?
7. Berapa lama waktu respons tiket, dan apakah waktunya berbeda pada hari Minggu pukul 03:00?
8. Apakah saya tetap memiliki akses root, dan apakah penggunaannya mengurangi cakupan dukungan yang Anda berikan?
9. Apakah biaya dikenakan per server atau per akun?
10. Jika saya berhenti menggunakan layanan Anda, apa yang dapat saya bawa? Konfigurasi yang berada di dalam control panel proprietari dapat sulit diekspor.

Pertanyaan 5 menentukan sebagian besar jawaban atas pertanyaan lainnya. Host yang menjawabnya secara terperinci menunjukkan bahwa mereka pernah melakukannya. Jawaban yang tidak jelas berarti pemulihan belum pernah diuji, dan backup yang belum diuji hanyalah salinan. Pertanyaan 5 juga memiliki aspek lokasi: tempat salinan disimpan secara fisik merupakan persoalan hukum sekaligus teknis, dan hal yang sebenarnya penting saat memilih negara hosting membahasnya.

Jalur tengah: unmanaged plus automation

Sebagian besar pembaca teknis tidak menginginkan salah satu ekstrem. Mereka menginginkan paket unmanaged dengan pekerjaan rutin yang diserahkan kepada mesin, sementara perhatian mereka digunakan untuk hal-hal yang tidak dapat dinilai oleh mesin. Siapkan semuanya pada hari pertama. Sepuluh menit pertama pada VPS baru adalah titik awal praktis bagi siapa pun yang memilih unmanaged, dan memperkuat akses SSH juga harus dilakukan dalam sesi pertama tersebut.

Pembaruan keamanan otomatis

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 tersebut sekarang harus berisi APT::Periodic::Update-Package-Lists "1"; dan APT::Periodic::Unattended-Upgrade "1";. File yang tidak ada, atau 0 pada salah satu baris, berarti tidak ada proses yang berjalan dan Anda tidak akan menerima pemberitahuan.

Uji tanpa mengubah sistem. Perhatikan bahwa nama paketnya adalah unattended-upgrades, sedangkan perintahnya berbentuk tunggal:

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

Output mencantumkan setiap paket yang diperiksa dan diakhiri dengan baris seperti No packages found that can be upgraded unattended jika tidak ada pembaruan yang tertunda. Eksekusi nyata dicatat di /var/log/unattended-upgrades/unattended-upgrades.log, jadi periksa file tersebut dan jangan menebak.

Pembaruan kernel tidak mengubah apa pun sampai mesin melakukan reboot, karena kernel yang sedang berjalan adalah kernel yang dimuat saat boot. File /var/run/reboot-required muncul jika reboot tertunda. Pantau file tersebut, atau biarkan mesin menanganinya di /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" menunda reboot saat seseorang sedang login. Ini lebih aman pada mesin yang Anda gunakan secara interaktif, tetapi tidak berguna pada mesin yang tidak pernah digunakan untuk login. Konfigurasi lengkap unattended upgrades di Ubuntu membahas sintaks blocklist dan opsi email.

Pemantauan yang berjalan di tempat lain

Monitor yang berjalan di server tidak dapat memberi tahu Anda bahwa server sedang down, karena monitor tersebut juga ikut down. Jalankan pemeriksaan pada host kedua atau layanan eksternal. Uptime Kuma untuk pemantauan status adalah pilihan self-hosted yang umum, dan harus ditempatkan pada mesin yang berbeda dari mesin yang dipantaunya.

Pantau setidaknya empat hal: keterjangkauan, penggunaan disk, apakah aplikasi merespons pada port sebenarnya, dan masa berlaku sertifikat. Disk adalah hal yang sering terlewat. File log atau database yang bertambah sedikit setiap hari dapat membuat mesin down pada saat yang tidak diperkirakan oleh indikator lain. Gejala pertama sering berupa layanan yang tidak dapat menulis lalu berhenti.

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

Tambahkan juga heartbeat. Timer pada server memanggil URL setelah setiap backup atau pemeriksaan kesehatan berhasil, lalu monitor memberi peringatan jika panggilan tersebut berhenti diterima. Dengan demikian, server yang tidak merespons dapat memicu peringatan secara otomatis. Pemeriksaan yang hanya melakukan pull tidak dapat melakukannya jika jalur jaringan adalah bagian yang rusak.

Backup yang setidaknya pernah dipulihkan sekali

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 mencetak created restic repository <id> at sftp:... satu kali. Menjalankannya pada repository yang sudah ada akan gagal, bukan menimpa isinya. Inilah perilaku yang diinginkan. Simpan salinan passphrase tersebut di luar server. Repository tidak dapat dibaca tanpanya dan tidak ada cara pemulihan.

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 harus mencantumkan proses yang baru saja Anda jalankan dengan tanggal hari ini. restic check memverifikasi struktur repository dan mencetak no errors were found. Sekarang lakukan bagian yang paling sering dilewati:

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

File yang Anda harapkan ada atau tidak ada. Mengetahuinya sekarang hanya memerlukan waktu sepuluh menit. Setelah itu, jadwalkan proses tersebut dengan timer agar tidak bergantung pada Anda. Tulis /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

Kemudian /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 menampilkan proses berikutnya dan sisa waktunya. Hasil kosong berarti Anda mengaktifkan service, bukan timer. Ini adalah kesalahan yang paling umum pada tahap ini. Persistent=true menjalankan job yang terlewat setelah boot berikutnya, sehingga mesin yang mati semalaman tetap mendapatkan backup. Backup Restic pada VPS membahas tata letak dan retensi repository secara lebih mendalam, sedangkan service dan timer systemd menjelaskan file unit baris demi baris.

Hal yang tidak diberikan oleh automation

Automation tidak memberikan penilaian. Reboot otomatis pada 02:00 terjadi terlepas dari apakah aplikasi kembali berjalan dengan benar. Karena itu, pastikan setiap service dapat berjalan sendiri, lalu lakukan reboot dengan sengaja saat Anda masih terjaga:

systemctl is-enabled nginx docker
sudo reboot

Unattended upgrade juga dapat memasang paket yang merusak aplikasi, dan tidak ada bagian dalam pipeline yang mengetahui bahwa hal tersebut terjadi. Monitor Anda yang mendeteksinya. Karena itu, monitor tidak bersifat opsional setelah pembaruan dibuat otomatis. Mesin menangani pekerjaan rutin. Penanganan insiden tetap menjadi tanggung jawab Anda.

Kapan layanan terkelola sepadan dengan biayanya

Pertimbangkan layanan terkelola secara objektif. Empat situasi berikut membuatnya layak dipilih.

• Tidak ada anggota tim yang mengelola Linux, dan Anda tidak berencana mempekerjakan seseorang untuk melakukannya.
• Persyaratan kepatuhan menetapkan pihak yang bertanggung jawab untuk menerapkan patch, dan pihak tersebut tidak boleh Anda.
• Stack yang digunakan merupakan stack yang menjadi keahlian penyedia, sehingga tim dukungannya pernah menangani kegagalan seperti yang Anda alami.
• Orang yang seharusnya melakukan pekerjaan tersebut adalah karyawan Anda yang paling mahal, dan biaya satu jam kerjanya lebih besar daripada biaya layanan premium selama sebulan.

Layanan terkelola tidak otomatis lebih aman. Paket terkelola memang menerapkan patch lebih cepat daripada pemilik yang lalai, dan itu merupakan keuntungan nyata. Penyedia juga sering memasang control panel, yaitu aplikasi besar yang menghadap jaringan, memiliki halaman login, serta riwayat kerentanannya sendiri. Pertukaran tersebut dapat masuk akal, tetapi tetap merupakan suatu pertukaran.

Keputusannya selalu bergantung pada daftar yang sama. Tuliskan sepuluh tugas tersebut, tandai pihak yang bertanggung jawab atas masing-masing tugas dalam setiap penawaran, lalu bandingkan selisihnya dengan nilai satu jam perhatian Anda. Sebagian besar pembaca teknis yang melakukan hal ini akhirnya memilih layanan unmanaged dan menyerahkan tugas rutin kepada timer. Itu merupakan pilihan yang dapat dipertanggungjawabkan, bukan sekadar pilihan yang murah.

FAQ

Apa perbedaan antara VPS terkelola dan VPS tidak terkelola?

VPS tidak terkelola hanya menyediakan mesin tanpa layanan lain. Anda bertanggung jawab atas patch, firewall, pencadangan, pemantauan, dan reboot setelah pembaruan kernel. VPS terkelola mengalihkan sebagian pekerjaan tersebut kepada penyedia, biasanya pada lapisan sistem operasi dan perangkat lunak yang mereka instal untuk Anda. Batas tanggung jawab yang tepat ditentukan oleh masing-masing penyedia, bukan oleh istilahnya. Karena itu, minta cakupan setiap tugas secara tertulis sebelum membandingkan dua harga.

Apakah VPS terkelola berarti saya tidak memerlukan pencadangan sendiri?

Tidak. Pencadangan penyedia biasanya melindungi image seluruh server milik penyedia dan digunakan jika host mengalami kegagalan. Pencadangan tersebut jarang membantu ketika Anda menghapus file, menjalankan migrasi yang salah, atau merusak data beberapa minggu lalu dan baru menyadarinya hari ini. Tanyakan berapa lama snapshot disimpan, apakah satu file dapat dipulihkan, dan siapa yang melakukan pemulihan. Kemudian simpan salinan offsite Anda sendiri menggunakan alat seperti restic, dan uji dengan restic restore latest --target /tmp/restore-check agar Anda mengetahui bahwa pencadangan tersebut berfungsi.

Apakah VPS terkelola lebih aman daripada VPS tidak terkelola?

Tidak secara otomatis. Paket terkelola menerapkan patch lebih cepat daripada pemilik yang tidak pernah login, sehingga benar-benar mengurangi risiko. Banyak paket terkelola juga memasang control panel. Panel adalah aplikasi besar yang menghadap jaringan, dengan halaman login dan riwayat kerentanannya sendiri. Server tidak terkelola dengan pembaruan keamanan otomatis, firewall tertutup, SSH yang hanya menggunakan key, dan tanpa layanan tambahan yang listening, merupakan target yang lebih kecil daripada server terkelola yang menjalankan panel.

Dapatkah saya memulai dengan layanan tidak terkelola lalu beralih ke layanan terkelola?

Biasanya bisa, meskipun prosesnya jarang hanya berupa satu checkbox. Penyedia biasanya mengaudit atau membangun ulang server sebelum mengambil tanggung jawab atasnya, karena mereka tidak akan mendukung konfigurasi yang tidak dapat mereka lihat. Tanyakan apa saja yang tercakup dalam onboarding, apakah proses tersebut memerlukan instalasi ulang, dan apakah konfigurasi yang Anda buat sendiri tetap berada di luar cakupan setelahnya.

Apakah saya tetap memiliki akses root pada VPS terkelola?

Pada sebagian besar paket VPS terkelola, Anda tetap memilikinya. Namun, akses root dan cakupan dukungan saling berkaitan. Beberapa penyedia mengurangi atau membatalkan dukungan untuk komponen yang Anda edit secara manual. Sebagian lainnya akan membangun ulang server dari template mereka sendiri jika suatu tiket dukungan memerlukan penanganan mendalam. Dapatkan ketentuan tersebut secara tertulis sebelum menyesuaikan apa pun. Simpan juga file konfigurasi Anda dalam version control agar proses pembangunan ulang memerlukan waktu satu jam, bukan satu akhir pekan.