Google'da SRE'nin Gelişim Süreci

• Google'ın ürünleri dünya genelinde milyarlarca kişi tarafından kullanılmakta ve bu ürünlerin kesintisiz çalışması kritik öneme sahiptir. Google'ın SRE ekibi, hizmetlerin güvenilirliğini artırmak için farklı yöntemler geliştirmiştir.
• Geleneksel SRE teknikleri (hata bütçesi, postmortem vb.) Google'ın web hizmetlerini ölçeklendirmesinde büyük katkı sağlamıştır.
• Son dönemde AI/ML gibi alanların etkisiyle sistem karmaşıklığı önemli ölçüde arttı ve yeni yaklaşımlara ihtiyaç doğdu.
• Sistem teorisi ve kontrol teorisi, karmaşık etkileşimleri sistematik biçimde anlamada yararlıdır.
• Sorun ortaya çıktıktan sonra düzeltme yaklaşımından çıkarak, sistem düzeyinde kökten tasarımdan güvenliğin garanti altına alınması zorunludur.

STAMP Genel Bakış

• MIT'den Profesör Nancy Leveson tarafından önerilen STAMP (System-Theoretic Accident Model and Processes), tek bir bileşen arızasından ziyade karmaşık sistem etkileşimleri açısından olayları (kaza/olay) analiz eder.
• Geleneksel nedensel bakışın yerine (“hata var, bu yüzden arıza oldu”) “sistemin bütünü hangi hatalı kontrol akışına kapıldı?” sorusunu öne çıkarır.
• Kaza yeniden yapılandırması için sistem teorisine dayalı nedensel analiz (CAST) uygulanır; sistem teorik süreç analizi (STPA) ile risk faktörleri önceden tespit edilir.

Kontrol Teorisinin Temeli – Dört Koşul

• Etkili kontrol için kontrol teorisinde 4 koşul gerekir:
  • Hedef koşulu: Bir hedefin (ör. belirli bir metriğin korunması) olması gerekir.
  • Eylem koşulu: Hedefe ulaşmak için sistem durumunu etkileyebilmek gerekir.
  • Model koşulu: Sistemi anlamak için bir modelin (içsel ve dışsal) bulunması gerekir.
  • Gözlemlenebilirlik koşulu: Mevcut sistemi algılayan bir gözlem altyapısının (sensör vb.) olması gerekir.

Arızayı (Outage) Kontrol Sorunu Olarak Ele Almak

• Önceden arızalar genellikle “ardışık arıza” olarak açıklanmaya eğilimliydi.
• STAMP bunu “yetersiz kontrol ve etkileşim” perspektifinde yorumlar ve sistem seviyesinde güvenliği sağlar.
• Sadece “ilk arıza nerede başladı?”yı bulmak yerine, “hangi kontrol/geri bildirim akışı bozulmuştu?” sorusunu bütünsel olarak inceler.

Tehlike (Hazard) Durumundan Zamansal Fırsat Elde Etmek

• Geleneksel nedensel modelde normal durumdan doğrudan kaza durumuna geçildiği için müdahale penceresi çok dardır.
• STAMP, “tehlike durumu” kavramını getirerek tam bir kazaya dönüşmeden önce tehlike bölgesine geçiş noktasını tespit eder.
• Tehlike durumu algılandıktan sonra agresif müdahale yapılarak gerçek kaza olmadan önce önlem alma şansı ortaya çıkar.

Gerçek Örnekle İnceleme

• Google içindeki “Quota Rightsizer”, hizmet kullanımına göre kaynakları yeniden tahsis eder.
• STPA perspektifinden, “yanlış kullanım bilgisi alarak gerçek ihtiyacın altında kaynak ayırmak” durumu önceden belirlenebilir.
• Tasarım aşamasında genelde sadece “doğru kontrol mantığı”na odaklanılırken, STPA uygulamasıyla geri bildirim yollarında (örn. kaynak kullanımının hesaplanması süreci) sorunlar bulunmuştur.
• 2021'de yanlış geri bildirim birikimi büyük bir probleme yol açmış ve haftalarca tehlike durumunda kalındığı ama fark edilmeyip geçildiği bir vaka vardır.

Gelecek Yol

• Google SRE, STAMP, STPA ve CAST gibi sistem teorisi temelli yaklaşımlarla daha yüksek seviyede güvenlik ve karmaşıklık yönetimi hedeflemektedir.
• Küçük ölçekli bir mühendislik yatırımıyla (sadece birkaç hafta) bile, büyük sistemlerde çok sayıda potansiyel risk senaryosu bulunabilmektedir.
• Mevcut güvenilirlik kültürüne ek olarak kontrol teorisi temelli analizler eklendiğinde, AI/ML döneminde de istikrarlı hizmet sunumu olasılığı yükselir.

[GN⁺]

Hacker News Yorumları

• Google'ın mühendislik yaklaşımı startuplar için zararlı olabilir. SRE'lerin kahraman sendromu yaşayarak diğer ekiplerin teknik tasarımlarını yeniden yapma eğiliminde oldukları görülüyor

  • Bu, bir hukuk ekibinin şirketi yönetmeye kalkmasına benziyor

• Sidney Dekker'ın kitabıyla benzerlikler var

  • Sistemin tamamını değerlendirip, kazaya dâhil olanların zihinsel durumunu anlayarak neden doğru bir karara vardıklarına inanıldığını analiz eder
  • Karmaşık bir sistemde bağımsız değişikliklerin güvenliği nasıl etkileyebileceğini açıklar

• CAST yaklaşımı çekici görünüyor

  • Birçok hata ve near-miss analizi gerektirir; bunu uygulamanın en zor kısmı insandır

• CAST ile mekanik muhakeme çalışmaları arasında ilginç bir benzerlik var

  • Sistem bileşenlerinin birbirleriyle nasıl etkileştiğini analiz etmek için bir çerçeve sağlar

• Resmi bir güvenlik mühendisliği çerçevesinin sinir ağı analizine uygulanmış örnekleri olup olmadığını merak ediyorum

  • Karmaşık nedensel ilişkileri ve sistem düzeyindeki davranışı takip etmenin yararlı olabileceğini düşünüyorum

• "rightsizer" örneği geleneksel yöntemlerle analiz edilse bile aynı sonuca ulaşılmış olabileceğini düşünüyorum

  • Yeni yaklaşım daha kolay ve uygulanabilir

• Yazılım testi sevmememin nedeni dışsal etmenlerden kaynaklı hatalardır

  • Bu yaklaşım buna yardımcı olabilir

• CAST çok faktörlü temel neden analiziyle benzer

  • MIT'li Nancy Leveson'ın CAST yaklaşımını destekliyor

• SRE/DevOps'ın günlük rolün parçası olup olmadığına dair bir soru

  • Birçok durumda bu, mevcut operasyon rolünün yalnızca yeniden markalaştırılmasıdır

• Google SRE'nin en büyük özelliği, yeni ürünleri piyasaya sürerken SRE yardımı gerektirmesidir

  • Sınırlı SRE sayısı iyi fikirlerin daha iyi hale gelmesini sağlar

• Makale çok uzun ve özü kavramak zor

  • CAST ve STPA'ya yapılan atıflar en önemli ve en değerli kısım

• Bu yaklaşımın FAANG dışındaki ölçeklerde de değerli olup olmadığını merak ediyorum

  • Riskten kaçınmaya çok yatırım yapma eğilimleri var

• DevOps'a benzer şekilde SRE'nin anlamı genişliyor

  • SRE, yazılım yazma veya sistem arızalarını ele alma gibi çeşitli rolleri üstleniyor