10 Hari Kesalahan

10 Days of Errors - from Rollbar and LaunchDarkly

10 Days of Errors dipersembahkan oleh Launchdarkly dan mitra kami di Rollbar . 🦇


Ini akhirnya sepanjang tahun kita semua sangat ditakuti: musim yang menakutkan. Tempat bug melolong mengintai di sudut tergelap kode Anda, dan kisah tentang eksploitasi yang menarik akan mengguncang tim Keamanan yang paling tangguh sekalipun.

Singkirkan kisi-kisi bumbu labu dan kerangka plastik Anda, karena kita di sini untuk membicarakan tentang apa yang membuat Anda merinding dan berkata ” KESALAHAN: utama database disk penuh ”di malam hari. Jangan tanya untuk siapa pager berbunyi bip: itu berbunyi bip untukmu.

Untuk memulai, kami telah mengumpulkan sepuluh kisah mengerikan di blog Rollbar . Tapi itu baru permulaan. Kami memiliki lebih banyak cerita bug yang mengental di sini, dan kami akan menambahkannya ke pos ini hari demi hari. Jika Anda pernah mengalami beberapa kesialan yang mengerikan, beri tahu kami di Twitter: gunakan tagar #ErrorHorrorStory . Menunggu seberapa spektakulernya mereka, kami akan memasukkannya di sini. 👻

Bergabunglah dengan kami saat kami menghabiskan 10 hari berikutnya berbagi cerita mengerikan tentang kesalahan yang bahkan Poe sendiri tidak tahan untuk menulisnya… jika kamu berani .

Hari Pertama: Kesalahan “Melolong di Bulan”

Mari kita mulai dengan kisah lama tapi luar biasa dari Inggris. Awalnya ditulis oleh seseorang yang hanya dikenal sebagai “Taz”, kemudian diteruskan dari daftar ke daftar pada tahun 2002:

Lokasi adalah ruang server, di suatu tempat pada tanggal 4 atau Lantai 5 sebuah kantor di Portsmouth (saya pikir itu) di dekat dermaga. Suatu hari server DB Unix utama jatuh. Itu di-boot ulang tetapi dengan senang hati jatuh lagi dan lagi, jadi mereka memanggil perusahaan dukungan.

Jadi, gadgie pendukung – Mark, saya pikir namanya, bukan itu masalahnya – sampai di sana beberapa jam kemudian. Dari Leeds ke Portsmouth, Anda tahu… perjalanannya masih jauh. Dia mengaktifkan server dan semuanya bekerja tanpa kesalahan. Dukungan berdarah yang khas benar-benar, klien marah karena omong kosong semua. Dia memeriksa file log dan tidak menemukan apa pun yang akan membuat kotak itu jatuh. Mark kemudian kembali ke kereta dan kembali ke Leeds setelah buang-buang waktu.

Malam itu, server jatuh. Cerita yang persis sama… tidak akan muncul kembali. Mark melakukan semua hal dukungan jarak jauh yang biasa tetapi klien tidak dapat menjalankan server.

Pola ini berlanjut selama beberapa hari. Server bekerja, kemudian setelah sekitar sepuluh jam itu jatuh dan tidak akan berjalan selama dua jam lagi. Mereka memeriksa pendinginan, mereka memeriksa kebocoran memori, mereka memeriksa semuanya tetapi tidak berhasil. Kemudian semuanya berhenti.

Lalu, seminggu tanpa masalah. Semua orang senang… sampai dimulai lagi. Pola yang sama: 10 jam aktif, 2-3 jam libur.

Dan kemudian seseorang (sepertinya saya ingat dia mengatakan bahwa orang itu tidak ada hubungannya dengan IT) berkata:

“Ini air pasang!”

Yang disambut dengan tatapan kosong dan mungkin penyerahan interkom yang goyah ke Security.

“Ini berhenti bekerja saat air pasang.”

Tampaknya, ini adalah konsep yang cukup asing bagi staf dukungan TI, yang kemungkinan besar tidak akan ditemukan mempelajari almanak gelombang selama rehat kopi. Jadi mereka menjelaskan bahwa tidak ada hubungannya dengan pasang, karena itu bekerja selama seminggu.

“Minggu lalu adalah Neaps, minggu ini Springs.”

