Verifikasi Produk, Strategi Rilis, dan Alur Kerja AI End-to-End

Keuntungan:

Memahami strategi rilis yang mengurangi risiko (biru-hijau, canary, feature flag) dan disiplin verifikasi produk (pemeriksaan kesehatan, tes asap, pemantauan sinyal emas)
Kemampuan untuk menerapkan kebiasaan menyiapkan rencana rollback yang jelas sebelum penerapan dan memverifikasi jalur bisnis penting setelah penerapan
Kemampuan untuk menggabungkan semua bagian yang dipelajari sepanjang modul dalam alur kerja yang didukung AI ujung ke ujung dan menerapkan prinsip 'produksi AI, verifikasi dan jaminan manusia' di setiap langkah

Keseluruhan modul ini mengalir menuju satu titik: pengiriman kode dan infrastruktur yang aman ke produksi (lingkungan langsung yang digunakan oleh pelanggan nyata). Kini kita berada pada titik paling kritis dan menegangkan dalam rantai ini: mewujudkan perubahan dan memverifikasi bahwa perubahan tersebut benar-benar berhasil. Kesalahan di sini tidak bersifat abstrak — kesalahan ini berdampak langsung pada pelanggan, pendapatan, dan reputasi. Itu sebabnya tim yang matang melakukan produksi bukan dengan "berharap" tetapi dengan strategi rilis terkontrol dan verifikasi sistematis.

Dalam unit akhir ini kami menggabungkan dua hal: (1) metode rilis yang mengurangi risiko (canary, blue-green, feature flag) dan disiplin verifikasi produk; (2) bagaimana setiap bagian yang kita pelajari di seluruh modul—CI/CD, IaC, container, pemantauan, insiden, biaya, skrip, keamanan—digabungkan menjadi satu alur kerja end-to-end yang didukung AI. Mari ulangi kutipan awal untuk terakhir kalinya: AI menghasilkan dan mempercepat draf di setiap langkah; Namun Andalah yang menekan tombol "Saya menayangkan ini secara langsung" dan menjamin hasilnya.

Lepaskan strategi yang mengurangi risiko

Mendorong perubahan ke semua pengguna secara bersamaan adalah cara yang paling berisiko. Metode yang matang:

Penerapan Biru-Hijau: Dua lingkungan identik dipertahankan — “biru” (langsung) dan “hijau” (versi baru). Versi baru disiapkan dan diuji dalam warna hijau, lalu lalu lintas tiba-tiba beralih ke hijau. Jika ada masalah, lalu lintas langsung kembali menjadi biru. Rollback cepat adalah keuntungan terbesarnya.
Canary Deployment: Versi baru pertama kali dirilis ke sebagian kecil pengguna (misalnya 5%); Jika metriknya bagus, tingkatkan secara bertahap hingga 100%. Suatu masalah berdampak pada sebagian kecil pengguna, bukan keseluruhan pengguna.
Bendera Fitur: Fitur baru memasukkan kode tetapi diblokir oleh bendera; Itu dibuka untuk pengguna tertentu ketika diminta. Ada perbedaan antara penerapan dan "rilis"; Jika ada masalah, bendera dimatikan tanpa mengembalikan kode.

Tip: Jaring pengaman tercepat adalah menyiapkan rollback sebelum setiap penerapan. “Jika terjadi kesalahan, bagaimana saya bisa kembali ke versi lama dalam 60 detik?” Jika tidak ada jawaban yang jelas atas pertanyaan tersebut, Anda belum siap melakukan penerapan tersebut.

Verifikasi produk: pekerjaan tidak berakhir ketika penerapan berakhir

Hanya karena penerapan terlihat "ramah lingkungan" bukan berarti penerapannya berhasil. Verifikasi sistematis:

Pemeriksaan kesehatan: Apakah layanan sudah aktif, apakah /healthz merespons?
Tes asap: Apakah beberapa jalur pengguna yang paling penting (login, pembayaran, pencarian) benar-benar berfungsi? Otomatis dan cepat.
Perhatikan sinyal emas: Tingkat kesalahan pasca penerapan, latensi, apakah lalu lintas normal? (Empat sinyal pada unit 6.)
Perluas secara bertahap: Lihat metrik di setiap langkah saat Anda meningkatkan persentase Canary.
Jendela observasi: Pantau dengan cermat selama jangka waktu tertentu (misalnya 30 menit) setelah penerapan; Masalah-masalah berbahaya tidak langsung terlihat.

