VPS แบบมีการจัดการหรือไม่: แบบไหนเหมาะกับคุณ

VPS แบบมีการจัดการเทียบกับ VPS แบบไม่มีการจัดการ: คำตอบโดยย่อ

การเลือกระหว่าง VPS แบบมีการจัดการกับ VPS แบบไม่มีการจัดการเป็นเรื่องของภาระงาน ไม่ใช่เรื่องของผลิตภัณฑ์ VPS แบบไม่มีการจัดการหมายความว่าคุณต้องรับผิดชอบการติดตั้งแพตช์ ไฟร์วอลล์ การสำรองข้อมูล การตรวจสอบระบบ และการรีบูตเวลา 2am ด้วยตนเอง VPS แบบมีการจัดการหมายความว่าผู้ให้บริการดำเนินการบางส่วนให้คุณ โดยขอบเขตงานดังกล่าวแตกต่างกันอย่างมากในแต่ละผู้ให้บริการ การเปรียบเทียบที่มีประโยชน์เพียงอย่างเดียวคือการตรวจสอบรายการงานที่แต่ละแพ็กเกจช่วยนำออกจากความรับผิดชอบของคุณ แล้วเปรียบเทียบกับราคาตามจำนวนชั่วโมงที่คุณต้องใช้ดำเนินการเอง

ไม่มีคำจำกัดความมาตรฐานสำหรับคำว่า มีการจัดการ ผู้ให้บริการรายหนึ่งอาจหมายถึงการติดตั้งแพตช์ให้ operating system และมีเจ้าหน้าที่ตอบ ticket ผู้ให้บริการอีกรายอาจหมายถึงเพียงติดตั้ง control panel แล้วงานทุกอย่างที่อยู่เหนือ control panel เป็นความรับผิดชอบของคุณ ส่วนผู้ให้บริการรายที่สามอาจหมายถึงสัญญาบริการที่เป็นลายลักษณ์อักษรและระบุระยะเวลาตอบกลับไว้ แพ็กเกจ 2 รายการที่ใช้คำเดียวกันอาจแตกต่างกันในทุกด้านที่สำคัญ ดังนั้นให้อ่านเอกสารขอบเขตบริการก่อนพิจารณาราคา หากคุณยังไม่แน่ใจด้วยซ้ำว่าเครื่องนี้มีไว้เพื่ออะไร คำถามที่ควรหาคำตอบก่อนคือ คุณสามารถทำอะไรกับ VPS ได้จริงบ้าง

ผู้ที่ต้องรับผิดชอบงานเหล่านี้

เซิร์ฟเวอร์ที่กำลังทำงานทุกเครื่องมีรายการงานชุดเดียวกัน แผนแบบไม่จัดการทำให้รายการนี้เป็นความรับผิดชอบของคุณ ส่วนแผนแบบจัดการคือการจ่ายเงินเพื่อให้มีผู้รับผิดชอบงานบางรายการแทนคุณ ตรวจสอบรายการตั้งแต่ต้นจนจบ และเขียนชื่อผู้รับผิดชอบไว้ข้างแต่ละรายการ

• การติดตั้งแพตช์ระบบปฏิบัติการ รวมถึงการ reboot ที่ kernel updates จำเป็นต้องใช้
• กฎ firewall ซึ่งต้องปรับให้ถูกต้องเมื่อคุณเพิ่มหรือลบบริการ พื้นฐาน firewall ufw สำหรับ VPS อธิบาย ruleset เริ่มต้น
• การเข้าถึง SSH: การจัดการ key, การปิดใช้งานการเข้าสู่ระบบด้วยรหัสผ่าน, การเพิกถอน key เมื่อมีผู้พ้นจากทีม และวิธีเข้าถึงระบบอีกครั้งเมื่อคุณล็อกตัวเองออกจากระบบ
• การสำรองข้อมูล, สำเนาที่เก็บไว้นอกสถานที่ และการกู้คืนข้อมูลที่คุณเคยดำเนินการจริง
• การตรวจสอบระบบ ซึ่งหมายถึงการทราบว่าเครื่องยังเข้าถึงได้, ดิสก์ยังมีพื้นที่, บริการยังทำงานอยู่ และ certificate ยังไม่หมดอายุ
• การตรวจสอบ log และการตอบสนองเมื่อพบสิ่งผิดปกติใน log เหล่านั้น
• การกำหนดค่าบริการสำหรับ web server, database, reverse proxy และ queue หากคุณใช้งาน
• การต่ออายุ certificate และการแก้ไขเมื่อการต่ออายุอัตโนมัติหยุดทำงาน
• ความจุ ซึ่งหมายถึงการสังเกตว่าหน่วยความจำใกล้เต็มก่อนที่ out of memory (OOM) killer จะตรวจพบแทนคุณ
• การตอบสนองต่อเหตุการณ์ ซึ่งหมายถึงการตื่นและพร้อมให้ติดต่อได้ในเวลาที่คุณไม่ได้เป็นผู้เลือก

