Cara VPS Medic memperbaiki server tanpa merusaknya: tangga keamanan dijelaskan

Setiap admin punya cerita tentang skrip "fix" yang reinstall paket, mereset config, atau menghapus log yang masih terbuka, lalu mengubah gangguan sepuluh menit menjadi semalaman. Itulah reputasi awal alat perbaikan otomatis mana pun, dan memang pantas. VPS Medic dibangun oleh orang yang bertahun-tahun membereskan sisa pola itu di server CyberPanel, jadi tugas pertama mesinnya bukan memperbaiki. Tugas pertamanya adalah tidak memperparah.

Satu tangga untuk setiap masalah

Apa pun gejalanya, mesin menaiki lima anak tangga yang sama, berurutan, dan aplikasi menunjukkan ia sedang di anak tangga mana.

1. Amati. Hanya perintah read-only: status systemctl, journalctl, log aplikasi, pemakaian disk dan inode, memori, uji config, integritas binary. Tidak ada yang berubah di server selama fase ini, dan Anda bisa menjalankannya sesering yang Anda mau.
2. Diagnosa. Bukti dicocokkan dengan penyebab yang dikenal untuk gejala itu, diurutkan dari paling umum. "lsws failed" saja tidak menentukan fix; "lsws failed + port 80 dipegang apache2" menentukan. Jika bukti tidak cocok dengan apa pun, mesin berhenti di sini dan melapor.
3. Perbaiki, paling ringan dulu. Perbaikan bertingkat. Level 1: start, enable, perbaiki permission, bersihkan cache. Level 2: edit atau pulihkan file config, reinstall satu paket, perbaiki pip, selalu setelah snapshot atas apa yang akan disentuh. Level 3: reinstall komponen atau rebuild environment Python, hanya setelah Anda konfirmasi dan hanya dengan backup.
4. Verifikasi. Setelah tiap langkah mesin memastikan gejalanya hilang dan efek yang Anda pedulikan kembali: unit active, port listening, setiap situs menjawab HTTP. Perintah yang keluar dengan kode 0 bukanlah verifikasi.
5. Rollback. Jika sebuah langkah gagal verifikasi, mesin naik satu tingkat. Jika sebuah langkah membuat sesuatu yang tadinya sehat menjadi mati, ia memulihkan snapshot dan berhenti.

Batas keras yang tidak bisa dilanggar playbook

Setiap perbaikan adalah playbook, dan playbook adalah data: bisa diperbarui dan ditambah tanpa mengubah aplikasi. Karena itu penting bahwa hal-hal berbahaya ditolak oleh mesin itu sendiri, bukan diserahkan pada "sopan santun" tiap playbook.

• Tidak ada apa pun di bawah /home, di direktori data MariaDB, atau di direktori konfigurasi OpenLiteSpeed dan CyberPanel yang pernah dihapus. Paling jauh di-backup atau dipindahkan.
• File log aktif dikosongkan, tidak pernah dihapus.
• Kernel yang sedang berjalan tidak pernah jadi kandidat pembersihan.
• Tidak ada langkah level 2 atau 3 yang berjalan saat root filesystem hampir penuh. Pembersihan disk aman berjalan dulu, karena disk penuh adalah asal binary dan modul corrupt.
• Tidak ada reinstall sebagai "fallback" tanpa penyebab yang terdiagnosa. Jika mesin tidak bisa menyebut penyebabnya, ia tidak reinstall; ia melapor.
• Tidak ada yang ditandai beres sampai langkah verifikasi lolos.

Seperti apa fallback-nya sebenarnya

Saat semua anak tangga sudah dicoba dan masalah tetap ada, Anda tidak mendapat "Error: fix gagal". Anda mendapat laporan diagnosa: service yang mati, bukti yang dikumpulkan di fase amati, penyebab yang diuji dan kenapa masing-masing disingkirkan, perbaikan yang dicoba beserta hasil verifikasinya, dan langkah manual yang akan diambil admin senior berikutnya. Anda bisa menyalin, menyimpan, atau mengirimnya ke support VPS Medic satu ketukan. Laporan yang mengungkap penyebab baru menjadi playbook baru, yang diterima setiap pemegang lisensi di update mesin berikutnya.

Kenapa dibangun seperti ini

Di VPS yang menampung website orang lain, biaya sebuah fix yang salah jauh lebih tinggi daripada biaya fix benar yang lebih lambat. Membaca journal butuh dua detik. Reinstall paket yang salah butuh sejam untuk dibatalkan dan kadang tidak bisa dibatalkan sama sekali. Mesin menghabiskan dua detik itu setiap kali, supaya pengalaman satu ketukan di aplikasi adalah sesuatu yang bisa Anda percaya jam 2 pagi, dengan root, di server yang sudah bermasalah.