Di bagian pertama kita sudah membahas mengapa membuat postmortem itu tidak semudah yang dibayangkan. Setelah insiden, biasanya tim sudah cukup letih memperbaiki masalah yang terjadi agar SLA yang disepakati bersama tercapai. Terkadang, ada juga perasaan malu melihat kesalahan tim sendiri, dan sering kali ada hal lain yang terasa lebih mendesak sehingga postmortem akhirnya hanya jadi judul atau bahkan tidak pernah terdokumentasi sama sekali.

Pada bagian kedua ini, saya ingin menekankan sadari awal bahwa isi dari artikel yang saya bagikan ini bukanlah solusi yang sangat revolusioner atau mengklaim mampu menyelesaikan semua tantangan dokumentasi di tim, melainkan hanya membagikan sebuah use case dan melakukan eksperimen sederhana untuk menjawab pertanyaan, “jika AI dan Vector Database bisa digunakan untuk membangun chatbot atau sistem rekomendasi e-commerce, mengapa tidak kita coba manfaatkan untuk membantu tim dalam menulis postmortem?” Sistem yang saya coba bangun di eksperimen kecil ini sebenarnya sangat sederhana, hanya memiliki dua endpoint /ingest dan /generate.

Stack yang dipakai pun sederhana dan bisa dijalankan di lokal: FastAPI untuk REST API, Qdrant sebagai Vector Database untuk menyimpan payload insiden, dan LLaMA (llama-cpp-python) sebagai local model untuk menghasilkan teks postmortem.

Pertama, endpoint /ingest. Digunakan sebagai tempat menyimpan kronologi insiden dengan cara yang lebih terstruktur, lalu dengan memanfaatkan Vector Database (Qdrant) untuk menyimpan payload insiden yang terdiri dari judul, kronologi, dan tag. Apakah embedding yang dipakai sudah canggih? Tentu saja belum, masih dummy 🙂 Tapi bahkan dummy vector lebih baik daripada tidak ada struktur sama sekali, karena setidaknya kita sudah memulai untuk membuat satu langkah penting, yaitu menyimpan kronologi secara konsisten.

Contoh penggunaannya, kita bisa melakukan ingest seperti berikut:

$ curl -X POST http://localhost:8000/ingest \
-H "Content-Type: application/json" \
-d '{
  "title": "Internal DNS Outage",
  "timeline": "On June 10th, internal DNS resolution failed across staging environments due to expired CoreDNS pod configmap. Engineers redeployed DNS stack manually.",
  "tags": ["dns", "internal", "kubernetes", "config"]
}'

Endpoint kedua yaitu /generate. Di bagian inilah kita meminta bantuan LLM (model lokal LLaMA) untuk membantu menulis draft postmortem. Masalah sebenarnya bukan hanya soal kronologi yang kadang terlupa, tapi kadang juga kita merasa kesulitan ketika memulai menyusun kalimat pertama. Dengan prompt yang sangat sederhana kronologi mentah bisa diubah menjadi narasi yang lebih terstruktur. Ini tidak sebagai titik awal kronologi yang bisa disesuaikan kembali.

Contoh penggunaannya bisa seperti ini:

$ curl -X POST http://localhost:8000/generate \
-H "Content-Type: application/json" \
-d '{
  "timeline": "On June 10th, internal DNS resolution failed across staging environments due to expired CoreDNS pod configmap. Engineers redeployed DNS stack manually."
}'

Outputnya:

{"postmortem":"Below is a suggested post-mortem report based on the provided chronology of events:\n\nPost-Mortem Report: Internal DNS Resolution Failure on June 10th\n\nIntroduction:\nOn June 10th, our internal DNS resolution failed across all staging environments due to an expired CoreDNS pod configmap. This incident affected multiple teams and resulted in significant disruption to our development workflows. In this report, we will detail the events leading up to the incident and the steps taken to resolve it.\nChronology of Events:\n6:00 AM - Internal DNS resolution fails across all staging environments\n6:30 AM - Engineers identify the cause of the failure as an expired CoreDNS pod configmap.\n7:00 AM - Engineers manually redeploy the DNS stack to resolve the issue.\n8:00 AM - Development teams begin reporting issues with accessing resources and services.\n9:00 AM - Engineers verify that the issue has been resolved and that DNS resolution is working as expected.\n\nRoot Cause Analysis:\nThe root cause of the incident was the expiration of the CoreDNS pod configmap. This caused the DNS stack to fail, resulting in disruption of internal DNS resolution across all staging environments.\nContributing Factors:\n* Insufficient monitoring of the CoreDNS pod configmap led to its expiration.\n* Lack of automated backup and restore processes for the DNS stack resulted in manual intervention being required.\n\nRecommendations for Prevention:\nTo prevent similar incidents from occurring in the future, we recommend the following:\n* Implement monitoring and alerting mechanisms for the CoreDNS pod configmap to ensure its renewal and avoid expiration.\n* Develop and implement automated backup and restore processes for the DNS stack to enable faster resolution of issues.\n* Provide training and awareness programs for engineers on the importance of DNS resolution and the potential consequences of failure.\n\nConclusion:\nIn conclusion, the internal DNS resolution failure on June 10th was caused by an expired CoreDNS pod configmap. The incident was resolved through manual intervention, but it highlights the importance of monitoring and automating backup and restore processes for the DNS stack. We will implement the recommendations outlined in this report to prevent similar incidents from occurr"}

Solusi seperti ini tentu belum bisa menjawab sepenuhnya. Belum ada fitur atau endpoint pencarian insiden yang serupa, embedding-nya pun belum sungguhan, belum mendukung multi-user atau keamanan yang lebih baik, dan belum ada UI. Tapi setidaknya ini sudah cukup memberi gambaran kepada kita bahwa LLM dan Vector Database bisa dipertimbangkan dan dikembangkan lebih lanjut untuk menyelesaikan dan menciptakan penyususan postmortem yang lebih terstruktur dan mudah dikelola 🙂