Kripto Hiç Uyumaz: 7/24 Piyasalar Neden 7/24 Altyapı Gerektirir?

Kripto Hiç Uyumaz: 7/24 Piyasalar Neden 7/24 Altyapı Gerektirir?

O anı hâlâ hatırlıyorum: bir Salı günü saat 02:47'ydi. Bir müşterinin arbitraj botunu izliyordum ve borsanın WebSocket beslemesi sessizleşti. Ne bir çökme mesajı, ne rate-limit uyarısı. Sadece sessizlik. Bot, on bir dakika boyunca bayat fiyatlarla emir vermeye devam etti. Ben fark ettiğimde iş işten geçmişti.

7/24 piyasaların olayı şu: kapanış zili yok ve bu sayede arızalar gizlenemiyor. Geleneksel piyasalar kapandığında sorunlar ertelenir. Kriptoda ise her saniyelik kesinti, bir başkasının senin aleyhine, sen olmadan ya da senin emirlerinin üzerine işlem yaptığı bir saniyedir.

Kapanış Zili, Bozuk Sistemler İçin Bir Hastane Gibidir

Geleneksel finansal piyasaların kriptoda olmayan bir şeyi var: kapanış saati. NASDAQ sırf eğlence olsun diye saat 16:00'da işlemleri durdurmuyor. O kapanış zili herkese hesapları dengelemek, bugları düzeltmek, açıkları kapatmak ve sistemi sıfırlamak için bir fırsat veriyor. Yıllardır hisse senedi piyasalarının istikrarını sessizce destekleyen gecelik bir bakım penceresi bu.

Kripto asla durmaz. Bitcoin öğle arası vermez. Ethereum yaz saati uygulamasına uymaz. Önceki startup'ımda bir market-making botu kurarken ilk sorumuz "Stratejimiz ne?" değildi. İlk sorumuz şuydu: "AWS us-east-1 gece 03:00'te çökerse ne olacak?"

Çoğu takımın bu soruya iyi bir cevabı yok.

Altyapı Çöktüğünde Gerçekten Ne Oluyor?

Sana üç gerçekçi senaryo anlatayım. Hiçbiri varsayımsal değil.

Senaryo 1: Tokyo'daki Yatırımcı ve Frankfurt Borsası

Yuki, Tokyo'da mütevazı bir kripto portföyü yönetiyor. Çalışan bir profesyonel olduğu için ciddi işlemlerini genelde JST ile 01:00-04:00 arasında yapıyor; tam da ABD piyasalarının aktif olduğu ve volatilitenin zirve yaptığı saatler. Bir gece, büyük bir likidasyon dalgası yaşanırken favori borsası neredeyse kırk dakika boyunca "503 Service Unavailable" hatası veriyor.

Yuki, eriyen pozisyonunu kapatamıyor. Teminatı finansman oranları tarafından yenirken borsanın durum sayfasında "Tüm sistemler çalışıyor" yazıyor. Belli ki o sayfayı mesai saatleri içinde sadece insanlar kontrol ediyor.

Sonuç mu? Yuki sadece para kaybetmiyor. Güvenini kaybediyor. Varlıklarını başka bir yere taşıyor ve olanları dört kişilik işlem grubuna anlatıyor. Borsanın altyapı hatası onlara sadece bir kullanıcıya değil, tüm bir ağa mal oldu.

Senaryo 2: Ani Çöküş ve Yavaş Oracle

Merkeziyetsiz bir borç verme protokolünün tasfiye motoru, fiyat oracle'larının her 15 dakikada bir güncellendiği bir sisteme dayanıyor. Ani bir çöküşte, dayanak varlık dört dakika içinde %23 değer kaybediyor. Oracle ise yeterli yedekliliğe sahip olmayan bir altyapıda çalıştığı için yedi dakika geriden geliyor.

Oracle durumu yakaladığında, onlarca eksik teminatlı pozisyon aradan sıyrılmış oluyor. Protokolün risk paneli sağlıklı görünüyor çünkü bayat veri okuyor. Sonunda protokol, "gerçek zamanlı" altyapısı gerçekten gerçek zamanlı olmadığı için 3 milyon dolarlık kötü borç yiyor.

En kötüsü de şu: basit bir mimari değişiklik — birden fazla bölgede yedekli oracle düğümleri çalıştırıp fiyatları medyan ile birleştirmek — tüm bu felaketi önleyebilirdi.

Senaryo 3: Botu Öldüren API Rate Limiti

Sophia küçük bir özel ticaret firması işletiyor. Ekibinin Kubernetes ile orkestre edilmiş, normal koşullarda kusursuz otomatik ölçeklenen bir bot dağıtımı var. Gece 02:00'deki acımasız bir volatilite sırasında borsanın genel API'sine gelen talep üç katına çıkıyor. Ortalama yüke göre değil de zirve yüke göre hazırlanmış borsa altyapısı agresif bir şekilde rate-limit uygulamaya başlıyor.