งานส่วนใหญ่เป็นงานประจำและมอบหมายให้ script ดำเนินการได้ แต่การตอบสนองต่อเหตุการณ์เป็นงานที่มอบหมายให้ script ไม่ได้ เพราะต้องมีบุคคลที่สามารถตัดสินใจได้ นี่คือบริการที่แท้จริงของแผนแบบจัดการ ดังนั้น checklist ในส่วนถัดไปจึงเน้นคำถามเกี่ยวกับขอบเขตการสนับสนุนมากกว่าการติดตั้งแพตช์

สิ่งที่บริการจัดการมักไม่ครอบคลุม

ประเด็นนี้ทำให้ผู้ซื้อเสียเปรียบได้ จึงต้องตรวจสอบให้ชัดเจน สัญญาบริการจัดการโดยปกติครอบคลุมระบบปฏิบัติการและซอฟต์แวร์ที่ผู้ให้บริการติดตั้ง การดูแลจะสิ้นสุดที่ขอบเขตของแอปพลิเคชันของคุณ

โค้ดของคุณเป็นความรับผิดชอบของคุณ ข้อผิดพลาด 500 ที่เกิดจากแอปพลิเคชันไม่ใช่ปัญหาของเซิร์ฟเวอร์ ผู้ให้บริการจะตรวจสอบว่ากระบวนการของเว็บเซิร์ฟเวอร์กำลังทำงาน แล้วส่ง ticket กลับมาให้คุณ ขอบเขตดังกล่าวถือว่าสมเหตุสมผล และยังเป็นช่องว่างที่ใหญ่ที่สุดระหว่างสิ่งที่ผู้ซื้อคาดหวังกับสิ่งที่ซื้อจริง

ปัญหาระดับแอปพลิเคชันมักไม่อยู่ในขอบเขตบริการ เช่น query ของฐานข้อมูลที่ทำงานช้า plugin ที่ทำงานผิดพลาดหลังการอัปเดต cache ที่ตั้งค่าไม่ถูกต้อง หรือ mail queue ที่หยุดระบายรายการ ปัญหาเหล่านี้อยู่เหนือขอบเขตดังกล่าว แม้ผู้ให้บริการจะเป็นผู้ติดตั้งซอฟต์แวร์ที่อยู่เบื้องหลังก็ตาม

การกู้คืนข้อมูลส่วนใหญ่มักไม่อยู่ในขอบเขตบริการ Backup ของผู้ให้บริการปกป้องภาพรวมของเซิร์ฟเวอร์ในมุมมองของผู้ให้บริการ และมีไว้สำหรับกรณีที่ฮาร์ดแวร์ของ host ขัดข้อง โดยทั่วไป Backup เหล่านี้ไม่ได้จัดทำมาเพื่อกรณีที่คุณลบแถวข้อมูล เรียกใช้ migration ที่มีปัญหา หรือทำให้ไฟล์เสียหายเมื่อ 6 สัปดาห์ก่อนแล้วเพิ่งตรวจพบในวันนี้ สอบถามว่าระยะเวลาเก็บรักษาคือเท่าใด สามารถดึงไฟล์เดียวออกมาได้หรือไม่ และใครเป็นผู้ดำเนินการ restore

ซอฟต์แวร์ที่คุณติดตั้งเป็นความรับผิดชอบของคุณ หากติดตั้ง Docker โดยทั่วไปผู้ให้บริการจะรับผิดชอบ host ส่วนคุณรับผิดชอบทุกสิ่งที่อยู่ภายใน container

