Gangguan Salesforce: Login Macet, Semua Ikut Macet

Gangguan masuk akun pada satu layanan dapat membuat pemesanan dan pekerjaan lain ikut menunggu. Setiap integrasi perlu batas waktu, aturan mencoba ulang, serta cara memberi tahu staf ketika layanan luar gagal. Kasus Salesforce berikut membantu Anda menanyakan kepada vendor: pekerjaan mana yang tetap berjalan, mana yang ditunda, dan bagaimana catatannya dipulihkan.

Pada 16 September 2026, masuk akun, API, dan integrasi Salesforce tersendat sampai 11 jam di ketiga wilayah layanannya sekaligus. Penyebabnya bukan serangan. Permintaan menumpuk di depan layanan masuk akun internal yang melambat, dan tiap permintaan yang menunggu menahan kapasitas server sampai habis. Pelajarannya berlaku untuk sistem apa pun: setiap panggilan yang menunggu wajib punya batas waktu.

Pola kegagalan ini sudah lama dikenal. Kasus Salesforce memperlihatkannya dengan jelas dan membantu pemilik sistem kecil mengenali ketergantungan serupa.

Apa yang terjadi pada 16 September?

Gangguan mulai pukul 00.50 waktu Pasifik, atau 14.50 WIB. Waktu tersebut bertepatan dengan jam kerja siang di Indonesia. Liputan langsung Salesforce Ben mencatat urutan pembaruan status-nya. Dalam satu jam pertama, banyak instance di semua wilayah sudah kena. Instance di sini maksudnya satu klaster server Salesforce yang menampung sekelompok pelanggan.

Mulai ulang bergilir sempat dicoba, lalu ditinggalkan. Perbaikan baru lolos uji di instance percobaan pukul 03.56 waktu Pasifik, sekitar 17.56 WIB.

Perbaikan ditemukan dalam sekitar tiga jam, tetapi penerapannya memerlukan sebagian besar waktu yang tersisa pada hari itu. The Register melaporkan Salesforce memasang perbaikan wilayah demi wilayah dan memulai ulang instance secara manual kalau perbaikan otomatisnya tidak tuntas. Pelanggan diminta membersihkan tembolok atau masuk akun ulang.

CIO.com mencatat status pulih pukul 14.59 waktu Timur AS, kira-kira sebelas jam sejak awal. Di Jakarta, itu hampir jam 2 dini hari tanggal 17.

Cakupannya lebar. Ringkasan untuk admin dari Vantagepoint menyebut ratusan instance di Amerika Utara, Eropa, dan Asia Pasifik, termasuk platform inti di balik Sales Cloud, Service Cloud, Agentforce, dan Data Cloud. Pembuatan tiket dukungan juga gagal.

Semua itu terjadi di hari pembukaan Dreamforce, konferensi tahunan Salesforce sendiri. Lebih dari 40.000 orang hadir di lokasi, lebih dari 200.000 menonton daring. Gangguan berlangsung saat konferensi baru dimulai.

Mengapa layanan masuk akun yang lambat menghambat seluruh sistem?

Bayangkan kantor cabang bank yang tiap transaksinya harus ditelepon dulu ke kantor pusat. Suatu pagi, telepon ke kantor pusat tidak diangkat-angkat. Tidak ada teller yang menutup telepon, karena tidak ada yang pernah bilang harus menunggu berapa lama.

Sepuluh menit kemudian, semua teller memegang gagang telepon. Antrean mengular sampai parkiran. Nasabah yang hanya mau setor tunai ikut tidak terlayani. Tellernya sehat semua. Mereka hanya sibuk menunggu.

Server bekerja dengan cara yang sama. Tiap permintaan yang masuk memakai satu worker, yaitu satu dari sejumlah slot tetap yang bisa diproses server pada saat bersamaan. Kalau permintaan itu memanggil layanan lain tanpa timeout — batas waktu tunggu sebelum menyerah — slotnya terkunci sampai jawaban datang.

