Gönderim Altyapısında Felaket Kurtarma: Sağlayıcınız Çökerse

Gönderim sağlayıcınız erişilemez oldu. Şifre sıfırlama e-postaları gitmiyor, sipariş onayları çıkmıyor, müşteriler arıyor. Sizin sunucunuzda hiçbir sorun yok — ama e-posta gönderemiyorsunuz.

Bu yazı, gönderim altyapısında yedeklilik kurmayı ele alıyor.

Tek Sağlayıcı Riski

Gönderim, çoğu sistemde tek bir dış bağımlılıktır:

• Sağlayıcı kesintisi.
• Hesap askıya alınması.
• Kota aşımı.
• Kimlik bilgisi sorunu.

İkinci madde teknik bir arıza değildir ama sonucu aynıdır: şikayet oranı yükselen bir hesap sağlayıcı tarafından geçici olarak durdurulabilir — ve bu, en kritik işlemsel e-postalarınızı da aynı anda durdurur.

Pazarlama tarafındaki bir hata, şifre sıfırlamayı da engellemiş olur.

Üçüncü madde ise beklenmedik bir trafik artışında yaşanır ve genellikle en kötü zamanda gelir.

Önce Trafiği Ayırın

Bu ayrım kurtarma planının temelidir: bir kesintide tüm gönderimi kurtarmaya çalışmak yerine yalnızca ilk üç satırı yedek kanala aktarmak, hem daha hızlı hem daha yönetilebilirdir.

Bülten birkaç saat gecikebilir; şifre sıfırlama gecikemez.

Bu ayrım aynı zamanda itibar korumasıdır ve normal işletimde de faydalıdır.

Yedek Sağlayıcı Kurmak

1. İkinci bir hesap açın.
2. Kimlik doğrulama kayıtlarını ekleyin.
3. Düşük hacimde sıcak tutun.
4. Geçiş mekanizmasını hazırlayın.

Üçüncü madde çok atlanan ama belirleyici bir detaydır: hiç kullanılmayan bir yedek gönderim hesabı, kriz anında devreye alındığında ısınmamış bir gönderici olarak davranır ve iletileriniz doğrudan spam klasörüne düşer.

Yedeklilik teknik olarak çalışır ama teslimat başarısız olur.

Çözüm, trafiğin küçük bir kısmını sürekli yedek kanaldan göndermektir. Böylece o kanal da itibar kazanır.

İkinci madde ise her iki sağlayıcının da gönderim kaydınızda yetkili olmasını gerektirir.

Kimlik Doğrulama Kaydı

• Her iki sağlayıcı kayıtta olmalı.
• Sorgu limitine dikkat edin.
• Her ikisi için imza tanımlayın.

İkinci madde teknik bir tuzaktır: gönderim yetkilendirme kaydında sorgu sayısı sınırlıdır ve birden fazla sağlayıcı eklemek bu sınırı aşabilir — sınır aşıldığında kayıt tamamen geçersiz sayılır ve iki sağlayıcı da doğrulanamaz.

Bu, yedeklilik kurarken ana kanalı da bozmak anlamına gelir.

Bu nedenle kayıt eklendikten sonra doğrulama araçlarıyla kontrol edilmelidir.

Gereksiz eski kayıtları temizlemek sınır sorununu genellikle çözer.

Geçiş Mekanizması

Üçüncü satır en iyi çözümdür ve uygulaması sanıldığı kadar zor değildir: gönderim kodunuz ana sağlayıcıdan hata aldığında otomatik olarak yedek sağlayıcıyı denerse, kesinti kullanıcıya hiç yansımaz.

Bu mantık birkaç satır kodla kurulabilir.

Ancak dikkat gerektiren bir nokta vardır: geçici hatalarda hemen yedeğe geçmek, ana kanalın itibarını kullanmayı bırakmak anlamına gelir.

Bu nedenle belirli sayıda başarısızlıktan sonra geçiş yapılmalıdır.

Kuyruk Kullanmak

Gönderimi kuyruğa almak dayanıklılığın temelidir:

1. Uygulama kuyruğa yazar.
2. İşçi gönderimi yapar.
3. Başarısızlıkta tekrar dener.
4. Sağlayıcı seçimi işçide yapılır.

Bu yapının değeri kesinti anında ortaya çıkar: kuyruk kullanan bir sistemde sağlayıcı kesintisi ileti kaybına yol açmaz — iletiler kuyrukta bekler ve servis döndüğünde gönderilir.

Kuyruk olmayan bir sistemde ise gönderim denemesi başarısız olur ve ileti kaybolur.

Dördüncü madde ise geçiş mantığını tek bir yere toplar. Uygulama kodu hangi sağlayıcının kullanıldığını bilmez.

Bu, sağlayıcı değiştirmeyi de kolaylaştırır.

