Gangguan Satu Layanan Tidak Seharusnya Menghentikan Seluruh Operasional

Gangguan Satu Layanan Tidak Seharusnya Menghentikan Seluruh Operasional

Bayangkan tim penjualan sebuah perusahaan distribusi tidak dapat menyimpan pesanan pelanggan karena layanan pengiriman notifikasi sedang bermasalah. Data produk masih tersedia, stok dapat diperiksa, dan aplikasi tetap terbuka. Namun, proses transaksi tertahan karena sistem menunggu pemberitahuan berhasil dikirim.

Gangguannya terjadi pada satu layanan pendukung, tetapi dampaknya meluas hingga pekerjaan utama. Tim penjualan akhirnya mencatat pesanan secara manual. Bagian gudang menunggu informasi, sementara pelanggan belum memperoleh kepastian.

Situasi ini menunjukkan mengapa ketahanan sistem perusahaan perlu dipikirkan sejak tahap pengembangan. Aplikasi perlu memiliki aturan yang jelas mengenai apa yang harus dilakukan ketika salah satu layanan tidak tersedia.

Ketergantungan yang Terlihat Praktis Bisa Menjadi Sumber Gangguan

Aplikasi perusahaan biasanya terhubung dengan beberapa sistem. Pencatatan pesanan dapat melibatkan pemeriksaan stok, perhitungan harga, persetujuan kredit, hingga pengiriman notifikasi melalui layanan pihak ketiga.

Hubungan tersebut membantu pekerjaan berjalan otomatis. Namun, jika seluruh tahapan harus selesai secara berurutan sebelum pengguna dapat melanjutkan, satu layanan yang lambat dapat menahan proses lainnya.

Masalahnya semakin besar ketika aplikasi terus mengirim permintaan ke layanan yang sedang terganggu. Pekerjaan menumpuk dan kapasitas pemrosesan ikut terpakai untuk menunggu respons. Pengguna lain kemudian merasakan aplikasi melambat, meskipun mereka menjalankan fungsi yang berbeda.

Ketergantungan semacam ini dapat terbentuk secara bertahap. Awalnya aplikasi hanya menangani transaksi sederhana. Setelah beberapa kali perubahan kebutuhan, muncul integrasi tambahan yang masing-masing dianggap kecil. Tanpa evaluasi menyeluruh, hubungan antarlayanan menjadi semakin rapat.

Persoalan seperti ini juga sering kami temukan ketika mendampingi proses pengembangan, integrasi, maupun modernisasi sistem pada perusahaan.

Tentukan Pekerjaan yang Harus Tetap Berjalan

Perusahaan perlu membedakan proses yang menentukan keabsahan transaksi dengan pekerjaan pendukung yang dapat ditunda.

Dalam contoh pesanan, pemeriksaan harga dan ketersediaan barang mungkin harus dilakukan sebelum transaksi dikonfirmasi. Sebaliknya, pengiriman notifikasi kepada tim internal bisa menyusul setelah pesanan tersimpan.

Pembedaan ini tidak dapat ditentukan oleh developer saja. Tim operasional perlu menjelaskan konsekuensi setiap pilihan. Apakah pesanan boleh diterima ketika stok belum terverifikasi? Berapa lama pemberitahuan boleh tertunda? Siapa yang menangani pekerjaan yang belum selesai?

Jawabannya dapat berbeda antarperusahaan. Distributor dengan persediaan terbatas mungkin perlu menahan konfirmasi pesanan sampai stok dipastikan. Perusahaan lain dapat menerima pengajuan terlebih dahulu, dengan status yang menunjukkan bahwa pesanan masih menunggu pemeriksaan.

Kejelasan aturan bisnis membantu tim IT merancang aplikasi yang tetap berguna saat gangguan terjadi, tanpa mengorbankan ketepatan transaksi.

Batasi Dampak Gangguan melalui Desain Aplikasi

Salah satu pendekatan yang dapat digunakan adalah memisahkan kapasitas untuk kelompok pekerjaan yang berbeda. Dengan demikian, pekerjaan pendukung yang bermasalah tidak menghabiskan seluruh sumber daya untuk transaksi utama.

