Bayi Hostingde Bir Müşteri Kaynakları Tüketiyorsa Ne Yapılmalı?

Bayi hesabınızdaki bir müşteri kaynakları tüketiyorsa önce ölçün: hangi hesap, hangi kaynak (işlemci, bellek, eşzamanlı işlem, disk), hangi saatlerde? CloudLinux kullanan sunucularda bayi arayüzünün geçmiş kullanım ekranı ve müşterinin cPanel'indeki kaynak kullanım ekranı bunu gösterir, sitenin erişim günlüğü de nedenini. Neden çoğu zaman dört gruptan birindedir: bot ya da saldırı trafiği, ele geçirilmiş site, ağır eklenti veya cron, gerçek büyüme. İlk üçü teknik müdahaleyle düzelir, dördüncüsü paket kararıdır. Müşteriyi ölçümle bilgilendirin, askıya almayı ancak kendi sözleşmenize dayanarak son çare olarak kullanın.

Sorun gerçekten tek bir müşteriden mi geliyor?

Tipik durum şöyle başlar: üç dört müşteriniz aynı gün "site çok yavaş" diye yazar, belki biri 508 hatası görür, sağlayıcınızdan da bir kaynak uyarısı gelir. İlk refleks en büyük siteyi suçlamaktır. Bazen haklıdır, bazen değil.

Ayrımı yapmanın kolay bir yolu var. Yavaşlık yalnız yükü yüksek hesaplarda mı görülüyor, yoksa neredeyse hiç trafiği olmayan statik bir sitede de mi? Boş bir site de yavaşsa sorun büyük olasılıkla sunucunun genelindedir. O zaman ilk adres ana sağlayıcınızdır. Yavaşlık belirli hesaplarda yoğunlaşıyor ve bir hesabın tüketim grafiği aynı saatlerde zirve yapıyorsa doğru yerdesiniz.

Bayi paketindeki kaynağın nasıl paylaşıldığını, limit türlerini ve paylaşımlı sunucudaki komşu etkisini CloudLinux, CageFS ve LVE yazısında anlattık. Aşağıdaki adımlar bu kavramları bildiğinizi varsayıyor.

Bayi olarak neyi görebilirsiniz?

Bayi hesabı root değildir. Ne gördüğünüz, sağlayıcınızın size açtığı yetkilere ve sunucuda CloudLinux bulunup bulunmadığına bağlı. Elinizdeki kaynaklar kabaca şöyle:

CloudLinux belgelerine göre bayi arayüzündeki Historical Usage ekranı, son kullanıcıların sağlayıcının bayiye koyduğu sınırlara takıldığı anları grafikte gösteriyor. Belgede iki kısıt da var. Bayi, son kullanıcıları için SPEED, PMEM, IO, IOPS, EP ve NPROC sınırlarını ayarlayabiliyor ama inode ve MySQL sınırlarını ne kendisi ne de kullanıcıları için yönetemiyor. Müşterinin cPanel'inde bu ekran Metrics bölümünde, sürüme göre "CPU and Concurrent Connection Usage" ya da Resource Usage adıyla görünür.

Kaynak ekranında asıl bakılacak şey, hangi limitin kaç kez ve hangi saatlerde dolduğudur. Eşzamanlı işlem (EP) sınırı dolan sitelerde ziyaretçiler 508 Resource Limit Reached hatası görür, işlemci sınırında ise site hata vermeden yavaşlar. Biz burada site düzeyindeki teşhisten çok bayinin vereceği karara ve müdahale sırasına odaklanacağız.

Erişim günlüğünden nedeni bulun

Kaynak ekranı size "ne zaman" ve "hangi kaynak" sorularının cevabını verir. "Neden" sorusunun cevabı ise erişim günlüğündedir. Müşterinin cPanel'inde Metrics » Raw Access ekranından ilgili alan adının ham günlüğünü indirin ve kendi bilgisayarınızda inceleyin. Aşağıdaki komutlar standart birleşik (combined) günlük biçimini varsayıyor. Dosya adını indirdiğiniz dosyayla değiştirin:

# En çok istek atan 20 IP adresi
zcat erisim.gz | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# En sık görülen tarayıcı kimlikleri (user agent)
zcat erisim.gz | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -20

# Saat başına istek sayısı
zcat erisim.gz | awk '{print substr($4,2,14)}' | sort | uniq -c

# En çok istenen adresler
zcat erisim.gz | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Saat başına sayıyı kaynak ekranındaki zirveyle yan yana koyun. Zirve saatinde istek sayısı da patlamışsa sebep trafiktir. İstek sayısı normal ama kaynak tüketimi yüksekse sebep sitenin kendisidir: ağır bir eklenti, yavaş bir sorgu ya da arka planda çalışan bir iş.

İlk müdahale: önce konuşun, sonra kısın

