Azure güvenini yıkan kararlar – Eski bir Azure Core mühendisinın kaydı

 (isolveproblems.substack.com)
3 puan yazan GN⁺ 27 일 전 | 1 yorum | WhatsApp'ta paylaş
  • Microsoft Azure Core içindeki gerçekçi olmayan karar alma süreçlerinin birikerek teknik karmaşa ve güven çöküşüne yol açtığını eski bir mühendis ayrıntılı biçimde anlatıyor
  • Donanım kısıtlarını göz ardı eden Windows özelliklerini taşıma planı ve 173 yönetim ajanının kontrolden çıkmış biçimde çoğalması başlıca sorunlar olarak gösteriliyor
  • Bu karmaşık yapının OpenAI, Anthropic ve kamu bulutu gibi kritik iş yüklerini taşıması, tek bir hatanın küresel çapta bir kesintiye yayılma riski doğurduğu anlamına geliyor
  • Yönetimin yanıtsız kalmasıyla birlikte OpenAI ile ilişkinin bozulması, ABD hükümetinin güvenini kaybetme ve özellik yayınlarında gecikme gibi gelişmeler yaşandığı belirtiliyor
  • Sonuçta bunun 1 trilyon dolarlık piyasa değerinin buharlaşmasına uzandığı ve bulut altyapısı işletiminde teknik gerçekleri kavrama ile sadeliği korumanın önemi vurgulanıyor

Azure güven çöküşünün içeriden kaydı

  • Eski bir mühendisin anıları, Microsoft Azure Core ekibi içindeki gerçekçi olmayan karar süreçlerini ve bunun yol açtığı teknik ve kurumsal karmaşayı ele alıyor
  • Overlake R&D ekibine katıldığı ilk günden itibaren, donanım kısıtlarını yok sayan Windows özelliklerini Overlake kartına taşıma planlarının konuşulduğuna tanık olduğunu anlatıyor
  • 173 yönetim ajanı bulunmasına rağmen, bunların işlevini ve neden gerekli olduğunu bilen neredeyse kimsenin olmaması, karmaşıklık ve opaklığın ne kadar ciddi olduğunu gösteriyor
  • Bu yapının OpenAI, Anthropic ve kamu bulutu gibi kritik iş yüklerini taşıması, tek bir hatanın küresel bir kesintiye dönüşme riski yarattığı anlamına geliyor
  • Bunun sonunda OpenAI güveninin kaybedilmesi, ABD Savunma Bakanlığı'nın açık güvensizliği ve 1 trilyon dolarlık piyasa değerinin silinmesiyle sonuçlandığı anlatılıyor

Azure Core'a katılım ve ilk durum

  • 1 Mayıs 2023'te Azure Boost offloading kartı ve ağ hızlandırıcılarından sorumlu Overlake R&D ekibine kıdemli mühendis olarak katıldı
  • Daha önce Windows ekibi ve Core OS ekibinde çekirdek iyileştirmeleri ve konteyner platformu geliştirme çalışmalarında yer aldı; Docker, AKS, App Services ve Windows Sandbox gibi temel teknolojilere katkı sundu
  • Overlake kartının ilk tasarımında da (2020~2021) görev aldı ve host OS ile hızlandırıcı kart arasındaki iletişim protokolünü önermişti
  • Azure platformunu 10 yıldan uzun süredir doğrudan işleten ve geliştiren bir uzman olarak geri döndü

İlk toplantıda görülen gerçek dışı plan

  • İşe başladığı ilk gün, ekibin aylık planlama toplantısında Windows bileşenlerini Overlake kartına taşıma planını gördü
  • Overlake kartının RAM kapasitesi ve güç bütçesi son derece sınırlı olmasına rağmen ekip, Windows işlevlerini taşımayı ciddi biçimde tartışıyordu
  • Bu, donanım özellikleri açısından imkânsız bir plandı ve hatta “birkaç junior geliştiriciye verelim” gibi ifadeler de kullanıldı
  • Kurum, VM yönetim ajanlarını korumak için Windows'u Linux'a taşıma yönünü ciddi biçimde değerlendiriyordu
  • Yazar bunu “gerçeklikten kopuk bir plan” olarak gördüğünü ve tüm organizasyonun imkânsız hedeflere doğru yürüyüşe geçtiğine karar verdiğini söylüyor

Teknik sınırlar ve yapısal sorunlar

  • O dönemki yığın, 400W Xeon CPU üzerinde yalnızca birkaç düzine VM işleyebiliyordu; bu da hypervisor'un 1.024 VM sınırından çok uzaktı
  • Aşırı kaynak tüketimi nedeniyle müşteri VM'lerinde jitter oluşması gibi performans sorunları da vardı
  • Bu verimsiz yığını küçük bir ARM SoC üzerine taşıyıp ölçekleme planı teknik olarak mümkün değildi
  • Yazar, “yeni teknoloji öğrenmekten daha acil olan şeyin, tüm organizasyonu yeniden gerçekliğe döndürmek olduğunu” söylüyor