Sophia'nın botu stratejisinin tam ortasında kısılıyor. Emir iptal edemiyor, teklifleri güncelleyemiyor, beklemekten başka bir şey yapamıyor. Rate limit temizlendiğinde piyasa pozisyonlarının aleyhine hareket etmiş oluyor ve botun "güvenlik" kodu en kötü fiyattan panik satışı gerçekleştiriyor.

Peki "7/24 Altyapı" Gerçekte Neye Benziyor?

Kripto için ürün geliştiren kurucular ve mühendislerle konuştuğumda genelde doğru içgüdülere sahip olduklarını ama ölçeği yanlış kurduklarını görüyorum. Birkaç yedekli sunucu ve bir izleme panelinin yeterli olduğunu sanıyorlar. Değil.

Coğrafi Yedeklilik Tartışılmaz

Tüm altyapın tek bir bulut bölgesinde yaşıyorsa, 7/24 altyapı işletmiyorsun demektir. İyi uptime istatistiklerine sahip "bazen" altyapısı işletiyorsun.

Kubernetes kümelerin en az iki, ideal olarak üç coğrafi bölgeye yayılmalı. Bulut sağlayıcıları bunu kolaylaştırdı — AWS Global Accelerator ve GCP multi-region load balancing işine yarıyor — ama bölgesel bir arıza için tasarım yapma yükü hâlâ sende. Çoğu takım servis arızası için tasarım yapar, bölge arızası için değil. Bunlar çok farklı şeyler.

"Sağlık Kontrolün" En Kötü Gününü Test Etmeli

Çoğu izleme sistemi, pili bitmiş bir duman alarmı kadar işe yarıyor. Sana bir şey zaten çöktüğünde haber veriyor; o zamana kadar piyasa çoktan hareket etmiş oluyor.

Benim önerdiğim şey biraz takıntılı: önceden hazırlanmış failover sistemleri ve bunların her hafta aktif olarak test edilmesi. Sadece bir yedeğin olsun yetmez — gerçekten ona geç. Üzerine çamur at. Üretimdeki ana sunucuyu öldür ve ne olacağını izle. Korkutucu ama altyapının zayıflıklarını bir piyasa olayı sırasında öğrenmekten çok daha ucuz.

Kaos Mühendisliği Senin Dostun, Boş Bir Kavram Değil

Netflix, Chaos Monkey ile kaos mühendisliğine öncülük etti. Alım satım sistemleri için karşılığı çok daha agresif olmalı. Sistemin insan müdahalesi olmadan şunlara dayanabilmesi lazım:
- Bir bulut bölgesinin tamamen kararması
- Veritabanı replikalarının dakikalarca gecikmesi
- Bağımlı olduğun borsanın tüm anahtarlarını rate-limit'e takması
- Secrets yönetim sisteminin ele geçirilmesi

Oyun günleri yap. Bir şeyleri bilerek kır. Takımın bir Perşembe öğleden sonrasında enjekte edilen bir arızayı kaldıramıyorsa, gece 02:00'deki gerçek bir arızayı asla kaldıramaz.

Rate-Limit Farkındalığı Rekabet Avantajıdır

7/24 piyasalar için üretim yaparken borsa senin ortağın değil; potansiyel bir düşmanın. Çoğu borsa, kendi altyapısı stres altındayken API isteklerini rate-limit'e takar. Sisteminde yerleşik backoff, kuyruk ve zarif bozulma (graceful degradation) yoksa, en çok ihtiyacın olduğunda ilk kesilen sen olursun.

Borsayı her an seni kısacakmış gibi düşünerek inşa et. Çünkü öyle.

İnsan Tarafı: 9-5 Ekiple 7/24 Koşamazsın

Kimsenin konuşmak istemediği kısma gelelim. Mükemmel otomasyon olsa bile, birinin uyanık ve hesap verebilir olması gerekiyor. "Kurucuları uyandırıveririz" modeli, üçüncü gece 03:00 olayından sonra çöker.

Kesin görüşüm şu: alım satım altyapısı işletiyorsan, resmi bir on-call rotasyonu ve eskalasyon yolun olmalı. "Slack'i hep beraber izleriz" değil, gerçek, yapılandırılmış bir on-call. PagerDuty veya Opsgenie gibi araçlar kullan. Akla gelebilecek her olay için runbook yaz. Ve Allah aşkına, olayları kayıt altına al — postmortem kültürü bürokrasi değildir; acı dersleri tekrar yaşamamak için en iyi yöntemdir.