Berikut ini sedikit pembongkaran jargon buat kamu yang belum punya Kualifikasi RYA . Pasang surut berjalan dalam siklus bulan, dan Anda mengalami pasang naik setiap 12,5 jam saat Bumi berputar. Namun seiring dengan perubahan orbit bulan, begitu pula perbedaan pasang naik dan surut. Saat bulan berada di antara kita dan matahari atau di sisi berlawanan dari planet, kita mendapatkan “Mata Air”. Ini adalah tertinggi tertinggi, dan terendah terendah. Saat ada bulan sabit, kita mendapatkan “Neaps”. Perbedaan antara tinggi dan rendah sangat berkurang. Siklus bulan adalah 28 hari, jadi Springs – Neaps – Springs – Neaps.

Benar saja, mereka benar. Dua minggu sebelumnya, sebuah kapal perusak Angkatan Laut atau sesuatu telah berlabuh di dekatnya. Setiap kali air pasang mencapai ketinggian tertentu, sarang gagak itu langsung berbaris dengan lantai tempat server itu duduk. Tampaknya radar (atau gangguan radar, atau apa pun yang dimiliki militer di perahu mainan mereka) sedang mengacaukan komputer.

Ini mungkin terdengar seperti mudah diselesaikan, tetapi tanyakan pada diri Anda: seberapa besar kemungkinan Anda atau rekan Anda untuk membuat koneksi? Pikiran itu membuat orang Inggris di antara kita ingin bersembunyi di bawah selimut dengan secangkir panas Horlicks . Dan kita tidak akan pernah melihat bulan dengan cara yang sama lagi.


Hari Kedua: kesalahan “Your Bug Possessed My Printer”

Kami terbiasa dengan perangkat lunak yang mogok, tetapi ketika bug menyerang kenyataan fisik, itu adalah level menakutkan berikutnya. Bayangkan ini: suatu hari Anda menjadi Pengguna Komputer yang Baik dan memasang pembaruan – seperti yang seharusnya Anda lakukan. Di tengah-tengah itu semua, perangkat yang duduk di sebelah Anda tiba-tiba mulai memuntahkan omong kosong dan tidak berfungsi seolah-olah dimiliki <.>

Versi asli dari cerita ini berasal dari Mark Ferlatte , yang bekerja dengan Yoz Grahame, salah satu penulis posting ini, di Linden Lab – perusahaan yang menjalankan Second Life dunia virtual. Ada cukup banyak cerita bug aneh dari Second Life untuk mengisi sebuah buku, tapi yang satu ini tidak melibatkan avatar, hewan peliharaan digital, atau distorsi virtual lain yang membingungkan. Ini berasal dari hari-hari awal layanan, kembali pada tahun 2003, dan ini adalah tur miniatur melalui sejarah komputasi pribadi yang seluas itu singkat, di mana serangkaian teknologi lama dan baru bekerja sama dengan cara yang benar-benar salah.

Aplikasi desktop Second Life untuk Windows memiliki pembaru bawaan yang bekerja dengan cara sesederhana mungkin: itu akan mengunduh program pembaru dari URL yang telah ditetapkan sebelumnya di situs web Second Life, menyimpannya ke hard drive pengguna sebagai updater.exe , dan jalankan.

Suatu hari, karena alasan kehilangan waktu, permintaan ke URL tersebut mengembalikan 404 Tidak Ditemukan halaman. Mungkin server salah konfigurasi, atau file telah dihapus… siapa tahu? Hal-hal ini terjadi di setiap situs web. Dalam kebanyakan situasi seperti ini, pengguna yang mencoba mengakses halaman itu adalah manusia yang merasa terganggu dan melakukan hal lain, dan itulah akhir cerita. Tetapi ketika pengguna adalah sebuah program, hasilnya kurang dapat diprediksi.

Dalam kasus ini, aplikasi desktop tidak memeriksa apa yang didapatnya. Itu baru saja mengunduh halaman 404, menyimpannya sebagai program updater.exe dan menjalankannya. Atau lebih tepatnya, itu menggunakan panggilan sistem untuk memberi tahu Windows untuk menjalankannya.

Windows melihat updater.exe dan segera melihat bahwa itu tidak ada di format standar untuk . exe file . Tetapi alih-alih berhenti dengan kesalahan, panggilan sistem ini memutuskan untuk berusaha lebih keras. Windows dikenal karena dedikasinya pada dukungan lama: Anda masih dapat menjalankan program dari masa lalu pada MS-DOS, program yang telah akhiran . COM . Sayangnya, panggilan sistem ini tidak memeriksa apa yang didapatnya, dan menjalankan updater.exe seolah-olah itu adalah . COM Program.

