SLI/SLO'lar, olay iş akışı, panolar, uyarılar ve raporlama ile iç araçların güvenilirliğini izleyen bir web uygulamasının nasıl tasarlanıp oluşturulacağını öğrenin.
Metrikleri veya panoları seçmeden önce uygulamanın ne için sorumlu olduğunu—ve ne olmadığını—belirleyin. Net bir kapsam, aracın kimsenin güvenmediği bir “ops portalı” haline gelmesini önler.
Uygulamanın kapsayacağı iç araçları (örn. ticketing, bordro, CRM entegrasyonları, veri boru hatları) ve bu araçların sahipleri ya da onlara bağımlı olan ekipleri listeleyerek başlayın. Sınırları açıkça belirtin: “müşteri odaklı web sitesi” kapsam dışı olabilir, ama “iç yönetici konsolu” kapsam dahilinde olabilir.
Organizasyonlar bu kelimeyi farklı kullanır. Çalışan bir tanımı sade bir dille yazın—genelde şunların bir karışımı olur:
Ekipler anlaşmazsa uygulamanız elma ile armut karşılaştırır.
1–3 ana sonuç seçin, örneğin:
Bu sonuçlar daha sonra ne ölçeceğinizi ve nasıl sunacağınızı yönlendirecek.
Uygulamayı kimlerin kullanacağını ve hangi kararları verdiklerini listeleyin: olay araştıran mühendisler, destek ekibi yükseltenler, eğilimleri inceleyen yöneticiler ve durum güncellemesi isteyen paydaşlar. Bu, terminoloji, izinler ve her görünümün göstermesi gereken ayrıntı düzeyini şekillendirir.
Güvenilirlik izleme, herkesin “iyi”nin ne olduğunu kabul etmesiyle işler. Önce üç benzer terimi ayırın.
Bir SLI (Service Level Indicator) ölçümdür: “İsteklerin yüzde kaçı başarılı oldu?” veya “Sayfaların yüklenme süresi neydi?”
Bir SLO (Service Level Objective) bu ölçüm için hedeftir: “30 gün içinde %99.9 başarı.”
Bir SLA (Service Level Agreement) sonuçları olan bir taahhüttür; genelde dışa dönüktür (kredi, ceza). İç araçlar için çoğunlukla SLO'lar belirlenir; bu, beklentileri hizalar ama güvenilirliği sözleşme hukukuna dönüştürmez.
Araçlar arasında karşılaştırılabilir ve açıklaması kolay tutun. Pratik bir temel şunlardır:
Eklemeye başlamadan önce “Bu metrik hangi kararı yönlendirecek?” sorusunu cevaplayabiliyor olun.
Skor kartlarının sürekli güncellenmesi için kayan pencereler kullanın:
Uygulamanız metrikleri eyleme dönüştürmeli. Seviyeleri (örn. Sev1–Sev3) ve açık tetikleyicileri tanımlayın:
Bu tanımlar uyarı, olay zaman çizelgeleri ve hata bütçesi takibini ekipler arasında tutarlı kılar.
Güvenilirlik takip uygulaması, arkasındaki verilere ne kadar güvenilirse o kadar güvenilir olur. Alım boru hatlarını kurmadan önce hangi sinyali "gerçek" sayacağınızı haritalayın ve her sinyalin hangi soruyu yanıtladığını yazın (erişilebilirlik, gecikme, hatalar, deploy etkisi, olay yanıtı).
Çoğu ekip temeli şu karışımla karşılayabilir:
Hangi sistemlerin yetkili olduğunu açıkça belirtin. Örneğin “uptime SLI” yalnızca sentetik probe'lardan alınabilir, sunucu loglarından değil.
Kullanım durumuna göre güncelleme sıklığını ayarlayın: panolar her 1–5 dakikada yenilenebilir; skor kartları saatlik/günlük hesaplanabilir.
Araç/hizmet, ortam (prod/ stage) ve sahipler için tutarlı ID'ler oluşturun. “Payments-API”, “payments_api” ve “payments” gibi varyantların üç ayrı varlık olmaması için adlandırma kurallarında erken anlaşın.
Ne kadar süreyle ne saklanacağını planlayın (örn. ham olaylar 30–90 gün, günlük toplamlar 12–24 ay). Hassas yükleri almaktan kaçının; güvenilirlik analizinde gereken meta verileri saklayın (zaman damgaları, durum kodları, gecikme bucket'ları, olay etiketleri).
Şemanız iki şeyi kolaylaştırmalı: günlük sorulara cevap vermeyi (“bu araç sağlıklı mı?”) ve bir olay sırasında ne olduğunu yeniden inşa etmeyi (“belirtiler ne zaman başladı, kim ne değiştirdi, hangi uyarılar tetiklendi?”). Küçük bir çekirdek varlık setiyle başlayın ve ilişkileri açık tutun.
Pratik bir başlangıç:
Bu yapı panoları (“tool → güncel durum → son olaylar”) ve derinlemesine incelemeyi (“olay → etkinlikler → ilgili kontroller ve metrikler”) destekler.
Sorumluluk ve geçmiş için her yerde denetim alanları ekleyin:
created_by, created_at, updated_atstatus artı durum değişikliği takibi (ya Event tablosunda ya da özel bir tarihçe tablosunda)Ayrıca filtreleme ve raporlama için esnek etiketler ekleyin (örn. takım, kritiklik, sistem, uyumluluk). Bir tool_tags join tablosu (tool_id, key, value) etiketlemeyi tutarlı kılar ve sonraki skor kartları ile roll-upları kolaylaştırır.
Güvenilirlik takipçiniz en iyi anlamda sıkıcı olmalı: çalıştırması kolay, değiştirmesi kolay ve desteklemesi kolay. “Doğru” yığın genelde ekibinizin kahramanlık yapmadan sürdürebileceği yığındır.
Ekiplerin iyi bildiği ana akım web framework'lerinden birini seçin—Node/Express, Django veya Rails sağlam seçeneklerdir. Öncelik verin:
İç sistemlerle (SSO, ticketing, chat) entegrasyon yapıyorsanız, bu entegrasyonların en kolay olduğu ekosistemi seçin.
Hızlı ilk yineleme istiyorsanız Koder.ai gibi bir vibe-coding platformu pratik bir başlangıç olabilir: varlıklarınızı (tools, checks, SLOs, incidents), iş akışlarınızı (alert → incident → postmortem) sohbetle tarif edip çalışan bir web uygulaması iskeleti hızlıca oluşturabilirsiniz. Koder.ai genelde frontend için React, backend için Go + PostgreSQL hedeflediği için birçok ekibin tercih ettiği “sıkıcı, bakımı kolay” varsayılan yığına uyar—ve daha sonra tamamen manuel bir boru hattına geçmek isterseniz kaynak kodunu dışa aktarabilirsiniz.
Çoğu iç güvenilirlik uygulaması için PostgreSQL doğru varsayılandır: ilişkisel raporlama, zaman bazlı sorgular ve denetim için iyidir.
Gerçek bir sorunu çözdüğünde ek bileşenler ekleyin:
Karar verin:
Hangi yolu seçerseniz seçin, dev/staging/prod standartlaştırın ve dağıtımları otomatikleştirin (CI/CD), böylece değişiklikler güvenilirlik sayılarını sessizce değiştirmez. Platform yaklaşımı (Koder.ai dahil) kullanıyorsanız ortamlara ayırma, dağıtım/barındırma ve hızlı rollback (snapshot) gibi özellikler arayın ki yinelemeler tracker'ı bozmasın.
Çalıştırma ile ilgili yapılandırmayı tek yerde belgeleyin: environment değişkenleri, sırlar ve feature flag'ler. “Yerel nasıl çalıştırılır” rehberi ve kısa bir runbook (alım durursa, kuyruk birikirse veya veritabanı sınırlarına ulaşırsa ne yapılır) bulundurun. /docs içinde kısa bir sayfa genelde yeterlidir.
Bir güvenilirlik takip uygulaması başarılı olduğunda insanlar iki soruyu saniyeler içinde yanıtlayabilir: “Durumumuz iyi mi?” ve “Sonraki adım nedir?” Görünümleri bu kararlar etrafında düzenleyin: genel görünüm → belirli araç → belirli olay.
Anasayfayı kompakt bir komuta merkezi haline getirin. Genel sağlık özetiyle başlayın (örn. SLO'ları karşılayan araç sayısı, aktif olaylar, en büyük riskler), sonra durum rozetleriyle son olayları ve uyarıları gösterin.
Varsayılan görünümü sakin tutun: sadece dikkat gerektirenleri vurgulayın. Her kartın ilgili araç veya olaya doğrudan derinleşme bağlantısı olsun.
Her araç sayfası “Bu araç yeterince güvenilir mi?” ve “Neden/Neden değil?” sorularına cevap vermeli. İçerik:
Grafikleri uzman olmayanlar için tasarlayın: birimleri etiketleyin, SLO eşiklerini işaretleyin ve yoğun teknik kontroller yerine küçük açıklamalar (tooltip) ekleyin.
Olay sayfası yaşayan bir kayıt olmalı. Zaman çizelgesi (otomatik yakalanan etkinlikler: uyarı tetiklendi, onaylandı, hafifletildi), insan güncellemeleri, etkilenen kullanıcılar ve alınan aksiyonlar olsun.
Güncelleme yayınlamayı kolaylaştırın: tek bir metin kutusu, ön tanımlı durumlar (Investigating/Identified/Monitoring/Resolved) ve isteğe bağlı dahili notlar. Olay kapatıldığında “Postmortem başlat” eyleği zaman çizelgesinden gerçekleri ön doldurmalı.
Yöneticiler araçları, kontrolleri, SLO hedeflerini ve sahipleri yönetmek için basit ekranlara ihtiyaç duyar. Doğruluk için optimize edin: mantıklı varsayılanlar, doğrulama ve raporlamayı etkileyen değişikliklerde uyarılar. İnsanların sayılara güvenmesi için görünür bir “son düzenleyen” izi ekleyin.
Güvenilirlik verileri ancak insanlar onlara güvendiğinde kullanılmaya devam eder. Bu, her değişikliği bir kimlikle bağlamayı, kimlerin yüksek etkili düzenlemeler yapabileceğini sınırlamayı ve incelemelerde başvurulacak net bir geçmiş tutmayı gerektirir.
İç araç için varsayılan olarak SSO (SAML) ya da IdP üzerinden OAuth/OIDC (Okta, Azure AD, Google Workspace) kullanın. Bu, parola yönetimini azaltır ve işe alım/çıkarma süreçlerini otomatikleştirir.
Pratik detaylar:
Basit rollere başlayın, gerektiğinde daha ince izinler ekleyin:
Raporlama veya güvenilirlik sonuçlarını değiştirebilecek eylemleri koruyun:
SLO'lar, kontroller ve olay alanlarındaki her düzenlemeyi kaydedin:
Denetim günlüklerini ilgili detay sayfalarından aranabilir ve görünür yapın (örn. bir olay sayfası kendi tam değişiklik geçmişini gösterir). Bu, incelemeleri nesnel yapar ve postmortem sırasında tartışmaları azaltır.
İzleme, güvenilirlik uygulamanızın “sensör katmanıdır”: gerçek davranışı güvenebileceğiniz verilere dönüştürür. İç araçlarda sentetik kontroller genellikle en hızlı yol çünkü “sağlıklı” olmanın ne anlama geldiğini siz tanımlarsınız.
Çoğu iç uygulamayı kapsayan küçük bir kontrol setiyle başlayın:
Kontroller deterministik olsun. Doğrulama içeriği değişebileceği için hata yaratıyorsa gürültü oluşturur ve güven sarsılır.
Her kontrol çalıştırması için yakalayın:
Veriyi ya zaman-serisi olayları (her kontrol çalıştırması için bir satır) ya da agregat aralıklar (ör. dakikalık rollup'lar ile sayılar ve p95 gecikme) olarak saklayın. Ham olay verisi hata ayıklama için harika; rollup'lar ise hızlı panolar için uygundur. Birçok ekip her ikisini de yapar: ham olayları 7–30 gün saklayıp uzun vadeli raporlama için rollup'ları tutar.
Eksik kontrol sonucu otomatik olarak “down” anlamına gelmemeli. Aşağıdaki durumlar için açık bir unknown durumu ekleyin:
Bu, şişirilmiş çalışma süresi rakamlarını engeller ve “izleme boşluklarını” kendi operasyonel sorunu olarak görünür kılar.
Kontrolleri sabit aralıklarla çalıştırmak için arka plan worker'ları (cron benzeri zamanlama, kuyruklar) kullanın (ör. kritik araçlar için 30–60 saniye). Zaman aşımı, geri deneme (backoff) ve eşzamanlılık sınırları ekleyin ki checker iç servisleri aşırı yüklemesin. Her çalıştırma sonucunu—başarısızlıklar dahil—kalıcı hale getirin ki uptime panonuz hem güncel durumu hem de güvenilir geçmişi gösterebilsin.
Uyarılar güvenilirlik izlemeyi eyleme dönüştüren noktadır. Amaç basittir: doğru kişiyi, doğru bağlamla, doğru zamanda bilgilendirmek—herkesi boğmadan.
Uyarı kurallarını doğrudan SLI/SLO'larınıza eşleyin. İki pratik desen:
Her kural için “neden”i de saklayın: hangi SLO etkileniyor, değerlendirme penceresi ve hedeflenen şiddet.
Ekiplerin zaten yaşadığı kanallardan bildirim gönderin (email, Slack, Microsoft Teams). Her mesaj şunları içermeli:
Ham metrik dökümü göndermekten kaçının. Kısa bir “sonraki adım” ekleyin: “Son deployları kontrol et” veya “Logları açın.”
İç araç bile olsa insanlar kontrol sahibi olmak ister. Uyarı/olay sayfasında manuel eskalasyon düğmesi ekleyin ve varsa on-call araçlarıyla (PagerDuty/Opsgenie eşdeğerleri) entegrasyon yapın; yoksa en azından uygulamada yapılandırılabilen bir dönüşümlü liste saklayın.
Olay yönetimi “bir uyarı gördük”ten paylaşılan, izlenebilir bir yanıta dönüşmeyi sağlar. Bu akışı uygulamanın içine yerleştirerek insanlar sinyalden koordinasyona geçerken araçlar arasında zıplamasın.
Bir uyarıdan, servis sayfasından veya uptime grafiğinden doğrudan olay oluşturmayı mümkün kılın. Önemli alanları (servis, ortam, uyarı kaynağı, ilk görüldüğü zaman) ön doldurun ve benzersiz olay ID'si atayın.
İyi bir varsayılan alan seti hafif olmalı: şiddet, etki (hangi iç takımlar etkilendi), mevcut sahip ve tetikleyici uyarıya bağlantılar.
Ekiplerin gerçekte nasıl çalıştığına uyan basit bir yaşam döngüsü kullanın:
Her durum değişikliği kim tarafından ve ne zaman yapıldığını kaydetmeli. Zaman çizelgesi güncellemeleri (kısa, zaman damgalı notlar), ekler ve runbook/bilet bağlantılarını destekleyin (örn. /runbooks/payments-retries veya /tickets/INC-1234). Bu thread “ne oldu ve ne yapıldı” için tek kaynak haline gelir.
Postmortem başlatmak hızlı ve tutarlı olmalı. Şablonlar sağlayın:
Aksiyon maddelerini olaya bağlayın, tamamlanmayı takip edin ve geciken öğeleri ekip panolarında gösterin. "Öğrenme incelemeleri" destekliyorsanız, bireysel hataları suçlamayan (blameless) bir modu da mümkün kılın.
Raporlama güvenilirlik takibinin karar vermeye dönüşmesidir. Panolar operatörlere yardımcı olur; skor kartları liderlerin iç araçların iyileşip iyileşmediğini, hangi alanların yatırım gerektirdiğini ve “iyi”nin ne olduğunu anlamasını sağlar.
Her araç (ve isteğe bağlı olarak her takım) için tekrar edilebilir bir görünüm oluşturun:
Mümkünse hafif bağlam ekleyin: “SLO iki deploy nedeniyle kaçırıldı” veya “Çoğu kesinti bağımlılık X kaynaklı” gibi; ama raporu tam olay incelemesine çevürmeyin.
Liderler genelde "her şeyi" istemez. Takım, araç kritikliği (Tier 0–3) ve zaman penceresi için filtreler ekleyin. Aynı araç birden fazla rolü varsa (platform takımı sahibi, finans bağımlı) aynı araç farklı rolluplarda görünebilmeli.
Uygulama dışına paylaşılabilecek haftalık/aylık özetler sunun:
Anlatıyı tutarlı tutun (“Önceki döneme göre ne değişti?” “Nerede bütçe aşılıyor?”). Paydaşlar için kısa bir primer gerekiyorsa, kısa bir rehbere bağlanın: blog/sli-slo-basics.
Güvenilirlik takipçisi hızla bir tek kaynak haline gelir. Üretim sistemi gibi ele alın: varsayılan olarak güvenli, kötü veriye karşı dayanıklı ve bir şey ters gittiğinde kurtarması kolay olsun.
Her uç noktayı kilitleyin—"sadece iç" görünümlü olanları bile.
Kimlik bilgilerini koddan ve log'lardan uzak tutun.
Sırları bir secret manager'da saklayın ve döndürün. Web uygulamasına en az ayrıcalık derecesinde veritabanı erişimi verin: okuma/yazma rolleri ayırın, sadece gerektiği tabloları erişime açın ve mümkünse kısa ömürlü kimlik bilgileri kullanın. Tarayıcı↔uygulama ve uygulama↔veritabanı arasındaki trafiği TLS ile şifreleyin.
Güvenilirlik metrikleri ancak temel olaylar güvenliyse işe yarar.
Zaman damgaları için sunucu tarafı kontrolleri (zaman dilimi/saat kayması), zorunlu alanlar ve yeniden denemeleri dedupe etmek için idempotency anahtarları ekleyin. Kötü olayları panolara bulaştırmamak için ingestion hatalarını dead-letter kuyruğunda veya “karantina” tablosunda izleyin.
Veritabanı migrasyonlarını ve rollback testlerini otomatikleştirin. Yedekleri planlayın, düzenli olarak geri yükleme testleri yapın ve minimal bir felaket kurtarma planı belgeleyin (kim, ne, ne kadar süre). Son olarak, takip uygulamasının kendisini güvenilir yapın: sağlık kontrolleri, kuyruk lagı ve DB gecikmesi için temel izleme ve alımın sessizce sıfıra düşmesi durumunda uyarı kurun.
Bir güvenilirlik takip uygulaması insanların ona güvenmesi ve gerçekten kullanmasıyla başarılı olur. İlk sürümü bir öğrenme döngüsü olarak kabul edin, “büyük patlama” lansmanı olarak değil.
Geniş kullanılan ve net sahipleri olan 2–3 iç araç seçin. Küçük bir kontrol seti uygulayın (örn: ana sayfa erişilebilirliği, giriş başarılı, kritik API uç noktası) ve şu soruyu yanıtlayan tek bir pano yayınlayın: “Çalışıyor mu? Değilse ne değişti ve kim sorumlu?”
Pilotu görünür ama sınırlı tutun: doğrulamayı yapmak için bir ekip veya küçük bir güç kullanıcı grubu yeterlidir.
İlk 1–2 haftada aktif olarak şu konularda geri bildirim toplayın:
Geri bildirimi somut backlog öğelerine dönüştürün. Her grafikte küçük bir “Bu metrikle ilgili sorun bildir” düğmesi hızlı içgörüler sağlayabilir.
Değeri katmanlı şekilde ekleyin: bildirimler için chat aracına bağlanın, sonra olay aracıyla otomatik bilet oluşturmayı ekleyin, ardından deploy işaretleri için CI/CD entegrasyonu yapın. Her entegrasyon manuel işi azaltmalı veya tanılama süresini kısaltmalı—aksi halde sadece karmaşıklık ekler.
Hızlı prototipleme yapıyorsanız, başlangıç kapsamını (varlıklar, roller, iş akışları) haritalandırmak için Koder.ai'nin planning modunu değerlendirin. Bu, MVP'yi sıkı tutmanın basit bir yoludur—ve snapshot/rollback özellikleriyle panoları ve alımları ekip tanımları netleştikçe güvenle yineleyebilirsiniz.
Daha fazla takıma açmadan önce gösterge panosu haftalık aktif kullanıcılar, tespit süresinin azalması, tekrarlı uyarıların azalması veya düzenli SLO incelemeleri gibi başarı metrikleri belirleyin. /blog/reliability-tracking-roadmap içinde hafif bir yol haritası yayınlayın ve araç bazında net sahipler ve eğitim oturumlarıyla genişletin.
Önce kapsamı tanımlayarak başlayın (hangi araçlar ve ortamlar dahil) ve güvenilirliği nasıl tanımladığınızı netleştirin (erişilebilirlik, gecikme, hatalar). Ardından iyileştirmek istediğiniz 1–3 sonucu seçin (ör. daha hızlı tespit, daha net raporlama) ve ilk ekranları kullanıcıların yapması gereken temel kararlar etrafında tasarlayın: “Durumumuz iyi mi?” ve “Sonraki adım nedir?”
SLI, ölçtüğünüz şeydir (ör. % başarılı istekler, p95 gecikme). SLO bu ölçüm için hedeftir (ör. 30 gün içinde %99.9). SLA ise sonuçları olan resmi bir taahhüttür (çoğunlukla dışa dönük). İç araçlar için genellikle SLO’lar taahhüt olmadan beklentileri hizalar—SLA benzeri yaptırımlar getirmeden.
Araçlar arasında karşılaştırılabilir kalacak küçük bir temel set kullanın:
Yeni metrik eklemeden önce “Bu metrik hangi kararı yönlendirecek?” sorusunu cevaplayabiliyor olun.
Sürekli güncel skor kartlar için kayan pencereler kullanın:
Kuruluşunuzun performansı nasıl incelediğine uygun pencere aralıkları seçin ki sayılar sezgisel olsun ve kullanılsın.
Kullanıcı etkisine ve süresine bağlı açık tetikleyicilerle şiddet seviyeleri tanımlayın, örneğin:
Bu kurallar uygulandığında uyarı, olay zaman çizelgeleri ve raporlama ekipler arasında tutarlı olur.
Her sorunun “gerçek kaynak” sistemini haritalandırarak başlayın:
Örn: “uptime SLI sadece probe'lardan gelir” gibi açık olmazsa ekipler hangi sayıların geçerli olduğu konusunda tartışır.
Pull: düzenli olarak anket yapılabilen sistemler için (Prometheus, bulut izleme, ticketing API'leri). Push: deploy'lar, uyarılar, olay güncellemeleri gibi yüksek hacimli veya gerçek zamanlı olaylar için (webhook/event). Dashboard'lar genelde her 1–5 dakikada yenilenirken skor kartlar saatlik/günlük hesaplanır.
Genelde şu tablolar gerekir:
Her yüksek etkiye sahip düzenlemeyi kim, ne zaman, ne değişti (önce/sonra) ve nereden (UI/API/otomasyon) ile kaydedin. Basit rol tabanlı erişimle birleştirin:
Bu korumalar güvenilirlik sayılarının gizlice değişmesini engeller.
Eksik kontrol sonucu otomatik olarak “kapalı” anlamına gelmemelidir. Aşağıdaki durumlar için ayrı bir unknown (bilinmiyor) durumu ekleyin:
“Unknown” görünür olduğunda çalışma süresi şişmesi önlenir ve izleme boşlukları kendi operasyonel sorunları olarak ortaya çıkar.
İlişkileri açık tutun (tool → checks → metrics; incident → events) ki “genel bakış → detaya inme” sorguları basit kalsın.