On-call adalah skill yang tidak pernah diajarkan siapa pun

Pukul 02.47 dini hari, hari Sabtu. Ponselku menyala di atas meja: CRITICAL – checkout_service P0 – payment success rate < 40%. Aku sudah duduk tegak sebelum benar-benar sadar. Aku ketuk link Slack-nya. Grafiknya terlihat seperti tebing terjal, mulai pukul 02.31. Enam belas menit pelanggan gagal menyelesaikan transaksi.

Aku buka laptop. Terminal masih terbuka dari hari Jumat. Aku ketik kubectl logs -n payments deployment/checkout-service --since=20m dan output membanjiri layar. Satu baris langsung mencolok, muncul berulang setiap beberapa detik: connection pool exhausted: max_connections=50 active=50 waiting=214.

Aku tahu ini apa. Aku rasa aku tahu ini apa.

Aku telepon kolegaku, Dian.

Kenapa tidak ada yang benar-benar mengajarkan ini

Program ilmu komputer mengajarkan kamu cara menulis kode yang bekerja. Kamu dapat algoritma, struktur data, desain sistem. Kalau beruntung, ada mata kuliah sistem terdistribusi yang membahas teorema CAP dan Lamport clock.

Tidak ada yang mengajarkan kamu cara mendiagnosis kode yang berhenti bekerja pukul 2 pagi sementara CTO sudah masuk ke group call dan grafik pembayaran masih terus turun.

On-call adalah sebuah craft. Dan seperti kebanyakan craft, satu-satunya cara mempelajarinya adalah dengan melakukannya dengan buruk dulu, lalu sedikit lebih baik, lalu akhirnya dengan semacam keanggunan. Buku Google SRE — terutama bab-bab tentang “Being On-Call” dan “Postmortem Culture” — adalah yang paling mendekati kurikulum yang dimiliki industri ini. Tapi bahkan itu pun tidak membahas soal rasa panik spesifik ketika menatap terminal sementara pendapatan seseorang sedang dipertaruhkan.

Panik adalah hal pertama yang harus kamu pelajari cara bekerjanya dari dalam. Semua hal lain adalah turunan dari itu.

Yang benar-benar memberi hasil berlipat

Setelah cukup banyak insiden, kamu mulai menyadari bahwa beberapa skill selalu terbayar setiap saat, dan beberapa skill hanya soal kecepatan — maksimum lokal yang tidak bisa ditransfer.

Membaca sistem yang sedang dalam tekanan. Hal pertama yang kamu pelajari adalah ke mana harus melihat. Bukan apa yang harus diperbaiki — tapi ke mana harus melihat pertama kali. Bagiku selalu urutan yang sama: dashboard metrik untuk menemukan bentuk masalahnya, lalu log untuk menemukan error pertama, lalu utilisasi resource untuk memahami batasannya. Bukan file konfigurasi. Bukan kode. Metrik, log, resource — dalam urutan itu — sebelum aku membentuk hipotesis apa pun. Ritual ini penting karena panik ingin membuatmu melewatkan langkah. Panik ingin kamu langsung menjangkau perubahan yang terasa paling jelas. Ritual ini memperlambatmu cukup untuk benar-benar melihat masalah yang sebenarnya.

Sabtu itu, masalahnya ada di connection pool. Tapi butuh dua hipotesis yang salah dulu. Aku restart deployment — tidak ada perubahan. Aku cek database slow query log — bersih. Aku buang sembilan menit untuk itu. Pool exhaustion sudah ada di log sejak awal. Aku saja yang tidak melihat ke sana lebih dulu.

Narasi keras-keras. Dian yang mengajarkanku ini. Ketika dia ada di incident bridge, dia berbicara melewati setiap langkah. “Aku sedang melihat ingress metrics. Latency normal. Pindah ke service layer.” Kedengarannya aneh pertama kali kamu dengar. Rasanya seperti memperlambat segalanya.

Tapi itu tidak memperlambat apa pun. Yang terjadi justru suhu ruangan turun. Ketika seseorang sedang bernarasi, orang lain di call bisa mengikuti alur pikirnya, menangkap kesalahan, menyingkirkan hipotesis secara paralel. Lebih penting lagi: itu memberi tahu semua orang bahwa ada seseorang yang memegang kendali situasi. Keheningan dalam crisis call adalah hal paling berbahaya. Keheningan adalah tempat asumsi menumpuk.

Aku pakai cara ini sejak saat itu. Aku bukan orang yang secara alami tenang di bawah tekanan. Tapi aku menemukan bahwa kalau aku terus bicara — pelan, metodis, keras-keras — ketenangan mengikuti narasinya, bukan sebaliknya.

Postmortem sebagai alat belajar yang sesungguhnya. Aku sudah hadir di banyak postmortem yang hanya teater performa. Semua orang berhati-hati. Tidak ada yang menyebut nama. Bagian “faktor-faktor yang berkontribusi” sudah begitu disanitasi sehingga bisa menggambarkan outage mana pun di perusahaan mana pun. Kamu arsipkan dokumennya, kirim ke distribution list, dan kelas insiden yang sama terjadi lagi empat bulan kemudian.

Versi yang benar-benar menghasilkan hasil berlipat terlihat berbeda. Dimulai dari framing fondasi John Allspaw tentang blameless postmortem — prinsip bahwa orang-orang mengambil tindakan yang masuk akal bagi mereka berdasarkan apa yang mereka ketahui saat itu, dan investigasinya harus tentang memahami konteks itu, bukan menetapkan kesalahan. Tapi lebih dari sekadar blameless. Postmortem yang mengubah cara aku berpikir adalah yang jujur tentang kebingungan. Bukan hanya “operator error” tapi “ini titik di mana aku benar-benar tidak tahu apa yang sedang terjadi, ini kenapa sistem menyulitkan untuk melihatnya, dan ini yang seharusnya membantu.”