Teknik önleme geçmeden müşteriye haber verin. Bu konuşma nezaketten öte, size bilgi de kazandırır. Belki o hafta kampanya başlattılar, belki yeni bir eklenti kurdular, belki de sitelerine biri dışarıdan erişiyor. Beş dakikalık bir telefon, saatlerce günlük okumaktan daha hızlı sonuç verebilir.

Saldırı trafiğinde müşterinin onayıyla hemen yapılabilecek birkaç şey var. WordPress'te XML-RPC'yi kullanan bir entegrasyon yoksa erişimi Apache 2.4 söz dizimiyle sitenin .htaccess dosyasından kapatabilirsiniz:

<Files "xmlrpc.php">
  Require all denied
</Files>

Değişiklikten sonra curl -I https://ornek.com.tr/xmlrpc.php komutuyla 403 döndüğünü doğrulayın. Bazı mobil uygulamalar ve eklentiler XML-RPC kullandığı için bunu müşteriye sormadan yapmayın. Giriş sayfası için deneme sınırı ve iki adımlı doğrulama, tek tek IP engellemekten daha kalıcı bir çözümdür. Belirli IP'leri engellemek ise kısa vadeli bir yamadır, saldırgan adres değiştirir.

Ağır cron işlerinde ilk şüpheli çoğu zaman her ziyaretçi isteğinde tetiklenen wp-cron'dur. Onu sunucu cron'una taşımak hem zirveleri yumuşatır hem de işin ne zaman çalıştığını öngörülebilir kılar. Müşterinin kendi kurduğu zamanlanmış görevler beş dakikada bir ağır bir rapor çalıştırıyorsa seyreltmek yeterli olabilir.

Ele geçirilmiş bir site ise başka bir kategori. Burada kaynak sorunu bir belirtidir, asıl iş olay müdahalesidir. Hacklenen müşteri sitesine müdahale sırası yalıtma, parola değişimi ve temizlikle başlar ve kaynak tüketimi de genellikle bu adımlarla düşer.

Peki müşteri ulaşılamıyorsa ya da tüketim diğer bütün müşterilerinizi etkiliyorsa? İki ara adımınız var. CloudLinux bayi limitleri açıksa o kullanıcının sınırlarını geçici olarak düşürmek, siteyi kapatmadan diğerlerini korur. Bu yetki yoksa WHM'den hesabı askıya almak (Manage Account Suspension) kalır. Askıya alma güçlü bir adımdır: müşterinin sitesi o süre boyunca yayında olmaz. Bu kararın dayanağı ise teknik ölçüm kadar sözleşmenizdir. Kendi müşteri sözleşmenizde adil kullanım ve askıya alma koşullarını düzenleyen madde neyse ona dayanın. Böyle bir madde yoksa ya da belirsizse, hukuk danışmanınızla konuşmadan kalıcı bir yaptırım uygulamayın.

Müşteriye ne yazmalı?

İyi bir bildirim suçlamaz, ölçüm gösterir. Hangi kaynağın, hangi saatlerde, ne kadar süre sınırda kaldığını yazın. Ne yaptığınızı ve müşteriden ne beklediğinizi de ekleyin. Varsayımsal bir örnek:

Konu: ornek.com.tr - kaynak kullanımı hakkında

Merhaba,

Barındırdığımız ornek.com.tr sitesinde 27 ve 28 Ekim
tarihlerinde, 14.00-17.00 arasında eşzamanlı işlem
sınırına tekrar tekrar ulaşıldığını gördük. Aynı saatlerde
erişim günlüğünde wp-login.php adresine birkaç IP'den
yoğun giriş denemesi var.

Yaptıklarımız:
- Bu IP'leri geçici olarak engelledik.
- Sitenin diğer sayfalarına dokunmadık.

Sizden ricamız:
- Yönetici parolalarını değiştirmeniz,
- Giriş sayfası için iki adımlı doğrulamayı açmamız
  konusunda onay vermeniz.

Tüketim aynı düzeyde sürerse sözleşmemizdeki
adil kullanım maddesi kapsamında paket değişikliğini
konuşmamız gerekecek.

Saygılarımızla

Mesajı tek bir kanaldan, kayıt tutulan bir yerden gönderin. Telefonda konuştuysanız da aynı özeti yazılı olarak iletin. Paket değişikliği ya da ek ücret konuşması gelecekse rakamları ilk mesajdan önce hazırlayın, yoksa ikinci yazışmada pazarlık başlar.

Kalıcı karar: optimizasyon mu, üst paket mi, ayrı sunucu mu?

İlk müdahaleden sonra bir iki hafta ölçmeye devam edin. Tüketim normale döndüyse iş bitmiştir, olayı ve yaptığınız değişiklikleri müşterinin kaydına not edin. Dönmediyse ve günlükler gerçek ziyaretçi artışını gösteriyorsa, artık teknik değil ticari bir karar veriyorsunuz.

