Ajanslar İçin Müşteri Sitelerini İzleme Mimarisi: Uptime, SSL ve Domain Alarm Sistemi

Bir yaratıcı veya performans odaklı dijital ajans olarak onlarca, bazen yüzlerce web sitesinden sorumlu hale gelmek birkaç yeni müşteri anlaşması kadar yakın. Proje planlama toplantılarında, kampanya stratejisi, içerik takvimi ve medya bütçeleri masadayken genellikle gözden kaçan kritik bir başlık var: müşteri sitelerinin sürekliliğini ve kritik tarihlerinin takibini nasıl otomatikleştireceğiz?

Tek bir alan adının süresinin uzatılmaması, bir SSL sertifikasının beklenmedik şekilde bitmesi veya ana sitenin saatlerce kapalı kalması; tüm emeği, raporları ve güveni birkaç saat içinde zedeleyebiliyor. Üstelik ajans tarafında bu risk, tekil bir site için değil, portföyünüzdeki tüm müşteriler için aynı anda var.

Bu yazıda, ajanslar için ölçeklenebilir bir müşteri sitelerini izleme mimarisi kurmayı adım adım ele alacağız: uptime takibi, SSL bitiş tarihleri ve alan adı yenileme alarmlarını tek bir mantıklı mimaride birleştireceğiz. Amacımız; kişisel hataya ve dağınık takip dosyalarına bağımlı olmayan, otomatik, şeffaf ve ajans ekibinizin büyüklüğünden bağımsız olarak yönetilebilir bir yapı ortaya koymak.

Ajanslar İçin Neden Ayrı Bir İzleme Mimarisi Gerekli?

Bir ajansın sorumluluğu, klasik bir site sahibinden farklıdır. Kendi siteniz için sadece bir alan adı, bir hosting hesabı ve bir SSL sertifikası takip ederken; ajans tarafında durum şu hale gelir:

• Farklı kayıt firmalarına dağılmış çok sayıda alan adı
• Çeşitli hosting panelleri, reseller hesapları, farklı sunucular
• Let’s Encrypt, ticari SSL, wildcard, SAN gibi farklı sertifika türleri
• Tek seferlik kampanya siteleri, micro landing sayfalar, test ortamları

Bu karmaşa büyüdükçe, tek tek kişilerin hafızasına ve dağınık Excel listelerine güvenmek sürdürülebilir olmaktan çıkıyor. Özellikle onlarca domain’i kontrol altına alma sürecini yaşamış ajanslar bu noktayı çok iyi biliyor.

Bu nedenle ajanslar için izleme mimarisinin bazı özel hedefleri olmalı:

• Merkezileştirme: Alan adı, SSL ve uptime bilgisinin tek yerde toplanması
• Otomasyon: Manuel hataları azaltan, kendini güncel tutan bir sistem
• Roller ve yetkiler: Teknik ekip, proje yöneticileri ve yöneticiler için farklı görünüm ve yetkiler
• Şeffaf raporlama: Gerekirse müşteriye gösterilebilecek uptime ve bakım kayıtları
• Sağlam altyapı: İzleme sisteminin de DCHost üzerinde güvenli ve yüksek erişilebilir bir altyapıda barınması

İzleme Mimarinizin Üç Temel Bacağı: Uptime, SSL ve Domain

Sağlam bir ajans izleme mimarisi, en az üç temel bileşeni kapsamalı:

1. Uptime izleme: Sitelerin erişilebilirliğini ve yanıt sürelerini takip etmek
2. SSL sertifika bitiş tarihleri: Sertifikaların süresinin dolmasını önceden görmek
3. Domain yenileme ve Whois takibi: Alan adlarının yenileme tarihlerine proaktif yaklaşmak

Bunlara ek olarak; DNS, e-posta, sunucu kaynakları (CPU, RAM, disk) ve güvenlik katmanlarını da mimariye entegre etmek mümkün, ancak bu yazıda özellikle müşteriye doğrudan görünen ve en kritik üç riske odaklanacağız.

1. Uptime İzleme Neyi Çözer?

Uptime, en basit tanımıyla; sitenin belirli bir periyot içinde erişilebilir olduğu zaman yüzdesidir. Örneğin %99.9 uptime’ın saat bazında ne anlama geldiğini biliyorsanız, küçük kesintilerin bile ay sonu raporunu ve müşteri algısını nasıl etkileyebileceğini tahmin edebilirsiniz.

