Saat AI Tangani Insiden, Engineer Perlahan Kehilangan Sentuhan dengan Sistemnya

Ada ironi yang mulai terasa di dunia Site Reliability Engineering. Alat bantu berbasis AI untuk menangani insiden semakin canggih. Mereka bisa memeriksa alert, menyusun hipotesis, menelusuri telemetry, mengorelasikan data dengan deployment terbaru, bahkan menerapkan perbaikannya sendiri. Di permukaan, ini kabar bagus: insiden rutin bisa ditangani otomatis, dan engineer tidak perlu bangun tengah malam hanya karena kapasitas server menipis.

Tapi di balik kemudahan itu, ada kekhawatiran yang jarang dibicarakan: kita kehilangan sentuhan dengan sistem kita sendiri. Sylvain Kalache, yang pernah bekerja sebagai SRE di LinkedIn dan kini memimpin AI Labs di Rootly, menyuarakan kekhawatiran ini dengan gamblang. Menurutnya, semakin baik alat AI menangani insiden rutin, semakin sedikit latihan yang didapat responden manusia. Dan ketika insiden yang benar-benar rumit datang, insiden yang tidak bisa diselesaikan otomatisasi, engineer yang bertugas akan kewalahan karena otot mereka sudah lama tidak dipakai.

Paradoks Otomasi yang Sudah Tua

Kekhawatiran ini sebenarnya bukan hal baru. Pada 1983, peneliti faktor manusia bernama Lisanne Bainbridge menerbitkan makalah terkenal berjudul The Ironies of Automation. Inti argumennya sederhana dan menusuk: otomasi mengurangi kesempatan operator untuk berlatih menangani pekerjaan rutin, tapi tetap meninggalkan mereka bertanggung jawab atas situasi baru dan abnormal. Dengan kata lain, semakin sukses sebuah sistem otomatis, semakin tidak siap manusia yang seharusnya mengawasinya saat sistem itu gagal.

Bainbridge berargumen bahwa operator justru perlu lebih terampil dan mendapat lebih banyak pelatihan setelah otomasi diperkenalkan, bukan lebih sedikit. Sebab pekerjaan yang tersisa untuk manusia bukanlah pekerjaan mudah. Itu adalah residu dari semua yang tidak bisa diotomatisasi, dan biasanya justru bagian yang paling sulit.

Paradoks ini dulu berlaku untuk pilot, operator pembangkit listrik, dan kru kapal. Sekarang berlaku juga untuk engineer yang menjaga layanan digital. Dulu, insiden rutin adalah sekolah tempat responden belajar membaca gejala sistem: pola grafik yang aneh, error log yang tidak biasa, hubungan sebab-akibat antara perubahan kecil dan dampak besar. Latihan itu yang membangun intuisi. Kalau AI SRE sekarang yang menangani semua kasus rutin, dari mana intuisi itu tumbuh?

Prediksi yang Tidak Nyaman

Kalache membuat prediksi yang layak dicermati. Dalam beberapa tahun ke depan, rata-rata MTTR (mean time to resolve) untuk kebanyakan insiden akan turun, berkat bantuan AI dalam incident response. Tapi di saat yang sama, waktu penyelesaian untuk insiden kompleks akan melonjak, karena responden kehilangan sentuhan dengan sistem mereka dan kesulitan saat harus menyelidiki secara manual.

Ini skenario dua sisi yang jahat. Statistik rata-rata akan terlihat bagus, dan leadership akan senang karena angka MTTR membaik. Tapi di balik rata-rata itu, ada ekor panjang insiden yang justru makin sulit ditangani. Dan insiden di ekor panjang itulah yang biasanya paling merusak: yang melibatkan banyak sistem, keadaan yang belum pernah terlihat, atau kegagalan yang tidak muncul di runbook mana pun.

Intuisi yang hilang itu bukan sekadar nostalgia. Ketika seorang engineer sudah ribuan kali melihat pola kapasitas menipis, dia bisa mengenali varian aneh dari pola itu dalam hitungan detik. Kemampuan pattern recognition semacam itu tidak bisa ditransfer lewat dokumentasi atau dipelajari dari video. Ia terbentuk dari pengalaman langsung yang berulang, dan pengalaman langsung itulah yang sekarang sedang diambil alih oleh agen AI.

