SLA uyumluluğunu takip eden bir web uygulamasını nasıl tasarlayıp inşa edeceğinizi öğrenin: metrikleri tanımlayın, olayları toplayın, sonuçları hesaplayın, ihlaller için uyarın ve doğrulanabilir raporlar oluşturun.
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:
Çoğu SLA izleme web uygulaması, gerçek operasyonel verilere eşlenen küçük bir metrik setiyle başlar:
Farklı kullanıcılar aynı gerçeği farklı biçimde görmek ister:
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.
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.
Gerçeğin kaynaklarını toplamakla başlayın:
Bu kuralları açık ifadeler olarak yazın. Bir kural net ifade edilemiyorsa, güvenilir şekilde hesaplanamaz.
SLA sayısını etkileyebilecek gerçek dünya “şeylerini” listeleyin:
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.
Kapsamı küçük tutun. Sistemin uçtan uca çalıştığını doğrulayacak minimum seti seçin, örneğin:
Daha sonra test edebileceğiniz tek sayfalık bir kontrol listesi oluşturun:
Başarı böyle görünür: iki kişi aynı örnek ayı manuel hesapladığında uygulamanız tam olarak aynı sonucu verir.
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.
En azından modelleyin:
Kullanışlı bir ilişki: customer → service → SLA policy (muhtemelen plan üzerinden). Olaylar ve eventler daha sonra servise ve müşteriye referans verir.
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.
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ş saatleriholiday_calendar bir bölgeye veya müşteriye bağlı, tarih aralıkları ve etiketlerle birlikteKuralları veri odaklı tutun ki operasyon bir tatili deploy olmadan güncelleyebilsin.
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.
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.
Çoğu ekip, bir karışım sistemden çeker:
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.
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.
Aşağıdakileri reddedin veya karantinaya alın:
occurred_at'ı çok gelecekte olan eventler.service_id ile eşleşmeyenler (veya açık bir “eşleşmeyen” iş akışı gerektirin).event_id ile çoğaltanlar.Bu disiplin, raporlar hakkında tartışmaya girmenizi önler—çünkü temiz, izlenebilir girdilere işaret edebileceksiniz.
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.
Her şeyi tek bir sıralı akıma dönüştürün (her olay veya servis-etkisi için):
Bu zaman çizelgesinden, süreleri aralıkları toplayarak hesaplayın, iki zaman damgasını körü körüne çıkarmayın.
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:
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.
Önceden karar verin:
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.
Her hesaplama yeniden üretilebilir olmalıdır. Şunları kalıcı hale getirin:
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, 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.
Müşterilerinizin gerçekten kullandığı yaygın raporlama dönemlerini destekleyin:
Dönemleri açık başlangıç/bitiş zaman damgaları olarak saklayın ("month = 3" demeyin) ki hesaplamaları daha sonra yeniden oynatıp açıklayabilesiniz.
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:
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.
Çoğu SLA hem yüzde hem de ikili bir sonuç ister.
Ayrıca “ihale kalan uzaklık”ı (kalan kesinti bütçesi) tutun ki panolar sınır aşılmadan önce uyarı verebilsin.
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.
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.
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.
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.
Her özet metriğin bir “Neden?” yolu olmalı:
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.
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.
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.
Üç tetik türüyle başlayın:
Tetikleri müşteri/servis/SLA başına yapılandırılabilir yapın; farklı sözleşmeler farklı eşikleri tolere eder.
Uyarıları insanların gerçekten yanıt verdiği yerlere gönderin:
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.
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.
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.
Rolleri basit tutun, sonra daha ince izinlere büyütün.
Pratik bir varsayılan: RBAC + tenant scoping:
Müşteri-özel veriler hakkında açık olun:
İ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.
Değişmez denetim girdileri ekleyin:
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).
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.
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:
POST /api/v1/events durum değişikliklerini almak için. GET /api/v1/events denetimler ve hata ayıklama için.POST /api/v1/incidents, PATCH /api/v1/incidents/{id} (onayla, çöz, ata), GET /api/v1/incidents.GET /api/v1/slas, POST /api/v1/slas, PUT /api/v1/slas/{id} sözleşmeleri ve eşikleri yönetmek için.GET /api/v1/reports/sla?service_id=...&from=...&to=... uyumluluk özetleri için.POST /api/v1/alerts/subscriptions webhook/e-posta hedeflerini yönetmek için; GET /api/v1/alerts uyarı geçmişi için.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 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.
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).
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.
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:
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.
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.”
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.
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.
Yönetilen servislerle başlayın ki doğruluğa odaklanabilesiniz.
Ortamları minimal tutun: dev → staging → prod, her biri kendi veritabanı ve sırlarıyla.
SLA izleme yalnızca request/response değildir; zamanlanmış işlere bağlıdır.
İş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.
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.
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:
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.
Bir SLA izleyici, tek bir soruyu kanıtla birlikte yanıtlar: belirli bir müşteri ve zaman dilimi için sözleşmeye bağlanmış taahhütleri yerine getirdiniz mi?
Pratikte bu, ham sinyallerin (monitoring, ticketlar, manuel güncellemeler) alınması, müşterinin kurallarının (mesai saatleri, hariç tutmalar) uygulanması ve denetlenebilir bir geç/kalma sonucu ile destekleyici ayrıntıların üretilmesi anlamına gelir.
Şu şekilde kullanın:
Bunları ayrı modelleyin ki güvenilirliği artırmaya yönelik SLO değişiklikleri yanlışlıkla sözleşme raporlamasını (SLA) değiştirmesin.
Güçlü bir MVP genellikle uçtan uca 1–3 metrik izler:
Bunlar gerçek veri kaynaklarına doğrudan bağlanır ve dönemler, takvimler, hariç tutmalar gibi zor parçaları erken zorunlu kılar.
Veritabanını tasarlamadan veya hesaplayıcıyı yazmadan önce toplayın ve yazın:
Bir kural net ifade edilemiyorsa, kodla “tahmin” etmeyin—bunu işaretleyin ve netleştirin.
Sade, açık varlıklarla başlayın:
Amaç izlenebilirlik olmalı: bildirilen her sayı belirli ve belirli bir bağlanabilmelidir.
Zamanı doğru ve tutarlı saklayın:
occurred_at'ı UTC olarak saklayın (zaman dilimi semantiğiyle)received_at'ı da saklayın (kaydın alındığı zaman)Ayrıca dönemleri açıkça (başlangıç/bitiş zaman damgaları) saklayın ki raporlar daha sonra yeniden üretilebilsin—DST değişiklikleri dahil.
Her şeyi tek bir dahili event şekline normalleştirin ve kararlı bir benzersiz ID kullanın:
event_id (benzersiz, tekrar denemelerde kararlı)Süreleri bir zaman çizelgesindeki aralıkları toplayarak hesaplayın; iki zaman damgasını körü körüne çıkarmayın.
“Chargeable” (hesaplanacak) zamanı açıkça tanımlayın ve sayılmayacak aralıkları çıkarın:
Türeyen aralıkları ve neden kodlarını saklayın ki tam olarak ne sayıldığını açıklayabilesiniz.
İki paydayı açıkça takip edin:
Sonra hesaplayın:
availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes
Ayrıca eligible_minutes sıfırsa ne olacağını önceden tanımlayın (ör. göster veya %100 kabul et) ve bunu tutarlı uygulayın.
Kullanıcı arayüzü “SLA’yı şu an karşılıyor muyuz ve neden?” sorusunu tek bakışta yanıtlamalı:
Uyarılar için, yaklaşan ihlal, ihlal gerçekleşti ve tekrar eden ihlaller gibi eyleme dönük tetiklere öncelik verin—her biri ilgili sayfalara (ör. /customers/{id}, ) bağlantı içermeli.
source, event_type, occurred_at, service_idincident_id ve attributesevent_id üzerinde benzersiz kısıtlama ile idempotentlik sağlayın. Eşleşmeyen veya sıra dışı gelenleri karantinaya alın; veriyi sessizce düzeltmeyin.
/services/{id}