manage software releases

Pipeline CI/CD dengan gerbang keamanan berlapis dan deploy GitOps yang teruji memblokir

Bangun pipeline untuk aplikasi contoh (disediakan) atau aplikasi Anda sendiri. Buktikan setiap gerbang bekerja dengan menyiapkan merge request yang sengaja berbahaya: rahasia yang ter-commit, dependensi rentan, image dengan kerentanan kritis, dan IaC yang membuka akses publik. Tahapan pengerjaan • Kerangka: Desain pipeline, daftar gerbang beserta kebijakan blokir atau peringatan, dan alasannya. • Draf: Pipeline berjalan dengan pemindaian kode, rahasia, dan dependensi. • Revisi: Pemindaian kontainer dan IaC, deploy GitOps, dan umpan balik reviewer ditindaklanjuti. • Final: Empat merge request berbahaya terblokir dengan bukti, SBOM dan tanda tangan artefak, serta kebijakan pengecualian.

Yang diserahkan: Tautan repositori dengan konfigurasi pipeline, tautan ke empat merge request uji beserta hasil pipeline-nya, dan dokumen kebijakan keamanan pipeline maksimal 3 halaman.

• Gerbang yang terbukti bekerjabobot 35% · skor 0–4

  Keempat perubahan berbahaya benar-benar terblokir dengan pesan yang jelas bagi pengembang.

• Desain kebijakanbobot 25% · skor 0–4

  Keseimbangan antara memblokir dan memperingatkan dibenarkan; pengecualian punya proses dan tenggat.

• Rantai pasokbobot 20% · skor 0–4

  SBOM dihasilkan dan artefak ditandatangani serta diverifikasi saat deploy.

• Deploy GitOpsbobot 20% · skor 0–4

  Deploy deklaratif, bisa diaudit, dan bisa dikembalikan ke versi sebelumnya.

Lapisan operasional produksi untuk satu aplikasi LLM: gerbang evaluasi, gateway, pemantauan, dan runbook

Ambil satu aplikasi LLM yang sudah berjalan dan siapkan untuk produksi. Anda menentukan sendiri target kualitas, latensi, dan biaya, lalu membuktikan sistem Anda menegakkannya. Simulasikan minimal dua insiden (penyedia model mati, dan kualitas turun setelah ganti prompt) dan tunjukkan bagaimana sistem Anda menanganinya. Tahapan pengerjaan • Kerangka: Target layanan (kualitas, latensi p95, biaya per permintaan), arsitektur operasional, rencana evaluasi, dan analisis biaya awal API vs model sendiri. • Draf: Gerbang evaluasi di CI berjalan, gateway dengan satu cadangan penyedia aktif, dan dasbor dasar. • Revisi: Model terbuka dilayani sendiri dan dibandingkan secara terukur, pemantauan kualitas aktif, dan umpan balik reviewer ditindaklanjuti. • Final: Simulasi dua insiden beserta buktinya, runbook, dan laporan keputusan akhir: apa yang Anda pilih dan berapa biayanya.

Yang diserahkan: Tautan repositori (konfigurasi CI, gateway, dan infrastruktur sebagai kode), tangkapan dasbor, runbook, dan laporan keputusan maksimal 4 halaman berisi tabel biaya dan latensi.

• Kualitas keputusan operasionalbobot 25% · skor 0–4

  Pilihan API vs model sendiri, cache, dan cadangan dibenarkan dengan angka biaya dan latensi, bukan selera.

• Gerbang evaluasi yang bermaknabobot 25% · skor 0–4

  Rilis yang menurunkan kualitas benar-benar terblokir; set uji mewakili penggunaan nyata.

• Ketahanan terhadap kegagalanbobot 20% · skor 0–4

  Insiden yang disimulasikan tertangani sesuai target; degradasi terkendali, tidak mati total.

• Observabilitasbobot 20% · skor 0–4

  Kualitas, latensi, token, dan biaya terlihat per fitur dan cukup untuk mendiagnosis insiden.

• Runbook dan dokumentasibobot 10% · skor 0–4

  Runbook bisa diikuti engineer lain yang tidak membangun sistem ini.