Saat Infrastruktur yang Pulih Otomatis Justru Memperburuk Keadaan

Ini jam 2 pagi. Aplikasi produksi Anda mulai melempar error koneksi pool. Engineer yang sedang on-call segera masuk ke konsol cloud, mengubah satu parameter database, dan sistem pun stabil. Semua orang lega.

Dua puluh menit kemudian, alert datang lagi. Error yang sama. Engineer memeriksa konsol dan mendapati parameter tersebut telah dikembalikan ke nilai semula. Pipeline infrastructure-as-code Anda mendeteksi perubahan manual sebagai "drift" dan otomatis mengembalikannya. Sekarang Anda kembali dalam insiden, dan siklus ini akan terus berulang sampai seseorang menonaktifkan mekanisme rekonsiliasi otomatis.

Skenario ini bukan hipotetis. Inilah yang terjadi ketika rekonsiliasi otomatis memperlakukan setiap penyimpangan dari kode sebagai masalah yang harus diperbaiki.

Masalah dengan Asumsi Semua Drift Itu Buruk

Rekonsiliasi otomatis terdengar sempurna di atas kertas. Pipeline Anda mendeteksi ketika infrastruktur dunia nyata telah menyimpang dari apa yang didefinisikan dalam kode, lalu secara otomatis menerapkan keadaan yang benar. Tanpa campur tangan manusia. Tanpa celah bagi drift untuk bertahan.

Namun asumsi dasarnya salah: tidak semua drift adalah kesalahan. Terkadang perubahan di luar pipeline terjadi karena alasan yang sah, dan perubahan itulah yang menjaga sistem tetap berjalan.

Saat terjadi insiden, engineer melakukan perubahan darurat. Saat migrasi database, tim untuk sementara memodifikasi resource sebagai bagian dari prosedur yang hati-hati. Saat pengujian beban, parameter scaling disesuaikan dengan cepat. Semua ini adalah alasan yang valid mengapa infrastruktur tidak cocok dengan repositori kode Anda.

Sistem rekonsiliasi otomatis tidak memiliki cara untuk membedakan antara perubahan yang merusak dan perubahan yang menyelamatkan. Ia hanya tahu bahwa keadaan aktual berbeda dari keadaan yang diinginkan, dan tugasnya adalah mengembalikan keadaan yang diinginkan. Ia tidak memiliki konteks tentang mengapa perubahan dibuat, apakah ada insiden aktif, atau apakah perubahan telah divalidasi oleh tim.

Saat Timing Memperburuk Keadaan

Waktu eksekusi rekonsiliasi otomatis menciptakan kategori risiko lain. Bayangkan sebuah tim yang sedang dalam proses migrasi database yang kompleks. Mereka sengaja memodifikasi beberapa resource cloud secara manual sebagai bagian dari prosedur multi-langkah yang belum sepenuhnya tertangkap di IaC. Jika pipeline rekonsiliasi berjalan di tengah migrasi, ia bisa menghapus resource yang sedang dalam transisi, menyebabkan kehilangan data atau kegagalan migrasi total.

Ini bukan edge case teoretis. Migrasi, upgrade infrastruktur, dan respons insiden keamanan semuanya melibatkan keadaan sementara di mana lingkungan live sengaja berbeda dari codebase. Rekonsiliasi otomatis yang berjalan selama jendela ini tidak hanya menyebabkan ketidaknyamanan. Ia bisa merusak data, memutus layanan yang sedang berjalan, atau membatalkan langkah keamanan kritis yang diterapkan secara manual karena situasi menuntut kecepatan daripada proses.

Mengendalikan Risiko Tanpa Meninggalkan Otomatisasi

Jawabannya bukan menonaktifkan rekonsiliasi otomatis sepenuhnya. Jawabannya adalah membangun kontrol yang sesuai dengan cara operasi nyata berjalan.

Diagram alir berikut mengilustrasikan loop rekonsiliasi otomatis yang bermasalah dan di mana kontrol yang diusulkan campur tangan.

flowchart TD A[Drift Terdeteksi] --> B{Gerbang Persetujuan?} B -- Tidak --> C[Kembalikan Otomatis] C --> D[Insiden Berulang] D --> A B -- Ya --> E[Tinjauan Manusia] E --> F{Drift Sah?} F -- Ya --> G[Adopsi ke Kode] F -- Tidak --> H[Rekonsiliasi Aman] I[Jendela Rekonsiliasi] --> B J[Pembekuan Perubahan] --> B K[Aturan Pengecualian] --> A

Gerbang Persetujuan untuk Rekonsiliasi

Alih-alih pipeline secara otomatis menerapkan perubahan saat drift terdeteksi, buatlah ia berhenti di tahap tinjauan. Kirim notifikasi ke tim terkait dengan detail tentang apa yang berubah. Minta persetujuan sebelum rekonsiliasi dijalankan. Ini memberi tim waktu untuk memeriksa apakah drift harus dikembalikan atau diadopsi ke dalam codebase.