Yapay Zekâ Bağlantısı

Bu altyapının nasıl işlediği konusunda sessiz bir devrim yaşıyoruz. Yapay zekâ ajanları birçok takım için ilk savunma hattı hâline geliyor. Claude Code'in "auto mode" özelliği artık varsayılan olarak açık; yani daha fazla otonom ajanın minimum insan gözetimiyle rutin operasyon görevlerini üstlendiğini göreceğiz.

Ama bir uyarım var: otonom ajanlar, etraflarına ördüğün güvenlik korkulukları kadar iyidir. Docker'ın yapay zekâ ajanları için sunduğu sandbox'lar (docker.com/products/docker-sandboxes/) tek kullanımlık, izole bir ortam sağlıyor. Böylece bir yapay zekânın olayı incelemesine veya bir failover scriptini test etmesine izin verirken üretim ortamına dokunmasından endişe etmezsin. Bunu kullan. Otonom araçlarını her zaman sandbox içinde çalıştır.

Aynı şekilde, altyapı için script yazarken GitHub Actions güvenliğini sıkılaştırmayı unutma. Workflow'larına en az yetki (least-privilege) izinleri ver. İhtiyacından fazlasına erişebilen bir deployment scripti, tetiklenmeyi bekleyen bir yüktür.

Pratik Yapılacaklar Listesi

Bunu okuyup "altyapımızı düzeltmeliyiz" diyorsan, buradan başla:

1. **Patlama alanını denetle.** Sistemindeki her bileşeni yaz. Her biri için şunu sor: "Bu gece 03:00'te çökerse, finansal hasar ne olur?"
2. **Bu hafta bilerek bir sunucu öldür.** Kritik olmayan bir servisi seç, ana sunucusunu sonlandır ve ekibinin tepkisini izle. Kurtarmanın ne kadar sürdüğünü ölç.
3. **Bağımlılıklarını haritalandır.** Sisteminin çağırdığı her harici API'yi biliyor musun? Rate limitlerini? Geçmiş kesintilerini? Bilmen lazım.
4. **Runbook iskeleti oluştur.** En olası beş arıza için kurtarma prosedürünü şimdi yaz. Gece 03:00'teki gelecek sen, sana sonsuza dek minnettar kalacak.

SSS

7/24 altyapı pahalı değil mi?

Evet, ama alternatifinden ucuz. Multi-region altyapı, tek bölgeli kurulumun 2-3 katına mal olabilir. Ama yanlış anda yaşanacak tek bir büyük olay, yılların kârını silebilir. Bunu sigorta gibi düşün — sigortayı yangın çıkacağını beklediğin için almazsın; yangının maliyeti felaket olduğu için alırsın.

Küçük kripto ekipleri gerçekten 7/24 uptime sağlayabilir mi?

Dürüst olayım: tek başlarına zor. Ama olmak zorunda da değiller. Yönetilen servisleri kullan (AWS/GCP/Azure), yönetilen Kubernetes kullan (EKS, GKE, AKS) ve kendi veritabanını kurmaya kalkma. Başarısız olan ekipler her şeyi kendi başına yapmaya çalışanlar. İyi yönetilen altyapı kullan ve mühendislik zamanını gerçekten seni farklılaştıran şeylere sakla.

En önemli şey nedir?

Stateful servislerin için coğrafi yedeklilik. API sunucuları gibi stateless servisler ölçeklenmesi ve taşınması kolay olanlardır. Zor kısım veritabanları ve kuyruklar. Verilerin bölgeler arasında çoğaltılmıyorsa, diğer hiçbir şeyin önemi yok.

Borsa API kesintisiyle nasıl başa çıkabilirim?

Olacağını varsay ve zarif bozulma için inşa et. Order book verisini önbelleğe al ama bayat olduğunu açıkça işaretle. Üstel geri çekilme (exponential backoff) uygula. Veri akışının yaşı belirli bir sınırı aştığında alım satımı durduran veya savunma moduna geçiren bir devre kesici (circuit breaker) kullan. Amaç parayı hızlı kaybetmek yerine yavaş yavaş kaybetmeyi durdurmak.

Özet

Kripto piyasası senin hafta sonunu umursamaz. Mühendislerinin tatilde olmasını, bulut sağlayıcının kötü bir gün geçirmesini ya da takımın gece yarısı nedensiz bir Zoom toplantısına katılmasını umursamaz. Piyasa sadece ileri giden bir makinedir.

Altyapına olması gereken sürekli açık sistem gibi davranmaya ne kadar erken başlarsan, o gece 03:00 çağrıları o kadar az acı verir. Çünkü sana şunu garanti edebilirim: 7/24 için inşa etmezsen, piyasa boşluğu bulur. Her zaman bulur.