การแก้ไขด้วยตนเองอาจทำให้สิทธิ์การสนับสนุนสิ้นสุดลง สัญญาบางฉบับจะนำ component ออกจากขอบเขตบริการทันทีที่ลูกค้าแก้ไข configuration ของ component นั้นโดยตรง หากคุณวางแผนจะปรับแต่งสิ่งใด ควรสอบถามเรื่องนี้ก่อน

ประเมินเวลาของคุณเทียบกับส่วนต่างรายเดือน

นำใบเสนอราคา 2 รายการที่อยู่ตรงหน้ามาเปรียบเทียบ แล้วจดส่วนต่างรายเดือน ตัวเลขนี้คือค่าบริการที่ผู้ให้บริการเรียกเก็บเพื่อจัดการรายการข้างต้นแทนคุณ จากนั้นกำหนดมูลค่าเวลาของคุณเองในการเปรียบเทียบนี้

• เวลาของคุณ 1 ชั่วโมงมีมูลค่าเท่าใด และรายการดังกล่าวใช้เวลากี่ชั่วโมงต่อเดือนหลังจากทำให้เป็นอัตโนมัติแล้ว
• ระบบหรือบริการที่ทำงานบน server นี้มีค่าเสียหายจาก downtime 1 ชั่วโมงเท่าใด

Ubuntu ที่ทำงานอย่างเสถียรและเปิดใช้ automatic updates พร้อม external monitoring ต้องการการดูแลตามปกติเพียงเล็กน้อย ส่วนใหญ่ไม่ต้องดำเนินการใดเลยในแต่ละเดือน งานตามปกติมีต้นทุนต่ำเมื่อ script เป็นผู้จัดการงานเหล่านั้น การหยุดชะงักเป็นส่วนที่มีค่าใช้จ่ายสูง และ managed plan ให้บริการเพื่อจัดการกับการหยุดชะงักดังกล่าว หาก server ใช้สำหรับโครงการงานอดิเรก outage ก็ไม่ก่อให้เกิดค่าเสียหาย ดังนั้น unmanaged จึงเป็นตัวเลือกที่ชัดเจน หาก server ใช้รับคำสั่งซื้อ ให้พิจารณาอย่างรอบคอบว่าสัญญา support ช่วยลดระยะเวลา outage ได้จริงหรือไม่ เพราะ managed provider ยังคงต้องอ่าน ticket ของคุณ ทำให้เกิดปัญหาซ้ำ และดำเนินการแก้ไข

ส่วนต่างนี้ยังเพิ่มขึ้นตามจำนวน server ด้วย โดยทั่วไป managed fee จะคิดตามจำนวน server ขณะที่เขียน automation เพียงครั้งเดียวแล้วคัดลอกไปใช้ได้ server เครื่องที่ 2 ทำให้ต้นทุนที่แท้จริงของ script ที่เขียนสำหรับเครื่องแรกเหลือครึ่งหนึ่ง ดังนั้นควรอ่าน วิธีจัดการ Linux server หลายเครื่อง ก่อนตัดสินใจจ่ายค่าบริการตามจำนวน server สำหรับตัวเลขพื้นฐานของทั้ง 2 ทางเลือกในการเปรียบเทียบ VPS มีค่าใช้จ่ายจริงต่อเดือนเท่าใด เป็นค่าใช้จ่ายขั้นต่ำ และ ข้อแลกเปลี่ยนระหว่าง VPS กับ dedicated server จะมีความสำคัญเมื่อ workload มีขนาดใหญ่พอจน managed premium กลายเป็นเพียงค่าคลาดเคลื่อนจากการปัดเศษ

คำถามที่ควรถามผู้ให้บริการโฮสต์ก่อนชำระค่าบริการแบบมีการจัดการระดับพรีเมียม

สอบถามก่อนชำระเงิน และขอคำตอบเป็นลายลักษณ์อักษร หน้าเสนอขายไม่ใช่เอกสารขอบเขตงาน