Perhatian: AI mungkin menghasilkan daftar tes asap atau verifikasi, tetapi tugas Anda adalah menentukan jalur pengguna mana yang "penting". AI memberikan daftar umum; Hanya Anda yang tahu bahwa alur pembayaran Anda, jalur yang paling menghasilkan pendapatan, harus diuji.

Perbandingan strategi rilis

Strategi

Keuntungan utama

Biaya/kompleksitas

paling cocok

Biru-Hijau

Pengembalian instan

Dua lingkungan = 2x sumber daya

Jika pengambilan cepat sangat penting

kenari

Membatasi dampak pada bagian kecil

Diperlukan manajemen lalu lintas

Basis pengguna yang besar

FiturBendera

Pisahkan penerapan dari rilis

Utang pengelolaan bendera

Pembukaan bertahap/tertarget

Pembaruan bergulir

Sederhana, ramah sumber daya

kemunduran lambat

Layanan sederhana

Alur kerja yang didukung AI secara menyeluruh

Sekarang mari gabungkan seluruh modul menjadi satu aliran. Katakanlah Anda menerbitkan layanan mikro baru. AI menghasilkan draf di setiap langkah; Anda memverifikasi di setiap langkah:

Kode & wadah (Unit 4): AI menghasilkan Dockerfile yang dioptimalkan dan aman; Anda memverifikasi tanpa rahasia dan ukurannya.
CI/CD (Unit 2): Menulis pipeline AI test-build-deploy; Anda mempersempit izin dan memeriksa referensi rahasia.
Infrastruktur (Unit 3): Menentukan sumber daya yang dibutuhkan dengan AI Terraform; Anda membaca keluaran rencana dan tidak mencari penghapusan yang tidak terduga.
Orkestrasi (Unit 5): AI menghasilkan manifes Kubernetes; Anda memverifikasi batas sumber daya, penyelidikan, dan RBAC.
Keamanan (Unit 10): Memprioritaskan keluaran pemindaian AI; Anda ambil yang bisa dieksploitasi terlebih dahulu.
Pemantauan (Unit 6): AI menghasilkan aturan alarm dan dasbor; Anda menguji ambang batas dengan data Anda sebelumnya.
Rilis & validasi (unit ini): Menguraikan pengujian asap AI dan rencana rollback; Anda memulai canary, perhatikan metriknya, tekan tombol.
Jika insiden terjadi (Unit 7): AI menghasilkan hipotesis dan sketsa postmortem; Anda memverifikasi dan mempelajari pelajarannya.
Biaya (Unit 8): AI memantau pemborosan sumber daya baru; Anda membuat keputusan yang tepat.

Di setiap langkah, aturan umum tetap sama: AI memproduksi dan mempercepat, manusia memverifikasi dan menjamin. Inilah inti dari modul ini.

tiga kasus mini

Kasus 1 — kenari membatasi bencana hingga 5%. Sebuah tim memberikan versi baru kepada 5% pengguna dengan canary. Dasbor yang dihasilkan AI segera menunjukkan bahwa tingkat kesalahan melonjak hingga 8% pada potongan ini. Tim mengambilnya kembali tanpa meningkatkannya menjadi 100%; Masalah ini hanya memengaruhi 5% pengguna, dan itu hanya berlangsung beberapa menit. Jika terjadi penerapan besar-besaran, semua pelanggan akan terkena dampaknya.

Kasus 2 — uji asap menemukan jalur yang hilang. AI menawarkan set tes asap, tetapi tidak memiliki aliran "pembayaran". Insinyur itu menambahkannya, mengetahui bahwa aliran pendapatan yang paling penting adalah pembayaran. Tes pasca-penerapan gagal tepat pada langkah checkout — kunci pihak ketiga telah kedaluwarsa. Verifikasi mendeteksi hilangnya pendapatan secara diam-diam dalam hitungan menit.