Data biner adalah data biner, dan dapat diinterpretasikan dengan cara yang tidak terbatas. Tampaknya – karena alasan yang sepenuhnya tidak disengaja – ketika situs web Second Life 404 halaman diartikan sebagai . COM file, itu dapat dibaca sebagai satu set instruksi untuk membuka LPT dan berteriak omong kosong ke dalamnya. Itulah yang dilakukannya.

Anda yang cukup umur untuk menggunakan MS-DOS mungkin ingat bahwa LPT adalah jalur ke printer. Windows, sekali lagi, bekerja ekstra untuk membantu pekerjaan perangkat lunak DOS lama. Itu menerima omong kosong yang dimuntahkan oleh 404-halaman-run-as-a-program, tidak memeriksa apa yang didapatnya (Anda mungkin merasakan tema di sini), dan dengan senang hati mengirimkannya ke printer apa pun yang diketahuinya.

Untungnya, banyak printer yang periksa apa yang mereka dapatkan! Sayangnya, masih banyak yang tidak, terutama jika itu adalah printer inkjet murah dari tahun 90-an. Dan printer itu menjadi liar . Dalam kata-kata Mark sendiri: “… mereka akan panik, memuntahkan kertas, dan dalam satu kasus, rusak secara fisik .

Ada pelajaran di sini untuk kita semua. Jika Anda menulis perangkat lunak, pastikan perangkat itu memvalidasi datanya sebelum mencoba menggunakannya. (Tidak, sungguh.) Dan ingat cerita ini saat Anda menyaksikan perilaku yang tidak dapat dijelaskan dalam teknologi Anda – siapa yang tahu mantra kuno apa yang mungkin digunakan? 🔮


Hari Ketiga: kesalahan “Seperti Tidak Bergaya”

Etsy adalah tempat magis untuk gaya rumahan. Setiap penjual mungkin hanya memiliki beberapa produk, tetapi dengan lebih dari 3 juta di antaranya , menjual ke 60 juta pembeli, itu adalah lot lalu lintas. Bayangkan betapa bersemangatnya Anda, sebagai insinyur muda, untuk bekerja di situs yang begitu populer! Bayangkan betapa bersemangatnya Anda membuat perubahan yang diterapkan di minggu pertama Anda – meskipun itu hanya perubahan kecil, seperti menghapus beberapa lembar gaya yang berlebihan. Sekarang bayangkan bagaimana perasaan Anda jika perubahan kecil itu membuat seluruh situs jatuh…

Saat itu malam yang gelap dan penuh badai, dan semuanya masih masuk kantor Etsy… kecuali untuk pengembang yang bersemangat mencoba mengirimkan perubahan pada minggu pertama mereka di perusahaan. Mereka menghapus style sheet yang tidak berbahaya dan tidak digunakan – yang awalnya diperlukan untuk mendukung IE6 kuno – dan semua file yang menyertakannya. Diuji pada pementasan, semuanya terlihat bagus! Tes lulus! Saatnya mengirimkannya.

Tapi lihatlah, ada bug! Kondisi perlombaan saat penerapan berarti bahwa beberapa halaman yang diperbarui tidak diterapkan dengan benar, dan versi lama mencoba menyertakan file CSS yang sekarang tidak ada, yang menimbulkan kesalahan. Ini tidak akan terlalu buruk, kecuali halaman kesalahan juga termasuk yang disebutkan di atas, bukan -file CSS yang tidak berbahaya. Jadi kesalahan menghasilkan kesalahan menghasilkan kesalahan, mengakibatkan hard loop pada setiap proses Apache di setiap kotak.

Proses perulangan Apache mengunci server dengan sangat keras sehingga server tidak dapat dimulai ulang dari jarak jauh. Beberapa karyawan Etsy yang malang harus pergi ke pusat data dan mem-boot ulang server secara manual.

Untungnya bagi developer baru, semuanya berjalan lancar. Departemen teknik Etsy memiliki sikap positif untuk belajar dari kesalahan . Mereka bahkan membagikan penghargaan tahunan untuk kesalahan yang paling mengejutkan: sweter tiga lengan, dirajut (tentu saja) oleh penjual Etsy. Saya ingin tahu apakah pengembang malang itu akan memakainya untuk Halloween?


