1. Soalan dan Konteks
Pasukan platform perlu menukar peraturan tembok api, had pembayaran, atau penghalaan perkhidmatan. Pemohon tidak boleh meluluskan perubahan mereka sendiri, kelulusan mesti menyasarkan versi yang tepat, dan pelaksanaan yang gagal tidak boleh meninggalkan kemas kini separa. Matlamatnya adalah aliran kerja yang boleh disahkan, boleh diaudit, dan boleh dipulihkan.
2. Perkara yang Dinilai oleh Penemu Duga
- Sama ada anda mengasingkan keadaan cadangan, kelulusan, pelaksanaan, dan rollback.
- Sama ada pelulus adalah bebas dan kandungan yang diluluskan tidak boleh diganti secara senyap.
- Sama ada anda mengendalikan kelulusan serentak, permintaan pendua, tamat masa, pembatalan, dan perubahan kebenaran.
- Sama ada anda menyediakan pelancaran skop kecil dan pemulihan yang stabil sambil mengawal risiko.
NIST SP 800-128 memerlukan perubahan konfigurasi disemak oleh orang yang diberi kuasa yang bebas daripada pemohon. Google SRE menekankan semakan kod untuk versi konfigurasi dan terus menyediakan konfigurasi sebelumnya apabila konfigurasi baharu gagal dalam pemeriksaan. Masukkan prinsip tersebut ke dalam data dan peralihan keadaan.
3. Soalan Penjelasan Sebelum Anda Menjawab
- Sumber dan medan manakah yang berisiko tinggi, dan adakah persekitaran atau penyewa berbeza?
- Adakah kelulusan untuk seorang individu, mana-mana daripada ramai, atau ambang merentasi peranan dan individu?
- Adakah pelaksanaan merupakan pertukaran penuh, pelancaran kelompok, atau pengesahan contoh sasaran?
- Adakah rollback merupakan versi baik terakhir yang diketahui atau versi yang dipilih oleh pemohon?
4. Kerangka Jawapan 30 Saat
Gunakan cadangan tidak boleh ubah (immutable), padanan dasar, pengasingan kelulusan, pelaksana, rollback, dan audit.
Saya membekukan setiap perubahan sebagai versi yang tidak boleh diubah, dan dasar akan memilih pelulus bebas daripada sumber, risiko, dan persekitaran. Kelulusan merekodkan ringkasan (digest) versi dan versi dasar, serta pemohon tidak boleh memenuhi ambang kelulusan. Pelaksana idempoten menerapkan perubahan secara berkelompok dengan pemeriksaan kesihatan. Sebarang kegagalan akan menghentikan pelancaran seterusnya dan memulihkan versi terakhir yang disahkan, manakala setiap keadaan dan keputusan dihantar ke storan audit tambah sahaja (append-only).
5. Huraian Terperinci Langkah demi Langkah
Langkah 1: Tentukan Entiti dan Mesin Keadaan
Cadangan mengandungi sumber, diff, pengarang, digest versi, persekitaran sasaran, dan tempoh luput. Kelulusan mengandungi pelulus, peranan, keputusan, masa, versi dasar, dan digest cadangan. Rekod pelaksanaan mengandungi kelompok, sasaran, hasil, dan versi rollback. Keadaan boleh menjadi DRAFT, PENDING_APPROVAL, APPROVED, EXECUTING, SUCCEEDED, FAILED, REVOKED, atau EXPIRED; hanya peraturan bahagian pelayan boleh melakukan peralihan keadaan ini.
Langkah 2: Jadikan Kelulusan Bebas dan Terikat Versi
Perkhidmatan dasar mengira peranan yang diperlukan, individu, larangan kelulusan sendiri, dan jangka hayat kelulusan. Diff yang ditunjukkan kepada pelulus mesti sepadan dengan cincangan (hash) versi pelaksanaan; sebarang suntingan cadangan akan membatalkan kelulusan dan memulakan semakan baharu. Semak semula kebenaran semasa kelulusan dan pelaksanaan supaya pembatalan peranan kemudiannya tidak boleh dipintas.
Langkah 3: Kawal Pelepasan dengan Pelaksana Idempoten
Jana kunci keidempotenan untuk setiap cadangan dan sasaran, dan rekod akuan terima luaran. Gunakan kelompok kecil selepas pemeriksaan sintaks, kebergantungan, dan keselamatan, kemudian perhatikan isyarat kesihatan. Cuba semula hasil yang tidak diketahui sahaja; jangan sesekali mengulangi operasi bukan idempoten secara membuta tuli. Baris gilir atau enjin aliran kerja mengendalikan tamat masa, percubaan semula, dan had keserentakan.
Langkah 4: Rollback dengan Selamat dan Lakukan Audit
Simpan versi disahkan yang terakhir sebelum pelepasan. Sekiranya berlaku kegagalan, hentikan kelompok seterusnya dan pulihkan versi tersebut. Rekod pengendali dan sebab untuk rollback; rollback kecemasan berisiko tinggi mungkin memerlukan kelulusannya sendiri. Audit sekurang-kurangnya digest cadangan, rantaian kelulusan, kelompok pelaksanaan, versi konfigurasi, sebab kegagalan, dan hasil rollback, dengan pemadaman dan mutasi dihadkan.
6. Contoh Jawapan Berkualiti Tinggi
Saya akan membahagikan sistem kepada API cadangan, perkhidmatan dasar, perkhidmatan kelulusan, baris gilir pelaksanaan, penyesuai konfigurasi, dan storan audit. Cadangan adalah tidak boleh diubah dan mengandungi diff sumber, persekitaran, pengarang, dan tempoh luput. Perkhidmatan dasar mengira peranan yang diperlukan dan bilangan pelulus mengikut risiko, tidak termasuk pengarang.
>
Pelulus melihat digest versi dan diff, dan kelulusan mengikat pada hash cadangan dan versi dasar. Sebarang suntingan mengembalikan cadangan kepada kelulusan yang belum selesai. Sebaik sahaja ambang dipenuhi, pelaksana mencipta kunci keidempotenan daripada ID cadangan dan ID sasaran, menjalankan pemeriksaan statik, kemudian menggunakan kelompok kecil sambil membaca isyarat kesihatan. Permintaan pendua mengembalikan hasil pelaksanaan sedia ada; hasil yang tidak diketahui diserahkan kepada semakan.
>
Setiap cadangan menyimpan versi terakhir yang disahkan. Jika sesuatu kelompok gagal, kelompok seterusnya dihentikan, versi lama dipulihkan, dan sebabnya direkodkan; rollback kecemasan berisiko tinggi masih memerlukan kelulusan bebas. Peristiwa audit adalah append-only dan merekodkan siapa yang meluluskan digest yang mana, bila, sasaran mana yang dijalankan, dan sama ada rollback berlaku. Ini menguatkuasakan pengasingan tugas dan menghalang konfigurasi yang diluluskan daripada diganti secara senyap.
7. Mod Kegagalan Biasa
- Mengikat kelulusan hanya pada ID sumber dan bukannya pada diff dan digest versi yang tepat.
- Membenarkan pengarang meluluskan sendiri melalui peranan kedua.
- Menulis kelulusan terus ke dalam storan konfigurasi tanpa keadaan pelaksanaan atau perakuan.
- Memperluaskan pelancaran selepas kegagalan atau mencuba semula operasi bukan idempoten tanpa henti.
- Melakukan rollback tanpa merekodkan versi, kebenaran, dan bukti audit.
8. Soalan Susulan dan Maklum Balas
Susulan 1: Bagaimana jika pengarang meninggalkan syarikat selepas kelulusan?
Keputusan terikat pada cadangan yang tidak boleh diubah dan tidak memerlukan pengarang berada dalam talian. Pelaksanaan menggunakan akaun perkhidmatan dan dasar semasa; membatalkan pengarang tidak memadamkan rantaian audit yang sah.
Susulan 2: Bagaimanakah anda menghalang dua aliran kelulusan daripada melaksanakan sumber yang sama?
Gunakan kunci atau pajakan (lease) sumber-dan-persekitaran, kemudian semak semula versi konfigurasi semasa sebelum pelaksanaan. Sekiranya berlaku konflik, cadangan yang lebih baharu akan mengira semula diff dan kelulusannya.
Susulan 3: Bolehkah perubahan kecemasan memintas kelulusan?
Tentukan laluan break-glass yang terhad dengan kebenaran dua orang, keistimewaan paling sedikit (least privilege), jangka hayat pendek, semakan pascaperubahan, dan audit lengkap. Ia tidak boleh menjadi jalan pintas biasa.