Ini bukan berarti operasi menjadi lambat. Proses persetujuan yang dirancang dengan baik bisa cepat. Kuncinya adalah manusia yang mengambil keputusan, bukan sistem otomatis yang tidak memiliki konteks.

Jendela Rekonsiliasi

Tentukan jendela waktu tertentu kapan rekonsiliasi otomatis diizinkan berjalan. Misalnya, hanya antara jam 9 pagi hingga 5 sore pada hari kerja. Di luar jam tersebut, drift terdeteksi dan dilaporkan, tetapi tidak diperbaiki secara otomatis.

Aturan sederhana ini mencegah skenario insiden jam 2 pagi. Jika perubahan darurat terjadi di malam hari, pipeline akan mencatatnya dan memberi tahu tim, tetapi tidak akan membatalkan perbaikan hingga pagi hari ketika seseorang dapat meninjaunya dengan benar.

Pembekuan Perubahan

Ketika tim sedang dalam periode pembekuan, matikan semua rekonsiliasi otomatis. Pembekuan terjadi sebelum rilis besar, selama audit, atau selama migrasi kritis. Selama pembekuan, drift dipantau dan dicatat, tetapi tidak ada perubahan otomatis yang diizinkan. Tim dapat mengaktifkan kembali rekonsiliasi setelah pembekuan berakhir dan setelah memastikan bahwa semua perubahan yang sah telah dicatat dalam kode.

Aturan Pengecualian untuk Resource Dinamis

Beberapa resource berubah sering di luar pipeline karena desain. Grup auto-scaling menyesuaikan ukuran berdasarkan beban. Alat monitoring secara otomatis menyesuaikan konfigurasi. Resource ini harus dikecualikan dari rekonsiliasi otomatis atau diberikan aturan khusus yang mengizinkan jenis drift tertentu.

Misalnya, di Terraform Anda dapat menggunakan blok lifecycle dengan ignore_changes untuk mencegah pipeline mengembalikan penyesuaian dinamis yang sah:

resource "aws_autoscaling_group" "app" {
  name               = "production-app-asg"
  min_size           = 2
  max_size           = 10
  desired_capacity   = 4
  launch_configuration = aws_launch_configuration.app.id
  vpc_zone_identifier = ["subnet-abc123", "subnet-def456"]

  lifecycle {
    ignore_changes = [
      desired_capacity,
      min_size,
      max_size,
    ]
  }
}

Ini memberi tahu Terraform untuk mengabaikan perubahan pada parameter scaling, sehingga scaling manual selama lonjakan beban tidak akan dikembalikan.

Ini bukan tentang membuat pengecualian terhadap aturan. Ini tentang mengakui bahwa beberapa infrastruktur pada dasarnya dinamis, dan memperlakukan perubahan operasional normalnya sebagai drift justru menciptakan lebih banyak masalah daripada solusi.

Daftar Periksa Praktis

Sebelum mengaktifkan rekonsiliasi otomatis untuk grup resource mana pun, verifikasi poin-poin berikut:

  • Dapatkah tim menimpa atau menjeda rekonsiliasi selama insiden?
  • Apakah ada jendela rekonsiliasi yang ditentukan yang mengecualikan jam di luar jam kerja?
  • Apakah resource dinamis seperti grup auto-scaling dikecualikan atau diberikan aturan khusus?
  • Apakah pipeline memerlukan persetujuan manusia sebelum menerapkan perubahan rekonsiliasi?
  • Apakah ada proses terdokumentasi untuk mengadopsi drift yang sah kembali ke dalam kode?

Inti Sebenarnya

Rekonsiliasi otomatis adalah alat, bukan kebijakan. Ia bekerja dengan baik ketika infrastruktur Anda stabil, semua perubahan melalui pipeline, dan insiden jarang terjadi. Ia bekerja melawan Anda ketika operasi berantakan, keadaan darurat terjadi, dan manusia perlu membuat keputusan berdasarkan penilaian.

Tim yang menangani ini dengan baik tidak mengotomatiskan segalanya. Mereka mengotomatiskan deteksi dan notifikasi drift, tetapi tetap menyerahkan keputusan untuk merekonsiliasi ke tangan manusia. Mereka membangun jendela dan pembekuan yang sesuai dengan realitas operasional mereka. Mereka mengecualikan resource yang seharusnya dinamis.

Infrastruktur Anda akan menyimpang dari kode Anda. Sebagian dari drift itu akan menjadi masalah. Sebagian lagi akan menjadi alasan layanan Anda tetap berjalan. Tujuannya bukan untuk menghilangkan drift. Tujuannya adalah memiliki kendali yang cukup untuk mengetahui jenis drift mana yang Anda hadapi sebelum bertindak.