Google Cloud, GCVE olayının ayrıntılarını açıkladı

 (cloud.google.com)
1 puan yazan GN⁺ 2024-05-26 | 1 yorum | WhatsApp'ta paylaş
  • Google Cloud’un Mayıs 2024’te yaşanan olayı, Avustralyalı müşteri UniSuper’ın GCVE ortamının bir bölümünün silinmesiyle ilgiliydi; şirket, iç incelemenin ardından nedenleri ve kurtarma adımlarını açıkladı
  • Etki alanı tek müşteri, tek bölge, tek hizmet ve müşterinin birden fazla GCVE Private Cloud’u içinden biriyle sınırlı kaldı; diğer müşteriler ve Google Cloud hizmetleri etkilenmedi
  • İlk dağıtım sürecinde iç araçtaki bir giriş değeri boş bırakıldı ve sistem bunu sabit 1 yıllık süre olarak yorumladı; süre bitince Private Cloud otomatik olarak silindi
  • Müşteri ve Google ekipleri birkaç gün boyunca 7/24 kurtarma çalışması yürüttü; GCS’de bulunan yedekler ve üçüncü taraf yedekleme yazılımı geri yüklemede kullanıldı
  • Google Cloud, aynı tür olayın tekrar yaşanmaması için ilgili iç aracı kullanımdan kaldırdı, tüm GCVE Private Cloud’ları elle gözden geçirdi ve silme davranışını düzeltti

Olayın kapsamı

  • Bu olay Google Cloud müşterisi UniSuper’ı etkiledi ve Google Cloud, müşteri sistemleri kurtarıldıktan sonra iç incelemesini tamamladı
  • Etki, Google’ın yönettiği hizmetler açısından sınırlıydı
    • Tek müşteri
    • Tek bulut bölgesi
    • Müşterinin Google Cloud VMware Engine (GCVE) kullanımı
    • Müşterinin sahip olduğu birden fazla GCVE Private Cloud içinden iki zone’a yayılan tek bir Private Cloud
  • Etkilenmeyen unsurlar da ayrıca belirtildi
    • Diğer Google Cloud hizmetleri
    • GCVE veya diğer Google Cloud hizmetlerini kullanan diğer müşteriler
    • Aynı müşterinin diğer GCVE Private Cloud’ları, Google Account, Orgs, Folders, Projects
    • Aynı bölgedeki Google Cloud Storage (GCS) veri yedekleri

Neden: iç araçta boş parametre

  • 2023’ün başlarında bir Google operatörü, belirli bir kapasite yerleştirme gereksinimini karşılamak için müşterinin GCVE Private Cloud’larından birini iç araçla dağıttı
  • Bu araç, kapasite yönetimine yönelik istisna sürecinde kullanılıyordu; 2023’ün 4. çeyreğinde kullanımdan kaldırıldı ve tamamen otomatik hale getirildi, böylece insan müdahalesi gerekmemeye başladı
  • Operatör, iç kontrol prosedürlerine uydu ancak Private Cloud sağlama sürecinde giriş parametrelerinden biri boş kaldı
  • Boş parametre nedeniyle sistem, o sırada bilinmeyen bir varsayılan değer olan sabit 1 yıllık süreyi bu parametreye atadı
  • Sistemin atadığı 1 yıllık süre sona erince müşterinin GCVE Private Cloud’u silindi

Müşteri bildirimi neden olmadı

  • Silme işlemi müşteri talebinden değil, Google operatörünün iç aracı kullanırken bıraktığı boş parametreden kaynaklandı
  • Müşteri silmeyi doğrudan talep etseydi önceden bildirim yapılacaktı, ancak bu silme için müşteriye bildirim gönderilmedi
  • Google Cloud, olayı tetikleyen koşulları ve alt sistem davranışını düzelterek aynı durumun yeniden yaşanmasını engellediğini belirtti