Planı Test Etmek

• Ana sağlayıcıyı kasıtlı devre dışı bırakın.
• Yedeğin devraldığını doğrulayın.
• Teslimat oranını kontrol edin.
• Geri dönüşü de test edin.

Üçüncü madde en kritik doğrulamadır: yedek kanal teknik olarak çalışsa bile iletileri spam klasörüne düşüyorsa, kurtarma planınız işe yaramamış demektir — teslimat oranı ölçülmeden test tamamlanmış sayılmaz.

Bu test, yedek kanalın sıcak tutulmasının neden gerekli olduğunu da gösterir.

Dördüncü madde ise ana kanal döndüğünde geri geçişi kapsar ve genellikle atlanır.

Test, düşük trafikli bir zamanda ve gerçek adreslere yapılmalıdır.

Kesinti Sırasında İletişim

Birinci satır kesinti sırasında en etkili çözümdür: şifre sıfırlama kodunu e-postayla gönderemiyorsanız, kullanıcı zaten sitedeyken kodu doğrudan ekranda göstermek pratik bir geçici çözüm olabilir.

Bu, akış tasarımında önceden düşünülmelidir.

İkinci satır ise en kritik işlemler için gerçek bir alternatiftir ve önceden entegre edilmiş olmalıdır.

Dördüncü satır ise gelen çağrıları yönetir. Destek ekibi durumu bilmezse yanlış bilgi verir.

Kesinti Sonrası

1. Kuyruktaki iletileri kontrol edin.
2. Birikmişi kademeli gönderin.
3. Süresi geçenleri ayıklayın.
4. Etkilenen kullanıcıları belirleyin.

Üçüncü madde önemli bir ayrımdır: kesinti boyunca biriken doğrulama kodları artık geçersizdir ve gönderilmemelidir — kullanıcıya süresi dolmuş bir kod göndermek kafa karışıklığı ve gereksiz destek talebi üretir.

Bunlar kuyruktan temizlenmeli, kullanıcılar yeni kod istemeye yönlendirilmelidir.

İkinci madde ise ani bir gönderim dalgasını önler. Birikmiş binlerce iletiyi aynı anda göndermek yeni bir sorun üretir.

Dördüncü madde ise proaktif iletişim sağlar. Etkilenen kullanıcılara durum açıklanabilir.

Yedek gönderim kanalı ve kuyruk yönetimi altyapı seçiminizle doğrudan ilgilidir; kurumsal posta gönderim altyapısı planlarken ikinci bir kanal kurgusunu baştan değerlendirmek doğru olur.

Sonuç

Gönderim kesintisi her zaman teknik arızadan gelmez: şikayet oranı yükselen bir hesap askıya alınabilir ve pazarlama tarafındaki bir hata şifre sıfırlamayı da durdurur. Bu yüzden önce işlemsel ve pazarlama trafiğini ayırın. Yedek sağlayıcı kurarken en kritik detay şudur: hiç kullanılmayan bir yedek hesap, kriz anında ısınmamış gönderici gibi davranır ve iletileriniz spam'e düşer — trafiğin küçük bir kısmını sürekli oradan gönderin.

Sıkça Sorulan Sorular (SSS)

Sağlayıcım güvenilir, yedeğe gerek var mı?

Kesinti tek risk değildir. Şikayet oranı yükselen bir hesap sağlayıcı tarafından askıya alınabilir, kota aşılabilir veya kimlik bilgisi sorunu çıkabilir. Hepsinin sonucu aynıdır ve en kritik işlemsel e-postalarınız da aynı anda durur.

Yedek hesabı neden sürekli kullanmalıyım?

Çünkü hiç kullanılmayan bir gönderim hesabı kriz anında devreye alındığında ısınmamış bir gönderici olarak davranır ve iletileriniz doğrudan spam klasörüne düşer. Yedeklilik teknik olarak çalışır ama teslimat başarısız olur. Trafiğin küçük bir kısmını sürekli oradan gönderin.

İki sağlayıcı eklerken neye dikkat etmeliyim?

Gönderim yetkilendirme kaydındaki sorgu sınırına. Birden fazla sağlayıcı eklemek bu sınırı aşabilir ve sınır aşıldığında kayıt tamamen geçersiz sayılır — iki sağlayıcı da doğrulanamaz. Yani yedeklilik kurarken ana kanalı da bozarsınız. Ekledikten sonra doğrulama araçlarıyla kontrol edin.

Kesinti bitince birikmişleri göndermeli miyim?

Seçerek. Süresi geçmiş doğrulama kodlarını göndermeyin — kullanıcıya artık geçersiz bir kod göndermek kafa karışıklığı ve gereksiz destek talebi üretir. Geri kalanı da kademeli gönderin; binlerce iletiyi aynı anda göndermek yeni bir sorun yaratır.