Saat Infrastruktur Melenceng: Cara Memutuskan Apakah Harus Diperbaiki atau Diterima

Anda membuka dasbor infrastruktur pada Senin pagi. Sekilas semuanya tampak baik-baik saja. Lalu Anda menyadarinya: ukuran instance database berbeda dari yang didefinisikan oleh kode Terraform Anda. Seseorang mengubahnya melalui konsol cloud akhir pekan lalu. Pipeline tidak berjalan. Kode mengatakan satu hal, tetapi infrastruktur aktual mengatakan hal lain.

Inilah yang disebut drift. Ini terjadi lebih sering daripada yang diakui kebanyakan tim. Seseorang melakukan perubahan manual saat insiden. Penyedia cloud memperbarui properti sumber daya secara otomatis. Seorang rekan mengubah aturan security group secara langsung karena perlu dilakukan dengan cepat. Apa pun penyebabnya, kini ada celah antara apa yang dideklarasikan kode Anda dan apa yang benar-benar ada di infrastruktur Anda.

Pertanyaannya bukan apakah drift akan terjadi. Itu pasti akan terjadi. Pertanyaan sebenarnya adalah apa yang Anda lakukan setelah mendeteksinya.

Tiga Jalur Menuju Rekonsiliasi

Rekonsiliasi adalah proses mengembalikan infrastruktur agar selaras dengan definisi kode Anda. Namun, tidak ada satu cara yang benar untuk melakukannya. Pendekatan terbaik tergantung pada situasi, risiko yang terlibat, dan konteks di balik perubahan.

Gunakan pohon keputusan ini untuk menentukan jalur yang sesuai dengan situasi Anda:

flowchart TD A[Drift terdeteksi] --> B{Tahu penyebabnya?} B -- Tidak --> C[Selidiki dulu] B -- Ya --> D{Disengaja?} D -- Tidak --> E[Jalankan ulang pipeline] D -- Ya --> F{Perubahan bermanfaat?} F -- Ya --> G[Adopsi drift] F -- Tidak --> H{Sumber daya melayani traffic?} H -- Ya --> I[Perbaikan manual] H -- Tidak --> E C --> D

Jalur Satu: Jalankan Ulang Pipeline

Opsi paling langsung adalah menjalankan pipeline Anda lagi tanpa mengubah kode apa pun. Anda mengambil Infrastructure as Code (IaC) yang sudah ada, membiarkannya persis seperti apa adanya, dan menjalankan langkah apply. Alat seperti Terraform, Pulumi, atau AWS CloudFormation akan membandingkan state file dengan sumber daya aktual dan melakukan penyesuaian yang diperlukan untuk mengembalikan semuanya sesuai dengan definisi kode.

Ini bekerja dengan baik ketika drift terjadi secara tidak sengaja. Seseorang mengubah ukuran instance melalui konsol tanpa sadar telah melewati pipeline. Seorang pengembang untuk sementara membuka port security group untuk debugging dan lupa menutupnya. Sebuah tugas terjadwal dari tim lain memodifikasi tag pada sumber daya Anda. Dalam kasus ini, menjalankan ulang pipeline bersih dan aman. Kode mewakili kondisi yang diinginkan, dan infrastruktur hanya perlu mengejar ketertinggalan.

Risiko di sini rendah karena perubahannya tidak disengaja. Anda sedang mengoreksi kesalahan, bukan membatalkan keputusan yang disengaja.

Jalur Dua: Adopsi Drift

Terkadang perubahan manual justru adalah hal yang benar. Saat insiden produksi, tim operasi Anda menaikkan skala database untuk menangani lonjakan traffic. Aplikasi tetap berjalan karena perubahan itu. Setelah insiden, Anda menyadari kapasitas baru lebih sesuai untuk beban kerja saat ini. Nilai lama di kode Anda kini sudah usang.

Dalam kasus ini, mengembalikan ke kode lama akan menjadi kesalahan. Anda akan membatalkan perbaikan yang membuat sistem tetap berjalan. Sebaliknya, perbarui IaC Anda untuk mencerminkan kondisi baru. Ini disebut mengadopsi drift. Anda mengubah kode agar sesuai dengan yang sebenarnya berjalan, lalu jalankan pipeline untuk memastikan semuanya konsisten.

Mengadopsi drift menjaga pipeline Anda sebagai sumber kebenaran tunggal sambil mempertahankan perubahan yang terbukti berguna. Namun, ini memerlukan evaluasi yang cermat. Anda perlu memahami mengapa perubahan dibuat, apakah sudah diuji, dan apakah menimbulkan efek samping. Mengadopsi drift tanpa tinjauan dapat mengubah IaC Anda menjadi kumpulan keputusan tak terdokumentasi yang berantakan.

