Approval Berbasis Risiko: Kapan Sebuah Perubahan Benar-Benar Membutuhkan Persetujuan?

Bayangkan dua perubahan masuk di hari yang sama. Satu mengubah warna tombol di dashboard internal. Satu lagi mengubah skema database di belakang sistem checkout. Jika kedua perubahan harus melalui proses persetujuan yang sama -- rapat CAB, tanda tangan manajer, atau antrian panjang -- tim akan cepat kehilangan kesabaran. Perubahan kecil jadi tertunda, sementara perubahan berisiko tinggi belum tentu mendapat perhatian yang lebih baik.

Ini terjadi di banyak organisasi engineering. Satu proses persetujuan untuk setiap perubahan seringkali berubah menjadi birokrasi, bukan perlindungan. Orang menunggu, konteks menjadi basi, dan efek samping paling berbahaya muncul diam-diam: tim berhenti berpikir jernih tentang risiko setiap perubahan.

Masalah dengan Menyetujui Setiap Perubahan

Ketika setiap perubahan membutuhkan persetujuan yang sama, tim bisa kehilangan rasa kepemilikan. Seorang developer mungkin berpikir, "Nanti ada yang ngecek." Padahal, orang yang paling dekat dengan perubahan biasanya paling memahaminya. Jika persetujuan menjadi satu-satunya mekanisme kontrol kualitas, tim justru menjadi kurang hati-hati, bukan lebih hati-hati.

Terlalu banyak persetujuan menciptakan ilusi keamanan. Reviewer dipaksa memeriksa terlalu banyak perubahan dalam waktu yang terlalu singkat. Perubahan berisiko tinggi mungkin mendapat review dangkal, sementara perubahan berisiko rendah menunggu di antrian yang sama. Prosesnya terlihat terkontrol, tetapi risiko aktualnya tidak dikelola dengan baik.

Prinsip Approval Berbasis Risiko

Approval berbasis risiko dimulai dengan prinsip sederhana: semakin tinggi risiko, semakin kuat jalur persetujuan yang seharusnya. Perubahan berisiko rendah bisa bergerak cepat. Perubahan berisiko tinggi harus direview oleh orang-orang yang memahami dampak potensialnya.

Banyak tim sudah melakukannya secara informal. Masalahnya, tanpa kerangka kerja yang jelas, batas antara "butuh persetujuan" dan "tidak butuh persetujuan" menjadi kabur. Keputusan bergantung pada siapa yang meminta perubahan, siapa yang bertugas, atau seberapa gugup organisasi minggu itu. Model yang lebih baik mengikat jalur persetujuan dengan risiko aktual dari perubahan tersebut.

Menentukan Ambang Batas Persetujuan

Ambang batas persetujuan adalah garis yang menentukan apakah suatu perubahan bisa berjalan otomatis atau harus menunggu persetujuan manusia. Garis itu harus eksplisit, konsisten, dan terikat pada karakteristik perubahan yang dapat diamati.

Kriteria yang berguna meliputi:

Diagram alir berikut mengilustrasikan bagaimana sebuah perubahan dapat dievaluasi terhadap kriteria-kriteria ini dan diarahkan ke jalur persetujuan yang sesuai.

Cuplikan GitLab CI berikut menunjukkan bagaimana pipeline dapat secara otomatis mendeteksi risiko dan secara kondisional memerlukan persetujuan manual:

stages:
  - test
  - deploy
  - approval
  - production

risk-check:
  stage: test
  script:
    - if git diff --name-only $CI_MERGE_REQUEST_DIFF_BASE_SHA...$CI_SHA | grep -E "^(migrations/|payment/)"; then
    -   echo "HIGH_RISK=true" >> risk.env
    - else
    -   echo "HIGH_RISK=false" >> risk.env
    - fi
  artifacts:
    reports:
      dotenv: risk.env

approval-job:
  stage: approval
  needs: [risk-check]
  rules:
    - if: $HIGH_RISK == "true"
      when: manual
      allow_failure: false
  script:
    - echo "Perubahan memerlukan persetujuan manual sebelum deploy ke produksi"

deploy-production:
  stage: production
  needs: [approval-job]
  script:
    - echo "Melakukan deploy ke produksi"
