1. Monitoring Nedir, SIEM’den Farkı Ne?
Monitoring, sistemin “şu an sağlıklı mı?” sorusuna cevap verir: uptime, latency, hata oranı, kaynak kullanımı gibi metriklerle erken uyarı üretir. SIEM ise daha çok güvenlik olaylarını log korelasyonu ile tespit etmeye odaklanır. İkisi birlikte kullanılır; ancak monitoring olmadan sertifika bitişi, disk doluluğu veya TTFB artışı gibi operasyonel sorunlar kullanıcı şikâyetine kadar görünmeyebilir.
Bu yaklaşım, yalnız teknik alarm kurmaktan ibaret değildir; güvenilirlik odaklı izleme ile uptime, performans, sertifika ve güvenlik sinyallerini tek bir web altyapısı standardı içinde ele almak gerekir.
Monitoring nedir, SIEM’den farkı nedir?
Monitoring; sağlık ve performans metrikleriyle erken uyarı verir. SIEM ise güvenlik loglarını toplayıp korele ederek şüpheli davranışları tespit eder. Monitoring genelde önleyici/erken, SIEM ise tespit/korelasyon odaklıdır; birlikte en iyi sonucu verir.
Pratikte monitoring ile SIEM farkı doğru kurulduğunda; operasyonel alarmlar ile güvenlik log korelasyonu birbirini tamamlar ve olayın hem erken sinyalini hem de bağlamını daha hızlı görürsünüz.
Monitoring’i iş etkisi ile birlikte okumak
Teknik alarmın değeri iş etkisini gösterdiğinde artar. Otelde booking/search akışı yavaşladıysa gelir etkisi olabilir; B2B’de export kuyruğu tıkanırsa operasyon etkisi büyür. Bu yüzden monitoring KPI’ları satış/dönüşüm raporlarıyla ilişkilendirilmelidir.
Bu yüzden uptime sorunlarının satış dönüşüm etkisi görünür hale geldiğinde; rezervasyon, form ve ödeme akışındaki kayıplar teknik ekip ile iş ekipleri arasında daha net konuşulabilir.
☑ Mini Check : Monitoring temel seti var mı?
- •Uptime (HTTP/DNS/SSL) izleniyor mu?
- •p95 latency + 5xx oranı var mı?
- •CPU/RAM/disk trendi izleniyor mu?
- •Sertifika bitiş alarmı var mı?
- •Alarm iş etkisiyle ilişkilendiriliyor mu?
Ne yapmalıyım?
- • Monitoring’i health+perf+security olarak tasarla.
- • Uptime/SSL/latency üçlüsünü çekirdek yap.
- • Alarmı dashboard + runbook ile anlamlı hale getir.
- • İş etkisini raporlamaya bağla.
2. Sağlık, Performans ve Güvenlik Göstergeleri
Bu bölüm, “neyi izleyeceğim?” sorusunu üç katmanda netleştirir.
Özellikle güvenlik sinyallerinde WAF ve DDoS alarm takibi ile ani trafik artışı, blok patlaması ve saldırı kaynaklı performans bozulmalarını aynı model içinde değerlendirmek gerekir.
Health (sağlık)
- •HTTP uptime
- •DNS çözümleme sağlığı
- •Kritik servis port kontrolleri
- •DB bağlantısı ve cache gibi dependency health kontrolleri
Performance (performans)
- •Response time / TTFB
- •p95/p99 latency
- •4xx/5xx trendi
- •Rapor/export queue depth
- •DB bağlantı havuzu doygunluğu
Security (temel güvenlik sinyalleri)
- •Olağan dışı trafik artışı
- •Fail login artışı
- •WAF blok patlamaları
- •Beklenmeyen country/IP paternleri
☑ Mini Check : Metrik kapsamı
- •Health check’ler var
- •Latency ve hata oranı uçtan uca izleniyor
- •Queue ve kapasite sinyalleri mevcut
- •WAF/login sinyalleri izleniyor
- •KPI’lar tek panelde görülebiliyor
Ne yapmalıyım?
- • Her servis için golden signals seti belirle.
- • Export/rapor gibi ağır işler için queue metriklerini zorunlu kıl.
- • Güvenlik sinyallerini monitoring ile birleştir.
- • Alarm eşiklerini gerçek kullanıma göre kalibre et.
3. Uptime ve Sertifika İzleme
Uptime izleme sadece sitenin açılması değildir; DNS, SSL, redirect zinciri ve sertifika süresi de kesintiye yol açar. Sertifika bitişi tamamen önlenebilir olmasına rağmen yüksek görünürlüklü bir incident üretir.
Uptime check türleri
- •Kritik sayfalar için HTTP check
- •DNS resolve check
- •SSL expiry ve chain check
- •Kritik servis port check
Domain süresi alarmı
Domain süresi bitişi nadir ama yıkıcı olabilir; çok domain yöneten yapılarda merkezi alarm, auto-renew ve sorumluluk ataması gerekir.
☑ Mini Check : Sertifika/Domain alarmı
- •SSL expiry alarmı 30/14/7 gün seviyelerinde var
- •SSL chain hataları izleniyor
- •Domain expiry alarmı var
- •Redirect ve HSTS değişiklikleri izleniyor
- •Sertifika yenileme runbook’u yazılı
Ne yapmalıyım?
- • SSL expiry alarmını zorunlu yap.
- • Sertifika yenilemeyi otomatikleştir ve doğrula.
- • Domain expiry alarmını portföy yönetimine bağla.
- • Uptime alarmlarını on-call sürecine entegre et.
4. Capacity ve Anomali Tespiti
İyi monitoring yalnız şu an kırıldı mı sorusunu değil, yakında kırılacak mı sorusunu da cevaplar. CPU/RAM/disk kapasitesi ve trafik/queue anomalileri bu nedenle birlikte izlenmelidir.
Bu görünürlük, monitoring dashboard’u ve performans raporlaması ile desteklendiğinde latency, hata oranı, alarm sayısı ve kapasite headroom gibi metrikler yönetim seviyesinde de takip edilebilir.
Capacity metrikleri
- •CPU/RAM trendleri ve headroom
- •Disk doluluk ve büyüme hızı
- •DB storage ve IOPS
- •CDN/app cache hit ratio
Anomali sinyalleri
- •Ani trafik artışı
- •Ani 5xx artışı
- •Export kuyruğunun uzaması
- •Multi-node yapıda tek node sapması
Otel sezon öncesi kapasite testleri / B2B export yükleri
Otel tarafında sezon öncesi peak testleri ve booking/search headroom ölçümü; B2B’de rapor/export için kuyruk kapasitesi, worker sayısı ve throttle davranışı izlenmelidir.
☑ Mini Check : Anomaliye hazır mıyım?
- •Capacity dashboard ve headroom hedefi var
- •Traffic/queue anomali alarmı var
- •Multi-node sapma alarmı var
- •Peak dönem runbook’u var
- •Limit/throttling stratejisi monitoring ile bağlı
Ne yapmalıyım?
- • Headroom KPI’ı koy.
- • Export/rapor için queue alarmı zorunlu yap.
- • Anomaliyi sezon ve kampanya takvimiyle yorumla.
- • Rate limit/throttling ile overload protection bağlantısını kur.
5. Otel ve B2B İçin Incident Management Süreçleri
Monitoring alarmla biterse gürültü olur; incident management ile birleşince operasyon standardına dönüşür. Amaç doğru kişiyi uyarmak, hızlı triage yapmak, çözmek ve öğrenmeyi kalıcılaştırmaktır.
Turizm tarafında bu akış, PMS ve rezervasyon servislerine doğrudan dokunduğu için incident management süreci otel B2B bağlamında API, rezervasyon motoru ve operasyon panellerinin birlikte izlenmesi gerekir.
Incident akışı (alert→triage→resolve→postmortem)
- •Alert: doğru sinyal, doğru kanal
- •Triage: etki alanı ve öncelik
- •Resolve: hızlı çözüm + geri dönüş
- •Postmortem: kök neden, aksiyon, tekrarını önleme
On-call modeli ve gürültü yönetimi
- •Çok alarm = kimse bakmaz
- •Az ama doğru alarm = MTTR düşer
- •Eşikler gerçek kullanım desenine göre düzenli kalibre edilmelidir
Otel ve B2B için incident management süreci nasıl tasarlanır?
Önce kritik akışları tanımlayın ve bu akışların KPI’larına göre alarmları kurun. Sonra on-call sorumluluğu, triage şablonu ve çözüm runbook’larını oluşturun. Her ciddi olaydan sonra postmortem yapıp aksiyonları bakım döngüsüne bağlayın.
Bazı olaylarda çözüm yalnız alarmı susturmak değildir; restore, rollback ve süreklilik kararları da devreye girer. Bu yüzden incident sonrası disaster recovery planı, kritik incident runbook’larının parçası olarak düşünülmelidir.
☑ Mini Check : Incident olgunluğu
- •On-call ve eskalasyon net
- •Triage şablonu var
- •Runbook’lar erişilebilir
- •Postmortem kültürü var
- •Olayların iş etkisi raporlanıyor
Ne yapmalıyım?
- • Kritik akış bazlı alarm tasarla.
- • On-call ve eskalasyon çizelgesini netleştir.
- • Postmortem çıktısını bakım backlog’una bağla.
- • İş etkisi raporlamasını standardize et.
6. İçerik İçi Tablo: Örnek Alarm Türleri ve Eşikleri
| Alarm türü | Sinyal | Eşik (çerçeve) | İlk aksiyon |
|---|---|---|---|
| Uptime | HTTP check | X dk erişilemez | Trafik/edge kontrol + rollback |
| SSL expiry | Sertifika süresi | 30/14/7 gün | Yenileme + doğrulama |
| Latency | p95 response | Baseline üstü artış | Triage: DB/CPU/edge |
| Error spike | 5xx oranı | Ani artış | Deploy geri al + log incele |
| Disk | Disk doluluk | %80/%90 | Temizlik + kapasite |
| Queue | Export backlog | Sürekli artış | Worker/limit ayarı |
7. Altyapı Monitoring & Incident Management Checklist Şablonunu İndir
Altyapı Monitoring & Incident Management Checklist Şablonunu İndir — Yazılım / Sunucu ve Güvenlik (v1.0)
Bu asset; monitoring’i health+perf+security katmanlarında kurgulayıp incident management süreciyle birleştirmek için hazırlanmıştır. SSL/domain expiry gibi önlenebilir kesintileri sıfıra yaklaştırmayı ve anomali/capacity problemlerini erken yakalamayı hedefler. Alarmları iş etkisi raporlamasıyla ilişkilendirir.
Kim Kullanır?
DevOps/SRE, sistem yöneticisi, otel/B2B operasyon liderleri.
Nasıl Kullanılır?
- Kritik akışları ve golden signals setini çıkar.
- Alarm eşiklerini tanımlayıp on-call triage akışına bağla.
- Postmortem şablonu ve bakım backlog’u ile döngüyü kapat.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Health: HTTP/DNS/port check’leri var
- ▢ ✅ Perf: p95 latency + 5xx izleniyor
- ▢ ✅ Capacity: CPU/RAM/disk headroom izleniyor
- ▢ ✅ SSL expiry alarmı 30/14/7 gün kurgulu
- ▢ ✅ Domain expiry alarmı var
- ▢ ✅ Traffic anomali + WAF/login sinyali izleniyor
- ▢ ✅ Export/rapor queue depth alarmı var
- ▢ ✅ On-call ve eskalasyon net
- ▢ ✅ Runbook’lar erişilebilir
- ▢ ✅ Postmortem süreci ve aksiyon takibi var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
7) Deliverables
- •Monitoring dashboard seti
- •Alarm kural seti + runbook
- •On-call rota + eskalasyon matrisi
- •Triage şablonu
- •Postmortem şablonu + aksiyon takip
- •İş etkisi raporlama bağlantısı
- •Yıllık alarm kalibrasyonu takvimi
Bu çerçeveyi ekip içinde standarda dönüştürmek isterseniz Sunucu ve Güvenlik hizmetiyle güvenilirlik odaklı izleme sürecinizi güçlendirin. Temel karar başlıkları ve ek operasyon soruları için de Sunucu ve Güvenlik hakkında sık sorulan sorular sayfasına geçebilirsiniz.
Bir Sonraki Adım
Uptime, performans ve temel güvenlik sinyallerini tek modelde izleyip on-call + postmortem süreçleriyle kesinti sürelerini azaltmak isteyen otel ve B2B ekipleri için.
Sık Sorulan Sorular
Monitoring nedir, SIEM’den farkı nedir?▾
Hangi metrikleri ve alarmları kurmalıyım?▾
Otel ve B2B için incident management süreci nasıl tasarlanır?▾
Uptime, sertifika ve kapasite problemlerini önceden nasıl yakalarım?▾
Alarm gürültüsü neden tehlikeli?▾
İlgili İçerikler