Ajans tarafında uptime izlemenin faydaları:

• Müşteri fark etmeden önce siz sorunu görürsünüz.
• Hosting veya uygulama kaynaklı problemleri objektif verilerle ayırt edersiniz.
• Aylık/çeyreklik raporlarda “uptime yüzdesi” gibi net metrikler sunabilirsiniz.
• Kampanya dönemlerinde (Black Friday, lansman vb.) önceden ekstra gözetim sağlar.

Uptime tarafını daha önce web sitesi uptime izleme ve alarm kurma rehberi yazımızda detaylı anlattık; bu yazıda o prensipleri ajans ölçeğine taşıyacağız.

2. SSL Bitiş Tarihi İzleme Neyi Çözer?

Tarayıcıda çıkan “Güvenli değil” uyarısı kadar itibarı zedeleyen çok az şey vardır. Hele ki bunu bir kurumsal site veya e-ticaret projesinde, üstelik ajans olarak sizin yönettiğiniz bir projede yaşamak istemezsiniz.

SSL bitiş tarihlerini izlemenin kritik faydaları:

• Tarayıcı uyarıları, ödeme hataları ve SEO kaybı yaşanmadan yenileme yaparsınız.
• Farklı sağlayıcılardaki çok sayıdaki sertifikayı tek panelden görürsünüz.
• Wildcard, SAN, Let’s Encrypt gibi farklı sertifika türlerinde bileşen bazlı riskleri azaltırsınız.

Özellikle onlarca müşteri için sertifika yönetiyorsanız, onlarca alan adı için SSL sertifika süre sonu izleme stratejileri yazımızda paylaştığımız otomasyon yaklaşımlarını ajansınız için ölçeklendirebilirsiniz.

3. Domain Yenileme İzleme Neyi Çözer?

Alan adının süresinin dolması, çoğu zaman müşterinin zihninde “ajans unuttu” olarak kaydedilir. Oysa arada muhasebe onay süreci, müşteri tarafı gecikmeleri veya eski bir kayıt firmasına dağılmış domain’ler olabilir.

Alan adı yenileme izlemenin yararları:

• Grace ve redemption dönemine hiç girmeden yenileme yaparsınız.
• Müşteriye haftalar önceden fiyat ve onay sürecini başlatabilirsiniz.
• Değerli alan adlarının düşmesini neredeyse imkânsız hale getirirsiniz.

Detaylı yaşam döngüsünü anlamak için alan adı yenileme, grace ve redemption süreleri rehberi yazımıza mutlaka göz atmanızı öneririz; burada ise bu bilgiyi ajans izleme mimarisine nasıl oturtacağımıza odaklanacağız.

Mimari Tasarıma Başlangıç: Envanter, Veri Kaynakları ve Merkezî Panel

Sağlam bir izleme sisteminin ilk adımı, teknik araçlardan önce doğru tasarlanmış bir envanterdir. Ajans tarafında bu envanter en az şu alanları içermeli:

• Müşteri adı ve sorumlu proje yöneticisi
• Birincil alan adı ve varsa ek alan adları (park, yönlendirme, kampanya domain’leri)
• Hosting türü (reseller, paylaşımlı, VPS, dedicated, DCHost üzerinde özel çözüm vb.)
• Sunucu lokasyonu ve panel (cPanel, DirectAdmin, Plesk vb.)
• SSL türü (Let’s Encrypt, ticari DV/OV/EV, wildcard, SAN vb.)
• Alan adı kayıt firması ve yenileme tarihi
• Uptime izleme endpoint’leri (ana site, admin, API vb.)

Bu tabloyu ister bir proje yönetim aracıyla, ister basit bir veritabanı veya YAML/JSON dosyasıyla tutabilirsiniz. Önemli nokta, tek gerçek kaynak (single source of truth) olacak bir yer belirlemek ve tüm otomasyonu buradan beslemek.

Veri Kaynaklarının Sınıflandırılması

Mimaride kullanacağınız veri kaynaklarını üçe ayırabilirsiniz:

