- Google SRE, küçük veri merkezleri ve Python betiklerine dayalı operasyonlardan başlayıp işlem ölçeğinin 1.000 kattan fazla, ağ ölçeğinin 10.000 kattan fazla büyüdüğü bir ortamda güvenilirliği artırma deneyimini özetliyor
- Olay müdahalesinde hızlı aksiyondan önce hafifletme önlemlerinin güvenliği gelir; hatalı kurtarma prosedürleri kesintiyi azaltmak yerine zincirleme arızaları büyütebilir
- YouTube ve Google Calendar örnekleri, küresel değişiklikleri sınırlayan kanarya dağıtımının, anında geri alınabilir Big Red Button’ın ve gerçek yolları doğrulayan entegrasyon testlerinin gerekliliğini gösteriyor
- 2017’deki OAuth token kesintisinde olduğu gibi temel bir bağımlılık çökerse yalnızca kullanıcılar değil, içerideki müdahale düzeni de sarsılır; bu yüzden yedek iletişim kanalları ve zarif performans düşüşü gerekir
- Sık rollout’lar, otomatik hafifletme, felaket kurtarma tatbikatları ve donanım çeşitliliği; karmaşık dağıtık sistemlerde MTTR’yi düşürmek ve tekil hata noktalarından kaçınmak için pratik ilkelerdir
Google SRE’nin 20 Yılda Yaşadığı Ölçek Değişimi
- 20 yıl önce Google iki küçük veri merkezi işletiyordu; her veri merkezinde binlerce sunucu vardı ve iki 2.4G ağ bağlantısı halka biçiminde birbirine bağlıydı
- O dönemde operasyonlar büyük ölçüde
Assigner,Autoreplacer,Babysittergibi Python betiklerine ve tek tek sunucu adlarını içeren yapılandırma dosyalarına dayanıyordu - MDB adlı küçük bir makine veritabanı, tekil sunucu bilgilerini düzenlemek ve sürekli güncel tutmak için kullanılıyordu
- Bugün işlem gücü 1.000 kattan fazla, ağ ise 10.000 kattan fazla büyümüş olsa da sunucu başına operasyonel efor azaldı ve servis yığınının güvenilirliği daha iyi hale geldi
- Operasyon araçları, betik koleksiyonlarından servis ekosistemine; oradan da temel güvenilirlik sağlayan entegre platformlara evrildi
YouTube Kesintisinden Çıkan Müdahale İlkeleri
- 2016’da YouTube, dağıtık bellek önbellekleme sistemindeki bir hata nedeniyle 15 dakika süren küresel bir kesinti yaşadı ve video sunma kapasitesi durdu
- Kesinti hafifletme önlemleri, kesintinin ciddiyetiyle uyumlu olmalıdır
- YouTube kesintisi sırasında riskli yük atma (load-shedding) prosedürü sorunu çözmedi, zincirleme arızalar yarattı
- Riskli hafifletme önlemleri en iyi ihtimalle kesintiyi giderir; en kötü ihtimalle yanlış çalışıp kesinti süresini uzatabilir
- Standart prosedürleri atlamayı gerektirecek kadar ciddi bir durumda bile önce ciddiyeti gözlemleyip değerlendirdikten sonra seçim yapılmalıdır
- Kurtarma mekanizmaları gerçek acil durumlardan önce yeterince test edilmelidir
- Kesinti sırasında riskli bir hafifletme prosedürünü ilk kez çalıştırmak, yüksek katlı bir binadaki yangın tahliyesi sırasında merdiveni ilk kez kullanmaya benzer
- Kurtarma prosedürünün gerçekten gereken işi yapıp yapmadığı ve sorumluların nasıl çalıştırılacağını bilip bilmediği önceden doğrulanmalıdır
- Testin kendisi de ilgili önlemi uygularken ortaya çıkacak riski azaltır
- Tüm değişikliklerde etki alanı kanarya dağıtımı ile sınırlandırılmalıdır
- Önbellekleme yapılandırmasındaki değişiklik, beklenmeyen sonuçlar doğurarak YouTube servisini 13 dakika boyunca ciddi biçimde felç etti
- Küresel değişiklik kanarya stratejisi ile kademeli dağıtılsaydı, küresel etki oluşmadan kesinti sınırlandırılabilirdi
- İlgili kaynaklar arasında kanarya stratejisi makalesi ve SREcon sunum videosu bulunuyor
Calendar Kesintisinden Öğrenilen Rollback ve Test Dersleri
- Riskli değişiklikler için önceden tanımlanmış bir Big Red Button gerekir
- Big Red Button, istenmeyen duruma yol açan nedeni geri alan, basit ve kolayca çalıştırılabilen bir güvenlik mekanizmasıdır
- Bir mühendisin, değişiklik yayılmadan önce masaüstü bilgisayarın fişini çekerek büyük bir kesintiyi kıl payı önlediği bir örnek vardı
- Büyük rollout’lar planlanırken “Benim Big Red Button’ım nedir?” sorusu düşünülmeli ve tüm servis bağımlılıkları için acil durumda çalıştırılabilecek bir mekanizma bulunmalıdır
- İlgili bir yazı olarak Generic Mitigations var
- Yalnızca birim testleri yeterli değildir; entegrasyon testleri gerekir
- Birim testleri tek tek bileşenlerin beklendiği gibi çalışıp çalışmadığını doğrular, ancak çalışma zamanı ortamını ve üretim gereksinimlerini tamamen yeniden oluşturamaz
- Entegrasyon testleri, işlerin ve görevlerin cold start yapıp yapamadığını ve bileşenlerin birlikte istenen sistemi oluşturup oluşturmadığını doğrulamak için kullanılır
- Calendar kesintisinde test yolu gerçek kullanım yolundan farklıydı; bu nedenle çok sayıda test olmasına rağmen değişikliğin gerçek dünyada nasıl çalışacağını değerlendirmeye yardımcı olmadılar
2017 OAuth Token Kesintisi ve Operasyon Sürekliliği
- Şubat 2017’de kullanılamayan OAuth token’ları nedeniyle milyonlarca kullanıcı cihazlardan ve servislerden çıkış yaptırıldı; 32.000 OnHub ve Google WiFi cihazı fabrika ayarlarına döndü
- Oturum açma hataları nedeniyle manuel hesap kurtarma talepleri 10 kat arttı ve Google’ın kesintiden tamamen toparlanması yaklaşık 12 saat sürdü
- Kesinti müdahalesinde birincil iletişim kanallarından ayrılmış yedek kanallar gerekir
- O dönemde ekipler kesintiyi Google Hangouts ve Google Meet ile yönetebileceklerini varsayıyordu
- Ancak 350 milyon kullanıcının cihazlardan ve servislerden çıkış yaptırıldığı bir durumda Google servislerine bağımlı olmak uygun değildi
- Bağımlılıkları ayrıştırılmış yedek iletişim kanalları hazırlanmalı ve test edilmelidir
- Servisler istisnai durumlarda da zarif performans düşüşü (graceful degradation) ile çalışmaya devam etmelidir
- Kullanılabilirliği yalnızca “tamamen normal” veya “tamamen durmuş” diye ikiye ayırmak yeterli değildir
- Performans düşüşü modunda bile asgari işlevleri sürdürmek daha tutarlı bir kullanıcı deneyimi sağlayabilir
- Performans düşüşü kullanıcıya görünmeyebilir; servisler istisnai durumlarda da çalışmaya devam edecek şekilde tasarlanmalıdır
Felaketler, Otomasyon, Rollout ve Donanım Çeşitliliği
- Felaket dayanıklılığı ve kurtarma testleri, iş sürekliliği stratejisinin temel unsurlarıdır
- Dayanıklılık testleri, servis veya sistemin arıza, gecikme ve kesinti durumlarında ayakta kalıp kalamayacağını doğrular
- Kurtarma testleri, tam kapanmanın ardından servisin normal duruma dönüp dönemeyeceğini kontrol eder
- Weathering the Unexpected gibi doğal afetler veya siber saldırılar gibi uç durumlar da varsayılmalıdır
- Ekiplerin masaüstü oyun biçiminde “Ağ bağlantılarının bir kısmı beklenmedik şekilde koparsa ne olur?” gibi senaryoları incelemesi de faydalıdır
- Net sinyali olan arızalarda hafifletme otomasyonu, MTTR’yi azaltmanın bir yoludur
- Mart 2023’te birden fazla veri merkezinde birden çok ağ cihazı neredeyse aynı anda arızalandı ve yaygın paket kaybı oluştu
- Bu 6 günlük kesinti sırasında servislerin yaklaşık %70’i konuma, servis yüküne ve ağ arızası anındaki yapılandırmaya bağlı olarak farklı seviyelerde etkilendi
- Etkilenen servis oranı: {p:70}
- Belirli bir arızanın gerçekleştiğine dair sinyal netse, manuel hafifletme adımları otomatik başlatılarak MTTR azaltılabilir
- Bazen önce kullanıcı etkisini önleyip ardından kök nedeni analiz etmek daha iyi olabilir
- Rollout aralığı uzadıkça değişikliğin güvenli olup olmadığını yargılamak zorlaşır
- Mart 2022’de ödeme sistemi kesintisi nedeniyle müşterilerin işlemleri tamamlaması engellendi ve Pokémon GO Community Day ertelendi
- Neden, tek bir veritabanı alanının kaldırılmasıydı; kodda bu alanın kullanımı kaldırıldığı için değişiklik güvenli görünüyordu
- Ancak sistemin bazı bölümlerindeki yavaş rollout döngüsü nedeniyle canlı sistem hâlâ bu alanı kullanıyordu
- Karmaşık, çok bileşenli sistemlerde uzun rollout gecikmeleri, belirli bir değişikliğin güvenliğini değerlendirmeyi çok zorlaştırır
- Uygun testlerle birlikte sık rollout yapmak, bu tür beklenmeyen arızaları azaltabilir
- Tek bir küresel donanım sürümü tekil hata noktası haline gelebilir
- Kritik bir işlevi yalnızca tek bir model ekipmana bırakmak operasyon ve bakımı basitleştirebilir
- Ancak o modelde sorun çıkarsa bu kritik işlev artık yerine getirilemez
- Mart 2020’de, keşfedilmemiş bir zero-day hatası bulunan ağ ekipmanı, trafik desenindeki değişimle hatayı açığa çıkardı; aynı model ve sürüm ağ genelinde kullanıldığı için kayda değer bölgesel kesintiler yaşandı
- Birden fazla ağ omurgası bulunduğundan, yüksek öncelikli trafik hâlâ çalışan alternatif rotalara gönderilebildi ve tam kesinti önlendi
- Kritik altyapıdaki olası hatalar, görünüşte zararsız bir olay yaşanana kadar gizli kalabilir; çeşitli bir altyapıyı korumak, sorunlu bir kesinti ile tam kesinti arasındaki farkı belirleyebilir
1 yorum
Hacker News yorumları
Yazı harika ve geniş ölçekte uygulanabilir görünüyor. “Bu ancak Google’da geçerli olur” denecek pek bir tarafı yok.
İletişim kanalları, yedek kanallar, hatta o yedek kanalın da yedeği gerçekten çok önemli. Netflix’te, kesinti sırasında kullanılacak sistemin tedarikçisini seçerken AWS üzerinde çalışmadığından her zaman emin olurduk; reddit’te ise normalde kullandığımız IRC çalışmadığında diye ofis sunucusunda yedek bir IRC bulundururduk.
Google’ın da AWS’te yedek bir IRC sunucusu olduğu söylenirdi; bu sadece bir efsane de olabilir. Asıl mesele, kendi altyapınızdan olabildiğince bağımsız bir ikincil iletişim kanalı bulundurmak.
O ekip kritik yol üzerindeydi; eğer bizim sistemimiz yüzünden çağrı geldiyse, yalnızca Google Meet’in değil Google.com’un da aynı anda çökmüş olma ihtimali hiç de düşük değildi. Gmail yüzünden e-posta da yoktu, Google Fi olduğu için iş telefonu da yoktu, evdeki ISP de Google Fiber/Webpass olduğundan ek yedek katmanlar gerekiyordu.
Bu yüzden Google’da iletişim için gerçekten yedek IRC sunucusu var. Konumunu söylemeyeceğim ama tam da bu nedenle açıkça Google altyapısının dışında tutuluyor.
“Geniş ölçekte uygulanabilir ve yalnızca Google’a özgü değil” kısmı açısından, başka yerlerde neredeyse hiç görmediğim şey operasyon panik odasıydı. Operasyon ortamına giden yedek VPN’i olan güvenli bir oda anlamına geliyor.
Bir gün operasyon SAN’inde sorun çıkınca on-premise veri merkezi çöktü ve Atlassian da onunla birlikte öldü. Jira yok, Confluence yok, muhtemelen CI/CD de yoktu; düzenli kurtarma prosedürleri olmadan geriye sadece kabile bilgisi kalmıştı.
İnsanlar öfkelendi, haklıydılar da. Müşteriye dönük sistemlerle altyapı sistemlerini aynı sepete koymak gerçekten tehlikeli.
En azından 2 yıl önce hâlâ orada çalışırken durum böyleydi.
Bir gün tam cold start sorununun çözümünü duymak isterim. Devasa kendi stack’lerine sahip şirketlerde çekirdek altyapıda döngüsel bağımlılıklar var.
Yazılım tanımlı ağlarda paket yönlendirmeyi yeniden başlatmak için bazı yazılımların ayakta olması gerekir; disksiz makinelerin boot etmek için depolamaya ihtiyacı vardır; kimlik doğrulama servisleri de güvenli yetkilendirmeyi bootstrap etmek için depolama erişimine ihtiyaç duyar.
Şu anda bu, birden fazla bağımsız region işletip tamamen kapanmış bir veri merkezini mevcut altyapıdan bootstrap ederek ele alınıyor. Ama tüm stack’in tamamen enerjisi kesilmiş durumdan tekrar ayağa kaldırıldığını hiç duymadım.
Birkaç yıl önce Facebook operasyon ağını tamamen bozduğunda bile makineler açıktı ve iç bağlantının bir kısmı hâlâ vardı. Büyük ölçekli bir güneş fırtınası gibi bir olayla elektrik şebekesi dünya genelinde uzun süre çöker ve jeneratörler bile tükenirse, AWS veya GCP gibi bulutların mutlaka geri döneceğinin garantisi yok.
Muhtemelen üstün yedek güç kaynaklarına ve şebeke dalgalanmalarından tamamen izole olabilme yeteneğine sahip küçük, özel veri merkezleri vardır.
Stack’in üst tarafında, kütüphane yazarlarının sessizce eklediği bağımlılıkları izlemek için yararlıydı; alt tarafında ise tabanda olması gereken şeylerin gerçekten tabanda kaldığını garanti etmeye yardımcı oluyordu.
Belgelenmiş prosedürlerin eskimemesi için sanal otomatik cluster başlatma/kapatma da yapılıyordu; SRE olarak geçirdiğim 6 yıl boyunca bu prosedürün 90 günden 1 saatin altına indiğini gördüm.
Fiziksel nesne gerektiren global şifreleme anahtarı yönetimi gibi şeyleri de sıfırdan yeniden başlatma tatbikatları düzenli olarak yapılırdı; yıllık DiRT tatbikatları ise herhangi bir kişinin, ekibin ya da ofisin sistemin sürekli çalışması için zorunlu koşul hâline gelmediğinden emin olmayı amaçlardı.
Geç başlanırsa çok acı verici olur; ama en baştan böyle yapılırsa hızla alışılır ve kırıcı değişiklikler ya da garip bağımlılıklar erken yakalanır.
Donanıma da uygulanabilir. Bir şeyin fişinin çekilmesi ya da sıfırlanması durumuyla başa çıkacak şekilde mimari değişir. Daha fazla otomasyon, sürüm yönetimi ve değişiklik yönetimi gerekir; bunun sayesinde yalnızca arıza önleme ve hızlı kurtarma değil, tüm işler de hızlanır ve basitleşir. Büyük bir kültürel değişimdir.
Hatırladığım kadarıyla yaklaşımın bazı bölümleri hassas bilgi sayılıyor, bu yüzden daha fazla ayrıntı vermeyeceğim.
Hangi elektrik şebekesinin en çok cold start yaptığı da ilginç olurdu. İdeal olarak böyle bir yerin bunu zaten iyi yapıyor olması gerekir. Karayipler’de ya da Afrika’da bir yer olabilir gibi geliyor.
Ancak küçük bir şebekenin cold start’ı, örneğin bir dizel jeneratör ve güneş enerjisi olan uzak bir ada, fazla kolay olduğundan iyi bir vaka çalışması olmayabilir.
İnternetin kendisinin AC elektrik şebekesi gibi cold start yapılamayacağı açık. Çok fazla AS var. AS’nin ne anlama geldiğini bir an düşünürseniz, koordineli ve önceden prova edilmiş bir cold start’ın neden imkânsız olduğunu anlarsınız.
Bu konuyu daha derinlemesine incelemek isteyenler için, Google’ın Building Secure and Reliable Systems kitabını neredeyse bitirmek üzereyim; hafif bir okuma değil, doğru düzgün bir ders kitabına daha yakın.
Oldukça ilginç bir kitap; içeriğin çoğu sağduyu gibi görünüyor ama “sağduyu” ifadesinin kendi içinde çelişkili olduğu da söylenir ya, tüm bilgiyi tek seferde tazelemek için faydalı oldu.
Son dönemde bazı şirketlerin SRE organizasyonlarını kapatıp çalışanlarını SWE ekiplerine taşıdığına dair şeyler duydum. LinkedIn, Adobe ve Robinhood’un bunu yaptığı söyleniyor.
Bu da bana SRE’nin kolay paranın bol olduğu balon ekonomisinin bir yan ürünü olup olmadığını düşündürüyor. Büyük maliyetle ayrı bir SRE ekibi bulundurmadan operasyon yürütmek mümkün değil mi?
Sistem yöneticilerinin ya da QA test uzmanlarının büyük ölçüde ortadan kaybolup birçok işlevin yazılım geliştirme ekiplerine geçtiği gibi, 10 yıl sonra SRE’nin hâlâ var olup olmayacağını merak ediyorum.
Ama şu anda işten çıkarmaların sürdüğü bir dönemdeyiz; bu noktayı önemseyen şirket sayısı fazla değil. Geliştiricilerin uzmanlık alanı olmasa da onları sorunların üzerine sürme eğilimi ortadan kalkmayacak bir sektör trendi ve ekonomik durgunluk dönemlerinde daha da belirginleşecek.
Full-stack geliştiriciler, iki rolü birleştirip ücretini iki katına çıkarmamanın iyi bir örneği.
Yine de kalan ana fikre katılıyorum. Günümüzde DevOps nedeniyle geliştiricilerden beklenen yetkinlikler genişledi ve SRE ile ciddi ölçüde örtüşüyor. Şirketler SRE ekiplerini küçültüp sorumluluğu geliştiricilere dağıtma eğiliminde olabilir.
Bir diğer büyük neden de otomasyon. Bağlantısı verilen siteyi uzun süre okursanız, Google’ın ilk dönemlerinde SRE’lerin grafikleri elle izleyerek dağıtım yapmak gibi çok sayıda manuel iş yaptığını görebilirsiniz.
O dönemde Google bile sistem otomasyonunda yeterince ileride olmadığı için SRE şarttı. Sisyphus hikâyesine https://www.usenix.org/sites/default/files/conference/protec... bakarsanız, Google’ın standartlaştırılmış otomasyonu ilk kez devreye almada başarısız olmasının SRE’nin iş güvencesini nasıl sağladığını bir ölçüde anlayabilirsiniz.
Yazdığı yazılımın operasyonunu başka birine devretmek mantıklı değil. SWE’leri on-call rotasyonuna koyarsınız, olur biter. Manuel işin en iyi yöntem olduğunu düşünüyorlarsa kendileri yapsınlar; o seviyedelerse de kötü mühendis sayılıp işten çıkarılmalılar.
Mülakatlar bu kadar zorlayıcıyken, insanın programlama yaptığı bilgisayarın nasıl çalıştığını bilmemesi tuhaf. İşletim sistemlerinin işleyişi gibi konular lisans eğitiminde bile var; bunu, çoğu zaman kendi kendine öğrenmiş sistem yöneticisi kökenli kişilerin yoğun olduğu rollere ve unvanlara havale etmek de garip.
Tanıdığım iyi SWE’lerin hepsi işletim sistemlerinin, bilgisayarların ve ağların nasıl çalıştığını biliyordu.
SRE’nin bugün yaptığı genel otomasyon, geliştirici araçları sağlama ve geliştirici deneyimini iyileştirme gibi işler platform ekiplerine kayıyor. Rolün ileride ciddi biçimde değişeceğini düşünüyorum.
Tek bir SRE ekibi birden fazla geliştirme ekibini destekleyebilir; geliştirme ekipleri de çoğu zaman karmaşık altyapı ya da dağıtık sistem tarafına çok az zaman ayırır. Çünkü bu, günlük olarak dert ettikleri bir alan değildir.
Bu yüzden uzmanlaşmış geliştirme ekiplerinden farklı bir birim olarak hareket eden bir altyapı organizasyonunun olması mantıklı. Buna SRE deyin, SRE SWE ekibi deyin ya da sadece altyapı deyin; belirli bir ölçeğin üzerinde ekipleri kesen çok sayıda ortak konu ortaya çıkar ve bunları böyle ayırmak daha ucuz hale gelir.
Özel SRE’ler olduğunda operasyon, ilgili sistemler, araçlar ve uyarılar konusunda gerçekten uzman kişileriniz olur; sonuçlar için de net bir sorumluluk oluşur. Ancak bakımını yaptıkları sistemin kendisine tamamen sahip olmadıkları için organizasyonel sorunlar çıkabilir.
“Biz X’i yayınlamak istiyoruz ama SRE karşı çıkıyor” ya da bunun tersi yaşanabilir; ayrıca SRE olmayan kişiler, desteklemesi zor kodların sorumluluğunu üstlenmeyebilir.
Buna karşılık SRE’siz mühendislik ekipleri bu tür organizasyonel ve sosyal sorunları azaltabilir; fakat operasyonel güvenilirlik birçok öncelikten yalnızca biri haline gelir.
Pratikte bence birçok şirket, güvenilirliği bir iş sonucu olarak çok da önemli görmemeye karar veriyor. Özellikle özellik geliştirme fırsat maliyeti yükseldiğinde bu daha da geçerli oluyor.
Otomatik hafifletme gerçekten uzun uzun düşünülmesi gereken bir konu. 30 yıllık kariyerimde otomatik hafifletmenin sorunu daha da kötüleştirdiğini defalarca gördüm. Bu yüzden kendi kendini iyileştirmenin gerçekten gerekli olup olmadığını dikkatle tartmak gerekir
2014’te şirket içi kullanım için bir mobil çökme raporlama çözümü yaptım; arka ucun bir kısmı Redis’i tek hata noktası olarak kullanan tek bir sunucuda çalışıyordu. Failover süreci yarı otomatikti; bir kişinin uyarının geçerli olduğunu doğruladıktan sonra başlatması gerekiyordu
Çökse bile gerçek bir parasal kayıp yoktu; en kötü durumda mobil uygulama geliştiricileri bir süre rahatsızlık yaşayacaktı. 10 yıl boyunca işletirken failover yapmamız gereken durumları iki parmağımla sayabilirim
SLA’sı olmayan bir sistem olmasına rağmen, çok daha önemli iç sistemlerden daha iyi çalışma süresine sahipti
Tersine örnek olarak GitHub vakalarına bakılabilir: https://github.blog/2023-05-16-addressing-githubs-recent-ava..., https://github.blog/2018-10-30-oct21-post-incident-analysis/, https://www.datacenterknowledge.com/archives/2012/12/27/gith...
Elbette GitHub çok daha büyük ölçekte çalışıyor. Mesele şu: yedeklilik ve otomatik hafifletme karmaşıklık ekler ve tanımı gereği, neredeyse hiç test edilmemiş halde öngörülemeyen durumlarda devreye girer
Bu yüzden SLA’yı ve kesinti maliyetini değerlendirip, kesintiyi önlemek için eklenecek karmaşıklıkla dengelemek gerekir. Sanırım 1998 civarında iki NetApp’i yüksek erişilebilirlik yapılandırmasında birbirine bağlamıştık; biri arızalanırken diğerindeki tüm diskleri de bozmuştu. Bu benim ilk dersimdi
Benzer bir dönemde iki Cisco PIX güvenlik duvarında da aynı şey olmuştu; o zamandan beri yüksek erişilebilirlik ve otomatik failover/hafifletme konusunda hep temkinli oldum
Pratikte büyük kırmızı düğme ve bilinçli kademeli performans düşürmenin nasıl ele alındığını merak ediyorum. Özellikle sistem sorun yaşarken bunların çalışmaya devam etmesi nasıl garanti ediliyor, bunu merak ediyorum
Örneğin veritabanı tabanlı feature flag’ler mi kullanılıyor; öyleyse veritabanının kendisi ya da erişim API’si aşırı yük altındayken ne yapılıyor?
Yoksa ortam değişkenleri gibi statik başlangıç bayrakları mı kullanılıyor; bu durumda yeterince hızlı dağıtılmaları nasıl garanti ediliyor? Ya da tamamen farklı bir yöntem mi var?
Kritik yolun bazı kısımlarında yedeklilik kullanmasanız bile, sistem tüm bakım yapanların zihnine sığacak kadar basit ve kolayca yeniden başlatılıp geri alınabilir durumdaysa, bu daha iyi olabilir
Ancak şirket “beş dokuz çalışma süresi” gibi garantiler vermeye başladığında, bu garantileri korurken geliştirme ve iyileştirmeyi sürdürebilecek sistemler tasarlamak için bir miktar karmaşıklık gerekir
Google’da belirli bir kümenin sağlıksız olduğuna karar verildiğinde rutin olarak “backend drain” yapılırdı ve API/yük dengeleyici katmanında bunu hızlıca ele alan bir sistem vardı
Başka yerlerde bunun uygulama düzeyi flag’lerle yapıldığını da gördüm.
kubectl edityapmak gibi; açıkçası ideal değil ama çalışıyorduBirincisi, basit tutmak gerekir. Karmaşık mantık ya da karmaşık veri depoları olmadan, flag’i basitçe kontrol etmek yeterli olmalı
İkincisi, mümkün olduğunca kaynağa yakın tutmalı ama istemcilere fazla güvenmemeli. Eski sürümler, yayılım gecikmeleri ve hatalar olabilir; bu yüzden hem istemci hem de sunucu tarafında düşürülmüş modu seçebilmek iyidir. Sadece biri mümkünse sunucu tarafı daha iyidir
Üçüncüsü, gerçek trafikle sık sık test etmek gerekir. Test ortamına güvenmeyin; %0,1 gibi küçük ölçekli periyodik testler ve planlı büyük ölçekli testler yapılmalı. Test etmediyseniz ihtiyaç duyduğunuzda çalışmaz; bir yıl önce çalıştıysa bugün çalışmama ihtimali yüksektir. Test edilmemiş mekanizmalar çözümden çok zarar verebilir
Örneğin Hacker News’e yorumların yanında profil fotoğrafı gösteren yeni bir özellik eklediğimizi varsayalım. Elbette her şeyi mikroservis yaptığımız için, frontend sayfa oluşturucusunun profil servisine çağrı gönderdiğini, profil servisinin de sorgulayıp görselin konumunu döndürdüğünü varsayalım
Yayın planının bir parçası olarak, yeni bileşen profil servisini ya da görsel depolamayı aşırı yüklerse izlenecek büyük kırmızı düğme prosedürünü belgelendiririm. Yani ağ katmanında servisimin dış istek hızını sınırlayan komutu çalıştırırım; acil durumda muhtemelen 0’a çekerim
Sorgu başarısız olur, ama sayfa oluşturucu kademeli olarak düşürülmek üzere tasarlanmıştır; yorum metnini profil fotoğrafı olmadan render etmeye devam eder
Bu gerçek bir tasarım dokümanı değil, bir şeyi nasıl inşa etmeniz gerektiğine dair tavsiye de değil; sadece noktayı anlatmak için çizilmiş bir karalama
djb’nin CDB’si (constant database) ile de yaptık; JSON yapılandırma dosyalarını API üzerinden polling’le alma ya da dbm/gdbm/Berkeleydb/leveldb kullanma örnekleri de gördüm
Bu yöntem başka büyük kırmızı düğmelere de genişletilebilir. Zarif değil ama health check sunup sunmayacağına karar vermek için dosya varlığını kontrol eden servisleri birçok kez işlettim. Bir düğümü yük dengeleyici rotasyonundan çıkarmak, tek bir dosya oluşturmak kadar kolaydı
Esas nokta, veritabanı arızalanırsa sistemin varsayılan olarak son doğrulanmış sağlam yapılandırmayı kullanmasıdır
“Kurtarma mekanizmaları acil durumdan önce tamamen test edilmiş olmalıdır” cümlesini gerçekten vurgulamak istiyorum. Google’da beklenmedik şekilde SRE olmuş ve çifte olumsuzluğu yanlış kullanarak şirket çapında tanınmış biri olarak, bu doğrudan doğruya düzgün yapılması gereken çok önemli bir iş
Merak eden Googler’lar içerde kullanıcı adımı ararsa, ölçülemeyecek kadar büyük bir etkiyi nasıl yarattığımı bulabilir
Arızaları önlemenin en ucuz yolu, onları yaşam döngüsünün erken aşamalarında yakalamaktır. Yazılım hataları gerçek böceklere benzer. Başlangıçta yumurtadırlar, yani bir değişiklik fikri; yumurtadan çıkan nimf ise ilk POC’dir. Üretim ortamına ulaştığında artık yetişkin böcek olmuştur.
Yetişkin olmadan önce başka aşamalar yok mu diyebilirsiniz. Doğru. Bir uygulamanın olgunlaşmadan önce birkaç aşamadan geçmesi gerekir. Hata iyice büyüyüp yumurtlamadan önce onu bulmak çok daha ucuzdur.
Canary dağıtımı zorsa ve geri alma da sorunluysa, üretim dağıtımından önce daha fazla test eklemek gerekir. Linter’lar, birim testleri, uçtan uca testler, profiler’lar, sentetik monitor’lar, salt okunur üretim replikaları, performans testleri vb. mümkün olan en fazla yöntemle hataları erken yakalamak gerekir.
Feature flag’ler, geriye dönük uyumluluk vb. de faydalıdır, ancak Shift Leftin yerini tutamaz.
FinTech, bankacılık, hedge fonlar ve kripto para alanlarında 15 yıl SRE yapmış bir bakış açısından benzer bir liste ilginizi çekerse şu yazıyı öneririm: https://x.com/alexpotato/status/1432302823383998471?s=20
Tadımlık: “25. Filtre koşullarıyla mevcut bir kuralı bulmaktansa yeni bir kural oluşturmanın daha kolay olduğu bir kural motorunuz varsa, sonunda bir sürü yinelenen kuralınız olur.”
“Arızaya yol açmak üzere olan bir değişikliği gönderen mühendis, değişiklik yayılmadan önce masaüstü bilgisayarının fişini çekerek büyük bir arızayı kıl payı önledi” derken bu ne anlama geliyor?
Bunun sonucu olarak altyapı SWE’leri gerçek düğmeler yapmak yerine bütün gün aptal CLI’lar yazmak zorunda kaldı. Ben ayrılırken bu durum epey değişmeye başlamıştı gerçi.
Bence Google’ın iç arızaları daha fazla kamuya açması gerekir. Bu arıza özellikle içeride çok meşhurdu.
Muazzam ölçekte bile shell araçları ve RPC client CLI’ları dünyadaki tüm makinelere oldukça hızlı biçimde temas edebilir.
psshtarzı bir yardımcı araçla yaptığımı hatırlıyorum.10 yıl önceydi; hâlâ böyle kullanılıyor mu bilmiyorum ama o yöntem şaşırtıcı derecede hızlıydı. Bu da o türden bir şey olmuş olabilir.
Ama 20 yıl önce bu daha yaygındı; bugün bile küçük organizasyonlarda hâlâ yaşanabilir.