Debugging Production Issues at 2 AM: A Survival Guide [Bahasa]

# Memecahkan Masalah Produksi pada Pukul 2 Pagi: Panduan Bertahan Hidup 2:17 AM. PagerDuty. Pemberitahuan mengatakan tingkat kesalahan 95% pada layanan pembayaran. 847 transaksi terpengaruh. Perutmu terasa mules. Kau terbangun secara instan—adrenaline jenis tertentu yang hanya muncul dari insiden produksi. Ponselmu sudah terunlock, laptop mulai booting, mesin kopi berdengung bangkit dengan memori otot saja. Ini adalah halaman nomor 847 dalam kariermu. Ya, kau melacaknya. Kau mulai menghitung setelah halaman 200 ketika kau menyadari bahwa ini akan menjadi bagian penting dari kehidupan profesionalmu, dan jika kau akan terbangun di jam-jam yang tidak wajar, kau sebaiknya punya data tentangnya. Layanan pembayaran. Tentu saja itu layanan pembayaran. Selalu layanan pembayaran, atau layer autentikasi, atau satu mikroservis yang seseorang bersumpah bahwa itu "hanya pembungkus sederhana" tiga tahun lalu dan sejak itu telah bermetamorfosis menjadi ketergantungan jalur kritis bagi setengah infrastruktur mu. Kau mungkin punya waktu 90 detik sebelum halaman kedua terkirim ke manajermu. Mungkin tiga menit sebelum pelanggan mulai membanjiri saluran dukungan. Mungkin lima menit sebelum seseorang dari C-suite bangun dan mulai mengajukan pertanyaan di Slack. Waktu terus berjalan, tanganmu bergerak, dan otakmu sudah melewati daftar mental yang telah kau bangun selama ratusan insiden ini. Ini bukan rodeo pertamamu. Tapi inilah yang tidak diberitahukan orang tentang debugging produksi pada pukul 2 pagi: itu tidak pernah lebih mudah. Kau hanya menjadi lebih cepat. Kau membangun alat yang lebih baik. Kau membuat lebih sedikit kesalahan bodoh. Kau belajar mempercayai instingmu sambil sekaligus mempertanyakan segalanya. Kau mengembangkan indera keenam untuk mengetahui apa yang benar-benar rusak versus apa yang hanya terlihat rusak. Dan yang paling penting, kau belajar bahwa perbedaan antara insiden 10 menit dan insiden 4 jam sering kali bergantung pada 60 detik pertama tanggapanmu. Panduan ini adalah semua yang kuinginkan seseorang beritahukan padaku sebelum halaman nomor 1.

60 Detik Pertama: Triage Seolah-Olhnya Pekerjaanmu Bergantung Padanya

Menit pertama dari insiden produksi apa pun adalah manajemen kekacauan murni. Otakmu masih mulai berjalan, kau mungkin tidak mengenakan celana, dan kau perlu membuat keputusan krusial yang akan menentukan apakah insiden ini teratasi dalam beberapa menit atau jam. Inilah yang aku lakukan, dalam urutan, setiap kali: Akui halaman tersebut segera. Jangan tunggu untuk "menyelidiki terlebih dahulu." Akui itu. Ini menghentikan rantai eskalasi dan memberi sinyal kepada timmu bahwa seseorang sudah menangani. Aku telah melihat terlalu banyak insiden di mana beberapa orang dihubungi karena orang pertama yang merespons ingin "hanya melihat sekilas" sebelum mengakui. 30 detik penyelidikan itu merugikanmu responder cadangan yang seharusnya bisa tidur. Buka dasbor respons insidenmu. Bukan aplikasi. Bukan log. Dasbor milikmu. Yang menunjukkan kesehatan sistem dalam sekejap. Bagiku, itu adalah papan Grafana kustom yang menunjukkan tingkat kesalahan, persentil latensi, kolam koneksi basis data, kedalaman antrean, dan penggunaan CPU/memori di semua layanan kritis. Aku bisa melihat radius ledakan dalam waktu kurang dari 5 detik. Periksa jika itu masih terjadi. Ini terdengar jelas, tetapi aku sudah dihubungi untuk masalah yang teratasi sendiri 30 detik sebelum alert muncul. Sistem pemantauan memiliki keterlambatan. Ambang batas peringatan memiliki jendela evaluasi. Terkadang masalah sudah hilang, dan kau perlu tahu itu sebelum mulai membatalkan penyebaran atau memulai ulang layanan. Ini menilai dampak pelanggan. Bukan dampak teoretis—dampak nyata. Berapa banyak pengguna yang terpengaruh saat ini? Apakah itu 100% dari lalu lintas atau 5%? Apakah itu terisolasi di satu wilayah, satu segmen pelanggan, satu fitur? Ini menentukan urgensi tanggapanmu dan apakah kau perlu membangunkan lebih banyak orang. Dalam insiden khusus ini—layanan pembayaran pada pukul 2:17 AM—dasbor ku memberi tahu semua yang perlu aku ketahui dalam 8 detik. Tingkat kesalahan: 94,7%. Permintaan yang terpengaruh: 847 dalam 5 menit terakhir. Distribusi geografis: global. Segmen pelanggan: semua. Latensi API penyedia pembayaran: normal. Koneksi basis data: normal. Masalahnya tidak di hulu atau di hilir. Itu kami. Saat itulah aku tahu aku sedang menghadapi malam yang panjang.

