Tidak Semua Perubahan Itu Sama: Perubahan Standar, Normal, dan Darurat

Seorang developer membuka pull request untuk memperbaiki typo di halaman "Tentang Kami" perusahaan. Tiga hari kemudian, perbaikan itu masih menunggu persetujuan. Sementara itu, tim lain bersiap untuk migrasi skema database payment, dan mereka juga menunggu proses persetujuan yang sama. Perbaikan typo dan migrasi database diperlakukan identik: keduanya perlu rapat, tanda tangan, dan slot di jendela rilis berikutnya.

Situasi ini membuat frustrasi, tetapi juga umum terjadi. Ketika setiap perubahan melewati pipeline persetujuan yang sama, perbaikan kecil tersangkut di belakang proses yang berat, dan perubahan berisiko tinggi mungkin tidak mendapatkan pengawasan yang layak. Masalahnya bukan pada governance itu sendiri. Masalahnya adalah memperlakukan semua perubahan seolah-olah memiliki risiko yang sama.

Mengapa Pendekatan Satu-Untuk-Semua Gagal

Naluri untuk mengontrol setiap perubahan datang dari niat baik: tidak ada yang ingin lingkungan produksi yang rusak. Namun ketika proses persetujuan tidak membedakan antara pembaruan teks dan migrasi skema, dua hal terjadi. Pertama, perubahan berisiko rendah menumpuk menunggu persetujuan yang tidak menambah keamanan nyata. Kedua, tim menjadi mati rasa terhadap proses tersebut. Ketika semuanya memerlukan tanda tangan, orang berhenti berpikir apakah tanda tangan itu benar-benar penting. Mereka hanya menunggu centang.

Hasilnya adalah sistem yang memperlambat perubahan aman tanpa membuat perubahan berisiko menjadi lebih aman. Solusinya bukan menghilangkan governance. Solusinya adalah membuat governance proporsional terhadap risiko.

Tiga Kategori Perubahan

Sebagian besar tim yang matang membagi perubahan menjadi tiga kategori berdasarkan risiko dan familiaritas: standar, normal, dan darurat. Setiap kategori memiliki jalur persetujuan yang berbeda.

Diagram alir berikut mengilustrasikan bagaimana sebuah perubahan masuk ke pipeline dan diarahkan ke proses persetujuan yang sesuai berdasarkan klasifikasinya.

flowchart TD A[Permintaan Perubahan] --> B{Apakah ini darurat?} B -->|Ya| C[Perubahan Darurat] C --> D[Lakukan perubahan segera] D --> E[Dokumentasi & tinjauan pasca] B -->|Tidak| F{Apakah prosedur terdokumentasi & terbukti?} F -->|Ya| G[Perubahan Standar] G --> H[Persetujuan pipeline otomatis] H --> I[Deploy] F -->|Tidak| J[Perubahan Normal] J --> K{Nilai tingkat risiko} K -->|Rendah| L[Tinjauan rekan] K -->|Tinggi| M[CAB atau tinjauan multi-stakeholder] L --> N[Setujui & deploy] M --> N

Perubahan Standar

Perubahan standar adalah sesuatu yang telah dilakukan tim berkali-kali sebelumnya. Prosedurnya diketahui, hasilnya dapat diprediksi, dan risikonya dipahami dengan baik. Contohnya termasuk memperbarui konten statis di halaman pemasaran, menambahkan server untuk menangani lonjakan traffic, atau menjalankan ulang pipeline yang gagal karena masalah jaringan sementara.

Karena tim sudah tahu persis apa yang akan terjadi dan memiliki prosedur yang terbukti, perubahan standar tidak memerlukan tinjauan atau persetujuan manual. Tim cukup mengikuti prosedur yang terdokumentasi. Persyaratan utamanya adalah prosedur harus terdokumentasi dan dapat diaudit. Jika terjadi kesalahan, tim dapat melacak kembali dan memeriksa apakah prosedur diikuti dengan benar.

Perubahan standar adalah tempat di mana automation bersinar. Jika suatu prosedur benar-benar dapat diprediksi, prosedur tersebut harus dikodifikasi dalam pipeline CI/CD. Pipeline itu sendiri menjadi mekanisme persetujuan: jika pemeriksaan otomatis lolos, perubahan akan berjalan.

Perubahan Normal

Perubahan normal adalah sesuatu yang belum pernah dilakukan tim sebelumnya, atau risikonya belum sepenuhnya dipahami. Contohnya termasuk menambahkan fitur yang mengubah logika bisnis, meningkatkan versi database, atau memodifikasi konfigurasi keamanan.

Perubahan normal memerlukan tinjauan. Peninjau bisa berupa developer rekan, anggota tim keamanan, atau Change Advisory Board (CAB), tergantung pada tingkat risiko. Namun tinjauan tidak harus berarti proses yang lambat. Untuk perubahan normal berisiko rendah, tinjauan cepat oleh satu atau dua orang sudah cukup. Untuk perubahan normal berisiko tinggi, tinjauan mungkin melibatkan lebih banyak pemangku kepentingan dan pengujian tambahan.

Poin kritisnya adalah perubahan normal tidak diblokir secara default. Mereka ditinjau secara proporsional. Tim yang memiliki kriteria jelas tentang apa yang membuat perubahan berisiko rendah versus berisiko tinggi dapat mengarahkan setiap perubahan ke kedalaman tinjauan yang sesuai secara otomatis.

Perubahan Darurat

