# Item Tindakan Pasca Insiden yang Tidak Pernah Selesai URL: https://upstreamapi.com/id/journal/item-tindakan-pasca-insiden-yang-benar-benar-selesai Type: blog Locale: id Published: 2026-09-05 Updated: 2026-09-06 --- > Item tindakan pasca insiden gagal bukan karena tim melewatkan review. Gagal karena item tanpa pemilik bernama, hidup di dokumen yang tak dibaca, dan tidak pernah masuk ke sprint kerja nyata. ## Item Tindakan Pasca Insiden yang Tidak Pernah Selesai Item tindakan pasca insiden menentukan apakah post-mortem tim Anda benar-benar menghasilkan perubahan. Lebih dari 50% item tindakan tidak pernah diselesaikan di tim SRE pada umumnya. Masalahnya bukan pada kualitas dokumen -- melainkan pada struktur: deskripsi yang kabur, pemilik yang tidak bernama, dan item yang tidak pernah masuk ke sistem kerja sprint nyata. Tim Anda baru saja menjalankan post-mortem pekan lalu. Enam item tindakan berhasil ditulis. Sekarang, mungkin dua sudah memiliki tiket Jira. Satu memiliki pemilik yang sedang menangani insiden lain. Tiga masih ada di Google Doc, di bawah heading "Tindak Lanjut", tidak tersentuh. Solusinya bukan template yang lebih baik. Ini tentang pemahaman yang berbeda tentang apa yang membuat item tindakan menjadi nyata. ## Mengapa Sebagian Besar Item Tindakan Cacat Secara Struktural Menulis "tingkatkan monitoring" dalam post-mortem terasa produktif. Tapi itu bukan item tindakan -- itu adalah kategori pekerjaan tanpa pemilik, tanpa tenggat, dan tanpa definisi selesai. Item tindakan yang efektif memiliki tiga bagian yang tidak bisa dihilangkan: apa yang perlu dilakukan (spesifik dan terukur), siapa yang memilikinya (seorang engineer bernama, bukan sebuah tim), dan kapan harus selesai (tanggal spesifik, bukan "Q3"). Kehilangan salah satu bagian berarti item kemungkinan tidak akan selesai, karena item fiktif tidak diprioritaskan ulang -- mereka menghilang. Tidak ada yang secara aktif memutuskan untuk tidak melakukannya. Item tersebut hanya tidak pernah muncul di tempat kerja sebenarnya dijadwalkan. Perbedaannya lebih tajam dari yang terdengar. "Perbaiki rate limiting" adalah fiksi. "Tambah circuit breaker pada panggilan API upstream search di checkout path -- pemilik @anya, target: di-merge sebelum 2026-09-19" adalah item tindakan. Satu akan muncul dalam standup. Yang lain tidak. Kegagalan struktural terjadi pada saat penulisan, ketika para engineer kelelahan, meeting sudah terlalu lama, dan tekanan untuk segera selesai lebih tinggi dari tekanan untuk presisi. Itulah momen ketika presisi paling penting -- karena konteks cepat terdegradasi, dan detail yang Anda lewati malam ini adalah detail yang @anya harus tanyakan tiga minggu kemudian. ## Angka yang Seharusnya Mengganggu Setiap Team Lead Lebih dari 50% item tindakan pasca insiden tidak pernah selesai di tim SRE pada umumnya. Di organisasi dengan budaya insiden yang lemah, angka itu melampaui 70%. Bayangkan apa artinya bagi reliabilitas di skala besar. Jika post-mortem Anda rata-rata menghasilkan empat item tindakan per insiden dan Anda menangani sepuluh insiden per kuartal, Anda menghasilkan 40 item, menyelesaikan kurang dari 20, dan membawa backlog yang terus bertumbuh dari mode kegagalan yang belum diperbaiki. Insiden berikutnya secara statistik kemungkinan merupakan varian dari sesuatu yang sudah Anda diagnosis. [Riset tentang postmortem culture dari Google SRE](https://sre.google/sre-book/postmortem-culture/) secara konsisten menemukan bahwa organisasi engineering berkinerja tinggi memiliki change failure rate yang lebih rendah bukan karena mereka menulis post-mortem yang lebih baik, tetapi karena mereka menutup item tindakan mereka. Dokumen bukan pekerjaan. Tiket adalah pekerjaan. Ketika tingkat penyelesaian turun di bawah 50%, post-mortem menjadi pertunjukan -- ditulis untuk memuaskan proses, bukan untuk mengubah sesuatu. Tim tahu ini. Para engineer yang menulis item dengan teliti menyaksikan item tersebut membusuk. Akhirnya, kualitas item yang ditulis terdegradasi sesuai dengan tingkat penyelesaiannya. Mengapa menulis item yang presisi dan dapat dimiliki jika tidak ada yang menutup item yang sudah ada? ## Item Mitigatif dan Preventif Bukan Antrean yang Sama Item tindakan pasca insiden terbagi dalam dua kategori, dan memperlakukan keduanya secara identis adalah kesalahan perencanaan yang berlipat ganda seiring waktu. Item mitigatif mengurangi blast radius dari kejadian berikutnya sebelum Anda menghilangkan akar penyebabnya. Tambah fallback. Set timeout. Pasang circuit breaker. Item ini hampir selalu mendesak dan harus dikirim dalam satu sprint -- idealnya sebelum meeting post-mortem ditutup jika cukup kecil. Item preventif menghilangkan mode kegagalan sepenuhnya: refactor queue consumer, desain ulang retry logic, instrumen celah SLO yang membuat insiden ini lolos dari burn rate alert Anda. Ini membutuhkan waktu lebih lama, memerlukan design review, dan bersaing langsung dengan feature work. Mencampur keduanya dalam satu label "aksi post-mortem" berarti item preventif yang panjang menghalangi daftar sampai tim lupa mengapa item itu ditulis, sementara item mitigatif menunggu dalam antrean yang sama di belakang mereka. Pisahkan secara eksplisit. Item mitigatif masuk ke sprint saat ini sebelum planning ditutup. Item preventif diukur dan diprioritaskan terhadap roadmap Anda sesuai jadwal tersendiri -- diperlakukan seperti investasi reliabilitas lainnya, bukan seperti catatan tempel yang dilampirkan pada insiden yang sudah ditutup. ![Papan tugas kanban di monitor menampilkan kartu proyek dengan status terlambat yang disorot, engineer menunjuk item untuk direview](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/07c92a-inline1.webp) ## Di Mana Item Tindakan Pergi untuk Mati Google Doc adalah tempat pemakaman yang paling umum. Tim menyusun post-mortem dalam dokumen bersama karena dokumen memiliki hambatan masuk yang rendah saat insiden terjadi. Masalahnya adalah dokumen bukan tempat di mana pekerjaan engineering berlangsung. Jira-lah tempatnya. Linear-lah tempatnya. GitHub Issues-lah tempatnya. Di mana pun sprint planning Anda berlangsung -- di sanalah item tindakan harus mendarat sebelum meeting post-mortem berakhir. Celah integrasi adalah titik kegagalan yang paling dapat diprediksi dalam seluruh alur kerja. Insiden terjadi. Post-mortem berjalan. Item tindakan yang baik ditulis. Lalu seseorang harus menyalinnya secara manual ke sistem tiket. Langkah penyalinan itu memiliki tingkat penyelesaian sekitar 40% di tim yang tidak mengotomatiskannya atau memberlakukannya. Perbaikannya bukan alat baru -- ini adalah menghilangkan celah antara dokumen post-mortem dan sistem sprint. Beberapa platform manajemen insiden sekarang menulis tiket Jira atau Linear langsung dari template post-mortem. Alat pencatatan yang menghasilkan item terstruktur dengan pemilik dan terintegrasi dengan tracker Anda menjalankan fungsi yang sama. Prinsip utamanya adalah tidak ada engineer yang harus menyalin-tempel dari dokumen ke tiket setelah meeting review 90 menit di akhir shift on-call. ## Meeting yang Menangkap Item Tindakan Sebelum Menguap Satu masalah yang sering diabaikan: item tindakan yang ditulis dalam meeting post-mortem tidak selalu sama dengan yang akhirnya masuk ke dokumen. Dalam ruangan dengan empat engineer yang sedang memulihkan diri dari insiden yang berat, item terpenting sering muncul secara percakapan sebelum seseorang membuka laptop. "Kita seharusnya menangkap ini di canary" -- apakah itu item tindakan? Tergantung siapa yang mendengarnya, apakah mereka menulisnya, dan apakah fasilitator meeting ingat untuk menanyakan di akhir. Peran fasilitator dalam post-mortem lebih sulit dari yang terlihat. Anda mengelola dinamika grup, menjaga timeline tetap jujur, mengamati ruangan untuk attribution drift, dan secara bersamaan seharusnya menangkap setiap tindak lanjut yang muncul. Sesuatu pasti terlewat. Ini bukan kelalaian; ini adalah beban kognitif. Alat pencatat AI yang berjalan di latar belakang dan menampilkan item terstruktur dari transkrip meeting telah menjadi solusi praktis untuk masalah ini. Bukan karena mereka lebih cerdas dari engineer, tetapi karena mereka tidak kelelahan, tidak mengelola ruangan, dan tidak berpindah konteks antara memfasilitasi dan mendokumentasikan. Output-nya tetap memerlukan tinjauan manusia. Tapi memiliki draft pertama item dari seluruh percakapan -- termasuk komentar tidak terduga di menit ke-45 -- mengubah apa yang bertahan dari meeting. ## Masalah Ownership: Tim Tidak Menyelesaikan Tugas Menetapkan item tindakan ke sebuah tim adalah padanan organisasional dari menetapkannya ke siapa pun juga. Tim tidak memiliki pengingat kalender. Mereka tidak diberi tanda di Jira. Mereka tidak muncul dalam standup ketika item terlambat. "Tim platform" tidak memiliki kotak masuk notifikasi. @carlos punya. Pemilik bernama penting, tetapi pemilik bernama dengan konteks lebih penting. "@carlos: tambah exponential backoff ke SQS consumer di payments-worker -- lihat timeline insiden untuk pola burst yang terjadi pukul 14:23 UTC. Target: di-merge sebelum penutupan sprint 2026-09-26, Jira: PAY-2891" adalah sesuatu yang dapat @carlos eksekusi tanpa percakapan lanjutan. Post-mortem adalah momen ketika konteks paling tinggi. Di situlah Anda menulis item. Detail terdegradasi cepat -- dalam 48 jam, separuh ruangan sudah melupakan pola burst spesifik yang memicu kegagalan. Dalam dua minggu, insiden menjadi kebisingan latar. Item yang ditulis dengan konteks penuh di akhir meeting post-mortem adalah item yang selesai. Item yang mendapat "kita tulis dengan benar nanti" menjadi yatim piatu. ![Tim engineering dalam diskusi post-mortem di depan whiteboard dengan diagram timeline insiden](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/b55433-inline2.webp) ## Celah Observabilitas Adalah Kasus Khusus Sebagian besar item tindakan pasca insiden melibatkan celah observabilitas: metrik yang tidak diinstrumentasi, ambang alert yang terlalu longgar, dashboard yang ada tetapi tidak tertaut dari runbook, jendela SLO yang terlalu lebar untuk menangkap degradasi sebelum pengguna menyadarinya. Item-item ini memiliki pola kegagalan yang dapat diprediksi. Mereka memerlukan akses ke monitoring stack Anda. Mereka tidak mendesak begitu insiden ditutup dan kebakaran langsung sudah padam. Dan mereka cenderung memerlukan koordinasi antara tim produk yang mengalami insiden dan tim platform yang memiliki alat observabilitas -- titik handoff yang sering berarti tidak ada yang secara formal memiliki penutupan. Perbaikannya adalah memperlakukan item tindakan observabilitas sebagai kategori kelas satu dengan pemilik langsung di tim platform, bukan tim produk yang mengalami insiden. "Tambahkan p99 latency alert pada search-service checkout path" harus memiliki pemilik di platform observabilitas Anda -- seseorang yang benar-benar memiliki akses dan konteks untuk menulis aturan alert -- bukan product engineer yang harus mengajukan tiga pertanyaan sebelum bisa memulai. ## Menutup Feedback Loop yang Tidak Pernah Ditutup Siapa Pun Ada satu langkah setelah penyelesaian yang sebagian besar tim lewatkan sepenuhnya: mengakuinya. Ketika item tindakan dari post-mortem #47 mencegah rekurensi yang seharusnya menjadi insiden #58, koneksi itu harus dibuat terlihat. Tulis di channel insiden Anda. Masukkan dalam update engineering all-hands berikutnya. Beri tahu on-call engineer yang memiliki PAY-2891 bahwa circuit breaker mereka menyerap burst Kamis lalu dan tidak ada yang dipaged. Tim engineering menyelesaikan lebih banyak item tindakan ketika mereka melihat pekerjaan mereka membuahkan hasil. Tim yang menulis item ke dalam dokumen yang tidak pernah ditinjau kembali akhirnya berhenti menulisnya dengan serius -- formatnya tetap ada, tetapi kualitasnya turun sesuai dengan dampak yang dirasakan. Itulah bagaimana budaya post-mortem blameless masih bisa menghasilkan budaya reliabilitas tanpa memori. Feedback loop inilah yang membedakan budaya post-mortem yang meningkat dengan yang hanya berperforma. Pukul 3 pagi, on-call engineer yang memperbaiki timeout kuartal lalu karena item yang mereka miliki -- engineer itu tahu persis untuk apa pekerjaan itu. Buat koneksi itu eksplisit untuk seluruh tim, bukan hanya orang yang kebetulan on-call ketika perbaikan membuktikan nilainya. ## Seperti Apa Item Tindakan yang Benar-Benar Selesai Ini adalah format yang secara konsisten menghasilkan penutupan: Tujuh field. Field "Konteks" tidak opsional. Itulah yang bertahan dalam jeda tiga minggu antara post-mortem dan sprint di mana @danielle akhirnya memiliki bandwidth. Tanpanya, item adalah tugas tanpa cerita. Dengannya, @danielle dapat membuka PAY-2891 dingin dan tahu persis apa yang sedang dibangun dan mengapa itu penting. ![Developer di laptop dengan indikator konfirmasi merge hijau terlihat di layar, item tindakan post-mortem ditutup](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/899b10-inline3.webp) ## Yang Dibutuhkan dari Engineering Lead Penyelesaian item tindakan adalah metrik team lead, bukan metrik engineer. Para engineer menulis item. Lead bertanggung jawab atas sistem yang memastikannya selesai. Secara konkret, ini berarti empat hal: Pertama, kapasitas sprint dialokasikan untuk item mitigatif sebelum planning dimulai -- bukan setelah tim sudah berkomitmen pada feature work. Jika item mitigatif harus bersaing untuk mendapat sisa, mereka kalah. Kedua, review lima menit yang ditetapkan atas item post-mortem terbuka di weekly team sync. Bukan seremonial. Hanya pemindaian: ada yang lebih dari 14 hari yang belum ada tiketnya, ada yang terlambat yang memerlukan keputusan. Ketiga, deprioritisasi eksplisit ketika sesuatu memang tidak bisa dilakukan. "Kita tidak melakukan PAY-2891 kuartal ini karena refactor pembayaran dikirim di Q4 dan ini menjadi redundan" adalah keputusan. "PAY-2891 sudah dalam backlog selama tiga bulan" adalah kegagalan proses. Keempat, melacak tingkat penyelesaian item tindakan sebagai metrik kesehatan tim bersama deployment frequency dan MTTR. Tim yang mengukurnya menemukan rata-rata sekitar 42% tanpa proses yang disengaja. Dengan pemilik bernama, integrasi sprint, dan review mingguan, angka itu naik di atas 75% dalam dua kuartal. Perbedaan dalam hal reliabilitas kira-kira setara dengan mencegah satu insiden besar tambahan per kuartal untuk tim yang berjalan pada cadence sepuluh insiden. Post-mortem memberi tahu Anda apa yang rusak. Item tindakan adalah kontrak untuk memperbaikinya. Apakah kontrak itu selesai adalah keputusan manajemen, bukan masalah kualitas dokumen. ## FAQ ### Apa yang membuat item tindakan pasca insiden menjadi efektif? Item tindakan yang efektif memiliki tiga bagian yang tidak bisa dihilangkan: apa yang perlu dilakukan (spesifik dan terukur, bukan kategori seperti 'tingkatkan monitoring'), siapa yang memilikinya (seorang engineer bernama, bukan tim), dan kapan harus selesai (tanggal spesifik). Kehilangan salah satu bagian berarti item kemungkinan tidak akan selesai. Menambahkan field konteks yang menjelaskan mengapa item itu penting secara signifikan meningkatkan tingkat penyelesaian ketika bandwidth terbatas. ### Apa perbedaan antara item tindakan mitigatif dan preventif? Item mitigatif mengurangi blast radius dari kejadian berikutnya sebelum Anda menghilangkan akar penyebabnya -- circuit breaker, timeout, fallback, ambang alert. Ini hampir selalu mendesak dan harus dikirim dalam satu sprint. Item preventif menghilangkan mode kegagalan sepenuhnya, seperti refactoring retry logic atau mendesain ulang queue consumer. Item ini membutuhkan waktu lebih lama dan harus diukur serta diprioritaskan terhadap reliability roadmap Anda secara terpisah. ### Mengapa item tindakan pasca insiden gagal diselesaikan? Penyebab paling umum adalah deskripsi yang kabur ('tingkatkan monitoring'), ownership yang ditetapkan ke tim alih-alih engineer bernama, dan item yang tetap berada dalam dokumen post-mortem yang tidak pernah terhubung ke sistem tiket tempat pekerjaan sprint sebenarnya berlangsung. Celah integrasi antara dokumen dan Jira atau Linear adalah tempat sebagian besar item hilang. ### Berapa tingkat penyelesaian item tindakan yang realistis untuk tim SRE? Riset dari incident.io menunjukkan bahwa tim SRE rata-rata menyelesaikan kurang dari 50% item tindakan pasca insiden. Tanpa proses yang disengaja, tingkat penyelesaian rata-rata sekitar 42%. Tim yang menambahkan pemilik bernama, integrasi sprint, dan review mingguan atas item terbuka biasanya mencapai di atas 75% dalam dua kuartal. Organisasi berkinerja tinggi memperlakukan angka di bawah 70% sebagai risiko reliabilitas, bukan ketidaknyamanan proses. ### Apakah item tindakan pasca insiden harus masuk ke sprint saat ini? Item mitigatif -- yang mengurangi blast radius sebelum mode kegagalan dihilangkan -- harus mendarat di sprint saat ini sebelum planning ditutup, idealnya sebelum meeting post-mortem berakhir jika cukup kecil untuk diestimasi. Item preventif diukur dan diprioritaskan terhadap roadmap pada jadwal terpisah. Mencampur keduanya dalam antrean sprint yang sama tanpa membedakannya adalah kesalahan perencanaan yang umum. ### Bagaimana cara melacak item tindakan pasca insiden tanpa menambah overhead proses? Pendekatan paling efektif adalah menghilangkan celah antara dokumen post-mortem dan alat sprint yang sudah digunakan tim Anda. Item tindakan harus menjadi tiket Jira, Linear, atau GitHub Issues sebelum meeting berakhir -- baik secara manual oleh fasilitator maupun melalui integrasi. Tim yang mengandalkan penyalinan manual dari dokumen ke sistem tiket setelah meeting kehilangan sekitar 60% item hanya dalam langkah itu saja.