Petunjuk dan konteks
Desain platform incident command untuk banyak tim. Platform ini harus menerima peringatan, membuat insiden, menetapkan peran respons, mengoordinasikan komunikasi internal dan eksternal, serta mempertahankan linimasa yang dapat diaudit setelah pemulihan. Jelaskan konsistensi, izin, notification storm, dan tujuan pemulihan.
Ini cocok untuk peran system design, SRE, platform, dan backend. Ini menguji bagaimana deteksi, komando, kolaborasi, dan peninjauan menjadi sistem yang dapat dipulihkan di bawah tekanan. Platform ini bukan sekadar obrolan: ini adalah control plane dengan penanggung jawab yang jelas, transisi status, bukti, dan jalur degradasi. Perjelas tingkat peringatan normal dan puncak, insiden bersamaan (konkuren), peserta, saluran, dan retensi.
Hal yang dinilai oleh pewawancara
- Memisahkan manajemen insiden dari sistem pemantauan, obrolan, dan tiket.
- Mendefinisikan status, idempotensi, source of truth, dan aturan pengeditan bersamaan.
- Memisahkan tugas incident manager, tech lead, communications lead, dan scribe.
- Menangani deduplikasi, korelasi, notification storm, dan otorisasi.
- Menyediakan degradasi, pemulihan regional, integritas audit, dan retensi.
- Memvalidasi desain dengan MTTA, MTTR, kebisingan peringatan, dan penundaan komunikasi.
Jawaban 30 detik
“Saya akan membagi platform menjadi penerimaan peringatan, orkestrasi insiden, kolaborasi real-time, notifikasi, dan penyimpanan tinjauan. Lapisan penerimaan melakukan deduplikasi berdasarkan sumber dan jendela waktu; orkestrasi memperlakukan insiden sebagai source of truth serta membuat versi status dan perubahan peran untuk audit. Incident manager memegang komando, tech lead mendiagnosis, communications lead memperbarui pemangku kepentingan, dan scribe memelihara linimasa. Peristiwa disimpan secara persisten sebelum stream yang dapat diputar ulang mendorong pembaruan. Notifikasi diprioritaskan dan dibatasi kecepatannya. Selama kegagalan regional, control plane minimum dan fallback manual tetap tersedia; pemulihan menghasilkan tinjauan dari linimasa.”
Solusi langkah demi langkah
Langkah 1: Tentukan batasan dan tujuan
Sinyal dapat berasal dari metrik, log, synthetic check, eskalasi dukungan, atau manusia. Platform mengatur sinyal menjadi insiden dan alur kerja respons; platform ini tidak menggantikan komputasi pemantauan, penyimpanan obrolan, atau deployment. Tetapkan tujuan untuk latensi pembuatan insiden, pengiriman notifikasi kritis, daya tahan linimasa, waktu pemulihan regional, dan retensi audit.
Pisahkan beban normal dari pemadaman besar: puluhan ribu peringatan per menit, ratusan insiden bersamaan, ratusan peserta per insiden, dan pengiriman SMS, email, push notification, serta webhook secara simultan. Lonjakan memerlukan backpressure dan prioritas sehingga notifikasi bernilai rendah tidak dapat memblokir tindakan komando.
Langkah 2: Serap, deduplikasi, dan korelasikan peringatan
Pertahankan sumber, versi aturan, stempel waktu, sidik jari (fingerprint), dan payload mentah untuk setiap sinyal. Percobaan ulang klien dan replay jaringan memerlukan kunci idempotensi; batasan unik atau lease mencegah duplikasi insiden untuk satu sidik jari. Jendela deduplikasi tidak boleh menyembunyikan pemadaman baru selamanya, jadi konfigurasikan berdasarkan layanan, lingkungan, dan waktu.
Korelasi dapat dimulai dengan topologi layanan, versi deployment, wilayah, dan label bersama, kemudian memungkinkan incident manager untuk membagi atau menggabungkan. Korelasi otomatis harus mencatat aturan dan buktinya; korelasi tidak boleh mengubah cakupan insiden secara diam-diam. Peringatan mentah bersifat immutable, sedangkan agregasi adalah status turunan.
Langkah 3: Modelkan status dan peran
Sebuah insiden dapat menggunakan status seperti detected, triaged, mitigating, monitoring, resolved, dan closed. Tentukan transisi yang sah, pelaku (aktor), dan bukti yang diperlukan. Status bukan sekadar Boolean; catat dampak, hipotesis saat ini, tindakan berikutnya, dan waktu pembaruan secara bersamaan.
Pisahkan peran respons dari identitas. Incident manager memegang prioritas dan keputusan, tech lead memegang investigasi, communications lead memegang pembaruan internal dan eksternal, dan scribe memelihara linimasa. Perubahan peran menambahkan peristiwa audit. Lease dan versi mencegah dua responder menimpa komando secara diam-diam.
Langkah 4: Bangun kolaborasi di sekitar satu source of truth
Simpan status, peran, action item, dan ringkasan komunikasi ke log peristiwa atau penyimpanan transaksional sebelum memublikasikannya melalui bus ke saluran WebSocket, SSE, email, dan seluler. Klien dapat merender secara optimis, tetapi konflik versi memerlukan pembacaan ulang server yang baru. Memori browser tidak pernah menjadi kebenaran akhir.
Simpan pelaku, waktu server, versi insiden, jenis tindakan, ringkasan, dan peringatan terkait di linimasa. Obrolan panjang dapat ditempatkan di tempat lain, tetapi keputusan dan bukti pemulihan termasuk dalam linimasa terstruktur. Read model dapat merender insiden saat ini, sementara replay tetap dapat merekonstruksinya.
Langkah 5: Kendalikan notification storm dan akses
Batasi kecepatan berdasarkan prioritas insiden, jadwal on-call, keandalan saluran, dan konfirmasi (acknowledgement). Ringkas peringatan berprioritas rendah; gunakan backoff, eskalasi, dan batas waktu konfirmasi untuk notifikasi berprioritas tinggi. Satu insiden tidak boleh mengirimkan ratusan pesan duplikat ke satu responder. Isolasi antrean notifikasi dari control plane sehingga pemadaman penyedia tidak dapat memblokir perubahan status.
Otorisasi pengamat, responder, incident manager, communications lead, dan administrator berdasarkan tenant, layanan, dan lingkungan. Halaman status eksternal adalah proyeksi baca teredaksi dari dampak dan kemajuan; halaman ini tidak boleh mengekspos hipotesis, data pelanggan, atau kredensial. Catat pembacaan dan ekspor, serta wajibkan alasan ditambah peninjauan kemudian untuk akses darurat (break-glass).
Langkah 6: Degradasi, pulihkan, dan tinjau
Jika platform gagal, pertahankan phone bridge, runbook statis, atau log insiden cadangan. Pertahankan pembuatan insiden, klaim peran, dan penulisan linimasa terlebih dahulu; analitik, pencarian, dan laporan historis dapat dibuat tidak tersedia. Deployment regional dapat menggunakan primary writer dengan replikasi asinkron atau penulisan ter-shard, tetapi dokumentasikan penanganan konflik dan akuisisi ulang lease selama failover.
Setelah pemulihan, buat draf tinjauan dari stempel waktu deteksi, konfirmasi, mitigasi, pemulihan, dan penutupan, keputusan, kualitas peringatan, komunikasi, dan pekerjaan tindak lanjut. Jangan menimpa linimasa asli; revisi dilakukan dengan menambahkan versi baru. Lacak MTTA, MTTM, MTTR, rasio peringatan duplikat, latensi klaim peran, pengiriman notifikasi, dan penyelesaian action item.
Perolehan informasi dan batasan
Nilai dari platform incident command berasal dari penataan kepemilikan, status, dan bukti, bukan dari memindahkan setiap percakapan ke dalam satu halaman. Platform ini tidak dapat menjamin akar masalah yang benar atau menggantikan kualitas pemantauan dan pelatihan responder. Notifikasi, identitas, jaringan regional, dan platform itu sendiri dapat gagal bersamaan, sehingga desain membutuhkan control plane minimum dan fallback manual.
Contoh jawaban
“Pertama-tama saya akan menentukan batasannya: platform mengatur peringatan dan respons, sementara pemantauan, deployment, dan obrolan biasa tetap terpisah. Tujuannya adalah latensi pembuatan, pengiriman notifikasi kritis, daya tahan linimasa, pemulihan regional, dan retensi audit. Penerimaan mempertahankan peringatan mentah dan menggunakan sidik jari sumber ditambah kunci idempotensi untuk deduplikasi. Korelasi berdasarkan layanan, wilayah, versi, dan topologi dapat dijelaskan dan dibalikkan.
Lapisan orkestrasi adalah state machine berversi yang perubahan status dan perannya ditambahkan ke log yang tahan lama. Incident manager memegang keputusan, tech lead menginvestigasi, communications lead memperbarui pemangku kepentingan, dan scribe memelihara bukti. Klien menerima pembaruan yang dapat diputar ulang dan membaca ulang saat terjadi konflik versi; cache browser tidak bersifat otoritatif. Tindakan kontrol dan notifikasi menggunakan antrean terpisah, dengan batas prioritas, on-call, dan konfirmasi.
Akses diisolasi berdasarkan tenant, layanan, dan lingkungan, serta proyeksi eksternal diredaksi. Selama kegagalan regional, pembuatan, klaim peran, dan penulisan linimasa tetap tersedia sementara pencarian dan laporan didegradasi menjadi read-only atau offline. Pemulihan menghasilkan tinjauan dari linimasa yang immutable dan menghitung MTTA, MTTR, kebisingan peringatan, dan penyelesaian tindakan. Jika platform tidak tersedia, phone bridge dan runbook statis menjaga agar komando tetap memungkinkan.”
Kesalahan umum
- Memperlakukan platform sebagai obrolan → status utama menjadi tidak dapat diaudit → gunakan state machine terstruktur dan linimasa.
- Menyiarkan setiap peringatan → notification storm memblokir komando → deduplikasi, prioritaskan, konfirmasi, dan batasi kecepatan.
- Menyimpan peran hanya di UI → responder yang bersamaan saling menimpa satu sama lain → gunakan lease server, versi, dan peristiwa audit.
- Menyembunyikan korelasi otomatis → cakupan yang buruk tidak dapat dijelaskan → pertahankan peringatan mentah dan bukti korelasi.
- Hanya mendesain wilayah yang sehat → pemadaman platform menghilangkan komando → sediakan control plane minimum dan fallback manual.
- Menimpa bukti tinjauan → keputusan dan stempel waktu tidak dapat diverifikasi → jaga log mentah tetap immutable dan tambahkan revisi.
Pertanyaan lanjutan
Bagaimana jika dua incident manager mengklaim kendali sekaligus?
Gunakan takeover lease yang kedaluwarsa dan versi monotonik. Server hanya menerima penulisan kontrol dari pemegang lease saat ini. Responder yang kalah membaca ulang dan menampilkan pemiliknya; akses darurat (break-glass) memerlukan otorisasi, alasan, dan audit.
Bisakah pemadaman penyedia notifikasi memengaruhi status insiden?
Hal itu tidak boleh membuat pengiriman notifikasi menjadi prasyarat untuk penulisan status. Simpan insiden dan notifikasi yang tertunda secara persisten terlebih dahulu, lalu biarkan worker yang terisolasi mencoba lagi, beralih saluran, atau memicu proses telepon sementara control plane tetap dapat digunakan.
Bagaimana cara mencegah korelasi menyembunyikan insiden baru?
Korelasi membuat hubungan kandidat dan mempertahankan sinyal mentah. Gunakan beberapa dimensi bukti seperti waktu, layanan, wilayah, dan topologi. Sinyal berdampak tinggi atau berkeyakinan rendah memerlukan konfirmasi manusia, serta versi aturan dan pemisahan dimasukkan ke dalam linimasa.
Apa saja yang termasuk dalam halaman status eksternal?
Hanya proyeksi yang difilter privasinya mengenai dampak, fase saat ini, waktu pembaruan berikutnya, dan kemajuan pemulihan. Simpan hipotesis internal, pengidentifikasi pelanggan, kredensial, akar masalah yang belum dikonfirmasi, dan log terperinci dalam tampilan internal yang terkontrol.