Konteks dan arahan
Pertanyaan system design platform ini membahas penyimpanan komponen, sistem, domain, API, pemilik, dan tepi dependensi dari repositori, sistem deployment, serta deklarasi manual. Katalog ini berfungsi untuk penemuan (discovery), respons insiden, dan tata kelola; sistem ini tidak boleh menjadi CMDB manual lainnya yang tidak dipercayai oleh siapa pun.
Apa yang dievaluasi oleh pewawancara
- Mengubah kebutuhan "temukan pemilik layanan" menjadi model entitas, kebijakan kepercayaan sumber, dan pengalaman pencarian yang baik.
- Menangani konflik, kedaluwarsa, dan penghapusan antara metadata deklaratif dan pemindaian otomatis.
- Menjelaskan kueri dependensi, isolasi izin, batasan penyewa (tenant), dan SLO kesegaran data.
- Memilih peluncuran platform bertahap yang menyeimbangkan nilai guna dengan biaya pemeliharaan.
Pertanyaan klarifikasi yang perlu diajukan
Konfirmasikan jumlah entitas, volume perubahan harian, keterlambatan metadata, lonjakan kueri, isolasi organisasi atau pelanggan, apakah dependensi bersifat statis atau diamati saat runtime, dan siapa yang dapat mendeklarasikan kepemilikan. Penggunaan pada insiden berisiko tinggi memerlukan tingkat sumber, penanda data usang (stale), dan audit; direktori pengembang dapat dimulai dengan tingkat kesegaran data yang lebih longgar.
Kerangka jawaban 30 detik
Saya akan memodelkan grafik entitas deklaratif: komponen, sistem, domain, API, tim, dan relasi memiliki identitas yang stabil. File katalog repositori memberikan maksud (intent); sinyal deployment dan runtime menambahkan versi serta tepi yang teramati; pengumpul data (collector) menulis peristiwa berversi. Layanan kueri menyajikan pemilik, dependensi balik, dan pencarian sambil menampilkan sumber serta waktu pembaruan. Konflik menjadi status yang dapat ditindaklanjuti, bukan penimpaan data secara diam-diam. Izin diterapkan pada entitas dan bidang (field), dan entitas usang tetap disimpan sebagai riwayat historis tetapi disembunyikan dari hasil default.
Jawaban mendalam langkah demi langkah
1. Memodelkan entitas dan relasi
Model entitas Backstage adalah referensi yang berguna: komponen termasuk dalam sistem, sistem dalam domain, API disediakan atau dikonsumsi oleh komponen, dan tim memiliki komponen. Berikan setiap entitas nama yang stabil, namespace, dan kunci versi. Tepi relasi membawa informasi sumber, waktu penemuan, dan tingkat keyakinan (confidence). Kepemilikan harus merujuk ke entitas tim (principal) yang dapat diselesaikan, bukan teks bebas, sehingga perutean insiden dapat diotomatisasi.
2. Menetapkan kapasitas dan SLO
Asumsikan 10.000 entitas dengan masing-masing 20 relasi, sekitar 200.000 tepi, dan 5% perubahan entitas harian, yaitu sekitar 500 impor. Tulis data melalui antrean peristiwa (event queue) dan pertahankan model baca dengan indeks pemilik dan keterdekatan (adjacency). Target awal dapat berupa visibilitas impor dalam hitungan menit, P95 pencarian di bawah 300 milidetik, dan kueri dependensi tiga lompatan (three-hop) dalam satu detik; tampilan berisiko tinggi juga menampilkan usia data.
3. Merancang penyerapan data dan prioritas sumber
Deklarasi repositori memberikan maksud dan kepemilikan, sistem deployment memberikan versi dan lingkungan aktual, serta telemetri runtime menyediakan tepi panggilan terbaru. Setiap impor menyimpan sumber, versi commit, dan hasil validasi serta menggunakan kunci idempotensi. Gabungkan konflik berdasarkan kebijakan tingkat bidang: satu pengamatan runtime tidak dapat menulis ulang kepemilikan yang dideklarasikan, dan tepi runtime tidak dapat membuktikan bahwa suatu dependensi tidak ada. Masukkan konflik ke dalam antrean dan beri tahu pemilik.
4. Menentukan semantik kesegaran dan penghapusan
Simpan lastSeenAt, versi deklarasi, dan kebijakan kedaluwarsa per entitas. Tandai entitas sebagai usang setelah sumbernya berhenti memperbarui; sembunyikan atau turunkan peringkatnya dalam pencarian default sambil tetap mempertahankan riwayat untuk pemutaran ulang insiden (incident replay). Penghapusan repositori, penghentian layanan, dan lingkungan efemeral memerlukan status yang berbeda. Penghapusan langsung akan menghancurkan riwayat; tidak pernah menghapus akan mengotori pencarian. Rekonsiliator berkala akan mencoba ulang impor yang gagal dan menghapus tepi yang yatim (orphan edges).
5. Membangun jalur kueri, izin, dan keamanan
Dukung pencarian berdasarkan nama, tim, domain, lingkungan, tag, dan pemilik. Batasi kedalaman dependensi dan jumlah hasil agar penelusuran grafik tidak membebani layanan. Lampirkan cakupan organisasi ke entitas dan bidang; sensor (redact) jalur repositori sensitif, endpoint internal, dan detail penyewa pelanggan berdasarkan bidang. Lakukan audit terhadap perubahan kepemilikan dan akses yang ditolak; menyembunyikan data di browser bukanlah bentuk otorisasi.
6. Meluncurkan secara bertahap dan menyiapkan alternatif
Tahap satu mencakup layanan kritis dan pencarian pemilik dengan persyaratan sumber dan kesegaran data. Tahap dua menambahkan grafik dependensi, versi deployment, dan perutean insiden. Tahap tiga mengevaluasi tata kelola otomatis. Jika tim tidak memelihara deklarasi, mulailah dengan template repositori dan pemeriksaan CI alih-alih katalog untuk seluruh perusahaan. Panduan PM Amazon menekankan masalah pelanggan dan bukti kompetensi; adopsi harus dibuktikan dengan keberhasilan pencarian, waktu lokalisasi insiden, dan tingkat pemeliharaan metadata.
Contoh jawaban berkualitas tinggi
Saya akan memperlakukan katalog sebagai grafik entitas dengan sumber dan kesegaran data, bukan sebagai spreadsheet. Komponen, sistem, domain, API, tim, dan relasi memiliki kunci yang stabil; deklarasi repositori menentukan maksud, deployment menambahkan versi lingkungan, dan sinyal runtime menambahkan dependensi terkini. Pengumpul data berbasis peristiwa, bersifat idempoten, dan mempertahankan versi commit. Model baca menyajikan pemilik, dependensi balik, dan kueri grafik yang dibatasi. Konflik masuk ke antrean, entitas usang tetap disimpan secara historis tetapi hilang dari pencarian default, dan izin berlaku berdasarkan organisasi dan bidang. Saya akan membuktikan keberhasilan pencarian, waktu lokalisasi insiden, dan tingkat pemeliharaan pada layanan penting sebelum melakukan ekspansi.
Kesalahan umum
- Membangun CMDB manual → data cepat menjadi usang → gunakan deklarasi repositori dan pengumpulan otomatis sebagai fakta.
- Menyimpan string teks pemilik → notifikasi dan proses offboarding tidak dapat divalidasi → rujuk ke prinsipal tim yang dapat diselesaikan.
- Membiarkan sumber terbaru menimpa segalanya → derau runtime menimpa fakta tata kelola → beri peringkat pada sumber dan simpan konflik.
- Menghapus layanan yang dihentikan → pemutaran ulang insiden kehilangan informasi dependensi → gunakan status siklus hidup dan versi historis.
- Penelusuran dependensi tanpa batas → satu kueri meluas ke seluruh grafik → batasi kedalaman dan hasil serta gunakan indeks keterdekatan.
Pertanyaan lanjutan dan tanggapan
Bagaimana jika kepemilikan yang dideklarasikan berkonflik dengan data deployment?
Representasikan keduanya sebagai atribut bersumber terpisah, gabungkan berdasarkan kebijakan bidang, dan tampilkan konfliknya. Deklarasi terkontrol memiliki bidang pemilik; sistem deployment memiliki bidang lingkungan. Beri tahu kedua pihak dan selesaikan melalui commit perbaikan.
Bagaimana Anda menangani lingkungan pratinjau yang berumur pendek?
Beri entitas informasi lingkungan dan masa kedaluwarsa. Entri pratinjau menerima bobot default yang rendah dan diarsipkan secara otomatis. Jika sistem produksi bergantung pada salah satunya, tepi runtime dapat memicu peringatan, namun kepemilikan dan otorisasi penyewa tetap berlaku.
Apa yang terjadi jika katalog tidak tersedia saat terjadi insiden?
Simpan snapshot yang dapat diekspor dan cache pemilik terbaru untuk layanan kritis serta tampilkan usianya. Alat bantu insiden dapat membaca snapshot, tetapi tidak boleh menampilkan snapshot yang kedaluwarsa sebagai kebenaran langsung (live truth).
Bagaimana cara mencegah tim memperlakukan katalog sebagai gerbang persetujuan rilis?
Mulailah dengan penemuan dan respons insiden, lalu ukur waktu pencarian dan lokalisasi. Hubungkan pemeriksaan tata kelola hanya setelah metadata dan izin stabil; pemeriksaan yang gagal harus memberikan jalur perbaikan daripada memblokir setiap rilis.