Metodologi Debugging yang Sebenarnya Berfungsi di Bawah Tekanan

Semua orang memiliki metodologi debugging saat mereka tenang, terjaga, dan bekerja di lingkungan pengembangan pada pukul 2 siang. Sangat sedikit orang memiliki metodologi yang tetap berfungsi saat kau setengah tertidur, CEO ada di saluran insiden, dan setiap detik waktu henti mengakibatkan biaya nyata. Aku menggunakan apa yang aku sebut pendekatan "Radius Ledakan ke Akar Masalah". Ini tidak mewah, tetapi itu berfungsi saat otakmu beroperasi pada 60% kapasitas. Mulai dengan radius ledakan, bukan akar masalah. Ini bertentangan dengan intuisi. Setiap insting memberitahumu untuk segera menemukan akar masalah. Tahan insting itu. Pertama, pahami dengan tepat apa yang rusak dan apa yang tidak. Peta batas-batas kegagalan. Ini melayani dua tujuan: mencegahmu mengejar hal-hal yang tidak relevan dalam sistem yang sehat, dan sering kali secara langsung menunjukkan akar masalah melalui proses eliminasi. Untuk insiden layanan pembayaran, aku menghabiskan 90 detik untuk memetakan radius ledakan: - Inisiasi pembayaran: gagal - Pemeriksaan status pembayaran: gagal - Webhook pembayaran: gagal - Proses pengembalian dana: berjalan baik - Kuery pembayaran admin: berjalan baik Pola itu memberi tahu saya sesuatu yang penting: operasi baca berjalan baik, operasi tulis gagal. Itu adalah masalah basis data, masalah antrean, atau masalah izin. Tiga kemungkinan alih-alih tiga puluh. Ikuti aliran data, bukan aliran kode. Ketika kau debugging pada pukul 2 pagi, kau tidak punya waktu untuk menelusuri kode. Ikuti data. Di mana permintaan pembayaran masuk ke sistem? Kemana ia pergi selanjutnya? Di mana ia gagal? Aku menarik tracing distribusi kami (syukurlah kami memilikinya) dan melihat satu permintaan mengalir melalui sistem. Itu berhasil melalui autentikasi, melalui pembatasan laju, melalui validasi, dan mati pada saat mencoba menulis ke basis data. Basis data. Di situlah masalahnya. Periksa hal-hal membosankan terlebih dahulu. Ruang disk. Memori. Kolam koneksi. Deskriptor file. Masa berlaku sertifikat. DNS. Hal-hal membosankan membunuh lebih banyak sistem produksi daripada bug cerdas lainnya. Aku pernah dihubungi pada pukul 2 pagi karena pekerjaan cron seseorang memenuhi disk. Aku pernah dihubungi karena sertifikat kedaluwarsa. Aku pernah dihubungi karena seseorang mengubah TTL DNS dan tidak menunggu propagasi. Dalam hal ini, kolam koneksi basis data berada pada 100%. Setiap koneksi sedang digunakan. Tapi mengapa? Lalu lintas tidak melonjak. Pola kuery tidak berubah. Sesuatu menahan koneksi tetap terbuka. Percaya pada pemantauanmu, tetapi verifikasi semuanya. Sistem pemantauan bisa berbohong. Tidak dengan niat jahat—mereka hanya perangkat lunak, dan perangkat lunak memiliki bug. Aku telah melihat sistem pemantauan melaporkan layanan sehat yang sebenarnya sedang down. Aku telah melihat mereka melaporkan kesalahan yang tidak ada. Selalu verifikasi jalur kritis secara manual. Untuk sistem pembayaran, aku siap dengan kartu kredit uji dan perintah curl. Aku dapat memvalidasi seluruh aliran pembayaran dalam 10 detik. Aku menjalankan pembayaran ujianku. Itu terhenti selama 30 detik dan waktu habis. Pemantauan itu tidak berbohong. Kami benar-benar mengalami masalah.

