Belajar Engineering Manager - Crisis & Incident Leadership

#Pendahuluan

Setelah di episode 19 kita menata compliance dan risiko, kita tiba di momen yang menguji semuanya sekaligus: krisis — production down, data bocor, insiden yang membuat pelanggan marah dan eksekutif menelepon.

Krisis adalah kaca pembesar budaya tim. Tim dengan trust tinggi justru sering tampil lebih baik saat darurat; tim yang rapohnya selalu damai tapi komunikasinya takut akan hancur tepat ketika paling dibutuhkan. Dan posisi EM dalam krisis itu spesifik: bukan orang pertama yang mengetik kubectl, bukan pula penonton — melainkan penjaga struktur: siapa memutuskan, siapa bicara ke luar, dan apa prioritasnya (pulih cepat vs akar masalah). Episode ini memberi playbook-nya.

#Peran dalam Incident Command

Prinsip utama dari dunia SRE: pemecah masalah tidak boleh sekaligus juru bicara dan pencatat. Tiga peran inti:

Perhatikan implikasinya bagi EM: jika kalian IC, kalian tidak debugging. Godaan terbesar EM teknis adalah turun tangan memperbaiki sendiri — lima menit pertama menyenangkan, sepuluh menit kemudian koordinasi runtuh karena semua orang menunggu jawaban kalian yang sedang asyik membaca log. Jika engineer terbaik kalian harus jadi IC, pastikan ada responders lain; satu orang tidak boleh memakai dua topi ini bersamaan.

Rotasi IC via on-call schedule (episode 6) menjaga skill tersebar — dan drill berkala (episode 18 tabletop) membuat struktur ini otomatis dipanggil, bukan diimprovisasi saat panik.

#Ritme Komunikasi Saat Insiden

Kebisingan informasi adalah musuh kedua setelah bugnya sendiri. Tetapkan ritme update yang dapat diprediksi:

[SEV-1] Checkout gagal global - Update #3 - 14:45 WIB
 
Status     : MITIGASI BERJALAN - traffic dialihkan ke region cadangan
Dampak     : ~35% transaksi checkout gagal sejak 14:10 WIB
Tindakan   : rollback release v2.41.0 pada 14:30; drain queue berlangsung
Langkah    : verifikasi error rate turun; root cause masih investigasi
IC         : Dewi | Comms: Andi | Next update: 15:05 WIB atau saat berubah

Aturan mainnya: interval tetap (misalnya setiap 20-30 menit untuk SEV-1) walau isinya "belum ada perkembangan" — keheningan mengisi ruang dengan spekulasi yang lebih buruk dari fakta jelek. Status hanya boleh tiga nilai (investigating/mitigated/resolved), dampak dinyatakan dalam bahasa user ("transaksi gagal"), bukan bahasa sistem ("pod crash-looping"). Untuk komunikasi eksternal/customer, comms lead bekerja dengan template yang sudah disetujui legal — dan ingat kewajiban notifikasi 3x24 jam dari UU PDP jika data pribadi terlibat (episode 19).

#Keputusan Sulit: Mitigasi Cepat vs Akar Masalah

Pertanyaan klasik tiap insiden: fix proper atau mitigate dulu? Jawaban default dunia modern: mitigasi dulu (rollback, feature flag off, failover) — waktu pemulihan adalah metrik DORA (episode 13) yang langsung terasa user. Investigasi akar masalah dilakukan setelah service stabil, dengan evidence yang diawetkan (log, snapshot, dump) oleh scribe.

Tapi ada pengecualian yang harus EM/IC waspadai: mitigasi yang menghancurkan bukti (rebuild node, wipe cache) atau menambah risiko (failover ke region yang belum pernah menerima traffic produksi). Keputusan seperti ini adalah exactly kenapa peran IC ada: ia menimbang opsi dengan konteks bisnis yang responders mungkin tidak punya. Framework singkat IC: sebutkan opsi, sebutkan risiko masing-masing, tentukan deadline keputusan ("kalau 15 menit lagi error rate tidak turun, kita failover") — keputusan berkala lebih baik daripada sempurna yang terlambat.

#Blameless Postmortem yang Menghasilkan Aksi