Kurtarma süreci

  • Müşteri ve Google ekipleri birkaç gün boyunca 7/24 iş birliği içinde kurtarma çalışması yürüttü
    • Müşterinin GCVE Private Cloud’unun kurtarılması
    • Ağ ve güvenlik yapılandırmasının geri yüklenmesi
    • Uygulamaların geri yüklenmesi
    • Tüm operasyonun yeniden ayağa kalkması için veri kurtarma
  • Müşterinin sağlam ve dayanıklı mimari yaklaşımı kurtarmaya yardımcı oldu
  • Aynı bölgedeki Google Cloud Storage’da tutulan veri yedekleri silme işleminden etkilenmedi
  • Bu yedekler ve üçüncü taraf yedekleme yazılımı hızlı geri yüklemede kritik rol oynadı

Tekrarını önleme adımları

  • Google Cloud, olayın tekrarını önlemek için çeşitli adımlar attı
    • Olay akışını tetikleyen iç aracı kullanımdan kaldırdı
    • Belirli kapasite yönetimi gerekse bile artık müşteri bunu kullanıcı arayüzü üzerinden kontrol ediyor ve ilgili kısımlar tamamen otomatik hale getirildi
    • Sistem veritabanını temizledi ve diğer GCVE dağıtımlarının riske açık olup olmadığını doğrulamak için tüm GCVE Private Cloud’ları elle inceledi
    • İlgili dağıtım iş akışında GCVE Private Cloud’un silinecek olarak işaretlenmesine yol açan sistem davranışını düzeltti
  • Google Cloud, bu türden bir olayın daha önce yaşanmadığını ve bunun sistematik bir sorun olmadığını değerlendirdi
  • Google Cloud hizmetlerinde gerektiğinde soft delete, ön bildirim ve human-in-the-loop kombinasyonundan oluşan koruma mekanizmaları bulunduğunu ve bu mekanizmaların kullanılmaya devam ettiğini doğruladı
  • Müşteriyle yakın iş birliği hızlı kurtarma açısından önemliydi; beklenmedik olaylara karşı dayanıklı risk yönetimi ve fail-safe mekanizmaları hızlı toparlanma için kritik önemdeydi
  • Google Cloud, bu tek seferlik olaya rağmen kendi uptime ve dayanıklılığının büyük bulut sağlayıcıları arasında en üst seviyede olduğunun bağımsız olarak doğrulandığını belirtti

İlgili okumalar