Kasus 3 — rollback siap disimpan dalam 90 detik. Sebuah tim yang memasang warna biru-hijau mengubah versi baru menjadi hijau; Setelah 2 menit, penundaan menjadi dua kali lipat. Mereka mengubah lalu lintas menjadi biru dalam 90 detik dengan rollback yang mereka persiapkan sebelumnya. Mereka menemukan akar permasalahan (kueri yang lambat di versi baru) tidak di bawah tekanan, kemudian dengan tenang. Jalur rollback yang siap membuat interupsi hampir tidak terlihat.

Empat templat yang dapat disalin

1) Pemilihan strategi rilis:

Saya akan memproduksi layanan berikut: [LAYANAN/KONTEKS: jumlah pengguna, toleransi pemadaman, infrastruktur]. Manakah yang Anda rekomendasikan antara bendera biru-hijau, kenari, dan fitur? Bandingkan keuntungan, biaya, dan kecepatan rollback masing-masing dalam konteks ini. Berikan saran, tetapi nyatakan bahwa saya akan mengambil keputusan akhir.

2) Tes asap/daftar verifikasi:

Menghasilkan rancangan uji asap dan daftar verifikasi untuk [SERVICE] yang akan saya jalankan setelah penerapan: pemeriksaan kesehatan, jalur pengguna paling penting, metrik mana yang harus saya pantau selama berapa menit? Asumsikan saya akan menandai jalur bisnis yang paling penting dan mengosongkan bidang tersebut.

3) Rencana pengembalian:

Saya menggunakan [METODE DEPLOY]. Tuliskan saya rencana rollback yang jelas: dengan perintah/langkah apa saya melakukan rollback ke versi lama, berapa lama waktu yang dibutuhkan, apa risiko rollback itu sendiri (misalnya migrasi basis data tidak dapat dibatalkan), apa yang harus saya periksa sebelum melakukan rollback?

4) Daftar periksa rilis menyeluruh:

Menghasilkan daftar periksa persiapan menyeluruh untuk rilis ke proyek [SERVICE] baru: keamanan kode/gambar, saluran pipa, rencana infrastruktur, pemantauan dan peringatan, pemindaian keamanan, strategi rilis, rollback, dan verifikasi. Periksa setiap item dengan pertanyaan "Apakah saya siap?" Ubah itu menjadi sebuah pertanyaan.

Perintah lemah / Perintah kuat

Lemah: "Bagaimana cara memasukkan ini ke dalam produksi?"

Hasil: tidak ada konteks; AI mencantumkan langkah-langkah penerapan umum, namun tidak mengatasi toleransi risiko, skala pengguna, dan kebutuhan rollback Anda.

Güçlü: "Saya akan memproduksi layanan pembayaran dengan 10 juta pengguna, toleransi saya terhadap waktu henti sangat rendah. Apakah Anda merekomendasikan Canary atau Blue-Green, mengapa? Jalur penting mana yang harus saya uji setelah penerapan, metrik mana yang harus saya pantau berapa menitnya, dan seperti apa rencana rollback 60 detik? Saya akan membuat keputusan akhir."

Perbedaan: perintah kedua memberikan skala, toleransi, dan ekspektasi kemunduran; Hal ini membutuhkan strategi + verifikasi + pembatalan dan menyerahkan keputusan kepada manusia.

Kesalahan umum

Menyebarkan tanpa rencana rollback. Jika tidak ada jalan kembali, setiap penerapan adalah pertaruhan.
Penyebaran big bang. Memberikannya kepada seluruh pengguna sekaligus akan memaksimalkan risikonya.
Dengan asumsi "hijau = berfungsi". Pelayanan yang telah lolos health check kemungkinan akan terputus pada jalur kritis.
Berpikir bahwa Anda meninggalkan jalur bisnis penting menuju AI. Anda harus menandai metode seperti pembayaran.
Tidak memantau setelah penerapan. Masalah-masalah berbahaya tidak muncul pada menit pertama; jendela observasi diperlukan.
Berpikir bahwa migrasi basis data dapat dibalik. Beberapa perubahan tidak dapat dibatalkan; direncanakan secara terpisah.

