- 12 Haziran 2025'te, Google Cloud ve Google Workspace hizmetlerinde dış API isteklerinde 503 hataları dünya genelinde arttı
- Hatanın nedeni, Service Control sistemindeki bir kod değişikliği ile politika verilerinde boş alan içeren hatalı bir politikanın devreye alınmasıydı
- Temel binary'deki yetersiz hata işleme ve feature flag uygulanmaması gibi etkenler sorunun yayılmasını büyüttü
- Kurtarma 2-3 saat sürdü; us-central-1 bölgesinde ise altyapı aşırı yükü nedeniyle daha uzun toparlanma süresi yaşandı
- Google, mimari ayrıştırma, hata işlemenin iyileştirilmesi ve veri doğrulamanın güçlendirilmesi gibi tekrarını önleme adımlarını açıkladı
Genel kesinti özeti
Google Cloud ve Google Workspace hizmet kesintisi özeti
- 12 Haziran 2025 saat 10:49'dan (PDT) itibaren, Google Cloud, Google Workspace ve Google Security Operations dahil birçok hizmette dış API istekleri için 503 hatalarında ani artış yaşandı
- Google, bunun müşteri hizmetleri ve güven üzerinde ciddi etki yaratmış olmasından dolayı derin özürlerini iletti
- Google API yönetim ve kontrol düzlemi, her isteğin politika ve kota kontrollerinden sorumludur ve temel kontrol sistemi
Service Control adlı bir binary olarak çalışır
Kesintinin neden analizi
Değişen sistem yapısı – Service Control
- 29 Mayıs 2025'te, Service Control'e kota politika kontrollerini güçlendiren yeni bir özellik eklendi
- Bölgelere göre kademeli dağıtım yapıldı, ancak sorunlu kod yalnızca politika gerçekten uygulandığında çalışıyordu; daha önce tetiklenmediği için ön testler yetersiz kaldı
- Bu yeni özellik yolunda uygun hata işleme ve feature flag bulunmadığından, null pointer durumunda binary zincirleme şekilde çöktü
Kesintinin oluşum süreci
- 12 Haziran 2025 saat 10:45'te (PDT), bir politika değişikliği Regional Spanner tablosuna eklendi
- Bu politika verisi, istenmeden eklenmiş bir boş alan (Blank Field) içeriyordu ve bu veri dünya geneline neredeyse gerçek zamanlı olarak çoğaltıldı
- Service Control bu politikayı işlerken null pointer kaynaklı çökme yaşandı ve her bölgedeki instance'lar küresel olarak Crash Loop durumuna girdi
- 2 dakika içinde SRE ekibi durumu fark etmeye başladı; 10 dakika içinde neden tespit edilip binary yolu geçici olarak engellendi (red-button), 40 dakika içinde ise bölgelerin çoğu toparlandı
Ek kurtarma sorunları
- Bazı büyük bölgelerde (us-central-1), Service Control task'leri yeniden başlatılırken herd effect nedeniyle altyapı (Spanner tabloları) aşırı yüklendi
- Service Control, rastgele üstel backoff uygulamadığı için altyapı üzerindeki yük daha da arttı
- Bu bölgede toparlanma 2 saat 40 dakikaya kadar gecikti; trafik yönlendirmesi gibi önlemlerle etki azaltıldı ve genel olarak hizmet kurtarma tamamlandı
Müşteri etkisi ve kesintinin kapsamı
- Müşteriler, API ve kullanıcı arayüzüne erişim sorunları yaşadı; streaming ve IaaS kaynakları etkilenmedi
- Gecikme ve backlog etkileri bazı hizmetlerde 1 saatten uzun süre devam etti
- Kesintiden etkilenen Google Cloud ve Google Workspace ürünlerinin listesi geniş kapsamlı olarak paylaşıldı
- Örnekler: IAM, Cloud Build, Cloud Storage, BigQuery, AppSheet, Gmail, Google Drive ve daha onlarca hizmet
Gelecekteki iyileştirme planları
- Hizmet mimarisi modüler hale getirilecek, böylece işlevler ayrıştırılacak ve kesinti durumunda fail open yaklaşımı devreye alınacak
- Küresel veri çoğaltımı kademeli yayılacak ve gerçek doğrulama süreçleri güçlendirilecek
- Tüm önemli binary değişikliklerinde feature flag ve varsayılan olarak devre dışı bırakma politikası uygulanacak şekilde süreç yenilenecek
- Statik analiz ve testler iyileştirilecek, böylece hata tespiti artacak ve kesinti anında fail open mümkün olacak şekilde tasarım gözden geçirilecek
- Rastgele üstel backoff politikası ile izleme/iletişim güvenilirliği güçlendirilecek
- Kesinti anlarında da müşterilere hızlı izleme ve bilgi aktarımı sağlanabilmesi için altyapı yedekliliği ve otomatik iletişim iyileştirilecek
Kesinti duyurusu ve iletişim
- Olaydan sonraki 1 saat içinde Cloud Service Health üzerinde duyuru yapıldı, ancak izleme altyapısının kendisi de kesintiden etkilendi
- Bazı müşteriler, Google Cloud tabanlı izleme sistemlerinin kendileri düzgün çalışmadığı için kesinti sinyallerini ve etkisini anlamakta zorlandı
- Google, gelecekte izleme ve müşteri iletişimi altyapısını güçlendirme sözü verdi
Temel kesinti zaman çizelgesi (mini rapor özeti)
- Kesinti başlangıcı: 12 Haziran 2025 10:49 (PDT)
- Bölgelerin çoğunda toparlanma: 12 Haziran 2025 12:48 (PDT)
- Kesinti sonu: 12 Haziran 2025 13:49 (PDT)
- Toplam süre: yaklaşık 3 saat
- Etkilenen bölge: dünya genelinde
Sonraki önlem özeti
- API yönetim platformunda veri hatası veya bozulması durumlarına karşı koruyucu mekanizmalar hazırlanacak
- Küresel metadata yayılımı öncesinde doğrulama, test ve izleme güçlendirilecek
- Geçersiz verilere karşı sistem hata işleme ve kapsamlı testler genişletilecek
Etkilenen hizmetler listesi (seçme)
Google Cloud başlıca hizmetleri
- Identity and Access Management, Cloud Build, Google Cloud Storage, Cloud Monitoring, BigQuery, Vertex Gemini API, Cloud Firestore, Looker, Cloud Run, Compute Engine vb.
Google Workspace başlıca hizmetleri
- AppSheet, Gmail, Google Drive, Google Meet, Docs, Chat, Calendar vb.
Sonuç
- Bu kesinti, politika/kota yönetim sistemi yapısı, veri bütünlüğü doğrulamasındaki eksiklikler ve hata işleme mekanizmasının yokluğu gibi etkenlerin birleşimiyle ortaya çıktı
- Google, mimari seviyede iyileştirmeler ve kesinti müdahale kabiliyetinin güçlendirilmesi sözü verdi
2 yorum
Bu, GN+ olmayan sürüm yazısının bağlantısıdır.
Hacker News yorumları
İçeriden biri olarak geçici hesap kullanıyorum; bu olayın temel nedeni, liderliğin hız uğruna ilkeleri görmezden gelmesi. Bu tür pratikler yıllardır sürüyordu ve sonunda sınırına ulaştı. Bu kez yaşanan “query of death”, belirli bir sorgu yüzünden çöken eski C++ sunucularda kaçınılmaz olarak görülen tipik bir hata türü. Service Control C++ ile yazılmıştı ve bu tür hataları en aza indirmek için çeşitli mühendislik yönergelerinden yararlanmaya çalıştı. 10 yıl boyunca büyük bir olay olmadan çalıştı, ancak son dönemde liderlik baskısıyla aceleyle yapılan global kota politikası sorun oldu. Bu tür yeni özellikler ya ayrı bir servis olarak geliştirilmeli ya da en azından mevcut yönergelere uyulmalıydı. Resmî raporda anılan önlemlerden çok daha yüksek standartlar ekip tarafından zaten uygulanıyordu. Ekip de elinden geldiğince mevcut standartları korumaya çalışıyor
Olay raporu bence ilginç. SRE ekibi 2 dakika içinde hızlı yanıt verdi ve “red button” rollout başladı. Sorun, us-central-1 gibi büyük bölgelerde Service Control görevleri yeniden başlarken altyapıda (Spanner tablosunda) aşırı yük oluşturan bir “herd effect” ortaya çıkmasıydı. Service Control içinde rastgele üstel backoff uygulanmadığı için tam toparlanma 2 saat 40 dakikaya kadar gecikti. Bu tür durumlarda normal kotalar hızla doluyor ve yeni arızalara yol açıyor. Altyapı kaldırabiliyorsa kotayı geçici olarak durdurmak veya kurtarma işini yavaşça sınırlamak da iyi olabilir diye düşünüyorum
Bu gerçekten amatörce bir hata gibi görünüyor. NPE, hata işleme yok, üstel backoff yok, test kapsamı yok, staging ortamında test yok, kademeli rollout yok; bunların hepsi ciddi başarısızlıklar. Bunların hepsi zaten SRE kitabında yazıyor: Google SRE Book içindekiler, Building Secure and Reliable Systems TOC. Acaba çıta çok mu düştü, yoksa kitap sadece pazarlama mı diye merak ediyorum
Bence ister insan ister otomasyon olsun, savunma katmanlarında mükemmellik diye bir şey yok; sonuçta her şey ardışık trade-off’lardan ibaret. Ne kadar çok unit test, entegrasyon testi, statik analiz ve aşamalı dağıtım yaparsanız yapın, ölçek büyüyünce beklenmedik boşluklar mutlaka ortaya çıkıyor. Bunun nedeni de kitaptaki “bir tane daha 9 eklemenin çok daha fazla çaba gerektirmesi” ile aynı. En kötü durumda tüm stack’i kopyalayıp aylarca süren tüm trafiği yeniden oynatmanız gerekebilir, ama bu maliyet/fayda düzeyini kimse karşılayamaz. OpenZFS üzerinde çalışırken de kodun kendisi normal görünmesine rağmen 10 yıl önce yazılmış veri edge case’lerinde sorunların ortaya çıktığını gördüm. Sistem yeterince karmaşık hale geldiğinde tüm varyasyonları test etmek imkânsız oluyor; bu yüzden gerçekçi olarak maliyet-etkinlik temelinde karar vermek zorundasınız. Bu arada Google SRE’yim ama bu olayla ilgili olmayan bir ekipteyim; bunlar kişisel görüşlerim
Neredeyse tüm Google global kesintileri buna benzer ilerliyor: hızla globale yayılan özel yapım sistemler hatalı konfigürasyon alıyor. Normal binary rollout’larında veya config push’larda kademeli rollout uygulanması olağan. Google Cloud’da da eskiden pek çok sistem global olarak bağlıydı, ama artık önemli ölçüde bölgeselleşti ve daha güvenilir hale geldi. Eskiden global kesintiler sık olurdu ama duyurulmadığı için çoğu kullanıcı bunu kendi ISP sorunu sanıyordu. Şu an durumun özellikle kötüleştiğini düşünmüyorum. Ek olarak benim de SRE deneyimim var
Dışarıdan bakınca, büyük işten çıkarmalar ve CEO’nun “tembellik” açıklamaları sonrasında herkesin kalite yerine hız ve görünür çıktılara odaklandığı görülüyor. Zamanla bu kültürü sorun edenlerin dışlandığı bir ortama dönüşüyor
Daha fazla ayrıntı açıklanmasını isterdim. Bana göre burada söylenen, test yapılmadığı değil; politikadaki boş alan için, yani sorun çıkaran girdi için test olmadığı. Staging ortamında hiç test yapılmadığı da söylenmiyor; flag olsaydı bunun yakalanacağı söyleniyor. Kişisel görüşüm bu
“En tehlikeli araca bile alışınca insanlar dikkati elden bırakır ve kuralların gereksiz derecede katı olduğunu düşünmeye başlar” diyen 1864 tarihli barut deposu raporunu hatırlattı
Cloud içinde başka bir ekipteyim. Genel olarak tüm kodlarda unit ve entegrasyon testleri var. Binary veya config değişiklikleri iş yüküne ve bölgeye göre günler boyunca kademeli yapılır. Buna canary analizi de eşlik eder. Hatta rollback bile fazla hızlı yapılırsa durumu kötüleştirebildiği için yavaş ilerletilir. Örneğin global veritabanını bir anda aşırı yüklemek yerine 40 dakikalık kesintinin 4 saatlik arızadan daha iyi olduğuna karar verilebilir. Bu olaya doğrudan dahil değildim ama PM’e göre kod test edilmişti, sadece bu edge case atlanmıştı. Sorun, kota politikası ayarının binary ya da config dosyası olarak değil, veritabanı güncellemesiyle uygulanması ve değişikliğin birkaç saniye içinde dünyadaki tüm veritabanlarına yayılmasıydı. Null pointer sorunu başka dillerde de
assert()ile ortaya çıkabilirdi. Böyle çekirdek bir servisi başka bir dile yeniden yazmanın riskinden ziyade, tüm politika kontrollerine flag guard eklemek, kota politikası denetiminde fail open kullanmak ve DB değişikliklerini bölge bölge yavaşça yaymak daha mantıklı görünüyor. Kişisel görüşüm buassert, politika yoluyla yasaklaması çok daha kolay bir yapıKod test edilmiş ama bu edge case atlanmışsa, sonuçta test edilmemiş sayılır diye itiraz ediliyor
DB değişikliği binary ya da config değişikliği değil diye sorun değişmiyor; değişikliğin eşzamanlı biçimde globale yayılması, türü ne olursa olsun felaketin tohumu. Crowdstrike olayındaki akışın aynısı
“Dili değiştirip yeniden yazmanın riskleri çok yüksek” deniyorsa, bu ya servis gereksinimlerinin yeterince anlaşılmadığını ya da servisin dikkatli bir migration gerektirecek kadar kritik olmadığını mı gösteriyor diye merak ediyorum
Uygun hata işleme olmadan binary’nin null pointer yüzünden çöktüğü söyleniyor. Bu noktada “trilyon dolarlık hata” şakası yapılması şaşırtıcı değil
Bu olay yüzünden bir yıl boyunca kaç SLA’in bozulduğunu merak ediyorum
Keşke bu tür sorunu engelleyecek bir dil olsaydı diye düşünmeme neden oldu /s
Service Control (Chemist) epey eski bir servis ve birçok GCP API’sinde kimlik doğrulama, yetkilendirme, izleme, kota gibi çekirdek roller üstleniyor. İstek akışında GCP API’lerinin çoğu Chemist’ten geçiyor, bu yüzden fail open hafifletmesinin etkili olmayacağını düşünüyorum. Hem Chemist hem de proxy C++ ile yazılmış ve yıllar içinde bolca legacy kod birikmiş. Ekiplerin statik analiz, test, kademeli dağıtım, feature flag, red button, güçlü izleme ve alarm sistemleri var; özellikle SRE ekibi çok iyi. Chemist üzerinde IAM, kota ve başka politikalar doğrulandığı için birçok ekip kod tabanına katkıda bulunuyor. Her değişiklikte Chemist onay sürecinden geçmek istemedikleri için kestirme geliştirme yolları artmış. Son dönemde organizasyon değişiklikleri ve offshore artışıyla birlikte L8/L9 seviyesinde gösterişli yeni projelere ağırlık verildi; kalite, bakım ve güvenilirlik ise geri plana düştü. Bu kültürel değişim yüzünden Cloud’dan ayrıldım. Google’ın genel sunucu/servis en iyi uygulamaları burada sık sık uygulanmıyor. Bu olay da daha çok kod ve code review kalitesizliğine benziyor; hatalı kod onaylandı ve konfigürasyon değişikliği Spanner üzerinden anında yansıtılınca sorun büyüdü
Servis politika verisinde istemeden boş bir alan yer aldı ve Service Control, her bölgede kota denetimi sırasında bu boş alanı, yani null değeri okuyunca istisna oluştu. Bu, Hoare’ın “milyar dolarlık hata”sının çeşitli Google sistemlerinde tekrarlandığı bir örnek. Asıl sorun, en başta böyle bir “boş alan”ın (
null) girebilmesine izin verilmiş olması; şemada null yasak (NOT NULL) olarak belirtilmeliydi. Ne yazık ki Spanner’da varsayılan nullable olduğu için bunu ayrıca belirtmek gerekiyor. Uygulama kodu düzeyinde de tip sistemi veya şema diliyle geçersiz durumları imkânsız hale getirmek için bir fırsat daha vardı. Veri deposundan uygulama nesnelerine deserialize ederken şema zorlamalı doğrulama eklemek de mümkündü. Sorun yeni bir kod yolunda ortaya çıktığına göre, veri katmanında filtrelenmeden geçtiği anlaşılıyor. Service Control programının kendisinin null pointer referansına izin veren bir dilde yazılmış olması da ayrıca problem. Eğer ben bu işten sorumlu olsaydım, politikayı uygulama kodundatagged enumtürleri gibi null ifade edemeyen yapılara dönüştüren, en az müdahaleli bir plan düşünürdüm. proto3 bunu kısıtlamıyor ama şöyle bir örnek varMulti-region sık sık dayanıklılık ve erişilebilirlik aracı olarak anılıyor, ama pratikte arıza anlarında büyük bulut sağlayıcılarının bölgeler arasında da sıkı biçimde bağlı olması ilginç
Bu özellikle GCP’de belirgin; GCP bölgeleri rakiplerinden farklı ele alıyor. Dayanıklılık açısından GCP’ye, birden çok zone’un birleştiği tek bir bölge gibi bakmak gerekir
Buna rağmen “bilmediğimiz arızalar” hâlâ olabilir; bu yüzden region/zone sharding’in etkisini fazla küçümsemek doğru olmaz
Multi-region dağıtımların olayı önlediği çok sayıda örnek de vardır; bu yüzden gerçekten hangi vakalarda işe yaradığını görmeden hüküm vermemek gerekir
Google postmortem’lerinin ayrıntı düzeyi beni hep etkiliyor; bunu hem şirket içinde hem dışında hissediyorum. Amaç, aynı hataları tekrar etmemek, protokolleri ve hata işlemeyi güçlendirerek daha dayanıklı sistemlere evrilmek. Google gibi büyük ölçekli yerlerde her zaman bir şeyler ters gider; asıl mesele bunun müşterilere, kullanıcılara ve diğer sistemlere sıçramasını engellemek. İçeride olsanız bile ekipten ekibe görünmeyen pek çok sorun olabilir. Bence bunlar insanların yaptığı en karmaşık sistemler arasında yer alıyor; AGI yoksa insanların bundan daha iyisini yapması zor
Ama bu olayda art arda junior seviyesinde hatalar yaşandı. Null veriyi işleyememek, yetersiz test, yeni özellik için test kapsamının olmaması, tam dağıtımdan önce küçük bir prod ortamında doğrulama yapılmaması; bunların hepsi problem. 10 yıl önceki Google’da böyle hatalarla herkes dalga geçerdi diye düşünüyorum
Benim anladığım kadarıyla bu kesintinin nedeni şunlar: 1) global bir özellik tek seferde her yere dağıtıldı 2) null pointer dereference oldu 3) uygun retry politikası olmadığı için
thundering herdsorunu yaşandı. Bunların hepsi sektörde çalışanların aşina olduğu türden hatalar. İlginç ya da karmaşık dağıtık sistem mantığı değil; tipik “acemi hataları” birleşmiş oldu“Aynı hatayı bir daha tekrarlamayız” deniyor ama gerçekte değişiklik feature flag olmadan rollout edildi, client tarafında üstel backoff yoktu, sunucuda load shedding yoktu. Bunların hepsi yıllardır Google SRE Book’ta yazıyor
Bu hata, fark edilmeyen bir null pointer problemiydi. Google ölçeğinde ve kalite iddiasındaki bir şirketin bu şekilde stack’in büyük bölümünü düşürmesi, ciddi bir tekrar önleme mekanizmasının eksik olduğuna işaret ediyor olabilir
Bu, defalarca tekrarlanmış aynı hata. “Yeni özelliği dikkatle dağıtıyoruz ama ancak yeni veri gelince ortaya çıkan bug” ifadesi çoğu global kesintiyi özetliyor. Kusursuz sistem yok; FAANG kesintileri tartışmalarında gerçekten hatasız olan tek şey HN’in koltuk uzmanları
Çoğu zaman başkasının kesintisine bakınca buna kolayca “junior seviyesi hata” deniyor; ama kendi işimizde aynı şey olunca kaçınılmazdı, öngörülemezdi gibi mazeretler üretiyoruz. İnsan hatası kaçınılmaz ve beklentiler zaten aşırı yüksek. Fiziksel bir dükkân ansızın kapansa en fazla “özür dileriz” denip geçiliyor. Sadece BT sektöründe birkaç saatlik arıza yüzünden aşırı stres yaşanıyor; keşke herkes biraz daha rahat olabilse