Perubahan darurat adalah sesuatu yang harus dilakukan segera untuk memperbaiki masalah langsung. Contohnya termasuk server produksi down, data korup, atau kerentanan keamanan yang sedang dieksploitasi secara aktif. Dalam situasi ini, menunggu tinjauan atau rapat persetujuan akan memperburuk masalah.

Perubahan darurat memiliki jalur cepat. Tim dapat melakukan perubahan segera, tetapi ada syaratnya: perubahan harus didokumentasikan dan dievaluasi setelahnya. Tim perlu mencatat apa yang diubah, siapa yang mengubahnya, mengapa itu darurat, dan apa dampaknya. Setelah insiden selesai, tim mengevaluasi apakah perubahan darurat itu tepat atau perlu koreksi lebih lanjut.

Jalur cepat bukanlah tiket gratis. Ini adalah trade-off: kecepatan sekarang, akuntabilitas nanti. Tim yang menyalahgunakan jalur darurat dengan mengklasifikasikan perubahan rutin sebagai darurat pada akhirnya akan kehilangan kepercayaan dan menciptakan risiko nyata.

Cara Mengklasifikasikan Perubahan

Tiga kategori hanya berguna jika tim memiliki kriteria jelas untuk masing-masing. Tanpa kriteria, klasifikasi menjadi arbitrer. Perubahan standar bagi satu orang bisa menjadi perubahan normal bagi orang lain, dan seluruh sistem menjadi kacau.

Mulailah dengan mendefinisikan apa yang membuat perubahan menjadi standar. Aturan praktis yang baik: jika tim telah melakukan perubahan yang sama setidaknya lima kali tanpa insiden, dan prosedurnya terdokumentasi penuh, maka itu adalah kandidat untuk status standar. Jika ada ketidakpastian, itu termasuk dalam kategori normal.

Untuk perubahan normal, definisikan apa yang membuat perubahan berisiko tinggi versus berisiko rendah. Faktor umum meliputi: apakah perubahan menyentuh skema database? Apakah memengaruhi autentikasi atau otorisasi? Apakah mengubah cara penanganan uang? Apakah memerlukan rencana rollback? Semakin banyak jawaban ya, semakin tinggi risikonya.

Untuk perubahan darurat, definisikan apa yang memenuhi syarat sebagai darurat. Typo di halaman arahan bukanlah darurat. Gangguan produksi yang memengaruhi pelanggan yang membayar adalah darurat. Tim harus menyepakati contoh-contoh darurat asli dan contoh situasi yang terlihat mendesak tetapi sebenarnya tidak.

Mengintegrasikan Klasifikasi ke dalam Pipeline

Setelah kriteria jelas, langkah selanjutnya adalah mengintegrasikan klasifikasi ke dalam pipeline CI/CD. Ini tidak berarti membangun sistem persetujuan yang kompleks. Ini berarti menambahkan field sederhana ke permintaan perubahan atau tiket deployment yang meminta developer mengklasifikasikan perubahan. Pipeline kemudian dapat mengarahkan perubahan ke jalur tinjauan yang sesuai.

Sebagai contoh, workflow GitHub Actions dapat secara otomatis memberi label pull request sebagai standard ketika hanya menyentuh dokumentasi atau file konfigurasi, dan kemudian melewati langkah persetujuan manual:

name: Classify Change
on: pull_request

jobs:
  classify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v5
        with:
          repo-token: "${{ secrets.GITHUB_TOKEN }}"
          configuration-path: .github/labeler.yml

  deploy-standard:
    if: contains(github.event.pull_request.labels.*.name, 'standard')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy without manual approval
        run: echo "Deploying standard change..."

Dan file .github/labeler.yml yang menyertainya mendefinisikan path mana yang dipetakan ke label standard:

standard:
  - changed-files:
      - any-glob-to-any-file: ['docs/**', 'config/**', '*.md']

Untuk perubahan standar, pipeline dapat berjalan otomatis setelah tes biasa lolos. Untuk perubahan normal, pipeline dapat berhenti sejenak dan memberi tahu peninjau yang sesuai. Untuk perubahan darurat, pipeline dapat mengizinkan deployment tetapi memicu persyaratan dokumentasi pasca-deployment.

Tujuannya bukan membangun birokrasi. Tujuannya adalah membuat pipeline mencerminkan pemahaman tim tentang risiko. Ketika pipeline menangani klasifikasi secara otomatis, tim menghabiskan lebih sedikit waktu pada proses dan lebih banyak waktu pada pekerjaan aktual.

Daftar Periksa Praktis

Sebelum deployment Anda berikutnya, ajukan pertanyaan-pertanyaan ini:

  • Apakah perubahan ini sesuatu yang pernah kami lakukan sebelumnya dengan prosedur terdokumentasi? Jika ya, perlakukan sebagai standar dan otomatiskan persetujuan.
  • Apakah perubahan ini baru atau tidak pasti? Jika ya, identifikasi tingkat risiko dan tetapkan peninjau yang sesuai.
  • Apakah perubahan ini diperlukan untuk memperbaiki masalah langsung? Jika ya, lakukan perubahan sekarang, tetapi dokumentasikan semuanya dan jadwalkan tinjauan pasca-insiden.

Kesimpulan

Governance bukan tentang memperlambat semua orang. Ini tentang menerapkan jumlah kontrol yang tepat pada perubahan yang tepat. Perubahan standar harus melesat. Perubahan normal harus mendapatkan tinjauan proporsional. Perubahan darurat harus mendapatkan kecepatan dengan akuntabilitas. Ketika tim menyepakati kriteria dan menerapkannya ke dalam pipeline, persetujuan menjadi lebih cerdas, bukan lebih berat.