Contohnya, pemrosesan laporan dalam jumlah besar dapat diberi batas kapasitas agar aktivitas tersebut tidak menghambat pencatatan pesanan. Microsoft membahas prinsip pembatasan ini melalui pola bulkhead, yaitu pemisahan komponen atau sumber daya untuk membantu menahan penyebaran gangguan. 

Aplikasi juga memerlukan batas waktu saat menunggu layanan lain. Jika layanan terus gagal, panggilan dapat dihentikan sementara melalui mekanisme yang dikenal sebagai circuit breaker. Tujuannya memberi kesempatan layanan pulih sekaligus menghindari penumpukan permintaan yang kemungkinan besar kembali gagal.

Untuk pekerjaan yang boleh ditunda, perusahaan dapat menggunakan antrean pemrosesan. Pesanan disimpan terlebih dahulu, sementara pemberitahuan dijadwalkan untuk dikirim setelah layanan tersedia.

Namun, antrean tetap harus dipantau. Pekerjaan tertunda membutuhkan status, penanggung jawab, dan penanganan apabila tidak kunjung berhasil. Tanpa itu, gangguan hanya berpindah menjadi tumpukan pekerjaan yang tidak terlihat.

Fungsi Terbatas Harus Tetap Memberikan Kepastian

Saat terjadi gangguan, aplikasi mungkin masih dapat menyediakan sebagian fungsi. Pengguna dapat melihat pesanan yang sudah tersimpan, tetapi belum dapat memperoleh estimasi pengiriman terbaru.

Kondisi tersebut perlu ditampilkan dengan jelas. Informasi “pesanan tersimpan, pemberitahuan tertunda” lebih membantu daripada pesan kesalahan umum yang membuat pengguna tidak mengetahui apakah transaksi berhasil.

Ketidakjelasan status dapat mendorong pengguna mengulangi tindakan. Akibatnya, tim harus memeriksa kemungkinan pesanan ganda dan mencocokkan catatan secara manual.

Meski demikian, mempertahankan operasional tidak berarti semua proses harus selalu dilanjutkan. Jika informasi penting tidak dapat diverifikasi, aplikasi perlu menahan proses terkait. Ketahanan sistem juga mencakup kemampuan menghentikan pekerjaan secara terkendali ketika melanjutkannya justru berisiko menghasilkan kesalahan.

Apa yang Perlu Dipertimbangkan Perusahaan?

Mulailah dengan memetakan satu proses yang paling penting bagi operasional. Catat aplikasi dan layanan yang terlibat, lalu periksa apa yang terjadi apabila salah satunya tidak memberikan respons.

Dari pemetaan tersebut, perusahaan dapat menilai beberapa hal:

• Dampak bisnis: pekerjaan mana yang berhenti dan siapa yang terdampak?

• Batas penundaan: berapa lama proses pendukung boleh menunggu?

• Kejelasan status: apakah pengguna mengetahui pekerjaan yang berhasil, tertunda, atau gagal?

• Pemulihan: bagaimana pekerjaan dilanjutkan tanpa kehilangan atau menggandakan transaksi?

Asumsi tersebut perlu diuji melalui simulasi gangguan yang terkendali. Pengujian fungsi normal belum cukup untuk menunjukkan perilaku aplikasi ketika layanan eksternal lambat atau tidak tersedia.

Perbaikan dapat dilakukan bertahap pada ketergantungan yang paling berisiko. Perusahaan tidak selalu perlu membangun ulang aplikasi atau beralih ke microservices. Pilihan desain perlu mempertimbangkan manfaat, tambahan biaya, serta kemampuan tim dalam melakukan maintenance.

Kesimpulan

Ketahanan sistem perusahaan bergantung pada kejelasan batas ketergantungan antarlayanan. Perusahaan perlu menentukan proses yang harus tetap berjalan, pekerjaan yang dapat ditunda, dan kondisi yang mengharuskan transaksi dihentikan.

Dengan keputusan tersebut, gangguan dapat ditangani dalam ruang lingkup yang lebih terkendali. Tim memiliki kepastian untuk bekerja, sementara pengembangan aplikasi tetap mengikuti kebutuhan operasional yang sebenarnya.

Diskusikan Ketahanan Sistem Anda bersama Rakit Sembada

Rakit Sembada membantu perusahaan mengevaluasi arsitektur aplikasi dan ketergantungan antarsistem melalui layanan IT Architecture Design, System & API Integration, serta modernisasi aplikasi.