Go‑live günü, teknik ekipler için “en iyi ihtimalle yoğun”, “en kötü ihtimalle incident” günüdür. Kurumsal yapılarda go‑live’ı pahalı yapan şey kod değil; operasyonel belirsizliktir: Kim karar veriyor, geri alma nasıl, alarm kime gidiyor, bağımlılıklar hazır mı?
ORR (Operational Readiness Review) bunu çözmek için vardır: Go‑live öncesi “her şey tamam mı?” toplantısı değil; riskleri görünür kılan ve karar kapısı olan bir ritim.
ORR’in amacı: “mükemmel hazırlık” değil, “kontrollü sürüm”
İyi bir ORR şu üç çıktıyı üretir:
- Go/No‑Go kriterleri netleşir (tartışma değil karar)
- Rollback / mitigasyon planı uygulanabilir olur
- Sahiplik yazılı hale gelir (kim, neyi, ne zaman yapacak?)
Minimum viable ORR checklist (sahada çalışan)
1) Mimari ve bağımlılıklar
- Kritik bağımlılıklar listeli mi? (DB, queue, kimlik, DNS, CDN, third‑party)
- Tekil nokta var mı? (single‑AZ / single‑region / single‑vendor)
- Değişiklik kapsamı net mi? (hangi servisler etkilenir?)
2) Kapasite ve performans
- Beklenen yük profili biliniyor mu? (pik saat, batch, kampanya)
- Limitler ve timeouts “uyumlu” mu? (queue/pool/timeout zinciri)
- Canary / ring planı var mı?
3) Observability ve alarm
- Dashboards hazır mı? (latency, error rate, saturation)
- Alarm kriterleri action‑oriented mı?
- On‑call/escalation zinciri net mi?
4) Güvenlik ve erişim
- Prod erişimleri least privilege mi?
- Break‑glass planı var mı? (kim, hangi şartta açar?)
- Audit log ve saklama gereksinimi karşılanıyor mu?
5) Rollback ve kurtarma
- Rollback “gerçekten” mümkün mü? (versiyon, data migrasyonu, feature flag)
- Geri alma süresi ve etkisi biliniyor mu?
- Veri uyumluluğu riski yazıldı mı? (forward‑only migration var mı?)
6) İş iletişimi
- Müşteri etkisi cümlesi hazır mı?
- Durum sayfası/iletişim kanalı kimde?
- Go‑live penceresi ve “dur” kararı kimde?
Go/No‑Go kararını nasıl netleştirirsin?
Kararı “hissetmek” yerine kriterle bağla. Örnek:
- Go: SLO dashboard hazır, rollback yolu testli, on‑call hazır, kritik bağımlılıklarda alarm var
- No‑Go: Rollback yok, güvenlik erişim modeli belirsiz, kritik bağımlılık tekil, alarm/owner tanımsız
- Conditional Go: belirli riskler kabul edilerek, dar kapsam/canary ile
Operasyonel liderlik notu: ORR’ı yaşayan bir ritme çevir
- ORR çıktıları issue/ticket olarak sahiplikle açılır
- “Kapanmayan risk” bir sonraki ORR’de yeniden gelir (takip)
- Aynı risk sürekli geliyorsa: sorun teknik değil, organizasyonel olabilir
Sonuç
ORR, go‑live’ı “kahramanlık” işinden çıkarıp tekrar edilebilir bir operasyona dönüştürür. Doğru ORR; ekipleri yavaşlatmaz, tam tersine incident sayısını ve go‑live gecelerini azaltır. Çünkü en pahalı şey, kod değil; belirsizliktir.