Pisahkan kepemilikan dari akses sehari-hari
Tentukan siapa yang memegang setiap akun hosting, domain, DNS, dan pihak ketiga, siapa yang membayar tagihannya, dan siapa yang mengendalikan pemulihan. Peran tersebut bisa dimiliki orang yang berbeda. Pemelihara yang mengunggah rilis tidak boleh menjadi satu-satunya orang yang dapat memulihkan proyek klien.
Cantumkan pengenal akun, pemilik bisnis, pemilik kontak pemulihan, dan administrator yang berwenang. Catat di mana materi pemulihan disimpan tanpa menaruh materi itu sendiri di lembar ini. Pastikan kelangsungan bisnis tidak bergantung pada email atau perangkat pribadi kontraktor yang akan keluar.
Selesaikan matriks tanggung jawab bersama-sama
Contoh di bawah adalah proposal untuk didiskusikan, bukan pernyataan kewajiban kontraktual PrivateHostLab. Klien memiliki keputusan bisnis, agensi mengambil pekerjaan teknis yang diterimanya, dan kewajiban penyedia berasal dari perjanjian layanan yang sebenarnya. Ganti peran dengan nama orang atau kontak penyedia yang terdokumentasi.
Untuk setiap baris, tambahkan batas persetujuan dan metode kontak yang disepakati. Pengganti harus menerima peran dan memiliki akses yang diperlukan. Pengganti yang kosong atau rute eskalasi penyedia yang tidak diketahui adalah tindakan terbuka, bukan cakupan yang diasumsikan.
Gulir secara horizontal untuk semua kolom tabel.
| Tanggung jawab | Usulan utama | Pengganti yang harus ditunjuk | Eskalasi saat |
|---|---|---|---|
| Anggaran hosting dan perpanjangan | Pemilik anggaran klien | Wakil yang diberi wewenang klien | Keputusan pembayaran atau perpanjangan tidak ditugaskan |
| Kendali domain dan DNS | Pemilik klien; agensi hanya mengubah berdasarkan kesepakatan | Operator domain yang berwenang | Akses gagal atau catatan mengarahkan pengguna dengan salah |
| Pemeliharaan OS dan aplikasi | Pemelihara agensi dalam lingkup yang disepakati | Pengganti agensi yang memenuhi kualifikasi | Pembaruan gagal atau komponen yang tidak didukung memerlukan keputusan |
| Pemeriksaan pencadangan dan pemulihan | Operator data agensi atau klien yang ditunjuk | Operator pemulihan yang terlatih | Salinan hilang atau pemeriksaan pemulihan gagal |
| Masalah infrastruktur | Penyedia dalam batas layanan terverifikasinya | Rute yang dinyatakan dalam perjanjian sebenarnya | Bukti mengarah ke luar kendali aplikasi |
| Pembaruan insiden klien | Kontak proyek yang disepakati | Pengganti yang disetujui klien | Alur kerja kritis terputus atau pembaruan berikutnya sudah jatuh tempo |
Beri operator akses yang dibutuhkan tugas mereka
Gunakan identitas individual di mana sistem terkait mendukungnya. Jaga agar izin penerbitan, penerapan, penagihan, dan pemulihan akun tetap berbeda jika praktis. OWASP merekomendasikan pemberian hak istimewa minimum yang diperlukan dan peninjauan izin untuk akses yang menumpuk. Terjemahkan prinsip itu menjadi tugas bernama dan tanggal peninjauan untuk setiap akun proyek. Lembar Curang Otorisasi OWASP.
Sepakati siapa yang dapat menambah atau menghapus kunci SSH dan siapa yang memverifikasi hasilnya. Sebelum mengubah konfigurasi SSH, pertahankan sesi yang diketahui berfungsi dan rute pemulihan yang terkonfirmasi; validasi konfigurasi sebelum menerapkannya, lalu buktikan koneksi baru yang berwenang sebelum menutup sesi lama. Ubuntu secara eksplisit menyarankan memeriksa konfigurasi sebelum memulai ulang OpenSSH untuk menghindari kehilangan akses. Dokumentasi server Ubuntu OpenSSH.
Dokumen serah terima harus berisi sidik jari kunci atau referensi catatan akses, bukan kunci privat, kata sandi, atau frasa pemulihan dompet.
Tentukan eskalasi berdasarkan dampak bisnis
Pisahkan permintaan konten rutin, perubahan pemeliharaan terencana, dan insiden yang memengaruhi alur kerja klien yang kritis. Tulis jam cakupan, zona waktu, kontak pertama, pengganti, dan titik pemeriksaan komunikasi berikutnya. Jangan mengubah saluran pesan yang nyaman menjadi jaminan waktu respons tersirat.
Peringatan harus mengarah ke tindakan yang dapat diambil seseorang. Panduan pemantauan Google membedakan gejala yang terlihat dari kemungkinan penyebab dan menanyakan apakah panggilan itu mendesak dan dapat ditindaklanjuti. Untuk proyek ini, "pertanyaan tidak dapat dikirim" adalah deskripsi insiden yang lebih jelas daripada "server tampak tidak biasa." Panduan pemantauan Google SRE.
Catatan eskalasi yang berguna mencatat alur kerja yang terpengaruh, waktu pertama diamati, keberhasilan terakhir yang diketahui, perubahan terbaru, dan tindakan yang sudah diambil. Hapus data pribadi dan rahasia dari log pendukung.
Tetapkan keputusan pemulihan serta tugas pencadangan
Sepakati titik waktu data harus dipulihkan dan berapa lama pemulihan dapat berlangsung sebelum bisnis terpengaruh secara material. Ini adalah pertanyaan perencanaan yang berbeda yang tercermin dalam titik pemulihan dan waktu pemulihan tujuan.
Sebutkan orang yang memelihara salinan, orang yang mengujinya, dan penyetuju untuk pemulihan produksi. Latih di tujuan terpisah. Catat titik data yang dipulihkan, pemeriksaan fungsional, waktu yang berlalu, dan kesenjangan; latihan yang berhasil adalah bukti untuk latihan itu, bukan jaminan untuk setiap insiden di masa depan.
Serahkan catatan proyek yang dapat digunakan
Bayangkan klien mengganti pemelihara hariannya setelah kampanye. Agensi yang keluar menyediakan rilis terkini, inventaris dependensi, langkah deployment, prosedur pemulihan basis data dan unggahan, detail penjadwal, peta DNS, dan daftar akun pihak ketiga. Klien mengonfirmasi akun dan pekerjaan berkelanjutan mana yang beralih ke pengganti.
Operator penerima harus melakukan latihan terkendali dengan dokumen-dokumen tersebut: temukan rilis yang disetujui, pulihkan data sampel secara terisolasi, temukan pekerjaan terjadwal berikutnya, dan identifikasi pemilik perpanjangan. Catat apa yang tidak dapat diselesaikan dan selesaikan sebelum mengandalkan operator tersebut untuk insiden.
- Konfirmasi akses resmi pengganti sebelum mencabut akses orang yang keluar.
- Putar kredensial yang dibagikan, atau cabut identitas individual jika itu adalah kontrol yang tepat.
- Hapus kunci usang, token deployment, dan pemberian akses di seluruh inventaris proyek.
- Konfirmasi disposisi salinan yang tersisa dan pekerjaan terbuka sesuai ketentuan serah terima yang disepakati.
Terima lembar tersebut, lalu pelihara
Tandai setiap pemeriksaan serah terima sebagai diterima, terblokir, atau memerlukan tindak lanjut, dengan peninjau dan lokasi bukti. Kontak pemulihan yang belum terselesaikan harus tetap terlihat daripada menghilang ke dalam pesan umum “serah terima selesai”.
Tinjau lembar setiap kali klien, agensi, cakupan penyedia, atau aplikasi berubah. Tautkan ke anggaran hosting yang disetujui dan catatan migrasi. Lembar kerja ini menyiapkan perjanjian operasional; ini tidak menggantikan ketentuan penjual yang sebenarnya atau menciptakan komitmen dukungan penyedia. Bandingkan dengan cakupan layanan yang dipublikasikan dan selesaikan detail yang hilang secara eksplisit.
Sumber & tinjauan
Referensi teknis diperiksa pada September 12, 2026. Contoh adalah latihan perencanaan; dokumentasi perangkat lunak yang direferensikan tidak menetapkan kemampuan layanan PrivateHostLab.