Insiden yang Mengajarkan Saya Segalanya Tentang Koneksi Basis Data

Izinkan aku menceritakan tentang halaman nomor 312. Itu pukul 3:47 AM pada hari Selasa di bulan Maret, dan itu mengubah cara aku berpikir tentang manajemen koneksi basis data selamanya. Kami sedang menjalankan penjualan kilat. Lalu lintas tinggi tetapi tidak tanpa preseden—kami telah menangani lonjakan yang lebih besar. Tiba-tiba, setiap layanan yang bersentuhan dengan basis data mulai mengalami timeout. Kolam koneksi habis. Gejala klasik. Jawaban yang jelas: tingkatkan ukuran kolam koneksi. Jadi kami melakukannya. Kami menggandakannya. Kemudian kami mendirikannya tiga kali lipat. Masalahnya semakin buruk. Saat itulah aku belajar bahwa terkadang solusinya malah memperburuk masalah. Setiap koneksi yang kami tambahkan ke kolam adalah koneksi lain yang mencoba mengeksekusi kuery di basis data yang sudah kelebihan beban. Kami sedang DDoSing diri kami sendiri. Masalah sebenarnya? Seorang pengembang telah menambahkan fitur baru yang melakukan pemindaian tabel lengkap pada tabel dengan 50 juta baris. Tanpa indeks. Kuery membutuhkan waktu 45 detik untuk selesai. Setiap permintaan yang mengenai jalur kode itu menahan koneksi basis data selama 45 detik. Dengan lalu lintas yang cukup banyak, kami menghabiskan kolam koneksi bukan karena kami kekurangan koneksi, tetapi karena setiap koneksi terjebak menunggu kuery yang mengerikan itu selesai. Perbaikannya bukan lebih banyak koneksi. Itu adalah menghentikan kuery itu, menambahkan indeks, dan menerapkan batas waktu kuery di tingkat aplikasi. Insiden itu mengajarkanku tiga hal: Kelelahan kolam koneksi adalah gejala, bukan penyakit. Ketika kau melihatnya, jangan langsung tingkatkan kolamnya. Tanyakan mengapa koneksi tidak dilepaskan. Apakah kuery lambat? Apakah ada deadlock? Apakah sesuatu menahan transaksi tetap berjalan? Kolam koneksi memberitahumu ada masalah di tempat lain. Batas waktu kuery harus ada di mana-mana. Setiap kuery basis data harus memiliki batas waktu. Setiap permintaan HTTP harus memiliki batas waktu. Setiap operasi antrean harus memiliki batas waktu. Batas waktu bukan opsional. Itu adalah perbedaan antara layanan yang menurun dan layanan yang mati total. Ketika sesuatu berjalan salah, batas waktu memungkinkanmu gagal cepat alih-alih mengumpulkan koneksi yang diblokir hingga seluruh sistem runtuh. Pemantauan pemanfaatan kolam koneksi tidak cukup. Kau perlu memantau umur koneksi. Berapa lama rata-rata koneksi ditahan? Apa P99? Jika umur rata-rata koneksimu tiba-tiba melonjak dari 50ms menjadi 5 detik, kau memiliki masalah bahkan jika kolammu belum habis. Itu adalah sistem peringatan awalmu. Kembali ke insiden layanan pembayaran pada pukul 2:17 AM. Aku memeriksa umur koneksi. Rata-rata: 8 detik. P99: