Olay müdahale süresini en çok kısaltan API izleme uyarıları, daha ilk bildirimde neyin yanlış gittiğini, sorunun nerede yaşandığını ve etkinin ne kadar ciddi olduğunu söyleyen uyarılardır. “Uç nokta başarısız oldu” diyen bir uyarı, müdahale eden kişiyi hatanın türünü, hangi uç noktanın etkilendiğini, hangi bölgeden kaynaklandığını ve gerçek kullanıcıları etkileyip etkilemediğini araştırmaya zorlar. “Ödeme API'si 5 bölgenin 3'ünden 503 döndürüyor, hata oranı %34, 90 saniye önce başladı” diyen bir uyarı ise müdahale eden kişiyi doğrudan önceliklendirme ve kurtarma aşamasına taşır.
Bu iki uyarı arasındaki fark izleme kapsamı değildir; uyarı tasarımıdır. Her iki ekibin de izlemesi vardır. Ancak ikinci ekip çözüme daha hızlı ulaşır, çünkü uyarının kendisi, ilk ekibin elle yapmak zorunda olduğu araştırmanın ilk 5 ila 15 dakikasını ortadan kaldırır. Yılda yüzlerce olay boyunca bu tasarım farkı birikerek ortalama çözüm süresinde (MTTR) çarpıcı farklılıklara dönüşür.
Bu rehber, olay müdahale süresini kısaltmada en büyük etkiye sahip API izleme uyarı türlerini sıralıyor, her birinin neden işe yaradığını açıklıyor ve en yüksek operasyonel değer için nasıl yapılandırılacaklarını anlatıyor.
Uyarı Tasarımı Neden Uyarı Sayısından Daha Önemlidir?
Çoğu ekibin uyarı eksikliği yoktur. Eksik olan, müdahaleyi hızlandıran uyarılardır. Yüzlerce eşik tabanlı tetikleyiciye sahip gürültülü bir izleme sistemi, müdahale süresini aslında uzatabilir; çünkü müdahale edenler önemli olan sinyali bulmadan önce alakasız sinyalleri ayıklamak zorunda kalır.
Olay müdahale süresini kısaltan uyarıların birkaç ortak özelliği vardır. Gerçek müşteri etkisine güvenilir şekilde işaret eden koşullarda tetiklenirler. İlk araştırma aşamasını atlamaya yetecek kadar bağlam içerirler. Sorunu gerçekten çözebilecek kişiye veya ekibe yönlendirilirler. Ve tetiklendiklerinde ekibin onları ciddiye alacağı kadar seyrektirler.
Uyarı kalitesi, bir ekibin tespitten çözüme ne kadar hızlı geçtiğini en doğrudan belirleyen operasyonel değişkendir. Kaliteyi iyileştirmeden daha fazla uyarı eklemek, müdahaleyi çoğu zaman hızlandırmak yerine yavaşlatır.
Uyarı Türü 1: Çok Bölgeli Erişilebilirlik Hatası
Müdahale süresine etkisi: Çok yüksek
Çok bölgeli erişilebilirlik uyarısı, bir API uç noktası birden fazla bağımsız izleme konumundan aynı anda başarısız olduğunda tetiklenir. Bu, müdahale süresini kısaltmada en değerli uyarı türüdür; çünkü boşa harcanan araştırmanın en yaygın kaynağını, yani geçici yerel arızaların neden olduğu yanlış alarmları ortadan kaldırır.
Bir uyarı, uç noktanın üç veya daha fazla coğrafi konumdan başarısız olduğunu doğruladığında, müdahale eden kişi “Bu gerçek mi?” sorusunu hemen atlayıp doğrudan “Buna ne sebep oluyor?” sorusuna geçebilir. Yalnızca bu atlama bile bir olayın kritik ilk aşamasında 5 ila 10 dakika kazandırabilir.
Çok bölgeli doğrulama aynı zamanda anında tanısal bağlam sağlar. Arıza küreselse, sorun büyük olasılıkla kaynaktadır: bir dağıtım hatası, bir veritabanı sorunu veya bir yapılandırma değişikliği. Arıza bölgeselse, sorun DNS, CDN, yönlendirme veya bölgesel bir altyapı bileşeni olabilir. Bu coğrafi sinyal, müdahale eden kişi tek bir pano açmadan önce araştırma kapsamını daraltır.
Nasıl yapılandırılır?
Uyarı tetiklenmeden önce en az 2 ila 3 bağımsız bölgeden doğrulama şartı koyun. Kritik uç noktalar için kontrol aralığını 30 ila 60 saniye olarak ayarlayın. Başarısız ve sağlıklı bölgelerin listesini uyarı içeriğine ekleyin. Uyarıyı PagerDuty, telefon veya yüksek öncelikli Slack bildirimiyle etkilenen hizmetin nöbetçi mühendisine yönlendirin.
Uyarı Türü 2: Temel Seviyenin Üzerinde Hata Oranı Artışı
Müdahale süresine etkisi: Çok yüksek
Hata oranı artışı uyarısı, başarısız API yanıtlarının oranı uç noktanın normal temel seviyesinin belirgin şekilde üzerine çıktığında tetiklenir. Bu uyarı türü, gerçek API olaylarının en yaygın örüntüsünü yakaladığı için müdahale süresini kısaltır: bir şey bozulmuş ve hata oranı sıçramıştır.
Burada kilit ifade “temel seviyenin üzerinde”dir. “Hata oranı %5'i aşarsa uyar” gibi sabit bir eşik, doğal olarak daha yüksek hata oranına sahip uç noktalarda gürültü yaratır ve temel hata oranı çok düşük olan uç noktalardaki sorunları kaçırır. Temel seviyeye duyarlı uyarı, göreli değişimi tespit eder ve bu neredeyse her zaman gerçek bir olayın daha iyi bir göstergesidir.
Hata oranı uyarıları anında ciddiyet bağlamı sağlar. %0,5'ten %1'e iki katlık bir artış dikkate değerdir ancak acil olmayabilir. %0,5'ten %10'a yirmi katlık bir artış ise ciddi bir soruna işaret eder. Uyarıya mevcut oranı, temel oranı ve değişimin büyüklüğünü eklemek, müdahale eden kişiye bir panoya bakmasına gerek kalmadan anında ciddiyet değerlendirmesi sunar.
Nasıl yapılandırılır?
Her uç nokta için temel hata oranını önceki 7 ila 14 günden hesaplayın. Mevcut hata oranı art arda 2 ila 3 kontrol aralığı boyunca temel seviyenin 3 ila 5 katını aştığında uyarı verin. Mevcut oranı, temel oranı, hata türü dağılımını (5xx, 4xx ve zaman aşımı) ve uç nokta adını ekleyin. Kritik iş uç noktalarını dahili veya ikincil uç noktalardan farklı ciddiyet seviyeleriyle ayırın.
Uyarı Türü 3: P95 veya P99 Gecikme Eşiği Aşımı
Müdahale süresine etkisi: Yüksek
Yüzdelik dilim gecikme uyarısı, 95. veya 99. yüzdelik dilimdeki yanıt süresi önceden tanımlanmış bir eşiği aştığında tetiklenir. Bu uyarı türü, performans düşüşünü erişilebilirlik hatalarına veya hata oranı artışlarına yol açacak kadar ciddileşmeden önce, erken aşamada yakalayarak müdahale süresini kısaltır.
Gecikme artışı çoğu zaman yaklaşan bir olayın ilk görünür sinyalidir. Bağlantıları tükenen bir veritabanı, yavaşlayan bir alt bağımlılık, ilerleyen bir bellek sızıntısı veya doygunluğa ulaşan bir iş parçacığı havuzu, doğrudan arızaya yol açmadan önce artan kuyruk gecikmesi (tail latency) olarak kendini gösterir. P95 veya P99 üzerinden uyarı vermek, ekibe kısmi bir performans düşüşünün tam bir kesintiye dönüşmesini önleyebilecek bir avantaj sağlar.
Yüzdelik dilim uyarılarının ortalama gecikme uyarılarından daha iyi sonuç vermesinin nedeni hassasiyettir. Ortalaması 200 ms olan bir API'nin P99 değeri 4 saniye olabilir. Ortalama gecikme uyarısı yeşil kalırken her 100 kullanıcıdan biri medyanın 20 katı kadar bekler. P95 ve P99 uyarıları bu kuyruk bozulmasını doğru ve erken tespit eder.
Nasıl yapılandırılır?
P95 ve P99 eşiklerini her uç noktanın geçmiş performansına göre bir pay bırakarak belirleyin. Geçmiş P95 değeri 300 ms ise, 500 ila 600 ms'lik bir eşik gürültü yaratmadan anlamlı bozulmaları yakalar. Eşiğin art arda 2 ila 3 kontrol aralığı boyunca aşılmasını şart koşun. Müdahale eden kişinin sorunun geniş çaplı mı (P50 yükselmiş) yoksa yalnızca kuyrukta mı (P50 normalken P99 yükselmiş) olduğunu hemen değerlendirebilmesi için uyarıya mevcut P50, P95 ve P99 değerlerini ekleyin.
Uyarı Türü 4: Bağımlılık Hatası Uyarısı
Müdahale süresine etkisi: Yüksek
Bağımlılık hatası uyarısı, hizmetinizin bağlı olduğu üçüncü taraf bir API hata döndürmeye veya gecikme eşiklerini aşmaya başladığında tetiklenir. Bu uyarı türü, belirli bir nedenle müdahale süresini önemli ölçüde kısaltır: dağıtık sistemlerdeki en çok zaman alan yanlış teşhisi ortadan kaldırır.
Bağımlılık izlemesi olmadan, müşteriye dönük bir API bozulduğunda ekip; uygulama kodunu, veritabanını, barındırma altyapısını ve iç ağı inceler ve sonunda kök nedenin kontrol edemedikleri harici bir hizmet olduğunu keşfeder. Bu araştırma 15 ila 30 dakika veya daha fazlasını alabilir. Müşteriye dönük uyarıyla aynı anda veya ondan önce tetiklenen bir bağımlılık uyarısı, ekibi hemen gerçek nedene yönlendirir.
Bağımlılık uyarıları aynı zamanda müdahale eylemini de değiştirir. Sorun dahiliyse ekip bir düzeltme dağıtır. Sorun harici bir bağımlılıksa ekip bir yedek mekanizmayı devreye alır, tedarikçiye destek talebi açar ve etkiyi paydaşlara iletir. Hangi müdahale yolunun izleneceğini bilmek, bir olayın ilk dakikalarında ciddi zaman kazandırır.
Nasıl yapılandırılır?
Her kritik üçüncü taraf API uç noktasını sentetik kontrollerle bağımsız olarak izleyin. Gecikme ve hata oranını kendi hizmetlerinizden ayrı takip edin. Bağımlılığın hata oranı veya gecikmesi normal temel seviyesini aştığında uyarı verin. Uyarıya tedarikçi adını, uç noktayı ve gözlemlenen hata örüntüsünü ekleyin. Hem tedarikçi ilişkisinin hem de müşteri etkisinin eş zamanlı yönetilebilmesi için uyarıyı hem entegrasyon sahibine hem de nöbetçi ekibe yönlendirin.
Uyarı Türü 5: Yanıt Doğrulama Hatası
Müdahale süresine etkisi: Yüksek
Yanıt doğrulama uyarısı, bir API başarılı bir durum kodu döndürdüğü hâlde yanıt gövdesi içerik düzeyindeki doğrulamalardan geçemediğinde tetiklenir: zorunlu alanların eksik olması, yanlış veri türleri, veri beklenen yerde boş diziler veya başka açıdan başarılı görünen bir yanıtın içine gömülü hata mesajları. Bu uyarı türü, diğer uyarıların tamamen kaçırdığı bir olay kategorisinde müdahale süresini kısaltır.
Sessiz doğruluk hataları, tüm standart sağlık göstergeleri normal göründüğü için teşhisi en zor olaylar arasındadır. Uç nokta ayaktadır. Gecikme iyidir. Durum kodu 200'dür. Ancak veri yanlıştır. Yanıt doğrulama uyarıları olmadan bu olaylar genellikle müşteriler tarafından fark edilir ki bu, mümkün olan en yavaş tespit yöntemidir. Sorunun başlaması ile birinin onu araştırması arasındaki süre saatler sürebilir.
Yanıt doğrulama uyarısı, doğruluk hatasını başladığı anda yakalayarak bu boşluğu kapatır. Uyarı ayrıca müdahale eden kişiye hangi doğrulama kuralının başarısız olduğuna dair özel bilgi verir ve bu da araştırmayı ilgili kod yoluna veya veri kaynağına hemen daraltır.
Nasıl yapılandırılır?
Her kritik uç nokta için doğrulama kuralları tanımlayın: zorunlu alanlar, beklenen veri türleri, boş olmayan diziler, değer aralıkları ve yanıt gövdesindeki bilinen hata örüntüleri. Geçici veri sorunlarından kaynaklanan yanlış alarmları önlemek için doğrulama art arda 2 veya daha fazla kontrolde başarısız olduğunda uyarı verin. Başarısız olan belirli doğrulamayı ve alınan gerçek değeri ekleyin. Uyarıyı genel olmaktan çıkarıp eyleme dönüştürülebilir kılan şey bu bağlamdır.
Uyarı Türü 6: Hata Bütçesi Tüketim Hızı (Burn Rate) Uyarısı
Müdahale süresine etkisi: Orta-yüksek
Burn rate uyarısı, hizmet hata bütçesini ölçüm dönemi boyunca SLO'yu sürdürebilecek hızdan daha hızlı tükettiğinde tetiklenir. Bu uyarı türü, müdahale süresini tek bir arızayı daha hızlı tespit ederek değil, ne kadar acil müdahale edileceğine karar vermek için gereken operasyonel bağlamı sağlayarak kısaltır.
Aylık hata bütçesinin %0,1'ini tüketen kısa bir sıçrama anında müdahale gerektirmeyebilir. Aylık bütçenin %30'unu 2 saatte tüketen kalıcı bir bozulma ise acil eskalasyon gerektirir. Burn rate uyarısı bu ayrımı otomatik olarak yapar; bu da müdahale eden kişinin ciddiyeti elle hesaplamak zorunda kalmaması anlamına gelir.
Bu uyarı türü en çok SLO'larını tanımlamış ekipler için değerlidir. Ham hata verisini iş açısından anlamlı bir aciliyet sinyaline dönüştürür. Ekip, %2'lik bir hata oranının ciddi olup olmadığını tartışmak yerine, mevcut hızla SLO'nun 6 saat içinde ihlal edileceğini görebilir ve bu da kararı netleştirir.
Nasıl yapılandırılır?
Kritik uç noktalar için erişilebilirlik ve gecikme bileşenleri içeren SLO'lar tanımlayın. Burn rate'i, mevcut hata oranının SLO için sürdürülebilir maksimum orana oranı olarak hesaplayın. Birden fazla burn rate eşiğinde uyarı verin: hızlı tüketim (bütçeyi sürdürülebilir hızın 10 katıyla tüketme) anında nöbetçiyi çağırmalı, yavaş tüketim (sürdürülebilir hızın 2 ila 3 katıyla tüketme) ise mesai saatleri içinde bildirim göndermelidir. Mevcut burn rate'i, kalan bütçeyi ve SLO ihlaline kadar öngörülen süreyi ekleyin.
Uyarı Türü 7: Çok Adımlı İş Akışı Hatası
Müdahale süresine etkisi: Orta-yüksek
İş akışı hatası uyarısı, sentetik çok adımlı bir API testi dizinin herhangi bir noktasında başarısız olduğunda tetiklenir. Bu uyarı türü, tek uç nokta izlemenin tespit edemediği olaylarda müdahale süresini kısaltır: duruma bağlı hatalar, kimlik doğrulama akışı hataları ve yalnızca API'ler gerçekçi bir sırayla çağrıldığında ortaya çıkan entegrasyon kopuklukları.
Örneğin kimlik doğrulama, sepet getirme, ödeme işleme ve sipariş onayını içeren bir ödeme iş akışı, her bir uç nokta tek başına test edildiğinde sağlık kontrolünden geçse bile ödeme adımında başarısız olabilir. Hatayı tetikleyen, önceki adımlarda oluşan durumdur. Bunu yalnızca çok adımlı sentetik bir test yakalar.
İş akışı uyarıları, hatanın dizi içindeki yerini kesin olarak gösterir. Uyarı, müdahale eden kişiye yalnızca iş akışının başarısız olduğunu değil, hangi adımın başarısız olduğunu, önceki adımların ne döndürdüğünü ve hata yanıtının ne içerdiğini de söyler. Bu netlik, genel bir erişilebilirlik uyarısına kıyasla araştırma süresini önemli ölçüde kısaltır.
Nasıl yapılandırılır?
API'niz üzerinden en kritik kullanıcı yolculuklarını taklit eden sentetik iş akışları oluşturun: oturum açma, temel veri getirme, yazma işlemleri ve temizlik. Bu iş akışlarını 1 ila 5 dakikada bir çalıştırın. Bir iş akışı herhangi bir adımda başarısız olduğunda adım adını, gönderilen isteği ve alınan yanıtı içeren bir uyarı verin. Uyarıyı yalnızca başarısız uç noktanın sahibi olan ekibe değil, iş akışının iş işlevinden sorumlu ekibe yönlendirin.
Uyarı Türü 8: Coğrafi Anomali Uyarısı
Müdahale süresine etkisi: Orta
Coğrafi anomali uyarısı, API performansı veya erişilebilirliği izleme bölgeleri arasında belirgin şekilde farklılaştığında tetiklenir. Bu uyarı türü, başka türlü tespit edilmesi zor olan belirli bir olay kategorisinde müdahale süresini kısaltır: DNS sorunları, CDN yanlış yapılandırmaları, yönlendirme asimetrileri veya bir pazarı etkilerken diğerlerini sağlıklı bırakan altyapı sorunlarından kaynaklanan bölgesel arızalar.
Coğrafi anomali tespiti olmadan bu olaylar, etkilenen bölgedeki müşteriler sorun bildirmeye başlayana kadar çoğu zaman fark edilmez. Ekip, birden fazla noktadan elle kontrol edene kadar sorunun bölgesel olduğunu anlamayabilir ve bu da araştırma süresini uzatır. Hangi bölgelerin etkilendiğini ve hangilerinin sağlıklı olduğunu hemen belirleyen bir uyarı, araştırmayı ileri taşıyan coğrafi bağlamı sağlar.
Nasıl yapılandırılır?
Performansı ve erişilebilirliği her kontrol bazında izleme bölgeleri arasında karşılaştırın. Bir veya daha fazla bölge çoğunluktan belirgin şekilde daha kötü sonuç verdiğinde uyarı verin. Uyarıya etkilenen bölgeleri, sağlıklı bölgeleri ve performans farkını ekleyin. Bu, özellikle CDN'ler üzerinden sunulan veya bölgesel altyapı bileşenlerine sahip API'ler için değerlidir.
Bu Uyarı Türleri Birlikte Nasıl Çalışır?
Hiçbir uyarı türü tek başına her arıza modunu kapsamaz. En etkili izleme sistemleri, tespiti farklı boyutlarda katmanlayan uyarı türlerinin bir kombinasyonunu kullanır.
Çok bölgeli erişilebilirlik uyarıları kesin arızaları hızla yakalar. Hata oranı artışı uyarıları kısmi arızaları ve dağıtımla ilgili kırılmaları yakalar. Gecikme yüzdelik dilim uyarıları erken bozulma sinyallerini yakalar. Bağımlılık uyarıları harici arızaları anında yakalar. Doğrulama uyarıları sessiz doğruluk sorunlarını yakalar. Burn rate uyarıları aciliyet bağlamı sağlar. İş akışı uyarıları entegrasyon ve durum hatalarını yakalar. Coğrafi anomali uyarıları bölgesel sorunları yakalar.
Bu uyarı türleri doğru yönlendirme ve ciddiyet sınıflandırmasıyla birlikte çalıştığında, ekibin medyan olay müdahale süresi önemli ölçüde düşer; çünkü neredeyse her API arızası kategorisi hızla tespit edilir, doğru teşhis edilir ve hemen harekete geçmeye yetecek bağlamla doğru kişiye yönlendirilir.
Müdahale Süresini Kısaltan Uyarı Tasarımı İlkeleri
Doğru uyarı türlerini seçmenin ötesinde, birkaç tasarım ilkesi tüm kategorilerde müdahale süresini tutarlı şekilde kısaltır.
Uyarı İçeriğine Bağlam Ekleyin
Her uyarı; uç nokta adını, uyarıyı tetikleyen metriği, mevcut değeri, eşiği veya temel seviyeyi, etkilenen bölgeleri ve koşulun ne zaman başladığını içermelidir. Bu bağlam, müdahale edenlerin aksi hâlde elle yapmak zorunda kalacağı ilk pano kontrolü turunu ortadan kaldırır.
Ortak Kanallara Değil, Sahiplere Yönlendirin
Genel bir izleme kanalına gönderilen uyarı, dikkat çekmek için diğer tüm uyarılarla yarışır. Doğrudan başarısız hizmetin sahibi olan ekibe gönderilen uyarı ise hemen ilgi görür. Sahiplik tabanlı yönlendirme, ekiplerin müdahale süresini kısaltmak için yapabileceği en basit ve en etkili değişikliklerden biridir.
Farklı Eskalasyon Yollarına Sahip Ciddiyet Seviyeleri Kullanın
Her uyarı birini çağırmamalıdır. İş açısından kritik uç noktalardaki kritik uyarılar, anında müdahale için PagerDuty veya telefon bildirimlerini kullanmalıdır. Uyarı seviyesindeki bildirimler aynı gün içinde incelenmek üzere Slack veya e-posta kullanmalıdır. Bu kademeli yaklaşım, kritik kanaldaki yorgunluğu önlerken düşük ciddiyetli sinyallerin de incelenmek üzere kaydedilmesini sağlar.
Bakım Pencerelerinde Uyarıları Bastırın
Planlı dağıtımlar ve bakım çalışmaları beklenen geçici arızalar yaratır. Bu arızalar uyarı tetiklerse ekip ya onları görmezden gelir (kendini uyarıları görmezden gelmeye alıştırır) ya da araştırır (zaman kaybeder). Bakım penceresinde bastırma, hem uyarılara duyulan güveni hem de müdahale süresini korur.
Eskalasyondan Önce Doğrulama Şartı Koyun
Bir uyarı tetiklenmeden önce art arda 2 ila 3 başarısızlık veya çok bölgeli uzlaşma şartı koymak, geçici yanlış alarmları ortadan kaldırır. Bu doğrulama mantığı, her uyarının ciddiye alınacağı kadar düşük bir uyarı hacmi sağlamak için gereklidir. Her uyarı güvenilir olduğunda, uyarının gerçek olup olmadığına karar verme adımı ortadan kalktığı için müdahale süresi iyileşir.
Müdahale Süresini Uzatan Yaygın Hatalar
En yaygın hata, doğrulama olmadan tek başarısızlıklarda uyarı vermektir; bu da gürültü yaratır ve güveni aşındırır. İkincisi, bağlam içermeyen genel uyarı mesajları kullanmaktır; bu, müdahale edenleri uyarının zaten bildiği şeyleri araştırmaya zorlar. Üçüncüsü, ciddiyet ve sahiplikten bağımsız olarak tüm uyarıları tek bir kanala yönlendirmektir. Dördüncüsü, uç noktalar arasındaki temel seviye farklılıklarını hesaba katmayan statik eşikler belirlemektir. Beşincisi, doğruluğu izlemeden yalnızca erişilebilirliği izlemektir; bu da sessiz veri hatalarının saatlerce fark edilmemesine yol açar.
Bu hataların her biri her olaya dakikalar ekler. Zamanla bu dakikalar birikerek uyarılara güvenilmeyen, araştırmaların yavaş başladığı ve olayların olması gerekenden uzun sürdüğü bir kültüre dönüşür.
Son Düşünceler
Olay müdahale süresini en çok kısaltan API izleme uyarıları, gerçek müşteri etkisini hızla tespit etmek ve müdahale edenin hemen harekete geçmesine yetecek bağlamı sunmak üzere tasarlanmış uyarılardır. Çok bölgeli erişilebilirlik hataları, temel seviyenin üzerindeki hata oranı artışları, yüzdelik dilim gecikme aşımları, bağımlılık hatası uyarıları, yanıt doğrulama hataları, burn rate uyarıları, çok adımlı iş akışı hataları ve coğrafi anomali tespiti; her biri farklı bir arıza modunu ele alır ve olay yaşam döngüsünün farklı bir aşamasını kısaltır.
En hızlı müdahale sürelerine sahip ekipler, en çok uyarıya sahip olanlar değildir. Uyarıları doğrulanmış, bağlam içeren, sahibi belli ve eyleme dönüştürülebilir olan ekiplerdir. Her uyarı, müdahale eden kişi bir pano açmadan önce üç soruyu yanıtlamalıdır: Ne başarısız oluyor, ne kadar ciddi ve kim düzeltmeli? Uyarılar bu soruları net biçimde yanıtladığında, uyarının kendisi yalnızca araştırmanın değil kurtarmanın da başlangıç noktası hâline geldiği için olay müdahale süresi düşer.