İşletim gereksinimleriyle başlayın
Yapılandırmaları karşılaştırmadan önce her projenin uygulama yığınını, veritabanını, yüklemelerini, zamanlanmış görevlerini, entegrasyonlarını ve beklenen değişikliklerini toplayın. Kimin içerik erişimine, dağıtım erişimine ve ana bilgisayar yönetimine ihtiyacı olduğunu belirleyin. Bunlar farklı işlerdir. Bir sayfayı düzenleyen müşterinin yalnızca bir uygulama hesabına ihtiyacı olabilir; işletim sistemini yöneten bir yüklenicinin çok daha geniş yetkiye ihtiyacı vardır.
Ayrıca kabul edilebilir bakım penceresini, kesinti süresini kimin onayladığını, kurtarma kopyalarının nerede tutulduğunu ve operasyonel işlerin bedelini kimin ödediğini kaydedin. Ayrı bir sunucu veya hesap için müşteri gereksinimini bir karar kısıtı olarak not edin. Bir kaynak tablosu, bir sahiplik veya erişim gereksinimini çözemez.
- Her proje için birincil operatörü ve bir yedeği adlandırın.
- Paylaşılan bağımlılıkları listeleyin: DNS erişimi, dağıtım kimlik bilgileri, veritabanı hizmetleri ve yedekleme hedefleri.
- Bir düzenlemeyi taahhüt etmeden önce müşteri kararı için bilinmeyen gereksinimleri işaretleyin.
Sunucu boyutundan önce erişim sınırını seçin
OWASP, bir kişinin işi için gereken izinlerin verilmesini ve amaçlanan kısıtlamaların geçerli olduğunun doğrulanmasını önerir. Bu ilkeyi barındırma planına uygulayın: bireysel kimlikler, projeye özel uygulama kimlik bilgileri ve belgelenmiş bir dağıtım yolu kullanın. Bir müşterinin adını taşıyan dizin, kurumsal bir yardımcıdır; erişim politikası değildir.
Docker kullanıyorsanız, daemon'ına erişimi ana makine düzeyinde bir sorumluluk olarak değerlendirin. Docker'ın güvenlik dokümantasyonu, güvenilir bir daemon operatörünün ana makine dosyalarını bağlayıp değiştirebileceğini açıklar. Bu nedenle, harici bir yükleniciye sınırsız Docker kontrolü vermek, ilgisiz bir müşterinin verilerini barındıran bir ana makine için uygun değildir.
Ayrı VPS örnekleri, ayrı işletim sistemi yönetimi ve sürüm kararlarına olanak tanır. Yine de her projede dikkatli izinler gerektirirler. Ortak ajans kimlik bilgileri veya paylaşılan bir dağıtım hesabı, ayırmayı amaçladığınız riskleri yeniden birleştirebilir.
İki kurgusal müşteri brief'i üzerinden çalışın
Aşağıdaki müşteriler kurgusal örneklerdir, müşteri geçmişi değildir. Ajans bugün her iki projeyi de işletmektedir, ancak erişim ve zamanlama gereksinimleri farklıdır.
Bu iki projeyi bir araya koymak, Morrow'un yüklenici erişimini ve lansman takvimini Aster'in işletme riskinin bir parçası haline getirir. Ayrı sunucu kararı bu kısıtlamalardan doğar; Morrow'un belirli sayıda CPU'ya ihtiyaç duyduğunu veya Aster'in risksiz olduğunu iddia etmez.
Tüm tablo sütunları için yatay olarak kaydırın.
| Karar faktörü | Aster Mobilya: tanıtım sitesi | Morrow Atölyeleri: kayıt sitesi |
|---|---|---|
| İş yükü | Herkese açık sayfalar ve ara sıra içerik güncellemeleri | Formlar, bir veritabanı ve zamanlanmış kayıt dışa aktarımları |
| Erişim | Müşteri içeriği düzenler; ajans dağıtır | Harici geliştiricinin ana makine yönetimine ihtiyacı var |
| Bakım | Kararlaştırılmış bir akşam penceresi | Bir rezervasyon lansmanı sırasında planlı değişiklik yok |
| Olay etkisi | Geçici bir sayfa kesintisi tartışılabilir | Kaybolan veya çoğaltılan gönderimler araştırma gerektirir |
| Çıkış gereksinimi | İçeriği dışa aktarın ve uygulamayı taşıyın | Bağımsız olarak işletilen bir ortamı aktarın |
| Geçici karar | Uyumlu ajans işletimindeki sitelerle paylaşmayı düşünün | Ayrı bir VPS ve ayrı proje kimlik bilgileri kullanın |
Her iki düzenlemenin toplam maliyetini karşılaştırın
Mevcut yapılandırıcıyı kullanarak iki bütçe sürümü oluşturun: biri paylaşılan yapılandırma, biri proje başına yapılandırma. Her biri için seçilen dönemin barındırma toplamını, yinelenen seçenekleri, harici hizmetleri ve ajans bakım süresini ayrı ayrı listeleyin. Müşteri brifingine eski bir fiyatı kopyalamaktan kaçının. Yapılandırmanın ne zaman hazırlandığını ve tahsisi kimin onayladığını kaydedin.
Paylaşılan bir ana makine için, müşterilerin sabit maliyetleri nasıl böleceğini ve birinin ayrılması veya yükseltme gerektirmesi durumunda ne olacağını kararlaştırın. Eşit paylar basittir ancak bir projenin depolama büyümesinin veya operasyonel işin çoğunu yapması durumunda uygun olmayabilir. Ayrı sunucular, atfı daha net hale getirirken ayrı yama, izleme ve kurtarma görevleri ekler.
Sürümler, yedeklemeler ve geçici işler için kaynak payı bırakın. Docker konteynerlerinin varsayılan olarak CPU veya bellek kısıtlaması yoktur; uygun sınırları yapılandırın ve birleşik iş yükünü değerlendirin. Yalnızca bir konteyner listesi, uygulanabilir bir kaynak bütçesi göstermez.
Bakım ve kurtarmayı projeye özel hale getirin
Paylaşılan bir ana makinede, bir işletim sistemi yeniden başlatması tüm yerleşik projeleri etkiler. Ana makine bakımını ortak bir takvime koyun ve her müşteriyle kimin iletişime geçeceğini belirleyin. Uygulama sürümlerini mümkün olduğunda ayrı tutun ve bir projenin veri dışa aktarımını diğerinin önemli lansmanı sırasında planlamaktan kaçının.
Kurtarma notları, sırları notlara kopyalamadan bir projenin veritabanını, dosyalarını, yapılandırmasını ve gerekli kimlik bilgilerini tanımlamalıdır. Geri yüklemeyi ayrı bir test hedefine planlayın. İlk yanıt olarak tüm paylaşılan ana makineyi geri yüklemek, diğer müşteriye ait sağlıklı değişiklikleri değiştirebilir.
Ayrı VPS örnekleriyle, kalan paylaşılan hizmetleri kaydedin. Ortak bir DNS hesabı, yedekleme hedefi veya operatör yine de her iki projeyi etkileyebilir. Sunucu ayrımı, bağımsız fiziksel altyapının veya garantili kullanılabilirliğin kanıtı değildir.
Düzenlemeyi doğrulayın ve gözden geçirme tetikleyicilerini belirleyin
Düzenlemeyi kabul etmeden önce, ikinci bir operatöre bir proje kimliğinin atanmış işini yapabildiğini ve diğer projenin dosyalarını, yedeklerini veya sırlarını okuyamadığını kontrol ettirin. Uygulama ekranlarının yanı sıra veritabanı izinlerini ve dağıtılan kimlik bilgilerini inceleyin. Kararlaştırılmış bir ortamda zararsız test verileri kullanın; başka bir müşterinin üretim verilerini araştırmayın.
Sonucu kabul edildi, reddedildi veya adı belirtilen bir düzeltme bekleniyor olarak kaydedin. Yalıtım gösterilemiyorsa, erişimi daraltın veya daha geniş izinler vermeden önce projeyi taşıyın. Başarılı bir ana sayfa yanıtı, erişim veya kurtarma kontrolü değildir.
- Seçilen düzeni, onaylanan maliyet dağılımını, sahipleri ve çözülmemiş maddeleri içeren bir karar kaydı tutun.
- Harici bir yönetici katıldığında, bir lansman penceresi değiştiğinde, depolama büyüdüğünde veya bir müşteri ayrılmaya hazırlandığında seçimi gözden geçirin.
- Teknik seçimi bir işletme anlaşmasına dönüştürmek için sorumluluklar kılavuzunu kullanın.
Kaynaklar ve inceleme
Teknik referanslar 12 Eylül 2026 tarihinde kontrol edildi. Örnekler planlama alıştırmalarıdır; başvurulan yazılım belgeleri PrivateHostLab hizmet yeteneklerini ortaya koymaz.