• Statik veri: Müşteri adı, panel erişimi, sorumlu kişi gibi sık değişmeyen bilgiler
• Yarı dinamik veri: Domain yenileme tarihleri, SSL bitiş tarihleri gibi dönemsel değişen bilgiler
• Dinamik veri: Uptime, yanıt süresi, HTTP durum kodu, gecikme gibi sık ölçülen metrikler

Statik ve yarı dinamik veriler envanterinizde saklanırken, dinamik veriler izleme aracı/servisi tarafından toplanır. Bu ayrımı net yapmak, hem veritabanı tasarımını hem script’leri sadeleştirir.

Merkezî Panel ve Rol Tasarımı

Ajans içinde herkesin Prometheus grafiği veya log satırı görmek zorunda olmadığı bir gerçek. Bu yüzden:

• Teknik ekip: Detaylı metrikler, loglar, HTTP cevapları, ping süreleri
• Proje yöneticileri: Basitleştirilmiş uptime yüzdeleri, kritik tarih listeleri
• Yöneticiler: Özet dashboard’lar, riskli müşteriler listesi

Bu farklı kitleler için aynı veri setini, farklı arayüzler ve raporlarla sunmak ideal. Dilerseniz kendi iç panelinizi DCHost üzerinde bir VPS’te barındırıp, Prometheus, Grafana ve Uptime Kuma ile izleme katmanını teknik ekibe, sadeleştirilmiş bir web panelini de proje ekiplerine açabilirsiniz.

Katman 1: Uptime İzleme Mimarisi

Uptime izleme, mimarinin en hareketli ve en çok veri üreten kısmıdır. Ajans ölçeğinde planlarken şu soruları netleştirin:

• Her site için hangi endpoint’leri izleyeceğiz?
• Kontrol sıklığı ne olacak? (1 dk, 5 dk, 10 dk vb.)
• Alarm eşikleri nasıl belirlenmeli?
• Farklı bölgelerden kontrol (multi-region) gerekli mi?

Hangi Endpoint’ler İzlenmeli?

Ajanslar genelde sadece ana sayfayı izliyor; ama pratikte şu kombinasyon daha sağlıklı:

• Public ana sayfa: https://www.ornekdomain.com/
• Login veya kritik form sayfası: /giris, /sepet, /odeme gibi URL’ler
• Admin panel (opsiyonel): /wp-admin, /cpanel, özel yönetim paneli
• API endpoint’i (varsa): /api/health gibi basit bir sağlık kontrolü

Özellikle e-ticaret veya SaaS projelerinde, sadece ana sayfanın çalışıyor olması yetmez; ödeme adımları ve API’nin de canlı olması gerekir. Bu noktada, e-ticaret sepet ve ödeme adımlarını izleme pratiğini uptime mimarisiyle birleştirebilirsiniz.

Kontrol Sıklığı ve Alarm Eşikleri

Ajans ölçeğinde tipik bir yaklaşım şöyle olabilir:

• Kritik siteler (büyük e-ticaret, yoğun trafik kampanya sayfaları): 1 dakikalık kontrol
• Orta önemde siteler (kurumsal, blog, B2B siteler): 5 dakikalık kontrol
• Düşük önemde siteler (mikro landing, geçici kampanya siteleri): 10–15 dakikalık kontrol

Alarm için ise tek başarısız denemede değil, örneğin üst üste 3 başarısız kontrolde tetiklenmesini ayarlamak, geçici network dalgalanmalarını filtrelemek için idealdir.

İzleme Araçlarının Konumlandırılması

İki temel yaklaşımınız var:

• Harici SaaS tipi uptime araçları: Kurulumu kolay, ancak veriniz dışarıda ve maliyet site sayısı arttıkça katlanabilir.
• Kendi izleme altyapınız: DCHost üzerinde bir veya birkaç VPS üzerinde Uptime Kuma, Prometheus vb. kurarak tamamen size ait bir izleme katmanı kurabilirsiniz.

Ajans ölçeğinde çoğu zaman hibrit bir yaklaşım mantıklı: İç izleme sisteminizi DCHost üzerindeki VPS’te kurup, kritik birkaç site için dış bağımsız bir kontrol daha kullanarak gerçek kullanıcı deneyimine daha yakın bir görünüm elde edebilirsiniz.

Katman 2: SSL Sertifika Bitiş Tarihi ve Geçerlilik Kontrolleri