Hari Keempat: kesalahan “Pembayaran Tidak Ditemukan” 🤑

Untuk Throwback Thursday, bug ini datang kepada Anda sekitar 20 tahun yang lalu, diberitahukan oleh seseorang yang tidak ingin disebutkan namanya. Insinyur tertentu ini baru dalam pengkodean, dan tidak memiliki banyak pelatihan formal. “Tes untuk orang bodoh, kode saya terkompilasi, jadi semuanya bekerja” adalah lelucon umum di antara tim teknik ini. Insinyur muda itu mengikutinya, tetapi masih khawatir tentang hal-hal yang mungkin salah, terutama selama pengujian. Sayangnya, saat mereka memikirkan beberapa masalah, mereka lupa mengkhawatirkan orang lain…

Tugasnya adalah mendirikan toko e-commerce yang menjual suku cadang industri untuk lokasi tambang, pikirkan katalog Grainger, tetapi untuk perusahaan sipil. Tim pengembangan berkumpul, membagi tugas dan mulai bekerja membangun. Proyek yang cukup lurus ke depan; katalog barang, otentikasi dan checkout dengan kartu kredit. Tim menyelesaikan proyek tersebut dan merasa cukup baik tentangnya. Mereka mengirimkannya dan bangga bahwa proyek tersebut berjalan sangat lancar.

Maju cepat 18 bulan setelah pengiriman situs web, ketika bug ditemukan.

Pengembang khawatir tentang tagihan sebenarnya yang timbul saat pembayaran kartu kredit sedang diuji. Jadi kode mereka diperiksa jika lingkungan diatur ke dev dalam hal ini, terlepas dari jumlah yang dihitung pada checkout, tidak ada transaksi aktual yang akan dikirim ke prosesor kartu kredit. Ketika proyek dikirim, bendera lingkungan itu tidak pernah diubah menjadi prod , jadi meskipun semuanya terlihat bagus di sisi pelanggan untuk menambahkan barang ke keranjang mereka, memeriksa dan menerima faktur untuk jumlah yang benar, kartu kredit tidak pernah ditagih untuk jumlah tersebut. Sebaliknya, ia secara konsisten menagih pelanggan sejumlah NOL dolar.

Pada saat ini ditemukan, mereka memperkirakan sekitar 2 juta dolar barang yang dikirim dan dijual, tanpa pembayaran yang dikumpulkan.

Untungnya bagi pengembang, situs web perusahaan tersebut terutama menjual ke perusahaan internal lain, jadi uang yang hilang sebagian besar merupakan masalah akuntansi. Namun, Anda dapat yakin bahwa mereka tidak hanya mempelajari nilai pengujian, tetapi juga menguji lingkungan produksi!


Hari Kelima: kesalahan “Matahari Lubang Hitam”

Ini berasal dari Pengacara Pengembang LaunchDarkly lainnya, Dawn Parzych . Dia memakai banyak topi, salah satunya menjadi arsitek solusi. Mari selami untuk melihat beberapa masalah yang kami temui saat bekerja dengan perangkat keras dan perangkat lunak!

10 tahun lalu, saya bekerja untuk F5 Networks sebagai Solusi Arsitek. Perangkat keras kami telah digunakan di ISP untuk meningkatkan kinerja web bagi pengguna seluler. Setiap hari pada waktu yang hampir bersamaan internet berhenti bekerja selama sekitar 5 menit, dan proses sistem dimulai ulang. Saya dikirim ke tempat pada hari itu untuk memecahkan masalah. Seiring berlalunya hari, saya menyadari bahwa perjalanan cepat sehari berubah menjadi semalam. Semua diagnostik dan pemecahan masalah tidak menunjukkan masalah, masalah terjadi pada jam 3 pagi. Saya harus berada di tempat untuk melihat apa yang sedang terjadi.

Sebuah hotel di menit terakhir dipesan, dan saya pergi berbelanja untuk ganti pakaian. Saya tidur beberapa jam sehingga saya bisa on-line pada jam-jam ajaib untuk melihat apa yang salah. Benar saja seperti yang diharapkan, sistem gagal. Dalam 5 menit semuanya berfungsi kembali. Semuanya baik-baik saja dengan perangkat kerasnya. Saya mencari-cari di internet, dipersenjatai dengan stempel waktu kapan kegagalan itu terjadi. Tak satu pun dari pencarian standar menghasilkan solusi.

