Anatomi Kehancuran Mental pada Pukul 2 Dini Hari

 (zarar.dev)
1 poin oleh GN⁺ 2024-08-21 | 1 komentar | Bagikan ke WhatsApp
  • Sekitar pukul 10 malam di jumpcomedy.com, semua panggilan HTTP POST RTK Query gagal sehingga fungsi situs rusak, dan karena di lokal berjalan normal, pelacakan penyebabnya menjadi sulit
  • Sementara keluhan pelanggan terus menumpuk, operator harus menangani insiden sendirian tanpa dukungan produksi, SRE, engineer senior, maupun manajer
  • TypeError terkait fetch di browser tidak memberikan petunjuk langsung, apalagi GET dan DELETE tetap berjalan normal
  • Meski sudah memeriksa Sentry, DB produksi, Cloudflare, pembaruan Chrome, dan rollback ke versi lama, tidak ada perubahan; masalah baru bisa direproduksi saat api_key PostHog yang sebelumnya dikosongkan di lokal diisi
  • Setelah PostHog dihapus, fungsi kembali normal, dan kemudian issue GitHub di PostHog serta Redux Toolkit mengonfirmasi gangguan yang sama sehingga terungkap sebagai dampak dari alat eksternal

Tekanan yang Ditimbulkan oleh Insiden

  • jumpcomedy.com mulai sekitar pukul 10 malam mengalami kegagalan total pada panggilan HTTP POST berbasis RTK Query, sehingga fitur-fitur utama tidak berfungsi sebagaimana mestinya
  • Ada perubahan yang baru saja dirilis, tetapi isinya tidak tampak sebagai penyebab, dan masalah tidak bisa direproduksi di lingkungan lokal sehingga penelusurannya makin sulit
  • Bantuan sudah diminta ke Discord NextJS dan Vercel, tetapi tidak ada respons, dan juga tidak ada tim dukungan produksi untuk mengambil alih penanganan insiden
  • Email pelanggan terus berdatangan
    • pertanyaan bahwa harga event tidak bisa diubah
    • pertanyaan bahwa kode promosi tidak bisa dihapus
  • Karena pelanggan bisnis kecil bergantung pada layanan ini, operator merasakan malu, sedih, tidak kompeten, dan impostor syndrome

Proses Debugging dan Konfirmasi Penyebab

  • Error di browser adalah TypeError bahwa fetch dijalankan dengan request object yang sudah pernah digunakan, tetapi itu tidak mampu menunjukkan penyebab sebenarnya
  • Berbagai console.log() dan breakpoint ditambahkan untuk memeriksa header, panjang token API, urutan pemanggilan, dan lain-lain, tetapi tetap tidak mengarah ke penyebab yang jelas
  • Kemungkinan pembaruan Chrome sempat dicurigai, tetapi karena masalah yang sama muncul di Firefox dan Edge, ini bukan masalah browser semata
  • Bahkan setelah dikembalikan ke versi-versi lama, kegagalan tetap berlanjut
    • gagal juga pada versi satu bulan lalu
    • gagal juga pada versi tiga bulan lalu
    • gagal juga pada versi satu tahun lalu
  • Untuk memperkecil perbedaan antara lokal dan produksi, beberapa kandidat diperiksa
    • menghapus Sentry di produksi: tidak ada perubahan
    • menghubungkan lokal ke DB produksi: tidak ada perubahan
    • menonaktifkan Cloudflare: tidak ada perubahan
  • Di lokal, api_key PostHog sengaja dikosongkan untuk menghemat biaya, dan saat nilai itu ditambahkan, masalah yang sama berhasil direproduksi
  • Pada commit berikutnya, PostHog dihapus dan semua fungsi kembali berjalan normal
  • Masalah yang sama kemudian juga dikonfirmasi lewat issue GitHub

Bacaan terkait