Singkatnya

Menuju produksi adalah tautan paling penting dalam rantai dan dilakukan bukan dengan "berharap" namun dengan strategi terkendali: biru-hijau memberikan rollback langsung, membatasi efek canary menjadi bagian kecil, memisahkan penerapan tanda fitur dari rilis. Pekerjaan belum selesai ketika penerapan selesai; Verifikasi sistematis melalui pemeriksaan kesehatan, tes asap, dan pemantauan sinyal emas sangat penting. AI menghasilkan dan mempercepat draf di setiap langkah di seluruh modul — mulai dari Dockerfile hingga pipeline, dari Terraform hingga aturan alarm, dari postmortem hingga analisis biaya. Namun tetap ada orang yang berkompeten yang memverifikasi setiap langkah, menekan tombol go live dan menjamin hasilnya. Ini adalah aturan emas DevOps yang didukung AI end-to-end.

Tugas aplikasi

Pilih layanan (nyata atau fiksi) untuk dipublikasikan. (1) Pilih strategi yang sesuai dengan konteks Anda dengan template “Pemilihan strategi rilis” dan tulis alasannya. (2) Buat daftar verifikasi dengan templat "Uji asap / daftar verifikasi" dan tambahkan sendiri jalur bisnis yang paling penting. (3) Siapkan rencana rollback 60 detik dengan templat "Rencana Rollback" dan periksa apakah ada langkah yang tidak dapat diubah di dalamnya.

daftar periksa

[ ] Saya memilih strategi rilis (canary/blue-green/flag) yang sesuai dengan konteks saya.
[ ] Saya memiliki rencana rollback yang jelas dan cepat sebelum penerapan.
[ ] Saya sendiri yang menambahkan jalur bisnis paling penting (misalnya pembayaran) ke pengujian Asap saya.
[ ] Pasca penerapan, saya memantau sinyal emas melalui jendela observasi.
[ ] Saya juga merencanakan langkah-langkah yang tidak dapat diubah (migrasi basis data, dll.).
[ ] Saya memverifikasi cetak biru AI di setiap langkah; Saya membuat keputusan untuk melakukan siaran langsung.

Ujian Modul

1. Manakah dari berikut ini yang merupakan posisi terbaik untuk DevOps dan AI di cloud?

A) Kecerdasan buatan merupakan alat bantu dan pendukung keputusan; Orang bertanggung jawab atas keputusan penting yang mempengaruhi produk ✔
B) Kecerdasan buatan dapat menyelesaikan penerapan produk dan rotasi rahasia tanpa persetujuan manusia
C) Kecerdasan buatan hanya berguna untuk menulis dokumentasi, tidak ada hubungannya dengan infrastruktur
D) Audit tidak diperlukan karena kecerdasan buatan selalu menghasilkan perintah yang lebih andal daripada insinyur

Deskripsi: Ini adalah asisten dan alat pendukung keputusan yang mempercepat tugas-tugas intensif teks seperti pipeline kecerdasan buatan, konfigurasi, skrip, dan log. Tanggung jawab atas keputusan yang memengaruhi waktu henti, uang, dan keamanan, seperti rilis produksi, manajemen rahasia, dan aplikasi akhir, tetap berada pada insinyur yang kompeten.

2. Ekspresi manakah yang paling akurat untuk disiplin verifikasi sebelum menerapkan perintah atau konfigurasi DevOps yang dihasilkan oleh kecerdasan buatan?

A) Jika output terlihat lancar dan percaya diri dapat langsung dijalankan di prod
B) Output aman hanya jika tidak ada kesalahan sintaksis, tidak diperlukan pemeriksaan lebih lanjut
C) Hubungkan output ke sumber, rencanakan/uji coba, dan filter dengan konteks sistem Anda; lalu terapkan ✔
D) Melakukan percobaan pertama langsung di prod dan melihat hasilnya adalah verifikasi tercepat

Penjelasan: Verifikasi tiga langkah sangat penting: menghubungkan output ke sumber (apakah perintah/bendera sebenarnya ada di dokumen resmi), menjalankannya hingga kering (melihat apa yang terjadi dengan rencana/--dry-run), dan meneruskannya melalui filter sistem (apakah sesuai dengan konteks arsitektur dan keamanannya). Kefasihan tidak berarti akurasi.

