Sunucuyu yeniden başlattınız ve site açılmadı. Elle bir komut çalıştırdınız, düzeldi. Bir daha yeniden başlattınız, yine açılmadı. Sorun uygulamada değil, servislerin hangi sırayla ayağa kalktığındadır.
Bu yazı, servis bağımlılıklarını ve başlatma sırasını ele alıyor.
Tipik Senaryo
Olayların gerçek sırası genellikle şudur:
- Sunucu açılır.
- Uygulama servisi başlar.
- Veritabanı henüz hazır değildir.
- Uygulama bağlanamaz ve çıkar.
- Veritabanı birkaç saniye sonra hazır olur.
- Ama uygulama artık çalışmıyordur.
Dördüncü adım kritik olandır: uygulama ilk bağlantı denemesinde başarısız olduğu için tamamen çıkar ve kimse onu tekrar başlatmaz — oysa birkaç saniye beklese sorunsuz çalışacaktır.
Bu, elle başlatınca neden çalıştığını da açıklar. Siz komutu çalıştırdığınızda veritabanı çoktan hazırdır.
Bağımlılık Tanımlamak
Servis yöneticisi bu ilişkiyi bilmelidir:
| Tanım türü | Anlamı |
|---|---|
| Sıralama | Önce şu başlasın |
| Gereklilik | O olmadan bu başlamasın |
| İstek | Tercihen başlasın, şart değil |
İlk iki satır sürekli karıştırılır ve ikisi birden gerekir: yalnızca gereklilik tanımlamak sıra garantisi vermez — iki servis aynı anda başlatılabilir ve yine aynı sorun yaşanır.
Doğru yapılandırma her ikisini de içerir: hem "buna ihtiyacım var" hem "ondan sonra başla".
Üçüncü satır ise isteğe bağlı bileşenler içindir. Önbellek sunucusu çalışmıyorsa uygulama yine de açılabilmelidir.
"Başladı" ile "Hazır" Farkı
Bağımlılık tanımlamak bazen yetmez:
- Servis süreci başlamıştır.
- Ama bağlantı kabul etmeye hazır değildir.
- Başlatma işlemleri sürüyordur.
Bu ayrım veritabanlarında çok belirgindir: bir veritabanı süreci saniyeler içinde başlar ama kurtarma ve indeks yükleme işlemleri nedeniyle bağlantı kabul etmesi dakikalar sürebilir.
Servis yöneticisi süreci "başladı" olarak işaretler ve sıradakini çalıştırır. Uygulama bağlanmaya çalışır ve reddedilir.
Çözüm, bağımlılık tanımına ek olarak uygulamanın kendisinin sabırlı olmasıdır.
Uygulamayı Dayanıklı Yapmak
Asıl çözüm uygulama tarafındadır:
- Bağlantı başarısız olursa hemen çıkmayın.
- Artan aralıklarla tekrar deneyin.
- Makul bir üst sınır koyun.
- Denemeleri günlüğe yazın.
İkinci madde doğru davranıştır: her denemede bekleme süresini artırmak, hem hızlı toparlanmayı hem de sürekli denemeyle kaynak tüketmemeyi sağlar.
Bir saniye, iki saniye, dört saniye şeklinde artan bir yaklaşım hem hızlı hem naziktir.
Üçüncü madde sonsuz döngüyü önler. Belirli bir süre sonra gerçekten bir sorun olduğu kabul edilmeli ve durum açıkça bildirilmelidir.
Bu davranış yalnızca açılış için değil, çalışma sırasındaki geçici kesintiler için de değerlidir.
Otomatik Yeniden Başlatma
Servis yöneticisinin bir başka özelliği devreye girer:
| Ayar | Etkisi |
|---|---|
| Her zaman yeniden başlat | Çıkış nedeni ne olursa olsun |
| Hatada yeniden başlat | Yalnızca başarısız çıkışta |
| Yeniden başlatma gecikmesi | Denemeler arası bekleme |
| Deneme sınırı | Sürekli döngüyü keser |
Üçüncü ve dördüncü satırlar birlikte önemli bir koruma sağlar: gecikme tanımlanmazsa çöken bir servis saniyede onlarca kez yeniden başlatılmaya çalışılır ve sunucuyu meşgul eder.
Dördüncü satırın ise bir yan etkisi vardır ve bilinmelidir. Sınıra ulaşıldığında servis tamamen durur ve elle müdahale gerekir.
Bu nedenle sınır, geçici sorunları kapsayacak kadar geniş olmalıdır.
Ağ Hazır Olma Sorunu
Bir başka klasik açılış hatası:
- Servis belirli bir IP adresini dinlemek ister.
- Açılışta o adres henüz atanmamıştır.
- Bağlanma başarısız olur.
Bu durum özellikle sabit IP yapılandırması yavaş tamamlanan sistemlerde görülür: servis belirli bir adrese bağlanmayı deneyip başarısız olur, oysa tüm arayüzleri dinleseydi sorun yaşamayacaktı.
Çözümler arasında ağın tamamen hazır olmasını beklemek, tüm arayüzleri dinlemek veya çekirdek düzeyinde henüz atanmamış adrese bağlanma izni vermek bulunur.
Doğrulamak
Yapılandırmanın çalıştığını test etmenin tek yolu vardır:
- Sunucuyu gerçekten yeniden başlatın.
- Hiçbir şeye dokunmadan bekleyin.
- Tüm servislerin durumunu kontrol edin.
- Açılış günlüklerini okuyun.
İkinci madde disiplin gerektirir: açılışta bir servisi elle başlatmak, sorunu çözmez sadece gizler — bir sonraki beklenmedik yeniden başlatmada aynı kesinti yaşanır.
Bu test, planlı bir bakım penceresinde yapılmalıdır. Beklenmedik bir yeniden başlatmada öğrenmek en kötü senaryodur.
Dördüncü madde ise sırayı ve süreleri gösterir. Hangi servisin ne kadar sürede hazır olduğu buradan okunur.
Yeniden başlatma testlerini planlı yapabilmek için panel üzerinden kontrol edebilmek gerekir; VDS sunucu altyapısı yönetim panelinden yeniden başlatma ve konsol erişimi doğrudan yapılabilir.
Sonuç
"Yeniden başlatınca çalışmıyor ama elle başlatınca çalışıyor" tablosunun nedeni nettir: uygulama ilk bağlantı denemesinde başarısız olup tamamen çıkar, oysa birkaç saniye beklese sorunsuz çalışacaktır. Servis yöneticisinde hem gereklilik hem sıralama tanımlayın; yalnızca gereklilik sıra garantisi vermez. Ama asıl çözüm uygulama tarafındadır — artan aralıklarla tekrar deneme, hem hızlı toparlanmayı hem kaynak israfını önlemeyi sağlar. Ve yapılandırmayı gerçek bir yeniden başlatmayla test edin.
Sıkça Sorulan Sorular (SSS)
Elle başlatınca neden çalışıyor?
Çünkü siz komutu çalıştırdığınızda veritabanı çoktan hazırdır. Açılış sırasında ise uygulama, veritabanı henüz bağlantı kabul etmeye hazır değilken başlar, ilk denemede başarısız olur ve tamamen çıkar. Kimse onu tekrar başlatmaz.
Bağımlılık tanımlamak yetmiyor mu?
Çoğu zaman yetmez. Birincisi, yalnızca gereklilik tanımlamak sıra garantisi vermez — hem gereklilik hem sıralama gerekir. İkincisi, servis yöneticisi süreci "başladı" olarak işaretler ama veritabanı kurtarma ve indeks yükleme nedeniyle dakikalarca bağlantı kabul etmeyebilir.
Kalıcı çözüm ne?
Uygulamayı dayanıklı yapmak: bağlantı başarısız olunca hemen çıkmayın, artan aralıklarla tekrar deneyin ve makul bir üst sınır koyun. Bir saniye, iki, dört şeklinde artan bekleme hem hızlı toparlanır hem kaynak tüketmez. Bu davranış çalışma sırasındaki geçici kesintilerde de işe yarar.
Nasıl test ederim?
Sunucuyu gerçekten yeniden başlatıp hiçbir şeye dokunmadan bekleyerek. Açılışta bir servisi elle başlatmak sorunu çözmez, sadece gizler — bir sonraki beklenmedik yeniden başlatmada aynı kesinti yaşanır. Bu testi planlı bir bakım penceresinde yapın.
