Pertanyaan dan konteks
Pertanyaan ini menguji penilaian, kemampuan menulis, dan koordinasi selama insiden berlangsung, bukan saat retrospeksi. Asumsikan bahwa dampaknya mungkin masih meluas, incident manager, technical lead, dan penanggung jawab komunikasi (communications owner) sudah ada, dan akar penyebabnya belum diketahui. Anda memerlukan pemberitahuan awal, frekuensi pembaruan berkala, pesan mitigasi dan pemulihan, serta jalur koreksi.
Pertanyaan ini cocok untuk technical lead, SRE, platform engineer, customer engineer, dan peran umum yang mengoordinasikan berbagai tim. Pisahkan alur kerja internal dari halaman status publik. Jangan mengubah hipotesis yang belum diverifikasi menjadi sebuah kesimpulan atau membiarkan pihak terdampak tanpa informasi saat menunggu akar penyebab ditemukan.
Apa yang dievaluasi oleh pewawancara
Jawaban yang kuat pertama-tama menetapkan tingkat keparahan (severity) dan audiens berdasarkan dampak bisnis, kemudian menentukan satu sumber kebenaran (single source of truth), seorang penanggung jawab komunikasi, dan frekuensi pembaruan. Jawaban tersebut menyatakan apa yang diketahui, tidak diketahui, sedang berlangsung, dan kapan pembaruan berikutnya akan diberikan. Jawaban juga mencakup eskalasi keamanan, kehilangan data, dan kepatuhan, serta konsistensi saluran, pesan yang sudah usang, pemulihan, dan tinjauan pascainsiden (post-incident review).
Pertanyaan klarifikasi yang perlu diajukan
- Pengguna, wilayah, fungsi, dan data mana yang terpengaruh? Apakah cakupannya menyeluruh, sebagian, atau belum diketahui?
- Mungkinkah ini melibatkan keamanan, privasi, kehilangan data, atau kewajiban regulasi? Hal tersebut mengubah jalur persetujuan dan pemberitahuan.
- Siapa incident manager, technical lead, dan penanggung jawab komunikasinya? Siapa yang berwenang menyetujui redaksi pesan eksternal?
- Saluran internal dan eksternal apa saja yang tersedia, dan apakah pelanggan dapat mengakses halaman status atau pemberitahuan yang ditargetkan?
- Berapa frekuensi pembaruan yang diharapkan? Apakah Anda tetap harus mengirimkan pembaruan "masih dalam penyelidikan" jika belum ada bukti baru?
Kerangka jawaban 30 detik
"Pertama-tama, saya menetapkan dampak, tingkat keparahan, serta risiko keamanan atau data, lalu menunjuk incident manager, technical lead, dan penanggung jawab komunikasi yang berpusat pada satu sumber kebenaran. Saya segera mengakui adanya masalah dengan menyertakan dampak yang diketahui, investigasi atau mitigasi saat ini, dan waktu pembaruan berikutnya. Pesan internal mencakup peran, saluran kerja, dan jalur eskalasi; pesan eksternal hanya berisi fakta dan tindakan yang relevan bagi pelanggan. Saya menjaga frekuensi pembaruan tetap berjalan meski belum ada kesimpulan baru. Setiap saluran menggunakan status dan ID insiden yang sama, dan pesan pemulihan mencakup konfirmasi, ringkasan dampak, serta rencana tinjauan pascainsiden."
Jawaban langkah demi langkah
Langkah 1: Menilai dampak dan batasan komunikasi
Tentukan siapa yang terpengaruh, apa yang mereka lihat, kapan masalah dimulai, apakah masalah meluas, dan apakah ada risiko keamanan atau data. Tingkat keparahan menentukan respons 24/7, eskalasi ke eksekutif, tinjauan hukum, atau keterlibatan tim privasi. Beri label hal yang belum diketahui sebagai 'belum diketahui'; jangan mengganti bukti dengan asumsi yang terlalu optimis atau terlalu mengkhawatirkan.
Langkah 2: Menetapkan peran dan satu sumber kebenaran
Incident manager bertanggung jawab atas prioritas dan keputusan, technical lead bertanggung jawab atas hipotesis, mitigasi, dan bukti, serta penanggung jawab komunikasi mengelola pesan internal dan eksternal. Semua orang berbagi ID insiden, dokumen status, dan linimasa yang sama; obrolan, halaman status, email, dan tiket hanyalah saluran distribusi. Tim komunikasi tidak boleh mengubah fakta teknis, dan para insinyur tidak boleh memublikasikan dugaan di luar jalur persetujuan.
Langkah 3: Mengirim pemberitahuan awal
Setelah insiden terkonfirmasi secara wajar, publikasikan pesan singkat yang memuat produk yang terpengaruh, gejala saat ini, status investigasi, tindakan sementara bagi pengguna, dan jadwal pembaruan berikutnya. Pesan internal dapat mencakup tingkat keparahan, saluran on-call, penanggung jawab, dan jalur eskalasi; redaksi eksternal harus menghindari jargon internal dan penyebab yang belum diverifikasi. Jika dampak keamanan atau data belum diketahui, sampaikan bahwa hal itu sedang dinilai dan gunakan proses pemberitahuan keamanan terpisah jika diperlukan.
Langkah 4: Menetapkan frekuensi dan templat pembaruan
Pilih frekuensi yang sesuai dengan tingkat keparahan, misalnya setiap 30 menit; perbarui lebih cepat jika ada bukti baru yang ditemukan. Batasi setiap pesan pada status saat ini, dampak pengguna, tindakan yang sedang berjalan, dan waktu pembaruan berikutnya. Meskipun tidak ada bukti baru, sampaikan bahwa dampaknya masih dalam investigasi atau mitigasi. Detail internal dan eksternal boleh berbeda, tetapi status, waktu, dan dampak harus selaras.
Langkah 5: Menyelesaikan konflik antarsaluran dan melakukan koreksi
Jika terjadi pertentangan pesan antarsaluran, hentikan penyalinan teks lama dan kembalilah ke sumber kebenaran untuk memastikan waktu, dampak, dan status. Penanggung jawab komunikasi memublikasikan koreksi yang menyebutkan apa saja yang diubah, alih-alih menimpa riwayat secara diam-diam. Gunakan ID insiden dan transisi status yang sama di semua tempat; tandai halaman yang sudah usang sebagai 'selesai' atau tautkan ke ringkasan akhir.
Langkah 6: Mengomunikasikan mitigasi, pemulihan, dan risiko residual
Mitigasi bukanlah pemulihan penuh. Bedakan antara tindakan mitigasi, pengguna yang mungkin masih terdampak, pemeriksaan konsistensi data, dan validasi berikutnya. Setelah pemulihan, nyatakan waktu konfirmasi, rentang waktu terjadinya dampak, apakah pengguna perlu mencoba kembali atau masuk kembali, dan apakah akan ada tinjauan pascainsiden. Jika cakupan baru diketahui belakangan, kirimkan pemberitahuan yang ditargetkan alih-alih menyajikan perkiraan awal sebagai hasil akhir.
Langkah 7: Mengubah komunikasi menjadi siklus perbaikan
Tinjau waktu hingga pemberitahuan pertama (time to first notice), kepatuhan terhadap frekuensi pembaruan, konsistensi saluran, volume tiket bantuan, dan informasi mana yang menimbulkan kebingungan. Buat tindakan yang jelas penanggung jawabnya dan dapat diuji untuk templat, akses halaman status, peran on-call, dan jalur eskalasi. Tingkatkan proses komunikasi bersamaan dengan tinjauan teknis, tetapi jangan menulis pembaruan publik yang sedang berlangsung sebagai kesimpulan akar penyebab pascainsiden.
Contoh jawaban yang kuat
"Saya pertama-tama akan menetapkan pengguna, wilayah, fungsi yang terpengaruh, waktu mulai, dan risiko data, kemudian menetapkan tingkat keparahan berdasarkan dampak bisnis. Incident manager memegang prioritas, technical lead mengelola hipotesis dan bukti, dan penanggung jawab komunikasi mengelola pesan; ketiganya berbagi satu ID insiden, dokumen status, dan linimasa yang sama.
Setelah mengonfirmasi masalah tersebut, saya akan segera mengirimkan pemberitahuan awal: apa yang terpengaruh, apakah kami sedang menyelidiki atau memitigasi, apa yang dapat dilakukan pengguna, dan kapan pembaruan berikutnya akan diberikan. Redaksi internal menambahkan tingkat keparahan, saluran kerja, dan kontak eskalasi; redaksi eksternal memuat fakta yang relevan bagi pelanggan dan tidak berspekulasi mengenai akar masalah. Saya akan mempertahankan frekuensi yang dijanjikan meskipun belum ada kesimpulan baru.
Jika halaman status, email, dan respons tim bantuan berbeda, saya akan merujuk ke sumber kebenaran dan meminta penanggung jawab komunikasi memublikasikan koreksi yang disertai ID insiden. Saya akan membedakan mitigasi, pemulihan, dan risiko residual, lalu memublikasikan rentang waktu dampak, panduan mencoba kembali, dan alur tinjauan pascainsiden. Terakhir, saya akan meninjau frekuensi, jangkauan, konsistensi, dan beban bantuan, lalu menetapkan langkah-langkah perbaikan dengan penanggung jawab yang jelas."
Kesalahan umum
- Menunggu akar penyebab sebelum memberi tahu → pengguna tidak dapat menilai risiko → sampaikan dampak yang diketahui, tindakan yang diambil, dan pembaruan berikutnya terlebih dahulu.
- Menulis secara terpisah untuk setiap saluran → terjadi konflik status dan waktu → pertahankan satu sumber kebenaran dan satu ID insiden.
- Menyalin jargon internal ke publik → pelanggan tidak tahu apa yang harus dilakukan → sesuaikan bahasa berdasarkan audiens dengan tetap menjaga keakuratan fakta.
- Hanya menyatakan “termitigasi” → pengguna mengira sistem sudah pulih total → pisahkan antara mitigasi, pemulihan, validasi, dan risiko residual.
- Tidak memberikan jadwal frekuensi pembaruan → keheningan tampak seperti kehilangan kendali → berkomitmenlah pada suatu frekuensi dan perbarui status meski tanpa kesimpulan baru.
- Mengedit pesan yang salah secara diam-diam → kepercayaan dan kemampuan audit menurun → publikasikan koreksi berstempel waktu dan pertahankan riwayat.
Pertanyaan lanjutan dan jawabannya
Pertanyaan lanjutan 1: Penyebabnya belum diketahui dan pelanggan bertanya apakah data mereka aman. Apa yang Anda katakan?
Nyatakan pemeriksaan yang telah selesai dan penilaian yang sedang berlangsung, misalnya: "Sejauh ini kami tidak menemukan bukti adanya paparan data, dan tim keamanan masih terus menyelidiki." Jangan mengubah "belum ditemukan" menjadi "pasti tidak ada". Gunakan jalur pemberitahuan keamanan dan privasi jika ambang batasnya terpenuhi.
Pertanyaan lanjutan 2: Haruskah Anda tetap memperbarui status ketika tidak ada progres?
Ya. Penuhi komitmen tersebut dan sampaikan apakah dampaknya berubah, hipotesis mana yang sedang diuji, validasi apa yang sedang berjalan, dan kapan pembaruan berikutnya akan tiba. Jika frekuensi berubah, jelaskan frekuensi yang baru beserta alasannya.
Pertanyaan lanjutan 3: Sebagian kecil pelanggan terdampak. Apakah halaman status publik akan menimbulkan kepanikan?
Tentukan pilihan berdasarkan cakupan dan apakah saluran yang ditargetkan dapat menjangkau semua pihak dengan cepat. Jika kelompok yang terdampak belum diketahui pasti atau saluran normal tidak tersedia, halaman publik dapat melengkapi pemberitahuan yang ditargetkan. Jelaskan fungsi yang terpengaruh dan gejala yang terlihat oleh pengguna tanpa menyertakan detail internal yang tidak perlu.
Pertanyaan lanjutan 4: Kapan tinjauan pascainsiden harus dipublikasikan?
Publikasikan konfirmasi pemulihan dan rentang waktu dampak yang diketahui terlebih dahulu. Publikasikan tinjauan setelah bukti dan analisis dampak sudah memadai. Jika pelanggan membutuhkan konteks lebih awal, berikan ringkasan awal yang diberi label ketidakpastian dan tambahkan linimasa serta tindakan yang telah divalidasi kemudian.