S&P Global’s innovative disaster recovery strategy using Amazon FSx for NetApp ONTAP snapshots · Nishanth Charlakola
Kuruluşların karmaşık SQL Server altyapıları için yüksek erişilebilirlik ve felaket kurtarma (HA/DR) çözümleri kurma zorunluluğu var — veri erişilebilirliğini ve bütünlüğünü korumak için. S&P Global Market Intelligence, Capital IQ platformu için bunu Amazon FSx for NetApp ONTAP üzerine kurmuş.
Çözümün en öğretici kısmı ikili bir seçim yerine ara bir mod sunması: ikincil bölgede salt-okunur moda anında failover (failover). Yani felaket anında sistem ya tamamen çalışıyor ya tamamen kapalı değil — okuma yapılabilen, yazma yapılamayan bir orta hâlde ayakta kalıyor.
Bu ayrım pratikte çok değerli. Çoğu iş yükünde okuma trafiği yazmadan kat kat fazladır; salt-okunur bir sistem kullanıcıların büyük kısmına hizmet vermeye devam eder. Ayrıca yazmayı kapatmak, split-brain (split-brain) riskini ortadan kaldırır — iki bölge aynı anda yazarsa veriyi uzlaştırmak çok daha zor bir problemdir.
Yazı ayrıca bulut göçlerinde kavram kanıtının (POC) rolüne değiniyor: standart belirlemek, riski azaltmak ve hızı korurken iş ve teknik doğrulama yapmak.
Öne çıkanlar
- "Açık ya da kapalı" yerine kademeli hizmet seviyeleri tasarlamak, dayanıklılığın en pratik biçimi.
- Snapshot (snapshot) tabanlı replikasyon, tam yedekten çok daha hızlı failover sağlıyor.
- Salt-okunur failover, veri tutarlılığını koruma açısından da güvenli: çift yazma riski yok.
Neden önemli?
Felaket kurtarma planı olmayan sistem, sadece henüz felaket yaşamamış sistemdir. Ama iyi bir DR planının işareti "her şeyi yedekliyoruz" değil, RTO ve RPO hedeflerinin açıkça tanımlanmış olmasıdır: ne kadar sürede ayağa kalkmalıyız ve en fazla ne kadar veri kaybını kabul ediyoruz? Bu iki sayı verilmeden yapılan yatırım, ya yetersiz ya da gereksiz pahalı olur.
Pratikte
Bu iki kısaltmayı ezberle, mülakatta çıkar: RTO (Recovery Time Objective), kabul edilebilir kesinti süresi; RPO (Recovery Point Objective), kabul edilebilir veri kaybı. Kendi uygulaman için sor: veritabanı bozulursa kaç saatlik kullanıcı verisini kaybetmeyi göze alabilirsin? Cevap ‘hiç’ ise sürekli replication gerekir, ‘bir gün’ ise günlük backup yeterlidir ve maliyet farkı büyüktür. Bir de şunu yap: backup’tan geri dönmeyi bir kere gerçekten dene. Test edilmemiş backup, backup değildir; bunu felaket anında öğrenmek en pahalı öğrenme biçimidir.
Sözlük
- failover
- Ana sistem çalışamaz hâle geldiğinde hizmetin yedek sisteme geçirilmesi.
- RTO / RPO
- RTO ne kadar sürede ayağa kalkılacağını, RPO en fazla ne kadar veri kaybının kabul edildiğini tanımlar.
- split-brain
- İki node’un birbirini görmeyip ikisinin de kendini lider sanması; çelişkili yazmalar üretir.
- snapshot
- Bir depolama biriminin belirli bir andaki durumunun hızlıca alınan kopyası.
The power of collaboration: How we can reduce traffic congestion
Google Research, Nature Cities'te yayımlanan çalışmasında navigasyon platformlarının trafiği iyileştirmek için kullanılmasına dair ilk büyük ölçekli gerçek dünya araştırmasını sunuyor. Bulgu: sürücülerin küçük bir kısmını bile koordine etmek ağ verimliliğini iyileştiriyor.
Yazının açtığı soru bir mühendis için çok tanıdık: karayolu trafiği, havacılığın hava sahasını ya da internetin veri paketlerini yönettiği gibi sistem çapında yönetilebilir mi? Kara ulaşımının tarihsel olarak fiziksel bir kontrol kulesi olmadı, ama dijital platformlar daha koordineli bir geleceğin kapısını aralıyor.
Altta yatan kavram bilgisayar biliminde iyi bilinen bir sonuç: her aktör kendi için en iyi yolu seçtiğinde ortaya çıkan denge, sistem için en iyi çözümden daha kötü olabilir.
Öne çıkanlar
- Bireysel optimum ile toplam optimum aynı değil — trafikte, ağ yönlendirmesinde ve kaynak paylaşımında hep böyle.
- Küçük bir azınlığı koordine etmek bile ölçülebilir kazanç veriyor; herkesi ikna etmek gerekmiyor.
Pratikte
Bu, dağıtık sistemlerde doğrudan karşına çıkacak bir olgu. Klasik örnek: bir servis hata alınca hemen yeniden dener. Her istemci için makul olan bu davranış, hepsi aynı anda yaptığında zaten zorlanan sunucuyu tamamen düşürür — retry storm. Çözümler tam olarak "koordinasyon" fikrinden geliyor: exponential backoff, rastgele jitter eklemek ve circuit breaker (circuit breaker). Kod yazarken "benim isteğim için en iyisi ne?" yerine "herkes bunu yaparsa ne olur?" diye sormayı alışkanlık hâline getir — bu tek soru, ölçeklenebilir sistem tasarımının önemli bir kısmını kapsıyor.
Sözlük · 3 terim
- selfish routing
- Her aktörün yalnızca kendi maliyetini düşünerek yol seçmesi; toplam verimliliği düşürebilir.
- retry storm
- Çok sayıda istemcinin aynı anda yeniden denemesiyle zaten zorlanan sistemin tamamen çökmesi.
- jitter
- Yeniden deneme sürelerine eklenen rastgelelik; istemcilerin aynı anda tekrar denemesini önler.
Australian Payments Plus moves faster with ChatGPT and Codex
Australian Payments Plus (AP+) Avustralya'da ödeme ve kimlik altyapısı işletiyor. Ekipleri şema kuralları, teknik spesifikasyonlar, üye yükümlülükleri, operasyonel süreçler, siber güvenlik ve düzenleyici beklentiler arasında çalışıyor — hızın önemli olduğu ama doğruluk ve hesap verebilirliğin daha önemli olduğu bir alan.
Paylaşılan en somut örnek bir debugging vakası: bir reconciliation (reconciliation) sorununda ekipler, sistem logları ve reconciliation verisi arasında ince bir timestamp tutarsızlığını izlemek için Codex kullanmış. Günlerce sürebilecek elle inceleme 30 dakikaya inmiş — önceki süre 4 saat olarak veriliyor.
Diğer sayılar: çalışanların %77'si haftada 2+ saat tasarruf bildiriyor, %80'i yaratıcılık ya da iş kalitesinde iyileşme belirtiyor.
Öne çıkanlar
- En değerli kullanım karmaşık yaratıcı iş değil, sıkıcı ve hacimli iş: çok sayıda log satırında bir tutarsızlık aramak.
- Ödeme sistemlerinde timestamp tutarsızlıkları klasik bir hata kaynağı — saat dilimi, clock skew, sıralama.
Pratikte
Buradaki hata sınıfını tanı: timestamp tutarsızlığı. Borsa saati mi, sunucu saati mi, UTC mi? Kural basit ama sürekli ihlal edilir: her timestamp’i UTC olarak sakla, yalnızca gösterirken yerel saate çevir. PostgreSQL’de timestamptz kullan, timestamp değil; Java’da Instant kullan, LocalDateTime değil. İkinci ders LLM kullanımıyla ilgili: modeli ‘bana kod yaz’ için değil, ‘bu 50.000 satır logda tutarsızlığı bul’ için kullanmak çok daha yüksek getirili. İnsanın sıkıldığı, makinenin sıkılmadığı işler.
Sözlük · 3 terim
- reconciliation
- İki ayrı sistemin kayıtlarının birbirini tutup tutmadığının karşılaştırılması (ör. banka kaydı ile iç kayıt).
- clock skew
- Farklı sunucuların saatlerinin birbirinden sapması; olayların yanlış sırada görünmesine yol açar.
- UTC
- Saat dilimlerinden bağımsız evrensel zaman standardı; veri saklamanın doğru birimi.