1. งานใดอยู่ในขอบเขตบริการ โดยแจกแจงเป็นรายงาน ขอรายการงาน ไม่ใช่เอกสารโฆษณา
2. บริการสนับสนุนครอบคลุมซอฟต์แวร์ที่ฉันติดตั้งเองหรือไม่ หรือครอบคลุมเฉพาะซอฟต์แวร์ที่คุณติดตั้ง
3. คุณติดตั้งแพตช์โดยอัตโนมัติหรือไม่ และจะ reboot เพื่ออัปเดต kernel โดยไม่ขออนุญาตฉันล่วงหน้าหรือไม่
4. ใครรับผิดชอบหากแพตช์ที่คุณติดตั้งทำให้แอปพลิเคชันของฉันทำงานผิดพลาด
5. คุณสำรองข้อมูลหรือไม่ จัดเก็บข้อมูลสำรองไว้ที่ใด เก็บไว้นานเท่าใด และใครเป็นผู้กู้คืนข้อมูล
6. เมื่อไม่นานมานี้ คุณเคยกู้คืนเซิร์ฟเวอร์ของลูกค้าหรือไม่ และใช้เวลานานเท่าใด
7. ระยะเวลาตอบกลับ ticket คือเท่าใด และแตกต่างกันหรือไม่หากเป็นเวลา 03:00 ของวันอาทิตย์
8. ฉันยังคงมีสิทธิ์เข้าถึง root หรือไม่ และการใช้สิทธิ์ดังกล่าวทำให้ขอบเขตการสนับสนุนที่คุณให้ลดลงหรือไม่
9. ค่าบริการคิดต่อเซิร์ฟเวอร์หรือต่อบัญชี
10. หากฉันยกเลิกบริการ ฉันนำสิ่งใดติดตัวไปได้บ้าง ระบบที่อยู่ภายในแผงควบคุมเฉพาะของผู้ให้บริการอาจส่งออกได้ยาก

คำถามข้อ 5 เป็นตัวกำหนดคำตอบของคำถามข้ออื่น ๆ ส่วนใหญ่ ผู้ให้บริการโฮสต์ที่ตอบคำถามนี้ได้อย่างชัดเจนกำลังบอกคุณว่าเคยดำเนินการดังกล่าวมาก่อน คำตอบที่คลุมเครือหมายความว่ายังไม่เคยทดสอบการกู้คืนข้อมูล และข้อมูลสำรองที่ยังไม่เคยทดสอบก็เป็นเพียงสำเนาเท่านั้น คำถามข้อ 5 ยังมีประเด็นด้านสถานที่จัดเก็บด้วย สถานที่ที่สำเนาถูกจัดเก็บไว้จริงเป็นประเด็นทางกฎหมายพอ ๆ กับเป็นประเด็นทางเทคนิค และ สิ่งที่สำคัญจริง ๆ เมื่อเลือกประเทศสำหรับบริการโฮสติ้ง อธิบายเรื่องนี้ไว้.

แนวทางตรงกลาง: แผน unmanaged พร้อมระบบอัตโนมัติ

ผู้อ่านด้านเทคนิคส่วนใหญ่ไม่ต้องการสุดโต่งด้านใดด้านหนึ่ง พวกเขาต้องการแผน 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 ในบรรทัดใดบรรทัดหนึ่ง แสดงว่าจะไม่มีการทำงานใดเกิดขึ้นและคุณจะไม่ได้รับการแจ้งเตือน

ทดสอบโดยไม่เปลี่ยนแปลงระบบ โปรดสังเกตว่าแพ็กเกจคือ unattended-upgrades แต่คำสั่งเป็นรูปเอกพจน์:

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

ผลลัพธ์จะแสดงแพ็กเกจทั้งหมดที่ระบบตรวจสอบ และจบด้วยบรรทัดลักษณะ No packages found that can be upgraded unattended เมื่อไม่มีรายการที่รอดำเนินการ การทำงานจริงจะถูกเขียนลงใน /var/log/unattended-upgrades/unattended-upgrades.log ดังนั้นให้ตรวจสอบที่นั่นแทนการคาดเดา

การอัปเดต kernel จะไม่ส่งผลจนกว่าเครื่องจะ reboot เนื่องจาก kernel ที่กำลังทำงานคือ kernel ที่โหลดเมื่อ boot ไฟล์ /var/run/reboot-required จะปรากฏขึ้นเมื่อมี reboot ที่รอดำเนินการ คุณอาจตรวจสอบไฟล์นี้ หรือให้เครื่องจัดการโดยใช้ /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" จะเลื่อนการ reboot ออกไปขณะที่มีผู้เข้าสู่ระบบอยู่ ซึ่งปลอดภัยกว่าบนเครื่องที่คุณใช้งานแบบโต้ตอบ และไม่มีประโยชน์บนเครื่องที่ไม่มีผู้เข้าสู่ระบบ การตั้งค่า unattended upgrades บน Ubuntu แบบครบถ้วน อธิบายไวยากรณ์ของ blocklist และตัวเลือกอีเมลเพิ่มเติม