3. Apa pendekatan yang benar ketika menanyakan kecerdasan buatan tentang kesalahan atau masalah penerapan dengan file .env yang berisi kata sandi database sebenarnya?

A) Tutupi rahasia sebenarnya dengan <PLACEHOLDER>; bagikan hanya kesalahan dan konteks yang terselubung ✔
B) Menempelkan seluruh file .env apa adanya memecahkan masalah lebih cepat
C) Karena rahasianya sudah base64, maka aman untuk menempelkannya biasa saja
D) Menempelkan kata sandi aman karena kecerdasan buatan tidak pernah menyimpannya

Deskripsi: Tidak ada rahasia nyata yang disisipkan ke dalam perintah AI. Nilai seperti kata sandi dan token ditutupi dengan <PLACEHOLDER>; hanya pesan kesalahan dan konteks yang diperlukan yang dibagikan. Jika Rahasia sudah terlanjur bocor, sebaiknya segera dibatalkan dan dirotasi.

4. Manakah dari berikut ini yang merupakan pengelolaan rahasia (kata sandi, token) yang benar dalam saluran CI/CD?

A) Itu disimpan dalam repositori rahasia platform dan dipanggil dengan referensi (misalnya ${{ secret.X }}), tidak ditulis dalam teks biasa ✔
B) Ditulis dalam teks biasa ke saluran pipa YAML untuk kenyamanan
C) Diverifikasi dengan menekan echo dan log di awal setiap pekerjaan.
D) Jika didefinisikan dengan izin terluas (tulis semua), keamanan meningkat

Penjelasan: Rahasia tidak ditulis ke YAML dalam teks biasa; Itu disimpan di repositori rahasia platform dan dipanggil dengan referensi seperti ${{ secret.X }}. Selain itu, dengan prinsip otoritas terkecil, izin token dipersempit dan log rahasia tidak dicatat.

5. Dalam pengelolaan infrastruktur dengan Terraform, langkah paling penting apa yang harus diambil sebelum menerapkan perubahan secara langsung?

A) Menjalankan 'terraform apply' secara langsung; rencananya hanya membuang-buang waktu
B) Mencadangkan file Negara ke repositori publik
C) Jalankan 'terraform plan' dan periksa baris hancurkan/ganti di output, lalu terapkan ✔
D) Copot pemasangan versi Penyedia dan pastikan versi terbaru hadir secara otomatis

Penjelasan: 'terraform plan' harus dijalankan sebelum 'terraform apply'. Rencana tersebut menunjukkan apa yang harus ditambahkan, apa yang harus diubah, dan terutama apa yang harus dihapus (dihancurkan), tanpa melakukan apa pun. Jika garis pemusnahan atau penggantian yang tidak terduga terlihat, penerapan tidak boleh diterapkan.

6. Apa artinya dan apa yang harus dilakukan jika baris '-/+ ganti' untuk database produksi muncul di keluaran rencana Terraform?

A) Sumber hanya akan diperbarui di tempat, tidak ada risiko
B) Sumber daya akan dihapus dan dibuat ulang; Ada risiko kehilangan data, penerapan harus dihentikan jika tidak diharapkan ✔
C) Menambahkan sumber daya baru, database yang ada tidak terpengaruh
D) Ini hanya peringatan, bisa diabaikan dengan aman

Penjelasan: '-/+ ganti' berarti sumber daya akan dihapus dan dibuat ulang; Untuk database, ini berarti kehilangan data. Jika tidak diharapkan, penerapan harus dihentikan, perubahan harus diubah ke metode yang aman, atau bidang yang tidak dapat diubah tidak boleh disentuh.

7. Manakah dari berikut ini yang benar agar Dockerfile siap produksi dalam hal keamanan dan ukurannya?

A) Untuk kenyamanan, menyematkan rahasia pada gambar dengan ENV dan menjalankannya sebagai root
B) Selalu gunakan tag ':latest' dan pertahankan gambar dasar sebesar mungkin
C) Pembuatan satu tahap dan membiarkan semua alat pembuatan pada gambar akhir
D) Tidak menyematkan Rahasia, bekerja dengan PENGGUNA yang tidak sah, menggunakan gambar dasar yang kecil dan stabil serta pembangunan multi-tahap ✔