Belajar dari Industri Penerbangan

Industri penerbangan sudah bergulat dengan masalah yang sama selama puluhan tahun, dan pendekatan mereka layak ditiru. Autopilot menangani sebagian besar fase terbang, tapi pilot tetap bertanggung jawab atas situasi yang tidak bisa ditangani otomasi: kegagalan mesin, instrumen yang tidak bisa dipercaya, rejected takeoff, stall, dan kondisi abnormal lainnya.

Kejadian macam itu sangat langka. Mesin turbin modern, misalnya, mengalami kurang dari satu in-flight shutdown per 100.000 jam terbang mesin. Sekuat itulah teknologinya. Tapi konsekuensinya, seorang pilot komersial bisa menjalani seluruh kariernya tanpa pernah mengalami kegagalan nyata di luar simulator. Kalau tidak ada persiapan khusus, begitu kegagalan itu benar-benar terjadi, pilot tidak akan punya pengalaman untuk bereaksi dengan benar.

Contoh tragisnya adalah TransAsia Airways Flight 235. Tak lama setelah lepas landas, baling-baling mesin kanan mengalami autofeather. Pesawat sebenarnya dirancang untuk terus terbang dengan mesin kiri, tapi kru salah mengidentifikasi masalah, malah mematikan mesin yang masih sehat. Pesawat jatuh hanya 117 detik setelah peringatan pertama muncul.

Karena itulah pilot secara rutin kembali ke simulator untuk mengulang skenario darurat yang langka. Di bawah aturan FAA Amerika Serikat, kapten wajib menjalani pelatihan berulang atau proficiency check setiap enam bulan, termasuk skenario kegagalan mesin saat lepas landas. Simulator adalah tempat yang aman untuk berlatih menghadapi bencana, sehingga saat bencana sungguhan datang, responsnya sudah terlatih.

Insiden software jarang mengancam nyawa seperti kecelakaan pesawat. Tapi itu bukan alasan untuk tidak menyempurnakan keahlian. Prinsip yang sama berlaku: kalau insiden langka dan berisiko tinggi, latihan teratur di lingkungan yang aman adalah harga yang wajib dibayar.

Simulasi Insiden untuk Engineer

Kabar baiknya, ide simulator sudah mulai merambah dunia software. Rootly, perusahaan tempat Kalache bekerja, berkolaborasi dengan Uptime Labs untuk menghadirkan simulasi insiden yang realistis. Engineer mengambil kursi incident commander selama simulasi outage e-commerce, menggunakan alat observability, sambil berkoordinasi dengan stakeholder yang diperankan LLM di Slack. Hasilnya terasa nyata: lo harus menyelidiki apa yang salah sambil menjaga response tetap terorganisir dan berurusan dengan CEO serta customer support yang panik.

Simulasi macam ini melatih keterampilan yang benar-benar dipakai saat insiden: memahami informasi yang tidak lengkap, berkomunikasi dengan jelas, mengoordinasikan orang, dan menjalankan response secara nyata. Bukan sekadar mengeklik runbook, tapi berpikir di bawah tekanan dengan informasi yang berantakan. Persis seperti pilot di simulator, engineer berlatih menghadapi kekacauan di lingkungan yang aman.

Tabletop exercise dan chaos engineering sebenarnya bukan hal baru di industri software. Tapi di era LLM, praktik semacam ini jadi jauh lebih penting. Karena semakin banyak pekerjaan rutin yang diambil alih otomasi, semakin sedikit kesempatan alami untuk belajar, dan latihan terstruktur menjadi satu-satunya jalan untuk menjaga keterampilan tetap tajam.

AI sebagai Pelatih, Bukan Pengganti Latihan

Ada satu nuansa yang sering terlewat: AI sebenarnya bisa dipakai untuk melatih keterampilan ini, bukan cuma mengambil alih pekerjaannya. Responden bisa meminta agen AI menjelaskan langkah yang diambilnya, sinyal apa yang diperiksa, dan bukti apa yang mendasari diagnosisnya. Penjelasan semacam ini bisa jadi bahan belajar yang berharga.