flowchart TD A[Perubahan Diajukan] --> B{Penilaian Risiko} B -->|Risiko Rendah| C[Perubahan Standar] C --> D[Tidak Perlu Persetujuan Formal] D --> E[Deploy] B -->|Risiko Sedang| F[Perubahan Normal] F --> G[Peer Review] G --> H{Disetujui?} H -->|Ya| E H -->|Tidak| I[Revisi & Ajukan Ulang] I --> A B -->|Risiko Tinggi| J[Perubahan Darurat] J --> K[Jalur Persetujuan Cepat] K --> L{Disetujui?} L -->|Ya| E L -->|Tidak| I
  • Apakah perubahan menyentuh data pengguna?
  • Apakah ia memodifikasi skema database atau jalur migrasi?
  • Dapatkah ia mempengaruhi ketersediaan layanan?
  • Apakah ia melibatkan pembayaran, autentikasi, keamanan, atau alur kritis lainnya?
  • Apakah ia mengubah infrastruktur yang bergantung pada banyak sistem?
  • Apakah ia mempengaruhi komponen dengan riwayat perilaku rapuh?

Ambang batas terbaik adalah yang bisa dideteksi secara otomatis. Sebuah pipeline dapat melihat bahwa pull request berisi file migrasi database, perubahan Terraform, konfigurasi penandatanganan mobile, atau perubahan kebijakan secret produksi. Pipeline kemudian dapat mengarahkan deployment melalui jalur persetujuan yang tepat tanpa mengandalkan tebakan.

Tiga Kategori Perubahan Praktis

Banyak tim bisa memulai dengan tiga kategori.

Perubahan standar berisiko rendah dan dapat diulang. Contohnya termasuk pembaruan konten, perubahan konfigurasi yang sudah teruji dengan baik, atau deployment yang mengikuti pola aman yang diketahui. Perubahan ini harus berjalan tanpa persetujuan formal. Tim tetap bertanggung jawab atas kualitas.

Perubahan normal membawa risiko sedang. Mereka mungkin perlu review dari satu atau dua orang yang memahami area yang terpengaruh. Ini biasanya bisa dilakukan secara asinkron. Rapat formal jarang diperlukan.

Perubahan darurat dibuat untuk menyelesaikan insiden atau mencegah kerusakan segera. Mereka membutuhkan jalur cepat dengan gesekan minimal, diikuti dengan dokumentasi setelahnya. Tujuannya bukan untuk memperlambat pemulihan. Tujuannya adalah memastikan organisasi tahu apa yang diubah, mengapa diubah, dan apa yang harus ditingkatkan setelah insiden.

Apa yang Ini Ubah dalam Perilaku Tim

Ketika persetujuan dicadangkan untuk risiko yang berarti, tim menjadi lebih perhatian. Mereka tahu perubahan kecil adalah tanggung jawab mereka. Mereka juga tahu bahwa perubahan besar akan mendapat perhatian ekstra dari orang-orang yang dapat membantu menemukan titik buta.

Ini mendukung budaya kepemilikan, bukan budaya serah terima. Developer tidak bisa bersembunyi di balik persetujuan. Reviewer tidak tenggelam dalam permintaan sepele. Organisasi menghabiskan perhatiannya di mana perhatian itu benar-benar penting.

Daftar Periksa Praktis

  • Identifikasi komponen kritis seperti database, alur pembayaran, autentikasi, state infrastruktur, dan layanan bersama.
  • Tentukan ambang batas objektif untuk setiap kategori risiko.
  • Dokumentasikan jalur persetujuan mana yang berlaku untuk perubahan standar, normal, dan darurat.
  • Buat pipeline mendeteksi indikator risiko jika memungkinkan.
  • Catat persetujuan dan bukti sebagai bagian dari catatan deployment.
  • Tinjau ambang batas secara berkala, karena risiko berubah seiring evolusi sistem dan tim.

Tata Kelola yang Membantu Pengiriman Bergerak

Dengan approval berbasis risiko, tata kelola menjadi bantuan pengiriman, bukan penghambat pengiriman. Ini memberikan jalur cepat untuk perubahan berisiko rendah dan memberikan perhatian yang layak untuk perubahan berisiko tinggi.

Intinya bukan menyetujui semuanya. Intinya adalah menyetujui hal yang tepat. Sistem CI/CD yang sehat harus bisa membedakan antara gerakan rutin dan bahaya nyata. Ketika perbedaan itu jelas, tim bisa bergerak lebih cepat tanpa berpura-pura bahwa setiap perubahan sama amannya.

Intisari konkret: Mulailah dengan mengidentifikasi perubahan mana yang benar-benar berisiko tinggi di lingkungan Anda. Berikan jalur cepat untuk perubahan rutin. Berikan review yang lebih kuat untuk perubahan berisiko. Persetujuan yang efektif bukan tentang mengendalikan setiap gerakan. Ini tentang memastikan bahwa perubahan yang dapat menyebabkan kerusakan nyata mendapat perhatian yang tepat sebelum mencapai produksi.