SLA Uyumluluğunu Doğru Takip Eden Bir Web Uygulaması Nasıl Yapılır

SLA Uyumluluğunu Tanımlayın ve Ne İnşa Ettiğinizi Belirleyin

SLA uyumluluğu, Hizmet Seviyesi Anlaşması (SLA) içindeki ölçülebilir vaatleri karşılama anlamına gelir—sağlayıcı ile müşteri arasındaki bir sözleşme. Uygulamanızın işi basit bir soruya kanıtla cevap vermektir: Bu müşteri için, bu zaman diliminde verdiğimiz sözü tuttuk mu?

Üç ilgili terimi ayırmak faydalıdır:

• SLI (Service Level Indicator): ham ölçüm (örneğin “başarılı kontrollerin yüzdesi”, “ilk yanıta kadar geçen süre” veya “servisin geri gelme süresi”).
• SLO (Service Level Objective): bir SLI için dahili hedef (çoğunlukla SLA’dan daha sıkı). Örnek: “%99.95 erişilebilirlik hedefi.”
• SLA: dışarıya taahhüt edilen yükümlülük, genellikle kredi veya cezalarla ilişkilidir. Örnek: “aylık %99.9 erişilebilirlik.”

İzleyeceğiniz yaygın SLA metrikleri

Çoğu SLA izleme web uygulaması, gerçek operasyonel verilere eşlenen küçük bir metrik setiyle başlar:

• Uptime / erişilebilirlik: raporlama dönemi boyunca hizmetin “çalışır” olduğu zamanın yüzdesi.
• Yanıt süresi (destek): müşteri talebi oluşturulmasından ilk insan yanıtına kadar geçen süre.
• Çözüm süresi: olay/talep oluşturulmasından kapanış veya hizmetin geri gelmesine kadar geçen süre.
• Erişilebilirlik pencereleri: “yalnızca mesai saatlerini say”, “planlı bakımı hariç tut”, veya “müşterinin zaman diliminde 08:00–18:00 arası ölç” gibi kurallar.

Uygulamayı kim kullanır—ve neden

Farklı kullanıcılar aynı gerçeği farklı biçimde görmek ister:

• Ops/SRE: ihlalleri erken tespit etmek ve olay zaman çizelgelerini doğrulamak.
• Destek ekipleri: müşteri başına yanıt ve çözüm taahhütlerini takip etmek.
• Yöneticiler: eğilimleri, riski ve ekiplerin hedefleri tutturup tutturmadığını görmek.
• Müşteriler: ne olduğunu gösteren şeffaf raporlar (ve bazen bir durum sayfası) görmek ister.

Ne inşa ediyorsunuz (ve ne inşa etmiyorsunuz)

Bu ürün izleme, kanıt ve raporlama ile ilgilidir: sinyalleri toplamak, kararlaştırılmış kuralları uygulamak ve denetime uygun sonuçlar üretmek. Bu uygulama performans garantisi vermez; onu ölçer—doğru, tutarlı ve daha sonra savunabileceğiniz şekilde.

Gereksinimler: Metrikler, Kurallar ve Kim Ne İhtiyaç Duyar

Tabloları tasarlamadan veya kod yazmadan önce, işletmeniz için “uyumluluk”ın ne anlama geldiğini acı verici şekilde netleştirin. Çoğu SLA izleme problemi teknik değil—gerekçelendirme problemidir.

Girdileri toplayın (hafızaya güvenmeyin)

Gerçeğin kaynaklarını toplamakla başlayın:

• Müşteri sözleşmeleri ve MSA’lar (ekler ve ticketing ekleri dahil)
• Servis katmanları (ör. Basic vs Premium) ve hangi müşterinin hangi kata ait olduğu
• Müşteri (veya servis) başına çalışma saatleri ve zaman dilimleri
• Hariç tutmalar ve özel kurallar: planlı bakım pencereleri, mücbir sebep, müşteri kaynaklı gecikmeler, üçüncü taraf bağımlılıkları, süre tanıma

Bu kuralları açık ifadeler olarak yazın. Bir kural net ifade edilemiyorsa, güvenilir şekilde hesaplanamaz.

Ne izlenmeli karar verin

SLA sayısını etkileyebilecek gerçek dünya “şeylerini” listeleyin:

• Olaylar/çöküşler (başlangıç, bitiş, şiddet, etkilenen servisler)
• Talepler/ticketlar (oluşturuldu, ilk yanıt, çözüm, müşteri bekleme)
• Bakım (planlı vs acil; erişilebilirliğe sayılıp sayılmadığı)
• Kısmi kesintiler (performans düşüklüğü) ve bunların sayılıp sayılmayacağı

Ayrıca kimin neye ihtiyaç duyduğunu belirleyin: destek ekipleri gerçek zamanlı ihlal riski ister, yöneticiler haftalık özet, müşteriler genellikle durum sayfası için basit özetler ister.

İlk sürüm için 1–3 metrik seçin

Kapsamı küçük tutun. Sistemin uçtan uca çalıştığını doğrulayacak minimum seti seçin, örneğin:

• Servis başına aylık Erişilebilirlik %
• Mesai saatleri içinde ilk insan yanıt süresi
• Severity-1 olaylar için çözüm süresi

Gereksinimler kontrol listesi ve başarı kriterleri

Daha sonra test edebileceğiniz tek sayfalık bir kontrol listesi oluşturun:

• Net metrik tanımları (başla/dur zaman damgaları, zaman dilimi, yuvarlama)
• Dahil/haric kurallar (bakım, müşteri bekleme)
• Katman başına hedef eşikleri (ör. %99.9, 1 saat yanıt)
• Çıktı gereksinimleri (müşteri raporu, dahili pano, dışa aktarım)

Başarı böyle görünür: iki kişi aynı örnek ayı manuel hesapladığında uygulamanız tam olarak aynı sonucu verir.

SLA, Servis, Olay ve Eventler için Veri Modeli

Doğru bir SLA izleyicisi, bir sayının neden öyle olduğunu açıklayabilen bir veri modeli ile başlar. Aylık erişilebilirlik rakamını tam olarak hangi olayların ve hangi kuralların kullanıldığına kadar izleyemiyorsanız, müşteri itirazları ve iç belirsizliklerle boğuşursunuz.

Temel varlıklar (sıkıcı ve açık tutun)

En azından modelleyin:

• Customer (tenant/account): servisler, takvimler, kontaklar ve raporlama tercihleri sahibi.
• Service: ölçülen şey (API, web uygulaması, bölgeye özgü bileşen). Birden fazla bileşeni toplamak istiyorsanız isteğe bağlı parent/child ilişkisi ekleyin.
• Plan: ticari sarmal (ör. “Gold”), genelde varsayılan SLA politika seti bağlamak için kullanılır.
• SLA policy: ölçülebilir kurallar: uptime hedefi, yanıt süresi hedefi, ölçüm penceresi ve neyin “hariç” sayıldığı.
• Incident: insan-dostu gruplama (başlık, şiddet, zaman çizelgesi) ve altında yatan eventlere referans.
• Event: hesaplamaları yönlendiren değiştirilemez gerçekler (durum değişiklikleri, monitoring sinyalleri, onaylar).

Kullanışlı bir ilişki: customer → service → SLA policy (muhtemelen plan üzerinden). Olaylar ve eventler daha sonra servise ve müşteriye referans verir.

Zaman-temelli izleme için minimal şema

Zaman hataları yanlış SLA hesaplarının #1 nedenidir. Saklayın:

• occurred_at olarak UTC (zaman damgası ve zaman dilimi semantiği)
• received_at (sistemin onu gördüğü zaman)
• source (monitor adı, entegrasyon, manuel)
• external_id (yeniden denemeleri dedupe etmek için)
• payload (ileride hata ayıklama için ham JSON)

Ayrıca customer.timezone (IANA string, ör. America/New_York) görüntüleme ve “mesai saatleri” mantığı için saklayın, fakat olay zamanını yeniden yazmak için kullanmayın.

Çalışma saatleri ve tatiller

Yanıt süresi SLA’ları mesai dışında duruyorsa, takvimleri açıkça modelleyin:

• working_hours müşteri (veya bölge/servis) başına: haftanın günü + başlangıç/bitiş saatleri
• holiday_calendar bir bölgeye veya müşteriye bağlı, tarih aralıkları ve etiketlerle birlikte

Kuralları veri odaklı tutun ki operasyon bir tatili deploy olmadan güncelleyebilsin.

Denetlenebilirlik: ham vs hesaplanmış

Ham eventleri append-only bir tabloda saklayın ve hesaplanmış sonuçları ayrı tutun (ör. sla_period_result). Her sonuç satırı şunları içermeli: dönem sınırları, girdiler versiyonu (politika versiyonu + motor versiyonu) ve kullanılan event ID referansları. Bu, yeniden hesaplamayı güvenli kılar ve müşteriler “Hangi kesinti dakikalarını saydınız?” dediğinde denetim izi sağlar.

Olay Alma: Veriler Uygulamaya Nasıl Girer

SLA sayılarınız, aldığınız eventler kadar güvenilirdir. Amaç basit: önemli olan her değişikliği (bir kesinti başladı, bir olay onaylandı, servis geri geldi) tutarlı zaman damgaları ve uyumluluk hesaplamak için yeterli bağlam ile yakalayın.

