Pada dini hari tanggal 27 Agustus 2026, Proton mengalami gangguan meluas yang berdampak pada layanan bagi sejumlah pengguna. Akar penyebabnya adalah kegagalan total pada sistem pendingin di pusat data Frankfurt kami. Meskipun semua sistem di Proton bersifat redundan dan kami memiliki kapasitas yang cukup untuk bertahan dari kegagalan pusat data secara menyeluruh, terdapat sejumlah kecil skenario di mana failover dapat memakan waktu lebih lama dan menyebabkan gangguan yang dialami pengguna.

Berikut kronologi tentang apa yang terjadi, keputusan yang kami ambil selama insiden dan alasannya, serta bagaimana masalah tersebut diselesaikan.

Kronologi

Tepat setelah pukul 23.00 (Waktu Eropa Tengah) pada hari Rabu, 26 Agustus, kegagalan sistem pendingin terjadi di ruangan utama pusat data Frankfurt kami. Sekitar pukul 23.15, suhu mulai naik dari sekitar 21,8°C (suhu nominal) menjadi 51,9°C dalam waktu kurang dari setengah jam, dengan beberapa sensor pengukur melaporkan suhu udara mencapai 60°C di ruangan tersebut. Seiring naiknya suhu, peralatan server dan jaringan di dalam fasilitas mulai mati satu per satu.

Insiden yang dialami pengguna dimulai sekitar tengah malam pada 27 Agustus, ketika kegagalan makin meluas hingga hilangnya redundansi kritis. Hal ini terjadi saat sakelar jaringan utama dan cadangan pada rak kritis mengalami kegagalan, dan sayangnya rak tersebut memuat beberapa salinan database utama. Meskipun hampir semua sistem Proton bersifat redundan dan akan melakukan failover secara otomatis/seketika, failover database utama tidak dilakukan secara otomatis tanpa pengawasan manusia.

Kami mempertahankan kontrol ini demi menghindari situasi yang disebut “split brain”, yaitu saat ketidaksediaan sementara database utama menyebabkan salinan replika melewatkan sejumlah pembaruan dan menjadi tidak tersinkronisasi dengan cara yang sulit direkonsiliasi nantinya. Selain itu, ketika failover database utama terjadi, prosedur operasi standarnya adalah melakukan failover ke replika di pusat data yang sama demi alasan latensi dan performa. Namun, sifat spesifik dari masalah ini membuat langkah tersebut berisiko, karena kami berpotensi melakukan failover ke sistem yang juga akan mati.

Keputusan yang diambil

Pada tahap ini, teknisi siaga Proton harus mengambil beberapa keputusan penting di bawah tekanan ekstrem.

  • Apakah mereka memprioritaskan untuk membuat layanan kembali daring, atau memprioritaskan penanganan masalah pendinginan dan menyelamatkan perangkat keras di dalam pusat data?
  • Haruskah kami melakukan failover ke replika di dalam gedung yang sama di Frankfurt (lebih cepat dan minim gangguan, tetapi berpotensi menjadi solusi sementara jika suhu panas tidak dapat dikendalikan), atau melakukan failover ke Zurich?
  • Apakah kami melakukan failover untuk semuanya atau hanya sistem yang sedang mati saat itu? Kami memiliki rencana darurat untuk kegagalan pusat data total di mana seluruh sistem beralih secara penuh dan sebagian besar berjalan otomatis dengan cukup cepat, tetapi situasi di mana server acak mati satu per satu tidak tertangani dengan baik oleh logika failover kami.

Pada akhirnya, laju peningkatan suhu memaksa kami untuk memprioritaskan penyelamatan perangkat keras daripada mengembalikan layanan daring. Ini bukanlah pilihan yang biasanya perlu diambil, karena sistem pendingin umumnya bersifat redundan, dan hilangnya pendinginan total sangat jarang terjadi, sehingga biasanya ada cukup waktu sebelum suhu mencapai tingkat kritis. Masalah ini diperparah oleh lonjakan kepadatan daya server dalam beberapa tahun terakhir dengan CPU dan GPU berdaya lebih tinggi untuk AI. Akibatnya, kondisi kritis yang biasanya baru tercapai dalam 3-4 jam kini terjadi hanya dalam 20 menit.

Oleh karena itu, tim siaga memusatkan perhatian mereka untuk berkomunikasi dengan tim operasi pusat data di lokasi guna memulihkan pendinginan sembari mematikan sebanyak mungkin server demi melindunginya. Mengingat terjadinya kelangkaan peralatan server akibat ledakan tren AI saat ini, banyak dari peralatan ini — jika rusak — tidak akan dapat diganti dalam waktu singkat. Menyelamatkannya harus menjadi prioritas, meskipun berisiko memperpanjang waktu henti layanan.