Azure Linux ve Overlake ile ilgili iç görüşmeler

  • Linux System Group yöneticisiyle yaptığı 90 dakikalık görüşmede, Overlake kartı için 173 ajanın taşıma adayı olarak belirlendiğini öğrendi
  • Araştırma sonucunda, Microsoft içinde kimsenin bu 173 ajanın rolünü, etkileşimlerini ve neden var olduklarını net biçimde açıklayamadığı ortaya çıktı
  • Azure'un çekirdeği VM, ağ ve depolamadan oluşurken, diğer hizmetler bunun üstüne kurulmuş olmasına rağmen gereksiz karmaşıklık birikmişti
  • Bu kontrol edilemeyen bileşenler kümesi, OpenAI, Anthropic ve kamu bulutu gibi büyük iş yüklerini yönetiyordu

Güven kaybı ve sonrasındaki gelişmeler

  • Bu karmaşık yapı, ulusal güvenlik ve iş sürekliliği açısından ciddi riskler doğurabilecek durumdaydı
  • Sonrasında CEO'ya, yönetim kuruluna ve Cloud+AI bölümünün EVP'sine gönderilen mektupların tamamı yanıtsız kaldı
  • Bunun sonucu olarak OpenAI ile ilişkinin bozulması, ABD hükümetinin güveninin çökmesi (Savunma Bakanı'nın açık açıklaması), mühendislik israfı ve Rust'a geçiş talimatı ile özellik yayınlarında gecikmeler yaşandığı belirtiliyor
  • Yazar bunu “1 trilyon dolarlık piyasa değerinin buharlaştığı olay” diye tanımlıyor ve Azure kullanan şirketleri üretim ortamında bu yapıya bağımlı olmanın riskleri konusunda uyarıyor

Sonuç

  • Azure içindeki teknik karmaşıklık, zayıf yönetim ve gerçekçi olmayan kararların birikerek güven kaybına yol açtığı süreç ortaya konuyor
  • Kritik altyapıdan sorumlu bir organizasyonun gerçeklik duygusunu yitirip yapısal bir başarısızlığa doğru yürümeyi sürdürmesinin bir örneği olarak sunuluyor
  • Bulut altyapısında istikrar ve sadeliğin, ayrıca kurum içinde teknik muhakemeyi korumanın öneminin altı çiziliyor

İlgili okumalar

1 yorum

 
GN⁺ 27 일 전
Hacker News yorumları

  • Her gün Azure kullanan biri olarak, bu ifşalar doğruysa gerçekten pek çok şeyi açıklıyor gibi geliyor
    Arayüz özensiz, belgeler sanki yapay zeka yazmış gibi hatalı, hizmet türü de o kadar fazla ki hangisini kullanmak gerektiğine dair bile fikir oluşmuyor
    Danışman desteği olmadan yapılandırmak zor ve yapılandırdıktan sonra da gerçekten düzgün çalıştığından emin olunamıyor
    Açıkçası bunun hâlâ ayakta olmasına şaşırıyorum

    • Eskiden Azure belgelerine hayran kalırdım ama bir haftalık uygulamanın ardından test ortamında GraphAPI belgelerde yazdığı gibi çalışmadığı için tamamen başarısız oldum
      O zamandan beri belgelere güvenmiyorum
    • Azure danışmanlarıyla çalıştım, onlar da Azure'dan nefret ediyor
    • Yönetim çok fazla kredi olduğu için AKS'ye geçti ama pod'lar rastgele çöküyor ve DB düğümlerindeki disk gecikmesi aniden fırlıyordu
      GCP'de stabil çalışan hizmet öngörülemez hâle geldi

  • Yük altındayken Azure OpenAI'ın başka müşterilerin prompt yanıtlarını sızdırdığını gördüm
    İlgili tweet de var
    Ama kimsenin umursamadığı bir hava var

    • “Azure OpenAI”ın tam olarak ne anlama geldiğini merak ediyorum — GitHub Copilot, Microsoft Copilot, OpenAI API ya da Azure üzerinde barındırılan LLM'lerden biri mi?
      Tam bir Vahşi Batı durumu gibi

  • Bu yazının iddiaları çok somut olduğu için şaşırtıcı
    İçeriden bilgi sızdıran biri mi, yoksa sadece memnuniyetsiz eski bir çalışan mı diye merak ediyorum
    CEO'ya ve yönetim kuruluna doğrudan rapor verdiği kısmı özellikle etkileyici
    ABD şirket kültüründe böyle bir sürecin “alışılagelmiş” olması bana yabancı geliyor
    Azure gerçekten bu kadar kararsız mı, gerçek kullanıcı deneyimini merak ediyorum

    • Fiilen SRE olarak AWS, Azure ve GCP'nin üçünü de işletiyorum ve kesintilerin %80-90'ı Azure'da yaşanıyor
      Azure sorunu fark etmiyor, sebebini de bilmiyor, hatta umursamıyor gibi bile görünüyor
      Bütün ekip Azure'dan nefret ediyor
    • Azure'da tutarlılık sorunları ve race condition çok fazla
      OpenAI modellerini AWS Bedrock üzerinden kullanabilmek ve böylece Azure'dan kaçınabilmek sevindiriciydi
      Güvenilirlik hâlâ ciddi bir sorun
    • Büyük şirketler kısa vadeli metrikler uğruna sık sık kaliteden ödün veren kararlar alıyor
      “Hızlı çıkaralım, sonra düzeltiriz” stratejisi sonunda böyle sonuçlar doğuruyor
    • Eskiden Azure container'ından çıkış yapıp yönetim denetleyicisindeki bir zafiyeti bulan bir güvenlik raporu görmüştüm
      O zamandan beri güvenmiyorum
    • Ücretsiz kredi verseler bile AWS ya da GCP'ye para ödemek daha iyi diye düşünüyorum

  • Yazı biraz duygusal olarak abartılı olduğu için asıl niyet bulanıklaşmış gibi
    Azure içindeki unvan yapısı ya da Sev2 seviyesindeki sorunlar o kadar da sıra dışı değil
    Azure'nun sorunları var ama ölçek büyük olduğu için pürüzler de doğal
    Gerçek olgunluk bence sistemin içinde kalarak iyileştirmeye çalışmakta

    • Yönetim kuruluna doğrudan mektup göndermek kurum içinde asla iyi sonuçlanmayacak bir hareket
      Azure berbat olabilir ama yazarın yaklaşımı da sorunlu olmuş olabilir
    • AWS ve GCP'nin UX/DX'i çok daha iyi ve Azure neden çalışmadığını bile söylemiyor
      Azure hakkındaki izlenimim tamamen olumsuz
    • Microsoft devlet kurumlarının varsayılan çözümü ama baştan sona yeniden yazım önerisi gerçekçi değil
      Yazarın yaklaşımı tersine güveni azaltıyor
    • Yazarın söz ettiği daha düşük kıdemli kişilere çekirdek sistemlerin emanet edilmesi şaşırtıcı
    • “Her şey mahvoldu” diye bağıran çok insan var ama bu kurumun atalete kapılmış sorunu da olabilir
      Yeni çalışanların günde kaç kez “wtf/day” dediği kurum sağlığının bir göstergesi gibi
      Azure dışarıdan bakınca da kalite olarak dibi görüyor
      AWS'yi yakalamak için aceleyle özellik fırlattıkça devasa bir teknik borç bataklığına saplanıyor
      IPv6, azcopy, VM yükseltmesi gibi temel özellikler bile hâlâ kararsız

  • Eski bir iş arkadaşım Azure'u her gün kullanıyor ve onların şikâyet patlamalarını her duyduğumda bu yazının içeriği daha anlamlı geliyor
    12 yıl önce bulut uzmanlaşmasını seçerken Azure'u kısa süre denemiş ve onu yavaş, bozuk bir platform olarak görmüştüm; bu yazı o yargımı doğruluyor

  • Yazının sonlarına doğru Microsoft'un 2025'te 15.000 kişiyi işten çıkardığı kısmı dikkat çekiciydi
    Yapay zeka patlamasının arkasındaki gerçeği gösteren bir örnek gibi

    • Ama bence o kısım yazının zayıf bir iddiası
      OpenAI sözleşmesi GPU kapasitesi sorunuydu ve işten çıkarmalar ayrı bir konu
      Asıl mesele mühendis rotasyonu ve sorumluluk eksikliği
      Her projeye yeni insanlar giriyor ve sahiplenme duygusu kayboluyor

  • Host ele geçirilirse tüm VM belleğine erişilebilmesi kısmı son derece tehlikeli geliyor

    • Böyle bir mimariyi iyi fikir sayan bir ortamı hayal bile edemiyorum
    • Yazarın ne beklediğini bilmiyorum

  • Satya Nadella'nın maaşının %22 artarak 96,5 milyon dolara çıktığını söyleyen CNBC alıntısıyla,
    Artemis II astronotunun “İki Outlook da çalışmıyor” sözünü yan yana görmek ironikti

    • “İki Outlook” mu? Zaten bir tanesi bile fazla

  • Yazıdaki içerik abartılı görünüyor ama ben de benzer sistemler işletmiş biri olarak istikrarı korumak için sürekli mücadele etmek zorunda kaldığım günleri hatırlıyorum
    Başka şirketlerde de benzer sorunlar gördüm ama Azure ölçeğinde bu kadar ağır değildi
    Bu yapı sonunda bir kendini yok etme döngüsüne girecek gibi geliyor

  • 2018'de Azure'u denedim; yavaş ve pahalıydı, kalitesi de berbattı
    GitHub forumlarında diğer kullanıcılarla birlikte en temel özelliklerin bile çalışmaması sorunlarını çözmeye uğraşıyordum
    Bu yazı o zamanki sorularımı yanıtlıyor
    Kişisel olarak Google Cloud'un en iyi tasarlanmış platform olduğunu düşündüm ama AWS'ye kıyasla insan desteğinin zayıf olması hayal kırıklığı yaratıyor

    • GCP desteği gerçekten çok kötü
      Temsilci üç ay içinde üç kez değişti ve kota talepleri ya da sistem sınırlarıyla ilgili sorular bazen görmezden gelindi