การตรวจสอบที่ทำงานบนเครื่องอื่น

ระบบ monitor ที่ทำงานบนเซิร์ฟเวอร์ไม่สามารถแจ้งได้ว่าเซิร์ฟเวอร์ล่ม เพราะระบบดังกล่าวก็ล่มด้วยเช่นกัน ให้ย้ายการตรวจสอบไปยังโฮสต์เครื่องที่สองหรือบริการภายนอก Uptime Kuma สำหรับการตรวจสอบสถานะ เป็นตัวเลือกแบบ self-hosted ที่ใช้กันทั่วไป และควรติดตั้งบนเครื่องอื่นที่ไม่ใช่เครื่องที่กำลังตรวจสอบ

อย่างน้อยควรตรวจสอบ 4 รายการ ได้แก่ การเข้าถึงได้ การใช้พื้นที่ดิสก์ การตอบสนองของแอปพลิเคชันบนพอร์ตจริง และวันหมดอายุของ certificate ดิสก์เป็นรายการที่มักสร้างปัญหา ไฟล์ log หรือฐานข้อมูลที่เพิ่มขนาดขึ้นเล็กน้อยทุกวันอาจทำให้เครื่องหยุดทำงานในเวลาที่สิ่งอื่นไม่สามารถคาดการณ์ได้ และอาการแรกมักเป็น service ที่เขียนข้อมูลไม่ได้แล้วหยุดทำงาน

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

ควรเพิ่ม heartbeat ด้วย timer บนเซิร์ฟเวอร์จะเรียก URL หลังจากการ backup หรือ health check สำเร็จแต่ละครั้ง และ monitor จะแจ้งเตือนเมื่อไม่มีการเรียกดังกล่าวเข้ามาอีก เซิร์ฟเวอร์ที่หยุดส่งสัญญาณจึงทำให้เกิดการแจ้งเตือนได้เอง ซึ่งการตรวจสอบแบบ pull-only ไม่สามารถทำได้เมื่อเส้นทาง network เป็นสิ่งที่ขัดข้อง

Backup ที่คุณเคยกู้คืนอย่างน้อย 1 ครั้ง

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:... 1 ครั้ง การเรียกใช้กับ repository ที่มีอยู่แล้วจะล้มเหลวแทนการเขียนทับ ซึ่งเป็นพฤติกรรมที่ต้องการ เก็บสำเนา passphrase ดังกล่าวไว้นอกเซิร์ฟเวอร์ เพราะจะอ่าน repository ไม่ได้หากไม่มี passphrase และไม่มีวิธีกู้คืน

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 ควรแสดงรายการ run ที่คุณเพิ่งทำพร้อมวันที่ของวันนี้ restic check จะตรวจสอบโครงสร้าง repository และแสดง no errors were found ตอนนี้ให้ทำขั้นตอนที่คนส่วนใหญ่มักข้าม:

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

ไฟล์ที่คุณคาดว่าจะมีจะอยู่ที่นั่นหรือไม่ก็ไม่มี และการตรวจสอบให้ทราบตอนนี้ใช้เวลา 10 นาที จากนั้นตั้งค่าให้ 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 ถัดไปและเวลาที่เหลือ หากไม่มีผลลัพธ์ หมายความว่าคุณเปิดใช้ service แทน timer ซึ่งเป็นข้อผิดพลาดที่พบบ่อยที่สุดในขั้นตอนนี้ Persistent=true จะเรียกใช้ job ที่พลาดไปหลัง boot ครั้งถัดไป ดังนั้นเครื่องที่ปิดอยู่ตลอดคืนก็ยังจะทำ backup ได้ Backup ด้วย Restic บน VPS อธิบายโครงสร้าง repository และการเก็บรักษาเพิ่มเติม และ services และ timers ของ systemd อธิบายไฟล์ unit ทีละบรรทัด

สิ่งที่ระบบอัตโนมัติไม่สามารถทดแทนได้

ระบบอัตโนมัติไม่สามารถทดแทนการใช้วิจารณญาณได้ การ reboot อัตโนมัติเวลา 02:00 จะเกิดขึ้นไม่ว่าแอปพลิเคชันของคุณจะกลับมาทำงานได้อย่างถูกต้องหรือไม่ ดังนั้นให้ยืนยันว่าแต่ละ service เริ่มทำงานได้เอง แล้วจึง reboot โดยตั้งใจในช่วงที่คุณยังตื่นอยู่:

