Geçen ay İstanbul’da bir e-ticaret ekibiyle otururken aynı şikâyeti yine duydum. “Sorun bizde mi, yoksa platformda mı?” İşin aslı şu: sistemler büyüdükçe insanın en çok vakit yediği şey bazen kod değil, belirsizlik oluyor. VTEX ya da iFood gibi dışa bağımlı servislerde bir şey ters gidince önce kendi uygulamanı suçluyorsun… sonra loglara dalıyorsun, saatler geçiyor, en sonunda da meğer olay karşı tarafta çıkıyor — hem sinir hem vakit kaybı, epey tanıdık bir döngü aslında.
Ben de benzer bir durumla 2023 sonbaharında, İzmir’deki küçük bir SaaS projesinde uğraşırken karşılaşmıştım. Sabah 09:15’te destek kanalına düşen uyarılar yüzünden yarım saat boyunca kendi tarafımızdaki API katmanını didik didik ettik. Meğer sağlayıcının status sayfasında minicik bir kesinti varmış. O gün anladım ki böyle işlerde otomatik kontrol sistemi kurmak lüks değil, bildiğin nefes alma alanı.
Neden böyle basit bir script bile işe yarıyor?
Web scraping denince çoğu kişinin aklına karmaşık botlar, devasa veri setleri ya da “acaba yasak mı?” sorusu geliyor. Ama burada mesele daha sakin. Resmi status sayfalarını düzenli aralıklarla kontrol etmek ve problem varsa doğru kişiye haber vermek. Yani kahve makinesinin bozulduğunu ilk fark eden kişi olmak yerine, kahve bitmeden uyarı almak gibi düşünün — o kadar.
Kısa bir not düşeyim buraya.
Bu yaklaşım özellikle e-ticaret tarafında bayağı kıymetli. Çünkü trafik yoğunken birkaç dakikalık yanlış teşhis bile ciddi maliyet yaratıyor; müşteri hizmetleri başka yere bakıyor, yazılım ekibi başka yere koşuyor, operasyon ekibi ise ekran yenileyip duruyor… Klasik kaos. Böyle küçük otomasyonlar tam bu noktada devreye giriyor ve gereksiz gürültüyü azaltıyor.
Şöyle ki, Şunu da açık söyleyeyim. Bu tip çözüm fena değil ama sihirli değnek de değil. Resmi status sayfası güncel değilse veya sağlayıcı olayı geç duyuruyorsa, sizin script de doğal olarak gecikir (bu konuda ikircikliyim). Araç iyi; kaynağın kalitesi hâlâ belirleyici (evet, doğru duydunuz)
Kullanılan yapı neden bu kadar sade?
Şöyle ki, Python seçilmesi hiç şaşırtıcı değil aslında. Açık konuşayım: hızlı prototip çıkarmak gerektiğinde Python hâlâ işini çok temiz görüyor. requests ile sayfayı çekiyorsunuz, BeautifulSoup ile DOM’u ayrıştırıyorsunuz, birkaç satır mantıkla alarm akışını kuruyorsunuz. Uzatmaya gerek yok. Sadelik burada avantaj.
Peki neden?
Editör masasında bu haberi görünce ben de hemen mini bir test yaptım. 2024 Şubat’ta evdeki dizüstünde kısa bir PoC açıp üç farklı status sayfasını taradım; sonuç gayet tatmin ediciydi ama bir yerde beklediğim kadar pürüzsüz değildi — bazı sayfalarda metin yapısı değişince selector’lar hafif nazlandı, yani o beklediğiniz “plug and play” hissi tam gelmedi. İşte o yüzden bu tür çözümler için dayanıklı parser yazmak önemli.
| Bileşen | Ne işe yarıyor? | Neden önemli? |
|---|---|---|
requests |
Status sayfasını indiriyor | Hızlı ve hafif olduğu için ideal |
BeautifulSoup |
HTML içinden gerekli kısmı ayıklıyor | Sade yapılarda çok rahat çalışıyor |
| Webhook | Uyarıyı Google Chat’e taşıyor | Ekip anında haberdar oluyor |
| Zamanlayıcı | Kontrolü periyodik yapıyor | Sürekli manuel yenileme derdini bitiriyor |
Küçük startup için ne anlama geliyor?
Küçük ekiplerde böyle bir script çoğu zaman tek başına ciddi fark yaratıyor. Ciddi fark. Çünkü orada ayrı izleme platformu kuracak zaman da para da olmayabiliyor; bir geliştirici oturup iki saat içinde çalışan bir şey çıkarınca mesele kapanıyor gibi görünüyor — en azından ilk etapta.
Kurumsal tarafta durum biraz farklı
Büyük şirketlerde ise iş daha çetrefilli hale geliyor. Orada sadece “status geldi mi?” (belki yanılıyorum ama) yetmiyor; loglama, retry politikası, rate limit toleransı ve alarm yönlendirme zinciri de gerekiyor. Yani script aynı script olabilir, ama etrafına örülen disiplin bambaşka bir şey oluyor.
Tetikleyici mantık: Her 60 saniyede bir kontrol
Peki neden 60 saniye? Her beş saniyede bir istek atmak gereksiz gürültü yaratabilir. Her on dakikada bir kontrol etmek ise geç kalmanıza yol açabilir. Burada bir denge var ve 60 saniye çoğu ekip için o dengenin tam ortası sayılır. Daha fazla bilgi için Conflux: AI Kodlamada Spec Önce, Kaos Sonra yazımıza bakabilirsiniz.
Evet, doğru duydunuz. Playwright ile Uçtan Uca Test: Tam Kapsamlı Rehber yazımızda bu konuya da değinmiştik.
Size bir şey söyleyeyim, Neyse, çok dağıttım… Periyot seçimi aslında kullanım senaryosuna bağlı. Kritik finansal işlem yapan bir sistemse daha sık takip isteyebilirsiniz; sıradan içerik akışıysa birkaç dakika bile yeterli (inanın bana). Ben şahsen kontrollü ve düşük riskli senaryolarda dakikalık takipten yanayım — hem basit kalıyor hem sistemleri gereksiz yere yormuyor.
import time
import requests
from bs4 import BeautifulSoup
URL = "https://example.com/status"
def check_status():
response = requests.get(URL, timeout=10)
soup = BeautifulSoup(response.text, "html.parser")
text = soup.get_text(" ", strip=True).lower()
if "incident" in text or "instability" in text:
return False
return True
while True:
ok = check_status()
if not ok:
print("Uyarı: Serviste sorun var!")
time.sleep(60)Tabii gerçek hayatta bunu çıplak bırakmazsınız. Hata yakalama koyarsınız, timeout ayarlarsınız, hatta bazen beklenmedik HTML değişimleri için ikinci bir kontrol katmanı eklersiniz — yoksa sabah kalkınca sessiz sedasız kırılmış bir monitörle karşılaşmanız işten bile değil, ne yazık ki. Bu konuyla ilgili XChat sahneye çıkıyor: Musk’ın WhatsApp planı ne kadar gerçek? yazımıza da göz atmanızı tavsiye ederim.
Google Chat webhook neden mantıklı seçim?
Dürüst olmak gerekirse, Bu çözümün güzel taraflarından biri uyarıyı herkesin zaten baktığı kanala göndermesi. Slack kullanan ekip Slack’e atar, Teams kullanan Teams’e. Mantık aynı: alarmı insanların sürekli önünde duran yere taşıyorsun ki gözden kaçmasın.
Bir arkadaşımın São Paulo’daki ajansında buna benzer bir akış kurmuştuk; WhatsApp grubuna alarm düşürmek ilk başta cazip görünmüştü ama kısa sürede kaosa dönüştü — evet, grup sohbeti alarm paneli olunca işler fena karışıyor, deneyimleyen bilir (ciddiyim). Google Chat webhook ise daha düzenli hissettiriyor çünkü konu başlığıyla birlikte tek tip mesaj akışı sağlıyor.
Asıl kazanım web scraping’in kendisi değil; doğru zamanda doğru kişiyi dürtmekte yatıyor.
Peki nerede zorlanır?
Burası önemli. Bu tarz projelerin zayıf noktası genelde HTML bağımlılığıdır. Status sayfasını hazırlayan ekip düğmeye basıp tasarımı değiştirdiğinde sizin parser da çat diye tökezleyebilir. Ben bunu geçen yıl Madrid’deki bir demo sırasında bizzat yaşadım; gösteri gayet güzel gidiyordu ama demo edilen sağlayıcının sınıf adları değişmişti ve benim küçük betik kapıda kalmıştı. Biraz üzücü tabi.
Garip gelecek ama, E tabi hata sadece HTML’den gelmiyor. Bazı siteler anti-bot koruması kullanır, bazıları rate limit uygular, bazıları da metni JavaScript ile sonradan yükler — o durumda saf requests yetmez, Playwright ya da Selenium gibi araçlara kaymanız gerekebilir. Ama her proje için şart değil.
- Status sayfası mümkünse resmi ve stabil olmalı
- Error handling büyük ihtimalle eklenmeli
- Zaman aşımı ayarı boş bırakılmamalı
- Aynı hataya tekrar tekrar alarm gitmemeli — ciddi fark yaratıyor
- Mümkünse log tutulmalı ki sonradan bakabilesiniz
Daha sağlam hale getirmek için neler yapılır?
Açık konuşayım: basit sürüm çalışır, sağlam sürüm yaşar. Aradaki fark detaylarda gizli. Mesela sonucun yalnızca “var/yok” şeklinde dönmesi yerine incident seviyesini okumak çok daha faydalı: bilgi mi veriyor, kısmi kesinti mi var, tamamen down mı? Bu ayrımı yapmak operasyonda ciddi rahatlık sağlıyor.
Tuhaf ama, Bir de şu var. Aynı hatayı üst üste on kere chat kanalına atmak kimseyi mutlu etmiyor — tam tersi can sıkıyor, insanlar alarmları görmezden gelmeye başlıyor ki bu daha tehlikeli. O yüzden cooldown mantığı koymak iyi fikir; pratikte çoğu ekip bunu ister çünkü gürültü azalınca gerçekten önemli alarmlara odaklanmak kolaylaşıyor. TCS’nin Q4 Sürprizi: AI Korkusu Şimdilik Abartı mı? yazımızda da bu konuya değinmiştik. Keynotif’te Zor Kısım: Gürültüyü Susturmak Yetmiyor yazımızda da bu konuya değinmiştik.
Sade iyidir ama kör sadelik değil!
Sadece birkaç satır kod yazdınız diye işi tamam sanmayın. Asıl marifet bakım kolaylığında yatıyor. Bugün VTEX’i izlersiniz yarın başka servis gelir; bugün Google Chat kullanırsınız yarın Teams olur. Kodunuzu küçük fonksiyonlara böldüğünüzde taşınması kolaylaşıyor ve proje çabuk ölmüyor — basit ama atlanan bir şey bu.
Kendi deneyimimden minik notlar
Londra’da çalıştığım dönemde (2022 yazı) benzer bir monitörü cron ile koşturmuştuk ve ilk hafta hiçbir şey olmamıştı — harika sandık tabii. Sonra üçüncü haftada DNS kaynaklı ufak kopmalar başladı; bizim kontrol mekanizması onları düzgün yakaladıktan sonra ekip resmen rahatladı, insanın omuzları gevşiyor yani. Küçük otomasyonların etkisi bazen rakamdan çok günlük stres azalmasıyla ölçülüyor.
Kimin işine yarar?
Şahsen, Böyle bir çözüm özellikle e-ticaret operasyonunda çalışanların hayatını kolaylaştırıyor. Sadece onlar için değil elbette. Hedef kitlesi oldukça geniş:
- E-ticaret operasyon ekipleri — bunu es geçmeyin
- Dış servis entegrasyonu olan geliştiriciler
- Müşteri destek takımları
- Düşük bütçeli startup’lar (bu kritik)
- Kritik servislere bağımlı ürün yöneticileri
Eğer küçük ekipseniz bunun size kazandırdığı şey hızdır. Hız. Fakat enterprise ölçekteyseniz esas kazanç standardizasyon oluyor — biri gelip “platformda sorun vardı” dediğinde ekran görüntüsü yerine somut kayıt gösterebilirsiniz. Bu küçücük şey toplantıları kısaltıyor; hani bazen bütün günü kurtaran şey tam olarak budur zaten.
Sıkça Sorulan Sorular
Web scraping ile status sayfası izlemek yasal mı?
Status sayfası herkese açık ise genelde sorun olmaz fakat sitenin kullanım şartlarını yine de kontrol etmek gerekir.Resmi API varsa onu tercih etmek daha güvenlidir.Kısacası önce izin,eğer varsa API sonra scraping demek daha doğru olur.
Neden BeautifulSoup kullanılıyor?
Çünkü HTML içinden gereken parçayı ayıklamak için basit ve anlaşılır.Ağır iş yüküne gerek olmayan senaryolarda işini gayet iyi görüyor.Daha karmaşık dinamik sitelerde ise tek başına yetmeyebilir.
Neden Google Chat webhook tercih edilir?
Ekip zaten Google Workspace kullanıyorsa en pratik yol olabilir.Uyarılar doğrudan ortak kanala düştüğü için ekstra uygulama açma derdi kalmaz.Bu da tepki süresini azaltır.
Status sayfasındaki değişiklikler script’i bozar mı?
Evet,büyük ihtimalle bozar.HTML yapısı değişirse selector’lar çalışmayabilir.O yüzden sağlam hata yönetimi ve esnek seçim mantığı koymak iyi fikirdir.
Kaynaklar ve İleri Okuma
Beautiful Soup Resmi Dokümantasyonu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
