1. Pertanyaan dan Konteks
Tim platform perlu mengubah aturan firewall, batas pembayaran, atau perutean layanan. Pemohon tidak dapat menyetujui perubahannya sendiri, persetujuan harus menargetkan versi yang tepat, dan eksekusi yang gagal tidak boleh meninggalkan pembaruan parsial. Tujuannya adalah alur kerja yang dapat diverifikasi, dapat diaudit, dan dapat dipulihkan.
2. Hal yang Dievaluasi oleh Pewawancara
- Apakah Anda memisahkan status proposal, persetujuan, eksekusi, dan rollback.
- Apakah pemberi persetujuan bersifat independen dan konten yang disetujui tidak dapat diganti secara diam-diam.
- Apakah Anda menangani persetujuan konkuren, permintaan duplikat, batas waktu, pencabutan, dan perubahan izin.
- Apakah Anda menyediakan peluncuran bertahap berskala kecil dan pemulihan yang stabil sembari mengendalikan risiko.
NIST SP 800-128 mewajibkan perubahan konfigurasi ditinjau oleh orang yang berwenang dan independen dari pemohon. Google SRE menekankan peninjauan kode untuk versi konfigurasi dan terus melayani konfigurasi sebelumnya ketika konfigurasi baru gagal dalam pemeriksaan. Terapkan prinsip-prinsip tersebut ke dalam data dan transisi status.
3. Pertanyaan Klarifikasi Sebelum Anda Menjawab
- Sumber daya dan bidang mana yang berisiko tinggi, dan apakah ada perbedaan antar lingkungan atau penyewa (tenant)?
- Apakah persetujuan dilakukan oleh satu orang, salah satu dari banyak orang, atau ambang batas di berbagai peran dan orang?
- Apakah eksekusi berupa peralihan penuh, peluncuran batch, atau konfirmasi instans target?
- Apakah rollback mengarah ke versi terakhir yang diketahui baik atau versi yang dipilih oleh pemohon?
4. Kerangka Jawaban 30 Detik
Gunakan proposal yang tidak dapat diubah (immutable), pencocokan kebijakan, isolasi persetujuan, eksekutor, rollback, dan audit.
Saya membekukan setiap perubahan sebagai versi yang tidak dapat diubah, dan sebuah kebijakan akan memilih pemberi persetujuan independen berdasarkan sumber daya, risiko, dan lingkungan. Persetujuan mencatat ringkasan (digest) versi serta versi kebijakan, dan pemohon tidak dapat memenuhi ambang batas persetujuan. Eksekutor yang idempoten menerapkan perubahan secara bertahap (batch) dengan pemeriksaan kesehatan. Setiap kegagalan akan menghentikan peluncuran lebih lanjut dan memulihkan versi terverifikasi terakhir, sementara setiap status dan keputusan dicatat ke penyimpanan audit yang hanya dapat ditambahkan (append-only).
5. Pembahasan Mendalam Langkah demi Langkah
Langkah 1: Tentukan Entitas dan Mesin Status
Sebuah proposal berisi sumber daya, diff, pembuat, ringkasan versi, lingkungan target, dan masa berlaku. Sebuah persetujuan berisi pemberi persetujuan, peran, keputusan, waktu, versi kebijakan, dan ringkasan proposal. Catatan eksekusi berisi batch, target, hasil, dan versi rollback. Status dapat berupa DRAFT, PENDING_APPROVAL, APPROVED, EXECUTING, SUCCEEDED, FAILED, REVOKED, atau EXPIRED; hanya aturan sisi server yang dapat mengubah status tersebut.
Langkah 2: Buat Persetujuan Independen dan Terikat Versi
Layanan kebijakan menghitung peran yang diperlukan, individu, larangan persetujuan diri sendiri, dan masa berlaku persetujuan. Diff yang ditampilkan kepada pemberi persetujuan harus menghasilkan hash yang sama dengan versi eksekusi; setiap pengeditan proposal akan membatalkan persetujuan dan memulai peninjauan baru. Periksa kembali izin pada saat persetujuan dan eksekusi sehingga pencabutan peran di kemudian hari tidak dapat dilewati.
Langkah 3: Kontrol Rilis dengan Eksekutor yang Idempoten
Buat kunci idempotensi untuk setiap proposal dan target, lalu catat pengakuan eksternal. Terapkan batch kecil setelah pemeriksaan sintaksis, dependensi, dan keamanan, kemudian amati sinyal kesehatan. Coba lagi hanya untuk hasil yang tidak diketahui; jangan pernah mengulangi operasi non-idempoten secara membabi buta. Antrean atau mesin alur kerja menangani batas waktu, percobaan ulang, dan batas konkurensi.
Langkah 4: Rollback dengan Aman dan Lakukan Audit
Simpan versi terverifikasi terakhir sebelum rilis. Jika terjadi kegagalan, hentikan batch berikutnya dan pulihkan versi tersebut. Catat operator dan alasan rollback; rollback darurat berisiko tinggi mungkin memerlukan persetujuannya sendiri. Audit setidaknya ringkasan proposal, rantai persetujuan, batch eksekusi, versi konfigurasi, alasan kegagalan, dan hasil rollback, dengan pembatasan pada penghapusan dan mutasi data.
6. Contoh Jawaban Berkualitas Tinggi
Saya akan membagi sistem menjadi API proposal, layanan kebijakan, layanan persetujuan, antrean eksekusi, adaptor konfigurasi, dan penyimpanan audit. Proposal bersifat immutable dan berisi diff sumber daya, lingkungan, pembuat, serta masa berlaku. Layanan kebijakan menghitung peran yang diperlukan dan jumlah pemberi persetujuan berdasarkan risiko, tidak termasuk pembuat.
>
Pemberi persetujuan melihat ringkasan versi dan diff, dan persetujuan tersebut mengikat pada hash proposal dan versi kebijakan. Setiap pengeditan akan mengembalikan proposal ke status menunggu persetujuan. Setelah ambang batas terpenuhi, eksekutor membuat kunci idempotensi dari ID proposal dan ID target, menjalankan pemeriksaan statis, lalu menerapkan batch kecil sembari membaca sinyal kesehatan. Permintaan duplikat akan mengembalikan hasil eksekusi yang ada; hasil yang tidak diketahui akan dialihkan ke peninjauan.
>
Setiap proposal menyimpan versi terverifikasi terakhir. Jika sebuah batch gagal, batch berikutnya akan dihentikan, versi lama dipulihkan, dan alasannya dicatat; rollback darurat berisiko tinggi tetap memerlukan persetujuan independen. Peristiwa audit bersifat append-only dan mencatat siapa yang menyetujui ringkasan yang mana, kapan, target mana yang dijalankan, dan apakah terjadi rollback. Hal ini menegakkan pemisahan tugas dan mencegah konfigurasi yang disetujui diganti secara diam-diam.
7. Pola Kegagalan Umum
- Mengikat persetujuan hanya ke ID sumber daya, bukan ke diff dan ringkasan versi yang tepat.
- Membiarkan pembuat menyetujui perubahannya sendiri melalui peran kedua.
- Menulis persetujuan langsung ke penyimpanan konfigurasi tanpa status eksekusi atau pengakuan.
- Memperluas peluncuran setelah terjadi kegagalan atau mencoba ulang operasi non-idempoten tanpa batas.
- Melakukan rollback tanpa mencatat versi, otorisasi, dan bukti audit.
8. Pertanyaan Lanjutan dan Tanggapan
Pertanyaan Lanjutan 1: Bagaimana jika pembuat keluar dari perusahaan setelah persetujuan?
Keputusan terikat pada proposal yang immutable dan tidak memerlukan pembuat untuk tetap online. Eksekusi menggunakan akun layanan dan kebijakan saat ini; mencabut hak pembuat tidak akan menghapus rantai audit yang valid.
Pertanyaan Lanjutan 2: Bagaimana cara mencegah dua alur persetujuan mengeksekusi sumber daya yang sama?
Gunakan penguncian (lock) atau sewa (lease) sumber daya dan lingkungan, lalu periksa kembali versi konfigurasi saat ini sebelum eksekusi. Jika terjadi konflik, proposal yang lebih baru akan menghitung ulang diff dan persetujuannya.
Pertanyaan Lanjutan 3: Bisakah perubahan darurat melewati persetujuan?
Tentukan jalur break-glass yang dibatasi dengan otorisasi dua orang, hak istimewa paling rendah (least privilege), masa berlaku singkat, tinjauan pascaperubahan, dan audit lengkap. Jalur ini tidak boleh menjadi jalan pintas yang lazim.