Bayi havuzunuzda yer varsa müşteriyi daha yüksek limitli bir pakete almak ilk seçenektir. Bunun fiyata yansıması gerekir ve bayi hostingte fiyatlandırma yaparken hesap başı maliyeti hesaba katmadıysanız şimdi tam zamanı. Havuzun kendisi zorlanıyorsa, yani birden çok müşteri birlikte büyüyorsa, konu tek müşteriden çıkıp bütün paketin kapasitesine döner. Bunun eşiklerini bayi hostingte kapasite planlama rehberinde ele aldık.

Açıkçası bir müşterinin bütün bayi havuzunu düzenli olarak zorlaması, o sitenin paylaşımlı modele artık sığmadığının işaretidir. Bu durumda müşteriyi kaynakları kendisine ayrılmış bir sunucuya taşımak hem onun hem diğer müşterilerinizin işine gelir. Netx'te bu geçiş için KVM tabanlı VPS sunucular bir seçenek. Aynı sunucuya ileride başka sitelerin de gelip gelemeyeceğini hesaplamak için bir sunucuda kaç site barındırılabileceğini bellek ve işlemci bütçesiyle çıkarmak gerekir.

Önleme: limitleri ve kuralları baştan koyun

Aynı sorunu bir daha yaşamamanın yolu, sınırları sorun çıkmadan önce yazmaktır. Bizim önerdiğimiz düzen şu:

1. WHM'de her paket kademesine gerçekçi disk, bant genişliği, e-posta ve veritabanı değerleri verin. CloudLinux bayi limitleri açıksa her kademeye işlemci, bellek ve eşzamanlı işlem sınırı da tanımlayın.
2. Haftada bir Historical Usage ekranındaki en çok tüketen beş kullanıcıya bakın. Aynı isim üç hafta üst üste listedeyse konuşmayı şikâyet gelmeden başlatın.
3. Müşteri sözleşmenizde adil kullanım tanımını, askıya alma koşullarını ve bildirim sürecini yazılı hâle getirin.
4. Faturalama otomasyonu kullanıyorsanız, ödeme dışı nedenle askıya aldığınız hizmetlerin ödeme gelince kendiliğinden açılmadığından emin olun. WHMCS'te askıya alma otomasyonu elle verilen ve neden yazılan askıları bu yüzden ayrı tutar.
5. Yeni müşteri alırken site tipini ve beklenen trafiği sorun. Paketinize uymayan bir siteyi baştan doğru yere yönlendirmek, sonradan taşımaktan kolaydır.

Ana sağlayıcıya ne zaman yazmalı?

Elinizdeki ekranlar nedeni göstermiyorsa, sorun sunucunun genelinden geliyor gibi görünüyorsa ya da MySQL sorgu yükü ve çalışan işlemlerin listesi gibi root gerektiren verilere ihtiyacınız varsa ana sağlayıcınıza yazın. Netx'in cPanel/WHM bayi hosting hesabını kullanıyorsanız bunu müşteri panelinden destek talebiyle yaparsınız. Talebe şunları ekleyin: hesabın cPanel kullanıcı adı, sorunun yaşandığı saat aralığı (Türkiye saatiyle), gördüğünüz belirti ve hata mesajları, kaynak ekranındaki gözlemleriniz ve o ana kadar yaptığınız müdahaleler. "Sitem yavaş" diye başlayan bir talep ile "kullanici3 hesabı 27 Ekim 14.00-17.00 arasında EP sınırında, günlükte wp-login denemeleri var, IP engeli koyduk ama düşmedi" diye başlayan talep arasında çözüm süresi açısından ciddi fark vardır.

Sık sorulan sorular

Müşteriye haber vermeden hesabını askıya alabilir miyim?

Teknik olarak WHM buna izin verir. Yapıp yapamayacağınız ise müşterinizle aranızdaki sözleşmeye bağlıdır. Acil bir güvenlik durumunda önce askıya alıp hemen ardından bildirim yapmak yaygın bir uygulamadır, ama bunun da sözleşmede tanımlı olması iyi olur.

Bir müşterinin aşırı kullanımı bütün bayi hesabımı riske atar mı?

Atabilir. Ana sağlayıcının kullanım koşullarında aşırı kaynak kullanımına ilişkin hükümler genellikle bayi hesabının tamamına uygulanır, çünkü sağlayıcının gözünde bayi paketi tek bir hizmettir. Kendi sağlayıcınızın koşullarını okuyun ve kaynak uyarılarını görmezden gelmeyin.

Kaynak tüketen müşteriden ek ücret almak doğru mu?

Ölçüme dayanıyorsa ve sözleşmede tanımlıysa evet. Sürpriz bir ek fatura yerine, ölçümü gösterip üst paket önermek müşteri ilişkisini daha az yıpratır.