Yaygın olay kaynakları

Çoğu ekip, bir karışım sistemden çeker:

• Ticketing / olay araçları (Jira Service Management, ServiceNow, Zendesk): oluşturuldu/onaylandı/çözüldü zaman damgaları, öncelik değişiklikleri, atanan kişi değişiklikleri.
• Monitoring araçları (Pingdom, Datadog, CloudWatch, Prometheus Alertmanager): up/down sinyalleri, alarm tetiklendi/temizlendi, sentetik kontrol sonuçları.
• Altyapı ve uygulama logları: deploy olayları, hata artışları, sağlık kontrolü hataları (monitoring gürültülü veya eksik olduğunda faydalı).
• Manuel girdiler: otomasyon gerçeği bilemediğinde “iş tarafından doğrulanmış kesinti başlangıcı/bitişi” veya “bakım penceresi başladı” için küçük bir UI.

Alma seçenekleri (ne zaman kullanılmalı)

Webhooklar genelde gerçek zamanlı doğruluk ve daha düşük yük için en iyisidir: kaynak sistem olayları uç noktanıza gönderir.

Polling webhooks yoksa iyi bir geri dönüş: uygulamanız periyodik olarak son cursor’dan bu yana değişiklikleri çeker. Orada rate limit ve dikkatli “since” mantığı gerekir.

CSV içe aktarma geri doldurmalar ve göçler için yardımcıdır. Tarihsel dönemleri yeniden işlemeyi kolaylaştırmak için bunu birinci sınıf alma yolu olarak ele alın.

Önerilen olay formatı (idempotentlik ile)

Yukarı akış yükleri farklı olsa bile her şeyi tek bir dahili “event” şekline normalleştirin:

• event_id (gerekli): tekrar denemelerde kararlı, benzersiz. Kaynağın GUID'sini tercih edin; yoksa deterministik bir hash oluşturun.
• source (gerekli): örn. datadog, servicenow, manual.
• event_type (gerekli): örn. incident_opened, incident_acknowledged, service_down, service_up.
• occurred_at (gerekli): olayın gerçekleştiği zaman (aldığınız zaman değil), zaman dilimi ile.
• received_at (sistem): uygulamanızın olayı aldığı zaman.
• service_id (gerekli): olayın etkilediği SLA-ilgili servis.
• incident_id (opsiyonel ama önerilir): birden fazla olayı tek bir olaya bağlar.
• attributes (opsiyonel): öncelik, bölge, müşteri segmenti vb.

event_id'yi benzersiz kısıtlama ile saklayın ki alma idempotent olsun: tekrar denemeler kopya yaratmaz.

Kötü veriyi önleyen doğrulama kuralları

Aşağıdakileri reddedin veya karantinaya alın:

• Eksik/geçersiz zaman damgalarına sahip veya occurred_at'ı çok gelecekte olan eventler.
• Bilinen bir service_id ile eşleşmeyenler (veya açık bir “eşleşmeyen” iş akışı gerektirin).
• Var olan bir event_id ile çoğaltanlar.
• Kurallarınızı bozan sıra dışı gelişler (bunları koruyun ama “inceleme gerektirir” olarak işaretleyin, sessizce üzerine yazmayın).

Bu disiplin, raporlar hakkında tartışmaya girmenizi önler—çünkü temiz, izlenebilir girdilere işaret edebileceksiniz.

SLA Hesaplama Motoru: Eventleri Uyumluluğa Çevirme

Hesaplama motorunuz, “ham eventleri” savunulabilir SLA sonuçlarına dönüştüren yerdir. Anahtar, bunu muhasebe gibi ele almaktır: deterministik kurallar, net girdiler ve yeniden oynatılabilir bir iz.

Normalleştirilmiş bir zaman çizelgesi ile başlayın

Her şeyi tek bir sıralı akıma dönüştürün (her olay veya servis-etkisi için):

• zaman damgaları (UTC) için: olay başladı, onaylandı/ilk yanıt, hafifletildi, çözüldü, yeniden açıldı
• durum değişiklikleri: duraklatıldı/tekrar başlatıldı, müşteri-bekliyor, bakım penceresi aktif
• kapsam: hangi servis(ler) ve müşteri(ler) etkilendi, hangi şiddette

Bu zaman çizelgesinden, süreleri aralıkları toplayarak hesaplayın, iki zaman damgasını körü körüne çıkarmayın.

İlk yanıt süresi (TTFR) ve çözüm süresi (TTR)

TTFR'yi incident_start ile first_agent_response (veya SLA metnine göre acknowledged) arasındaki “ücretlendirilebilir” geçen süre olarak tanımlayın. TTR'yi incident_start ile resolved arasındaki “ücretlendirilebilir” geçen süre olarak tanımlayın.

