Yazılım dünyasında “canlıda hata çıkması” kaçınılmaz bir gerçektir. Soru şu değil: “Hata olur mu?” Asıl soru: “Hata olduğunda ne yapacaksınız?” Paniğe kapılmak, ortalığı birbirine katmak ya da sessizce geçiştirmeye çalışmak — bunların hepsi durumu daha da kötüleştirir. Ama doğru bir protokolle hareket edildiğinde, çoğu kriz yönetilebilir bir sürece dönüşür.
İşte bu yazıda, production ortamında bir hata çıktığında adım adım nasıl ilerleyeceğinizi ele alıyoruz.
1. İlk 5 Dakika: Sakin Kal, Önce Değerlendir
Hata bildiği anda refleks olarak “hemen düzelt” moduna geçmek, çoğu zaman yanlış bir hamle olur. Neyi düzelteceğinizi bilmeden hareket etmek, sistemi daha kırılgan hale getirebilir.
Bu ilk birkaç dakikada odaklanmanız gereken sorular:
- Hata ne zaman başladı?
- Kaç kullanıcıyı etkiliyor?
- Sistemin hangi parçası etkilendi?
- Belirli bir akış mı bozuk, yoksa her şey mi çöktü?
Bu soruları yanıtlamadan alınan aksiyonlar, sorunu çözmek yerine çoğunlukla yeni sorunlar doğurur.
2. Hatayı Sınıflandır — Her Bug Kriz Değildir
Her canlı hata aynı aciliyette değildir. Yanlış önceliklendirme, ekibi hem yorar hem de asıl önemli sorunu gözden kaçırmanıza neden olur.
Genel bir sınıflandırma şöyle yapılabilir:
- Kritik: Sistem tamamen çalışmıyor, kullanıcılar hiçbir şey yapamıyor. Hemen müdahale gerekli.
- Yüksek: Önemli bir özellik bozuk ama sistem ayakta. Kısa sürede çözülmeli.
- Orta: Belirli bir senaryoda hata var, çoğu kullanıcı etkilenmiyor. Planlanmış bir düzeltme yeterli.
- Düşük: Küçük bir görsel bozukluk ya da edge case. Bir sonraki release’e bırakılabilir.
Hatanın severity’sini doğru belirlemek, hem iletişiminizi hem de aksiyon planınızı şekillendirir.
3. İletişim Protokolü: Kim, Ne Zaman, Nasıl Haberdar Edilir?
Teknik ekip hatayı fark ettiğinde, iletişim genellikle en çok ihmal edilen adım olur. Oysa doğru iletişim, güveni korumanın ve panik yönetiminin temelidir.
- Ekip içi iletişim: İlk değerlendirme yapıldıktan hemen sonra, durumu sade bir şekilde ilgili kişilerle paylaşın. “Bilmiyoruz ama bakıyoruz” da bir bildirimdir.
- Müşteri / proje sahibi bildirimi: Hatanın kapsamına göre, müşteriyi erken bilgilendirmek sessiz kalmaktan her zaman daha iyidir. Belirsiz bir bildirim, bilgisizlikten iyi görünür.
- Son kullanıcıya şeffaflık: Eğer hata kullanıcıları doğrudan etkiliyorsa, kısa ve anlaşılır bir bilgilendirme yapmak güveni sarsmak yerine güçlendirir.
İletişimin zamanlaması kadar tonu da önemlidir. “Baktık, çözüyoruz” mesajı bile büyük bir fark yaratır.
4. Hızlı Karar: Rollback mı, Hotfix mi, Workaround mı?
Hatayı anladıktan ve ilgili kişileri bilgilendirdikten sonra, düzeltme yöntemi kararı gelir. Bu kararı doğru vermek kritiktir.
- Rollback: Son stabil versiyona geri dönmek. Hata yeni bir deploy sonrası çıktıysa ve hızlıca izole edilemiyorsa en güvenli seçenek.
- Hotfix: Hatayı doğrudan canlıda patch’lemek. Riskleri var — aceleyle yazılan kod yeni hatalar doğurabilir. Test adımını atlamayın.
- Workaround: Geçici bir çözümle kullanıcıların etkilenmesini engellemek. Kısa vadeli ama işe yarar. Kalıcı çözüm için zaman kazandırır.
Hangisini seçeceğiniz; hatanın kritikliğine, değişikliğin izole edilebilirliğine ve ekibinizin o anki kapasitesine göre belirlenir. Tek doğru cevap yoktur.
5. Düzeltme Sonrası: İş Bitmedi
“Düzelttik” demek sürecin sonu değildir. Production’da yapılan her değişiklik, özellikle kriz anında yapılanlar, mutlaka doğrulanmalıdır.
Düzeltme sonrası yapılması gerekenler:
- Hata senaryosunu tekrar test edin — düzeldi mi gerçekten?
- Yan etki kontrolü yapın — başka bir şeyi bozmadınız mı?
- Logları ve monitoring araçlarını izlemeye devam edin.
- Etkilenen kullanıcılara veya müşteriye çözüm bildirimini yapın.
Kriz anında yapılan bir hotfix, yeterli doğrulama olmadan başka bir hatanın fitilini ateşleyebilir. Aceleyle kapatılan bir ticket çoğu zaman daha büyük bir ticket olarak geri döner.
6. Post-Mortem: Aynı Hatayı Bir Daha Yaşamamak
Kriz geçtikten sonra yapılacak en değerli şey, retrospektiftir. Buradaki amaç suçlu bulmak değil, sistemi güçlendirmektir.
Bir post-mortem’de yanıtlanması gereken sorular:
- Hatanın kök nedeni neydi?
- Neden yayına çıkmadan fark edilmedi?
- Hangi süreç veya kontrol eksikti?
- Bir dahaki seferde farklı ne yapabiliriz?
İyi bir post-mortem, ekibin birbirine güvenini pekiştirir. Hatayı yaşayan ekip, onu çözme kapasitesi de olan ekiptir — önemli olan buradan öğrenmektir.
Son Söz
Production hatası bir başarısızlık değil, her yazılım sürecinin kaçınılmaz bir parçasıdır. Sizi diğerlerinden ayıran şey hatanın çıkmaması değil; çıktığında nasıl hareket ettiğinizdir.
Protokol, panikten daha güçlüdür.
Ve eğer bu sürecin hiçbir adımına gelmek istemiyorsanız — yayına çıkmadan önce bir bağımsız göz değerli olabilir. Vidius Project tam da bunun için burada.