Black Friday Öncesi Sistem Hazırlığı: Teknik Rehber

Kısa cevap: Hazırlık kasım başlamadan bitmelidir. Beklenen peak'in üstünde yük testi koşun; p95 ve p99 latency'yi, error rate'i, database connection sayısını ve cloud quota'larını ölçün; yedeği değil restore'u deneyin. Ay boyunca değişiklikleri kısıtlayın, 11.11 ile Black Friday–Cyber Monday çevresinde tam change freeze uygulayın, on-call rotasyonunu dört haftaya göre planlayın. Go kararını tek bir "hazırız" cümlesine değil yedi kanıt kapısına bağlayın: talep, kapasite, journey, dayanıklılık, koruma, operasyon, değişiklik. En küçük doğrulanmış sınır, kampanyanın gerçek sınırıdır.

Don't Deploy on Friday. Verify on Friday.

Kampanya trafiği neden farklıdır?

1961'de Philadelphia polisi, Şükran Günü'nün ertesindeki cumaya "Black Friday" dedi, çünkü şehir kilitleniyordu. Bugün aynı kalabalık ödeme sayfalarını kilitliyor. O yıllarda kalabalık bir cumaya sığıyordu; bugün e-ticarette indirimler kasım boyunca sürüyor ve 11.11, Black Friday ile Cyber Monday bu dönemin en yoğun günleri. Teknik açıdan bu, tek bir peak değil; dört hafta boyunca yüksek seyreden bir baseline ve üstüne binen birkaç peak demektir.

Yüksek trafikli bir dönem, normal günün büyüğü değildir. Trafik aynı anda yükselir, kullanıcı davranışı değişir, third-party limitleri görünür hâle gelir ve küçük gecikmeler retry dalgalarına dönüşür. Her peak'te yükün şekli aynıdır: istekler aynı birkaç akışa (ürün sayfası, sepet, checkout) yığılır, bot trafiği bu yığılmaya eklenir. Application katmanı yatay ölçeklenir; database, session store, stok kilidi ve ödeme entegrasyonu aynı hızda ölçeklenmez. Darboğaz önce bu katmanlarda aranır.

Bu yüzden hazırlık daha fazla CPU veya sunucu ayırmakla bitmez. Ekip, kritik customer journey'lerin beklenen yükte ve öngörülen arızalar altında nasıl davrandığını kanıtlamak zorundadır.

Ayın tamamına yayılan bir kampanya, hazırlığı üç yerden değiştirir:

• Change freeze tek haftaya sığmaz. Ay boyunca kısıtlı değişiklik, peak günlerinde tam freeze gerekir.
• Kapasite haftalarca yüksek kalır. Geçici quota artışları ve autoscaling alt sınırları ay boyu maliyet üretir.
• Ekip dört hafta on-call kalır. Tek gecelik bir plan ikinci peak'e yetmez.

2026'da bu günler 11 Kasım Çarşamba (11.11), 27 Kasım Cuma (Black Friday) ve 30 Kasım Pazartesi'ye (Cyber Monday) denk geliyor; Şükran Günü kasımın dördüncü perşembesi, yani 26 Kasım. Takvim bölümü bu tarihlere göre hazırlandı; kendi kampanya takviminize göre kaydırın.

Hazır olmanın tanımı

Bir sistem, normal koşullarda tahmini peak trafiği taşıdığı için hazır sayılmaz. Hazır bir sistem kritik journey'leri hedef SLO içinde sürdürür, en önemli arıza senaryolarında kontrollü biçimde bozulur, overload sırasında kendini korur ve ekibin bildiği süre içinde toparlanır. Bu iddiaların her biri test sonucu, dashboard, runbook veya tatbikat kaydıyla doğrulanır.

Peak güvenilirliği = doğrulanmış kapasite × arıza toleransı × operasyon kabiliyeti

Çarpanlardan biri sıfıra yaklaştığında toplam güvenilirlik de düşer; en küçük doğrulanmış sınır kampanyanın gerçek sınırıdır. Bu yüzden rehber kapasite planlama, performans testi, resilience, graceful degradation, change management ve incident command pratiklerini tek bir çalışma sisteminde birleştirir. Shopify'ın BFCM hazırlık programındaki scale test ve Resiliency Matrix yaklaşımından, Google SRE'nin overload, load shedding, retry ve incident response ilkelerinden, AWS Operational Readiness Review ve Azure mission-critical test pratiklerinden yararlanır; kaynaklar son bölümde.

Temel ilkeler

Rehber nasıl kullanılır

1. Teknik lider, event owner'ı ve kapsam içindeki kritik customer journey'leri belirler.
2. Her servis sahibi kendi kapasite sınırını, dependency'lerini, failure mode'larını ve kanıtlarını doldurur.
3. Merkezi readiness review, riskleri yedi kanıt kapısı üzerinden değerlendirir.
4. Kırmızı kapılar kapanmadan go kararı verilmez. Amber kapılar için yazılı risk kabulü, tetikleyici eşikler ve geri dönüş planı gerekir.
5. Kampanya sonrasında tahmin ile gerçek karşılaştırılır; kontrol listesi incident bulgularıyla güncellenir.

Kontrol listesi maddeleri dört parçadan oluşur. Yapılacak: ne yapılmalı ve hangi araçla. Nasıl fark edilir: kontrol atlandığında sorunun ilk görüldüğü yer. Neden önemli: kontrolün arkasındaki teknik gerekçe ve kaynağı. Komut: örnek değerlerle verilen komutlar; eşikleri kendi SLO'nuza göre değiştirin.

Hazırlık takvimi · Kasım 2026

Önce zemin, sonra iki freeze, arada bir prova.

Peak'e geri sayım

