27 Ağustos 2026’nın ilk saatlerinde Proton, birçok kullanıcı için hizmetleri etkileyen yaygın bir kesinti yaşadı. Kesintinin temel nedeni, Frankfurt veri merkezimizdeki soğutma sisteminin tamamen arızalanmasıydı. Proton’daki tüm sistemler yedekli olmasına ve veri merkezinin tamamen çökmesine dayanacak yeterli kapasiteye sahip olmamıza rağmen, yük devretmenin daha uzun sürebileceği ve kullanıcıları etkileyen kesintilere yol açabileceği az sayıda senaryo bulunmaktadır.

İşte yaşananların, olay sırasında hangi kararları neden aldığımızın ve sorunun nasıl çözüldüğünün bir zaman çizelgesi.

Zaman çizelgesi

26 Ağustos Çarşamba günü saat 23.00’ten (Orta Avrupa Saati) hemen sonra Frankfurt veri merkezimizin ana odasında bir soğutma sistemi arızası meydana geldi. Saat 23.15 civarında sıcaklık yaklaşık 21,8°C’den (nominal sıcaklık) yarım saatten kısa bir süre içinde 51,9°C’ye yükselmeye başladı ve odadaki bazı ölçüm probları 60°C hava sıcaklığı bildirdi. Sıcaklık arttıkça tesisteki sunucu ve ağ ekipmanları birer birer devre dışı kalmaya başladı.

Kullanıcıları etkileyen olay, 27 Ağustos gece yarısı sularında arızaların kritik yedekliliğin kaybedileceği seviyeye tırmanmasıyla başladı. Bu durum, kritik bir kabindeki hem birincil hem de yedek ağ anahtarının arızalanması sonucu meydana geldi ve maalesef bu kabinde birkaç birincil veritabanı kopyası bulunuyordu. Neredeyse tüm Proton sistemleri yedekli olmasına ve yük devretmeyi otomatik/anında gerçekleştirmesine rağmen, birincil veritabanı yük devretmeleri insan denetimi olmadan otomatik olarak yapılmaz.

Bu kontrolü, birincil veritabanının geçici olarak kullanılamamasının çoğaltma kopyalarının bazı güncellemeleri kaçırmasına ve daha sonra uzlaştırılması zor olabilecek şekilde senkronizasyonun bozulmasına yol açtığı “split brain” (bölünmüş beyin) durumlarından kaçınmak amacıyla elimizde tutuyoruz. Ayrıca, birincil veritabanı yük devretmesi gerçekleştiğinde standart işletim prosedürü, gecikme süresi ve performans nedenleriyle aynı veri merkezindeki bir kopyaya yük devretmektir. Ancak sorunun kendine has niteliği, potansiyel olarak çökecek başka bir sisteme yük devretme ihtimalimiz olduğundan bunun yanlış bir karar olabileceği anlamına geliyordu.

Kararlar

Bu noktada Proton’un nöbetçi mühendislerinin aşırı baskı altında çalışırken birkaç önemli karar alması gerekiyordu.

  • Hizmeti yeniden çevrim içi duruma getirmeye mi öncelik vermeliler, yoksa soğutma sorununu çözmeye ve veri merkezindeki donanımı kurtarmaya mı öncelik vermeliler?
  • Yük devretmeyi Frankfurt’taki aynı bina içindeki kopyalara mı yapmalıyız (daha hızlı ve daha az kesintili, ancak sıcaklık kontrol altına alınamazsa olası geçici bir çözüm) yoksa Zürih’e mi devretmeliyiz?
  • Her şeyi mi yoksa yalnızca o anda çökmüş olanları mı devredelim? Her şeyin tamamen ve çoğunlukla otomatik olarak oldukça hızlı bir şekilde devredildiği tam veri merkezi çökmesi durumları için acil durum planlarımız bulunuyor, ancak rastgele sunucuların birer birer devre dışı kaldığı bir durum yük devretme mantığımız tarafından pek iyi karşılanamıyor.

Sonuç olarak sıcaklıkların artış hızı, bizi hizmetleri yeniden çevrim içi yapmaya kıyasla donanımı kurtarmaya öncelik vermeye zorladı. Bu normalde yapılması gereken bir seçim değildir çünkü soğutma sistemleri genellikle yedeklidir ve soğutmanın tamamen devre dışı kalması oldukça nadirdir; bu da sıcaklıklar kritik seviyeye gelmeden önce epey zaman olduğu anlamına gelir. Bu sorun, son yıllarda yapay zeka için daha yüksek güçlü CPU ve GPU’larla sunucu güç yoğunluğundaki büyük artış nedeniyle daha da kötüleşti. Sonuç olarak, eskiden kritik seviyeye ulaşması 3-4 saat süren durum 20 dakikada kritik seviyeye ulaştı.

Bu nedenle nöbetçi ekip, sunucuları korumak amacıyla mümkün olduğunca çoğunu kapatırken, soğutmayı yeniden sağlamak için yerinde veri merkezi operasyon ekibiyle iletişime geçmeye odaklandı. Devam eden yapay zeka patlamasıyla bağlantılı sunucu ekipmanı kıtlığı nedeniyle, bu ekipmanların birçoğunun kaybolması durumunda kısa süreler içinde yenilenmesi mümkün olmayacaktı. Kesinti süresini uzatma pahasına da olsa bunları kurtarmak bir öncelik olmalıydı.

