Hani, Bir sistemin sağlıklı çalışıp çalışmadığını anlamak için uyarı kurarsınız, tamam. Ama işin aslı şu: uyarılar zamanla gürültüye dönüşüyorsa ortada gözlemleme değil, bildirim çöplüğü var demektir. Ben bunu ilk kez 2019 sonbaharında, İstanbul’daki küçük bir SaaS ekibinde bizzat yaşadım — gece yarısı gelen onca alarmın içinde gerçek arızayı kaçırmıştık, kim fark etti dersiniz, sabah kimse. Ofise geldiğimde herkes birbirine bakıyor, hangi sayfanın gerçekten önemli olduğunu hatırlayan yok. Kulağa tanıdık geliyor mu?
Doğrusu, Muhtemelen evet.
Bu konuya bugün yeniden dönmemin sebebi de zaten bu (en azından benim deneyimim böyle). Geçen ay, Mart 2026’da bir fintech projesinde benzer tabloyu gördüm: dashboard’lar dolup taşıyor, Slack kanalları kıpkırmızı, ekipteki herkes ise omuz silkiyor. Yani uyarı sistemi çalışıyor gibi görünüyordu… ama kimse aksiyon almıyordu. İşte tam orası kritik eşik.
Uyarı gürültüsü neden sandığınızdan pahalı?
Gürültülü alarmlar sadece teknik sorun değil. Açık konuşayım: ekip kültürünü de kemiriyor, yavaş yavaş, fark ettirmeden. Sürekli çalan ama (söylemesi ayıp) çoğu zaman boş çıkan bir pager varsa insanlar iki şey yapıyor — ya alarmı görmezden geliyor ya da “bu yine saçma bir şeydir” deyip geçiyor. İkisi de kötü, üstelik ikincisi daha sinsi.
Peki neden?
İşin parasal tarafı da var tabi. Yanlış yere harcanan mühendis saatleri, gereksiz bağlam değiştirme maliyeti, geciken müdahaleler… Bunlar bir araya gelince küçük görünmüyor — özellikle startup tarafında üç kişiyle beş servisi taşıyorsanız, her yanlış sayfa doğrudan üretkenlikten çalıyor. Bunu geri kazanmak düşündüğünüzden çok daha zor oluyor.
Şahsen, Bir de moral meselesi var ki bence en yıkıcısı o. On-call nöbeti ceza gibi hissettirmeye başlarsa ekip yavaş yavaş sistemden soğuyor. 2024’te Ankara’daki bir ürün ekibinde buna şahit oldum; yeni başlayan iki mühendis sırf gece alarmlarından bunaldığı için on-call rotasyonuna isteksiz yaklaşmaya başlamıştı. Bu iyi değil. Hatta bayağı tehlikeli.
Sinyal mi, yoksa sadece ses mi?
Ben uyarıları artık şöyle düşünüyorum: her biri sınırlı bir dikkat bütçesinden pay istiyor. Alert = dikkat çekme hakkı. Eğer o hak boş yere kullanılıyorsa sisteminiz borçlanıyor demektir — ve bu borç er geç faizli geri geliyor.
Ölçmeniz gereken şey yalnızca kaç alarm düştüğü değil; kaçının gerçekten işe yaradığı. Kaçı aksiyona dönüştü? Kaçı kullanıcı etkisini erken yakaladı? Kaçı olay büyümeden durdurdu? Bunları sormadan “monitoring kurduk” demek… hmm, nasıl desem, biraz havada kalıyor.
| Uyarı tipi | Neye bakar? | Gürültü riski | Beklenen aksiyon |
|---|---|---|---|
| SLO tabanlı alarm | Error budget tüketimi / burn rate | Düşük | Kullanıcı etkisini incele |
| Semptom alarmı | Latency, hata oranı | Orta-yüksek | Triage et, gerekiyorsa yükselt |
| Altyapı alarmı | CPU, disk doluluğu, instance down | Yüksek | Araçla düzelt veya operasyona aktar |
| Sessiz sinyal olmayan bildirimler | Neredeyse her metrik eşiği aşımı | Ciddi derecede yüksek | Aksiyon yoksa kapat gitsin! |
Aksiyon alınabilir alarm nasıl kurulur?
Lafı gevelemeden söyleyeyim: iyi alarm tasarımı “bir şey bozuldu” diye bağırmaz. “Kullanıcı etkisi büyüyor” der. Aradaki fark devasa. İlki panik üretir, ikincisi karar ürettirir — ve bu ayrım, hele ki gece ikide uyandığınızda, çok ciddi anlam taşıyor. Daha fazla bilgi için Yazılım Mühendislerinde Tükenmişlik: Sessiz İşaretler yazımıza bakabilirsiniz.
SLO ile başlamak neden daha temiz?
SLO dediğimiz şey aslında ürününüzün söz verdiği hizmet seviyesiyle ilgili net çizgi çekmek demek. Bakın, ben bunu ilk kez 2022’de İzmir’deki orta ölçekli bir e-ticaret platformunda test ettim; latency bazlı alarmları azaltıp error budget odaklı akışa geçtiğimizde gece sayıları ciddi biçimde düştü. Ekip rahatladı mı? Evet. Ama daha önemlisi, doğru olaylar öne çıktı — gürültü azalınca aslında ne kadar çok şeyi kaçırdığımızı da fark ettik, bu biraz tuhaf bir histi.
Kısa bir not düşeyim buraya.
Eğer elinizde sağlam SLO varsa alerting stratejiniz daha az keyfi olur. “CPU %80 oldu” diye zırlayan sistem — kendi adıma konuşayım — yerine “son 30 dakikada kullanıcıların hata bütçesi hızla eriyor” diyen sistem kurarsınız. Bu çok daha anlamlı — hem teknik hem de yöneticiye anlatmak açısından.
İyi uyarı sistemi panik üretmez; karar üretir.
Burn rate niye işe yarıyor?
Tuhaf ama, Bunu mutfak örneğiyle anlatayım. Tencere kaynıyor diye her saniye bağıran sensör yerine suyun gerçekten taşmak üzere olup olmadığını söyleyen sensör istersiniz ya… Burn rate tam olarak öyle çalışıyor. Hızlı tüketim varsa alarm veriyor; yavaş ve önemsiz dalgalanmaları umursamıyor. Basit ama zekice. Daha fazla bilgi için EIE: Ollama’ya Rakip Yerel Yapay Zekâ Sunucusu yazımıza bakabilirsiniz.
Durun, bir saniye. Daha fazla bilgi için Klasörlerden Hafıza Kurmak: Claude Code ile İkinci Beyin yazımıza bakabilirsiniz. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
Küçük startup için bu model çok kurtarıcı oluyor çünkü az sayıda servisle bile ciddi sinyal kalitesi alabiliyorsunuz. Enterprise tarafta ise iş biraz daha karmaşık — servis bağımlılıkları fazla olduğundan burn rate’i tek katmanlı okumak yetmiyor, segmentlere bölmek gerekiyor, hatta bazen servis başına ayrı politika tanımlamak kaçınılmaz oluyor.
# Basit mantık örneği
if burn_rate_5m > threshold_high and burn_rate_1h > threshold_low:
page("Hızlı bütçe tüketimi var")
elif burn_rate_1h > threshold_mid:
ticket("İzleme gerekli")
else:
log("Şimdilik normal") Eşikler sabit olmak zorunda mı?
Hayır işte. Burada çoğu ekip duvara tosluyor çünkü her şeyi sabit eşikle çözmeye çalışıyorlar. Oysa trafik saate göre değişiyor, kullanıcı davranışı değişiyor, sistemin yükü değişiyor — bunların hepsine aynı sınırı uygulamak bazen saçma oluyor, özellikle gece yarısı gelen düşük hacimli trafiği gündüzle aynı keseye koyarsanız. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
Ama burada da fazla ileri gitmeyin derim. Dinamik eşiklerin avantajı kadar bakım yükü de var. Fazla oynarsanız ekip yeni modelinizi anlamaz hale gelir ve güven yine düşer. Denge önemli — hem burada hem de hayatın geri kalanında, neyse bu konuya girmeyelim.
Noise’u kesmenin pratik yolları neler?
Neyse uzatmayalım. Alarm kalitesini artırmak istiyorsanız sadece metrik seçmek yetmez; yönlendirme. Filtreleme katmanını da temiz kurmanız gerekir (şaşırtıcı ama gerçek). Şunlara bakın:
- Dedupe: Aynı kökten gelen beş bildirimi tek olaya indirgemezseniz insanları bezdirirsiniz. Hem de hızla.
- Grouping: Benzer alarmları tek başlık altında toplamak özellikle deploy anlarında hayat kurtarır. — ciddi fark yaratıyor
- Inhibition: Alt seviye altyapı arızası varken üst seviye semptom alarmlarını susturmak mantıklı olur.
- Eskalasyon: İlk seviyede çözülmeyen olayları otomatik olarak doğru kişiye aktarmak gerekir.
- Zaman penceresi: Her spike’a koşmak yerine kısa ve uzun pencereyi birlikte değerlendirin. — bunu es geçmeyin
Bana göre en sık yapılan hata şu: ekipler tüm zekâyı tek alarma gömmeye çalışıyor. Büyük hata. Doğru olan dağıtılmış basitliktir — routing ayrı iş yapmalı, dedupe ayrı iş yapmalı, escalation ayrı iş yapmalı (inanın bana). Hepsini tek yere yığarsanız hem anlayamazsınız hem de bir şey bozulduğunda nerede patladığını bulamazsınız.
Ha bu arada — Alertmanager + Prometheus kullanan ekiplerde grouping ve inhibition ayarıyla birkaç haftada bariz rahatlama gördüğümü söylemeliyim. Tabii sihir değil bu; düzgün kural seti gerekiyor.
Peki kaliteyi nasıl ölçersiniz?
Vallahi, Editör masasında bu yazıyı hazırlarken kendi not defterime baktım. Şubat 2026’da yazdığım bir notta şu cümle duruyordu: “Alarm sayısı düştü ama kör nokta oluştu mu?” İşte mesele tam burada başlıyor. Gürültüyü azaltırken kapsama alanını da korumanız lazım — yoksa sessizlik kazanırsınız ama güvenliği kaybedersiniz. Bu ince çizgi, inanın, çok insanı yanıltıyor.
Bak şimdi, Bence ölçmeniz gereken birkaç temel sinyal var:
- Aylık veya haftalık toplam page sayısı nedir?
- Bunların yüzde kaçı aksiyona dönüyor? (bu kritik)
- Aynı olay kaç kere tekrar ediyor?
- Müdahale süresi düşüyor mu yoksa artıyor mu?
- Tetiklenen runbook gerçekten işe yarıyor mu? (bu kritik)
İnanın, Eğer bu sorulara cevap veremiyorsanız alerting sistemi aslında veri üretiyor ama değer üretmiyor demektir. Bunu biraz acıyla söylüyorum. Ben de yıllarca sadece sayı topladım, sanmıştım ki bir şeyler yapıyorum — meğer gürültüyü güzel paketliyormuşuz, o kadar.
Küçük startup ile kurumsal yapı aynı şeyi mi ister?
Bi saniye — Kısmen evet, ama detayda hayır. Küçük ekipte amaç genelde hızlı öğrenmek ve yanlış pozitifleri hızla budamak olur. Kurumsal tarafta ise governance, denetlenebilirlik ve servis haritasına uygun eskalasyon şarttır — bunlar olmadan büyük yapılarda bir şeyin nereye gittiğini takip etmek neredeyse imkânsız hale geliyor. Startup’ta tek bir on-call zinciri yeterken enterprise’da bölge bazlı rota gerekebilir (inanın bana). Hatta bazı yerlerde gece vardiyasıyla gündüz vardiyası arasında bile farklı politikalara ihtiyaç duyuyorsunuz. Bakın şimdi, burası önemli:
Düzgün runbook olmadan hiçbir şey tamam değildir
Anlık alarmdan sonra insanlar ne yapacağını bilmiyorsa tüm tasarım eksik kalır. Runbook dediğiniz şey uzun roman olmamalıdır — üç adımlık net tarif bile bazen yeterli. Önce etkiyi doğrula, sonra kapsamı daralt, sonra gerekiyorsa escalate et. Bu kadar.
“`text
Runbook örneği:
1) Kullanıcı etkisi var mı kontrol et.
2) Son deploy’u incele.
3) Tekrarlayan hatayı izole et.
4) Gerekirse ilgili kişiye eskale et.
“`
Bunu geçen yıl Kasım ayında Berlin’de çalışan uzak ekiple test ettik; kısa runbook kullandığımız servislerde müdahale süresi gözle görülür şekilde kısaldı. Uzun dokümanlara kimsenin kriz anında bakmadığını kabul etmek lazım — hani teoride güzel duruyor ama pratikte pek işlemiyor (ilk duyduğumda inanamadım). Bunu öğrenmek için biraz acı çekmek gerekti açıkçası.
Sıkça Sorulan Sorular
## CI/CD pipeline nedir?
Oops wrong content please ignore
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.
