Kısa yanıt
Otomasyon sunucusu, görevlerin ne yaptığına, ne sıklıkta çalıştığına ve aynı anda kaç iş yürüttüğüne göre seçilir. CPU, bellek ve disk kadar kuyruk, yedek, izleme ve yönetim sorumluluğunu da planlayın. Küçük bir pilotta gerçek iş yükünü ölçün. Paket adını veya yalnızca RAM miktarını kapasite kanıtı olarak kullanmayın.
Dört adımda uygulama rotası
BAŞLANGIÇ → SONUÇ- 01Tanımla
İş türü ve çalışma sıklığını yaz.
- 02Ölç
Yoğun saatte süre ve kaynakları izle.
- 03Koru
Yedek ve erişim düzenini kur.
- 04İzle
Geciken ve başarısız görevleri görünür tut.
Önce iş yükünü tarif edin
Otomasyon için sunucu seçerken ilk soru “kaç GB RAM?” olmamalı. İşin ne yaptığı, ne sıklıkta çalıştığı ve bir görevin ne kadar sürdüğü kaynak ihtiyacını belirler. Sadece bir API’den küçük veri alan görev ile video işleyen görev aynı sunucu planıyla değerlendirilmez.
Görev sayısını, ortalama ve yoğun saatlerdeki çalışma süresini, aynı anda çalışan iş sayısını ve tutulan veri miktarını kaydedin. Kesin kapasiteyi paket adından çıkarmak yerine kendi iş yükünüzle küçük bir ölçüm yapın. Sonucu başka bir uygulamanın garantisi gibi kullanmayın.
Zamanlayıcı ile görev kuyruğunu ayırın
Zamanlayıcı, bir işin ne zaman başlayacağını belirler; kuyruk, bekleyen işlerin kontrollü işlenmesini sağlar. Bir önceki çalışma bitmeden yenisi başlarsa aynı kayıtlar tekrar işlenebilir. Kilit, sabit görev kimliği ve eşzamanlı çalışma sınırı tasarlayın.
Örneğin her on dakikada veri alan bir görev bazen on beş dakika sürüyorsa yalnızca çalışma sıklığını artırmak çözüm değildir. Önce neden uzadığını ölçün. İşleri küçük parçalara ayırmak ve kaldığı yeri kaydetmek, kesintiden sonra tamamını yeniden çalıştırma ihtiyacını azaltabilir.
Örnek: API’den veri alan görev ile görsel işleyen görev
Bir görev saatte bir dış hizmetten küçük bir liste alıyor, diğeri yüklenen görselleri işliyor olsun. Birincisi zamanının önemli bölümünü ağ yanıtını bekleyerek geçirebilir; ikincisi işlemci veya belleğe daha fazla ihtiyaç duyabilir. İki işin dosya sayısı aynı olsa bile kaynak davranışı aynı değildir. Bu yüzden yalnızca görev adedini ölçmek yeterli olmaz.
Pilotta başlangıç ve bitiş zamanı, işlenen kayıt miktarı, hata sayısı ve kaynak kullanımı birlikte kaydedilsin. Görev uzadığında bunun dış hizmetin yanıtından mı yoksa yerel işlemden mi kaynaklandığı araştırılsın. Ağ bekleyişi ağır basıyorsa daha güçlü sunucu sorunu sınırlı ölçüde etkileyebilir.
Bir sonraki çalışmanın önceki bitmeden başlaması da yükü büyütebilir. Eşzamanlı iş sayısı sınırını ve yarım kalan kaydın nasıl devam edeceğini belirleyin. Sağlayıcıyla kaynak artışı görüşürken bu ölçüm notu, “uygulama yavaş” ifadesinden daha kullanışlı bir ihtiyaç tarifi sunar.
Bu senaryo açıklama amacıyla hazırlanmıştır; gerçek müşteri sonucu veya ürün testi değildir.
Sunucu teklifinde hangi alanlar bulunmalı?
| Alan | Sorulacak soru |
|---|---|
| Kaynak | CPU, RAM ve disk sınırları nasıl uygulanıyor? |
| Yönetim | Güncelleme ve olay müdahalesi kimin sorumluluğunda? |
| Yedek | Nerede tutuluyor, geri yükleme nasıl yapılıyor? |
| Ayrılma | Veriler hangi biçimde dışarı alınabiliyor? |
Bu ihtiyaç listesini hazırladıktan sonra bize ait Online Sunucu projesinin seçeneklerini inceleyebilirsiniz. Bağlantı bağımsız performans testi değildir. Güncel kaynaklar, destek kapsamı ve toplam maliyet için sağlayıcıdan yazılı bilgi alın.
Başarıyı ve sessiz hataları izleyin
Sunucunun açık olması işlerin doğru tamamlandığını göstermez. Son başarılı çalışma zamanı, bekleyen görev sayısı, başarısız görev sayısı ve en eski görevin yaşı gibi ölçüler tutun. Beklenen saatte hiçbir işlem başlamaması da uyarı nedeni olsun.
Yedek dosyasının varlığıyla yetinmeyin; test ortamına geri yükleyip uygulamanın gerekli veriye eriştiğini doğrulayın. Erişim anahtarlarını kod deposundan ayrı tutun. Günlük saklama süresini belirleyerek sınırsız dosya büyümesinin diski doldurmasını önleyin.
Kaynak, süreklilik ve yönetim ayrı kararlar
| Karar alanı | İstenecek bilgi | Pilot kontrolü |
|---|---|---|
| Kaynak | CPU, RAM, disk ve ağ sınırlarının uygulanışı | Gerçek görevin yoğun saat ölçümü |
| Süreklilik | Yedek konumu, kapsamı ve geri yükleme yolu | Örnek veriyi test ortamında geri açma |
| Yönetim | Güncelleme ve olay müdahalesinin sorumlusu | Bir hata bildirimini doğru kişiye ulaştırma |
Bir hizmetin yedek sunması, uygulamanın bütün bağımlılıklarının o yedekte bulunduğunu göstermez. Dosya, veritabanı, yapılandırma ve gerekli erişimler ayrı ele alınmalıdır. Geri yüklemenin kim tarafından ve hangi iş sırasıyla yapılacağı teklif kadar önemlidir.
Birden çok müşteriye kaynak açacaksanız
Sunucu sağlama işlemi de otomasyona bağlanacaksa müşteri siparişiyle sağlayıcı kaynağını tek bir kayıt üzerinden eşleştirin. Tekrarlanan istek yeni bir ücretli kaynak oluşturmamalı. İptal, yetersiz bakiye ve yarım kalan kurulum süreçlerini ayrıca tasarlayın.
Bize ait VDSHost projesini sunucu API ve bayilik kapsamı açısından bu sorularla değerlendirebilirsiniz. Güncel entegrasyon belgelerini doğrulayın; önce tek kaynaklı pilot çalıştırıp oluşan kaydı ve maliyeti kontrol edin.
Büyüme ve ayrılma planı
İlk kapasiteyi seçerken günlük ortalama kadar beklenen yoğunluğu da yazın. Ancak henüz oluşmamış trafiği kesin veri gibi sunmayın. Mevcut ölçümle geleceğe dair varsayımı ayrı sütunlarda tutmak, sonradan neyin değiştiğini anlamayı kolaylaştırır. Kaynak artışı gerekirse kesinti, taşıma ve geri dönüş biçimini sağlayıcıyla konuşun.
Sunucu bayiliği veya API ile kaynak oluşturma söz konusuysa müşteri siparişiyle sağlayıcı kaydını da eşleştirin. İptal edilmiş işin ücretli kaynağı açık kalıyorsa uygulama çalışsa bile operasyon tamamlanmış sayılmaz.
0 / 4 adım kontrol edildi · Bu seçimler yalnızca açık sayfada tutulur.
Sık sorulan sorular
Otomasyon için mutlaka ayrı sunucu gerekir mi?
İş yüküne ve mevcut altyapının izinlerine bağlıdır. Küçük bir görevin mevcut ortamda çalışması mümkün olabilir. Kaynak sınırlarını, güvenlik ayrımını ve zamanlama desteğini doğrulamadan ayrı sunucu gerekliliği varsaymayın.
Yedek varsa görevleri izlemek gerekli mi?
Evet. Yedek, beklenen görevin bugün çalıştığını göstermez. Son başarılı işlem ve kuyruk yaşı gibi iş ölçülerini ayrı izleyin. Ayrıca yedeğin geri yüklenebilirliğini sınayın.
Sunucu açıkken rapor neden gelmez?
Görev tetiklenmemiş, işlem yarıda kalmış veya sonuç bildirimi gönderilememiş olabilir. Sistem erişimini, görev sonucuyla aynı gösterge olarak kullanmayın; her aşamanın kaydını inceleyin.
Ölçüm için sadece ortalama CPU değerine bakmak yeterli mi?
Görevin davranışına göre bellek, disk, ağ bekleyişi, çalışma süresi ve aynı anda işlenen kayıtlar da önemlidir. Günlük ortalama yoğun anları gizleyebilir. Ölçümü işin gerçekleştiği saatle ilişkilendirin; kaynak grafiğinin yanında beklenen çıktının zamanında oluşup oluşmadığını da kaydedin. Böylece kapasite sorusunu iş sonucuyla bağlarsınız.
Yöntem ve kaynak notu
Örnek senaryolar ve karar tabloları, konuyu açıklamak için hazırlanmış çalışma önerileridir. Ölçülmüş müşteri sonucu veya bağımsız ürün testi olarak sunulmaz. Platform ve ürün koşulları değişebileceğinden uygulama öncesinde ilgili resmi belgeyi ve kendi hizmet kapsamınızı kontrol edin.