SSL tarafı, uptime kadar sık veri üretmez; ama ihmal edildiğinde etkisi çok daha dramatiktir. Mimaride şu bileşenleri kurmanız gerekir:

• Her domain için sertifika bitiş tarihinin bilinmesi
• Otomatik periyodik kontrol (cron, timer vb.)
• Belirlediğiniz eşiklere göre alarm (örneğin 30, 14 ve 7 gün kala)
• Otomatik yenileme varsa bu sürecin izlenmesi, yoksa manuel iş akışı

Sertifika Envanterini Nasıl Tutmalı?

Envanterde en azından şu alanları bulundurun:

• Alan adı veya wildcard pattern’i (*.ornekdomain.com gibi)
• Sertifika türü (DV, OV, EV, wildcard, SAN)
• Sertifika sağlayıcısı ve yenileme yöntemi (otomatik ACME, panel üzerinden manuel vb.)
• Bitiş tarihi (expiry)
• Sunucu/panel bilgisi (hangi DCHost VPS veya hangi paylaşımlı hosting hesabında)

Bu bilgiyi başta manuel doldursanız bile, sonrasında script’lerle otomatik güncellemek mümkündür. Örneğin belirli aralıklarla openssl s_client veya benzeri araçlarla sertifika bitiş tarihini çekip envanterinizde güncelleyen basit bir cron işiniz olabilir.

Let’s Encrypt ve Diğer ACME Tabanlı Sertifikalar

Let’s Encrypt ve benzeri ACME tabanlı sertifikalar için genelde otomatik yenileme ayarlanır; ancak bu “artık hiç bakmama gerek yok” anlamına gelmez. Şu riskler hâlâ geçerlidir:

• DNS veya HTTP-01 doğrulama hataları
• Panel güncellemeleri sonrası bozulmuş cron işleri
• Limitlere (rate limit) takılma durumları

Bu nedenle, ACME otomasyonu olsa bile bağımsız bir SSL bitiş tarihi izleme katmanına sahip olmak iyi bir sigortadır. Bu konuda detaylı stratejileri SSL sertifika otomasyon araçları ve ACME entegrasyonları yazımızda paylaştık; ajans mimarisinde de aynı prensipler geçerli.

Alarm Eşikleri ve İş Akışı

Ajans tarafında SSL bitiş tarihleri için tipik bir eşik tasarımı şöyle olabilir:

• 30 gün kala: Proje yöneticisine sadece bilgi e-postası
• 14 gün kala: Teknik ekibe ve proje yöneticisine uyarı (yenileme süreci başlamalı)
• 7 gün kala: Yüksek öncelikli Slack/Teams/WhatsApp bildirimi, sorumlu atanmış ticket

Otomatik yenileme kullanılan projelerde bile, 14 ve 7 gün kala yapılan kontroller, olası ACME hatalarını canlıya yansımadan yakalamak için oldukça değerlidir.

Katman 3: Domain Yenileme ve Whois Tabanlı İzleme

Domain tarafında zorluk, alan adlarının çoğu zaman farklı kayıt firmalarına dağılmış olmasıdır. Tümünü tek ekrandan göremeyince, ister istemez Excel listeleri veya bireysel notlar devreye girer.

Domain Envanteri Nasıl Yapılandırılmalı?

Her alan adı için aşağıdaki alanları envanterinizde tutmanızı öneririz:

• Alan adı (domain)
• Kayıt firması ve panel erişim notu
• Kayıt ve bitiş (expiry) tarihi
• Otomatik yenileme açık/kapalı bilgisi
• Fatura/ödeme sorumlusu (ajans mı, müşteri mi ödüyor?)
• Kritiklik seviyesi (premium domain, marka domain’i, kampanya domain’i vb.)

Bu envanteri güncel tutmak için periyodik Whois taramaları kullanabilirsiniz. Ancak Whois verisinin GDPR/KVKK nedeniyle bazı TLD’lerde maskelenmiş olabileceğini, bu yüzden her zaman kayıt firmasının panelindeki bilgilere güvenmenin daha isabetli olacağını unutmayın.

Yenileme Süreçlerini Otomatikleştirmek

Mimaride amaç; “domain süresi dolmuş” sürprizini tamamen ortadan kaldırmak. Bunun için:

• En az 60, 30 ve 7 gün kala ajans ve müşteri tarafına hatırlatma akışı tasarlayın.
• Eğer ajans olarak siz yeniliyorsanız, otomatik ödeme talimatı veya kredi kartı güncelliğini takip edin.
• Premium veya marka değeri yüksek alan adları için ekstra iç onay adımları planlayın.

Özellikle değerli portföyler için, alan adı yaşam döngüsü ve düşen domain yakalama rehberi yazısında anlattığımız grace/redemption risklerini bilmek, alarm eşiklerini nerede tutmanız gerektiğini netleştirmenize yardımcı olur.

Alarm ve Bildirim Katmanı: Kim, Ne Zaman, Hangi Kanaldan Haberdar Olmalı?

İyi bir izleme mimarisi kurmak kadar, doğru kişiye doğru alarmı ulaştırmak da önemlidir. Ajans yapısında genelde şu rol dağılımı olur:

• Teknik ekip: Uptime, SSL, sunucu kaynakları, DNS hataları
• Proje yöneticisi: Müşteriyi ilgilendiren ciddi kesintiler, domain ve SSL tarihleri
• Yönetim: Kritik müşterilerde yaşanan büyük kesintiler, SLA ihlalleri

Bildirim Kanallarını Tasarlama

Pratik bir ajans mimarisinde genelde şu kanallar kombinasyonu kullanılır:

• E-posta (teknik ekip ve proje yöneticileri için)
• Slack/Teams gibi anlık iletişim araçları için özel kanal entegrasyonları
• Özellikle kritik müşterilerde, WhatsApp/SMS gibi daha dikkat çekici uyarılar
• İç ticket sistemi ile otomatik iş kaydı açılması

Burada önemli nokta, gürültüyü yönetmektir. Sürekli uyarı alan bir ekip zamanla alarmlara duyarsız hale gelir (alarm yorgunluğu). Bu nedenle eşikleri, önem derecelerini ve tekrar bildirim mantığını dikkatle ayarlamalısınız.

Örnek Mimariler: Küçük, Orta ve Büyük Ajans Senaryoları

Küçük Ajans (10–20 Site)

Birkaç kişiyle çalışan, 10–20 müşteri sitesini yöneten ajans için:

• Tek bir DCHost VPS üzerinde Uptime Kuma + basit bir SSL/domain kontrol script’i
• Envanter için basit bir veritabanı veya YAML/JSON dosyası
• E-posta + Slack entegrasyonu ile temel alarm yapısı
• Haftalık raporları manuel veya yarı otomatik PDF/CSV olarak üretme

Bu düzeyde bile izleme mimarisi kurmak, “kim bakıyordu?” sorusunu ortadan kaldırır ve teknik borcun büyümesini engeller.

Orta Ölçekli Ajans (50–150 Site)

Gelişmiş ekip ve çoklu vertical’lerde çalışan ajanslar için:

• DCHost üzerinde en az iki VPS: biri izleme (Prometheus, Uptime Kuma, Grafana), diğeri yönetim paneli ve raporlama için
• Alan adı ve SSL için ayrı tablolarla normalize edilmiş envanter
• Domain ve SSL için günlük cron işleri ile otomatik expiry güncellemesi
• Slack/Teams’te “kritik-uptime”, “ssl-domain-uyari”, “bilgilendirme” gibi ayrı kanallar
• Proje yönetim aracınızla (Jira, ClickUp vb.) API entegrasyonu üzerinden otomatik ticket açılması

Büyük Ajans (150+ Site, Çoklu Marka ve Ülke)

Daha kurumsal ajans yapılarında mimari biraz daha olgunlaşır:

• Birden fazla DCHost VPS veya dedicated sunucuyla ayrıştırılmış izleme, loglama, raporlama katmanları
• Merkezî kimlik yönetimi (SSO, 2FA) ile erişim kontrolü
• Her müşteri için ayrı dashboard ve SLA raporu
• Farklı lokasyonlarda uptime kontrolü (multi-region)
• İş sürekliliği için izleme verilerinin periyodik yedeği ve felaket kurtarma planı

Bu düzeyde, izleme mimarisi artık sadece bir “teknik altyapı” değil, ajansın verdiği hizmetin bir parçası ve bazen müşteriye faturalandırılabilen bir kalem haline gelir.

