Ölçeklenebilen Ajans Hosting İş Akışı Örneği
30 Ağustos 2026 tarihinde yayınlandı
Yeni bir müşteri web sitesi, ardında şifreler, sohbet mesajları ve son dakika sunucu değişikliklerinden oluşan bir iz bırakmamalıdır. Bu ajans hosting iş akışı örneği, büyüyen bir web ajansının bir siteyi satıştan yayına ve sonrasındaki bakıma kadar, her adımda net sorumluluklarla nasıl taşıyabileceğini gösterir.
Amaç, her projeyi birbirinin aynısı yapmak değildir. Tek sayfalık bir kampanya sitesi ile bir WooCommerce mağazasının ihtiyaçları farklıdır. Amaç, tekrarlanabilir kısımları öngörülebilir hâle getirmektir: sitenin nerede barındığı, kimin erişebildiği, nasıl yedeklendiği ve bir şey ilgilenilmeyi gerektirdiğinde ne olduğu.
Ajansların neden tanımlı bir hosting iş akışına ihtiyacı var
Hosting çoğu zaman yavaş yavaş karmaşık hâle gelir. Bir geliştirici SSH üzerinden dağıtım yapar, diğeri paylaşılan bir panel girişini kullanır ve bir müşterinin kimsenin belgelememiş olduğu bir alan adı hesabı vardır. Her şey, bir yenileme kaçırılana, bir eklenti güncellemesi ödeme adımını bozuna veya kimlik bilgilerine sahip kişi tatilde olana kadar çalışır.
Belgelendirilmiş bir iş akışı, ajansa tek bir çalışma modeli sağlar. Ayrıca hizmetin satışını da kolaylaştırır. Belirsiz bir şekilde "managed hosting" vaat etmek yerine, müşterinin ne alacağını açıklayabilirsiniz: yönetilen bir ortam, izlenen kaynaklar, rutin bakım, geri yüklenebilir yedekler ve tanımlı bir destek yolu.
Bunun bir karşılığı vardır. Standardizasyon, anlık istisnaları sınırlar. Bu genellikle iyi bir şeydir, ancak ajanslar; uyumluluk ihtiyaçları, alışılmadık teknoloji yığınları veya henüz taşıyamadıkları mevcut altyapıları olan müşteriler için belgelenmiş bir istisna sürecine izin vermelidir. Asıl mesele, sırf katılık uğruna katılık değil, kontroldür.
Ajans hosting iş akışı örneği: imzalı tekliften yayına
Profesyonel hizmet firmaları için WordPress siteleri oluşturan 12 kişilik bir ajans hayal edin. Az sayıda Linux sunucusu üzerinde 80 aktif müşteri sitesini yönetiyor. Ajansın bir müşteri temsilcisi, bir proje yöneticisi, geliştiricileri ve altyapıdan sorumlu bir kişisi var.
İş akışının pratikte nasıl işlediği aşağıda açıklanmıştır.
1. Herhangi bir kaynak tahsisi yapmadan önce projeyi sınıflandırın
Bir teklif imzalandıktan sonra proje yöneticisi, başlangıç toplantısında bir hosting katmanı seçer. Karar; beklenen trafik, sitenin ödeme işleyip işlemediği, depolama gereksinimleri, e-posta ihtiyaçları ve müşterinin istediği destek yanıt süresine dayanır.
Bu, yaygın bir hatayı önler: başlangıçta uygun olduğu için her siteyi aynı plana koymak. Tanıtım amaçlı bir site, düşük riskli diğer sitelerle iyi yönetilen bir sunucuyu paylaşabilir. Bir mağaza, üyelik platformu veya yüksek trafikli kampanya daha güçlü kaynak sınırlarına, izole hesaplara ya da kendine ait bir sunucuya ihtiyaç duyabilir.
Proje kaydı; alan adı sahibini, yenileme iletişim kişilerini, DNS erişimini, beklenen yayın tarihini, teknik iletişim kişilerini ve tüm üçüncü taraf hizmetleri içerir. Bu kaydı bir geliştiricinin özel notlarında değil, ajansın proje sisteminde tutun.
2. Ayrı bir müşteri hesabı ve web sitesi ortamı oluşturun
Altyapıdan sorumlu kişi bir müşteri hesabı oluşturur, ardından bu hesabın içinde web sitesini ve veritabanını oluşturur. Müşterinin root erişimine ihtiyacı yoktur ve ajanstaki her çalışanın da buna ihtiyacı yoktur. Ayrım, müşterileri birbirinden korur ve devirleri çok daha temiz hâle getirir.
Personel değişikliklerinden etkilenmeden kullanılabilecek bir adlandırma kuralı kullanın. Örneğin, bunu bir kişinin adı ya da “new-site-final” gibi belirsiz bir etiket yerine kısa bir müşteri tanımlayıcısı ve ortam etiketi üzerine kurun. Önce production ortamını, proje gerektiriyorsa ardından staging ortamını oluşturun. Basit bir site için staging kopyası yeterli olabilir. Özel bir entegrasyon veya ticaret odaklı yapı için bu, beklenen kurulumun bir parçası olmalıdır.
Ajans; sunucuyu, hesap adını, birincil alan adını, veritabanı adını, PHP sürümünü ve yedekleme politikasını proje kaydına işler. Bu birkaç dakika sürer. Altı ay sonra acil bir talep geldiğinde saatler kazandırabilir.
3. Erişimi kolaylığa göre değil, role göre ayarlayın
Geliştiriciye yalnızca geliştirme ve dağıtım için gereken erişim verilir. Proje yöneticisi, sunucu ayarlarını değiştirebilecek kimlik bilgileri almadan durumu görüntüleyebilir. Müşteri, web sitesi yönetimi veya e-posta yönetimi gibi anlaşmasına dâhil görevler için sınırlı bir hesap alır.
Paylaşılan ana şifrelerden kaçının. Bunlar bir güvenlik sorunu yaratır ve neyi kimin değiştirdiğini bilmeyi imkânsız hâle getirir. Mümkün olan her yerde bireysel hesaplar kullanın, yüklenicilerin işi bittiğinde erişimlerini kaldırın ve ajans erişimini belirli bir takvime göre gözden geçirin.
Tam bağımsızlık isteyen müşteriler için devir koşullarını en baştan belgelendirin. Hosting hesabının sahibi onlar olabilirken, ajans devredilmiş erişim alabilir. Ajansın her şeyi yönetmesini tercih eden müşteriler için de sorumluluk sınırlarını aynı derecede netleştirin. Her iki model de işe yarar. Soruna yol açan şey kafa karışıklığıdır.
4. Staging üzerinde geliştirin, ardından bir yayın kontrol listesi hazırlayın
Geliştiriciler, canlı alan adından uzakta geliştirir ve test eder. Yayından önce proje yöneticisi geçiş zaman aralığını, DNS sahibini, mevcut TTL ayarlarını, formları, analitiği, yönlendirmeleri ve geri alma iletişim kişisini doğrular.
Yayın kontrol listesi, kısa bir listenin gerçekten işe yaradığı yerlerden biridir. Tipik bir WordPress projesinde, trafiği yönlendirmeden önce şu maddeleri doğrulayın:
- Canlı alan adı için SSL etkindir ve tercih edilen URL doğru şekilde yönlendirme yapar.
- Geçişten önce bir güncel yedek vardır ve hızlıca belirlenebilir.
- Formlar doğru alıcılara gönderim yapar ve işlemsel mesajlar test edilir.
- Önbellekleme, zamanlanmış görevler ve kritik eklentiler production ortamında çalışır.
- İzleme etkindir ve ekip yayın günü sorunlarını kimin ele alacağını bilir.
Kontrol listesini törensel bir belge gibi değerlendirmeyin. Ajansınızın gerçekten gördüğü sorunları yansıtmalıdır. Geçen yıl başarısız bir DNS değişikliği bir öğleden sonraya mal olduysa, DNS doğrulamasını ekleyin. Müşteriler düzenli olarak form bildirimlerini kimin aldığını unutuyorsa, bunu standart bir yayın testi hâline getirin.
5. Bir geri alma planıyla canlıya geçin
Yayında geliştirici onaylanan siteyi dağıtır ve altyapıdan sorumlu kişi hizmet sağlığını doğrular. Proje yöneticisi neler olduğunu ve müşterinin ne zaman onay beklemesi gerektiğini iletir. Bu, müşterilerin çoğu zaman stresli bulduğu bir anda ajansın düzenli görünmesini sağlayan küçük bir ayrıntıdır.
Bir geri alma planı teorik değil, pratik olmalıdır. Geri almanın; bir yedeği geri yüklemek, DNS'i eski host'a geri yönlendirmek veya yalnızca değiştirilmiş bir dosya ya da veritabanı girdisini geri almak anlamına mı geldiğine karar verin. Düşük riskli bir pazarlama sitesi için yakın tarihli bir yedek yeterli olabilir. Yoğun çalışan bir mağaza için yayın zaman aralığında oluşturulan siparişleri ve müşteri verilerini dikkate almalısınız. Körü körüne geri yükleme yapmak, geçerli işlemleri kaldırabilir.
6. Siteyi sürekli bakıma devredin
Yayın, proje teslimi ile tekrarlayan hosting operasyonları arasındaki devirdir. Proje yöneticisi geliştirme işini tamamlanmış olarak işaretlerken, müşteri temsilcisi müşteriyi destek süreci, bakım kapsamı ve beklenen yanıt süreleriyle tanıştırır.
Site, bakım katmanı ve temel ayrıntılarıyla bir bakım kuyruğuna girer. Birçok ajansın kârlılığı kaybettiği yer burasıdır. Sürekli işler geliştiricilere rastgele e-postalar ve doğrudan mesajlar üzerinden geliyorsa, kimse hacmi göremez veya dâhil olan işleri faturalandırılabilir taleplerden ayıramaz.
Net bir kuyruk, hizmeti ölçülebilir hâle getirir. Ayrıca geliştiricileri gayriresmî bir 24 saat yardım masasına dönüşmekten korur.
Yayın sonrası çalışma ritmi
Bir iş akışı ancak rutin işlerin bir ritmi olduğunda ölçeklenir. Bu örnekteki ajans günlük izleme, haftalık bakım incelemesi ve aylık müşteri odaklı bir kontrol kullanır.
Günlük izleme; erişilebilirlik, disk alanı, CPU ve bellek kalıpları, sertifika durumu ve yedekleme tamamlanmasına odaklanır. Gerçek zamanlı sunucu izleme, altyapıdan sorumlu kişinin bir kaynak sorununu müşteri bildirimi hâline gelmeden fark etmesine yardımcı olur. FASTPANEL gibi bir kontrol paneli; web sitesi, hesap, veritabanı, SSL ve sunucu bilgilerini tek bir çalışma alanında tutabilir; bu da ayrı araçlar arasında yapılan olağan aramayı azaltır.
Haftalık işler; eklenti ve tema güncellemelerini gözden geçirmeyi, başarısız yedekleme işlerini kontrol etmeyi, atıl geçici dosyaları kaldırmayı ve destek taleplerine yanıt vermeyi içerir. Her production sitesini aynı anda otomatik olarak güncellemeyin. Güvenlik güncellemeleri hızlı aksiyon gerektirebilir, ancak sitenin özel işlevleri varsa büyük eklenti veya WordPress sürümleri önce staging üzerinde test edilmelidir.
Her ay müşterilere sade dilli bir hizmet notu gönderin. Bu not; tamamlanan güncellemeleri, yedekleme durumunu, dikkat çeken destek işlerini, performans gözlemlerini ve onay gerektiren önerileri kapsayabilir. Bu, kimsenin okumak istemediği bir rapor üretmeden görünmeyen bakımı görünür değere dönüştürür.
Bir olay sizin yerinize bunu yapmadan önce sorumluluğu tanımlayın
Bir site çöktüğünde ilk on dakika önemlidir. Ekip, sorunun bir sunucu olayı, DNS problemi, süresi dolmuş alan adı, uygulama hatası, üçüncü taraf kesintisi veya müşteri içerik değişikliği olup olmadığını bilmelidir.
Basit bir eskalasyon yolu oluşturun. Birinci seviye destek kapsamı doğrular ve hatayı kaydeder. Altyapıdan sorumlu kişi sunucu ve hesap sağlığını kontrol eder. Geliştirici uygulama düzeyindeki arızaları ele alır. Müşteri temsilcisi, güncelleme yalnızca ekibin hâlâ araştırma yaptığı bilgisi olsa bile, müşteriyi üzerinde anlaşılan aralıklarla bilgilendirir.
Bu ayrım önemlidir çünkü teknik beceri tek başına bir olayı yönetilebilir kılmaz. Müşterilerin doğru iletişime ihtiyacı varken, teknik personelin de beş ayrı mesaja yanıt vermeden teşhis koyabilmek için alana ihtiyacı vardır. Önemli kesintilerden sonra bir olay kaydı tutun, ardından bunu daha erken yakalayabilecek kontrol listesini veya izleme kuralını iyileştirin.
İş akışını daha ağır değil, daha kolay hâle getirin
En iyi süreç, insanların yoğun bir salı gününde takip edebildiği süreçtir. Müşteri kaydını kısa tutun, anlamlı olduğu yerde tekrarlanabilir kaynak tahsisini otomatikleştirin ve birkaç yayından sonra iş akışını gözden geçirin. Ekibiniz bir adımı tekrar tekrar atlıyorsa, bunun gereksiz mi, yanlış zamanlanmış mı yoksa yanlış araçta mı gizli olduğunu sorun.
Bir müşteri türü ve bir hosting katmanıyla başlayın. Süreci sonraki üç yayın için uygulayın, pürüzleri giderin ve ardından genişletin. Sakin bir hosting operasyonu, en yoğun geliştiricinizden her şeyi hatırlamasını istemekten değil, görünür sorumluluklardan ve geri alınabilir kararlardan oluşur.