Jalur Tiga: Perbaikan Manual

Ada situasi di mana menjalankan pipeline otomatis terlalu berisiko. Sumber daya yang mengalami drift sedang melayani traffic langsung. Perubahan security group melindungi endpoint kritis. Konfigurasi load balancer sedang menyeimbangkan permintaan antar instance. Jika pipeline Anda menerapkan perubahan secara otomatis, hal itu dapat menyebabkan gangguan singkat atau bahkan outage total.

Dalam kasus ini, perbaikan manual adalah pilihan yang lebih aman. Seseorang dengan akses ke konsol cloud atau server memeriksa perubahan satu per satu, mengembalikannya dengan hati-hati, dan memantau dampaknya secara real-time. Ini lebih lambat dan lebih padat karya, tetapi memberi Anda kendali atas urutan dan waktu setiap perubahan.

Perbaikan manual bukanlah kegagalan otomatisasi. Ini adalah pengakuan bahwa beberapa sumber daya membutuhkan penilaian manusia selama pemulihan. Kuncinya adalah mendokumentasikan apa yang dilakukan dan mengapa, sehingga lain kali drift yang sama muncul, Anda dapat memutuskan apakah akan mengotomatiskan perbaikannya.

Siapa yang Harus Memutuskan?

Rekonsiliasi bukanlah keputusan teknis murni. Ini membutuhkan konteks. Apakah drift disebabkan oleh kesalahan, insiden, atau eksperimen yang tidak pernah dicatat? Jawabannya menentukan jalur mana yang harus diambil.

Keputusan harus melibatkan orang-orang yang memahami perubahan dan dampaknya. Itu bisa berupa tim operasi yang menangani insiden, pengembang yang melakukan perbaikan manual, atau platform engineer yang memantau perilaku sistem. Satu orang yang membuat keputusan sendirian dapat dengan mudah salah menilai situasi.

Aturan praktis sederhana: jika Anda tidak tahu mengapa drift terjadi, jangan lakukan rekonsiliasi secara otomatis. Selidiki dulu. Jalankan ulang hanya jika Anda yakin perubahannya tidak disengaja. Adopsi hanya jika Anda yakin perubahannya bermanfaat. Perbaiki secara manual jika Anda tidak yakin tentang keduanya.

Daftar Periksa Praktis untuk Keputusan Rekonsiliasi

Sebelum Anda bertindak berdasarkan peringatan deteksi drift, lalui pertanyaan-pertanyaan ini:

  • Apakah saya tahu siapa yang membuat perubahan ini dan mengapa?
  • Apakah perubahan ini dibuat saat insiden atau di bawah tekanan waktu?
  • Apakah sumber daya yang mengalami drift saat ini melayani traffic produksi?
  • Apakah mengembalikan perubahan ini akan menyebabkan masalah yang diketahui?
  • Apakah ada catatan perubahan ini di tiket, obrolan, atau runbook?

Jika jawaban untuk pertanyaan pertama adalah tidak, mulailah dengan investigasi, bukan tindakan. Jika sumber daya melayani traffic, utamakan perbaikan manual daripada apply otomatis. Jika perubahan dibuat saat insiden, pertimbangkan untuk mengadopsi drift setelah tinjauan yang tepat.

Rekonsiliasi Bukanlah Akhir

Setelah Anda melakukan rekonsiliasi, pekerjaan belum selesai. Anda perlu memastikan bahwa rekonsiliasi tidak menimbulkan masalah baru. Apply otomatis yang mengembalikan perbaikan keamanan kritis dapat membuat sistem Anda terekspos. Perubahan manual yang diadopsi tanpa pengujian dapat menyebabkan ketidakstabilan.

Tujuannya bukan untuk menghilangkan drift. Tujuannya adalah menanganinya dengan cara yang menjaga keandalan sistem dan kebermaknaan kode Anda. Setiap peristiwa drift juga merupakan peluang untuk meningkatkan proses Anda. Jika drift yang sama terus muncul, mungkin pipeline Anda memerlukan guardrail. Jika perubahan manual terlalu sering terjadi, mungkin proses respons insiden Anda memerlukan jalur yang lebih jelas untuk pembaruan kode pasca-insiden.

Intisari Konkret

Drift bukanlah tanda bahwa infrastruktur Anda rusak. Ini adalah tanda bahwa sesuatu terjadi di luar pipeline Anda. Respons yang tepat tergantung pada konteks, bukan dogma. Jalankan ulang jika perubahannya tidak disengaja. Adopsi jika perubahannya berguna. Perbaiki secara manual jika risikonya tinggi. Dan selalu, selalu pahami mengapa drift terjadi sebelum Anda memutuskan apa yang harus dilakukan selanjutnya.