Jawabannya tidak pernah datang. Slot terisi satu per satu. Server mulai menolak pekerjaan yang sebenarnya gampang.

Pembaruan status Salesforce menggambarkan persis ini: permintaan macet menunggu jawaban layanan masuk akun internal, sampai kapasitas server habis terpakai. Buku SRE Google menyebut polanya cascading failure, kegagalan berantai: satu bagian yang kewalahan menyeret semua yang bergantung padanya. Kehabisan proses pekerja termasuk bentuknya yang paling tua.

Layanan yang lambat dapat lebih menghambat pemanggilnya daripada layanan yang langsung menolak koneksi. Layanan mati langsung menolak koneksi, pemanggilnya dapat galat dalam hitungan milidetik, dan slotnya kosong lagi. Sebaliknya, layanan lambat menahan kapasitas pemanggil selama menunggu.

Satu catatan lagi untuk proses insiden Anda sendiri. Pembaruan awal Salesforce menyalahkan dependensi eksternal. Belakangan, menurut CIO.com, Salesforce menyatakan tidak ada masalah di infrastruktur pihak ketiga.

Penjelasan awal saat insiden berlangsung masih dapat berubah. Gunakan laporan analisis akar masalah atau RCA yang disusun setelah pemulihan sebelum menjadikan penjelasan tersebut dasar perubahan sistem.

Kenapa komponen lama bisa sepenting itu?

Pembaruan Salesforce sendiri menyebut legacy login server, server masuk akun generasi lama. Detail ini gampang menggiring orang ke kesimpulan yang keliru: "ganti saja semua yang tua."

Abbas Jaffery dari Info-Tech Research Group, dalam liputan CIO.com yang sama, menyodorkan poin yang lebih tajam. Berpindah ke komputasi awan tidak menghapus ketergantungan antarkomponen. Ketergantungannya tetap ada, hanya makin susah dilihat.

Nilai tingkat kepentingan komponen berdasarkan perannya. Komponen yang dilalui semua permintaan tetap kritis, baik berumur sepuluh tahun maupun sepuluh hari.

Sistem kecil punya bentuk yang sama, hanya kotaknya lebih sedikit. Ini yang hampir selalu saya temukan saat mengaudit sistem UKM di sini:

• Cek masuk akun atau SSO di setiap permintaan. SSO (single sign-on) itu satu proses autentikasi yang dipakai untuk mengakses beberapa aplikasi. Kalau tiap buka halaman aplikasi bertanya dulu ke server masuk akun apakah sesi masih sah, server masuk akun ikut berdiri di jalur setiap klik.
• Cek lisensi saat aplikasi dibuka atau di tiap aksi. Server lisensi vendor lambat sejam, seluruh mesin kasir ikut beku.
• Cek status pembayaran tanpa batas. Payment gateway melambat, semua layar kasir tertahan di tulisan "memeriksa pembayaran".
• Kirim pesan di tengah proses. Check-in tamu baru dianggap selesai setelah konfirmasi WhatsApp terkirim.

Semuanya single point of failure, satu titik yang kalau macet membuat semuanya ikut macet. Masalahnya, titik-titik ini tidak kelihatan rawan, karena 99% waktu dependensinya lancar-lancar saja.

Cara memetakannya sama seperti di panduan mencari single point of failure: ikuti satu transaksi nyata dari klik pengguna sampai ke basis data. Catat setiap sistem lain yang disentuhnya di sepanjang jalan.

Di mana sistem Anda sendiri menunggu tanpa batas?

Periksa nilai bawaan pustaka dan basis data. Nilai tersebut belum tentu sesuai dengan kebutuhan waktu tunggu aplikasi Anda.

Pustaka HTTP paling populer di Python menulis terang-terangan di dokumentasinya: permintaan tidak memiliki batas waktu tunggu jika nilainya tidak ditetapkan. Di PostgreSQL, statement_timeout bawaannya nol, artinya batasnya mati, jadi kueri boleh jalan selama apa pun. Kode yang ditulis tanpa memikirkan ini otomatis mewarisi sikap "tunggu selamanya" di panggilan yang paling penting.

