Checklist maintenance website membantu Anda memastikan website tetap menjalankan pekerjaan bisnisnya: menampilkan informasi yang benar, menerima pertanyaan, dan memberi pengunjung jalur pemesanan yang berfungsi. Pemeriksaan dimulai dari backup yang dapat dipulihkan, pembaruan sistem, lalu pengujian halaman dan formulir.
Website yang bisa dibuka belum tentu selesai diperiksa. Formulir dapat gagal mengirim pesan, tombol WhatsApp dapat menuju nomor lama, atau salinan backup ternyata tidak mencakup data terbaru. Karena itu, catat hasil pemeriksaan beserta penanggung jawabnya.
Isi backup yang perlu Anda ketahui
Minta pengelola menjelaskan apa yang disimpan: konten, database, gambar, kode, serta konfigurasi yang diperlukan untuk menjalankan website. Untuk WordPress, dokumentasi backup resminya menjelaskan bahwa database dan berkas merupakan bagian terpisah yang sama-sama diperlukan untuk pemulihan lengkap.
Pada website dengan teknologi lain, rinciannya perlu mengikuti arsitektur yang dipakai. Jangan menyamakan ekspor artikel dengan salinan seluruh sistem. Integrasi pembayaran, penyimpanan gambar, dan layanan email mungkin mempunyai pengaturan terpisah.
- Pastikan ada keterangan waktu pembuatan dan status keberhasilan backup.
- Tentukan lokasi penyimpanan serta siapa yang berhak mengaksesnya.
- Simpan salinan yang tidak bergantung sepenuhnya pada server website.
- Periksa apakah data yang dibutuhkan untuk pulih sudah tercakup.
Contoh retensi yang dapat dihitung
Contoh berikut hipotetis dan memakai full backup dengan ukuran tetap. Misalkan Anda menyimpan 7 backup harian terakhir dan 4 backup mingguan yang lebih lama dari jendela harian. Jika setiap snapshot lengkap berukuran 2 GB, ada 11 snapshot berbeda: (7 + 4) × 2 GB = 22 GB per lokasi penyimpanan. Menyalin kumpulan yang sama ke 2 lokasi independen memerlukan 44 GB total logis.
Perhitungan ini mengabaikan kompresi, deduplikasi, pertumbuhan data, metadata, dan backup tambahan sebelum pembaruan. Penyedia yang memakai backup incremental menghitung ruang dengan cara lain. Catat tanggal snapshot agar salinan mingguan yang sama tidak dihitung sebagai versi tambahan.
Dalam simulasi yang sama, backup terakhir berhasil pukul 02:00 dan gangguan terjadi pukul 15:30. Selisihnya 13 jam 30 menit. Jika pemulihan hanya memakai backup tersebut, perubahan dalam interval ini perlu ditelusuri dari sumber lain yang sah, misalnya catatan pesanan atau ekspor terkait. Selisih waktu itu belum membuktikan data hilang dan tidak menunjukkan berapa lama pemulihan akan berlangsung.
Jadwal pemeriksaan sebagai titik awal
Tabel berikut merupakan contoh jadwal kerja, bukan ketentuan untuk semua website. Sesuaikan frekuensinya dengan perubahan konten, jumlah transaksi, dan kemampuan tim menangani gangguan. Website yang menerima pesanan memerlukan perhatian berbeda dari profil perusahaan yang jarang berubah.
| Waktu | Pemeriksaan | Bukti yang dicatat |
|---|---|---|
| Setiap hari kerja | Halaman utama, jalur kontak, dan status pekerjaan backup | Hasil pemeriksaan serta pesan kegagalan |
| Setiap minggu | Pembaruan yang tersedia, formulir, dan halaman penting | Perubahan yang dilakukan dan hasil uji |
| Setiap bulan | Akun pengelola, informasi bisnis, serta uji pemulihan terjadwal | Daftar akses dan laporan pemulihan |
| Sebelum perubahan besar | Backup baru, salinan pengujian, dan rencana pembatalan perubahan | Versi awal serta langkah kembali |
Uji pemulihan pada lingkungan terpisah
Mintalah demonstrasi pemulihan pada salinan pengujian yang tidak menerima transaksi nyata. Catat waktu yang diperlukan, komponen yang belum pulih, serta tindakan tambahan yang harus dilakukan. Keberadaan berkas backup saja belum menunjukkan bahwa website dapat dijalankan kembali.
Dalam contoh hipotetis, katalog berhasil dipulihkan tetapi gambar produk tidak muncul. Temuan ini menunjukkan bahwa sumber gambar perlu dimasukkan ke rencana pemulihan. Jika formulir mengirim email dari salinan pengujian, matikan pengiriman nyata selama pengujian agar pelanggan tidak menerima pesan percobaan.
Sepakati seberapa banyak data terbaru yang masih dapat diterima jika hilang, dan berapa lama proses pemulihan boleh berlangsung bagi operasional Anda. Tuliskan kebutuhan ini dalam bahasa bisnis agar pengelola dapat merancang jadwal backup yang sesuai.
Catatan latihan pemulihan
Siapkan lembar uji dengan waktu mulai, snapshot yang dipakai, waktu sistem bisa dibuka, dan hasil pemeriksaan. Sebagai contoh hipotetis, pemulihan berkas berlangsung 18 menit, impor database 7 menit, serta uji halaman dan formulir 15 menit. Total latihan tersebut 40 menit; angka ini bukan estimasi layanan atau batas waktu pemulihan website Anda.
Periksa halaman utama, satu artikel, satu produk bila ada, gambar, login pengelola, dan formulir dengan pengiriman nyata dimatikan. Catat komponen yang gagal secara terpisah. Hasil latihan baru berguna ketika tim tahu berkas mana yang dipulihkan, kapan datanya dibuat, dan fungsi apa yang sudah diperiksa.
Pembaruan sistem dengan pemeriksaan setelahnya
Untuk WordPress, panduan pengamanan resminya mencakup penggunaan versi terkini serta pembatasan akses. Terapkan prinsip tersebut sesuai sistem yang digunakan. Pembaruan sebaiknya disertai backup, pemeriksaan kompatibilitas, dan pengujian fungsi setelah perubahan.
Catat komponen yang diperbarui. Bila pembaruan tertunda karena konflik, tuliskan alasannya dan langkah penyelesaiannya. Mengabaikan pemberitahuan tanpa penanggung jawab membuat pekerjaan tersebut mudah terlupakan.
Pengujian fungsi dari sudut pandang pelanggan
Gunakan ponsel dan komputer untuk menjalankan alur yang benar-benar dipakai pengunjung. Jangan berhenti pada tampilan halaman utama.
- Buka halaman layanan dari menu, kemudian baca informasi kontak dan cakupan pekerjaan.
- Kirim formulir percobaan yang diberi penanda jelas, lalu periksa apakah pesan diterima.
- Tekan tombol WhatsApp dan pastikan nomor serta pesan awalnya sesuai.
- Periksa gambar, unduhan, pencarian, serta tautan menuju halaman penting.
- Untuk toko online, uji alur pesanan melalui mode pengujian yang disediakan pengelola.
Jika Anda sedang merencanakan website bisnis baru, masukkan daftar pengujian tersebut dalam kriteria serah terima. Tim berikutnya akan memiliki acuan yang sama saat melakukan perawatan.
Periksa pula halaman yang menerima kunjungan dari kampanye aktif. Uji formulir di beranda belum memastikan bahwa formulir pada halaman lain memakai penerima yang sama. Simpan daftar singkat halaman yang perlu diuji langsung, terutama setelah ada perubahan nomor kontak atau petugas yang menerima pertanyaan.
Pembagian tanggung jawab yang dapat diperiksa
Tentukan siapa yang memantau gangguan, siapa yang memperbaiki, dan siapa yang menyetujui perubahan konten. Simpan akses melalui cara yang aman. Hapus akses pengelola yang sudah tidak terlibat dan hindari penggunaan satu akun bersama ketika sistem menyediakan akun terpisah.
Laporan maintenance sebaiknya memuat pekerjaan selesai, temuan terbuka, serta keputusan yang menunggu Anda. Bedakan waktu tanggapan dengan waktu penyelesaian. Perbaikan yang bergantung pada penyedia lain perlu dijelaskan sebagai ketergantungan, bukan diberi janji penyelesaian yang belum bisa dipastikan.
Untuk membahas cakupan perawatan, lihat layanan maintenance website Aksara Karya Digital. Bawa daftar fungsi penting, teknologi website, dan kebutuhan pemulihan Anda agar pekerjaan yang disepakati dapat diperiksa hasilnya.
Dzaki Fauzaan
