Pada tanggal 18 November, Cloudflare mengalami masalah besar — CDN, layanan keamanan, Workers KV, Turnstile, Access, banyak produk semuanya down, mereka sendiri mengatakan ini adalah kegagalan terburuk sejak 2019.
Awalnya tim mengira mereka diserang DDoS, tetapi setelah mencari selama setengah hari, mereka menemukan bahwa masalahnya berasal dari dalam: izin database diubah sedikit, yang menyebabkan file konfigurasi yang dihasilkan memiliki bug, langsung membuat sistem proxy inti mengalami masalah. Akhirnya, mereka mengandalkan pemulihan konfigurasi lama untuk menyelamatkan situasi, dan baru sepenuhnya pulih pada pukul 1:06 pagi waktu Beijing pada tanggal 19.
Laporan tinjauan dari blog resmi ditulis dengan cukup tulus, secara langsung mengakui “tidak dapat diterima”, dan mengatakan akan mempercepat transformasi ketahanan sistem. Bagi kami yang menggunakan layanan mereka untuk menjalankan proyek, tingkat kegagalan infrastruktur seperti ini memang harus diingat dengan baik—sehebat apapun vendor, mereka tetap bisa mengalami kegagalan karena kesalahan operasional internal, jadi penyebaran awan dan rencana darurat harus disiapkan sebelumnya.
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Tinjauan Pemadaman Terburuk dalam Sejarah Cloudflare: Bukan diserang, tetapi kesalahan konfigurasi yang dibuat sendiri.
Pada tanggal 18 November, Cloudflare mengalami masalah besar — CDN, layanan keamanan, Workers KV, Turnstile, Access, banyak produk semuanya down, mereka sendiri mengatakan ini adalah kegagalan terburuk sejak 2019.
Awalnya tim mengira mereka diserang DDoS, tetapi setelah mencari selama setengah hari, mereka menemukan bahwa masalahnya berasal dari dalam: izin database diubah sedikit, yang menyebabkan file konfigurasi yang dihasilkan memiliki bug, langsung membuat sistem proxy inti mengalami masalah. Akhirnya, mereka mengandalkan pemulihan konfigurasi lama untuk menyelamatkan situasi, dan baru sepenuhnya pulih pada pukul 1:06 pagi waktu Beijing pada tanggal 19.
Laporan tinjauan dari blog resmi ditulis dengan cukup tulus, secara langsung mengakui “tidak dapat diterima”, dan mengatakan akan mempercepat transformasi ketahanan sistem. Bagi kami yang menggunakan layanan mereka untuk menjalankan proyek, tingkat kegagalan infrastruktur seperti ini memang harus diingat dengan baik—sehebat apapun vendor, mereka tetap bisa mengalami kegagalan karena kesalahan operasional internal, jadi penyebaran awan dan rencana darurat harus disiapkan sebelumnya.