Pembelajaran : Studi Kasus Gangguan Layanan

Beberapa hari yang lalu menjadi hari yang cukup berat di Excellent. Setelah berjalan lancar sekian lama, tiba-tiba ada gangguan di infrastruktur layanan Excellent SMTP Relay. Layanan ini digunakan oleh klien-klien Excellent Managed Services dan klien yang menggunakan layanan SMTP khusus untuk blast email atau mereka yang sudah punya mail server sendiri. Dengan menggunakan layanan Excellent SMTP Relay, klien bisa menjaga IP public tetap bersih dan disisi lain memiliki proteksi terhadap kemungkinan spamming dari internal ke eksternal.

Masalah yang terjadi adalah delay pengiriman email. Tidak biasanya ada antrian email yang terjadi merata di seluruh front end server, yang awalnya berkisar puluhan namun kemudian meningkat menjadi ratusan. Saya segera meminta team Excellent untuk mengecek masalah yang terjadi. Kemudian meminta lead engineer, Ahmad Imanudin untuk memberikan supervisi team. Saat beberapa server front end mengalami antrian mencapai angka ribuan, saya juga turut langsung mengecek permasalahan yang terjadi.

Jika dilihat dari evidence-nya, masalah terjadi karena lost connection while sending MAIL FROM, yang kemungkinan besar karena masalah bandwidth. Karena server cluster Excellent ada puluhan dan tersebar di berbagai provider cloud dan letak geografis yang berbeda, kemungkinan hal ini bisa terjadi. Kami langsung menghubungi support dari data center masing-masing untuk menanyakan hal ini.

Saat proses pengecekan berlangsung, kami juga menemukan kenyataan bahwa pengiriman email sesama 1 provider juga mengalami kendala. Mengingat saya sudah menyiapkan plan B jika terjadi hal sejenis, saya meminta team melakukan re-routing pengiriman email menggunakan cluster server cadangan.

Masalah solved untuk sementara waktu namun menjelang sore masalah yang sama terjadi lagi. Bahkan cluster server cadangan juga mengalami kendala yang sama. Update informasi dari pihak data center, tidak ada kendala apa-apa. Terkait kemungkinan gangguan network, mereka meminta kami memberikan informasi data Mtr untuk pengecekan koneksi antar server.

Saat malam, gangguan mulai mereda. Ahmad melakukan tune up ke setting network di masing-masing server back end dan menyebar antrian ke berbagai server. Meski kelihatannya krisis sudah reda, saya masih tetap belum puas karena rasanya sumber utama masalah belum ditemukan. Terkait tune up setup network, sebelumnya tanpa tune up juga tidak ada kendala kok.

Pagi keesokan harinya, antrian mulai terjadi lagi. Jadi suspect masalah bahwa krisis mereda karena jam pulang kantor sehingga pengiriman email menjadi berkurang memang benar adanya. Saat pagi jam kerja, antrian mulai terjadi lagi.

Saya mengirimkan sinyal ke seluruh team untuk siaga 1. Selain team billing, accounting dan HR, semua team disiagakan untuk merespon keluhan klien, sementara engineer-engineer senior dibagi tugas masing-masing. Ada yang melakukan pengecekan, ada juga yang menyiapkan cadangan server di provider lain dengan asumsi masalah ada pada provider.

Sumber masalah mulai terkuak setelah menemukan log bahwa koneksi ke port tertentu timed out atau refused. Awalnya dipikir karena kekurangan spesifikasi memory dan vCPU jadi meski agak curious saya memberikan approval terhadap request itu. Namun upgrade vCPU dan memory hanya memberikan sedikit tambahan performa, karena masalah timed out dan refused masih terjadi.

Sebagai ujicoba, team mencoba melakukan disable services yang dirasa terkait dengan masalah tersebut, namun dengan melakukan monitoring ketat karena services yang didisable terkait kemampuan deteksi spam, limitasi pengiriman dan proteksi spam dari klien. Disable services ini berjalan sukses, karena email langsung terbang terkirim ke tujuan dengan cepat.

Saya puas menemukan sumber masalah namun tidak puas dengan penyelesaian disable services. Kalau disable permanen, itu akan mematikan fungsi utama smtp relay, hanya sekedar tukang pos saja. Jadi team engineer tetap dibagi dua, sebagian menangani dan melakukan monitoring layanan yang sedang berjalan sedangkan team senior melakukan investigasi lebih detail sekaligus menyiapkan rencana alternatif.

Setelah diinvestigasi lebih detail baru diketahui masalahnya. Karena ada modul tracking pengiriman email masuk dan keluar sekaligus tracking limitasi pengiriman dan log proteksi list domain, database yang digunakan jadi cepat sekali besarnya. Mengingat server cluster layanan smtp ada puluhan, team engineer sebelumnya melakukan sentralisasi database, sehingga pengubahan di server utama akan otomatis refleksi di server lainnya. Secara desain mekanisme ini cukup baik, namun lupa memperhitungkan skala reliabilitas, sehingga saat database membesar, server-server yang terpisah jadi lama melakukan koneksi yang berimplikasi pada delay proses pengiriman email dari klien.

Solusi temporer adalah melakukan clean up secara berkala untuk table database yang relatif tidak terlalu penting. Proses ini sudah dijalankan setiap hari, namun tidak memadai terbukti dari kasus yang ada, sehingga akhirnya diputuskan untuk clean up database setiap jam sekali. Data yang diclean up tidak masalah dihapus karena memang dibutuhkan hanya beberapa menit setelah terjadi sebagai bagian dari mekanisme limit pengiriman email. Untuk solusi permanen disiapkan mekanisme cluster database, dengan skema master dan slave sehingga beban server database utama tidak terlampau berat.

Setelah solusi temporer dilakukan dan berjalan dengan baik sedangkan solusi permanen sudah dirumuskan, saya menurunkan status siaga 1 menjadi siaga normal. Sebagai ucapan terima kasih untuk kinerja team selama proses siaga 1, ada bonus makan siang seluruh team 🙂

Proses yang dialami selama masalah mulai dilaporkan, dicheck dan dieskalasikan menjadi bagian dari pembelajaran di Excellent, terutama pada staff-staff junior bagaimana menyikapi masalah dan menyelesaikannya. Proses tersebut menjadi salah satu point menarik saat bekerja di Excellent, yang mungkin tidak setiap waktu ditemukan diperusahaan lain 😀