Aşağıdaki geri sayım ilk peak'e (11.11) göredir. Black Friday için aynı döngü, 13–17 Kasım ara değerlendirmesiyle kısaltılmış olarak yeniden koşulur; ilk peak'in bulguları ikincisinin test senaryosudur.

Yedi kanıt kapısı ve go / no-go

Go veya no-go kararı genel bir kanaate değil, yedi bağımsız kanıt alanına dayanır. Her kapının tek bir sorumlusu, son kanıt tarihi ve açık riskleri vardır. Bir kapının yeşil olması belgesinin var olduğunu değil, içeriğinin güncel ve test edilmiş olduğunu gösterir.

Durum kuralları

Ortalama bir readiness skoru kritik bir kırmızıyı gizler. 100 kontrolün 95'inin tamamlanması etkileyici görünür; eksik beş kontrol payment database kapasitesi, WAF fail-open davranışı veya rollback yetkisiyle ilgiliyse sistem hazır değildir. Kapılar birbirini telafi etmez: yönetim özeti renklerle sunulabilir, teknik karar kapı bazında verilir.

Go / no-go review

Review toplantısının amacı sunum dinlemek değil, eksik kanıtı ve kabul edilmemiş riski ortaya çıkarmaktır. Her kapı sahibi üç dakikada hedefi, sonucu, açık riski ve istediği kararı sunar; tartışma kanıt üzerinde yürür. Toplantıya girmeden şunlar hazır olmalı:

• Talep modeli ve marketing campaign takvimi güncel (kanıt: forecast version · sorumlu: event owner)
• Full-scale ve failover under load sonuçları erişilebilir (test run ID · platform)
• Kritik journey SLO dashboard'ları canlı (dashboard URL · journey owner)
• Açık P0/P1 teknik riskler owner ve tarihle listeli (risk register · tech lead)
• Vendor quota ve escalation teyitleri tamam (vendor kaydı · service owner)
• On-call roster, break-glass hesapları ve war room prova edildi (drill log · ops lead)
• Freeze ve emergency change authority duyuruldu (change plan · change owner)

Karar kaydında şu alanlar bulunur: karar (go / koşullu go / no-go), karar zamanı, Event Commander, kırmızı kapılar, kabul edilen amber riskler, koşullar ve son tarih, bir sonraki review.

No-go kriterleri

• Kritik journey'nin peak test sonucu yok veya SLO karşılanmıyor.
• Tek bir failure domain kaybında kalan doğrulanmış kapasite tahmini peak'in altında.
• Payment, order veya benzeri write akışında idempotency ve reconciliation belirsiz.
• Overload davranışı kontrolsüz retry, sınırsız queue veya process crash üretiyor.
• Kritik dependency için owner, alarm veya çalışır runbook yok.
• Incident response rollerinde veya production erişiminde doğrulanmamış boşluk var.
• Event penceresinde geri döndürülemeyen yüksek riskli migration planlanmış.

Talep modeli ve capacity envelope

Kapasite tahmini tek bir RPS sayısı değildir. Aynı toplam trafik; cache hit ratio, authenticated kullanıcı oranı, ürün karması, payload boyutu veya checkout dönüşüm oranı değiştiğinde bambaşka bir altyapı yükü üretir. Bu yüzden talep, her kritik journey için çok boyutlu bir iş yükü vektörü olarak modellenir. Kampanyada kullanılabilecek güvenli sınır, en yüksek laboratuvar sonucu değil; planlanan arıza senaryosu ve güvenlik payı düşüldükten sonra kalan doğrulanmış kapasitedir.

Talep vektörü

Temel hesaplar

P = baseline × büyüme × kampanya etkisi × belirsizlik katsayısı

Peak tahmini P'de katsayılar aynı veriden türetilmemelidir; aksi hâlde aynı büyüme iki kez sayılır. En iyi, beklenen ve stres senaryoları ayrı tutulur.

H = doğrulanmış kapasite / tahmini peak

Headroom H yalnızca normal durumda değil, kaybedilmesi planlanan en büyük failure domain çıkarıldıktan sonra da hesaplanır.

L = λ × W

Little's law'a göre sistemdeki ortalama eş zamanlı iş sayısı L, geliş hızı λ ile sistemde kalma süresi W'nin çarpımıdır. Latency iki katına çıkarsa aynı RPS için concurrency de yaklaşık iki katına çıkar; connection pool ve thread pool bu yüzden latency'ye bağlı dolar.

ΔQ = geliş hızı − işleme hızı

Queue büyümesi ΔQ'daki pozitif fark kısa süreli görünse bile kuyruk yaşını hızla büyütür. Dashboard yalnızca queue depth değil, oldest message age göstermelidir.

Capacity envelope çalışma tablosu

Her bileşen için iki profil çıkarılır: normal limit ve arıza altı limit. Headroom ikisine göre ayrı hesaplanır.

Capacity plan için kırmızı bayraklar

• Autoscaling'in ihtiyaç duyduğu quota ayrılmamış veya scale-out süresi peak ramp süresinden uzun.
• Application instance sayısı artırıldığında database connection pool ve streaming connection toplamı doğrulanmamış.
• Failover region boş görünse de image pull, warm-up, cache fill veya data replication nedeniyle zamanında trafik alamıyor.
• Test anonymous browse ağırlıklı; authenticated checkout, webhook veya admin akışları gerçek oranında temsil edilmiyor.
• Cloud veya CDN sağlayıcısına büyük quota ve kapasite artışı önceden bildirilmemiş.
• Tek sonuç ortalama latency; p99, error rate, saturation ve recovery time raporlanmıyor.

Kritik customer journey'ler ve SLO