1 komentar

 
GN⁺ 2024-08-21
Komentar Hacker News

  • Setelah bekerja selama 1 tahun sebagai SRE di sebuah perusahaan global besar, saya bisa keluar dari mode “panik” yang disebutkan dalam tulisan itu
    Dari sisi bisnis, setiap masalah terlihat seperti peristiwa kiamat, dan mudah panik dalam situasi itu, tetapi kenyataannya jarang seburuk itu; kalaupun buruk, biasanya tetap bisa selamat
    Dalam situasi seperti ini, kuncinya adalah berhenti 5–10 menit sebelum langsung mencoba memperbaiki, lalu gambarkan situasinya sejelas mungkin. Rasa takut mengganggu penilaian rasional, dan jika menekan tombol sembarangan dalam keadaan panik, masalah bisa makin kusut. Trik saya adalah mengguyur wajah dan tangan dengan air yang sangat dingin untuk memutus sirkuit rasa takut
    Setelah mengalami hal seperti ini beberapa kali, Anda akan merasa ternyata tidak apa-apa, dan karena pernah menangani situasi buruk sebelumnya, muncul kepercayaan diri bahwa Anda bisa menghadapinya meski tidak ada orang yang bisa dimintai bantuan

    • Ketika sesuatu “rusak”, perusahaan bisa heboh, tetapi perlu diingat bahwa mereka sama sekali tidak panik terhadap masalah-masalah lain yang sebenarnya mungkin lebih penting
      Misalnya software yang dibeli tidak melakukan apa pun karena kegagalan penempatan staf atau konfigurasi, karyawan kehilangan ribuan jam tiap tahun karena pengalaman pengguna yang buruk dan persyaratan yang tidak bermakna, kapabilitas yang tidak berfungsi apa pun dibiarkan, rapat tidak berguna membuang waktu setiap hari, fitur yang hanya ada demi memenuhi persyaratan audit, atau para eksekutif yang terus membuang-buang uang perusahaan
      Downtime tidak tampak lebih buruk daripada masalah-masalah ini, tetapi menarik jauh lebih banyak perhatian dan kepanikan. Rasanya seperti perbandingan antara terorisme dan penyakit jantung. Perusahaan tidak peduli pada tidur atau kesehatan mental Anda, dan akan mendorong sejauh mungkin. Bukan berarti berniat jahat, tetapi dalam hal ini mereka seperti perundung: semakin Anda mundur, semakin mereka mendorong
    • Kesalahan terburuk yang pernah saya lihat saat insiden nyata biasanya berasal dari respons berlebihan
      Salah satu prinsip pemrograman saya adalah “tidak ada ilmu hitam”. Kalau Anda tidak paham mengapa sesuatu bekerja, berarti belum selesai
      Saya melihat respons insiden dengan cara yang sama. Jika seseorang tidak bisa menjelaskan secara konsisten mengapa usulannya akan berdampak, menurut saya jangan dijalankan. Mungkin suatu hari ada saatnya kita harus langsung menarik pelatuk, tetapi jika melihat ke belakang, rasanya pada akhirnya tidak pernah ada kasus seperti itu
      Cukup mengejutkan melihat eksekutif senior yang biasanya sangat tenang mulai melempar kandidat perbaikan secara acak saat insiden
    • Sebaliknya, orang-orang yang pada pukul 2 pagi, kira-kira ±2 zona waktu, harus mengubah harga event di jumpcomedy.com pasti sangat kecewa. Sebagian dari mereka mungkin bahkan meninggal
      Bayangkan seberapa besar kerugiannya jika ada yang menghentikan developer tunggal ini dengan mengatakan “jangan mencoba memopulerkan fetch”
    • Salah satu VP paling keren yang saya kenal sering berkata, “lambat itu mulus, dan mulus itu cepat”
      Benar bahwa rasa takut mengganggu penilaian rasional, dan saya ingin menambahkan bahwa rasa takut juga sangat menular. Ketika para praktisi melihat pemimpin, manajer, atau rekan kerja panik, mereka juga sering ikut panik. Untungnya VP saya selalu tenang, dan memprioritaskan kejelasan di atas tindakan
    • Pada akhirnya, bukan Anda yang menanggung risiko itu. Itu bukan perusahaan Anda, dan perusahaan bisa—dan memang akan—memutus hubungan dengan Anda kapan saja. Tentu saja pengecualiannya jika itu memang perusahaan Anda sendiri

  • Saya tidak yakin ini keruntuhan mental, dan bisa memberi kesan yang keliru bagi orang-orang yang benar-benar mengalami breakdown akibat stres terkait teknologi
    Dalam kasus saya, itu hanya terjadi sekali, dan itu adalah serangan kecemasan. Saya sangat beruntung karena istri saya ada di samping saya, menjelaskan situasinya dan membantu saya memahami apa yang sedang saya alami. Istri saya sudah mengalaminya berkali-kali, tetapi bagi saya itu yang pertama dan untungnya terakhir
    Hal seperti ini bisa terjadi pada manusia, dan tidak ada yang salah dengan itu. Sangat penting untuk menginternalisasi bahwa itu bukan berarti Anda cacat atau lemah
    Dalam kasus saya, yang akhirnya menghentikannya adalah Xanax, dan karena saya bisa tidur, menurut saya layak untuk menyimpannya dalam jangkauan
    Yang ingin saya katakan adalah ada perbedaan antara pikiran intrusif dan keadaan yang benar-benar tidak bisa dikendalikan serta melumpuhkan fungsi, seperti serangan kecemasan atau serangan panik. Jika hal seperti itu terjadi, Anda tidak bisa bekerja, dan itu tidak apa-apa

    • https://www.webmd.com/mental-health/signs-nervous-breakdown
      Tidak semua breakdown muncul dalam bentuk serangan panik atau kecemasan. Bisa tampak seperti itu, tetapi bukan satu-satunya cara. Stres muncul dengan cara yang sangat berbeda pada tiap orang, bahkan pada tiap pemicu stres
      Karena kita tidak tahu apa yang sebenarnya terjadi di kepala orang itu, hampir mustahil “mendiagnosis” dari luar. Meski bukan serangan panik penuh, kedengarannya ia memang seperti lumpuh secara fungsional selama beberapa jam
    • Pernyataan “sebaiknya menyimpan Xanax dekat-dekat” perlu hati-hati
      Kalau dicari online, tampaknya Xanax bisa bersifat adiktif
      https://www.drugs.com/xanax.html
      Sepertinya bukan jenis obat yang bisa dikonsumsi secara ringan
    • Saya seharusnya tidak perlu sampai minum obat hanya untuk menghadapi fitur yang selalu dirilis asal-asalan, perubahan yang didorong masuk tanpa pikir panjang, dan alarm PagerDuty pukul 3 pagi yang diakibatkannya
      Besar kemungkinan kita akan melihat kelompok besar yang masuk industri teknologi pada pertengahan 2000-an mulai meninggal karena penyakit terkait stres
    • Salah satu hal yang tidak saya duga saat bekerja di perusahaan teknologi enterprise adalah betapa banyaknya rekan kerja yang rutin mengonsumsi Xanax
      Sebagai orang yang seumur hidup mengalami kecemasan berat, gagasan bahwa satu pil adiktif bisa menghilangkan semua itu terasa menakutkan. Rasanya saya akan bergantung padanya seumur hidup
    • Sebenarnya saya kecewa karena ini hanya cerita debugging dependensi biasa. Saya beberapa kali pernah merasa hampir breakdown sebelumnya, jadi saya berharap tulisannya akan lebih relevan

  • Stres orang ini muncul karena satu baris kode PostHog. Commit yang di-revert ada di sini: https://github.com/PostHog/posthog-js/pull/1371/commits/7598...
    Saya melihat dua pelajaran di sini. Pertama, jika Anda men-deploy sesuatu, berarti Anda memilikinya. Jadi makin sedikit Anda men-deploy, makin baik, dan dependensi harus diminimalkan. Kedua, hal yang tidak penting harus ditempatkan di luar jalur kritis. Mesin tidak boleh mati hanya karena kompresor AC rusak. Di browser, ini sangat sulit dicapai, tetapi tetap layak dicoba

  • Lebih buruk lagi, PostHog tampaknya memperbarui sebagian kodenya sendiri secara dinamis saat runtime, dan sepertinya tidak membundelnya saat build
    Di dokumentasinya ada opsi lanjutan untuk menyertakan semua dependensi ke dalam build. Saya paham mengapa mereka melakukannya, dan mungkin saya salah paham, tetapi dari sudut pandang pengguna, saya berharap lazy loading kode yang dieksekusi bukan menjadi default, melainkan opsi optimisasi. Menurut saya itu hanya seharusnya dipakai ketika bundel lengkap menimbulkan keterlambatan pengiriman yang serius

    • Pelajaran-pelajaran ini jelas berharga, tetapi setelah itu seseorang dari sisi marketing akan datang dan menuntut agar PostHog atau skrip pelacakan lain dipasang di situs, dan tidak mau menerima penolakan

  • Sepertinya bug-nya ada di dalam window.fetch yang di-monkey-patch
    https://github.com/PostHog/posthog-js/blob/759829c67fcb8720f...
    Pelajaran terbesar di sini adalah, kalau membuat library populer dan melakukan monkey-patch fungsi global, pengujiannya benar-benar harus sangat baik
    “Untuk berjaga-jaga, mari bungkus pemanggilan PostHog dengan try/catch” dan “Karena PostHog, secara harfiah kita tidak bisa mengirim request POST dengan fetch()” adalah dua hal yang sama sekali berbeda

    • Saya mencoba melihat mengapa ini tidak tertangkap dalam test, dan ternyata pemanggilan fetch biasa saja pun bisa menimbulkan error. Tampaknya cakupan test untuk berbagai cara menggunakan fetch kurang, dan mocking yang berlebihan juga ikut berperan: https://github.com/PostHog/posthog-js/blob/main/src/_tests...
      Karena seluruh fungsi fetch dan XHR di-mock sehingga tidak melakukan apa pun, tentu saja masalah yang muncul saat berinteraksi dengan native di bawahnya atau library lain tidak akan tertangkap. Cypress juga sudah disiapkan, jadi saya tidak tahu mengapa mereka ingin me-mock API browser
    • Terima kasih sudah menunjukkan ini. Saya tidak membaca tulisannya secara detail, tetapi saya penasaran bagaimana library monitoring bisa menjatuhkan seluruh aplikasi
      Kalau integrasinya masuk akal, saya pikir skenario terburuknya hanya pemrosesan event monitoring yang gagal
      Fakta bahwa PostHog mem-patch fungsi global yang sangat penting adalah fitur yang harus didokumentasikan dengan baik. Dengan begitu pengguna mengetahuinya, dan bisa mempertimbangkannya secara wajar saat men-debug masalah yang dari luar tampak sulit dijelaskan
    • Sepertinya berjalan sesuai definisi. Bukankah mereka meng-hog request POST?
    • Ini umum terjadi pada kumpulan alat analitik seperti ini. Saya tidak tahu bagaimana mereka bisa benar-benar menguji semuanya sambil menyentuh API yang sepenting ini
      Misalnya Heap Analytics masih saja, per bulan ini, mengutak-atik sesuatu di internal Hotwire sehingga Hotwire secara acak benar-benar rusak dan semua klik menjadi full page load. Dalam pengalaman saya, ini memengaruhi 30–60% page load. Bisa diperbaiki, tetapi saya harus debugging lebih dari 50 jam sampai bisa membuat Heap dimuat setelah semua JavaScript Hotwire

  • Seperti yang dikatakan orang lain, bug yang menyebabkan stres larut malam ini adalah perubahan satu baris di library PostHog[0]
    Saya melihat ini sebagai pengingat pentingnya memberi nama variabel secara tepat
    Kode res = await originalFetch(url, init) terlihat cukup tidak berbahaya. Tetapi seperti yang ditunjukkan deklarasi TypeScript, parameter url tidak selalu URL: url: URL | RequestInfo
    Masalah muncul ketika itu bukan URL, melainkan objek RequestInfo. Di bagian awal implementasi fungsi, objek Request dibuat dan sudah “dikonsumsi”, sehingga tidak bisa digunakan lagi di sini
    Kalau nama parameternya lebih tepat, seperti urlOrRequestInfo, akan lebih sulit melewatkan masalah dalam perubahan ini
    Ini jauh lebih spekulatif, tetapi karena linear type yang berasal dari linear logic dapat memformalkan bahwa sebuah nilai telah “dikonsumsi”, mungkin sistem tipe yang sesuai juga bisa mencegah bug semacam ini
    [0] https://github.com/PostHog/posthog-js/pull/1351/commits/2497...

    • Masalah pada sistem tipe linear/affine adalah hambatan masuknya sangat tinggi
      Cukup lihat saja semantik ownership di bahasa seperti Rust. Bukan berarti tidak bisa ditembus, dan terutama akan membaik seiring pengalaman, tetapi bebannya besar sampai-sampai itu menjadi salah satu hal yang paling sering dikeluhkan pembelajar

  • Tulisannya menegangkan tetapi juga lucu. Namun bagian menyalahkan diri sendiri terasa terlalu familier
    Saya mengelola aplikasi iOS/macOS yang cukup sukses, dan pernah mendorong rilis yang benar-benar merusak lebih dari 350 ribu instalasi. Tidak sepenuhnya salah saya, tetapi karena itu produk saya, rasanya tidak banyak bedanya
    Keringat dingin dan rasa malu saat itu benar-benar parah. Ditambah lagi karena App Store, versi perbaikan juga harus melewati proses review sehingga waktunya bertambah. Untungnya 30 menit setelah dikirim masuk review dan disetujui dalam beberapa menit

    • Pekerjaan pertama saya sebagai developer “mengizinkan” saya merusak milik pelanggan di usia muda, bukan karena saya pintar, melainkan karena saya tidak kompeten
      Seiring membangun karier dan beralih ke leadership, saya sadar itu pengalaman yang sangat berharga. Dulu mungkin saya stres, tetapi sekarang ingatan itu sudah begitu jauh sampai tidak lagi menyentuh saya. Sekarang jelas saya tidak stres karenanya
      Ini mungkin kontroversial, tetapi saya kadang membiarkan anggota tim di awal karier mereka merusak production. Maksudnya ketika tanda-tandanya sudah terlihat sebelumnya, dan kami yakin bisa memulihkan dengan cepat
      Memberi ruang untuk gagal memang akal sehat, tetapi banyak pemimpin menarik garis pada kegagalan yang berdampak pada pelanggan nyata. Dalam situasi yang sangat umum dan beruntung, yaitu ketika kita tidak sedang membuat sesuatu sepenting software untuk mendaratkan pesawat, tim harus mengalami insiden operasional meski harga yang dibayar adalah seseorang di Spokane, Washington, tidak bisa memakai produk selama beberapa menit

  • Terima kasih sudah menulis ini. Saya terutama suka membaca bagaimana orang melewati tantangan seperti ini di bawah tekanan, biasanya semalaman
    Rasanya lebih baik karena kita tidak hanya mendapat postmortem teknis, tetapi juga sudut pandang manusiawi yang biasanya dihapus dari cerita seperti ini. Narasi teknis seperti ini adalah jenis yang mungkin hanya bisa dibagikan secara bebas oleh developer kecil/solo atau founder

  • Dari cara ia melacak masalahnya saja sudah terlihat bahwa ia pertama-tama adalah programmer. Ia menelusuri ke kodenya sendiri, lalu ke log. Keduanya masuk akal dan keduanya bisa menjadi penyebab, tetapi ia melewatkan petunjuk terpenting yang dimilikinya: “di localhost jalan”
    Sebagai SRE, DevOps, platform engineer, atau apa pun jabatan yang melekat hari itu, saya akan berfokus pada perbedaan antara sistem yang berjalan dan sistem yang tidak berjalan. Saya akan menambahkan lalu menghapus perbedaan itu satu per satu, atau menghapus lalu menambahkannya kembali, sampai sesuatu berjalan
    Yang saya lihat ada dua hal. 1) Ada lingkungan yang berjalan. 2) Lingkungan yang gagal pun awalnya berjalan, lalu mulai gagal
    Ini bukan berarti metode saya lebih unggul. Saya hanya ingin menunjukkan perbedaan cara memandang masalah. Keduanya mempersempit masalah berdasarkan hal yang diketahui. Saya memahami sistem, Anda memahami kode

    • Dulu, saat bekerja sebagai teknisi elektronik, ada tumpukan board prosesor Perkin Elmer 7/32 yang sudah dilepas dari layanan. Itu board yang rusak, revisinya bermacam-macam, dan untuk tiap board hanya ada skema rangkaian untuk satu revisi
      Saya pikir itu tidak ada harapan, tetapi seorang teknisi yang lebih tua dan lebih bijak mengajari saya caranya
      Pasang board yang bagus ke extender, lalu jalankan program diagnostik yang gagal dalam loop. Dengan osiloskop, lihat dan catat semua pin pada konektor. Ganti dengan board yang buruk, lalu ulangi
      Sinyal mana yang berbeda? Telusuri balik sinyal itu. Jika skema tidak cocok, buat skema yang mencerminkan wiring sebenarnya dengan voltmeter dan mata
      Ia menyebut ini “kartu bagus - kartu buruk”, dan itu benar-benar berhasil. Saya tidak akan mengklaim bahwa ini hemat biaya, tetapi semua board berhasil diperbaiki, dan kemampuan troubleshooting rangkaian elektronik digital saya meningkat pesat
      Ini semacam pekerjaan “pemadam kebakaran”. Karena tugasnya menunggu sistem rusak, tidak masalah jika 2 teknisi menghabiskan 1 minggu untuk satu circuit board

  • “Coba kembalikan ke versi sebulan lalu. Tidak bisa. Tiga bulan lalu? Tidak bisa. Masih gagal. Satu tahun lalu? Sama sekali tidak bisa.”
    Apakah ia hanya mengembalikan kodenya sendiri, sementara tetap memakai pembaruan PostHog yang rusak pada hari yang sama? Pelajaran saya adalah kita harus bisa mengembalikan semuanya, termasuk dependensi

  • Tulisan yang bagus karena mengingatkan kita kembali pada orang-orang di balik layanan, dan juga memperlihatkan proses debugging dengan baik
    Secara realistis, tekanan tidak membuat kita men-debug masalah lebih cepat. Biasanya justru mengganggu proses berpikir. Kita harus sebisa mungkin mengabaikan konsekuensinya dan tetap setenang mungkin
    Sebagian besar dari kita mungkin pernah mengalami situasi serupa, meski tingkatnya berbeda-beda. Tentu saja, stres menjalankan perusahaan sendiri pasti terasa sangat berat