Deskripsi: Gambar siap produksi: tidak menyematkan rahasia (menyuntikkannya saat runtime), dijalankan dengan USER yang tidak sah, bukan root, menggunakan gambar dasar kecil dan berversi (slim/alpine, bukan :latest), dan diperkecil dengan build multi-tahap. Itu juga dipindai untuk mencari kerentanan sebelum dipublikasikan.

8. Apa risiko terpenting jika tidak menentukan batas sumber daya untuk suatu Deployment di Kubernetes?

A) Pod tidak pernah dimulai karena limit adalah kolom yang wajib diisi
B) Hanya peringatan yang muncul di papan pemantauan, pengoperasian tidak terpengaruh
C) Kubernetes secara otomatis menerapkan batas default yang aman, tanpa risiko
D) Pod dapat tumbuh tanpa batas dan menghabiskan sumber daya node, sehingga membuat layanan tetangganya mogok ✔

Penjelasan: Sebuah Pod yang tidak memiliki batas sumber daya dapat tumbuh tanpa batas, menghabiskan semua sumber daya dari node yang menjalankannya, dan membuat layanan tetangganya crash, misalnya dengan kebocoran memori. Itu sebabnya mendefinisikan permintaan/batas adalah dasar dari ketahanan.

9. Bagaimana cara menghindari 'kelelahan kewaspadaan' dalam pemantauan dan pengaturan alarm?

A) Setel alarm pada sebanyak mungkin metrik dan hasilkan peringatan pada setiap fluktuasi.
B) Atur semua alarm ke tingkat keparahan tertinggi
C) Memicu alarm dengan nilai seketika tanpa mengatur waktu (untuk)
D) Menjaga alarm tetap berorientasi pada tindakan dan pada urgensi yang tepat, menguji ambang batas dengan data historis, menggabungkan yang tidak perlu ✔

Deskripsi: Setiap alarm harus dapat ditindaklanjuti dan memiliki tingkat urgensi yang tepat; Informasi yang tidak memerlukan tindakan ditampilkan di papan, tidak membangunkan siapa pun. Ambang batas alarm diuji terhadap data historis sistem dan alarm yang tidak perlu/berulang dikonsolidasikan. Dengan cara ini alarm sebenarnya tidak akan hilang dalam kebisingan.

10. Apa urutan prioritas terbaik saat terjadi insiden produksi?

A) Pertama-tama temukan akar permasalahan yang sebenarnya dan kurangi hanya jika penyebabnya jelas.
B) Pertama tulis laporan postmortem, lalu sentuh layanannya
C) Kurangi dulu (layanan pemulihan/restore), tinggalkan analisis akar permasalahan untuk nanti ✔
D) Pertama temukan orang yang bertanggung jawab atas kejadian tersebut dan laporkan

Penjelasan: Aturan emasnya adalah 'kurangi dulu, selidiki nanti'. Tujuannya adalah memulihkan layanan terlebih dahulu atau mengembalikannya ke versi yang dikenal baik (mitigasi); Analisis akar permasalahan dilakukan dengan tenang setelah tekanan mereda. Menunggu untuk menemukan akar permasalahan yang tepat akan menambah waktu pemulihan (MTTR).

11. Apa tujuan utama dari budaya postmortem yang tidak bercela?

A) Mengidentifikasi orang yang melakukan kesalahan dan menempatkan tanggung jawab padanya
B) Berfokus pada sistem dan proses dan mendorong pembelajaran; ✔ Belajar pelajaran yang mencegah pengulangan daripada menyalahkan
C) Jangan pernah melaporkan kejadian tersebut dan pastikan bahwa kejadian tersebut dilupakan
D) Hanya menulis rincian teknis dan tidak menambahkan item yang dapat ditindaklanjuti

