Menemukan Single Point of Failure Sebelum Ia Menemukan Anda

Menemukan Single Point of Failure Sebelum Ia Menemukan Anda

Server down 40 menit. Bisnisnya down 3 hari. Bedanya: router yang gagal ternyata cuma satu, dan tidak ada cadangannya.

Hampir semua outage besar yang saya periksa polanya sama. Bukan servernya yang jadi biang, tapi satu komponen kecil yang tidak pernah digandakan — dan semua yang ada di belakangnya ikut padam berurutan. Menemukan komponen itu sebelum ia gagal bukan soal anggaran. Ini soal pemetaan, dan kebanyakan bisnis belum pernah benar-benar memetakannya.

Apa itu single point of failure sebenarnya

Single point of failure (SPOF) adalah "bagian sistem yang, jika gagal, akan menghentikan seluruh sistem" — dengan implikasi tidak ada cadangan redundan di baliknya. Definisi Wikipedia ini kebetulan persis definisi yang dipakai para engineer. Perhatikan apa yang tidak disebutkan: seberapa mungkin komponen itu gagal.

Peluang kecil cuma berarti kesialan datang lebih jarang. Failure rate tahunan 0,01% tetap SPOF kalau tidak ada apa pun di baliknya.

Engineer menyebut tiga bentuk yang berulang. Bottleneck memperlambat, bukan menghentikan total — satu payment gateway, satu orang yang me-review setiap deployment. Cascading failure adalah saat kegagalan satu komponen menyeret komponen dependen berikutnya, sampai satu fault menjadi outage penuh. Achilles' heel adalah SPOF yang tak pernah dicurigai, tak terlihat sampai ia jadi satu-satunya hal yang menentukan.

Enam tempat SPOF bersembunyi di SME

Kebanyakan bisnis punya keenamnya. Kebanyakan pemilik bisnis paling bisa menyebut dua.

Satu server atau database tanpa failover. Backup malam hari yang tidak pernah di-restore siapa pun, tanpa replica yang siap pakai. Dump yang belum pernah di-restore adalah hipotesis, bukan backup — lihat verifikasi backup Postgres benar-benar bekerja.

Satu jalur jaringan atau router. Satu jalur ISP, satu router yang melayani kantor. Begitu kru konstruksi tak sengaja memutus kabel fiber beberapa blok dari kantor, seluruh operasi ikut offline — sebagus apa pun server di baliknya.

Satu vendor atau ketergantungan SaaS. Payment processing, email transaksional, CRM tempat seluruh proses sales berjalan. Outage vendor atau perubahan API tanpa fallback di sisi sendiri mengubah insiden mereka jadi insiden internal.

Satu orang yang tahu segalanya. Masalah bus factor: satu engineer memegang kredensial deploy atau satu-satunya mental model arsitektur. Bus factor satu adalah SPOF kritis menurut definisinya; tiga sampai empat orang dianggap sehat.

Satu penyetuju proses. Satu orang yang menandatangani purchase order atau refund, tanpa delegasi. Saat ia sedang bepergian, seluruh alur kerja antre di belakangnya — bottleneck manusia berbentuk persis seperti database tanpa replica.

Satu sumber daya listrik. Satu jalur listrik utilitas, UPS yang tidak pernah diuji beban, generator yang tidak pernah dinyalakan sesuai jadwal. Listrik berada di bawah semua SPOF lain di daftar ini: replica tidak menolong kalau semuanya kehilangan daya bersamaan.

Empat outage, satu pola

April 2011, upgrade kapasitas rutin di region US-East AWS salah mengarahkan trafik ke jaringan EBS redundan berkapasitas lebih rendah, bukan router yang dituju. Kesalahan itu memicu cascade menjadi outage multi-hari — post-mortem AWS sendiri menelusuri persis bagaimana caranya.

Oktober 2021, server DNS Meta dikonfigurasi untuk menarik kembali pengumuman rute-nya sendiri setiap kali tidak bisa menjangkau data center Meta. Sebuah perintah maintenance memutus konektivitas backbone, dan DNS menarik dirinya sendiri offline juga, membawa Facebook, Instagram, dan WhatsApp turun sekitar enam jam. Mekanisme keamanannya sendiri adalah dependency yang self-referential — satu-satunya cara ia memberi sinyal "tidak sehat" adalah dengan ikut padam.