Servisler altyapı organizasyonuna göre bölünür; müşteri deneyimi bu sınırları izlemez. Hazırlığın ana birimi bu yüzden servis değil kritik journey'dir: ürün görüntüle → sepete ekle → ödeme → sipariş onayı. Her journey edge'den veri katmanına ve dış servislere kadar uçtan uca izlenir.

Journey reliability sheet

Her kritik journey için bir satır doldurulur; boş kalan alan açık risktir.

SLI seçimi

Synthetic transaction tasarımı

• Shallow probe yalnızca endpoint erişimini kontrol eder; deep probe gerçek iş sonucunu doğrular. İkisi farklı alarmlara bağlanır.
• Test kullanıcısı, ürün ve ödeme verisi peak sırasında tükenmeyecek ve gerçek müşteriyle çakışmayacak şekilde ayrılır.
• Synthetic transaction farklı region ve ISP noktalarından çalışır. İçeriden başarılı görünen servis dış kullanıcı için erişilemez olabilir.
• Canary sonucu genel error rate içinde kaybolmaz; bağımsız metric ve alarmı bulunur.
• Her kritik journey dashboard üzerinde tek satırda success, latency, volume ve saturation ile görünür.

Kontrol listesi · 01–03 · Yük testi, limitler ve değişiklik politikası

01 · Peak yükü kampanyadan önce siz üretin

Gerçek kullanıcı yolunu (ana sayfa, arama, ürün, sepet, checkout) izleyen bir senaryoyu, beklenen peak istek hızının üzerine çıkarak çalıştırın. k6, JMeter, Locust ya da Gatling bu iş için yeterli. Ortalama yerine p95 ve p99 latency'ye, error rate'e, database connection sayısına ve queue depth'e bakın. Testi CDN ve WAF arkasından da koşun, çünkü kampanya günü trafik oradan gelecek. Başarılı bir test yalnızca hedef RPS'ye ulaşmaz; sistem sınırını, sınırın yaklaştığını gösteren sinyalleri, sınır aşıldığında müşterinin gördüğü davranışı ve yük düştüğünde toparlanma süresini ortaya çıkarır. Her test bir hipotezle başlar ve yeniden üretilebilir bir sonuçla biter.

Gerçekçi trafik üretimi. Open workload model kullanın: yeni istekler önceki yanıtın bitmesini beklemez, böylece latency artarken yük kaybolmaz; gerçek internet trafiği de böyle davranır. Kullanıcı akışlarını production oranlarına göre ağırlıklandırın; nadir ama pahalı akışları ayrıca stress senaryosuna alın. Cache warm ve cold durumlarını ayrı koşun; cache busting yalnızca bilinçli bir senaryo olarak kullanılır. Test verisi hot key, kampanya ürünü, yüksek fan-out ve gerçek payload boyutlarını kapsasın. Load generator kapasitesini hedefin üstünde doğrulayın; generator saturation sistem limiti sanılmamalıdır. Third-party sistemlere gerçek zarar verecek çağrı yapılmaz; mock, sandbox veya önceden onaylı limit kullanılır.

// k6 · örnek değerler: hedef hızı ve eşikleri kendi peak trafiğinize ve SLO'nuza göre ayarlayın.
import http from 'k6/http';