systemctl is-enabled nginx docker
sudo reboot

unattended upgrade อาจติดตั้งแพ็กเกจที่ทำให้แอปพลิเคชันเสียหายได้ และไม่มีส่วนใดใน pipeline ที่ทราบว่าเหตุการณ์ดังกล่าวเกิดขึ้น monitor ของคุณเป็นสิ่งที่ตรวจพบปัญหานี้ นี่คือเหตุผลที่ monitor ไม่ใช่สิ่งที่เลือกตัดออกได้เมื่อการอัปเดตทำงานโดยอัตโนมัติ เครื่องจะจัดการงานประจำให้ ส่วน incident ยังคงเป็นความรับผิดชอบของคุณ

เมื่อบริการแบบ managed คุ้มค่าใช้จ่าย

ควรพิจารณาบริการแบบ managed อย่างเป็นธรรม มี 4 สถานการณ์ที่ทำให้บริการนี้เป็นตัวเลือกที่เหมาะสม

• ไม่มีบุคลากรในทีมที่ดูแล Linux ได้ และไม่มีแผนที่จะจ้างบุคลากรเพิ่มเติม
• ข้อกำหนดด้าน compliance ระบุผู้รับผิดชอบการติดตั้ง patch และผู้รับผิดชอบนั้นไม่สามารถเป็นคุณได้
• stack เป็นระบบที่ผู้ให้บริการมีความเชี่ยวชาญโดยตรง จึงมีประสบการณ์แก้ไขปัญหาลักษณะเดียวกับความล้มเหลวของคุณมาก่อน
• บุคลากรที่ต้องรับผิดชอบงานนี้หากไม่ใช้บริการ managed เป็นพนักงานที่มีต้นทุนสูงที่สุดของคุณ และค่าใช้จ่ายสำหรับเวลาทำงาน 1 ชั่วโมงของบุคลากรนั้นสูงกว่าค่าบริการ premium 1 เดือน

บริการแบบ managed ไม่ได้ปลอดภัยกว่าโดยอัตโนมัติ แผนแบบ managed ติดตั้ง patch ได้เร็วกว่าเจ้าของระบบที่ไม่ใส่ใจ และนี่เป็นข้อได้เปรียบที่เกิดขึ้นจริง แต่บริการเหล่านี้มักติดตั้ง control panel ด้วย ซึ่งเป็นแอปพลิเคชันขนาดใหญ่ที่เชื่อมต่อกับเครือข่ายและมีหน้า login รวมถึงมีประวัติช่องโหว่ของตนเอง การแลกเปลี่ยนนี้อาจสมเหตุสมผล แต่ก็ยังเป็นการแลกเปลี่ยน

การตัดสินใจพิจารณาจากรายการเดิมทุกครั้ง ให้เขียนงานทั้ง 10 รายการลงมา ระบุว่าใครเป็นผู้รับผิดชอบแต่ละรายการภายใต้ข้อเสนอราคาแต่ละรายการ แล้วเปรียบเทียบส่วนต่างกับมูลค่าของเวลา 1 ชั่วโมงที่คุณต้องใช้เอง ผู้อ่านด้านเทคนิคส่วนใหญ่ที่ทำเช่นนั้นมักเลือกใช้บริการแบบ unmanaged แล้วมอบหมายงานประจำให้ timer ซึ่งเป็นคำตอบที่มีเหตุผล ไม่ใช่เพียงคำตอบที่มีราคาถูกกว่า

FAQ

VPS แบบมีผู้ดูแลและ VPS แบบไม่มีผู้ดูแลแตกต่างกันอย่างไร

VPS แบบไม่มีผู้ดูแลจะให้เฉพาะเครื่องแก่คุณ ดังนั้นคุณต้องรับผิดชอบการติดตั้งแพตช์, firewall, การสำรองข้อมูล, การตรวจสอบระบบ และการ reboot หลังจากอัปเดต kernel เอง VPS แบบมีผู้ดูแลจะโอนงานบางส่วนให้ผู้ให้บริการ โดยปกติคือการจัดการชั้นระบบปฏิบัติการและซอฟต์แวร์ที่ผู้ให้บริการติดตั้งให้ ขอบเขตที่แน่นอนขึ้นอยู่กับผู้ให้บริการแต่ละราย ไม่ได้กำหนดจากคำเรียกนี้เอง ดังนั้นควรขอขอบเขตความรับผิดชอบแยกตามงานเป็นลายลักษณ์อักษร ก่อนเปรียบเทียบราคาของผู้ให้บริการ 2 ราย