Juli 2024, CrowdStrike merilis channel file yang strukturnya tidak cocok dengan yang diharapkan kode sensornya. Kesalahan itu memicu out-of-bounds read yang membuat sekitar 8,5 juta mesin Windows di seluruh dunia crash, menurut estimasi Microsoft sendiri. Laporan root-cause CrowdStrike menunjukkan satu file, dirilis ke semua pelanggan sekaligus, menjadi SPOF untuk satu kategori software secara keseluruhan.

Dan Mei 2017, British Airways kehilangan sistem check-in dan ground selama tiga hari setelah seorang engineer listrik memutus uninterruptible power supply (UPS) di data center. Seperti banyak diberitakan, ribuan penumpang terdampak, dan chairman saat itu, Willie Walsh, menunjuk tindakan pemutusan itu sebagai penyebabnya.

Kesalahan jaringan, desain DNS yang menjatuhkan dirinya sendiri, update software yang cacat, lonjakan listrik. Empat jenis kegagalan, satu pola. Setiap organisasi punya redundansi di atas kertas, dan masing-masing punya satu dependency yang dilewati semua redundansi itu, tak pernah diperiksa sampai hari itu tiba.

Petakan SPOF sendiri dengan dependency walk

Pilih dua atau tiga alur yang bisnis tidak bisa bertahan tanpanya — order intake, pembayaran, konfirmasi pengiriman. Lalu telusuri setiap dependency yang disentuh masing-masing: service, database, queue, DNS, jalur jaringan, API pihak ketiga. Apa pun yang muncul sekali, tanpa apa pun di baliknya, adalah kandidat SPOF, termasuk dependency operasional. Satu deployment pipeline atau satu orang yang bisa menjalankannya adalah SPOF dalam pengertian yang sama seperti database tanpa replica.

Dependency walk itu biasanya memunculkan lima sampai sepuluh SPOF dalam satu sore, kebanyakan tidak pernah tertulis di mana pun.

Mitigasi murah vs. high availability penuh

Tidak semua SPOF butuh solusi yang sama, kira-kira berurutan dari biayanya:

• Gratis atau nyaris gratis: penyetuju cadangan yang terdokumentasi, runbook tertulis, satu orang lagi dengan akses terbatas ke kredensial production.
• Murah, sekali bayar: jalur ISP kedua atau router failover LTE, uji beban bulanan untuk UPS dan generator, status page di provider berbeda.
• Biaya nyata: database replica hangat dengan restore testing beneran, fallback payment processor yang benar-benar diuji, jalur redundan dari dua provider upstream.
• High availability penuh: infrastruktur multi-region active-active, failover otomatis, on-call 24/7 — mahal dan berat secara operasional, tepat untuk sebagian bisnis, salah untuk kebanyakan.

Kapan redundansi tidak sepadan biayanya

Praktik site reliability engineering Google sendiri berargumen bahwa reliability 100% "probably never the right reliability target." Biayanya tidak berskala linear terhadap reliability: "an incremental improvement in reliability may cost 100x more than the previous increment." Keterampilannya bukan menghilangkan setiap SPOF, tapi mencocokkan tingkat mitigasi dengan biaya sebenarnya dari satu jam downtime.

Untuk perusahaan yang omzetnya bergantung pada tiap transaksi, angka itu gampang menembus ratusan ribu dolar per jam. Itu asuransi murah untuk fallback processor dan replica yang teruji.

Untuk bisnis sepuluh orang, satu jam yang sama mungkin cuma berbiaya beberapa ratus dolar kehilangan penjualan. Uang untuk membangun multi-region lebih baik dibelanjakan ke produknya sendiri. Sesuaikan mitigasi dengan biaya sebenarnya dari outage sendiri, bukan dengan apa yang terjadi pada perusahaan seratus kali lebih besar.

Audit mandiri untuk minggu ini

1. Pilih dua atau tiga alur yang bisnis tidak bisa bertahan kehilangannya.
2. Telusuri setiap dependency; tandai apa pun yang muncul sekali tanpa cadangan.
3. Catat berapa biaya per jam tiap SPOF kalau ia gagal hari ini.
4. Perbaiki yang gratis minggu ini: penyetuju cadangan, runbook, kredensial kedua.
5. Hitung harga yang mahal terhadap biaya per jam itu sebelum berkomitmen.

Kebanyakan daftar itu tidak berbiaya apa pun selain satu sore waktu. Bisnis yang celaka bukan yang melewatkan multi-region failover — melainkan yang tidak pernah melakukan dependency walk sama sekali. Kalau perlu sudut pandang kedua soal bagian mana dari peta yang masih berlubang, hubungi saya.