Google'da SRE'nin evrimi
(usenix.org)- Google SRE, hizmet ölçeği büyüse de arızaları azaltmayı başardı; ancak kişisel veri ihlali veya veri kaybı gibi mutlaka önlenmesi gereken kayıplar için mevcut yaklaşımın tek başına yetersiz olduğunu görerek STAMP'i benimsedi
- STAMP, tek tek bileşen arızalarından çok sistem etkileşimleri ve kontrol başarısızlığına odaklanır; CAST kaza incelemelerinde, STPA ise risk analizinde kullanılır
- Veri akışı modelleri ve doğrusal neden zincirleri, 100'den fazla düğüm içeren RPC diyagramları, eski mimari modeller ve eksik gereksinimler karşısında önemli analiz sınırlarına ulaşır
- 2021'deki dahili quota rightsizer vakasında, hatalı kaynak kullanımı geri bildirimi ve iletilmeyen pending change, haftalar boyunca riskli bir durum yarattı ve sonunda arızaya yol açtı
- Google, STPA analizine engineer-weeks ölçeğinde emek harcayarak yüzlerce senaryo buluyor; ayrıca SRE kapsamını Google Cloud, dahili ağlar ve çeşitli ürünlerin güvenli tasarımına doğru genişletiyor
Mevcut SRE yaklaşımının karşılaştığı sınırlar
- Google ürünleri her gün dünya çapında milyarlarca kişi tarafından kullanılıyor; son 25 yılda hizmet ölçeği büyük ölçüde artmasına rağmen arızalar daha seyrek hale geldi
- SRE şimdiye kadar güvenilirliği SLO, hata bütçeleri, izolasyon stratejileri, titiz postmortem'ler ve kademeli rollout ile ölçeklendirdi
- Artık mesele yalnızca arıza sıklığını azaltmak değil, ortaya çıkmasının baştan engellenmesi gereken kayıpları ele almak
- kişisel veri ihlali
- veri kaybı
- mevzuat uyumluluğu başarısızlığı
- Mevcut hata bütçesi yaklaşımı, durum sayısı az olan web servisleri için genel olarak iyi çalıştı; ancak 0 hata bütçesine yakın kayıpları ele almak için yeterli değil
- Yapay zeka ve ML neredeyse tüm ürünlerin çekirdeği haline gelirken, otomasyon ölçeklenebilirliği mümkün kılıyor; bu da maliyet ve enerji verimliliğini kullanıcı özellikleri kadar önemli kılıyor
Mevcut SRE düşünce yapısının yapısı
- Geleneksel risk analizi büyük ölçüde üç unsurdan oluşur
- sistemi modelleme biçimi
- sorunun nasıl ortaya çıktığını açıklayan nedensellik teorisi
- riskleri bulan arama algoritması
- Google SRE'nin mevcut yaklaşımı açık bir teori olarak formüle edilmemiş olsa da, riskleri yazılım mimarisi ve veri akışı modelleri etrafında analiz etti
- Veri akışı modeli, ağ isteklerinin veya verinin sistemin farklı bölümleri arasında nasıl hareket ettiğini gösterir
- Bu model doğal olarak doğrusal neden-sonuç akıl yürütmesine yol açar
- Her bileşenin SLO'suna bakarak güvenilirlik güvencesini anlamak
- Çağıranın gereksinimlerini karşılayıp karşılamadığını ya da aşıp aşmadığını doğrulamak
- Postmortem'lerde, tekil olaylardan genel örüntüler türeten tümevarımsal akıl yürütme kullanılır
- Amaç yalnızca bir olayı düzeltmek değil, aynı türdeki tüm olayları önlemenin yolunu bulmaktır
- Tekrarlayan alarmları mühendislik çözümlerine dönüştürerek sorunun kök nedenini ortadan kaldırmaya çalışır
Veri akışı modeli ve doğrusal neden analizinin sınırları
- Sistem karmaşıklığı her yıl arttıkça, veri akışı modeli Google ölçeğindeki karmaşıklığı taşımakta zorlanıyor
- RPC diyagramları ve yazılım mimarisi modelleri, soyutlama tutarlı kullanılmadığında aşırı karmaşık hale geliyor; çoğu zaman da eksik veya güncelliğini yitirmiş durumda kalıyor
- Bu modeller sistemin dinamiklerini yeterince gösteremiyor
- Hangi RPC'nin akışı başlatabileceği
- Hataların nasıl yayıldığı
- Hangi bileşenin ciddi bir arızaya, hangisinin yalnızca küçük bir soruna yol açabileceği
- Belirli bir etkileşimin hangi bağlamda güvenli, hangi bağlamda güvensiz olduğu
- Sistemin genel hedeflerinin ne olduğu
- Her bileşenin bu genel hedefler karşısındaki sorumluluğunun ne olduğu
- 100'den fazla düğüm içeren veri akışı diyagramları, kusur aramasının başlangıç noktasında bile bunaltıcı hale geliyor
- Gereksinim tanımı aşamasında güvenlik gereksinimleri eksik ya da yanlışsa, tasarım bu gereksinimleri kusursuz biçimde uygularsa bile sistem güvenliği bozulabilir
- Arıza verilerinden öğrenme yaklaşımı, henüz hiç yaşanmamış kayıpları tahmin edip önlemede sınırlı kalıyor
STAMP'in değiştirdiği düşünce biçimi
- Google SRE, sistem teorisi ve kontrol teorisini benimseyerek MIT'den Nancy Leveson tarafından geliştirilen STAMP çerçevesini kullanmaya başladı
- STAMP, kazaları bileşen arızalarının zinciri olarak değil, sistem kontrolünün yeterince işlemediği durumların sonucu olarak görür
- CAST kaza sonrası incelemelerde, STPA ise risk analizinde kullanılır
- STAMP, güvenliği tek tek bileşenlerin özelliği olarak değil, sistem düzeyinde ortaya çıkan bir özellik olarak ele alır
- Analiz soruları da değişir
- Eski soru: Hangi yazılım servisi başarısız oldu?
- STAMP sorusu: Sistemin her parçası arasındaki hangi etkileşim yeterince kontrol edilmedi?
- Karmaşık sistemlerdeki birçok olay, her bileşen tasarlandığı gibi çalışsa bile birlikte güvensiz bir durum üretmelerinin sonucu olabilir
Kontrol teorisinin dört koşulu
- W.R. Ashby'nin An Introduction to Cybernetics kitabındaki kontrol koşulları, Leveson'un STAMP metodolojisine entegre edilmiştir
- Bir süreci kontrol etmek için dört koşul gerekir
- Hedef koşulu: Denetleyicinin bir hedefi olmalıdır
- Eylem koşulu: Denetleyici sistem durumunu etkileyebilmelidir
- Model koşulu: Denetleyici sistemin bir modeline sahip olmalıdır
- Gözlemlenebilirlik koşulu: Denetleyici sistem durumunu algılayabilmelidir
- SRE pratiğinde bu koşullar, karmaşık sistemleri etkili biçimde kontrol etmek için gerekli unsurları doğrulama ölçütü olarak kullanılabilir
Risk durumlarının yarattığı müdahale alanı
- Doğrusal neden zinciri modeli genellikle yalnızca iki durum gösterir: normal işletim ve kayıp durumu
- Normal işletimden kayıp durumuna geçiş çoğu zaman ani olur ve kaybı önlemek için neredeyse hiç müdahale süresi bırakmaz
- SRE'nin hızlı burn ve yavaş burn SLO'ları birlikte kullanmasının nedeni de gerçek zarar öncesindeki sorunları tespit etmektir; ancak bu tür SLO'lar genellikle tekil bileşen özellikleridir
- STAMP bunu sistem düzeyinde risk durumu olarak formüle eder
- Risk durumu, belirli en kötü çevresel koşullarla birleştiğinde bir veya daha fazla paydaş için kayıp üreten sistem durumu ya da koşullar kümesidir
- Risk durumu, tek bir olayın ya da tek bir bileşenin fenomeni değildir
- Sistem, bir olay gerçekleşmeden önce uzun süre risk durumunda kalabilir
- Bir bug sisteme girmiştir ama henüz tetiklenmemiştir
- Bir alarm oluşmuştur ama kimseye ulaşmamıştır
- Bir sunucu yetersiz provision edilmiştir ama popüler bir özellikten aniden trafik almaktadır
- Mühendislik hedefi her tekil arızayı ortadan kaldırmak değil; sistemin risk durumuna girmesini önlemek ya da risk durumundan normal işletime geri dönmesini sağlamaktır
2021 quota rightsizer vakası
- Google, dahili altyapısında bazı yazılımlar için kaynak quota'larını belirliyor ve uyguluyor
- Verimliliği artırmak için her servisin quota'nın ne kadarını kullandığı izleniyor; uzun süre az kullanılırsa quota otomatik olarak düşürülüyor
- STPA perspektifinde quota rightsizer, servis quota'sını azaltan bir kontrol eylemine sahiptir
- Bu eylem, rightsizer quota'yı servisin gerçek ihtiyacının altına düşürdüğünde güvensiz hale gelir
- Servis kaynak yetersizliği durumuna girer
- STPA'da buna güvensiz kontrol eylemi, yani UCA denir
- UCA'nın dört türü vardır
- Gerekli kontrol eylemi sağlanmaz
- Hatalı ya da yetersiz kontrol eylemi sağlanır
- Kontrol eylemi yanlış zamanda ya da yanlış sırada sağlanır
- Kontrol eylemi çok erken durdurulur ya da çok uzun süre uygulanır
- Quota'yı gerçek ihtiyaçtan daha aşağı çekmek, ikinci tür UCA'ya girer
Geri bildirim yolunda ortaya çıkan zayıflıklar
- Güvenlik gereksinimi şu şekilde özetlenebilir: “quota rightsizer, quota'yı mevcut servis ihtiyacının altına indirmemelidir”
- Bu gereksinim, gelecekteki tasarım, test planları ve sistem anlayışı için faydalıdır
- STPA, bu güvenlik gereksinimini ihlal eden somut senaryoları bulacak şekilde analizi yapılandırır
- rightsizer vakasında dört temsilî senaryo incelenebilir
- rightsizer'ın kendisi yanlış çalışır
- rightsizer yanlış geri bildirim alır ya da hiç geri bildirim alamaz
- rightsizer bir eylem göndermeye çalışır ama quota sistemi bunu alamaz
- quota sisteminin kendisi yanlış çalışır
- Gerçekte öne çıkan senaryo, mevcut kaynak kullanımı geri bildiriminin olduğundan düşük hesaplanmasıydı
- Kaynak kullanımı hesabı birden fazla veri toplayıcı ve karmaşık toplulaştırma mantığı içerir
- Hesaplama sonucu gerçeğinden düşükse rightsizer tasarlandığı gibi çalışsa bile quota'yı yanlış biçimde düşürür
- Daha önce quota ayarlama algoritmasına ve çıktı doğruluğuna çok dikkat edilmişti; ancak geri bildirim yolu daha az anlaşılmıştı
- STPA yalnızca kontrol yolundaki değil, geri bildirim yolundaki sorunları da bulmayı sağlar; Google'ın birçok sistem analizinde de geri bildirim yollarının daha az anlaşıldığı görüldü
Olayın kayba dönüşme akışı
- 2021 olayında, Google altyapısındaki kritik bir servisin kullandığı kaynaklara dair hatalı geri bildirim rightsizer'a gönderildi
- rightsizer yeni quota'yı hesapladı ve gerçekte kullanılandan çok daha az kaynak tahsis edecek bir sonuca vardı
- Önleyici tedbir olarak quota küçültmesi hemen uygulanmadı; birinin müdahale edebilmesi için haftalarca bekletildi
- Ancak pending change ile ilgili geri bildirim kimseye iletilmedi
- Sistem haftalar boyunca riskli durumda kaldı; fakat bu durum özellikle aranmadığı için kaybı önleme fırsatı kaçırıldı
- Haftalar sonra quota küçültmesi uygulandığında ciddi bir arıza yaşandı
- Google, STPA kullanarak buna benzer sorunları birçok sistemde önceden tahmin etti
Google SRE'nin yöneldiği istikamet
- Google SRE, karmaşıklığı bir bug olarak görmek yerine; kontrol teorisi, STPA ve CAST ile daha kapsamlı ve daha proaktif bir güvenilirlik yaklaşımına geçiyor
- Amaç yalnızca arızalara tepki vermek değil, baştan daha güvenli sistemler tasarlamak
- Google, en karmaşık sistemlerinden bazılarını STPA ile analiz etti ve analiz başına engineer-weeks düzeyinde emekle etki alanı farklı yüzlerce senaryo buldu
- Bulunan senaryolar, arızaya dönüşmeden önce hafifletildi
- Hızlı geçici düzeltmeler
- Daha dikkatli planlanmış yazılım mühendisliği çalışmaları
- Google'ın düzenli planlama süreçleri kullanılarak maliyetin ve kesintinin azaltılması
- Mevcut çalışmalar, son derece karmaşık Google Cloud sistemlerine, büyük ölçekli dahili ağ sistemlerine ve çeşitli Google ürünlerine odaklanıyor
- SRE'nin sistem güvenliği metodolojisine geçişi, mühendislere inşa ettikleri sistemleri anlamak için yeni bir yaklaşım sunuyor ve çalışma biçimleri hakkında daha güçlü güvenceler sağlamayı hedefliyor
Henüz yorum yok.