“Ücretlendirilebilir” demek şu aralıkları çıkarmak demektir:

• mesai dışı saatler (mesai-saatine özgü SLA'larda)
• açıkça verilen duraklatmalar (ör. “müşteri bekliyor”)
• planlı bakım veya müşteri kaynaklı gecikmeler gibi hariç tutmalar

Uygulama detayı: bir takvim fonksiyonu (mesai saatleri, tatiller) ve bir kural fonksiyonu saklayın; bu fonksiyon bir zaman çizelgesini alır ve ücretlendirilebilir aralıkları döndürür.

Kısmi kesintiler ve çoklu servis olayları

Önceden karar verin:

• servis başına SLA (önerilir): bir olay birden fazla servis için ayrı etki kayıtları üretebilir; her biri kendi TTFR/TTR'sine sahip olur
• müşteri başına SLA: aynı kesinti yalnızca kiracı altkümesini etkileyebilir

Kısmi kesintilerde, sözleşmeniz bunu gerektirmiyorsa etkiye göre ağırlıklandırmayın; aksi halde “degrade”yi ayrı bir ihlal kategorisi olarak ele alın.

İzlenebilirlik: girdileri, çıktıları ve yeniden oynatmaları saklayın

Her hesaplama yeniden üretilebilir olmalıdır. Şunları kalıcı hale getirin:

• kullanılan tam eventler (id'ler, zaman damgaları, kaynak)
• türetilmiş aralıklar (ne neden hariç tutuldu)
• nihai sonuçlar (TTFR, TTR, ihlal bayrakları ve kural versiyonu)

Kurallar değiştiğinde, veriyi yeniden yazmadan versiyon bazında yeniden çalıştırabilirsiniz—denetimler ve müşteri anlaşmazlıkları için kritik.

Raporlama Mantığı: Dönemler, Erişilebilirlik ve Kenar Durumları

Raporlama, SLA izlemeyi ya güvenilir kılar ya da sorgulanır hale getirir. Uygulamanız ölçülen zaman aralığını, hangi dakikaların sayıldığını ve son sayıların nasıl elde edildiğini net göstermeli.

Dönemler: takvim, faturalama ve kayan pencereler

Müşterilerinizin gerçekten kullandığı yaygın raporlama dönemlerini destekleyin:

• Takvim aylık/çeyreklik (ör. 1–31 Mart)
• Fatura döngüleri (ör. 15–14 arası, faturalarla hizalanmış)
• Kayan pencereler (ör. “son 30 gün” günlük güncellenen)

Dönemleri açık başlangıç/bitiş zaman damgaları olarak saklayın ("month = 3" demeyin) ki hesaplamaları daha sonra yeniden oynatıp açıklayabilesiniz.

Erişilebilirlik: toplam dakika vs uygun dakika

Kafa karışıklığının sık bir kaynağı, paydanın tüm dönem mi yoksa yalnızca “uygun” zaman mı olduğudur.

Her dönem için iki değer tanımlayın:

• Eligible minutes: SLA'ya sayılan dakikalar (genellikle planlı bakım, müşteri kaynaklı kesinti veya destek saatleri dışı zaman hariç)
• Downtime minutes: servisin kapalı kabul edildiği eligible dakikalar

Sonra hesaplayın:

availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes

Eğer eligible minutes sıfır olabiliyorsa (ör. bir servis yalnızca mesai içinde izleniyor ve dönem hiç mesai içermiyorsa), kuralı önceden tanımlayın: “N/A” mi yoksa %100 mü kabul edilir—ama tutarlı uygulayıp belgeleyin.

Sayıları net bir geç/kalma durumuna çevirme

Çoğu SLA hem yüzde hem de ikili bir sonuç ister.

• Yüzde: ör. dönem için %99.95
• Geç/Kal: SLA hedefiyle karşılaştırma (örn. ≥ %99.9 ise geç)

Ayrıca “ihale kalan uzaklık”ı (kalan kesinti bütçesi) tutun ki panolar sınır aşılmadan önce uyarı verebilsin.

Kasıtlı olarak ele alınması gereken kenar durumlar

• Zaman dilimleri: müşteri/sözleşme başına bir raporlama zaman dilimi seçin (genellikle müşterinin zaman dilimi) ve eventleri tutarlı şekilde dönüştürün.
• Yaz saati uygulaması (DST): bir günün 1440 dakika olduğunu varsaymayın. Dönem uzunluğunun DST geçişlerinde doğru olması için zaman dilimi farkındalıklı zaman damgaları kullanın.
• Eksik bitiş zamanları: olaylar bazen çözüldü zaman damgası içermez. Bunları “açık” olarak ele alın ve rapor bitiş zamanına kadar sınırlayın; ayrıca kayıtları temizlemek için işaretleyin.

Son olarak, ham girdileri (dahili/haric tutulan eventler ve düzeltmeler) saklayın ki her rapor “bu sayı neden böyle?” sorusuna elinizdeki verilere dayanarak cevap verebilsin.

SLA Durumunu Açık Hale Getiren UI ve Panolar

Hesaplama motorunuz mükemmel olabilir ama UI temel soruyu anında cevaplamıyorsa kullanıcıları kaybedersiniz: “Şu an SLA’yı karşılıyor muyuz, ve neden?” Ekranları, her ekranın önce açık bir durum göstermesi sonra sayılara ve bu sayıları üreten ham eventlere inmesine izin verecek şekilde tasarlayın.

Oluşturulacak ana görünümler

Genel bakış panosu (operatörler ve yöneticiler için). Küçük bir tile seti ile başlayın: mevcut dönem uyumluluğu, erişilebilirlik, yanıt süresi uyumluluğu ve varsa “ihale kalana kadar kalan süre”. Etiketleri açık tutun (ör. “Availability (this month)” yerine “Aylık Erişilebilirlik”). Birden çok SLA destekliyorsanız, önce en kötü durumu gösterin ve kullanıcıların genişletmesine izin verin.

Müşteri detayı (hesap ekipleri ve müşteri raporlaması için). Bir müşteri sayfası, o müşteri için tüm servisleri ve SLA katmanlarını özetlemeli; basit geç/uyarı/başarısız durumu ve kısa bir açıklama (“2 olay sayıldı; 18dk kesinti sayıldı”) göstermeli. /status (müşteri tarafı durum sayfası sağlıyorsanız) ve rapor dışa aktarma bağlantılarına yer verin.

Servis detayı (derin inceleme için). Burada tam SLA kurallarını, hesaplama penceresini ve uyumluluk sayısının nasıl oluşturulduğunun dökümünü gösterin. Zaman içinde erişilebilirlik grafiği ve SLA'ya sayılan olayların listesi ekleyin.

Olay zaman çizelgesi (denetimler için). Tek bir olay görünümü, olayın tespit edilmesi, onaylanması, hafifletilmesi, çözülmesi zaman çizelgesini ve “yanıt” ve “çözüm” metriklerinde hangi zaman damgalarının kullanıldığını göstermeli.

Gerçek sorulara uyan filtreler

Ekranlar arasında filtreleri tutarlı yapın: tarih aralığı, müşteri, servis, katman ve şiddet. Her yerde aynı birimleri kullanın (dakika vs saniye; yüzde için aynı ondalık hassasiyet). Kullanıcı tarih aralığını değiştirdiğinde sayfadaki her metriği güncelleyin ki uyumsuzluk olmasın.

Güveni kaybetmeden derinlemesine inceleme

Her özet metriğin bir “Neden?” yolu olmalı:

• Bir uyumluluk yüzdesinden → o dönemde sayılan olayların listesine
• Bir olaydan → ham eventlere ve hesaplamada kullanılan türetilmiş zaman damgalarına
• Erişilebilirlikten → kaynak ile birlikte kesinti aralıklarına (monitoring event vs manuel düzeltme)

Açıklama balonlarını (tooltip) terimler için ölçülü kullanın: “Hariç tutulan kesinti” veya “Mesai saatleri” gibi tanımları gösterin ve servis sayfasında tam kural metnini sunun ki insanlar tahminde bulunmasın.

Basit ama yanılmaz tutun

Kısaltmalar yerine açık dili tercih edin (“Yanıt süresi” yerine “MTTA” gibi yalnızca hedef kitle beklentisi varsa kullanın). Durum için renk ile metni birleştirin (“Riskte: hata bütçesinin %92’si kullanıldı”) ki belirsizlik olmasın. Uygulamanız denetim günlüklerini destekliyorsa SLA kurallarının ve hariç tutmaların “Son değişiklik” kutusuna küçük bir bağlantı ekleyin (/audit) ki kullanıcılar tanımların ne zaman değiştiğini doğrulayabilsin.

İhlaller için Uyarılar ve Bildirimler

Uyarılar, SLA izleme web uygulamanızın pasif bir rapordan takımın cezaları önlemesine yardımcı olan aktif bir araca dönüşmesini sağlar. En iyi uyarılar zamanında, spesifik ve yapılabilir olmalıdır—yani bir şeyin “kötü” olduğunu söylemekle kalmaz, bir sonraki adımı da belirtir.

Gerçek kararlarla eşleşen uyarı tetiklerini tanımlayın

Üç tetik türüyle başlayın:

• İhlale yaklaşma: örn. “Yanıt süresi SLA'sına uymak için 30 dakikanız kaldı” veya “Bu ay erişilebilirlik %99.92'ye düştü ve SLA %99.9.” Bu en değerli uyarıdır çünkü iyileşme sağlar.
• İhlal gerçekleşti: hesaplama motoru ilgili pencere için SLA'nın kaçırıldığını doğruladığında tetiklenir.
• Tekrarlayan ihlaller: “30 günde 3 ihlal” veya “aynı servis bu hafta iki kez ihlal etti” gibi kalıpları tespit edin; bunlar genellikle sistemik bir sorunu işaret eder.

Tetikleri müşteri/servis/SLA başına yapılandırılabilir yapın; farklı sözleşmeler farklı eşikleri tolere eder.

Kanalları seçin ve mesajları yapılabilir tutun

Uyarıları insanların gerçekten yanıt verdiği yerlere gönderin:

• E-posta denetim dostu bildirimler ve dış paydaşlar için.
• Slack hızlı iç koordinasyon için.
• SMS (isteğe bağlı) yüksek şiddetli eskalasyonlar için.

Her uyarı, yanıtlama ekiplerinin sayıları hızlıca doğrulaması için /alerts, /customers/{id}, /services/{id} ve ilgili olay veya event detay sayfasına derin bağlantılar içermeli.

Gürültüyü azaltma: çoğaltmayı önleme, sessiz saatler, eskalasyon

Aynı anahtara (müşteri + servis + SLA + dönem) sahip uyarıları gruplayarak çoğaltmayı önleyin ve soğuma penceresi boyunca tekrarları bastırın.

Takım zaman dilimi başına sessiz saatler ekleyin ki kritik olmayan “ihlale yaklaşma” uyarıları mesai dışı beklesin; ancak yüksek şiddetli “ihlal gerçekleşti” sessiz saatleri geçersiz kılabilsin.

Son olarak, escalation kuralları (örn. 10 dakika sonra on-call bildir, 30 dakika sonra yöneticiyi eskale et) destekleyin ki uyarılar tek bir gelen kutusunda takılmasın.

Erişim Kontrolü, Kimlik Doğrulama ve Denetim Kayıtları

SLA verisi hassastır çünkü dahili performansı ve müşteriye özgü hakları açığa çıkarabilir. Erişim kontrolünü SLA “matematiğinin” bir parçası olarak ele alın: aynı olay farklı bir müşterinin SLA'sı uygulandığında farklı uyumluluk sonuçları üretebilir.

İlk günden desteklenecek roller

Rolleri basit tutun, sonra daha ince izinlere büyütün.

• Admin: küresel ayarları yapılandırır, servisleri, SLA'ları, kullanıcıları, entegrasyonları ve faturalama öğelerini yönetir.
• Agent: olay oluşturur/günceller, bakım pencereleri ekler, event ekler ve postmortem notları ekler.
• Manager: kapsamı dahilinde her şeyi okur, SLA tanımlarını onaylar ve raporları dışa aktarır.
• Müşteri görüntüleyici: yalnızca kendi servis(ler)ini, SLA hedeflerini, olay geçmişini ve müşteri raporlarını görür.

Pratik bir varsayılan: RBAC + tenant scoping:

• Her kayıt (servis, SLA politikası, rapor) bir sahip tenant/müşteri içerir.
• İç kullanıcılar birden fazla tenant'a atanabilir; müşteri görüntüleyicileri tam olarak bir taneye.
• Düzenleme izinleri görüntülemeden daha dar olmalı: örn. ajanlar olayları düzenleyebilir ama SLA kurallarını değiştiremez.

Her rolün neleri görebileceği/düzenleyebileceği

Müşteri-özel veriler hakkında açık olun:

• Müşteri görüntüleyicileri hiçbir zaman dahili alanları (kök sebep hipotezleri, dahili şiddet, on-call notları, özel etiketler) görmemelidir.
• SLA politikaları versiyonlanmalı ki müşteri olay zamanında geçerli olan SLA şartlarını görebilsin.

Sizi köşeye sıkıştırmayacak kimlik doğrulama seçenekleri

İlk olarak e-posta/şifre ile başlayın ve dahili roller için MFA zorunlu kılın. Kimliği (kim olduğunu) yetkilendirmeden (neye erişebildiği) ayırarak ileride SSO (SAML/OIDC) eklemeyi planlayın. Entegrasyonlar için dar kapsamlı ve döndürülebilir API anahtarları verin.

Minnettar olacağınız denetim günlükleri

Değişmez denetim girdileri ekleyin:

• SLA kural değişiklikleri (eşikler, takvimler, hariç tutmalar, hizmet/müşteri eşlemesi)
• Olay düzenlemeleri (zaman damgaları, durum geçişleri, manuel kesinti override'ları)
• İzin ve API anahtarı değişiklikleri

Kimin, neyi değiştirdi (önce/sonra), ne zaman, nereden (IP/user agent) ve bir korelasyon ID saklayın. Denetim günlüklerini aranabilir ve dışa aktarılabilir yapın (örn. /settings/audit-log).

Entegrasyonlar ve Otomasyon için API Tasarımı

Bir SLA izleme uygulaması nadiren yalnızdır. Monitoring araçlarının, ticketing sistemlerinin ve dahili iş akışlarının olay oluşturmasına, event itmesine ve rapor çekmesine izin veren bir API istersiniz.

Küçük, öngörülebilir bir yüzeyle başlayın

Sürümü belirtilmiş bir temel yol kullanın (örneğin, /api/v1/...) ki yükleri bozmadan payloadları geliştirebilesiniz.

Çoğu kullanım durumunu karşılayacak temel uç noktalar:

• Events: POST /api/v1/events durum değişikliklerini almak için. GET /api/v1/events denetimler ve hata ayıklama için.
• Incidents: POST /api/v1/incidents, PATCH /api/v1/incidents/{id} (onayla, çöz, ata), GET /api/v1/incidents.
• SLAs: GET /api/v1/slas, POST /api/v1/slas, PUT /api/v1/slas/{id} sözleşmeleri ve eşikleri yönetmek için.
• Raporlar: GET /api/v1/reports/sla?service_id=...&from=...&to=... uyumluluk özetleri için.
• Alerts: POST /api/v1/alerts/subscriptions webhook/e-posta hedeflerini yönetmek için; GET /api/v1/alerts uyarı geçmişi için.

Sayfalama ve filtrelemeyi tutarlı yapın

Bir konvansiyon seçin ve her yerde kullanın. Örneğin: limit, cursor sayfalama ve standart filtreler service_id, sla_id, status, from, to. Sıralamayı öngörülebilir tutun (örn. sort=-created_at).

Entegratörlerin güvenebileceği hata yanıtlarını tanımlayın

Entegratörlerin dayanabileceği yapılandırılmış hatalar döndürün:

{ "error": { "code": "VALIDATION_ERROR", "message": "service_id is required", "fields": { "service_id": "missing" } } }

Net HTTP statüleri kullanın (400 doğrulama, 401/403 auth, 404 bulunamadı, 409 çakışma, 429 rate limit). Olay alma için idempotentlik (Idempotency-Key) düşünün ki yeniden denemeler olay çoğaltmasın.

Oran limitleri ve temel güvenlik

Her token için makul oran limitleri uygulayın (ve alma uç noktaları için daha sıkı limitler), girdileri sanitize edin ve zaman damgalarını/zaman dilimlerini doğrulayın. Kısıtlı kapsamlı API tokenları tercih edin (yalnızca raporlama okuma vs. olay yazma), ve kim hangi uç noktayı çağırdı kaydını tutun (detaylar denetim günlükleri bölümünde).

Test Stratejisi: Sayıların Doğru Olduğunu Kanıtlayın

SLA sayıları, insanlar onlara güvendikçe anlamlıdır. Bir SLA izleme uygulaması için testler “sayfa yükleniyor mu”dan çok “süre hesabı sözleşmede tam olarak söylendiği gibi mi davranıyor” üzerine odaklanmalıdır. Hesaplama kurallarınızı kendi başına bir ürün özelliği gibi test paketine alın.

Sabit zaman çizelgeleri ile birim testleri yazın

Hesaplama motorunuzu deterministik girdilerle birim testleriyle başlayın: olay zaman çizelgesi (oluşturuldu, onaylandı, hafifletildi, çözüldü) ve net bir SLA kural seti.

Zamanı “dondurun” ki testler saate bağımlı olmasın. Sık hata yaratan kenar durumları kapsayın:

• Olay rapor döneminden önce başlar ve içinde biter
• Örtüşen olaylar (kesinti birleşmeli mi yoksa yığılmalı mı?)
• Birden çok duraklatma (bakım pencereleri, müşteri beklemeleri)
• Sınırdakiler (tam 00:00'da, ay sonu, artık gün)

Tüm boru hattı için uçtan uca testler

Bir dizi uçtan uca testi ekleyin: olay al → uyumluluk hesapla → rapor oluştur → UI render. Bunlar motorun ne hesapladığı ile panonun ne gösterdiği arasındaki uyumsuzlukları yakalar. Senaryolar az ama yüksek değerli olsun; nihai sayılar (erişilebilirlik %, ihlal evet/hayır, yanıt süresi) üzerine asser edin.

Takvimler ve zaman dilimleri için tekrar kullanılabilir fixture'lar oluşturun

Mesai saatleri, tatiller ve zaman dilimleri için test fixture'ları oluşturun. Tekrarlanabilir vakalar istersiniz: “olay Cuma 17:55 yerel zamanında oldu” veya “tatil yanıt süresi sayımını kaydırıyor.”

SLA uygulamasını kendiniz de izleyin

Testler deploy ile bitmez. İşlem gözlemi ekleyin: iş hata oranları, kuyruk/bekleyen büyüklük, yeniden hesaplama süreleri, hata oranları. Eğer alma gecikirse veya günlük iş başarısız olursa, kod doğru olsa bile raporunuz yanlış olabilir.

Dağıtım, Operasyonlar ve Pratik MVP Yol Haritası

Bir SLA izleme uygulamasını göndermek gösterişli altyapıdan çok öngörülebilir operasyonlarla ilgilidir: hesaplamalar zamanında çalışmalı, veriler güvenli olmalı ve raporlar yeniden üretilebilir olmalıdır.

Basit, güvenilir bir dağıtım yolu

Yönetilen servislerle başlayın ki doğruluğa odaklanabilesiniz.

• Yönetilen veritabanı (PostgreSQL): otomatik yedekler, zaman içinde geri alma, şifreleme.
• Konteyner barındırma web/API için: kolay rollback ve tutarlı ortamlar.
• Obje depolama dışa aktarımlar (CSV/PDF) ve büyük artefaktlar için, yaşam döngüsü kurallarıyla.

Ortamları minimal tutun: dev → staging → prod, her biri kendi veritabanı ve sırlarıyla.

İlk günden ihtiyaç duyacağınız arka plan işler

SLA izleme yalnızca request/response değildir; zamanlanmış işlere bağlıdır.

• Hesaplama işleri: yeni eventlerden itibaren SLA pencerelerini yeniden hesaplayın ve geç gelen veriler geldiğinde tekrar çalıştırın.
• Rapor üretimi: günlük/aylık özetler, müşteri hazır dışa aktarmalar.
• Veri bakımı: eski ham eventleri arşivleme, türetilmiş tabloları sıkıştırma, referans bütünlüğünü doğrulama.

İşleri worker süreç + kuyruk ile veya yönetilen bir zamanlayıcı ile çalıştırın. İşleri idempotent yapın ve her çalışmayı denetlenebilir şekilde loglayın.

Tutundurma ve dışa aktarımlar (abartmadan)

Veri türüne göre saklama politikası tanımlayın: türetilmiş uyumluluk sonuçlarını ham event akışlarından daha uzun tutun. Dışa aktarım için önce CSV sunun (hızlı, şeffaf), sonra PDF şablonlarını ekleyin. Açık olun: dışa aktarımlar “elinden geldiğince formatlama”dır; veritabanı gerçeğin kaynağı olmaya devam eder.

Kapsamı kontrol altında tutan aşamalı yol haritası

1. MVP: bir servis, bir SLA, bir zaman dilimi, temel pano + aylık rapor.
2. Daha fazla metrik: yanıt süresi SLA'ları, bakım pencereleri, hariç tutmalar, birden çok takvim.
3. Müşteri portalı: müşteri özel görünümleri, erişim kontrolü, indirilebilen raporlar.
4. Durum sayfası: hesaplanmış erişilebilirlikle desteklenen herkese açık/özel sayfalar (bakınız /blog/status-pages).

Hızlı prototipleme için Koder.ai ile (isteğe bağlı)

Veri modelinizi, alma akışınızı ve raporlama UI'sını hızlı doğrulamak istiyorsanız, Koder.ai gibi vibe-coding bir platform prototip üretmenize yardımcı olabilir. Çünkü Koder.ai sohbet üzerinden tam uygulamalar (web UI + backend) üretebildiğinden, çalışır bir uçtan uca prototip oluşturmak için pratiktir:

• uyumluluk, hata bütçesi ve zaman çizelgesi ayrıntıları için bir React pano,
• ham eventleri ve dönem sonuçlarını saklamak için Go + PostgreSQL backend,
• dışa aktarım/rapor uç noktaları ve basit müşteri portalı görünümleri.

Gerekli olan ve en zor olan kısım (gereksinimler ve hesaplamalar) kanıtlandığında, kaynak kodunu dışa aktarabilir ve daha geleneksel bir build-and-operate iş akışına geçebilirsiniz—hızlı yineleme sırasında anlık görüntüler ve geri alma gibi özellikler elinizde kalır.

availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes