Troubleshooting Dasar — Pengalaman Nyata dari Lapangan
Ketika Client Bilang "Gak Jalan"
Suatu hari kamu akan bangun dan menemukan pesan dari client:
"Hei, workflow saya gagal. Kamu ngapain?"
Client tidak mengirim stack trace atau log — mereka mengirim pesan singkat yang vague dan nonspesifik. Dan itu sepenuhnya normal. Cara kamu menangani momen ini yang membedakan freelancer dari agensi profesional.
┌─────────────────────────────────────────┐
│ MINDSET TROUBLESHOOTING │
├─────────────────────────────────────────┤
│ │
│ ❌ Panik → Tebak → Perbaiki asal jadi │
│ │
│ ✅ Tenang → Investigasi → Root Cause │
│ → Perbaiki → Cegah terulang │
│ │
└─────────────────────────────────────────┘Langkah Pertama: Kumpulkan Konteks
Tugas pertama kita bukan memperbaiki, tapi mengumpulkan konteks yang akurat:
| Pertanyaan | Tujuan |
|---|---|
| Apa yang berhenti bekerja? | Identifikasi scope masalah |
| Kapan gagalnya? | Timeline untuk korelasi event |
| Workflow mana yang terdampak? | Cek apakah masalah menyebar |
Pelajaran dari Pengalaman
"Pernah workflow saya gagal, dan saya langsung fix tanpa cari root cause. Saya pikir nanti saya cek lagi — tapi 'nanti' itu tidak pernah datang."
Jangan terjebak quick fix yang melewatkan akar masalah!
Studi Kasus: API Key Expired
Pengalaman nyata instruktur:
- Masalah: Client melaporkan workflow gagal
- Gejala: OpenAI menampilkan "quota exceeded"
- Langkah yang diambil:
Langkah 1: Fix dulu agar client tidak menunggu
(ganti API key)
Langkah 2: SEBELUM lupa — catat di to-do list
"Cek RCA nanti"
Langkah 3: Investigasi Root Cause Analysis:
├── Apakah quota benar-benar habis?
├── Apakah ada yang mengubah credential?
├── Kapan terakhir dipublish?
├── Berapa execution yang gagal?
└── Apakah key yang sama dipakai workflow lain?
Langkah 4: Cek error log → ternyata workflow lain
yang pakai key sama juga ikut gagal!Kunci: Jangan berhenti setelah memperbaiki satu workflow. Cek apakah error menyebar ke workflow lain yang menggunakan resource yang sama.
Urutan Troubleshooting Standar
Ikuti urutan ini — 80% masalah terselesaikan dengan framework ini:
┌──────────────────────────────────────────────┐
│ TROUBLESHOOTING FRAMEWORK │
│ │
│ 1. 📋 Cek Execution Log │
│ │ │
│ 2. 🔑 Test Credentials │
│ │ │
│ 3. 🔗 Validasi Entry Point / Webhook │
│ │ │
│ 4. 🌐 Review Network & Connectivity │
│ │ │
│ 5. 🔍 Isolasi Trigger vs Logic Workflow │
│ │ │
│ 6. ✅ Apply Fix & Komunikasikan │
└──────────────────────────────────────────────┘Troubleshooting ≠ Hanya Teknis
Troubleshooting di agensi bersifat client-facing work. Bukan sekadar memperbaiki kode — kamu harus:
- Mengkomunikasikan progres ke client
- Memberikan timeline realistis
- Menunjukkan profesionalisme saat krisis
- Menjaga kepercayaan meski ada masalah
"Sebelum client saya tahu ada error, saya sudah menghubungi dia: 'Hei, kayaknya ada alert di workflow kamu. Biar saya cek dulu.' Dan dia sangat senang karena proaktivnya saya."
Takeaway
- Jangan panik ketika client melaporkan masalah
- Kumpulkan konteks sebelum memperbaiki
- Cek apakah error menyebar ke workflow lain
- Catat temuan sebelum lupa
- Troubleshooting adalah skill client-facing, bukan cuma teknis