Insiden selesai bukan berarti belajar. Postmortem wajib untuk SEV-1/SEV-2, maksimal 3 hari kerja setelah resolusi, dengan prinsip blameless: fokus pada bagaimana sistem memungkinkan manusia melakukan kesalahan, bukan siapa yang salah.

# Postmortem: [SEV-1] Checkout gagal global - {tanggal}
 
## Ringkasan
3 kalimat: apa terjadi, dampak (durasi + volume), status sekarang.
 
## Timeline (dari catatan scribe)
14:08 deploy v2.41.0 dimulai
14:10 alert error rate checkout > 5% (dari dashboard ep. 13)
14:22 IC diangkat; channel #inc-checkout dibuka
14:30 rollback v2.41.0 -> v2.40.2 selesai
14:52 error rate normal; monitoring diperpanjang 24 jam
 
## Akar masalah (teknik 5 Whys)
Migrasi skema berjalan sebelum seed data selesai ->
migration runner tidak cek prerequisite -> checklist rilis
tidak memuat urutan migrasi -> (sistemik, bukan kesalahan individu)
 
## Apa yang berjalan baik / buruk / keberuntungan
...
 
## Action items (maksimal 5, masing-masing owner + tiket)
- [ ] Migration runner: pre-flight check (Owner: Budi, P1)
- [ ] Checklist rilis ditambah urutan migrasi (Owner: EM)
- [ ] Alert threshold checkout diturunkan ke 3% (Owner: Dewi)
 
## Lesson yang dibagikan
Ringkas 1 paragraf untuk arsip lintas tim.

Tiga penyakit postmortem yang harus kalian lawan sebagai EM. Theater: dokumen ditulis demi kelengkapan lalu action items mati di backlog — solusinya masukkan action item insiden ke keranjang prioritas RICE (episode 7) dan review progresnya di retro. Blame terselubung: "human error" sebagai akar masalah selalu analisis yang gagal — tanya lanjutan: kenapa sistem mengizinkan human error itu fatal? Postmortem of the postmortem: proses terlalu berat sehingga tim diam-diam menghindari mendeklarasikan insiden — jaga ringannya, SEV-3 boleh cukup dengan entri decision log.

Dan bagian yang sering dilupakan EM: menutup lingkaran ke atas. Setelah resolved, kirim debrief singkat ke stakeholder: apa terjadi, sudah pulih, apa yang dicegah berulang. Ini melanjutkan kontrak no surprise dari episode 11 — dan biasanya justru menaikkan reputasi tim, karena organisasi jarang melihat krisis yang ditangani se-transparan ini.

#Pemulihan Tim Pasca-Krisis

Insiden besar menguras emosi. Responder yang on-call semalaman butuh istirahat eksplisit (cuti kompensasi atau hari santai — tulis di working agreement); tim yang baru mengalami SEV-1 beruntung butuh sesi debrief emosional singkat, terpisah dari postmortem teknis. Dan hati-hati efek samping kebijakan: kalau respons kalian terhadap insiden adalah menambah approval layer, yang terjadi adalah tim belajar menyembunyikan insiden kecil — persis arah yang salah. Respons yang benar adalah memperkuat guardrail otomatis (episode 9, 18), bukan memperlambat semua orang.

#Penutup

Inti yang harus dibawa pulang:

• Struktur command: IC, comms lead, scribe, responders — EM bisa jadi IC tapi saat itu berhenti debugging.
• Ritme update tetap walau tanpa kabar; status tiga nilai; dampak dalam bahasa user; satu saluran resmi.
• Mitigasi dulu, akar masalah kemudian — dengan waspada mitigasi yang menghancurkan bukti atau menambah risiko.
• Postmortem blameless maksimal 3 hari, action items maksimal lima ber-owner, progres direview di retro.
• Pulihkan manusianya juga: istirahat eksplisit, debrief emosional, guardrail otomatis alih-alih approval layer baru.

Di episode 22 selanjutnya kita naik ke level organisasi: Managing Managers — span of control, org design dan trade-off-nya, coaching EM lain lewat skip-level, rubrik kematangan manager, dan pergeseran peran kalian dari memimpin engineer menjadi memimpin para pemimpin. Sampai jumpa!