export const options = {
  scenarios: {
    kampanya: {
      executor: 'ramping-arrival-rate', // open workload model
      startRate: 50,
      timeUnit: '1s',
      preAllocatedVUs: 200,
      maxVUs: 2000,
      stages: [
        { target: 600, duration: '10m' }, // peak hıza çık
        { target: 600, duration: '20m' }, // peak'te kal
      ],
    },
  },
  thresholds: {
    http_req_duration: ['p(95)<800'], // milisaniye
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  // Gerçek senaryoda ana sayfa → arama → ürün → sepet → checkout adımları sırayla çağrılır.
  http.get('https://staging.example.com/urun/123');
}

Nasıl fark edilir: Dashboard'lar normal görünürken müşteri hizmetlerine "ödeme sayfası dönüp duruyor" şikâyetleri gelmeye başlar.

Neden önemli: Ortalama, kuyrukta bekleyen isteklerin yaşadığı gecikmeyi gizler; p95 ve p99 onu gösterir. Örnekteki eşikler şunu söyler: her 20 istekten en fazla biri 0,8 saniyeyi geçebilir, her 100 istekten en fazla biri hata alabilir. Closed model ile warm cache üzerinde geçen bir test, gerçek peak'i temsil etmeyebilir.

Test kabul kriteri. Test ancak şu altı kanıt varsa geçmiş sayılır:

• Kritik journey SLO'ları test boyunca karşılandı (run raporu ve dashboard snapshot · journey owner)
• Normal ve failure senaryosu ayrı raporlandı (iki kapasite profili · platform)
• İlk saturation noktası ve leading indicator belirlendi (grafik ve threshold · servis owner)
• Retry ve timeout davranışı downstream yüküyle birlikte ölçüldü (attempt histogramı · app owner)
• Test sonrası backlog hedef sürede boşaldı (queue age trendi · data owner)
• Bulgular düzeltildi ve aynı senaryo yeniden koşuldu (karşılaştırmalı run ID · event owner)

Test raporunda aynı zaman ekseninde şu grafikler bulunur: offered load, accepted load ve completed business transaction; journey success rate ile p50/p95/p99 latency; CPU'nun yanında concurrency, connection, queue age, database wait, cache hit ve third-party error; autoscaler desired / ready / serving instance sayıları ve warm-up süresi; failure injection, operatör aksiyonu, recovery başlangıcı ve tam recovery zaman damgaları.

02 · Quota ve limitleri tek tabloda toplayın

Cloud hesabınızdaki vCPU, IP adresi, load balancer ve NAT gateway quota'larını yan yana yazın. Yanına database'in max_connections değerini, application'ın connection pool boyutunu ve firewall'un concurrent session ile saniyedeki yeni bağlantı (CPS) limitlerini ekleyin. Autoscaling'in üst sınırının bu limitlere sığdığını doğrulayın. Capacity envelope tablosundaki "normal limit" sütunu bu listeden doldurulur.

# AWS: EC2 quota'ları
aws service-quotas list-service-quotas --service-code ec2 --output table

# Azure: bölgedeki vCPU kullanımı ve limitleri
az vm list-usage --location westeurope --output table

-- PostgreSQL: anlık connection sayısı ve üst sınır
SELECT count(*) FROM pg_stat_activity;
SHOW max_connections;

Nasıl fark edilir: Autoscaling yeni sunucu açmaya çalışır ama açamaz; konsolda tek satırlık bir quota hatası durur. Ya da sunucular açılır ama database "too many connections" hatası vermeye başlar.

Neden önemli: Autoscaling yalnızca quota kadar büyür ve her yeni application instance'ı kendi connection pool'unu getirir. Bunu restorandaki masalar gibi düşünün: her sunucu kendi rezervasyonuyla gelir, restoranın masa sayısı (max_connections) ise değişmez; masalar dolunca database yeni bağlantıları reddeder. Connection pool toplamı instance sayısıyla çarpılıp database'in connection bütçesine bağlanır. Quota artışı sağlayıcı onayı gerektirebilir; talebi kasımdan önce açın ve bütçe alarmlarını artırılmış quota'lara göre güncelleyin.

03 · Değişiklikleri ay boyunca kısıtlayın, peak'lerde dondurun

Kasım boyunca production'a yalnızca test edilmiş, geri alınabilir ve düşük riskli değişiklikler çıksın, onlar da yoğun saatlerin dışında. Peak günlerinin çevresinde (takvimdeki iki freeze dönemi) tam change freeze uygulayın. Kapsamı yazılı olsun: application release'leri, Infrastructure as Code (Terraform vb.) değişiklikleri, database schema değişiklikleri, WAF ve CDN kuralları. Freeze sistemi dokunulmaz yapmak değildir; amaç değişiklik sayısını azaltmak, istisnaları görünür kılmak ve rollback kapasitesini korumaktır.

Emergency change kaydı. Freeze sırasında her istisna şu alanları doldurur: trigger (hangi metric ve eşik değişikliği gerektiriyor), hipotez (müşteri etkisini hangi mekanizmayla azaltacak), blast radius (hangi region, tenant, endpoint veya trafik yüzdesi), validation (ilk 5, 10 ve 20 dakikada hangi metrikler izlenecek), rollback (tek adım, owner, süre ve geri dönüş eşiği), approver (IC ve teknik owner; güvenlik etkisi varsa security owner), kayıt (zaman damgası, commit veya config ve sonuç).

Canary ve rollback kuralları. Canary yalnızca error rate ile değil kritik journey success, tail latency ve saturation ile değerlendirilir; canary gerçek trafik karmasını temsil etmiyorsa sonuç genellenmez. Rollback yeni deploy kadar test edilir; schema veya data migration geri dönüşü imkânsızsa forward-fix planı ve koruma modu bulunur. Config değişikliği de kod gibi versiyonlanır, peer review ve audit edilir. Peak sırasında aynı anda birden fazla hipotez değiştirilmez; aksi hâlde hangi değişikliğin sonucu etkilediği bilinemez.

Nasıl fark edilir: Kesinti, kampanyadan bir gün önce yapılan "küçük" bir konfigürasyon değişikliğinin ardından başlar ve war room'daki ilk soru "en son ne değişti?" olur.

Neden önemli: Google'ın SRE kitabına göre kesintilerin yaklaşık %70'i canlı sistemde yapılan bir değişiklikten kaynaklanır. Ayın tamamını dondurmak ise başka bir risk yaratır: değişiklikler birikir ve aralıkta tek seferde, daha büyük bir release olarak çıkar. Kısıtlı değişiklik ile peak freeze'i bu iki riski dengeler. Reliability Friday serimizin kuralı da bu: Don't Deploy on Friday. Verify on Friday.

Kontrol listesi · 04–06 · Restore, synthetic monitoring ve on-call

04 · Yedeği değil, restore'u ölçün

Kritik database'leri en son yedekten bir test ortamına restore edin. İki süreyi ayrı ölçün: verinin geri yüklenme süresi ve application'ın yeniden sipariş alabildiği ana kadar geçen süre. Point-in-time recovery (PITR) kullanıyorsanız belirli bir saate dönmeyi de deneyin ve sonuçları RPO ve RTO hedeflerinizle karşılaştırın. Kanıt, yedeğin varlığı değil; son test kaydındaki restore süresi ve doğrulanmış veri bütünlüğüdür.

Nasıl fark edilir: Backup dashboard'u aylardır yeşildir. Restore ilk kez gerçek bir arızada denenir ve planlanandan saatler sonra biter.

Neden önemli: Eksik WAL ya da binlog dosyaları, erişilemeyen encryption key'ler ve sürüm uyumsuzlukları ancak restore sırasında ortaya çıkar. Kampanya gününde kaybedilen her dakika, sıradan bir gündekinden daha çok siparişe mal olur.

05 · Müşterinin yolunu synthetic check'lerle izleyin

Ana sayfa, arama, sepete ekleme ve ödeme adımlarını dışarıdan, birden fazla bölgeden ve dakikada bir deneyen synthetic check'ler kurun. Alarmları CPU ve memory eşiklerine değil SLO'ya bağlayın: örneğin ödeme adımında beş dakikalık pencerede error rate ve p95 latency. Synthetic transaction tasarımı için bir önceki bölümdeki beş kural geçerlidir.

# Basit bir endpoint kontrolü: HTTP kodu ve toplam süre
curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' https://www.example.com/sepet

Observability tarafında kampanya öncesi şu altı kontrol kapatılır:

• Dashboard RED ve USE metriklerini kritik journey'lerle aynı zaman ekseninde gösteriyor.
• Telemetry pipeline peak yükte çalışıyor; log hacmi ve cardinality limiti incident anında körlük yaratmıyor.
• Alarm SLO tehdidine ve aksiyona bağlı; noisy alarm'lar kampanya öncesi temizlendi.
• Third-party dependency, quota, certificate, replication ve queue age için leading indicator alarmı var.
• Deploy, config, failover ve marketing push grafiklere event marker olarak düşüyor.
• War room için tek ekranlık executive view ile derin teknik dashboard'lar ayrılmış.

Nasıl fark edilir: Altyapı dashboard'ları yeşilken siparişler düşer. Sorunu ilk siz değil, sosyal medyada şikâyet eden müşteri fark eder.

Neden önemli: Altyapı metrikleri nedeni gösterir; synthetic check ve SLO alarmı ise müşterinin yaşadığı sonucu.

06 · On-call'u dört haftaya, runbook'u kampanya saatlerine göre planlayın

Kampanya ayı için on-call rotasyonunu, escalation matrisini ve kritik senaryolar için kısa runbook'ları hazırlayın. Ödeme sağlayıcısı yavaşlarsa, database connection'ları dolarsa ya da CDN hata dönerse ilk üç adım ne? Rollback, kampanyayı durdurma ve müşteriye duyuru kararlarının kimde olduğunu yazın. Aynı kişinin hem sistemi düzeltmeye hem koordinasyon yapmaya hem de paydaşları bilgilendirmeye çalışması response kalitesini düşürür; roller olay başlamadan atanır ve dress rehearsal sırasında prova edilir.

Bu rol dağılımı bir örnektir; kendi organizasyonunuzda roller birleşebilir veya farklı adlanabilir.

Incident ilan tetikleyicileri

War room çalışma düzeni. Tek karar kanalı, tek incident kaydı ve sabit conference bridge kullanılır. Her aksiyon owner ve zaman damgasıyla yazılır; sonucu gelmeden aynı hipotez unutulmaz. Teknik ekipler thread veya ayrı workstream'de çalışır, kararlar ana kanalda özetlenir. Güncelleme ritmi önceden belirlenir; yeni bilgi yoksa bile durum ve bir sonraki kontrol zamanı yazılır. IC sistemi düzeltmeye dalmaz; koordinasyon, öncelik ve iletişim kontrolünü korur. Recovery ilanı tek metriğe dayanmaz: journey SLO, backlog, saturation ve error trendi birlikte normale dönmelidir.

Event dashboard yerleşimi

Nasıl fark edilir: Gece 02.00'de alarm çalar. Telefonu açan kişi, ödeme sağlayıcısında kime ulaşacağını ve kampanyayı durdurma yetkisinin kimde olduğunu bilmez.

Neden önemli: Olay anında aranan her bilgi müdahale süresine eklenir. Rotasyon ve runbook, yorgun bir ekibin de aynı adımları atabilmesini sağlar.

Kontrol listesi · 07–10 · Dış servisler, botlar, tarihler ve kill switch

07 · Dış servislere timeout, retry budget ve circuit breaker koyun

Ödeme, 3D Secure, SMS ile doğrulama (OTP), kargo, stok ve e-posta entegrasyonlarını listeleyin. Her çağrı için açık bir timeout ve jitter'lı exponential backoff ile sınırlı retry tanımlayın. Ardından bir circuit breaker ve bir fallback davranışı ekleyin: kuyruğa alma, alternatif sağlayıcı ya da kullanıcıya net bir mesaj. Ödeme çağrılarında idempotency key kullanın. Overload sırasında amaç bütün istekleri kabul etmek değil, sistemin çökmesini önlerken en değerli müşteri işlemlerini tamamlamaktır; bu kontroller upstream'den downstream'e tutarlı çalışmalı, autoscaling, load balancing ve load shedding birbirine zıt sinyal üretmemelidir.

Timeout budget. Bir müşteri isteğinin toplam deadline'ı, zincirdeki her çağrıya bağımsız ve daha uzun timeout vermekle korunamaz. Her hop kalan budget'ı bilmeli; artık kullanıcıya fayda üretmeyecek iş başlamamalı veya iptal edilmelidir. Client vazgeçtikten sonra server tarafta devam eden iş, görünmeyen yükü büyütür. Aşağıdaki dağılım bir örnektir; değerler journey SLO'nuzdan türetilir.

Retry budget. Retry kapasite üretmez; yalnızca geçici ve lokal hataların başka bir denemede başarılı olma olasılığını kullanır. Birden fazla katmanda bağımsız retry yapılırsa tek kullanıcı işlemi katlanarak büyür: üç katmanın her biri ilk deneme dâhil dört attempt yaparsa database'e kadar 4³, yani 64 attempt oluşabilir. Bu yüzden retry tek bir kontrollü katmanda, exponential backoff ve jitter ile, açık bir bütçe içinde yapılır.

Nasıl fark edilir: Çağrı merkezine aynı cümle gelmeye başlar: "Kartımdan para çekildi ama siparişim görünmüyor."

Neden önemli: Timeout tanımlanmamış ya da çok uzun bırakılmış bir çağrı, yavaş bir dış servis yüzünden thread'leri ve connection'ları tutar; kuyruk büyür ve sağlıklı istekler de yavaşlar. Sınırsız retry, yavaşlayan servise giden yükü katlayıp kesintiye çevirir. Ödeme çağrısını idempotency key olmadan yeniden denemek çift tahsilat riski doğurur. Circuit breaker evdeki sigorta gibi çalışır: arıza tek bir odada kalır, bütün ev kararmaz.

08 · Bot trafiğini ödeme akışından ayırın

WAF'ta bot management ve rate limiting kurallarını endpoint bazında ayarlayın: login, sepet, stok sorgusu ve ödeme için ayrı limitler. Credential stuffing ve kart testi (card testing) saldırılarını yakalamak için login ve ödeme endpoint'lerinde başarısız deneme oranını izleyin. DDoS korumanızın application katmanını (L7) da kapsadığını doğrulayın. Rate limit global, tenant ve endpoint seviyesinde iş önceliğine göre uygulanır; bot davranışını normal müşteri burst'ünden ayıran kuralların false positive riski kampanya öncesi test edilir. Her güvenlik kontrolü için fail-open veya fail-closed kararı yazılı ve onaylı olmalı; fraud kontrollerinin latency'si ve fail mode'u ödeme journey'siyle birlikte test edilmelidir. Privileged access, break-glass hesapları, MFA ve audit kayıtları ile security kural değişiklikleri için emergency rollback ve iletişim owner'ı da bu maddenin parçasıdır.

Nasıl fark edilir: Kampanya ürünü, gerçek müşteriler sepete ulaşamadan "tükendi" görünür.

Neden önemli: Imperva'nın 2026 Bad Bot Report'una göre web trafiğinin yarısından fazlası (%53) botlardan geliyor. Ayıklanmayan her bot isteği, gerçek müşterilerle aynı connection pool'u, aynı stok sorgusunu ve aynı ödeme limitini kullanır.

09 · Certificate, domain, DNS ve disk tarihlerini kontrol edin

Kasım içinde süresi dolacak TLS certificate'larını ve domain'leri kampanya başlamadan yenileyin; certificate yenilemeyi ACME ile otomatikleştirin. Secret, license ve token expiry tarihlerinin de event penceresi dışında olduğunu doğrulayın. Kampanya sırasında trafik yönlendirmesi planlıyorsanız DNS TTL değerlerini önceden düşürün. Log ve metric hacmi haftalarca yüksek kalacağı için disk doluluk alarmlarını, log rotation'ı ve retention sürelerini gözden geçirin.

# Certificate'ın bitiş tarihi
echo | openssl s_client -servername www.example.com -connect www.example.com:443 2>/dev/null | openssl x509 -noout -enddate

# DNS kaydının TTL değeri (ikinci sütun)
dig +noall +answer www.example.com

Nasıl fark edilir: Bir sabah mobil uygulama ve API istemcileri aynı anda bağlantı hatası verir, tarayıcı kırmızı bir güvenlik uyarısı gösterir. Ya da loglarla dolan bir disk yüzünden servis yazamaz hâle gelir ve durur.

Neden önemli: CA/Browser Forum kararıyla 15 Mart 2026'dan bu yana verilen ve tarayıcıların güvendiği TLS certificate'ları en fazla 200 gün geçerli; her certificate yılda en az iki kez yenilenmeli. 15 Mart 2027'de süre 100 güne, 15 Mart 2029'da 47 güne inecek ve yenileme yılda yaklaşık sekiz kereye çıkacak.

10 · Kill switch ve virtual waiting room hazırlayın

Yük altında kapatılabilecek bileşenleri (öneri motoru, canlı stok sayaçları, kişiselleştirme, ağır raporlar) feature flag ile tek hamlede kapatılabilir hâle getirin. Ödeme akışını en üstte tutan bir öncelik sırası belirleyin. Kapasite sınırına yaklaşıldığında devreye girecek bir virtual waiting room eşiği tanımlayın. Feature flag ve kill switch tek owner'a bağlı olmamalı; audit ve rollback adımları bulunmalı.

Load shedding önceliği

Graceful degradation kataloğu

Nasıl fark edilir: Yük arttığında ödeme sayfası da yavaşlar, çünkü ağır bileşenlerle aynı kaynakları paylaşır ve onları kapatacak bir düğme yoktur.

Neden önemli: Graceful degradation, tam kesintiyle kısmi hizmet arasındaki farktır. Öneri motoru kapanırsa müşteri fark etmeyebilir, ödeme kapanırsa fark eder. Virtual waiting room bankadaki sıra numarası gibidir: kimse geri çevrilmez, ama herkes içeri aynı anda girmez.

Dependency ve failure modeli

Dependency haritası yalnızca servislerin birbirini çağırdığını gösterirse yetersiz kalır. Her bağlantı için failure semantics yazılır: timeout olduğunda ne olur, retry kimde yapılır, stale veri kabul edilir mi, startup dependency yoksa servis açılır mı ve dependency geri geldiğinde trafik nasıl toparlanır?

Resiliency Matrix

Shopify'ın yüksek trafikli etkinlikler için kullandığı Resiliency Matrix, her arıza senaryosunda müşterinin hangi journey'leri hangi kalitede tamamlayabildiğini tek tabloda gösterir. Tabloyu doldurmak başlı başına bir tabletop exercise'dır; satırları ve sütunları taramak sistemin en kırılgan yerini gösterir. Aşağıdaki hücreler örnektir; kendi dependency'lerinize göre doldurun.

Failure mode kaydı

Matristeki her hücrenin arkasında sekiz sorusu cevaplanmış bir kayıt bulunur.

Test edilecek failure sınıfları

Her Game Day senaryosu için kart şu alanları taşır: hipotez, başlangıç yükü, enjekte edilen arıza, beklenen müşteri davranışı, beklenen alarm ve otomasyon, abort kriteri, gözlenen davranış, recovery süresi, bulgular ve owner.

Teknik katman kontrolleri

Aşağıdaki kontroller servis sahiplerinin kendi alanlarında doğrulaması gereken minimumlardır. Her kontrol bir evidence link, owner ve son doğrulama tarihiyle tutulur. Observability ve security kontrolleri 05 ve 08 numaralı maddelerde yer aldığı için burada tekrarlanmadı.

DNS, CDN, WAF ve edge

• DNS TTL, secondary DNS ve registrar erişimi doğrulandı; acil değişiklik yetkisi test edildi.
• CDN cache key, TTL, stale-if-error, origin shield ve request coalescing davranışları ölçüldü.
• Cold cache ve cache purge sonrası origin kapasitesi test edildi.
• WAF rule evaluation, bot management, DDoS profili ve rate limit kapasitesi peak'e göre ayarlandı.
• TLS handshake, certificate expiry, OCSP ve connection reuse metrikleri dashboard'da.

Network ve load balancer

• New connection rate, active connection, SYN backlog, ephemeral port ve NAT table kapasitesi ölçüldü.
• Health check, application'ın gerçekten trafik alabilir olduğunu ölçüyor; warm-up bitmeden node healthy sayılmıyor.
• Connection draining ve keepalive süreleri deploy, scale ve failover davranışıyla uyumlu.
• Zone veya region kaybında routing convergence ve session stickiness etkisi test edildi.
• Load shedding hataları load balancer tarafından başarı gibi yorumlanmıyor; feedback loop kontrol edildi.
• Bandwidth yanında packet rate (PPS), drop, retransmit ve load balancer data plane limitleri izleniyor.

Compute, Kubernetes ve runtime

• Request ve limit değerleri gerçek profille uyumlu; CPU throttling ve memory OOM davranışı peak testinde ölçüldü.
• HPA sinyali leading indicator kullanıyor; CPU'dan önce queue age veya concurrency gerekiyorsa uygulandı.
• Cluster autoscaler quota, IP, subnet, image pull ve scheduling kısıtlarıyla birlikte test edildi.
• Startup, readiness ve liveness probe'ları overload altında restart loop üretmiyor.
• JVM GC, heap, thread pool; .NET thread starvation; runtime connection pool metrikleri görünür.
• Pod disruption budget ve topology spread, failure domain kaybında kalan kapasiteyi koruyor.

Application ve API

• Her downstream çağrıda deadline, bounded retry, idempotency ve cancellation davranışı tanımlı.
• N+1 query, pahalı serialization, büyük payload ve senkron fan-out profilleri giderildi veya sınırlandı.
• Circuit breaker threshold ve half-open davranışı test edildi; recovery sırasında thundering herd oluşmuyor.
• Concurrency limit ve queue bound açık; sınırsız in-flight request kabul edilmiyor.
• İş hataları teknik error rate içinde kaybolmuyor; checkout rejection ile system failure ayrılıyor.

Database ve data platform

• Peak TPS, connection, lock wait, buffer cache, IOPS, log flush ve replication lag sınırları ölçüldü.
• Hot partition, hot key ve kampanya ürünü için skew testi yapıldı.
• Read replica lag durumunda stale read ve read-your-writes kararları journey bazında yazılı.
• Failover sırasında write fencing, transaction retry ve duplicate write davranışı test edildi.

Cache, queue ve streaming

• Cache hit ratio yanında origin amplification, eviction, memory fragmentation ve hot key izleniyor.
• Cache stampede için jittered TTL, request coalescing veya single flight uygulandı.
• Queue depth yanında oldest message age, arrival rate, completion rate ve dead letter ölçülüyor.
• Consumer scaling partition sayısı, ordering ve downstream kapasiteyle uyumlu.
• Duplicate delivery ve out-of-order message için idempotent consumer davranışı test edildi.
• Backlog drain süresi kampanya sonrası recovery SLO içinde hesaplandı.

Third party ve vendor

• Quota, burst, concurrent connection ve günlük limitler yazılı olarak doğrulandı.
• Vendor, kampanya tarihi, beklenen hacim ve escalation contact bilgisiyle bilgilendirildi.
• Timeout, 429, partial response ve schema deviation senaryoları simüle edildi.
• Fallback provider veya manuel süreç için veri tutarlılığı ve reconciliation planı var.
• Vendor status page tek sinyal değil; bağımsız synthetic ölçüm bulunuyor.
• Support contract, severity tanımı ve escalation süresi event command planına işlendi.

Peak günü runbook'u

Bu bölüm genel bir iskelet sunar; her ortam için komut, dashboard, owner ve escalation bağlantıları kurumun kendi sistemlerine göre eklenir. Aynı iskelet 11.11, Black Friday ve Cyber Monday için ayrı ayrı koşulur.

Canlı karar eşikleri

Eşikler örnektir; boş bırakılan değerler kendi SLO'nuzdan doldurulur.

Scale-down için güvenlik koşulları

• Offered load belirlenen süre boyunca düşüş trendinde.
• Queue ve streaming backlog hedef recovery süresinde boşalıyor.
• Cache hit ratio ve database load normalleşti.
• Geç gelen webhook, batch ve reconciliation trafiği hesaplandı.
• Bir sonraki coğrafi peak veya kampanya dalgası başlamadan önce yeterli süre var.
• Scale-down, failure domain başına minimum failover capacity'yi koruyor.

Ara değerlendirme ve kampanya sonrası

İlk peak'i ikincisinin provası olarak kullanın. 11.11'den sonraki günlerde kısa bir ara değerlendirme yapın ve bulguları Black Friday'den önce kapatın. Kasım bittiğinde büyüttüğünüz kaynakları (autoscaling alt sınırları, geçici sunucular, büyütülmüş database sınıfları) geri küçültmeyi takvime bağlayın; aksi hâlde aralık faturasına yansır.

Kampanya problemsiz geçtiğinde de review yapılır. Hazırlık programının hangi varsayımları doğru çıktı, hangi kapasite kullanılmadı, hangi alarm gereksizdi ve hangi manuel müdahale gelecekte otomatikleştirilebilir soruları cevaplanır. Bu notlar bir sonraki kampanyanın yük testi senaryosu olur.

Kaldır, standartlaştır veya ürünleştir

Kampanya hazırlığında üretilen her geçici mekanizma üç gruptan birine atanır: kaldır, standartlaştır veya ürünleştir. Resiliency Matrix, synthetic journey, capacity model ve incident drill gibi kabiliyetler yalnızca Black Friday için bırakılmaz; normal operasyon standardına eklenir. Böylece bir sonraki peak hazırlığı sıfırdan başlamaz.

Aksiyon kalite kriteri

• Aksiyon belirli bir failure mechanism'i azaltır; genel iyileştirme ifadesi değildir.
• Owner ve tarih bulunur; başarı metriği ölçülebilir.
• Mümkünse guardrail veya otomatik kontrol hâline getirilir.
• Aynı sınıf incident'i diğer servislerde de arayan yatay tarama içerir.
• Tamamlandığında aynı test veya Game Day senaryosuyla yeniden doğrulanır.

Bu rehber yaşayan bir standarttır. Her yüksek etkili incident, başarısız test veya kampanya review'u sonrasında kontrol listesine yeni bir madde eklenebilir; yeni madde belirli bir failure mechanism'e, açık bir kanıta ve uygulanabilir bir owner modeline dayanmalıdır. Yılda en az bir kez sahiplik, araç bağlantıları ve risk eşikleri gözden geçirilir.

Anti-pattern kataloğu

Aşağıdaki cümleler readiness toplantılarında sık duyulur ve her biri bir kanıt boşluğunu örter.

Kontrol tablosu · yazdırıp doldurun

On madde, iki kampanya sonrası iş; her satırda bir sorumlu ve bir tarih. Tabloyu kasım başlamadan doldurun. Freeze dönemlerinde yalnız "Durum" sütunu güncellenir; yeni iş eklenmez.

Event readiness ana kaydı

Kampanya başında tek sayfada doldurulur: kampanya ve tarih, Event Commander, teknik lider, kritik journey'ler, tahmini peak ve burst, freeze başlangıcı, go / no-go tarihi, war room, vendor escalation. Yedi kapı özeti aynı sayfada yer alır: her kapı için owner, kanıt, durum (R / A / G) ve açık risk.

Runbook doğrulama kaydı

• Runbook başka bir ekip üyesi tarafından uygulanabildi (tatbikat kaydı)
• Tüm komut ve bağlantılar güncel (kontrol tarihi)
• Gerekli production yetkileri doğrulandı (access test)
• Rollback adımı gerçek ortam benzerinde denendi (test run)
• Recovery condition açık ve ölçülebilir (dashboard)
• Escalation kişi ve süreleri güncel (roster)

Eclit notu: Sisteminizin sınırını müşterilerinizden önce siz öğrenin.

Bu kontrollerin bir kısmını sürekli hizmet olarak da yürütüyoruz: 7/24 izleme, performans ve kapasite analitiği, yedekleme ve kurtarma ve uygulama güvenliği (WAF). Serinin bir önceki sayısında Terraform drift'i ve "No changes" çıktısının neyi kanıtlamadığını incelemiştik.

Every Friday. One Production Check.

Kaynaklar

Kontrol listeleri ve karar kapıları kaynakların birebir kopyası değildir; ortak reliability ilkelerinin kampanya dönemine uygulanmış hâlidir. Aşağıdaki sayfaların tamamı 30 Ekim 2026'da açılıp kontrol edildi.

• Shopify Engineering, How we prepare Shopify for BFCM (2025), Kyle Petroski ve Matthew Frail, 20 Kasım 2025: scale test programı, Game Day, kritik journey odaklı hazırlık
• Shopify Engineering, Performance Testing at Scale: for BFCM and Beyond, Jordan Neufeld, 27 Ocak 2023: full-scale test, CDN arkasından ve cache busting ile test
• Shopify Engineering, Resiliency Planning for High-Traffic Events, Ryan McIlmoyl, 10 Aralık 2020: Resiliency Matrix
• Google SRE Book, Introduction: kesintilerin yaklaşık %70'inin canlı sistemde yapılan bir değişiklikten kaynaklandığı (madde 03)
• Google SRE Book, Handling Overload: retry budget, client-side throttling
• Google SRE Book, Addressing Cascading Failures: load shedding, graceful degradation, retry amplification
• Google SRE Workbook, Managing Load: overload kontrolü
• Google SRE Workbook, Incident Response: incident command rolleri, war room düzeni
• AWS Well-Architected, Operational Readiness Reviews: readiness review ve kanıt kapıları yaklaşımı
• Microsoft Azure Well-Architected, Deployment and testing for mission-critical workloads: failover under load, chaos ve freeze pratikleri
• Imperva, 2026 Bad Bot Report duyurusu, 5 Mayıs 2026: web trafiğinin %53'ünden fazlasının botlardan geldiği (madde 08)
• DigiCert, CA/Browser Forum SC-081v3 sertifika süresi takvimi: 15 Mart 2026'dan itibaren 200 gün, 15 Mart 2027'den itibaren 100 gün, 15 Mart 2029'dan itibaren 47 gün (madde 09)