Lima pembatas berikut membantu mencegah penantian pada satu layanan menghabiskan kapasitas sistem.

1. Beri setiap panggilan keluar sebuah batas waktu tunggu. Patokannya perilaku dependensi di hari biasa: ambil satu panggilan paling lambat dari tiap seratus, tambahkan sedikit ruang, cukup. Cek masuk akun yang biasanya menjawab dalam 80 milidetik tidak perlu dijatah 30 detik.
2. Beri tenggat untuk satu permintaan pengguna secara utuh. Kalau pengguna sudah menyerah di detik ke-10, tidak boleh ada panggilan di dalam permintaan itu yang masih jalan di detik ke-11. Buku SRE menyebutnya deadline propagation: tiap lapisan meneruskan sisa waktu ke lapisan di bawahnya.
3. Hemat percobaan ulang. Percobaan ulang berarti mencoba lagi setelah gagal, dan jumlahnya berlipat. Tiga lapisan yang masing-masing mencoba tiga kali mengubah satu klik jadi 27 panggilan ke lapisan paling bawah, tepat saat lapisan itu sedang kepayahan. Cukup satu lapisan yang boleh percobaan ulang, maksimal satu-dua kali, dengan backoff dan jitter: jeda tiap percobaan makin panjang, ditambah selisih acak supaya ribuan klien tidak mencoba ulang di detik yang sama.
4. Sekat tiap dependensi. Cek masuk akun, panggilan pembayaran, dan kueri laporan masing-masing dapat jatah proses pekerja atau koneksi sendiri. Engineer menyebutnya bulkhead, dari sekat di lambung kapal: satu ruang bocor, kapalnya tidak ikut tenggelam. Layanan masuk akun yang lambat hanya bisa memenuhi ruangnya sendiri.
5. Pasang pemutus. Circuit breaker bekerja seperti MCB di meteran listrik rumah. Setelah beberapa kali gagal beruntun, ia berhenti memanggil dependensi itu sebentar dan langsung mengembalikan galat, lalu mencoba lagi belakangan. Pemanggil gagal cepat, tidak ikut antre di belakang layanan yang tidak bisa menjawab.

Apa yang tetap bisa jalan saat masuk akun mati?

Pengguna yang sudah memiliki sesi sah dapat tetap bekerja tanpa memeriksa layanan masuk akun pada setiap tindakan.

Ingat gelang di konser. Petugas gerbang mengecek tiket sekali, lalu memasang gelang di pergelangan tangan. Sesudah itu kru di dalam cukup melirik gelangnya. Tidak ada yang menelepon loket tiap kali Anda jalan ke stan minuman.

Di perangkat lunak, gelang itu token sesi yang ditandatangani secara digital, dengan format yang lazim bernama JWT. Server masuk akun menandatanganinya sekali. Layanan lain cukup mencocokkan tanda tangan itu sendiri, pakai kunci publik yang sudah disimpan. Kalau server masuk akun diam, yang sudah masuk tetap bisa kerja. Pendaftaran sesi baru dan pembaruan token masih dapat gagal. Kedaluwarsa token, pencabutan akses, dan rotasi kunci tetap perlu diperhitungkan dalam rancangan keamanan.

Selebihnya, putuskan dari awal apa yang dilakukan sistem kalau satu dependensi hilang:

• Mode baca saja saat tempat penyimpanan data tidak bisa dijangkau. Staf masih bisa mencari booking, data pelanggan, atau harga.
• Tampung dulu, kirim belakangan. Taruh tugas sinkronisasi keluar di antrean yang tetap utuh walau server dimulai ulang. Worker menghabiskannya setelah sisi seberang pulih. Polanya sama dengan yang menjaga webhook supaya tidak membuat uang hilang.
• Cadangan kertas untuk garis depan. Ekspor harian jadwal janji temu, kamar, atau pengiriman hari itu. Meja depan tetap jalan walau CRM-nya hilang.

