Ditinjau · sumber daya Hosmio
Sebelum Anda mulai
Kumpulkan inventaris aplikasi, kontak klien, operator saat ini dan kemungkinan pengganti. Sediakan tempat untuk menyimpan ringkasan yang tetap dapat diakses jika VPS tidak tersedia. Referensikan penyimpanan rahasia yang dilindungi; jangan menempelkan kredensial ke dalam dokumen.
01
Tentukan batas layanan terlebih dahulu.
Daftar pekerjaan yang diperlukan agar aplikasi tetap berguna: tinjauan akses, pembaruan sistem operasi, perubahan runtime, pemeliharaan basis data, cadangan, pemantauan dan pembaruan domain. Pisahkan ini dari pekerjaan yang sebenarnya telah disetujui oleh pemasok infrastruktur untuk dilakukan. Tombol reset, pilihan cadangan opsional atau kontak dukungan tidak dengan sendirinya membentuk kontrak layanan terkelola.
Tuliskan apa pun yang pemiliknya masih belum diketahui. Untuk Hosmio, intervensi pemasok akhir dan cakupan dukungan memerlukan konfirmasi. Merencanakan tanggung jawab Anda sendiri sekarang menghindari asumsi bahwa insiden aplikasi akan didiagnosis secara otomatis oleh host.
02
Tetapkan tindakan dan wewenang keputusan.
| Aktivitas | Peran penanggung jawab | Pemicu dan pemeriksaan |
|---|---|---|
| Rilis aplikasi | Operator aplikasi; pengganti yang ditunjuk | Perubahan yang disetujui; uji masuk dan tugas representatif |
| Pemeliharaan yang mengganggu | Penyetuju perubahan klien | Jendela dampak yang diketahui; go/no-go eksplisit |
| Latihan pemulihan | Operator pemulihan | Rehearsal terjadwal; catatan dan lampiran yang dipulihkan diperiksa |
| Komunikasi insiden | Pemilik insiden saat ini | Perubahan dampak material; serah terima dengan cap waktu |
| Pengecualian pembayaran | Kontak pembelian | Ketidakcocokan atau hasil tidak pasti; pertahankan detail pembayaran faktual |
Sebuah peran hanya berguna ketika tim telah menugaskan orang yang dapat dihubungi untuknya. Catat penugasan saat ini dalam catatan operasional pribadi Anda. Satu orang dapat memegang beberapa peran, tetapi pembedaan ini mencegah teknisi secara tidak sengaja menyetujui risiko bisnis atas nama klien.
03
Sepakati perubahan dan titik hentinya.
Untuk pembaruan terencana, catat mengapa diperlukan, apa yang berubah, layanan yang terdampak dan cara kembali ke keadaan yang diketahui. Tentukan siapa yang dapat menyetujui gangguan dan siapa yang dapat menghentikan pekerjaan jika pemeriksaan gagal. Gunakan jendela yang disepakati dengan zona waktu eksplisit; "setelah jam kerja" ambigu bagi tim internasional.
Sebelum pekerjaan dimulai, verifikasi akses, salinan pemulihan dan versi atau konfigurasi tepat yang diubah. Tetapkan waktu di mana tim harus lulus pemeriksaan penerimaan atau menjalankan rencana pemulihannya. Jangan gambarkan rollback sebagai instan kecuali rehearsal aktual mendukung ekspektasi tersebut.
04
Pilih sinyal yang mengarah pada tindakan.
Mulailah dengan tugas pengguna: dapatkah akun representatif masuk, membaca catatan yang diharapkan dan menyelesaikan operasi yang aman? Tambahkan pemeriksaan sumber daya dan dependensi yang membantu menjelaskan kegagalan. Aplikasi dapat merespons permintaan health dasar sementara antrean latar belakang tidak lagi membuat kemajuan.
Pilih ambang eskalasi dari kebutuhan dan pengamatan proyek. Portal ilustratif mungkin memperlakukan dua pemeriksaan tugas terjadwal yang gagal sebagai pemicu penyelidikan, bukan definisi gangguan universal. Catat bagaimana pemeriksaan berjalan dan apa yang harus diperiksa operator selanjutnya. Peringatan tanpa penerima yang bertanggung jawab tidak menciptakan cakupan.
05
Siapkan penggantinya sebelum insiden.
Minta operator pengganti menemukan inventaris, prosedur akses terlindungi, catatan perubahan terbaru dan catatan pemulihan tanpa pendampingan. Mereka harus dapat membedakan fakta yang diketahui dari hipotesis yang belum diuji. Beri mereka wewenang yang sesuai dengan peran, bukan berbagi akun pribadi hanya untuk membuat akses lebih mudah.
Jaga cap waktu insiden tetap tidak ambigu. RFC 3339 mendefinisikan representasi cap waktu dengan UTC atau offset eksplisit; catatan seperti 2026-09-12T14:00:00Z menghindari nilai jam lokal yang tidak dijelaskan. RFC 3339: stempel waktu Internet ↗ Ikuti panduan serah terima zona waktu untuk transfer kepemilikan saat ini yang lebih lengkap.
06
Latih ringkasannya dan catat celahnya.
Gunakan latihan tabletop sebelum mengandalkan dokumen. Sajikan skenario pekerjaan latar belakang yang gagal sementara operator utama tidak tersedia. Minta pengganti mengidentifikasi dampak, tindakan yang diizinkan, jalur persetujuan dan pembaruan berikutnya. Jangan lakukan perubahan layanan nyata hanya untuk menunjukkan bahwa ringkasan tersebut ada.
Catat izin yang hilang, kepemilikan yang tidak jelas dan dokumen yang tidak dapat diakses sebagai tindakan dengan penanggung jawab. Tinjau kembali ringkasan ketika staf, integrasi, target pemulihan atau pemasok berubah. Penyelesaian berarti orang berwenang lain dapat mengikuti proses dan menjelaskan batasannya; ini tidak berarti tim dukungan berkelanjutan telah dibentuk.
Lanjutkan dengan rehearsal keluar dari penyedia dan template ringkasan insiden. Jaga ringkasan operasional tetap ringkas agar dapat digunakan selama masalah dan tautkan ke prosedur yang lebih mendalam bila perlu.