Postmortem insiden checkout punya satu bagian berjudul “Hal-hal yang terlihat seperti masalah tapi ternyata bukan.” Aku menulis dua paragraf tentang sembilan menit yang aku habiskan mengejar hipotesis yang salah. Bagian itu lebih sering dirujuk dalam insiden-insiden berikutnya dibanding bagian faktor-faktor yang berkontribusi.

Runbook yang mengakui apa yang tidak diketahui penulisnya. Runbook yang ditulis oleh seseorang yang benar-benar memahami sistem pada saat insiden seringkali tidak berguna bagi seseorang yang tidak memahaminya. Runbook paling berguna yang pernah aku temukan — dan yang aku coba tulis — mencakup hal-hal yang penulisnya tidak yakin. “Aku tidak yakin apakah langkah 4 selalu perlu — coba lewati dulu dan cek apakah error count turun.” “Pola log yang kamu cari adalah pool exhausted tapi mungkin tertulis connection refused tergantung service mana yang memanggil.” Ketidakpastian, yang dibuat eksplisit, adalah bentuk dokumentasi.

Hal yang benar-benar membedakan senior dari yang lain

Dulu aku pikir itu soal kecepatan. Engineer senior menyelesaikan insiden lebih cepat. Itu memang benar, tapi itu adalah konsekuensi, bukan penyebabnya.

Bukan juga soal hafalan perintah. Perintah bisa kamu Google. Yang tidak bisa kamu Google adalah judgment.

Hal yang aku perhatikan dari engineer-engineer yang paling banyak mengajariku — dan hal yang Allspaw gambarkan lebih baik dari siapa pun dalam tulisannya tentang senior engineering — adalah judgment tentang hipotesis mana yang harus diuji lebih dulu. Insiden adalah pengujian hipotesis di bawah tekanan waktu. Setiap pemeriksaan yang kamu jalankan memakan waktu. Langkah senior bukan tentang mengetahui semua jawaban. Ini tentang mengetahui pertanyaan apa yang harus ditanyakan berikutnya, kenapa, dan berani mengatakan “aku menyingkirkan ini, ini alasannya” sebelum datanya ada.

Ini bisa dipelajari. Ini datang dari postmortem yang benar-benar kamu baca, dari insiden yang kamu tetap hadiri ketika ingin pergi, dari melihat bagaimana orang lain membangun pohon hipotesis ketika alert tidak masuk akal. Ini bukan sifat kepribadian. Ini skill yang kamu bangun dengan berada di dalam ruangan.

Charity Majors sudah menulis tentang sisi observability dari ini selama bertahun-tahun di charity.wtf — argumen bahwa kamu tidak bisa membangun judgment ini tanpa instrumentasi yang memberi tahu kamu apa yang sedang dilakukan sistem, bukan hanya apakah sistem itu hidup atau tidak. Aku akan menambahkan: instrumentasi itu perlu tapi belum cukup. Kamu juga perlu kebiasaan postmortem yang mengubah setiap insiden menjadi satu titik data.

Yang akan aku katakan kepada junior engineer yang memulai rotasi pertamanya

Berhenti mencoba terlihat tenang. Kamu tidak akan tenang. Tidak apa-apa.

Tujuannya bukan untuk merasa tahu apa yang kamu lakukan. Tujuannya adalah punya proses yang bekerja bahkan ketika kamu tidak tahu apa yang kamu lakukan. Tuliskan sebelum kamu di-page. “Ketika aku mendapat alert yang tidak aku kenali, aku akan: cek runbook, lihat dashboard yang relevan, cek deploy terbaru, lalu minta bantuan.” Jadikan langkah eskalasi eksplisit dan awal. Engineer yang paling cepat berkembang dalam on-call bukan yang menyelesaikan insiden sendirian — mereka yang melakukan eskalasi dengan jelas dan kemudian tetap ada di call untuk melihat apa yang terjadi selanjutnya.

Baca buku Google SRE sebelum kamu mulai, atau setidaknya bab on-call dan postmortem-nya. Gratis online. Itu tidak akan mencegah insiden buruk pertamamu. Tapi itu akan memberimu kosakata untuk memahami apa yang terjadi sesudahnya, dan kosakata adalah cara kamu mengubah pengalaman menjadi skill.

Setelah insiden, tuliskan apa yang kamu coba. Bukan yang berhasil. Semua yang kamu coba, secara berurutan, termasuk hipotesis yang salah. Dokumen itu nilainya lebih dari tutorial mana pun.

Ketenangan setelahnya

Pukul 04.12. Batas connection pool dinaikkan ke 200. Database proxy dijadwalkan untuk sprint berikutnya. Checkout success rate kembali ke 99,3%. Aku sudah kirim ringkasan insiden ke on-call channel dan menyusun kerangka postmortem. Dian masih ada di Slack.

“Bagus, tadi kamu tetap tenang,” dia ketik.

Aku sempat ingin bilang bahwa aku tidak tenang. Bahwa aku menghabiskan sembilan menit pada hipotesis yang salah dan merasakan keringat dingin yang spesifik ketika menyadari aku membuang waktu. Bahwa aku terus berbicara keras-keras sebagian besar karena dia yang mengajariku dan aku butuh strukturnya.

Tapi aku ketik saja: “Kamu juga. Aku akan tulis bagian sembilan menit yang melenceng itu di postmortem — berguna.”

Grafiknya naik kembali. Kursor berkedip.

Lain kali aku akan melihat connection pool lebih dulu.