Kalau perusahaan Anda pakai Salesforce, atau SaaS apa pun, server masuk akun mereka jelas di luar kendali Anda. Sisi integrasinya lain cerita. Middleware yang memanggil API mereka butuh batas waktu tunggu, batas percobaan ulang, dan antrean yang sama.

Tanpa pembatas tersebut, gangguan penyedia dapat menghabiskan kapasitas pemrosesan server Anda. Mekanisme kegagalannya sama, meski skalanya lebih kecil.

Apa yang dicek setelah vendor bilang "sudah pulih"?

Status "pulih" dari vendor menunjukkan layanan kembali menjawab. Anda tetap perlu memeriksa kelengkapan dan konsistensi data sendiri.

Daftar pasca-insiden Vantagepoint untuk admin Salesforce bisa jadi templat untuk sistem pencatat utama mana pun:

• Jalankan ulang integrasi dan impor data yang berjalan selama jendela gangguan.
• Cari data dobel yang tercipta dari percobaan ulang otomatis.
• Cek tugas terjadwal dan alur otomatis yang gagal atau berhenti di tengah jalan.
• Cocokkan jumlah catatan dan waktu ubah terakhir pada data terbaru, secara acak.
• Pastikan email dan tiket dukungan yang dikirim selama gangguan benar-benar sampai.
• Catat jendela gangguan, jam pulih, dan proses apa saja yang kena.

Data ganda dapat berdampak langsung pada operasi. Pesanan yang tercatat dua kali memengaruhi stok, sedangkan penagihan kartu dua kali merugikan pelanggan.

Idempotency key, ID unik yang ditempel ke tiap operasi supaya penerima bisa mengenali kiriman ulang, mencegah dua-duanya. Syaratnya: sudah terpasang sebelum gangguan. Setelah kejadian, alat yang tersisa tinggal rekonsiliasi, yaitu mencocokkan catatan Anda dengan catatan sistem seberang baris demi baris sampai sama.

Terakhir, minta RCA tertulis dari vendor. RCA yang bagus menjelaskan kenapa kegagalannya bisa menyebar, bukan hanya apa pemicunya. Isinya juga harus menyebut apa yang akan menahan penyebaran itu lain kali.

Daftar periksa minggu ini

1. Daftar semua panggilan keluar yang dibuat sistem saat melayani pengguna: masuk akun, pembayaran, lisensi, pesan, AI, API mitra.
2. Untuk tiap panggilan, cari nilai batas waktu tunggunya di kode atau konfigurasi. Periksa arti "bawaan" pada pustaka dan konfigurasi yang benar-benar dipakai.
3. Tetapkan batas waktu tunggu dari latensi normal plus sedikit ruang, dan beri tiap permintaan pengguna tenggat keseluruhan.
4. Izinkan percobaan ulang di satu lapisan saja, dengan batas, backoff, dan jitter.
5. Pastikan pengguna yang sudah masuk akun tetap bisa kerja saat layanan masuk akun mati.
6. Beri tiap dependensi penting jatah proses pekerja atau koneksi sendiri.
7. Tetapkan statement_timeout untuk peran basis data aplikasi.
8. Tulis daftar rekonsiliasi pasca-gangguan sekarang, sebelum butuh.

Yang tetap berlaku setelah beritanya lewat

Kasus ini memperlihatkan mekanisme sederhana dengan dampak luas. Satu layanan melambat, sementara pemanggilnya terus menunggu dan menghabiskan kapasitas.

Saat membandingkan ketersediaan vendor, periksa juga batas waktu tunggu dalam sistem Anda. Batas itu menentukan seberapa jauh gangguan penyedia memengaruhi pekerjaan internal.

Dependensi yang langsung menolak permintaan membebaskan kapasitas lebih cepat. Dependensi yang tidak menjawab terus menahannya. Menetapkan batas waktu pada konfigurasi membantu membatasi perbedaan dampak tersebut.