Belajar 9router - Operational Readiness & Runbooks

#Pendahuluan

Di episode 20 kalian memasang mata produksi: dashboard, deteksi anomali, dan alerting yang tepat sasaran. Tapi ada lubang yang sering terlewat: ketika alert berbunyi, apakah tim tahu persis harus melakukan apa? Tanpa jawaban tertulis, setiap insiden berubah menjadi tebak-tebakan — dan dua orang yang berbeda akan melakukan dua hal yang berbeda pula.

Episode 21 menutup lubang itu dengan operational readiness. Roadmap-nya: pertama memahami apa itu runbook dan mengapa insiden routing sangat membutuhkannya, kedua membedah anatomi runbook yang baik, ketiga menetapkan ownership dan batas dukungan, dan terakhir mendokumentasikan standar route dan policy yang menjaga sistem tetap konsisten.

#Apa itu Runbook dan Mengapa Insiden Routing Membutuhkannya

Runbook adalah prosedur tertulis untuk menangani situasi tertentu — jawaban yang sudah dipikirkan sebelum keadaan memaksa berpikir. Insiden routing punya keunikan yang membuat runbook lebih penting daripada layanan biasa: jalur kegagalannya berlapis. Error bisa berasal dari model, provider, policy, atau konfigurasi route — dan kesalahan diagnosis bisa memperburuk keadaan.

Bayangkan gejala "fallback rate naik". Tiga kemungkinan akar masalah: provider utama down, classifier intent bergeser, atau policy rate limit yang baru dideploy. Tim yang punya runbook langsung menjalankan langkah diagnosis berurutan. Tim yang tidak punya runbook menghabiskan 30 menit berdiskusi di meeting darurat — sementara pengguna menunggu.

Runbook yang baik ditulis bukan untuk orang yang sedang santai membaca dokumentasi, melainkan untuk orang yang dibangunkan jam 3 pagi dalam keadaan panik.

#Anatomi Runbook Insiden Routing

Struktur runbook harus konsisten di seluruh tim, supaya on-call tidak perlu belajar format baru setiap kali membuka prosedur yang berbeda. Bagian minimal yang wajib ada: gejala, severity, langkah, rollback, dan komunikasi.

Berikut contoh runbook untuk insiden yang paling sering terjadi: provider outage pada route utama.

# Runbook: Provider Outage pada Route Utama
 
## Gejala
- Fallback rate naik di atas 20 persen pada route chat-primary
- Error 429 atau 502 beruntun dari provider utama
- Latensi p95 melonjak jika fallback tidak aktif
 
## Severity
- SEV-2: fallback bekerja, latensi normal, pengguna tidak sadar
- SEV-1: degraded mode aktif atau latensi p95 di atas 10 detik
 
## Langkah
1. Jalankan 9router status routes untuk melihat skor kesehatan
2. Konfirmasi gangguan di dashboard status vendor
3. Nonaktifkan route utama dengan 9router route disable
4. Pantau fallback dan latency selama 15 menit
 
## Rollback
- Aktifkan kembali: 9router route enable chat-primary --after 15m
- Jika error muncul lagi, ulangi dari langkah 3
 
## Komunikasi
- Posting ke kanal #incident, update tiap 30 menit
- Umumkan ke stakeholder jika SEV-1

Perhatikan tiga karakteristik runbook yang baik di contoh ini. Gejala ditulis sebagai observasi terukur, bukan perasaan. Langkah berurutan dan singkat — on-call tidak punya waktu membaca paragraf. Ada jalur rollback — setiap tindakan punya jalan pulang. Untuk akses cepat saat darurat, setiap runbook bisa diregistrasi ke 9router dan dibuka dengan 9router runbook open provider-outage.

#Ownership dan Batas Dukungan

Runbook menjawab "apa yang harus dilakukan", tetapi tidak menjawab "siapa yang bertanggung jawab". Tanpa ownership yang jelas, setiap insiden berakhir dengan pertanyaan paling mahal di dunia: "kita cek siapa dulu, ya?".

Peta tanggung jawab untuk gateway AI routing biasanya mengikuti pola RACI:

RACI ini menjelaskan batasnya dengan tegas: masalah provider adalah tanggung jawab vendor, dengan SRE sebagai accountable dan platform sebagai konsultasi. 9router tidak menggantikan dukungan vendor — ia menjembatani. Ketika request gagal dengan error yang jelas dari sisi provider, eskalasi internal tidak akan menyelesaikannya; yang dibutuhkan adalah tiket ke vendor.

Batas dukungan juga soal waktu. Definisikan SLA internal: kapan on-call diharapkan merespons (misal 10 menit untuk SEV-1), kapan harus eskalasi, dan apa jalur eskalasinya. Ekspektasi yang tidak tertulis adalah ekspektasi yang tidak pernah terpenuhi.

#Dokumentasi Standar Route dan Policy

Bagian terakhir adalah membuat sistem tetap konsisten bahkan sebelum insiden terjadi. Dua artefak yang paling penting: standar penamaan dan registri route.

Standar penamaan menghilangkan tebakan saat membaca konfigurasi. Pola yang direkomendasikan untuk 9router terdiri dari tiga segmen yang dipisahkan tanda hubung: domain, workload, dan purpose. Untuk memudahkan, tuliskan contoh dalam YAML:

routes:
  - name: chat-marketplace-main
    match:
      intent: general_chat
      metadata:
        tenant: marketplace
    target:
      model: gpt-4o
      provider: openai-prod
 
  - name: chat-marketplace-backup
    match:
      intent: general_chat
      metadata:
        tenant: marketplace
    target:
      model: claude-3-5-haiku
      provider: anthropic-prod

Nama chat-marketplace-main langsung menjelaskan domain (chat), workload (marketplace), dan peran (main). Bandingkan dengan nama route-2 yang membuat seluruh tim harus membuka isi file untuk mengerti.

Registri route adalah dokumen hidup yang mencatat setiap route beserta pemilik, provider, model, dan tanggal review terakhir. Registri ini menjawab pertanyaan "siapa yang harus saya tanya sebelum mengubah route ini?" — jauh lebih cepat daripada menelusuri history commit. Untuk perubahan signifikan, gunakan pola ADR (Architecture Decision Record) sederhana: konteks, keputusan, konsekuensi. Tiga kalimat cukup untuk merekam alasan sebuah policy dipilih.

#Penutup

Episode 21 menyelesaikan fondasi operasional: runbook yang teruji untuk insiden routing, peta ownership dengan batas dukungan yang jelas, serta standar penamaan dan registri route yang menjaga konsistensi jangka panjang.

Inti yang harus dibawa pulang:

• Runbook ditulis untuk on-call yang panik: gejala terukur, langkah berurutan, dan jalur rollback.
• Runbook harus diuji, bukan sekadar ditulis — fire drill membuat prosedur benar-benar berfungsi.
• Ownership yang jelas menghilangkan pertanyaan "siapa yang menangani ini" di tengah insiden.
• Batas dukungan vendor harus eksplisit; jangan eskala ke vendor untuk masalah internal, dan sebaliknya.
• Standar penamaan dan registri route menjaga konfigurasi tetap bisa dipahami bertahun-tahun kemudian.

Di episode 22 — episode terakhir — kita merangkum seluruh perjalanan dan menyusun paket penutup: production hardening dan best practice menyeluruh, dari checklist keamanan dan reliabilitas hingga governance dan strategi upgrade berkelanjutan. Sampai jumpa di final!