Penjelasan: Postmortem yang tidak bercela berfokus pada pertanyaan 'sistem dan proses mana yang membiarkan kesalahan ini', bukan 'siapa yang melakukannya'. Orang-orang menceritakan kesalahannya secara terbuka jika mereka tahu bahwa mereka tidak akan dihukum; Kesalahan tersembunyi terulang kembali. Laporan tersebut bukanlah laporan tuduhan, melainkan dokumen pembelajaran yang berisi item-item yang berorientasi pada tindakan.

12. Dalam pengoptimalan biaya cloud (FinOps), langkah apa yang paling logis untuk diambil sebelum beralih ke diskon khusus (Reserved/Savings Plan)?

A) Ambil komitmen yang paling lama dulu, baru pikirkan pemborosan
B) Pertama, bersihkan sampah (penutupan menganggur, ukuran tepat), lalu berkomitmen untuk penggunaan berkomitmen ✔
C) Segera pindahkan semua sumber daya ke kapasitas Spot
D) Menghapus barang termahal tanpa meninjau data faktur

Penjelasan: Sampah harus dibersihkan terlebih dahulu (menutup sumber daya yang menganggur, mengurangi sumber daya yang terlalu besar). Jika tidak, Anda akan mengunci penggunaan yang terbuang dengan harga diskon selama 1-3 tahun. Pembersihan dengan ukuran yang tepat dan tidak memerlukan komitmen dan hampir bebas risiko.

13. Tindakan keamanan apa yang paling penting jika skrip yang disarankan AI memiliki baris 'rm -rf "$DIR"/'?

A) Menjalankan skrip langsung di prod tanpa membacanya akan mempercepat
B) Tambahkan set -euo pipefail dan kosongkan kontrol variabel dan coba dengan dry-run terlebih dahulu ✔
C) Memperpendek nama variabel saja sudah cukup
D) Menggunakan rm -rf --force alih-alih rm menyelesaikan masalah

Penjelasan: Jika $DIR kosong, pernyataan ini mungkin mencoba menghapus direktori root. Berhenti di variabel yang tidak terdefinisi dengan 'set -u' dan memeriksa apakah variabel tersebut tidak kosong sebelum menghapusnya (misalnya [ -n "$DIR" ] || exit 1) menghindari bencana. Selain itu, operasi destruktif harus dicoba dengan uji coba terlebih dahulu.

14. Apa hal pertama yang harus dilakukan jika access key cloud secara tidak sengaja bocor ke repositori publik?

A) Segera membatalkan dan memperbaharui (memutar) kunci; Menghapus saja tidak cukup ✔
B) Hapus saja file dari penyimpanan dan kuncinya aman
C) Tidak melakukan apa pun karena tidak ada yang melihatnya
D) Menjadikan penyimpanan pribadi menghilangkan kebutuhan untuk memutar kunci

Penjelasan: Rahasia yang bocor harus segera dibatalkan dan diputar. Menghapus file saja tidak cukup karena rahasianya tetap ada dalam riwayat Git dan repositori publik dipindai oleh bot dalam hitungan detik. Setelah pembatalan/pengembalian, dampaknya dievaluasi dan pemindai rahasia ditambahkan untuk mencegah terulangnya kembali.

15. Pendekatan manakah berikut ini yang meminimalkan risiko saat merilis Prod versi baru?

A) Memberikan versi baru kepada semua pengguna pada saat yang sama (big-bang) dan tidak menyiapkan rencana rollback
B) Mengingat penerapan selesai segera setelah tampak 'hijau', tidak melakukan verifikasi tambahan
C) Menggunakan strategi terkontrol seperti canary/blue-green/fitur flag, rencana rollback siap pakai dan uji asap + pemantauan metrik setelah penerapan ✔
D) Menyerahkan pengujian jalur bisnis penting sepenuhnya pada kecerdasan buatan dan tidak menentukannya sama sekali.

Penjelasan: Strategi rilis terkontrol (dimulai dengan persentase kecil dengan canary, rollback langsung dengan warna biru-hijau, memisahkan penerapan dari rilis dengan tanda fitur) membatasi risiko. Selain itu, rencana rollback yang jelas sebelum penerapan dan pemantauan sinyal emas dengan pengujian asap setelah penerapan sangat penting; 'tampak hijau' tidak berarti berhasil.