Tapi penjelasan dan observasi bukan pengganti praktik. Kalache memakai analogi yang tepat: lo bisa belajar beberapa hal dari menonton Serena Williams bermain, tapi lo hanya benar-benar belajar tenis dengan turun ke lapangan. Incident response tidak berbeda. Membaca postmortem orang lain atau menonton agen AI menyelesaikan insiden tidak akan membangun intuisi yang sama dengan benar-benar menangani insiden.

Kalache sendiri sudah membuktikan filosofi learning by doing ini sepanjang kariernya. Lebih dari separuh dekade dia habiskan membangun sekolah software engineering yang berfokus pada pendidikan progresif: tanpa dosen, siswa belajar dari proyek, bukan ceramah. Ketika Dropbox memberi tahu bahwa lulusan yang mereka rekrut masih kurang berpengalaman dalam troubleshooting, Kalache merespons dengan membuat proyek yang memberi siswa infrastruktur yang sengaja dirusak dan meminta mereka mendiagnosis serta memperbaikinya. Untuk keterampilan tangan, pendidikan langsung hampir selalu mengalahkan instruksi pasif.

Utang Pemahaman yang Menumpuk

Kalache menyebut risiko terbesarnya dengan istilah yang pas: comprehension debt, atau utang pemahaman. Ini adalah celah yang makin melebar antara cara sistem bekerja dan seberapa baik responden memahaminya. Seiring LLM mengerjakan lebih banyak pekerjaan kita, utang ini menumpuk diam-diam. Sistem tetap berjalan, angka MTTR terlihat sehat, tapi pemahaman tim tentang sistemnya sendiri menguap sedikit demi sedikit.

Utang pemahaman lebih berbahaya daripada technical debt biasa karena tidak terlihat. Technical debt muncul di kode dan bisa dideteksi lewat review atau analisis statis. Utang pemahaman ada di kepala manusia, dan baru terasa saat insiden kompleks datang dan tidak ada yang benar-benar mengerti apa yang terjadi. Pada titik itu, tidak ada refactor yang bisa menyelamatkan, karena masalahnya bukan di kode, tapi di kapasitas tim untuk berpikir jernih tentang sistemnya.

Obatnya sama seperti obat utang teknis: investasi rutin, bukan proyek sekali jalan. Engineer perlu secara teratur berinteraksi dengan sistem yang mereka jaga, menangani kegagalan yang tidak familiar, berlatih bekerja di bawah tekanan, dan mengulang koordinasi serta komunikasi yang dibutuhkan saat SEV0 melanda. Simulasi insiden, chaos engineering, dan rotasi on-call yang dirancang dengan baik bukan kemewahan, melainkan biaya operasional di era AI.

Kesimpulan

Ironi otomasi yang diidentifikasi Bainbridge pada 1983 kini menimpa dunia SRE dengan wajah baru: AI SRE. Alat ini luar biasa dalam menangani insiden rutin, dan itu kabar baik. Tapi setiap insiden rutin yang diambil alih mesin adalah satu kesempatan latihan yang hilang bagi manusia, dan kesempatan itulah yang membangun kemampuan menangani insiden langka dan kompleks.

Jawabannya bukan menolak AI, melainkan meniru industri penerbangan: otomatisasi boleh maju, tapi latihan teratur untuk skenario terburuk tetap wajib. Simulasi insiden, chaos engineering, dan budaya belajar dari kegagalan harus jadi bagian rutin dari operasional, bukan acara tahunan. Karena di era di mana mesin menangani hampir semuanya, kemampuan manusia justru jadi barang langka yang paling mahal saat semuanya gagal.

Buat tim yang baru mulai, langkah pertama tidak perlu besar. Ambil satu insiden yang pernah terjadi, ubah menjadi skenario simulasi, dan minta anggota tim menjalankannya secara bergiliran dengan tenggat waktu yang realistis. Catat di mana mereka kesulitan, di mana komunikasi macet, dan keputusan mana yang diambil tanpa data cukup. Satu jam latihan terstruktur per bulan jauh lebih berharga daripada menonton agen AI bekerja seribu kali, dan itu modal paling murah untuk malam ketika sistem beneran tumbang dan tidak ada yang bisa dihubungi kecuali tim lo sendiri.

Intinya sederhana: biarkan AI menangani yang rutin, tapi jangan biarkan ia melatih tim lo menggantikan pengalaman nyata. Keduanya berjalan beriringan, dan tim yang paham akan menjaga keduanya tetap hidup.