VPS แบบมีผู้ดูแลหมายความว่าฉันไม่ต้องสำรองข้อมูลเองใช่หรือไม่

ไม่ใช่ การสำรองข้อมูลของผู้ให้บริการมักปกป้อง image ของ server ทั้งเครื่องที่อยู่กับผู้ให้บริการ และมีไว้สำหรับกรณีที่ host ขัดข้อง การสำรองข้อมูลดังกล่าวมักไม่ช่วยเมื่อคุณลบไฟล์, ทำ migration ผิดพลาด หรือทำให้ข้อมูลเสียหายเมื่อหลายสัปดาห์ก่อนแล้วเพิ่งพบในวันนี้ ควรถามว่า snapshot เก็บไว้นานเท่าใด, สามารถกู้คืนไฟล์เดียวได้หรือไม่ และใครเป็นผู้ดำเนินการกู้คืน จากนั้นควรเก็บสำเนาของคุณเองไว้นอกสถานที่ด้วยเครื่องมือ เช่น restic และทดสอบด้วย restic restore latest --target /tmp/restore-check เพื่อให้ทราบว่าสำเนานั้นใช้งานได้

VPS แบบมีผู้ดูแลปลอดภัยกว่า VPS แบบไม่มีผู้ดูแลหรือไม่

ไม่ใช่โดยตัวมันเอง แผนแบบมีผู้ดูแลติดตั้งแพตช์ได้เร็วกว่าเจ้าของระบบที่ไม่เคยเข้าสู่ระบบ ซึ่งช่วยลดความเสี่ยงได้จริง แผนแบบมีผู้ดูแลจำนวนมากยังติดตั้ง control panel ด้วย และ control panel คือ application ขนาดใหญ่ที่เปิดให้เข้าถึงผ่าน network โดยมีหน้าเข้าสู่ระบบและประวัติช่องโหว่ของตนเอง VPS แบบไม่มีผู้ดูแลที่เปิด automatic security updates, ปิด firewall, ใช้ SSH แบบ key only และไม่มีบริการอื่นเปิดรับการเชื่อมต่อ จะเป็นเป้าหมายที่เล็กกว่า VPS แบบมีผู้ดูแลที่เปิดใช้ panel

ฉันเริ่มต้นด้วย VPS แบบไม่มีผู้ดูแลแล้วเปลี่ยนเป็นแบบมีผู้ดูแลภายหลังได้หรือไม่

โดยทั่วไปได้ แต่ไม่ใช่การเลือก checkbox เพียงรายการเดียว ผู้ให้บริการมักตรวจสอบหรือสร้าง server ใหม่ก่อนรับผิดชอบระบบ เนื่องจากจะไม่รองรับ configuration ที่ตรวจสอบไม่ได้ ควรถามว่าการเริ่มใช้บริการต้องดำเนินการอย่างไร, จำเป็นต้อง reinstall หรือไม่ และสิ่งที่คุณตั้งค่าเองจะยังอยู่นอกขอบเขตการรองรับภายหลังหรือไม่

ฉันยังคงเข้าถึง root บน VPS แบบมีผู้ดูแลได้หรือไม่

โดยส่วนใหญ่ยังเข้าถึงได้ แต่สิทธิ์ root และขอบเขตการรองรับมีความเกี่ยวข้องกัน ผู้ให้บริการบางรายจะลดหรือยกเลิกการรองรับ component ที่คุณแก้ไขด้วยตนเอง และบางรายจะสร้างระบบใหม่จาก template ของตนเองหากการตรวจสอบ ticket ดำเนินไปจนถึงระดับลึก ควรขอกฎดังกล่าวเป็นลายลักษณ์อักษรก่อนปรับแต่งสิ่งใด และเก็บ configuration files ไว้ใน version control เพื่อให้การสร้างระบบใหม่ใช้เวลาเพียง 1 ชั่วโมงแทนที่จะใช้เวลาตลอดสุดสัปดาห์