Gitae’yi geliştirmemin nedeni sürekli aynı pratik soruyla karşılaşmamdı: web sitesi gerçekten mi kapalı, yoksa sorun sadece bende mi?
Tek bir tarayıcı sekmesi iyi bir teşhis aracı değildir. Sayfa origin server kapalı olduğu için yüklenmeyebilir; ama DNS, HTTPS sertifikası, routing, firewall kuralı, kapalı ya da filtrelenen port, ISP, VPN rotası, tarayıcı durumu veya yerel cache de aynı sonucu yaratabilir. Görünen belirti aynıdır. Yapılması gereken işlem değildir.
Gitae ile çözmek istediğim şey buydu: yalnızca yeşil veya kırmızı bir durum göstermek değil, sorunu bir sonraki araştırılması gereken katmana kadar daraltmak.
“Site kapalı” ifadesinin arkasındaki gerçek problem
Basit website checker araçlarının çoğu dar bir soruya cevap verir: bu URL, belirli bir noktadan belirli bir anda yanıt verdi mi? Bu bilgi yararlıdır ama tek başına outage teşhisi değildir.
DNS yanlışsa uygulamayı yeniden başlatmak hiçbir şeyi düzeltmez. HTTPS sertifika nedeniyle başarısızsa sayfa içeriğini değiştirmek ilgisizdir. Bir TCP portuna erişilemiyorsa server yine de çalışıyor olabilir. Site harici bir serverdan açılıyor fakat benim bağlantımdan açılmıyorsa, problem application server yerine benim network ile hedef arasındaki rotada olabilir.
Bu yüzden Gitae’yi şu modele göre tasarladım: bir web sitesi bağımlılıklardan oluşan bir zincirdir ve her kontrol bu zincirin yalnızca bir bölümü hakkında kanıt sağlar.
Harici bir bakış açısı, mutlak bir hüküm değil
Gitae kontrolleri Moskova ve Helsinki’deki kendi VDS sunucularımdan çalışır. Böylece problemi ilk gördüğüm bilgisayar ve ağdan bağımsız gözlem noktaları elde ederim.
Site yerelde açılmıyor ama iki VDS’den de yanıt veriyorsa bu önemli bir işarettir: origin en azından herkes için erişilemez değildir. Böyle bir durumda yerel DNS, ISP routing, VPN, tarayıcı, firewall veya rotaya bağlı başka bir problemi daha dikkatli incelerim. Harici probe’lar da başarısızsa server, DNS, sertifika, routing veya daha geniş bir network sorunu üzerinde durmak için daha fazla neden vardır.
Ancak remote check otomatik olarak local check’ten “daha güvenilir” değildir. İki VDS noktası tüm interneti temsil etmez. Site Moskova ve Helsinki’den çalışırken başka bir ülkede, ISP’de, CDN edge’de veya networkte başarısız olabilir. Ben harici sonucu ek bir gözlem noktası olarak görüyorum, global bir karar olarak değil.
Gitae bugün neleri kontrol ediyor
- Website check — URL’nin harici bir serverdan yanıt verip vermediğini kontrol eder.
- SSL check — HTTPS/TLS sertifika durumunu ve sertifikayla ilgili problemleri inceler.
- DNS check, nslookup ve dig — domainin nasıl çözümlendiğini ve hangi DNS kayıtlarının döndüğünü gösterir.
- Reverse DNS ve IP check — IP ve PTR/reverse-DNS bilgilerini gösterir.
- Domain info ve domain age — temel domain metadatası sağlar.
- Port check — hedef portun probe konumundan erişilebilir olup olmadığını test eder.
- Find your IP — servisin gördüğü public IP adresini gösterir.
- Ping ve traceroute — latency, packet loss ve hosta giden yol hakkında network sinyalleri verir.
- Hosting check ve CMS detection — altyapı ve teknolojiyle ilgili tanımlamaya yardımcı sinyaller gösterir.
Bu sonuçları özellikle sinyal olarak ele alıyorum. Bir PTR kaydı server sahibini kanıtlamaz. Public fingerprint’lere dayanan CMS detection tam software stack’i kanıtlamaz. Bir probe’dan erişilemeyen port, herkes için kapalı olmak yerine yol üzerinde filtreleniyor olabilir.
Sonuçları nasıl yorumluyorum
Asıl değer, kontrolleri tek tek değil birlikte değerlendirdiğimde ortaya çıkıyor.
DNS beklediğim adresi döndürüyor, HTTPS sertifikası valid ve site iki VDS’den de yanıt veriyorsa fakat ben yerelde hâlâ açamıyorsam, serverı değiştirmeden önce yerel yolu daha ayrıntılı incelerim. DNS tutarsızsa veya remote website check de başarısızsa altyapıya bakmak için daha güçlü neden vardır.
Ping ve traceroute da dikkatli yorumlanmalıdır. ICMP filtrelenebilir veya rate limit uygulanabilir. Traceroute’ta görünmeyen bir hop o node’un bozuk olduğunu otomatik olarak göstermez; ping’e cevap vermeyen bir host HTTPS’i normal şekilde sunabilir. Bu araçlar bağlam ekler, kesin teşhis üretmez.
Benim için ana kural şu: tek bir başarılı kontrol tüm sistemin sağlıklı olduğunu kanıtlamaz; tek bir başarısız kontrol de nedeni tek başına açıklamaz.
Erişilebilirlik ile SEO aynı şey değil
Erişilebilirlik SEO açısından da önemlidir, fakat teknik outage ile ranking problemi aynı kavram değildir. Crawling indexing değildir; indexing de traffic değildir.
Bir crawler DNS, network veya server hatası nedeniyle siteye ulaşamıyorsa o anda ilgili içeriği başarılı biçimde alamaz. Google, crawling sırasında network ve DNS hatalarının server-side 5xx hatalarına benzer şekilde ele alındığını ve uzun süreli erişilemezliğin crawl ile daha önce indexlenmiş URL’leri etkileyebileceğini belgeliyor. Bu, her kısa kesintinin otomatik olarak SEO kaybı yaratacağı anlamına gelmez. Bir diagnostic tool da sonraki traffic değişiminin kesin olarak bu kesintiden kaynaklandığını kanıtlayamaz.
Kullanıcı açısından mantık daha basittir: siteye ulaşamıyorsa kullanamaz. Projeye göre bu durum session, lead, conversion veya revenue kaybı anlamına gelebilir. Teknik kontrol ise business etkisini hesaplamaz.
“Site kapalı” durumunda pratik kontrol sırası
- Belirtiyi başka bir networkten doğrula. Yerel tarayıcının tüm interneti temsil ettiğini varsayma.
- DNS’i kontrol et. Çözümlemeyi ve beklenen kayıtları doğrula.
- HTTPS/TLS’i kontrol et. Sertifikayı ve bağlantı hatalarını incele.
- Gerekli portu kontrol et. Probe konumundan erişilebilirliği test et.
- Network sinyallerini karşılaştır. Ping ve traceroute’u destekleyici bilgi olarak kullan.
- IP, reverse DNS, hosting ve CMS sinyallerine bak. Beklenen altyapıya ulaşıp ulaşmadığını anlamaya yardımcı olabilirler.
- Sonra araştırmayı daralt. Kanıtın application, server, DNS, network path veya local environment taraflarından hangisini daha güçlü gösterdiğine karar ver.
Bu evrensel bir incident response protokolü değil. Benim için esas amaç, tek bilgi “site açılmıyor” olduğu için yanlış katmanı değiştirme hatasını azaltmak.
Önce gerçek kullanım, sonra monetizasyon
Gitae şu anda monetized değil. Önce kendim için geliştirdim; kendi bilgisayarımın dışından bir siteyi hızlıca kontrol edip ardından DNS, sertifika, port ve network teşhisine farklı araçlar arasında dolaşmadan geçmek istiyordum.
Şimdiki hedefim tanılamayı daha kullanışlı hale getirmek ve projenin SEO ile gerçek talepten organik trafik alıp alamayacağını görmek. Orta düzeyde bile trafik oluşursa, anlık messenger uyarılarıyla otomatik website monitoring eklemek istiyorum. Böylece aynı fikir manuel teşhisten tespitin kendisine genişler: bir şeyin erişilemez hale geldiğini fark etmek ve sahibine hızlı inceleme başlatacak kadar bilgi vermek.
Temel fikir basit kalıyor
“Up” ve “down” belirtilerdir, açıklama değildir.
DNS, HTTPS/TLS, routing, portlar, hosting, application ve kullanıcının kendi networkü aynı görünen erişilebilirlik problemini oluşturabilir. Gitae her root cause’u sihirli biçimde bulmaz ve bu harici VDS noktaları tüm internetin ne gördüğünü göstermez. Ancak birkaç bağımsız sinyali tek yerde toplayabilir.
Benim istediğim araç tam olarak buydu: “site açılmıyor” noktasından çok daha faydalı bir soruya geçmek: “şimdi hangi katmanı araştırmalıyım?”