Akhirnya, saya mendapat pencerahan! Eureka! Dengan beberapa penelitian yang lebih mendalam, saya menyadari masalahnya. Pemadaman tersebut sejalan dengan flare matahari yang dilaporkan di wilayah tersebut. Flare mematikan konektivitas satelit sehingga membuat sistem kami offline. Ketika suar melewati sistem kembali on-line.

Kami memulai 10 Hari Kesalahan dengan gangguan bulan, dan sekarang kami juga mengalami kekacauan matahari. Siapa yang membutuhkan invasi alien ketika benda-benda langit itu sendiri memilikinya untuk kita? Dengan ini kami meminta agar alam semesta sedikit tenang. Sementara itu, kami akan berada di bunker kami. 👽


Hari Keenam: kesalahan “Kasus Buruk Hari Senin”

Teman-teman, kita berhasil melewati lima Hari Kesalahan pertama! Saya harap Anda memiliki akhir pekan yang menyenangkan, dan Anda dapat menjauhkan kerapuhan yang menakutkan dan bug perangkat lunak yang tidak dapat diprediksi dari perhatian Anda cukup lama untuk mencapai sesuatu yang menyerupai relaksasi . Atau mungkin Anda kehilangan hari Minggu karena membantu anak Anda menginstal dua puluh tiga mod Minecraft yang sangat bertentangan, diikuti dengan malam mimpi gelisah yang dipenuhi dengan traceback Java.

Apa pun itu, serahkan: Ini hari Senin lagi, ketika kita kembali ke pertarungan 9-ke-5 yang biasa dengan teknologi perusahaan. Cerita ini dari Adam Kalsey sepertinya pantas untuk dibagikan. Ini ditetapkan satu dekade lalu, saat dia membangun layanan perpesanan instan di seluruh dunia menggunakan standar XMPP. (Jika Anda tidak tahu apa itu XMPP, selamat.)

Seiring pertumbuhan IMified, hampir setiap Senin pagi kami mengalami crash server XMPP inti yang tidak dapat dijelaskan. Kami dapat melihat ada banyak lalu lintas jaringan sekitar jam 9 pagi PST, tetapi itu dienkripsi dan server XMPP komersial tidak memberikan alat untuk menganalisis pada tingkat detail apa pun.

Larutan? Kami membangun server XMPP kami sendiri untuk melengkapi dan menganalisis lalu lintas. Dan kemudian kami melihat sumber lalu lintas. Paket kehadiran.

09:00 PST adalah waktu yang ajaib: pekerja Pantai Barat mendaftar, Pantai Timur pergi untuk makan siang, orang Eropa meninggalkan pekerjaan untuk hari itu, dan akhirnya, waktu tidur di India. Untuk platform perpesanan instan, ini adalah waktu ketika kebanyakan orang mengubah status di seluruh dunia.

Jadi pertanyaannya tetap: kenapa Senin? Kami mendapat banyak paket di hari kerja lainnya, tetapi tersebar dalam jumlah waktu yang lebih lama. Teori kami adalah bahwa orang-orang tampaknya lebih tepat waktu untuk bekerja pada hari Senin. Jadi untuk membantu mengatasi lonjakan lalu lintas ini, kami membuat paket kehadiran garpu server XMPP kami ke server lain yang hanya menyajikan bit statis xml untuk paket XMPP. Voila! Kami online dan tersedia. Selalu.

Oh, apakah dia sudah selesai? Maaf, saya menjadi fugue saat pertama kali menyebutkan zona waktu. (Perasaan akrab bagi siapa saja yang harus men-debug kode kalender.) Gabungkan dengan lonjakan lalu lintas yang terjadi pada hari Senin pagi, dan saya merasakan dosis teror yang mengalahkan tiga espresso. Tidak mungkin saya akan tertidur dalam waktu dekat.

Terima kasih atas ceritanya, Adam. Semoga hari Senin Anda lebih tenang. ☕️


Bergabunglah dengan kami besok untuk ‘kesalahan mengerikan Hari Tujuh!

Ingin belajar bagaimana Anda bisa mulai menangkap kesalahan lebih cepat dan mulai tidur lebih nyenyak di malam hari? Bergabunglah dengan kami dan mitra kami di Rollbar untuk Tes dalam aliran Twitch Produksi pada 12 November. RSVP Di Sini!

Pos ini disusun bersama Ramon Niebla, Teknisi Perangkat Lunak di Rollbar.

Read More

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments