Merancang Riwayat Perubahan untuk Web App Bisnis

Status permintaan berubah dari menunggu menjadi disetujui. Seminggu kemudian, seseorang bertanya siapa yang mengubahnya dan apa yang menjadi dasar keputusan. Jika aplikasi hanya menyimpan keadaan terakhir, tim mungkin harus menelusuri percakapan yang tidak lengkap.

Riwayat perubahan membantu menjawab pertanyaan tersebut apabila dirancang mengikuti proses bisnis. Tujuannya perlu jelas sejak perencanaan web app: kejadian apa yang ingin ditelusuri, siapa yang membutuhkan informasinya, dan bagaimana catatan itu digunakan dalam pekerjaan sehari-hari.

Mulai dari pertanyaan operasional

Kumpulkan pertanyaan nyata dari pengguna. Misalnya, kapan permintaan dikembalikan, siapa yang mengganti penanggung jawab, atau mengapa pesanan dibatalkan. Pertanyaan ini lebih berguna daripada memulai dengan keinginan menyimpan semua aktivitas tanpa tujuan tertentu.

Pilih kejadian yang mengubah makna pekerjaan. Membuka halaman dan menyetujui permintaan adalah tindakan berbeda. Aktivitas teknis mungkin diperlukan untuk pengoperasian sistem, tetapi daftar riwayat bisnis tidak harus menampilkan setiap permintaan jaringan yang terjadi di belakang layar.

Untuk setiap kejadian, tuliskan keputusan yang dapat dibantu catatannya. Riwayat pembatalan, misalnya, dapat membantu operator mengetahui apakah pekerjaan perlu dihentikan. Jika belum ada pengguna atau keputusan yang jelas, pertimbangkan lagi kebutuhan mengumpulkan informasi tersebut.

Bentuk satu catatan kejadian yang dapat dibaca

Gunakan unsur yang konsisten: waktu kejadian, identitas aktor, objek, tindakan, hasil, serta alasan apabila proses memang memerlukannya. Panduan logging OWASP membahas informasi kejadian dan pembatasan data sensitif. Pilih unsur sesuai kebutuhan, bukan sebanyak mungkin.

Contoh fiktif: “Permintaan PR-017 dikembalikan oleh pemeriksa pada 7 Oktober, dengan alasan rincian kebutuhan belum lengkap.” Catatan itu menunjukkan objek dan tindakan. Nama tampil dapat membantu pembaca, sementara identitas akun yang stabil membantu sistem mempertahankan hubungan ketika nama berubah.

Bedakan waktu kejadian dengan waktu catatan diterima jika keduanya dapat berbeda. Cantumkan zona waktu pada kontrak data dan tampilkan waktu yang dipahami pengguna. Urutan yang ambigu dapat membuat dua tindakan terlihat bertentangan padahal terjadi pada saat berbeda.

Pilih perubahan yang perlu diperlihatkan

Untuk beberapa bidang, nilai sebelum dan sesudah membantu menjelaskan perubahan. Contohnya, penanggung jawab berpindah dari tim A ke tim B. Pada bidang lain, cukup catat bahwa perubahan terjadi tanpa menyalin seluruh isi ke dalam riwayat.

Tentukan daftar bidang secara sengaja. Jangan otomatis merekam kata sandi, token, atau isi dokumen pribadi karena ikut berada dalam objek yang diperbarui. Informasi yang dibutuhkan pada layar utama belum tentu perlu disalin ke catatan yang dapat dibaca lebih banyak orang.

Jika alasan berbentuk teks bebas, jelaskan penggunaannya kepada operator. Minta alasan terkait pekerjaan, bukan informasi pribadi yang tidak diperlukan. Tim juga perlu memikirkan cara menangani salah ketik dan informasi keliru tanpa menghapus jejak keputusan sebelumnya secara sembarangan.

Bedakan percobaan dengan hasil berhasil

Pengguna dapat mencoba menyetujui permintaan, tetapi tindakan ditolak karena status sudah berubah. Riwayat perlu menjelaskan hasil apabila percobaan itu memang dicatat. Kalimat “menyetujui” tanpa hasil dapat memberi kesan bahwa perubahan berhasil dilakukan.

Pisahkan pembaruan utama dari pekerjaan lanjutan. Persetujuan mungkin berhasil sementara pemberitahuan masih menunggu. Operator membutuhkan keadaan bisnis yang benar; tim pengelola sistem mungkin membutuhkan rincian pengiriman pemberitahuan pada catatan operasional tersendiri.

Sepakati perilaku ketika pencatatan gagal. Apakah tindakan utama harus ditahan, atau tersedia mekanisme pemulihan yang aman? Jawabannya mengikuti risiko proses. Jangan menyembunyikan celah pencatatan melalui tampilan yang seolah-olah selalu lengkap tanpa pemeriksaan.

Rancang akses dan cara menelusuri

Orang yang boleh mengubah objek belum tentu boleh membaca seluruh riwayat organisasi. Kaitkan akses dengan peran dan cakupan data. Gunakan matriks hak akses untuk membicarakan siapa yang dapat melihat, mencari, atau mengekspor catatan.

Sediakan penyaringan yang mengikuti pertanyaan awal: objek, rentang waktu, tindakan, atau aktor. Hindari daftar panjang tanpa konteks. Ketika pengguna membuka riwayat dari sebuah permintaan, tampilkan hubungan yang jelas dengan permintaan tersebut.

Tentukan siapa yang menerima pertanyaan jika catatan tampak tidak sesuai. Riwayat yang mudah ditemukan tetapi tidak memiliki pemilik tindak lanjut dapat tetap membuat pekerjaan berhenti. Jalur klarifikasi merupakan bagian pengalaman pengguna, bukan hanya urusan penyimpanan.

Tentukan masa simpan dan perubahan format

Riwayat memiliki siklus hidup. NIST SP 800-92 memberikan konteks pengelolaan log; kebutuhan masa simpan aplikasi Anda tetap perlu ditetapkan berdasarkan penggunaan dan aturan yang berlaku pada prosesnya.

Dokumentasikan pemilik keputusan masa simpan, akses arsip, dan prosedur yang diizinkan untuk koreksi atau penghapusan. Jangan memakai angka masa simpan generik tanpa mempertimbangkan alasan operasional. Arsip yang tidak lagi dapat dibaca juga tidak membantu penelusuran.

Saat nama tindakan atau format data berubah, pertahankan kemampuan membaca catatan lama. Catat versi struktur bila diperlukan. Uji contoh sebelum dan sesudah perubahan agar tim tidak kehilangan arti riwayat hanya karena tampilan aplikasi diperbarui.

Uji dengan satu rangkaian pekerjaan

Gunakan data contoh: buat permintaan, ganti penanggung jawab, kembalikan untuk revisi, lalu setujui. Periksa apakah pembaca dapat menjelaskan urutannya tanpa bantuan pengembang. Tambahkan satu percobaan yang ditolak untuk memastikan hasilnya tidak tertukar.

Periksa juga akses pengguna berbeda, pencarian, dan ekspor yang memang disediakan. Hasil yang dicari adalah riwayat yang berguna, dapat dipahami, dan sesuai cakupan. Bawa contoh tersebut saat membahas pengembangan atau perawatan web app bersama Creatyf.

Sumber resmi

• OWASP: Logging Cheat Sheet
• NIST: Guide to Computer Security Log Management