Canlı Bir Ürünü Rescue Ederken İlk Nereye Bakarım?
Canlı üründe ilk hareket kod değiştirmek değildir. Önce production gerçeği, etki alanı, canonical source, mutation path ve release zinciri doğrulanır; sonra minimum doğru müdahale yapılır.
Canlı ürün bozulduğunda hız önemlidir.
Ama hızlı kod yazmak ile hızlı teşhis aynı şey değildir.
Yanlış yere hızlı patch atmak, özellikle state veya data probleminde hasarı büyütebilir.
Bu yüzden rescue çalışmasına ilk olarak kod değiştirerek başlamıyorum.
1. Production gerçeğini sabitliyorum
Önce şu sorular:
- Sorun canlıda gerçekten var mı?
- Hangi URL / platform / version etkileniyor?
- Hangi commit veya build canlı?
- Her kullanıcıda mı, belirli state’te mi?
- Ne zamandan beri?
- Son release ile korelasyon var mı?
Bu sorular olmadan local’de gördüğüm şeyin production’daki sorunla aynı olduğunu varsayamam.
2. Data-loss veya destructive risk var mı?
İkinci öncelik kullanıcı verisi.
Sorun sadece görsel mi? Mutation yanlış entity’ye mi gidiyor? Delete/archive davranışı karışıyor mu? Offline queue duplicate yazabilir mi? Stale client yeni data’yı ezebilir mi?
Data-loss ihtimali varsa UX polish bekler.
Önce writer’ı durdurmak veya riskli flow’u sınırlandırmak gerekebilir.
3. Semptomu değil zinciri çıkarıyorum
Örneğin “not tıklayınca yanlış panel açılıyor.”
Bunu task’a çevirip component’e girmek yerine akışı çıkarırım:
Tap → event → selection → route/panel state → domain action → persistence → lifecycle restore
Sonra hangi adımda beklenen ile gerçek ayrılıyor bakarım.
4. Canonical source ve writer’ları buluyorum
Data problemi varsa şu harita kritik:
Canonical source → UI writer → mutation path → optimistic state → background writer → hydration/apply → realtime/invalidation → retry/resume → restore/migration → legacy writer
Bir ürün beklenmedik state’e dönüyorsa çoğu zaman yalnız “read” tarafına bakmak yetmez.
Bir şey o yanlış state’i yazmıştır.
5. Shared cause arıyorum
Semptom birden fazla route veya platformda görünüyorsa ortak katmanı kontrol ederim.
Shared component. Domain service. Store. Query cache. Platform adapter. Data migration. Design token.
Local patch ancak root cause gerçekten lokalse doğrudur.
6. Minimum doğru müdahale
Root cause belli olduktan sonra hedef “en küçük diff” değil, “en küçük doğru scope”.
Bazen tek satırdır. Bazen shared state ownership’i düzeltmektir. Bazen legacy restore path’ini kaldırmak gerekir.
Gereksiz refactor yapmam.
Ama root cause shared katmandaysa semptomun olduğu component ile sınırlı kalmam.
7. Build’den sonra davranışı doğruluyorum
Rescue işinde “test geçti” önemli ama yeterli değil.
Render. Interaction. Responsive. Accessibility. Platform behavior.
Sorun mobildeyse gerçek mobil davranış özellikle doğrulanmalı.
Back button veya gesture problemi browser click simülasyonuyla kapanmış sayılmaz.
8. Live verify
Son adım yine production.
Beklenen commit canlı mı? Kritik flow gerçekten düzeldi mi? Eski asset kalmış mı? Yeni fix başka yüzeyi bozdu mu?
Rescue ancak canlı gerçeklik değiştiğinde tamamlanır.
Neden bu kadar disiplin?
Çünkü canlı ürünlerde en pahalı hata bazen bug değildir.
Yanlış teşhis yüzünden art arda eklenen patch’lerdir.
Her patch sistemi biraz daha anlaşılmaz yapar.
Üçüncü patch’e geldiyseniz çoğu zaman problem “yeterince patch atmadık” değildir.
Model yanlış olabilir.
Sonuç
Rescue, hızlı bug fix hizmeti değildir.
Bir canlı sistemi tekrar anlaşılır, güvenilir ve kontrol edilebilir hâle getirmektir.
İlk baktığım yer component değil.
Gerçeğin nerede bozulduğudur.
Rescue & Ownership
Canlı üründe semptom yamalamak yerine production gerçeğini, root cause'u, release zincirini ve operasyonel sahipliği birlikte ele alan müdahale notları.