Mengapa Mencatat Persetujuan dan Bukti Lebih Penting daripada Sekadar Mendapatkan "Ya"
Anda baru saja mendapat persetujuan lisan dari manajer untuk melakukan deployment perubahan database larut malam. Mereka bilang "lanjutkan," Anda menjalankan deployment, dan semuanya tampak baik-baik saja. Seminggu kemudian, terjadi sesuatu yang rusak. Saat post-mortem, Anda mengatakan manajer Anda menyetujuinya. Manajer Anda bilang tidak ingat menyetujui hal seperti itu. Sekarang Anda menghadapi dua masalah: masalah teknis yang menyebabkan gangguan, dan sengketa tentang siapa yang mengotorisasi perubahan tersebut.
Skenario ini lebih sering terjadi daripada yang diakui sebagian besar tim. Persetujuan terjadi, tetapi tidak ada catatannya. Tidak ada bukti siapa yang mengatakan ya, kapan mereka mengatakannya, atau apa yang mereka lihat sebelum menyetujui. Tanpa catatan itu, persetujuan bisa dianggap tidak pernah ada.
Apa yang Harus Dicakup oleh Catatan Persetujuan yang Sebenarnya
Catatan persetujuan yang tepat menjawab tiga pertanyaan. Jika salah satu terlewat, jejak audit Anda memiliki celah yang bisa menyebabkan masalah serius di kemudian hari.
Berikut adalah contoh catatan persetujuan lengkap dalam log audit pipeline:
{
"change_id": "DEPLOY-2024-11-05-142",
"approver": {
"name": "alice.chen",
"role": "engineering_manager"
},
"timestamp": "2024-11-05T14:30:00Z",
"evidence": [
{
"type": "test_results",
"url": "https://ci.internal/pipeline/1234/test-report"
},
{
"type": "security_scan",
"summary": "0 critical, 2 high, 5 medium findings - all waived per policy"
},
{
"type": "change_request",
"url": "https://tickets.internal/CR-7890"
}
]
}
Siapa yang Menyetujui
Pipeline perlu mencatat identitas orang yang memberikan persetujuan. Bukan sekadar nama, tetapi juga peran mereka di tim. Apakah itu tech lead, engineering manager, atau DBA? Peran itu penting karena menunjukkan apakah orang tersebut memiliki wewenang untuk menyetujui jenis perubahan tersebut.
Lebih penting lagi, sistem perlu memverifikasi bahwa persetujuan benar-benar berasal dari orang tersebut, bukan dari orang lain yang menggunakan akun mereka. Inilah sebabnya alur kerja persetujuan harus berjalan melalui sistem yang terintegrasi dengan autentikasi tim Anda, bukan melalui pesan chat atau email yang mudah dipalsukan atau diteruskan. Jika seseorang bisa copy-paste pesan "disetujui" dari thread Slack, Anda tidak memiliki sistem persetujuan. Anda hanya memiliki permainan screenshot.
Kapan Disetujui
Timestamp harus mencakup menit dan zona waktu. Ini mungkin terdengar berlebihan sampai Anda perlu merekonstruksi urutan kejadian selama investigasi insiden.
Pertimbangkan timeline ini:
- Perubahan diajukan pukul 14:00
- Persetujuan diberikan pukul 14:30
- Deployment ke produksi pukul 14:45
- Insiden terdeteksi pukul 15:10
Dengan timestamp yang bersih, Anda bisa melihat dengan tepat bagaimana semuanya terjadi. Tanpa itu, Anda hanya menebak-nebak apakah persetujuan datang sebelum atau sesudah deployment. Persetujuan yang terjadi setelah deployment bukanlah persetujuan sama sekali. Itu hanya pemberitahuan yang dikemas sebagai tata kelola.
Bukti Apa yang Mendasari Persetujuan
Ini adalah bagian yang paling sering dilupakan tim. Seseorang menyetujui perubahan, tetapi apa yang sebenarnya mereka lihat sebelum mengklik "setujui"? Apakah mereka meninjau hasil tes? Membaca changelog? Memeriksa apakah perubahan memengaruhi sistem lain? Atau mereka hanya percaya bahwa semuanya baik-baik saja?
Pipeline harus menangkap bukti yang mendasari keputusan tersebut. Ini bisa berupa:
- Tautan ke pipeline run yang menunjukkan semua gate terlewati
- Screenshot hasil security scan
- Dokumen change request yang telah ditinjau
- Ringkasan tentang apa yang diperiksa dan dikonfirmasi
Saat Anda menangkap bukti ini, persetujuan berhenti menjadi stempel karet dan menjadi keputusan yang dapat diverifikasi. Siapa pun bisa melihat ke belakang dan mengetahui dengan tepat apa yang diketahui saat persetujuan diberikan, bukan hanya bahwa seseorang mengatakan ya.
Membangun Jejak Audit
Ketiga informasi ini bersama-sama membentuk jejak audit Anda. Jejak audit adalah catatan lengkap tentang apa yang terjadi pada suatu perubahan dari awal hingga akhir: siapa yang membuatnya, siapa yang meninjaunya, gate mana yang dilewati, siapa yang menyetujuinya, kapan di-deploy, dan apakah deployment berhasil atau gagal.
Jejak audit yang lengkap memiliki dua tujuan. Pertama, memenuhi persyaratan kepatuhan. Baik perusahaan Anda memiliki kebijakan internal atau peraturan eksternal yang harus diikuti, memiliki catatan yang jelas tentang setiap perubahan dan siapa yang mengotorisasinya seringkali bersifat wajib.
Kedua, dan yang lebih praktis, ini membuat investigasi insiden lebih cepat dan tidak terlalu menegangkan. Ketika terjadi kesalahan, Anda tidak perlu melacak orang dan bertanya "siapa yang melakukan ini?" atau "mengapa ini diizinkan lewat?" Jawabannya sudah tercatat. Anda bisa fokus memperbaiki masalah daripada merekonstruksi apa yang terjadi.
Menerapkannya dalam Praktik
Sebagian besar alat CI/CD modern sudah menangkap sebagian dari informasi ini. GitLab CI/CD, GitHub Actions, dan Jenkins dengan plugin yang tepat bisa mencatat siapa yang menyetujui perubahan dan kapan. Namun, bagian bukti biasanya memerlukan upaya manual dari orang yang memberikan persetujuan.
Perbaikannya sederhana tetapi membutuhkan disiplin: biasakan bahwa sebelum menyetujui, pemberi persetujuan menambahkan komentar dengan tautan atau ringkasan tentang apa yang mereka tinjau. Tanpa kebiasaan ini, catatan persetujuan Anda hanya akan bertuliskan "disetujui" tanpa konteks. Itu hampir tidak lebih baik daripada tidak memiliki catatan sama sekali.
Beberapa tim melangkah lebih jauh dengan menyematkan pengumpulan bukti ke dalam pipeline itu sendiri. Langkah persetujuan dapat menampilkan ringkasan hasil tes, temuan security scan, dan detail perubahan langsung di antarmuka persetujuan. Pemberi persetujuan melihat semua yang mereka butuhkan tanpa meninggalkan pipeline, dan sistem mencatat apa yang ditampilkan. Ini menghilangkan kebutuhan akan komentar manual dan membuat penangkapan bukti menjadi otomatis.
Daftar Periksa Cepat untuk Catatan Persetujuan Anda
Jika Anda sedang menyiapkan atau meninjau proses persetujuan, jalankan pemeriksaan ini:
- Apakah pipeline mencatat identitas dan peran pemberi persetujuan?
- Apakah timestamp cukup presisi untuk merekonstruksi urutan kejadian?
- Apakah bukti yang mendasari persetujuan ditangkap secara otomatis atau manual?
- Dapatkah seseorang yang meninjau jejak audit enam bulan kemudian memahami mengapa perubahan ini disetujui?
- Apakah sistem persetujuan terintegrasi dengan autentikasi tim Anda, bukan sekadar pesan chat?
Intinya
Persetujuan tanpa catatan bukanlah persetujuan. Itu adalah percakapan yang mungkin diingat secara berbeda oleh setiap orang yang terlibat. Saat Anda menangkap siapa yang menyetujui, kapan mereka menyetujui, dan bukti apa yang mereka lihat, Anda mengubah "oke, lanjutkan" yang santai menjadi keputusan yang dapat ditinjau, diaudit, dan dipertahankan. Itulah perbedaan antara proses yang terlihat memiliki kontrol dan proses yang benar-benar memilikinya.