DCHost Altyapısı Üzerinde İzleme Mimarisi Kurarken Dikkat Edilecek Noktalar

Biz DCHost tarafında, ajans müşterilerimizle çalışırken genelde şu mimari prensipleri öneriyoruz:

• Ayrı izleme VPS’i: Müşteri sitelerinizden bağımsız, sadece izleme ve raporlamaya ayrılmış bir VPS
• Güçlü disk ve ağ: Uptime verileri çok disk tüketmez; ancak loglama ve metrik saklama için NVMe diskler fark yaratır.
• Yedekleme: İzleme verilerini ve envanteri düzenli olarak yedekleyin; bunun için 3-2-1 yedekleme stratejisi yazımızdaki prensipleri uygulayabilirsiniz.
• Güvenlik: İzleme panelinize herkesin erişmesine gerek yok; IP kısıtlama, VPN ve 2FA ile erişimi sınırlandırın.

Yeni bir izleme VPS’i kurarken, yeni VPS’te ilk 24 saat yapılması gerekenler ve VPS güvenlik sertleştirme kontrol listesi yazılarımızdaki adımları takip ederek, hem güvenli hem de uzun vadede bakım yükü düşük bir temel atabilirsiniz.

Operasyonel İpuçları: Süreç, Dokümantasyon ve Eğitim

Teknik mimariyi kurduktan sonra, sürdürülebilirlik için şu üç alana yatırım yapmanız gerekir:

• Süreçler: Hangi alarmda kimin ne yapacağı, hangi süre içinde aksiyon alınacağı, müşteriye nasıl bilgi verileceği net olmalı.
• Dokümantasyon: İzleme mimarisinin nasıl çalıştığı, yeni müşteri ekleme prosedürü, alan adı/SSL ekleme rehberleri yazılı olmalı.
• Eğitim: Proje yöneticileri en azından temel terimleri (uptime, SLA, grace period, SSL türleri) bilmeli; teknik ekip de kullanılan araçlarda yetkin olmalı.

Yeni bir müşteri geldiğinde, sadece kreatif ve içerik tarafını değil, ajanslar için yeni müşteri hosting ve DNS kontrol listesini anımsatan bir onboarding süreciniz olsun ve bu sürece mutlaka “uptime/SSL/domain izleme sistemine ekleme” adımını dahil edin.

Sonuç: Manuel Takipten Otomatik İzlemeye Geçme Zamanı

Ajanslar için müşteri sitelerini izleme mimarisi kurmak, ilk bakışta ekstra iş gibi görünebilir. Ancak tabloya stratejik açıdan baktığınızda, bunun aslında üç kritik faydayı birlikte getirdiğini görürsünüz:

• Risk azaltma: Domain kaybı, SSL hataları ve uzun kesintiler büyük ölçüde önlenir.
• Güven inşası: Müşteriye uptime raporları, planlı bakım bildirimleri ve proaktif uyarılar sunabilirsiniz.
• Operasyonel verimlilik: Ekipleriniz e-posta kutusuna düşen “site kapalı mı?” mesajlarına reaktif yanıt vermek yerine, önceden aksiyon alır.

Biz DCHost olarak; ajans müşterilerimizin uptime, SSL ve domain takibini tek bir mantıklı yapı altında topladığında hem kendi iç operasyonlarının hafiflediğini, hem de müşterileri nezdinde “altyapıyı da ciddiye alan ajans” konumuna yükseldiklerini sahada sıkça görüyoruz.

Eğer siz de hâlâ Excel listeleri, bireysel hatırlatıcılar ve dağınık notlar arasında kayboluyorsanız; bir DCHost VPS üzerinde küçük bir izleme sunucusu kurarak başlayın, en kritik 5–10 müşterinizi sisteme ekleyin ve sonuçları görün. Sonrasında bu yapıyı büyütmek, ilk adımı atmaktan çok daha kolay olacak.

İzleme mimarinizi tasarlarken, bu yazıda bahsettiğimiz iç bağlantılardaki detaylı rehberlerden yararlanabilir; takıldığınız noktalarda DCHost ekibinden destek alarak ajansınız için uzun vadeli, güvenli ve ölçeklenebilir bir izleme altyapısı kurabilirsiniz.