6 Kisah Gangguan yang Menakutkan

1. Charity Majors, CTO of Honeycomb

• Push noti tidak terkirim ke pengguna di wilayah tertentu (Eropa Timur)

• Mulai terjadi tepat setelah perubahan ukuran ASG

• Penyebabnya adalah round-robin DNS record melampaui ukuran paket UDP

2. Matthew Fornaciari, CTO of Gremlin

• Gangguan terjadi karena disk penuh sehingga tidak bisa menulis log

• Mengembangkan fitur log rotation

• Menetapkan alert penggunaan disk

• Menambahkan agar bisa diuji melalui Gremlin (chaos engineering)

3. Lirran Haimovitch, CTO of Rookout

"Legenda urban bahwa server selalu mati pada jam tertentu setiap hari,

setelah investigasi selama beberapa minggu, penyebabnya ditemukan di kamera keamanan,

petugas kebersihan memutus koneksi server untuk menyambungkan penyedot debu"

4. Daniel "Spoons" Spoonhower, CTO of Lightstep

• Aplikasi tidak bisa dimuat

• Tidak ada deployment atau perubahan infrastruktur pada hari itu

• Dipastikan hanya pengguna internal yang mengalami masalah

• Saat memeriksa API untuk memuat aplikasi, ditemukan bagian yang mengembalikan data tambahan untuk pengguna internal

• Selama beberapa minggu sebelumnya payload perlahan membesar, lalu sore itu melewati ukuran payload maksimum sehingga aplikasi gagal dimuat

5. Lee liu, CTO of LogDNA

6. Ting Huang, CTO of Transpoit

• Tidak bisa dibaca di Twitter mobile

• Ditemukan masalah bahwa library baru tidak dapat mem-parsing session cookie

[kunggom]

Untuk kasus nomor 5 yang isinya tidak diringkas, tampaknya terkait kedaluwarsa sertifikat.

Mereka mengira tidak akan ada masalah meskipun masa berlaku sertifikat habis sesuai jadwal, tetapi itu hanya berlaku untuk sistem yang baru dikembangkan. Di sistem legacy yang masih digunakan, ternyata muncul masalah. Kebetulan, masalah yang sama juga terjadi pada solusi CI/CD yang mereka gunakan, sehingga situasinya menjadi lebih rumit.

[kbumsik]

"Petugas kebersihan mencabut koneksi server untuk menyambungkan vacuum cleaner"

Ya ampun...

[kunggom]

Setelah membaca artikel aslinya, ternyata bagian itu hanya pembuka; gangguan yang sebenarnya adalah kueri yang kadang dipakai admin dari pihak pelanggan saat rapat mengunci seluruh tabel, sehingga setiap kali itu terjadi latensi layanan backend meningkat tanpa batas. Kueri yang dicurigai memang sudah dioptimalkan, tetapi ternyata salah sasaran, jadi setiap kali pihak pelanggan menganggap halamannya terlalu lambat lalu berulang kali me-refresh, fenomena yang sama terus terjadi.

[kunggom]

Satu pengalaman pribadi yang kurang lebih mirip. Ini terjadi saat saya menangani pekerjaan terkait toko online yang masuk mendadak sebagai freelancer.

Dini hari, kami melakukan pekerjaan besar di toko online itu (upgrade besar-besaran versi solusi), lalu setelah memastikan tidak ada masalah pada fungsi utama seperti pembayaran produk, situs dibuka kembali. Namun, memasuki sore hari, situs web toko online itu tiba-tiba menjadi sangat lambat, hingga nyaris berhenti total. Ternyata penyebabnya adalah halaman khusus penjual yang terpasang terpisah pada toko online tersebut. Mereka mengoperasikan halaman admin khusus penjual yang dikembangkan secara kustom dan ditempelkan ke solusi toko online, dan begitu masuk ke sana, kueri yang sangat berat langsung dijalankan. Setelah toko online dibuka kembali, setiap kali masing-masing penjual mengaksesnya untuk melihat status penjualan, beban pada MySQL meningkat, dan akhirnya toko online itu sendiri ikut melambat. Setelah diperiksa, entah kenapa indeks pada tabel terkait tidak terpasang dengan benar. Pada akhirnya, masalah melambatnya toko online itu sendiri bisa diselesaikan dengan memasang indeks yang benar dan melakukan tuning pada beberapa parameter.

[kbumsik]

Oh, terima kasih sudah berbagi pengalamannya.

Memang, karena materi untuk admin atau pengambilan keputusan bisnis menggunakan aggregation, bebannya jadi cukup besar ya. Saya bukan web developer jadi tidak terlalu paham, tapi belakangan sepertinya hal seperti itu ditangani dengan pendekatan data engineering, yakni mengumpulkan datanya secara terpisah.

[kunggom]

Seperti yang Anda katakan, data seperti itu idealnya dipisahkan dan diproses secara terpisah, tetapi mal tempat saya bekerja adalah sistem legacy dengan cukup banyak hal yang tidak masuk akal, jadi pertimbangan arsitektural seperti itu sama sekali tidak diterapkan. MySQL versi yang sangat tua (versi dari masa ketika engine default-nya bukan InnoDB melainkan MyISAM) berjalan di dalam instance VM yang sama bersama Apache web server versi lama yang juga sudah usang. Solusi untuk mengoperasikan mal tersebut juga sudah dikategorikan sebagai legacy dan hanya menerima patch. Masalah struktural pada solusi yang saya rasakan saat bekerja tampaknya sudah diselesaikan sejak awal di versi baru yang dikembangkan ulang dari nol, tetapi bagi saya yang harus menyentuh versi legacy, hal itu sama sekali tidak memberi pengaruh apa pun. Ternyata itu sudah kejadian tahun lalu.