Kesinti raporu: 19 Mayıs 2026 – GCP hesap askıya alınması
(blog.railway.com)- Railway platformunda genel bir kesinti, 19 Mayıs 2026 22:20 UTC’den itibaren yaklaşık 8 saat sürdü ve doğrudan neden Google Cloud’un üretim hesabını askıya almasıydı
- Dashboard ve API anında 503 hatası döndürdü; Google Cloud üzerinde barındırılan compute, veritabanı, kontrol düzlemi ve burst-compute altyapısı çevrimdışı oldu
- Railway Metal ve AWS iş yükleri çalışmayı sürdürdü, ancak edge proxy Google Cloud’daki kontrol düzlemi API’sine bağımlı olduğundan rota önbelleği süresi dolunca 404 hataları yayılmaya başladı
- Hesap erişimi geri geldikten sonra bile kalıcı diskler, compute instance’ları ve ağ ayrı ayrı kurtarılmak zorunda kaldı; GitHub OAuth ve webhook rate limiting de girişleri ve build’leri ek olarak engelledi
- Railway, tek bir üst sağlayıcının eyleminin tam platform kesintisine dönüşmesine yol açan mimari kararların sorumluluğunu kabul etti ve Google Cloud’u veri düzleminin hot path’inden çıkaracak bir yeniden tasarım üzerinde çalışıyor
Etki
- 19 Mayıs 2026 22:20 UTC’den 20 Mayıs yaklaşık 06:14 UTC’ye kadar, yaklaşık 8 saat boyunca Railway’de platform genelinde kesinti yaşandı
- Google Cloud, Railway’nin üretim hesabı hizmetini askıya alınca API, kontrol düzlemi, veritabanları ve Google Cloud üzerinde barındırılan compute altyapısı çevrimdışı oldu
- Kullanıcılar dashboard ve API’de anında 503 hataları gördü ve
"no healthy upstream"ile"unconditional drop overload"mesajlarıyla giriş yapamaz hale geldi - Google Cloud compute üzerinde barındırılan tüm iş yükleri çevrimdışı oldu
- Railway Metal ve AWS burst-cloud ortamındaki iş yükleri çalışmaya devam etti, ancak Railway’nin edge proxy sistemi rota tablolarını doldurmak için Google Cloud’da barındırılan kontrol düzlemi API’sine bağımlıydı
- Önbelleğe alınmış ağ rotalarının süresi dolunca Google Cloud dışındaki iş yüklerine de ulaşılamaz hale gelindi ve ağ kontrol düzlemi etkin instance’ların rotalarını çözemediği için 404 hataları döndürmeye başladı
- Etkinin en yüksek olduğu anda tüm bölgelerdeki Railway iş yüklerine ulaşılamaz durumdaydı
- Google Cloud ortamı kurtarılırken, tek tek servisler geri getirilene kadar platform genelinde build ve deployment işlemleri engellendi
- Tüm altyapı geri geldikten sonra, beklemede biriken deployment işleri platformu aşırı yüklememek için kademeli olarak işlendi
- Aynı anda GitHub da Railway’nin OAuth ve webhook entegrasyonlarına rate limiting uygulayarak girişleri ve build’leri geçici olarak engelledi
- Çağrı hacmindeki artış, Google Cloud kesintisi nedeniyle önbelleklerin boşalmasının sonucuydu
- Hizmet şartları onay kayıtları da sıfırlandı; bu nedenle kullanıcıların dashboard’u bir sonraki ziyaretlerinde yeniden onay vermesi gerekti
- Railway, tek bir üst sağlayıcının eyleminin platform genelinde kesintiye dönüşmesini mümkün kılan mimari kararların sorumluluğunu kabul etti
Kesinti zaman çizelgesi
- 19 Mayıs 22:10 UTC: Otomatik izleme, API health check başarısızlığını tespit etti ve nöbetçi ekibi uyardı
- 19 Mayıs 22:11 UTC: Dashboard 503 hatası döndürmeye başladı ve kullanıcılar giriş yapamaz hale geldi
- 19 Mayıs 22:19 UTC: Google Cloud Platform’un Railway’nin üretim hesabını askıya aldığı, kök neden olarak doğrulandı
- 19 Mayıs 22:22 UTC: Google Cloud’a P0 ticket açıldı ve Railway’nin GCP hesap yöneticisi doğrudan devreye girdi
- 19 Mayıs 22:29 UTC: Kesinti ilan edildi
- 19 Mayıs 22:29 UTC: GCP hesap erişimi geri geldi ancak tüm compute instance’ları hâlâ durdurulmuş durumdaydı ve kalıcı disklere erişilemiyordu
- 19 Mayıs 22:35 UTC: Önbelleğe alınmış ağ rotalarının süresi dolmaya başlayınca Railway Metal ve AWS iş yükleri 404 hataları döndürmeye başladı
- 19 Mayıs 23:09 UTC: İlk kalıcı disk yeniden çevrimiçi oldu
- 19 Mayıs 23:54 UTC: Tüm kalıcı diskler ready durumuna geri döndü ancak ağ hâlâ çalışmıyordu
- 20 Mayıs 00:39 UTC: Disklerin ready durumda olduğu doğrulandı, ancak kurtarma Google Cloud ağının geri gelmesine takıldı
- 20 Mayıs 01:30 UTC: Compute instance’ları geri gelmeye başladı
- 20 Mayıs 01:38 UTC: Edge trafiği yeniden sunulmaya başladı ve ağ toparlandı
- 20 Mayıs 01:57 UTC: Orkestrasyon ve build altyapısı geri geldi; bekleyen işler aynı anda çalışıp sistemi zorlamasın diye deployment geçici olarak durduruldu
- 20 Mayıs 02:04 UTC: Compute host’ları kademeli olarak yeniden çevrimiçi oldu
- 20 Mayıs 02:47 UTC: GitHub, Railway’nin OAuth ve webhook entegrasyonlarına rate limiting uygulamaya başladı; bazı kullanıcılar giriş yapamadı ve build’ler engellendi
- 20 Mayıs 02:55 UTC: Dashboard’a yeniden erişilebilir hale gelindi
- 20 Mayıs 03:59 UTC: Tüm katmanlarda deployment işleme yeniden başladı
- 20 Mayıs 04:00 UTC: API, dashboard ve OAuth endpoint’lerinin çalıştığı doğrulandı; kalan iş yüklerinin kurtarılması sürdü
- 20 Mayıs 06:14 UTC: Kesinti izleme aşamasına alındı
- 20 Mayıs 07:58 UTC: Kesinti çözüldü
Ne oldu ve nasıl toparlandı
-
Google Cloud hesap askıya alması
- 19 Mayıs 22:20 UTC’de Google Cloud, otomatik bir işlemin parçası olarak Railway’nin üretim hesabını yanlışlıkla askıya alınmış duruma geçirdi
- Bu işlem, Google Cloud içindeki birden fazla hesabı etkiledi
- Platform genelinde uygulanan bir işlem olduğu için kısıtlama öncesinde tek tek müşterilere önceden bildirim yapılmadı
- Askıya alınmış durum, Railway Dashboard, API, ağ altyapısının bir bölümü ve Google Cloud üzerinde barındırılan ek burst-compute altyapısı dahil GCP ile ilişkili altyapıyı devre dışı bıraktı
-
Kontrol düzlemi bağımlılığı
- Railway’nin kontrol düzlemi, dashboard’u sunan, build ve deployment işlemlerini yürüten ve edge’in kullandığı rota tablolarını dolduran temel bağımlılık kümesidir
- Google Cloud’daki tüm iş yükleri anında etkilendi
- Railway’nin edge proxy sistemi, Google Cloud içinde barındırılan ağ kontrol düzleminin rota tablosu önbelleğini tutuyordu
- Önbellek geçerli kaldığı sürece Railway Metal ve AWS’deki iş yükleri trafiği işlemeye devam etti
- Önbelleğin süresi dolunca edge artık etkin instance’ların rotalarını çözemedi ve Metal ile AWS dahil tüm bölgelerdeki iş yükleri 404 hataları döndürmeye başladı
- İş yüklerinin kendisi çevrimiçiydi, ancak ağ arızasının etkisi Google Cloud dışındaki bölgelere de yayıldı
-
Yüksek erişilebilirlik tasarımının sınırları
- Railway altyapısı yüksek erişilebilirlik hedefiyle tasarlandı; veritabanları birden fazla availability zone üzerinde çalışıyor ve ağ, AWS, GCP ve Railway Metal arasında yedekli bağlantılar kullanıyor
- Hesap erişimi geri gelse bile tek tek servisler otomatik olarak toparlanmadı
- Kalıcı diskler, compute instance’ları ve ağ ayrı ayrı kurtarma gerektirdi ve bu kurtarma karakteristiği nedeniyle kesinti birkaç saat daha uzadı
- Diskler 23:54 UTC’de ready durumuna döndü, ancak kritik ağ ve edge yönlendirme 20 Mayıs yaklaşık 01:30 UTC’ye kadar tamamen toparlanmadı
- Railway, bu gecikme ve ilgili hataların Google tarafında oluşup oluşmadığının doğrulanmasını bekliyor
-
Kademeli toparlanma ve ikincil etkiler
- Ağ geri geldikçe Railway’nin çekirdek servisleri ve son kullanıcı iş yükleri katman katman doğrulandı
- Build sisteminin aşırı yüklenmesini önlemek için deployment geçici olarak durduruldu, ardından kademeli olarak yeniden açıldı
- Çekirdek sistemlerin toparlanmasına paralel olarak GitHub, Railway’nin OAuth ve webhook entegrasyonlarına rate limiting uyguladı
- Tüm yeniden deneme isteklerinin hacmi ve burst karakteri nedeniyle kullanıcı girişleri ve build’ler geçici olarak engellendi
- 20 Mayıs yaklaşık 04:00 UTC itibarıyla API, dashboard ve OAuth endpoint’lerinin çalıştığı doğrulandı; kalan iş yüklerinin toparlanması sürdü
Önleyici önlemler
-
Mevcut dayanıklılık tasarımı
- Railway’nin ağ kontrol düzlemi, multi-AZ, multi-zone yapı ile tasarlandı; böylece birden fazla makine ve bileşen kaybedilse bile kullanıcı etkisi olmadan çalışmayı sürdürebiliyor
- Bu tasarım, birkaç ay önce yayına alınmadan önce staging ortamında ve gerçek trafikte test edildi
- Railway, önceki kesintilerden sonra dayanıklılığa yatırım yapıyordu ve bunun sonucu olarak kullanıcı GitHub kurulumlarını ikincil rate limiting olmadan istikrarlı biçimde geri getirmeyi başarmıştı
-
Tekil bağımlılığın kaldırılması
- Railway ağı, Metal <> GCP <> AWS arasında yüksek erişilebilirlikli fiber ara bağlantılardan oluşan bir mesh ring yapısıdır
- Ancak bu halka içinde bile iş yükü keşfedilebilirliği, Google Cloud makinelerinde çalışan ağ kontrol düzlemi API’sine bağlı güçlü bir bağımlılık olarak kalmıştı
- Mesh yaklaşık bir saat boyunca çalışmayı sürdürdü, ancak rota önbelleğinin süresi dolunca rota tablolarını yeniden dolduramadığı için başarısız oldu
- Railway şimdi bu bağımlılığı derhal kaldırıp yapıyı gerçek bir mesh haline getirmek için çalışıyor
- Amaç, herhangi bir ara bağlantı kopsa bile bulutlar arasında her zaman bir yolun kalmasını sağlamak
-
Veritabanı ve failover iyileştirmeleri
- Railway, yüksek erişilebilirlikli veritabanı shard’larını AWS ve Metal geneline yaymayı planlıyor
- Gelecekte belirli bir buluttaki tüm instance’lar aniden kaybolsa bile veritabanı quorum’unun hizmeti sürdürmesi ve artık çalışmayan iş yükleri için anında failover yapılması hedefleniyor
-
Veri düzlemi ve kontrol düzleminin yeniden tasarımı
- Google Cloud servislerini veri düzleminin hot path’inden çıkarıp yalnızca ikincil veya failover amaçlı tutma planı sürüyor
- Bu çalışma, host bağlantılarını mümkün kılan veri düzlemi ile kullanıcıların Railway’ye erişip yönettiği dashboard’u çalıştıran kontrol düzlemi için yeni bir mimarinin uygulanmasıyla paralel ilerliyor
- Bu yükseltme, özellikle kullanıcıya dönük bileşenler olmak üzere çekirdek servislerin herhangi bir tek tedarikçiye ya da platforma bağımlı olmamasını sağlamayı amaçlıyor
Sorumluluk ve sonuç
- Tedarikçi seçimine ilişkin sorumluluk Railway’ye aittir ve bu tercih de nihayetinde Railway’nin sorumluluğundadır
- Müşteriler, arızanın nedeninin Google mı yoksa Railway mi olduğundan çok ürünün kendisine bakar; Railway’nin çalışma süresi Railway’nin sorumluluğudur
1 yorum
Hacker News yorumları
İlginç ve hâlâ açıklanmamış kısım, Google'ın hesabı neden işaretlediği
Olay sonrası analize gözlemlenen zaman damgaları ne kadar eklense de, kök neden ele alınmadı
Hikâyede “mantıklı gelmeyen” kısımda, muhtemelen kimsenin henüz kamuya açıklamak istemediği gerçek bir açıklama vardır
Google hesabı önceden haber vermeden kapattı ve o sırada ayda yaklaşık 10 bin dolar harcıyorduk
Hatta premium destek hesabı bile kilitlendi, bu yüzden destek ekibine “kilitlendiğimizi” bile bildiremedik
Yaklaşık 8 saat sonra rastgele bir Google destek mühendisi bunun Bitcoin madenciliği yaptığımız için olduğunu söyledi ama bu tamamen saçmalıktı
Tüm dönem için CPU kullanım grafikleri ve log'lar vardı, herhangi bir sıçrama da yoktu
Yaklaşık 12 saat sonra tekrar açtılar ve bunun bir “kötüye kullanım tespiti yapılandırma hatası” olduğunu söylediler, ayrıca yaklaşık 100 dolarlık kredi verdiler
AWS hakkında ne denirse densin, AWS olsaydı bir temsilci önce iletişime geçmeden müşteriye bunu yapmazdı
O günden beri GCP'ye güvenmiyorum
Otomasyon sistemleri hata yapar ama daha büyük sorun, tamamen opak olmaları
Google bile o sistemin tam olarak nasıl çalıştığını bilmiyor olabilir
Eğer Railway'nin GCP'den ayrılmak yerine buna enerji harcaması gerektiği kastediliyorsa, marka ve uzun vadeli müşteri kaybını telafi etmek için GCP'ye dava açmayı düşünmüyorlarsa neden yapsınlar bilmiyorum
GCP hiçbir ön uyarı olmadan kapattığı anda iş zaten bitmiştir, daha fazla sormaya da gerek yok bence
Railway'nin bu ay teknoloji medyasında pek iyi görünmediği anlaşılıyor
Her iki durumda da itibarın zedelenmesine diğer tarafın otomatik süreçleri neden oldu
Aslında Google temsilcisine Gemini CLI'yi öldüren sorunu anlatacaktım ama bu olay çok daha endişe verici
Yönetici hesap kimlik bilgilerini yapay zekaya veren yalnızca onlardı
Üstelik kişisel sorumluluk da almadılar ve bu kesinlikle itibarlarına zarar verdi
Bu kez en azından bir miktar sorumluluk kabul ediyorlar, bunu gelişme olarak teslim etmek gerekir
Ayrıca GCP'nin güvenilirlik sorunları ve Google'ın müşteri desteği problemleri gerçekten ciddi
Düzeltme: Aşağıda ilk iki paragrafın yanlış atfedildiğini ve bunun Railway değil, Railway'nin müşterisiyle ilgili olduğunu öğrendim. Özürler, Railway!
Şirketimiz geçmişte AWS üzerine bazı ek güvenceler ekleyen bir hosting sağlayıcısı kullanıyordu
Artık AWS ihtiyaç duyduğumuz özellikleri doğrudan sağlıyor, bu yüzden normal AWS'ye geçişi tamamladık
Ne yazık ki bu yüzden dün Azure'a acil migration yapmak zorunda kaldım
Neyse ki veritabanını Railway'de tutmuyorduk, bu yüzden birkaç saat içinde toparlandık
Railway'nin sunduğu sadelik gerçekten harikaydı ama bir B2B enterprise uygulamasını o altyapıda çalıştırmaya devam etmek için fazla çok olay ve sınırlama vardı
Üzücü bir gün :(
Hizmeti çok iyi tanımıyorum; benzersiz özellikleri için mi seçtin yoksa fiilen sanal makine amaçlı mıydı?
Eğer benzersiz özellikleri yüzündense, oradan çıkış migration'ının ne kadar zor olduğunu da merak ediyorum
Küçük SaaS araçları veya iç ürünler için, ekip AWS ya da başka bir IaaS sağlayıcısını doğrudan yönetmek istemiyorsa iyi alternatif ne olur?
AWS gibi bir şey kullansanız bile, birden fazla availability zone arasında yedekli yapı kurmazsanız ara sıra kesinti yaşarsınız
Birden fazla availability zone üzerinde yedekli yapı kursanız bile AWS tamamen izole bir mimari değildir; bazı servisler başarısız olabilir ve kesinti yaşanabilir
Bu yüzden kesintiyi kabul edin ve size en uygun aracı kullanın. Tabii GitHub seviyesinde aşırı kötü durumlar hariç
Eğer kesintiyi hiç kabul edemiyorsanız, kesinti olmayacağına güvenecek seviyeye gelmek için milyonlarca dolar ve aylarca çalışma gerekir
Netflix'in Chaos Monkey'si ve o seviyedeki altyapı ancak yeterli olur
En azından tam operasyonel kabiliyete sahip iki sağlayıcı gerekir
Kullandıkça öde ücretleri olmadan da epey yol alınabilir
Büyük bulut sağlayıcıları, Railway'nin sunduğundan yalnızca biraz daha zor servisler veriyor ve ihtiyaç arttıkça daha gelişmiş özelliklere genişleyebiliyorsunuz
Özellikleri, güvenliği ve erişilebilirliği kontrol eden bir üçüncü taraf eklemek zorunda kalmıyorsunuz
Örneğin bu zaman çizelgesine göre GCP 7 dakika içinde yanıt verdi
Cloud Run kullanıyor olsaydınız kesinti süresi 7 saatten fazla kısalırdı; ayrıca bilinmeyen tetikleyici başka müşteri aktiviteleriyle veya Railway'nin garip davranışlarıyla ilgiliyse, belki de en başta etkilenmezdiniz
Bir de karmaşıklık var
Railway'nin düzeltmek zorunda kaldığını yazdığı karmaşık altyapının önemli bir kısmı, yalnızca kendi hesabınızı kullansanız gerekli olmayacaktı
O kod muhtemelen faydalı işler yapıyordur ama hosting sağlayıcısı için gerekli olup normal kullanıcı için gerekmeyen çok sayıda hareketli parça var
Bu kesinti herkesi birlikte vurdu ama tekil AWS kullanıcıları veya bare-metal kullanıcıları baştan beri etkilenmemiş olurdu
Herkes için aynı tek bir küresel optimum yok ama geliştiriciler, dağıtım adımlarından birkaçını azaltarak kazandıkları zamana kıyasla doğrudan maliyeti ve başkasının ortamında çalışmanın daha görünmez maliyetini ciddi biçimde küçümseme eğiliminde
“19 Mayıs 22:10 UTC - Otomatik izleme API sağlık kontrolü başarısızlığını tespit etti, nöbetçi ekip çağrıldı ve sorumlular incelemeye başladı”
“19 Mayıs 22:20 UTC - Google Cloud, otomatik aksiyonların bir parçası olarak Railway'nin production hesabını yanlışlıkla askıya alınmış duruma geçirdi”
Zaman damgaları doğruysa, hesabın askıya alınmasından 10 dakika önceki hataya ne sebep oldu?
En basit açıklama, iki zaman damgasından birinin yanlış olmasıdır; bu da tek başına büyük bir mesele değil
Ama zaman damgalarından emin değilseniz, birbirleriyle açıkça çelişmelerine rağmen onları rapora kesinleşmiş gibi koymak oldukça tuhaf
22:10'un geçtiği zaman çizelgesi bölümü kendi içinde tutarlı ve şunu da içeriyor
“19 Mayıs 22:19 UTC - Kök neden belirlendi: Google Cloud Platform, Railway'nin production hesabını askıya aldı”
Bir olay gerçekleşmeden önce kök neden tespit edilemez
Örneğin bir Google çalışanı ayarları yanlışlıkla değiştirip, önceki olaylarda olduğu gibi askıya alma gerektiriyormuş gibi görünen bir sinyal üretmiş ve bunun askıya alma sürecine dönüşmesi 10 dakika sürmüş olabilir
Ya da bir Railway müşterisi dolandırıcılık yapmış veya öyle görünmüş olabilir; Google sistemi erişimi kısıtlamaya başladıktan sonra 10 dakika boyunca bunu askıya almaya yükseltip yükseltmemeye karar vermiş olabilir
Onay sürecinde bir insan varsa bu daha da olasıdır
Ama belli ki o kişi, bunun yapılmaması gerektiğini görecek kadar derine inmemiş
GCP işleten herkes için bu bir uyarı olmalı
GCP ne yaptığını düşünmeden hesapları sağa sola askıya alıyor gibi görünüyor
Sanki production kararlarını Gemini 3.1 Pro'ya verdiriyorlar
TK'nin, OCI'de olduğu gibi kurum kültürünü tamamen bozma geçmişi var ve duyduğuma göre GCP'de de benzer şeyler yaptı
GCP ile Google tamamen farklı çalışma biçimlerine sahip organizasyonlar
Sırf adında Google var diye Google kalitesi beklememek gerekir
Nokia gibi, bugün ucuz lisanslı ürünlere yapıştırılan eski bir marka gibi. Abartı ama gerçekten çok da uzak değil
Bununla da kalmıyor; servisleri rastgele kapatıp migration için yaklaşık 6 ay süre vermesiyle de tanınıyor
Yapacak işi olmayan çok sayıda mühendisi olduğu için iç kullanıcıları o servislerden çıkarmaya yönlendirebiliyor ama müşterilerin çoğu bunu yapamaz
Eski bir GCP çalışanının yazdığı harika bir yazı vardı ama şimdi bulamıyorum
İşinizi ciddiye alıyorsanız GCP'den vebadan kaçar gibi kaçınmalısınız
Düzeltme: İronik biçimde Gemini o yazıyı buldu. Okumaya değer: https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
HN ana sayfasında en üste çıkacak kadar bilinen bir isim ve belli bir ölçekte, bir noktada Google içinde müdahale edecek birini bulabilmesi gerekir
Bu benim yaptığım küçük bir ürün olsaydı, hiçbir başvuru yolum olmazdı
Asıl ürün kalitesi iyi olduğu için bu daha da üzücü
Rahatlıkla 2 numaralı sağlayıcı olabilirdi ama Azure çok dengesiz ve dokümantasyonu da düşük seviyede
GCP'nin 3. sırada olması büyük ölçüde kendi yarattığı bir sonuç
Tamamen dayanaksız kişisel değerlendirmem şu: Google'ın gevşek enterprise yaklaşımını düzeltmek için disiplinli bir yetişkin rolüyle getirildi
Bu olayın da gösterdiği gibi daha gidilecek yol var ama “ciddi” bir enterprise organizasyonu olmak için muhtemelen buna ihtiyaç vardı
Ama bu süreçte Google'ın geri kalanıyla çatışan bir kültür yaratmış olabilir
Yine de OCI'de yıkılacak bir kültür gerçekten var mıydı? Tersine, TK'nin o kültürü Google'a taşımış olması daha olası görünüyor
Önemli hiçbir iş için kullanılmamalı
Google Cloud'un müşteri hesaplarını ciddi biçimde bozduğu ilk olay bu değil: https://cloud.google.com/blog/products/infrastructure/detail...
“Railway, tedarikçi seçimi konusunda sorumluluğu üstlenir ve sonuçta bu seçim de bizim sorumluluğumuzdur. Müşteriler bir kesintinin Google'dan mı Railway'den mi kaynaklandığını umursamaz. Müşterinin gördüğü bizim ürünümüzdür. Çalışma süreniz bizim sorumluluğumuzdur ve bunu sağlamaya devam edeceğiz”
Bunu PR diliyle geçiştirmeyip kabul etmeleri takdire değer
GCP'ye güvenmek Railway tarafında bir mimari başarısızlıktı ve bunu düzeltmeye çalıştıklarını gösteriyor
Bunu önceden öngörmeleri gerekir miydi? Evet. Yine de hiç yapmamaktan iyidir, geç de olsa yapmak
“Son olarak, Google Cloud servislerini data plane'in hot path'inden çıkarıp yalnızca ikincil/failover amaçları için tutma planları yapıyoruz”
Oldukça açık
Google artık bir B2B hizmet sağlayıcısı olarak güvenilir değil
Bir şirkette, geliştiricilerden birinin kişisel Facebook hesabı hiçbir neden olmadan Meta tarafından engellendi diye, şirketin Meta OAuth uygulaması tamamen kullanılamaz hale gelmişti
Defalarca escalation yapıldı ama hiçbir yere ulaşılamadı
Meta, hesabın “kişisel” olmak zorunda olması nedeniyle daha da kötü
Business Manager olsa bile oraya eklenen tüm kullanıcılar kişisel Meta/Facebook hesaplarına bağlı
Saçmalık
Google tam da bu tür sorunlar yüzünden bir hizmet sağlayıcısı olarak güvenilemeyeceğini defalarca kanıtladı
Bu yüzden onlarca parçaya bölünmeleri gerekiyor
Çoğu zaman ancak kullanıcılar öfkelerini kamuya taşıyıp olay yayılınca gecikmeli olarak geri adım atıyorlar
Google, ücretli müşterilere karşı hiçbir yükümlülüğü yokmuş gibi davranmayı hep sürdürdü
Bence en önemli kısım bu
Bir bulut sağlayıcısı hiçbir sebep yokken tüm hesabı askıya almaz