1 yorum

 
GN⁺ 2024-05-26
Hacker News yorumları

  • Bu olayın etki ölçeğine bakınca, iyileştirmelerin daha derin olmaması şaşırtıcı. Yapılan şey, aynı sorunun aynı şekilde tekrar etmemesini sağlamakla sınırlı; ileride bir yerde eşdeğer bir kusur ortaya çıkarsa benzer, hatta daha kötü sonuçlar doğabilir.
    Örneğin bir hizmet sonlandırıldığında verileri hemen silmek yerine birkaç gün boyunca koruyup tek düğmeyle geri getirilebilir durumda tutmaları; tüm hizmetlerin silme akışlarını denetleyip herhangi bir nedenle sonlandırmadan önce müşteriye haber vermeleri; ya da belli bir ölçeğin üzerindeki aktif hizmet sonlandırmalarına manuel inceleme eklemeleri gerekirdi.
    Bu tür geniş kapsamlı önlemler yoksa bu olay sonrası analiz hiç güven vermiyor. Bu kadar akıl almaz bir kazada, hizmetinden az da olsa gurur duyan ya da itibarını korumak isteyen bir sağlayıcının, bunun bir daha olmaması için gereğinden fazla çaba gösterdiğini ortaya koyması beklenirdi; Google Cloud ise yalnızca asgari olanı yapmış görünüyor.

    • Hizmet sonlandırılırken verileri hemen silmemek o kadar bariz bir kurumsal yazılım temel pratiği ki, Google'ın 2024'te buna sahip olmaması çok şey anlatıyor.
      Kariyerimin başından beri bile artık gerekmeyen verileri anında silme fikri mantıklı gelmezdi. Veritabanlarında silindi işareti için bir sütun kullanan soft delete uygulanır; diskteki veriler gerçekten silinebileceğinden emin olana kadar taşınır ya da yeniden adlandırılır; buna rağmen yedekler de tutulurdu.
    • Kesinlikle katılıyorum. GCP operatörlerinin platformu yönetme biçiminde sistemik bir sorun olmadığını vurgulamakla daha çok ilgilenmişler gibi duruyordu; bu da tam tersine, sistemik bir sorun olduğu hissini güçlendiriyor ve metni rahatsız edici kılıyor. Olay sonrası analizde sağduyulu önlemlerin eksik olması, bunu düzeltme niyetleri yokmuş gibi görünüyor.
    • Gerçek silmeyi bir silme bayrağına çevirmek, “Google Cloud müşteri verilerini silemediği için AB düzenlemelerini ihlal etti” gibi başka eğlenceli bir bug doğurabilir. Google'ın yanlışlıkla silmemek yerine yanlışlıkla silme tarafını seçeceğini düşünüyorum; en azından AB'de böyle görünüyor.
    • Bunları yapmamaları şaka gibi. Dev bir bulut sağlayıcısının veri silme için güvenlik önlemleri koymayı düşünmemesi akıl alır gibi değil. Gerçekte muhtemelen bunu defalarca düşündüler ama maliyetli olduğu için uygulamadılar.
    • Google'ın “olay sonrası analizi” gerçekten anlaşılır gibi değil. Çevrimiçi hizmet işletmiş herkes bunun açıkça yetersiz olduğunu görmekle kalmaz; sonuç kısmı da kibirle dolu. “Tek seferlik bir kazaydı, bir daha olmayacak; gerçekten üzgünüz ama biz harikayız ve harika olmaya devam ediyoruz” havasında, bu yüzden Google Cloud adına insanın yüzünü ellerinin arasına almasına neden olan anı hiç telafi etmiyor.

  • GCP müşterisiyseniz ve bir TAM'iniz varsa, şöyle sorarsanız zorlanacaktır: GCP bir yönetim hatası yaptığında hesabımdaki büyük miktarda kaynağın yanlışlıkla silinmesini engelleyen korumalar neler?
    Muhtemelen belirli sorunun ilgili aracın emekliye ayrılması ve daha fazla otomasyonla hafifletildiğini söyleyecekler; siz de “Bunun düzeltildiğini biliyorum. Peki büyük ölçekli silmelerden önce bir insan incelemesi yapılıyor mu?” diye devam edebilirsiniz.
    Daha önce GCP'de çalışmış, AWS'yi ise daha uzun süredir aktif olarak kullanmış biri olarak gördüğüm kadarıyla, GCP'nin insan temelli koruma önlemleri neredeyse yok ve AWS'ye kıyasla çok daha az. Her hâlükârda bu gerçek riski TAM'inize sormaya kesinlikle değer.

    • İyice sıkıştırmak lazım. Böylece TAM'ler iç sistemlerle daha iyi başa çıkmayı öğrenir. Tek başlarına değiştiremezler ama bazen bir üst kademeye iletme yolu sözü ya da gayriresmî bir mutabakat elde edebilirsiniz.
      Yeterince çok TAM ses çıkarırsa, bir gün yukarıdaki biri harekete geçebilir.
    • Müşteri varlıkları silinmek üzereyken Google çalışanlarının iletişime geçip müşteri elde tutma fırsatı yakalaması şeklinde paketlerseniz, içeride daha iyi karşılık bulabilir. Yan etki olarak da herkese yakında bir şeylerin uçup gideceğini açıkça bildirmiş olur.

  • “Google ekibi birkaç gün boyunca 24x7 çalıştı” deniyor; burada 7'nin ne anlama geldiğini bilmiyor gibiler.

    • Herhalde 24 mühendisin günde 7 saat çalıştığı anlamına geliyor. Masaj ve şeflerin hazırladığı ücretsiz kampüs yemekleri dahil.
    • Tamamen kelimesi kelimesine alırsak biraz anlamsız olduğu doğru. Ama x7 elbette haftanın 7 günü çalıştıkları anlamına gelir; yani perşembe öğleden salı sabahına kadar da 24x7 çalışmış olabilirler. Hafta sonu ara vermedikleri anlamına geliyor.
    • O kadar çok çalışmışlar ki birkaç gün onlara birkaç hafta gibi gelmiş olmalı.
    • Hafifletme çalışmaları hafta sonuna denk geldiyse yine de anlamlı olabilir.
    • Ekip üyelerinin vardiyalı şekilde gece ya da hafta sonu kesintisi olmadan çalışmaya devam ettiği anlamına da gelebilir. Bana kalırsa böyle büyük projelerde bunun zaten standart olması gerekir.

  • Vay, yanılmışım. Terraform gibi bir yerde kurtarma süresi olmadan anında silmenin varsayılan olduğunu ve UniSuper tarafında birinin test yaparken silme kapsamını yanlış belirlediğini sanmıştım. Yine de bir varsayılan değer sorunu olduğunu düşünüyordum ama bunun üçüncü taraf araç ve UniSuper tarafındaki bir hata olacağını sanmıştım.
    Bunun gerçekten Google tarafındaki bir sorun olması çılgınca. UniSuper muhtemelen “Bu da ne?” diye kalmıştır.

    • Yazıda ne olduğu anlatılıyor ve UniSuper ile ilgisi yok. Google, dahili bir araçla private cloud dağıttı ve o Google dahili aracı bunu 1 yıl sonra otomatik silinecek şekilde ayarladı.
    • Google'ın GCP faturasında devasa krediler verdiğini ya da doğrudan ayrı bir tazminat ödediğini düşünüyorum.

  • İlgili yazılar: UniSuper members go a week with no account access after Google Cloud misconfig[0](186 points, 16 days ago, 42 comments), Google Cloud accidentally deletes customer's account [1](128 points, 15 days ago, 32 comments)
    [0]: https://news.ycombinator.com/item?id=40304666
    [1]: https://news.ycombinator.com/item?id=40313171

  • Belirli bir araç ya da prosedür incelemesinde durmayıp, geri kalanlarda da otomatik silme sorunu olup olmadığına baktıklarını ve soft delete davranışını da kontrol ettiklerini söylemeleri, oldukça kapsamlı bir inceleme gibi geliyor.
    Bir adım daha ileri gidip şaşırtıcı varsayılan davranışlar var mı diye tüm varsayılan değer senaryolarını da gözden geçirebilirlerdi. Yine de neyin “şaşırtıcı” olduğuna karar vermek zor olabilir. Çünkü araçları ya da API’leri en az bilen kişiler çoğu zaman varsayılanları olduğu gibi kullanır.

    • “Soft delete davranışını da kontrol ettiler” kısmı tam olarak nerede geçiyor? Sadece bu belirli otomatik silme senaryosunun artık yaşanmayacağını garanti ettiklerini söylüyorlar; ana gerekçe de “artık dağıtım otomatikleştirildi” gibi görünüyor.
      Önceden de otomatikti, şimdi daha da otomatikleşmiş; bu, silme mekanizmasının tutarlı biçimde güvenli olduğuna dair hiç güven vermiyor. Sadece direksiyon başında bir operatör kalmadığı anlamına geliyor.
    • Bu tür bir olay, sadece AWS kullanalım demek için mükemmel bir gerekçe olduğundan, içeride epey paniklemiş olmalılar.
      “Sistem tarafından verilen 1 yıllık süre sona erdikten sonra müşterinin GCVE Private Cloud’u silindi. Dahili aracı kullanan bir Google operatörünün parametreyi boş bırakması sonucunda silme tetiklendi ve bu müşteri kaynaklı bir silme isteği olmadığı için müşteriye bildirim gönderilmedi. Silme müşteri tarafından başlatılmış olsaydı önceden bildirim yapılacaktı.”
      Ta-da! İnsan incelemesi olmadan devasa silmelerin gerçekleşmesine izin verecek kadar beceriksiziz. Neyse ki bu müşteri bize güvenmeyip GCP dışında yedek tuttuğu için tamamen mahvolmadı.
      “Google Cloud’da bu nitelikte bir olay daha önce yaşanmadı. Bu sistemik bir sorun değil.”
      Çevirisi: “Aman Tanrım, AWS ve Azure satışçıları bizim bu muazzam fiyaskomuzu alıntılayıp tüm potansiyel müşterilere üçer e-posta gönderdi.”

  • Böyle bir olayın ilk kez milyarlarca dolarlık bir yatırım fonunun başına geldiğini söylemek inanması güç. UniSuper sorununun çözülmesine sevindim ama muhtemelen göz ardı edilebilecek kadar küçük başka vakalar da olmuştur.
    Umarım bu olay GCP için gerekli uyarı olur.

    • GCVE, yani yönetilen VMware, epey obscure bir hizmet. Mevcut VMware kümelerini olduğu gibi buluta lift-and-shift yapmak isteyen milyarlarca dolarlık şirketlerin kullanacağı türden bir hizmet.
    • Bu olayın özü, çoğu müşteride olmayan ya da kullanılmayan özel bir özelleştirmenin bulunması ve bunun bazı güvenlik kontrollerini atlatmasıydı. Bu yüzden “tipik” küçük müşterileri etkileyemezdi.
    • Küçük bir müşteri bile bunu basına götürürdü ve basın kesinlikle haber yapardı; bu yüzden öyle bakmak zor.
      “Google bulut hizmetimizi sildi” her ölçekte şirket için büyük haberdir.

  • “Müşterinin CIO’su ve teknoloji ekibi, Google Cloud ekibiyle yakın çalışarak 24x7 kurtarmayı hızlı ve doğru biçimde yürüttükleri için takdiri hak ediyor” denmiş; blog yazısında sadece övgü mü aldılar, yoksa yüklü miktarda Google Cloud kredisi de kopardılar mı merak ediyorum.

    • Yetkin bir müşteri için Google’ın bu maliyeti üstlenmemesini sağlayacak bir gerçeklik yok. Bu yıl faturalarının hiç olmamasına şaşırmam.
    • Cezai tazminat da olmalıydı.

  • Avustralya’da UniSuper müşterisiyim. O sırada ne olduğunu bilmiyordum ama çözmeye çalıştıkları süre boyunca her gün e-posta aldım. Aslında ne olduğunu haberlerden öğrendim. Bütün olayı sistem kesintisi gibi küçülterek anlattılar hissi verdi.
    İnsanların parası ve emeklilik fonlarıyla biriken milyarlarca dolara gerçekten bir şey olduğunu hayal etmek ürkütücü.

    • Diğer insanların aldığıyla aynı e-postaları mı aldın? Neredeyse her gün e-posta geldi ve “disruption”, “apologies”, “frustration” gibi kelimeler birkaç kez kullanıldı.
      Birkaç gün sonra “A letter from the CEO” başlıklı bir e-posta da geldi.
      “Hizmet kesintisine ilişkin bir güncelleme paylaşmak istiyoruz.”
      “Öncelikle bu aksaklık için şahsen özür diler, ekiplerimiz sistemleri kademeli olarak tekrar çevrimiçi duruma getirmek için gece gündüz çalışırken gösterdiğiniz sabır için teşekkür ederim.”
      O koşullarda daha net bir iletişim ya da Google Cloud içinde ne olduğuna dair daha açık bir açıklama istemek zor olurdu diye düşünüyorum.

  • Bu olayla ilgili ilk duyuru epey yanıltıcıydı. Google yanlışlıkla tüm GCP hesabını silmiş gibi geliyordu. Bu yazıyı okuyunca biraz rahatladım. Kaybedilen şey yalnızca bir bölge ölçeğinde sanal makineler gibi görünüyor; böyle bir şey gerçekten olabilir ve benim sistemimin bunu büyük sorun yaşamadan kaldırabileceğini düşünüyorum.
    İlk yazı, tüm bölgelerdeki GCS bucket’ları, SQL veritabanları vb. her şey yok olmuş gibi geliyordu; bu bambaşka bir sorun ve Google’ın böyle bir şey yapmadığına güvenebilmek isterim.

    • UniSuper bunun hesap değil abonelik silinmesi olduğunu söylediğinde bu bir uyarı işaretiydi. Birçok kişi oradan aceleyle sonuca vardı.