ICT capacity planning strategies

Infrastruktur sebagai kode dan deployment Kubernetes untuk aplikasi AI tiga komponen

Deploy aplikasi AI tiga komponen (API, worker, basis data; aplikasi contoh disediakan) ke cloud pilihan Anda memakai Terraform dan Kubernetes. Reviewer akan membaca kode Anda untuk menilai apakah infrastruktur bisa dibangun ulang dari nol. Tetapkan anggaran bulanan dan buktikan infrastruktur Anda berada di bawahnya. Tahapan pengerjaan • Kerangka: Diagram arsitektur, pilihan layanan cloud beserta alasannya, dan estimasi biaya bulanan. • Draf: Terraform membuat klaster dan jaringan; aplikasi berjalan di Kubernetes. • Revisi: Rahasia dikelola dengan benar, autoscaling teruji dengan uji beban sederhana, dan umpan balik reviewer ditindaklanjuti. • Final: Bukti pemulihan dari kehilangan basis data, perbandingan biaya aktual dengan estimasi, dan prosedur pembongkaran infrastruktur.

Yang diserahkan: Tautan repositori berisi Terraform dan manifest Kubernetes, README untuk membangun ulang dari nol, hasil uji beban, dan laporan biaya.

• Reprodusibilitas infrastrukturbobot 30% · skor 0–4

  Infrastruktur bisa dibangun ulang dan dibongkar hanya dari kode; tidak ada langkah manual tersembunyi.

• Ketepatan deployment Kubernetesbobot 25% · skor 0–4

  Sumber daya, probe kesehatan, dan autoscaling dikonfigurasi dengan benar dan teruji.

• Keamanan dasarbobot 20% · skor 0–4

  Rahasia tidak ada di repositori, kontainer berjalan sebagai non-root, akses jaringan dibatasi.

• Kendali biayabobot 15% · skor 0–4

  Estimasi masuk akal dan biaya aktual dilaporkan jujur terhadap anggaran.

• Pemulihanbobot 10% · skor 0–4

  Pencadangan dan pemulihan basis data terbukti berjalan.

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.