Pertanyaan
Ceritakan tentang momen ketika Anda mendapati bahwa sebuah build lolos pengujian tetapi provenance atau tanda tangannya tidak dapat diverifikasi, dan Anda mengubah keputusan rilis. Pewawancara sedang menguji cara Anda menilai bukti, memengaruhi tim tanpa otoritas langsung, dan memulihkan delivery dengan aman.
Konteks dan batasan
Gunakan rilis nyata, pembaruan dependensi, atau peninjauan supply-chain. Jelaskan bukti apa yang ada, apa yang belum diketahui, seberapa ketat jendela rilisnya, dan wewenang apa yang Anda miliki. Jangan menyamakan tanda tangan yang hilang dengan kode berbahaya, dan jangan menyajikan bukti yang baru ditambahkan kemudian seolah-olah sudah ada pada saat itu.
Apa yang sedang diuji oleh pewawancara
Keahlian intinya adalah penilaian bukti dan komunikasi risiko: membedakan antara "build berhasil" dan "build berasal dari proses yang sah", kemudian menetapkan gate menggunakan digest yang dapat diverifikasi, tanda tangan, identitas, dan stempel waktu. GitHub mendokumentasikan artifact attestations sebagai cara untuk menetapkan di mana dan bagaimana perangkat lunak dibangun, dengan verifikasi kriptografis terhadap tanda tangan dan identitas penandatangan; Google SRE menekankan catatan keputusan berbasis fakta dan pekerjaan tindak lanjut yang meningkatkan sistem.
Perjelas poin-poin ini terlebih dahulu:
- Apakah rilis tersebut merupakan layanan internal, paket yang dapat diunduh pelanggan, atau image kontainer?
- Apakah celahnya berupa tanda tangan, identitas build, tautan sumber, SBOM, atau pengikatan (binding) antara bukti-bukti tersebut?
- Siapa yang dapat menyetujui rilis, tindakan mana yang dapat dibatalkan (reversible), dan kapan tenggat waktu keputusannya?
- Bisakah Anda membatasi cakupan, mempertahankan versi sebelumnya, atau membuat rebuild yang dapat diaudit terlebih dahulu?
Jawaban 30 detik
Gunakan STAR-L: Situation menyatakan sasaran rilis dan celah bukti; Task menyebutkan hasil pengguna atau kepatuhan yang Anda lindungi; Action menjelaskan bagaimana Anda memeriksa digest, tanda tangan, dan identitas alur kerja, mengusulkan gate bertingkat, serta mengoordinasikan pengumpulan bukti; Result memberikan informasi penundaan, cakupan, dan perubahan risiko; Learning menjelaskan bagaimana pemeriksaan bukti baru tersebut dimasukkan ke dalam pipeline.
Pembahasan mendalam langkah demi langkah
- Bekukan kesimpulan: catat digest artefak kandidat, hasil pengujian, alur kerja build, dan bukti yang ada, pisahkan fakta dari hipotesis.
- Tentukan bukti minimum: digest harus cocok dengan objek rilis, dan bukti harus mengikat repositori, commit, alur kerja, dan identitas penandatangan; tandai kasus sebagai Unknown jika ada tautan yang hilang.
- Tawarkan opsi bertingkat: blokir artefak berisiko tinggi; untuk artefak berisiko rendah, pertahankan versi lama atau gunakan canary internal kecil, tanpa melewati catatan audit.
- Verifikasi bersama: bagikan satu daftar periksa bukti kepada pemilik build, rilis, keamanan, dan bisnis, dengan menetapkan penanggung jawab dan tenggat waktu untuk setiap item.
- Pulihkan dan lacak: hanya rilis artefak yang cocok dengan digest setelah verifikasi, catat alasan pengecualian, pemberi persetujuan, dan tindakan tindak lanjut.
Contoh jawaban
“Sebuah perbaikan mendesak berhasil lolos setiap pengujian, tetapi sistem rilis tidak dapat mengambil tanda tangan yang terikat pada commit SHA. Pertama-tama saya mencatat digest image, hasil pengujian, dan log build, mengonfirmasi bahwa masalahnya adalah bukti yang hilang, bukan ketidakcocokan digest. Karena versi tersebut ditujukan untuk pelanggan, saya mengusulkan untuk menjeda rilis eksternal sambil tetap mempertahankan versi lama dan membuat canary internal. Saya bekerja sama dengan tim build untuk menambahkan identitas alur kerja dan penandatanganan, meminta tim keamanan memverifikasi tanda tangan dengan kredensial independen, dan menyepakati batas waktu pemulihan terakhir dengan pemilik rilis. Rilis ditunda selama 90 menit; canary dan rollback selesai sesuai rencana. Kami kemudian menjadikan pencocokan digest, verifikasi tanda tangan, dan persetujuan pengecualian sebagai gate wajib. Saya belajar untuk mengodekan gate bukti sebagai pemeriksaan otomatis sebelum krisis terjadi, menyisakan penilaian manusia hanya untuk pengecualian yang terdokumentasi.”
Kesalahan umum
- Menganggap rangkaian pengujian yang hijau (lolos) sebagai bukti yang cukup atas asal-usul yang tepercaya.
- Mengatakan "tambahkan tanda tangan" tanpa menjelaskan apa yang diikatnya, siapa yang menandatangani, atau bagaimana cara memverifikasinya.
- Menggunakan risiko keamanan untuk mengesampingkan tujuan bisnis tanpa opsi versi lama, canary, atau batas waktu.
- Menggambarkan tim build sebagai penghalang alih-alih menyelaraskan langkah dalam verifikasi bersama.
- Hanya melaporkan apakah rilis berhasil atau tidak, tanpa menyebutkan biaya penundaan, cakupan, atau gate tindak lanjut.
Jawaban yang kuat memiliki garis waktu faktual, membedakan digest artefak, asal build, dan identitas penandatangan, mengusulkan opsi yang dapat dibatalkan sesuai dengan tingkat risiko, menjelaskan cara memengaruhi tanpa otoritas, dan mengukur hasilnya. Jawaban yang lemah hanya berkutat pada "meningkatkan keamanan" atau memperlakukan intuisi pribadi sebagai bukti.
Pertanyaan lanjutan dan tanggapan
Bagaimana jika pemilik bisnis meminta Anda untuk merilisnya sekarang dan menambahkan buktinya nanti?
Konfirmasikan audiens rilis dan dampak terburuknya, lalu usulkan opsi yang dapat dibatalkan seperti mempertahankan versi lama, canary internal, atau cakupan yang lebih sempit. Jika pengecualian tetap diperlukan, catat item yang belum diverifikasi, pemberi persetujuan, tenggat waktu, dan kondisi rollback; jangan melabeli pengecualian tersebut sebagai patuh (compliant).
Jika tanda tangannya valid tetapi commit berasal dari repositori atau branch yang tidak disetujui, bisakah Anda merilisnya?
Tidak bisa hanya berdasarkan validitas tanda tangan saja. Verifikasi identitas penandatangan, repositori, commit, alur kerja, dan lingkungan terhadap kebijakan; setiap kegagalan pengikatan (binding) akan dialihkan ke peninjauan atau memblokir rilis.
Bagaimana Anda menunjukkan bahwa gate baru ini tidak menimbulkan waktu tunggu yang tak ada habisnya?
Berikan pemeriksaan otomatis, penanggung jawab, dan tenggat waktu untuk setiap item bukti. Lacak pemblokiran, waktu pemulihan rata-rata, dan tingkat pengecualian; tinjau setiap pengecualian dan kurangi penantian manual seiring waktu.
Daftar periksa wawancara
Kesimpulan satu kalimat
Tingkatkan dari "build lolos" menjadi "artefak, asal-usul, identitas, dan keputusan dapat diverifikasi", lalu gunakan opsi yang dapat dibatalkan untuk menyeimbangkan pengiriman dan risiko.