00:45 CEST itibarıyla soğutmayı yeniden sağlayabildik ve tesisteki sıcaklıklar düşmeye başladı; nöbetçi ekip de odak noktasını hizmet kurtarmaya çevirdi. Bu noktada, trafik akışlarımızı çok fazla değiştirmemek ve olası yeni istikrarsızlıklara yol açmamak için, eğer kopya hâlâ çalışıyorsa birincil veritabanlarını Frankfurt’a, Frankfurt’ta çalışan kopya kalmadığı durumlarda ise Zürih’e devretme kararı aldık. Bu seçenek tercih edildi çünkü artık soğutmayı kontrol altına aldığımız için Frankfurt’u yeniden çevrim içi duruma getirmenin nispeten kolay ve Zürih’e geçmekten daha hızlı olacağını varsaydık.

Ne yazık ki durumun böyle olmadığı anlaşıldı. Olay sırasında Frankfurt altyapısındaki birçok ağ kartı 105°C sıcaklığa ulaştı (normal çalışma sıcaklığı 45°C’dir). Bu durum, özel bir sıcaklık koruma kipini tetikleyerek soğuk sistem sıfırlaması yapılana kadar ağ kartlarının devre dışı bırakılmasına neden olur. Güvenlik duruşumuz sistemlerimizin bant dışı (out-of-band) denetleyicisine erişimi sınırlandırdığından, kurtarma sürecine yardımcı olmak için ek personeli uyandırmamız gerekti.

01:30 CEST itibarıyla birçok kullanıcı için çoğu hizmeti yeniden çevrim içi duruma getirmeyi başardık. Ancak anlık bildirimler veya ödeme işlemleri gibi daha az kritik olan bazı sistemler yaklaşık 02:00 CEST’e kadar kurtarılamadı.

İlk olay raporunda bildirdiğimiz gibi hiçbir e-posta kaybolmadı ancak olay sırasında her iki yöndeki e-posta teslimatlarında gecikmeler yaşandı.

Kullanıcılara yönelik hizmetler tamamen geri yüklenmiş olsa da, özellikle veritabanı ekibi olmak üzere mühendislerimiz için gece henüz bitmemişti. Altyapımız son derece anormal bir durumda kaldı; bazı birincil veritabanları Zürih’te, bazıları ise Frankfurt’taydı ve bunlardan birkaçı azaltılmış yedeklilik ve/veya düşük performansla çalışıyordu. Ekibimiz bu sorunların en acil olanlarını çözmek için gece boyunca çalıştı ve tam yedekliliği yeniden sağlamak için çalışmalar 27 Ağustos günü boyunca devam etti.

Altyapının neredeyse tamamını kurtarabilmiş olsak da ne yazık ki bazı sunucular aşırı sıcaklık nedeniyle kalıcı hasar gördü ve ısınma olayının sağlam kalan ekipmanın kullanım ömrünü etkileyip etkilemeyeceğini henüz bilmiyoruz.

Temel neden ve sonraki adımlar

27 Ağustos’ta yapılan müteakip incelemede, soğutma arızasının temel nedeninin soğutma sistemine güç sağlayan yedekli hava kompresörlerinin her ikisinde yapılan hava filtresi değişimi olduğu tespit edildi. Ne yazık ki veri merkezi işletmecisi bu işlemi gecenin bir yarısı önceden bildirimde bulunmaksızın gerçekleştirdi ve soğutma arızası meydana geldiğinde bunu bildirmeyerek müdahale etmek için sahip olduğumuz süreyi önemli ölçüde kısalttı. Bu olayın tekrarlanmasını önlemek için işletmeciyle yakın bir şekilde çalışıyoruz.

Bununla birlikte, bu tür bir kesintinin normalden daha uzun bir kurtarma sürecine yol açabilmesi mevcut veritabanı altyapımızın bilinen bir kısıtlamasıdır. Bu olaya yol açan olaylar zinciri son derece olasılık dışıydı, yine de gerçekleşti.

Bu arıza kipini ele almak için gereken veritabanı dayanıklılığı çalışması hâlihazırda devam etmekte olup yıl sonuna kadar tamamlanması planlanmaktadır. Yeni veri merkezi alanı da dahil olmak üzere ek altyapı kapasitesi de şu anda devreye alınmaktadır ve önümüzdeki birkaç hafta içinde kullanıma sunulması beklenmektedir; bu da tek bir konuma olan bağımlılığımızı daha da azaltacaktır.

Ne yazık ki bu olay, söz konusu iyileştirmeler tam olarak uygulamaya konulmadan önce gerçekleşti. Şimdi, kritik veritabanı altyapısındaki değişiklikler için gereken özen düzeyini korurken kalan çalışmaları nerede güvenli bir şekilde hızlandırabileceğimizi gözden geçiriyoruz.

Kullanıcılarımızın Proton’dan çok yüksek düzeyde güvenilirlik beklediğinin farkındayız ve bu olay, bu çalışmaları tamamlamanın ve dayanıklılık standartlarımızı yükseltmeye devam etmenin önemini pekiştiriyor. Etkilenen her kullanıcıdan içtenlikle bir kez daha özür dileriz.