Her şeyi bozan deploy sonrası rollback

main'e merge, yeşil pipeline, başarılı deploy — 10 dakika sonra hata oranı %0.1'den %15'e çıktı. Kullanıcılar logout oldu, session'lar bozuldu, support grubu doldu.
Kök neden: staging'de test edilmemiş bir migration değişikliği — staging eski veritabanına sahipti ve migration sadece main'in taze schema'sında temiz çalışmıştı. Pipeline yeşildi; gerçek veri kırıktı.
Rollback manueldi: registry'de önceki image'ı bul, tag'le, yeniden deploy. 45 dakika stres. "Son sürüme dön" butonu yoktu — sadece kubectl ve umut.
En kötüsü: 45 dakika boyunca migration'ın geri alınıp alınamayacağını bilmiyorduk. Backend ve DevOps aynı anda log okuyup tahmin ediyordu. Runbook'suz incident yavaş ilerler.
Incident sonrası yapısal değişiklikler: immutable image tag'ler (production'da asla latest), iki deploy slot (basit blue-green) ve gerçekçi veriyle zorunlu staging smoke test.
Yüksek riskli değişiklikler için feature flag ekledik — her şey için değil, rollback'in zor olduğu yerler: auth, ödeme, migration. Kurulum maliyeti düşük; değeri ilk incident'te belli olur.
Tek sayfalık runbook yazdık: incident commander kim, nasıl rollback, loglar nerede, kullanıcıya ne zaman haber. Basit ama gece 23:00'te herkes gerginken beyin checklist ister.
Yeşil pipeline yetmez — deploy sonrası da sağlıklı olmalısın. Artık her release'te deployer'ın error rate ve latency izlediği 15 dakikalık monitoring window var. Anomali = toplantısız rollback.