Laporan kebolehpercayaan awan dan SaaS IncidentHub bagi separuh pertama 2026 mengira 30,246 gangguan merentas 1,082 penyedia antara Januari dan Jun, memuncak pada Mei dengan 6,070 insiden; kategori penyedia awan sahaja menyumbang 4,723 gangguan daripada 86 penyedia. Laporan itu merumuskan separuh tahun tersebut dalam satu frasa: risiko kebergantungan — kegagalan yang merebak menuruni satah kawalan, rangkaian edge dan CDN, penyedia identiti serta API AI.

Tiga kes yang wajar diingat

  • Railway, 19 Mei, kira-kira 8 jam: pencetusnya ialah penggantungan akaun automatik di Google Cloud, yang melumpuhkan satah kawalan, API dan pangkalan data Railway sehingga semua beban kerja Railway tidak boleh dicapai — termasuk yang berjalan pada perkakasan Railway sendiri dan pada AWS. Tiada apa-apa rosak dari segi perkakasan; ini ialah penguatkuasaan dasar secara automatik oleh sebuah platform, yang diasingkan oleh laporan itu sebagai kategori risiko baharu.
  • Google Cloud, kebakaran pusat data Delhi/Mumbai: trafik dari rantau India mengalami degradasi selama 21 hari 12 jam. GCP hanya mencatat 2 insiden sepanjang separuh tahun itu — bukti bahawa bilangan insiden yang rendah tidak menggambarkan skala kesannya.
  • Azure, 24 April, satah kawalan East US tergendala lebih 12 jam: melibatkan perebutan kunci dan failover yang tidak lengkap. Apabila satah kawalan gagal, satah data selalunya terus berfungsi, tetapi anda tidak boleh mencipta, menskala atau mengubah apa-apa — tepat operasi yang diperlukan ketika mengendalikan insiden.

Dua angka lain juga wajar disimpan: Cloudflare mencatat 487 insiden dalam tempoh itu (memuncak pada 98 kali pada April), dan storan objek Hetzner mengalami degradasi selama 27 hari 16 jam di nbg1 serta 31 hari 13 jam di hel1. Arah alirannya menunjukkan gangguan pendek semakin kerap — jenis yang tidak pernah menjadi berita tetapi melatih sistem amaran anda menjadi hingar latar.

Asingkan satah kawalan daripada satah data

Kebanyakan orang membayangkan "penyedia tumbang" sebagai laman yang tidak boleh dicapai. Kerosakan sebenar selalunya lebih janggal: laman terus berfungsi, tetapi anda tidak boleh mengubah apa-apa — tiada penskalaan, tiada suntingan firewall, tiada pengeluaran sijil, tiada log masuk konsol. Pelan insiden yang berguna menjawab dua soalan secara berasingan: apa berlaku apabila perkhidmatan tidak tersedia, dan apa berlaku apabila perkhidmatan elok tetapi anda hilang kawalan ke atasnya.

Lukis peta kebergantungan (kurang daripada setengah jam)

Satu baris bagi setiap pihak ketiga, tiga lajur: apa yang rosak jika ia gagal, berapa lama untuk menggantikannya, dan sama ada ada alternatif.

  • DNS: perkara paling penting untuk dijauhkan daripada penyedia CDN anda. DNS yang disimpan di tempat lain itulah yang membolehkan anda melencong daripada CDN yang bermasalah.
  • CDN / proksi songsang: sahkan bahawa pelayan asal anda boleh berfungsi sendiri tanpa CDN — termasuk sijilnya. Banyak pelayan asal hanya menerima sambungan daripada julat keluar CDN, menjadikannya langsung tidak boleh dicapai apabila CDN itulah masalahnya.
  • Pengeluaran sijil: adakah anda menerima amaran apabila pembaharuan ACME gagal? Adakah ada sijil ganti yang dikeluarkan secara manual di mana-mana?
  • Storan objek dan sandaran: sekurang-kurangnya satu salinan mesti berada dengan vendor berbeza, dan pemulihannya mesti pernah dilatih. Multi-AZ dalam satu penyedia tidak melindungi daripada kejadian peringkat akaun.
  • Akaun dan pengebilan itu sendiri: kaedah pembayaran luput, alamat hubungan mati, penandaan risiko automatik — kes Railway menunjukkan itu sahaja cukup untuk menghapuskan segalanya. Sahkan semula kenalan pengebilan, kaedah pembayaran dan status pengesahan akaun mengikut jadual.
  • Akses luar jalur: kunci persendirian SSH, kod pemulihan konsol, laluan masuk sokongan — adakah salinan yang tidak memerlukan log masuk ke platform yang baru sahaja gagal?

Mengapa VPS bebas yang ringkas menjadi lapisan sandaran berguna

Ini bukan hujah bahawa mengehos sendiri lebih boleh dipercayai — satu mesin tiada multi-AZ, dan perkakasan rosak tetap rosak. Tetapi dalam seni bina yang bertindan dengan perkhidmatan terurus, satu instance yang anda kawal sepenuhnya, boleh dimasuki terus melalui SSH, dan mampu menyajikan halaman statik serta perkhidmatan asas dengan sendirinya ialah pautan yang benar-benar berguna dalam rantaian pemulihan: tempat mengehos halaman penyelenggaraan, pelayan asal sementara selepas penukaran DNS, tempat jatuh kedua bagi sandaran. SharkCloud mempunyai nod di Jepun, Singapura, Hong Kong dan Amerika Syarikat — dan meletakkan instance sandaran itu dengan penyedia berbeza di rantau berbeza ialah kotak paling mudah untuk diisi pada peta kebergantungan anda.