Menjelang 00.45 CEST, kami berhasil memulihkan pendinginan dan suhu di fasilitas mulai turun, lalu tim siaga mengalihkan fokus ke pemulihan layanan. Pada titik ini, kami memutuskan untuk melakukan failover database utama ke Frankfurt jika replikanya masih aktif, dan ke Zurich jika tidak ada replika yang aktif di Frankfurt, demi mencegah perubahan alur lalu lintas yang berlebihan dan potensi munculnya ketidakstabilan baru. Opsi ini dipilih karena kami berasumsi bahwa dengan pendinginan yang telah terkendali, akan relatif mudah dan lebih cepat untuk membuat Frankfurt kembali daring dibandingkan beralih ke Zurich.

Sayangnya, asumsi tersebut keliru. Selama insiden berlangsung, banyak kartu jaringan di infrastruktur Frankfurt mencapai suhu 105°C (suhu operasi normal adalah 45°C), yang memicu mode perlindungan suhu khusus dan menyebabkan kartu jaringan dinonaktifkan hingga sistem diatur ulang secara dingin (cold reset). Kebijakan keamanan kami membatasi akses ke pengontrol out-of-band pada sistem kami, sehingga kami harus membangunkan staf tambahan untuk membantu proses pemulihan.

Pada pukul 01.30 CEST, sebagian besar layanan sudah berhasil kami buat kembali daring bagi sebagian besar pengguna. Namun, beberapa sistem yang kurang kritis, seperti notifikasi push atau pemrosesan pembayaran, baru pulih sekitar pukul 02.00 CEST.

Sebagaimana kami sampaikan dalam laporan insiden awal, tidak ada email yang hilang, tetapi pengiriman email di kedua arah mengalami keterlambatan selama insiden berlangsung.

Meskipun layanan bagi pengguna telah sepenuhnya dipulihkan, malam itu belum berakhir bagi para teknisi kami, khususnya tim database. Infrastruktur kami berada dalam kondisi yang sangat tidak normal, dengan beberapa database utama berada di Zurich dan lainnya di Frankfurt, serta beberapa di antaranya beroperasi dengan redundansi dan/atau performa yang berkurang. Tim kami bekerja semalaman untuk menyelesaikan masalah yang paling mendesak ini, dan pekerjaan berlanjut sepanjang hari pada 27 Agustus untuk memulihkan redundansi penuh.

Meskipun kami berhasil menyelamatkan hampir seluruh infrastruktur, sayangnya beberapa server mengalami kerusakan fatal akibat panas, dan kami belum mengetahui apakah insiden kenaikan suhu ini akan memengaruhi masa pakai peralatan yang bertahan.

Akar masalah dan langkah selanjutnya

Investigasi lanjutan pada tanggal 27 Agustus mengungkap bahwa akar penyebab kegagalan pendinginan berasal dari penggantian filter udara pada kedua kompresor udara redundan yang menggerakkan sistem pendingin. Sayangnya, operator pusat data melakukan tindakan ini di tengah malam tanpa pemberitahuan sebelumnya, dan juga gagal mengomunikasikan kegagalan pendinginan saat insiden terjadi, yang secara drastis memangkas waktu respons kami. Kami bekerja sama secara erat dengan pihak operator untuk mencegah terulangnya insiden ini.

Namun, keterbatasan pada infrastruktur database kami saat ini juga menjadi faktor yang dapat membuat proses pemulihan dari gangguan semacam ini memakan waktu lebih lama dari biasanya. Rangkaian peristiwa yang memicu insiden ini sangat tidak lazim — namun benar-benar terjadi.

Upaya peningkatan ketahanan database yang diperlukan untuk menangani mode kegagalan ini sudah berjalan dan tetap direncanakan selesai pada akhir tahun. Kapasitas infrastruktur tambahan, termasuk ruang pusat data baru, saat ini juga sedang disiapkan dan diperkirakan mulai beroperasi dalam beberapa minggu ke depan, yang akan makin mengurangi ketergantungan kami pada satu lokasi saja.

Sayangnya, insiden ini terjadi sebelum peningkatan tersebut diterapkan sepenuhnya. Saat ini kami sedang mengevaluasi bagian mana dari pekerjaan yang tersisa yang dapat dipercepat secara aman sembari tetap menjaga tingkat ketelitian tinggi yang diwajibkan untuk perubahan pada infrastruktur database kritis.

Kami menyadari bahwa pengguna mengharapkan tingkat keandalan yang sangat tinggi dari Proton, dan insiden ini mempertegas pentingnya menyelesaikan upaya ini serta terus meningkatkan standar ketahanan kami. Kami memohon maaf sekali lagi, tanpa syarat, kepada setiap pengguna yang terdampak.