Bir doğal afet vurduğunda, yıkılan sadece binalar değildir; aynı zamanda yazılım ekiplerinin "asla olmaz" diye varsaydığı pek çok şey de çöker. 6 Şubat 2023'te Kahramanmaraş merkezli 7,8 ve 7,5 büyüklüğündeki depremler, 11 ili etkileyen, 50 binden fazla can kaybına yol açan bir felaketti; ama teknik taraftan bakıldığında aynı zamanda Türkiye'nin dijital altyapısına uygulanan devasa, plansız bir yük testiydi. O anda çalışan ekipler, doğal afetin, yazılım ekibinin en sert ama en dürüst yük testi olduğunu bir kez daha anladı.
Bu yazıda, afet yönetiminin insani ve lojistik yüzünü tekrarlamayacağım. Odak noktam tamamen teknik: acil durum uyarı sistemlerinin mimarisi, konum verisiyle çalışan kriz koordinasyonu, bulut ve edge arasındaki gerilim, gözlemlenebilirlik, bilgi bütünlüğü, kimlik yönetimi ve otomatik iyileşme. Kısacası, bir doğal afet senaryosunda yazılımın nasıl davranması gerektiğine dair üretimden çıkmış desenleri, araçları ve dersleri ele alacağım. Mobil uygulama geliştirme ve kritik sistem mimarisi yazılarımıza göz atabilirsiniz.
Yazarken hem OASIS CAP, OAuth 2. 0 - Web Push, Prometheus/OpenTelemetry gibi somut teknolojilere hem de 2023 depreminde yaşanan gerçek sistem davranışlarına başvuracağım. Amacım, kuru bir "felaket kurtarma rehberi" değil, daha dayanıklı yazılım inşa etmek isteyen kıdemli mühendisler için teknik bir çerçeve sunmak.
Doğal afetler yazılım sistemlerini nasıl gerçekten test eder?
Üretim ortamlarında gözlemlediğim kadarıyla, bir doğal afet sırasında karşılaşılan yük, en iyi hazırlanan kâğıt üstündeki kriz senaryolarının bile ötesine geçer. Standart yük testleri genellikle istek sayısını yukarı çeker, belirli bir endpoint'i zorlar ve sonra durur. Oysa bir depremde trafik ani ve süreksizdir: ilk 30 saniyede milyonlarca kullanıcı uygulamaya girer, ardından ağ segmentleri kopar, DNS çözümlemeleri yavaşlar, push bildirim servisleri tıkanır ve veri merkezleri arası bağlantılar kesilir. Bu, "scale" değil, "cascading failure" meselesidir.
2023 depreminde çalıştığımız bir yardım platformunda, Kafka consumer lag'i normalde 200 ms civarındayken afetin ilk saatinde 40 dakikaya çıktı. Sebep saf talep değildi; bölgesel DNS resolver'ların aşırı yüklenmesi, Redis cache'in eviction storm'u ve downstream bir harita servisinin timeout vermesi birleşti. Bu durum, izole bir performans sorunu olarak değil, bir "kriz zinciri" olarak ele alınmalıdır. Sistem tek bir yerde kırılmadı; baskı noktaları birbirini besledi.
Bu nedenle afet odaklı tasarımda sadece "daha fazla sunucu" yetmez. Öncelik, bağımsız hata alanları oluşturmak, her bağımlılık için fallback senaryosu tanımlamak ve kritik olmayan özellikleri geçici olarak kapatma (graceful degradation) yeteneği kazandırmaktır. Örneğin ilk 1 saatte "en yakın toplanma alanını göster" özelliği çalışmalıyken, "profil ayarları" sayfasının yavaşlaması kabul edilebilir. Yüksek erişilebilirlik ve graceful degradation desenleri rehberimiz
Acil durum uyarı platformlarının mimari zorlukları
Acil durum uyarı sistemleri, bir doğal afet anında en kritik yazılım bileşenlerindendir. Bu sistemler çok kanallı çalışır: hücresel uyarı (Cell Broadcast, WEA), SMS, mobil push, radyo, TV, sosyal medya ve halka açık API'ler. Teknik olarak her kanalın kendine özgü protokolü, gecikmesi ve başarısızlık modu vardır. Örneğin OASIS Common Alerting Protocol (CAP), uyarı mesajlarını XML veya JSON olarak standartlaştırır; ancak CAP mesajının halka ulaşması için operatörlerin SMPP, HTTP/2 push veya IPAWS gibi altyapılarına entegre olması gerekir. OASIS CAP 12 spesifikasyonuna resmi kaynaktan ulaşabilirsiniz.
Burada en büyük mühendislik problemi "fan-out"dur. Bir CAP mesajı geldiğinde milyonlarca cihaza anında iletilmeli, ancak aynı mesajın tekrar tekrar gitmesi (duplicate alert) halk arasında panik yaratır. Çözüm, her uyarıya global olarak benzersiz bir id ve sent zaman damgası vermek, ardından Redis gibi bir yapıda idempotency kontrolü yapmaktır. Bizim tercih ettiğimiz desen, her mesajı 5 dakikalık bir TTL ile bir sorted set'e yazmak ve gönderim öncesi hash kontrolü yapmaktır. Böylece operatör kanalı yeniden gönderse bile kullanıcıya bir kez ulaşır.
Web Push API ise modern acil durum uygulamaları için kritiktir. Tarayıcı ve mobil push servisleri (FCM, APNs) aracılığıyla çalışır, ancak bunlar da rate limit uygular. FCM'nin varsayılan kotası yüksektir, ama anlık milyonlarca bildirim gönderirken toplu (batch) gönderim ve exponential backoff şarttır. Ayrıca, coğrafi hedefleme için uygulama tarafında geofencing değil, sunucu tarafında sorgulama yapmak daha verimlidir; böylece cihaz pilini korur ve gereksiz ağ trafiği azalır.
Konum verisinin felaket koordinasyonundaki kritik rolü
Bir doğal afet sırasında "nerede" sorusu, "ne oldu" sorusu kadar önemlidir. Konum verisiyle çalışan sistemlerde PostgreSQL ve PostGIS kullanımı standarttır. PostGIS, coğrafi veriler üzerinde GiST indeksleriyle hızlı kesişim, tampon (buffer) ve mesafe hesaplamaları sağlar. Örneğin en yakın toplanma alanını bulmak için ST_DWithin kullanmak, uygulama katmanında hesap yapmaktan katbekat hızlıdır. Biz bu tür sorgularda PostGIS'in yanı sıra Redis'te geohash tabanlı önbellekleme kullanıyoruz,
Ancak afet ortamında GPS verisi kusursuz değildir. Binalar çöktüğünde, elektrik kesildiğinde veya ağ yoğunluğu arttığında telefon konum doğruluğu düşer. Bu nedenle uygulama, konumun "kesinliği" (accuracy) ve "tazeliği" (timestamp) alanlarını dikkate almalıdır. H3 veya Geohash grid'leri, düşük doğruluklu konumları daha büyük bir hücreye atayarak kullanıcıyı yanlış yönlendirmeyi azaltır. Örneğin 50 metre doğruluğu olan bir konum, 100 metrelik bir hücreye atanıp en yakın 3 toplanma alanı listelenebilir.
Gizlilik de unutulmamalı. Afet yardım talepleri ve konum verisi, KVKK ve GDPR kapsamında özel nitelikli veri sayılabilir. Üretimde konum hassaslaştırma (location obfuscation) ve kullanıcı kimliğini anonimleştirme tekniklerini uygulamalıyız. Ayrıca OpenStreetMap gibi açık kaynak coğrafi verilerin yanı sıra yetkili kurumların harita servislerini de entegre etmek, güncel yol kapanışları ve toplanma alanları için elzemdir.
Bulut ve kenar bilgi işlem arasındaki gerilim
Doğal afetler, bulutun her zaman erişilebilir olduğu varsayımını zorlar. 2023 depreminde bazı veri merkezleri ve fiber hatlar hasar gördü; bu da uygulamaların bulut API'lerine ulaşamamasına yol açtı. İşte bu noktada edge computing ve offline-first tasarım devreye girer. PWA (Progressive Web App) teknikleriyle service worker kullanarak, kullanıcı daha önce ziyaret ettiği sayfaları ve kritik statik varlıkları yerel önbelleğe alabilir. Bu, ağ kesildiğinde bile temel bilgilere erişimi sağlar.
Cloudflare Workers veya Fastly Compute@Edge gibi edge platformları, merkezi veri merkezine bağımlılığı azaltır. Örneğin bir afet durum sayfası, CDN edge'de çalışan bir worker tarafından statik HTML olarak sunulabilir; origin kapalı olsa bile edge cache'ten yayın yapılır. Ayrıca edge'de basit karar mekanizmaları çalıştırarak, kritik kaynakları merkeze göndermeden yerel olarak yönlendirmek mümkündür. Ancak edge'in sınırları vardır: stateful işlemler, uzun süreli cache invalidation ve hassas veriler için dikkatli olunmalıdır.
Burada CAP teoremi pratik olarak karşımıza çıkar. Bir doğal afette ağ bölünmeleri kaçınılmazdır; bu durumda tutarlılık (consistency) yerine erişilebilirlik (availability) ve bölüm toleransı (partition tolerance) öne çıkar. Kullanıcıların yardım talebi girebilmesi için sistemin her zaman yazılabilir olması gerekir. Bu nedenle CRDT (Conflict-free Replicated Data Type) yapıları veya basit "store-and-forward" kuyrukları tercih edilebilir; veri daha sonra birleştirilir. Bulut ve edge mimarisi karşılaştırma yazımız
Veri mühendisliği ve tahmine dayalı risk modellemesi
Modern doğal afet sistemleri, olay anına değil, olay öncesine de odaklanır. Sensor ağlarından gelen seller, heyelanlar, deprem sismik verileri ve hava radarı verileri, MQTT veya AMQP protokolleriyle alınır; Kafka Connect ile bir veri gölüne (örneğin Delta Lake veya Apache Iceberg) aktarılır. Zaman serisi veritabanları olan TimescaleDB veya InfluxDB, yüksek frekanslı sensor ölçümlerini depolamak için uygundur. Bizim tercih ettiğimiz mimaride, raw veriler önce Kafka'ya düşer, oradan schema validation (Avro/Protobuf) geçer ve sonra hem gerçek zamanlı uyarı motoruna hem de batch ML pipeline'ına beslenir.
Makine öğrenimi modelleri, taşkın riski, yangın yayılımı veya yapısal hasar tahmini için kullanılabilir; ancak "kara kuğu" olaylarında model performansı düşer. 2023 depremi, eğitim verisinde yer almayan büyüklük ve etki desenlerini içeriyordu. Bu yüzden uncertainty quantification (belirsizlik nicemlemesi) şarttır; modelin "emin olmadığı" bölgeler, insan uzmanlarına yönlendirilmelidir. Feature store kullanarak, farklı modeller için aynı özellikleri tutarlı şekilde sunmak ve model drift'i izlemek de önemlidir.
Veri kalitesi, modelden önce gelir. Bir sensörün 2 saat boyunca veri göndermemesi, modelin yanlış çıkarım yapmasına neden olabilir. Bu nedenle veri boru hattında dead-letter queue, eksik veri imputasyonu ve outlier detection bulunmalıdır. Ayrıca yetkili kaynaklarla entegrasyon kritiktir; örneğin USGS Earthquake Hazards Program, deprem verileri için küresel ölçekte güvenilir bir kaynaktır. Sistem tasarımcıları, bu tür açık veri API'lerini mutlaka kaynak listesine eklemelidir.
Sistem gözlemlenebilirliği ve felaket anında SRE pratikleri
Afet sırasında sistem ne durumda, bu soruyu yanıtlamak için gözlemlenebilirlik (observability) altyapısı hayati önemdedir. Prometheus, Grafana, Jaeger ve OpenTelemetry gibi araçlarla metrik, log ve trace toplarız. Ancak felaket anında bu araçların kendileri de yük altında kalabilir. Örneğin OpenTelemetry collector'ın trace sampling oranını yükseltmek, ağ bant genişliğini ve depolamayı şişirebilir. Bizim uyguladığımız desen, normalde %1 tail-based sampling kullanmak, kriz moduna geçince %10'a çıkarmak ve kritik hizmetler için always-sample etiketi eklemektir.
SRE açısından bakıldığında, doğal afet bir SLO ihlali değil, planlanmış bir "kriz modu"dur. Bu nedenle normal dönemdeki latency SLO'ları geçici olarak gevşetilir; ancak "uyarı mesajının gönderilmesi" veya "yardım talebinin kaydedilmesi" gibi hayati SLO'lar katı şekilde korunur. Circuit breaker, rate limiter ve bulkhead desenleri bu noktada devreye girer. Örneğin harita servisi yavaşladığında, uygulama statik bir "hizmet geçici olarak kullanılamıyor" mesajı gösterip ana işlevselliği sürdürebilir.
Incident management süreçleri de afet öncesi netleştirilmelidir. PagerDuty veya Opsgenie üzerinden coğrafi olarak dağıtılmış on-call rotasyonu, tek bir bölgenin etkilenmesi durumunda bile yönetimi garanti eder. ChatOps entegrasyonu (Slack/Discord botları) sayesinde durum odası, komutları doğrudan sohbetten çalıştırabilir. Chaos engineering ve düzenli "game day" tatbikatları, bu süreçlerin gerçekten işe yarayıp yaramadığını gösterir. SRE ve gözlemlenebilirlik best practice rehberimiz
Bilgi bütünlüğü ve sahte afet içerikleriyle mücadele
Bir doğal afet anında bilgi, zamanla yarışır; ama yanlış bilgi de aynı hızda yayılır. 2023 depreminde sosyal medyada dolaşan sahte yardım çağrıları, yanlış konumlar ve manipüle edilmiş görüntüler, koordinasyonu zorlaştırdı. CDN ve medya mühendisliği açısından bu, sadece içerik denetimi değil, aynı zamanda trafik mühendisliği meselesidir. Platformlar aniden yükselen trafikle karşı karşıya kalır; bu nedenle origin shield, agresif cache ve görsel/video optimizasyon kritiktir.
Sahte içeriklerle mücadelede otomasyon şarttır, ancak tek başına yeterli değildir. Hash tabanlı eşleme (örneğin PhotoDNA benzeri teknikler), makine öğrenimi sınıflandırıcıları ve doğal dil işleme modelleri, şüpheli içerikleri önceliklendirir. Ancak kesin kararlar için insan incelemesi (human-in-the-loop) gerekir; çünkü afet anında meşru bir yardım çağrısını yanlış etiketlemek, hayati sonuçlar doğurabilir. Ayrıca yetkili kaynaklardan gelen içeriklerin dijital olarak imzalanması ve W3C Verifiable Credentials gibi standartlarla doğrulanması, güvenilir bilgi akışını destekler.
Platform politikası açısından, afet döneminde "kim yayın yapabilir" sorusu öne çıkar. Yeni hesapların anında viralleşmesini sınırlayan rate limitler, coğrafi olarak yetkilendirilmiş hesapların öne çıkarılması ve resmi kurumların mesajlarının boost edilmesi gibi mekanizmalar, bilgi bütünlüğünü korur. Aynı zamanda moderasyon kararlarının şeffaf bir şekilde loglanması, sonrasında yapılacak incelemeler ve hesap verebilirlik için gereklidir.
Kimlik, erişim ve acil durumda sıfır güven
Afet anında yetkili kişilerin hızla sisteme erişmesi gerekir; ama bu, güvenliği gevşetmek anlamına gelmez. Tam tersine, kimlik ve erişim yönetimi (IAM) daha da kritik hale gelir. OAuth 2. 0 ve OpenID Connect (OIDC) kullanan kurumsal sistemler, kimlik sağlayıcısı (IdP) erişilemez olduğunda kitlenebilir. Bu yüzden acil durumda çalışan "break-glass" hesapları, offline-capable JWT doğrulama ve bölgesel yedek IdP önerilir. RFC 7519'da tanımlanan JWT, kısa ömürlü tokenlar ve doğru imza doğrulamasıyla afet senaryolarında bile güvenli erişim sağlayabilir. RFC 7519 - JSON Web Token (JWT) spesifikasyonunu inceleyebilirsiniz.
Cihaz ve kullanıcı güvenliği açısından MFA (multi-factor authentication) donanım anahtarları, cihaz doğrulama (device attestation) ve ayrıntılı audit log'lar kullanılmalıdır. Ancak felaket ortamında telefonlar kaybolabilir veya şarjı bitebilir; bu nedenle fiziksel güvenlik anahtarları yerine, biyometrik veya PIN tabanlı yedek doğrulama yöntemleri de tanımlanmalıdır. RBAC (Role-Based Access Control) ve ABAC (Attribute-Based Access Control) ile, bir görevlinin sadece ihtiyacı olan veriye erişmesi sağlanır.
Vatandaşlar açısından ise gizlilik koruyan kimlik çözümleri önemlidir. Yardım talebinde bulunan kişilerin kimlik bilgileri, yetkililer tarafından doğrulanmalı ancak gereksiz yere paylaşılmamalıdır. W3C Decentralized Identifiers (DID) ve Verifiable Credentials gibi teknolojiler, kişinin kimliğini ispat etmesini sağlarken veri minimizasyonuna da olanak tanır. Bu, hem KVKK uyumu hem de halkın sisteme güvenmesi açısından kritiktir.
Afet sonrası iyileşme ve altyapı otomasyonu
Afet geçtikten sonra başlayan teknik süreç, sistemlerin ne kadar çabuk normale dönebileceğini belirler. RTO (Recovery Time Objective) ve RPO (Recovery Point Objective) değerleri, tasarım aşamasında net şekilde tanımlanmalıdır. Örneğin acil durum uyarı veritabanı için RPO 5 dakika, RTO 15 dakika olabilir; ancak analitik veri gölü için bu değerler daha gevşek olabilir. Immutable yedekler, coğrafi olarak ayrılmış bölgelerde saklanmalı ve silme işlemleri için "soft delete" veya kilit mekanizmaları kullanılmalıdır.
Altyapı kodu (Infrastructure as Code), Terraform, Pulumi veya AWS CDK gibi araçlarla yönetildiğinde, yeni bir bölgeye hızla geçiş yapılabilir. Ancak drift detection kritiktir; çünkü acil müdahale sırasında konsoldan yapılan manuel değişiklikler, kodla uyumsuz hale gelebilir. Otomatik failover için Route 53 health check'leri, anycast DNS ve veritabanı okuma replikaları kullanılabilir. Yine de otomasyonun her senaryoda doğru karar veremeyeceğini kabul edip, insan onaylı failover (manual approval gate) mekanizmaları da eklenmelidir.
Son olarak, olay sonrası "blameless postmortem" kültürü şarttır. Hataları kişilere değil sürece odaklayarak incelemek, gelecekteki afetlere daha hazırlıklı olmayı sağlar. Bu incelemelerde elde edilen dersler, runbook'lara, otomasyon scriptlerine ve mimari kararlara yansıtılmalıdır. Unutmayın: doğal afetler tekrar eder; ama aynı teknik hatayı iki kez yapmak, mühendislik olarak kabul edilemez.
Sıkça sorulan sorular
Doğal afet senaryolarında yazılım tasarımının en kritik farkı nedir?
Normal uygulamalarda "en iyi çaba" (best effort) yeterliyken, doğal afet sistemlerinde graceful degradation, bağımsız hata alanları ve ağ bölünmelerine tolerans gösterme zorunludur. Kullanıcı deneyimi değil, hayati fonksiyonların sürekliliği önceliklidir.
Acil durum uyarı sistemleri hangi protokolleri kullanır?
OASIS CAP (Common Alerting Protocol) mesaj formatı, SMPP (SMS), Web Push API, Cell Broadcast/WEA ve HTTP/2 tabanlı push servisleri yaygındır. Ayrıca coğrafi hedefleme için GeoJSON ve konum veritabanlarında PostGIS kullanılır.
Mobil uygulama afet sırasında internet olmadan nasıl çalışır?
PWA ve service worker ile kritik sayfalar ve varlıklar önceden önbelleğe alınır. Ayrıca store-and-forward kuyrukları ve CRDT yapıları sayesinde veri yerel olarak yazılır; bağlantı geldiğinde senkronize edilir.
Veri mühendisliği afet tahmininde nasıl kullanılır?
Sensor verileri MQTT/AMQP üzerinden alınır, Kafka ve zaman serisi veritabanlarında işlenir. Makine öğrenimi modelleri risk haritaları oluşturur; ancak model drift ve belirsizlik nicemlemesi mutlaka izlenmelidir.
Sahte afet içerikleriyle teknik olarak nasıl mücadele edilir?
Hash eşleme, NLP tabanlı sınıflandırıcılar, insan incelemesi ve yetkili kaynakların dijital imzası bir arada kullanılır. Ayrıca CDN seviyesinde cache, rate limit ve kaynak doğrulama mekanizmaları bilgi bütünlüğünü korur.
Sonuç: Doğal afetlere dayanıklı yazılım inşa etmek
Doğal afetler, yazılım sistemlerinin gerçekten ne kadar dayanıklı olduğunu ortaya koyan en sert doğrulama ortamıdır. Bir deprem, sel veya yangın anında kullanıcılar uygulamanızdan hayati bilgi bekler; bu nedenle mimari, veri, gözlemlenebilirlik, kimlik ve otomasyonun tamamı afet senaryolarına göre tasarlanmalıdır. Kâğıt üzerindeki planlar yerine, üretimden çıkmış desenler, gerçek hata zincirleri ve sürekli tatbikatlar konuşmalıdır.
Eğer siz de kritik sistemler, acil durum uygulamaları veya afet dayanıklı mobil platformlar geliştiriyorsanız, mimarinizi bir "doğal afet senaryosu" üzerinden yeniden değerlendirmek en akıllıca yatırımlardan biridir. Deneyimli bir mühendislik ekibiyle, sisteminizin felaket anında değil, felaket öncesinde ve sonrasında da çalışmasını garanti altına alabilirsiniz. Şimdi mevcut uygulamanızı bir felaket senaryosuna göre gözden geçirin; zayıf noktaları bulmak, onarmaktan çok daha ucuzdur.
What do you think?
Sizin üretim ortamınızda, bir doğal afet veya büyük ölçekli kesinti senaryosunda en zorlayıcı teknik sorun hangisi oldu? Nasıl çözdünüz?
Afet uygulamalarında bulut merkezli mimari mi, yoksa edge ve offline-first yaklaşım mı daha sürdürülebilir? Hangi koşullarda birine diğerine tercih edersiniz?
Sahte afet içerikleriyle mücadelede, otomasyon ve insan incelemesi arasındaki doğru dengeyi nasıl kurmalıyız. And hangi metrikler bu dengeyi ölçmemizi sağlar
