İç araçlar için SLO'lar basitleştirildi: ölçülebilir çalışma süresi ve gecikme hedefleri koyun, sonra küçük bir ekibin tükenmeden idare edebileceği uyarılara eşleyin.
İç araçlar küçük hissedilir çünkü kitlesi küçüktür. Etki çoğu zaman küçük değildir: ops panonuz kapalıysa siparişler durur; destek konsolu yavaşsa müşteriler bekler; yönetici paneli bozulursa düzeltmeler birikir.
Net güvenilirlik hedefleri yoksa her kesinti bir tartışmaya dönüşür. Biri 10 dakikalık aksaklığa aldırmaz, diğeri bunu kriz gibi ele alır. Gürültülü sohbetlere, belirsiz önceliklere ve en kötü anda ortaya çıkan beklenmedik işlere zaman kaybedersiniz.
SLO'lar bunu ölçeklenebilir beklentiler koyarak çözer. Ölçülebilir iki pratik soruyu cevaplarlar: ne çalışmalı ve insanların işlerini yapmak için ne kadar iyi çalışmalı.
“Oldukça stabil tutarız”ın saklı maliyeti hızlıca ortaya çıkar. Araç toparlanana kadar işler durur. Destek çağrıları artar çünkü kimse normalin ne olduğunu bilmez. Mühendisler planlı iyileştirmeler yerine acil düzeltmelere çekilir. Ürün sahipleri sisteme güvenmeyi bırakır ve manuel yedekler istemeye başlar. Açık bir sınırı aşmadığı için küçük sorunlar uzun süre kalır.
Tam bir güvenilirlik programına ihtiyacınız yok. Küçük bir ekip, "giriş çalışıyor" veya "arama sonuçları hızla yükleniyor" gibi birkaç kullanıcı odaklı hedefle başlayabilir ve gerçek işe etki ettiğinde tetiklenen bir küçük uyarı seti kurabilir.
Bu, aracın nasıl inşa edildiğine bakılmaksızın geçerlidir. AppMaster (appmaster.io) kullanıyorsanız, insanların güvendiği eylemleri seçin, çalışma süresini ve yanıt süresini ölçün ve işe etki ettiğinde yalnızca uyarı verin.
Bu üç terim benziyormuş gibi görünür ama farklı güvenilirlik dili türleridir. Karıştırmak sık yapılan bir hatadır.
SLI (Service Level Indicator) bir ölçümdür. Sayılabilecek bir şeydir; örneğin “başarılı isteklerin yüzdesi” veya “sayfanın ne kadar sürede yüklendiği.” Eğer güvenilir şekilde ölçemiyorsanız, iyi bir SLI değildir.
SLO (Service Level Objective) o ölçüm için hedeftir. Kullanıcılara çoğu zaman hangi seviyenin yeterli olduğunu söyler. SLO'lar neyin önce düzeltileceğine ve neyin bekleyebileceğine karar vermenize yardım eder.
SLA (Service Level Agreement) genellikle yazılı bir taahhüttür ve çoğunlukla sonuçları olabilir. Birçok iç araçın SLA'ya ihtiyacı yoktur; onlar yasal tarzda taahhütler yerine net hedeflere ihtiyaç duyar.
Kısa bir örnek:
Eksik olanı fark edin: “hiçbir zaman kesinti yok” veya “her zaman hızlı” gibi beklentiler. SLO'lar mükemmellik hakkında değildir. Küçük bir ekibin özellikler, güvenilirlik çalışmaları ve gereksiz emeği önleme arasındaki takasları görmesini sağlar.
Pratik bir kural: hedefe ulaşmak kahramanlık gerektirecekse, bu bir SLO değil, dilekten ibarettir. Ekibinizin sakince sürdürebileceği bir şeyle başlayın; eğer kullanıcılar hâlâ acı hissediyorsa sonra sıkılaştırın.
İç araçlar belirli şekillerde başarısız olur: yönetici paneli yüklenir ama bir kaydı kaydetme sonsuza kadar bekler; ops panosu açılır ama grafikler yenilenmez; personel portalı çalışır ama güncellemeden sonra giriş bozulur. En büyük değeri, insanların her gün güvendiği eylemlere odaklanarak elde edersiniz, her sayfa ve düğmeye değil.
Önce araç tipinin adını yazın; çünkü bu kritik yollar hakkında ipucu verir. Yönetici panelleri “güvenli bir şekilde bir şeyi değiştirme” ile ilgilidir. Ops panoları “şu anda ne oluyor görmek” ile ilgilidir. Portallar “giriş yap, bilgi bul, talep gönder” ile ilgilidir.
Sonra en önemli kullanıcı yolculuklarını sade dille yazın. İyi bir başlangıç seti:
Her yol için neyin başarısız sayılacağını tanımlayın. Katı ve ölçülebilir olun: 500 hatası başarısızlıktır, ama zaman aşımı, sayfanın hiç bitmemesi veya veri eksikliğiyle başarılı dönen bir form da başarısızlıktır.
Başlangıçta kapsamı küçük tutun. Gerçek acı ve gerçek riskle eşleşen 1 ila 3 yol seçin. Eğer çağrı listelerinde genelde “kimse giriş yapamıyor” ve “kaydet düğmesi takılıyor” ise, Login ve Submit form ile başlayın. Ölçümlere ve uyarılara güvendikten sonra Aramayı ekleyin.
İyi SLI'lar sıkıcıdır. Zaten sahip olduğunuz verilerden gelirler ve aracın çalıştığını veya başarısız olduğunu kullanıcıların hissettiği şeyle eşleşirler. Onları ölçmek için tamamen yeni bir izleme kurulumuna ihtiyacınız varsa, daha basit SLI'ları seçin.
İnsanların anlayacağı terimlerle erişilebilirlikle başlayın: aracı açabiliyor muyum ve görevi tamamlayabiliyor muyum? Birçok iç araç için iki SLI çoğu acıyı kapsar:
Sonra gecikmeyi ekleyin, ama dar tutun. Kullanıcıların şikayet ettiği beklemeyi temsil eden bir veya iki ekran veya uç nokta seçin; örneğin panoyu yüklemek veya bir form göndermek. Her şeyi ölçmek genellikle gürültü ve tartışma yaratır.
Ölçüm penceresini baştan kararlaştırın. Dönemsel 30 gün kararlı araçlar için yaygındır; sık yayın yapıyorsanız haftalık hızlı geri bildirim için uygun olabilir. Ne seçerseniz seçin, eğilimlerin anlamlı olması için ona bağlı kalın.
Son olarak, her SLI için bir doğruluk kaynağı seçin ve yazın:
Örnek: İç uygulamanız AppMaster üzerinde kuruluysa, çalışma süresini backend'e yapılan sentetik ping ile, başarı oranını API yanıtlarından ve gecikmeyi backend istek zamanlamalarından ölçebilirsiniz. Önemli olan tutarlılıktır, mükemmeliyet değil.
Kötü bir haftada savunabileceğiniz bir çalışma süresi sayısı seçerek başlayın. Birçok iç araç için %99.5 iyi bir ilk SLO'dur. Yüksek görünür ama normal değişiklik çalışmalarına alan bırakır. Direkt %99.9'a atlamak genellikle mesai dışı paging ve daha yavaş sürümler anlamına gelir.
Çalışma süresini daha gerçek hissettirmek için bunu zamana çevirin. 30 günlük bir ay yaklaşık 43.200 dakika içerir:
Bu izinli kesinti sizin hata bütçenizdir. Eğer bunu erken harcarsanız, riskli değişiklikleri durdurur ve işler düzelenene kadar güvenilirliğe odaklanırsınız.
Gecikme için ortalamalardan kaçının. Ortalamalar kullanıcıların hatırladığı yavaş anları gizler. Bir yüzde kullanın (genellikle p95) ve gerçek bir eyleme bağlı net bir eşik belirleyin. Örnekler: “p95 panonun yüklenmesi iş saatlerinde 2 saniyenin altında” veya “p95 Kaydetme 800 ms altında.”
İlk sayıyı belirlemenin basit bir yolu, bir haftalık gerçek trafiğe bakmak ve bugünlerden biraz daha iyi ama gerçekçi bir hedef seçmektir. Eğer p95 zaten 1.9s ise, 2.0s bir SLO güvenli ve faydalıdır. 500 ms'lik bir SLO sadece gürültü yaratır.
SLO'ları destek kapasitenize göre eşleştirin. Küçük bir ekip, birçok katı hedef yerine birkaç ulaşılabilir hedef tercih etmelidir. Kimse bir saat içinde yanıt veremiyorsa, buna dayanan hedefler koymayın.
Daha sıkı bir SLO rahatlatıcı gelir ama bir bedeli vardır. Bir aracı %99.5'ten %99.9'a çekiyorsanız, “daha az kötü dakika kabul ediyoruz” demiş olursunuz; bu genellikle daha fazla paging ve yeni özellikler yerine güvenilirlik üzerinde daha fazla zaman geçirmek demektir.
Bunu gerçek kılmanın en basit yolu hata bütçesinden bahsetmektir. %99.5 aylık hedefle 30 günlük ayda yaklaşık 3.6 saat downtime “harcayabilirsiniz”. %99.9 ile sadece yaklaşık 43 dakikanız olur. Bu fark, özellik çalışmalarını durdurma sıklığını değiştirir.
Ayrıca beklentileri insanların aracı gerçekten kullandığı zamanlara göre eşleştirmek yardımcı olur. Araç sadece 09:00–18:00 arası kritikse 24/7 hedef pahalı olur. İş saatleri için daha sıkı bir SLO ve mesai dışı için daha gevşek bir SLO koyabilirsiniz ki ekip uyuyabilsin.
Planlı bakım, iletişim kurulup sınırlandırıldığı sürece başarısızlık sayılmamalıdır. Bunu açık bir istisna (bakım penceresi) olarak ele alın; sonradan uyarıları yok saymayın.
Herkesin takasları görmesi için temel bilgileri yazın:
4–6 hafta gerçek veri sonra hedefi gözden geçirin. Eğer hiç hata bütçesi harcamıyorsanız, SLO fazla gevşek olabilir. Hata bütçesini hızlı harcıyorsanız ve özellikler duruyorsa, muhtemelen çok sıkıdır.
Uyarılar SLO'nuz değildir. Uyarılar SLO'yu koruyan “şu an bir şey ters gidiyor” sinyalidir. Basit bir kural: her SLO için bir anlamlı uyarı oluşturun ve kanıt olmadan daha fazlasını eklemeye direnin.
Pratik bir yaklaşım, hızlı SLO tüketimini (hata bütçesini ne kadar çabuk tükettiğiniz) veya kullanıcı acısını yansıtan tek bir net eşikte uyarı vermektir. Gecikme SLO'nuz “p95 800 ms altında” ise her yavaş sıçramada page atmayın. Sadece sürdürülen durumlarda page atın.
Gürültüyü düşük tutan basit bir ayrım:
Somut eşikler (trafiğinize göre ayarlayın): eğer çalışma süresi SLO'nuz aylık %99.5 ise, erişilebilirlik 10 dakika boyunca %99'un altına düşerse page atın (açık bir kesinti). 6 saat boyunca %99.4'ün altındaysa bilet oluşturun (yavaş tüketim). Gecikme için, p95 15 dakika boyunca 1.5 s'nin üzerindeyse page, 2 saat boyunca 1.0 s'nin üzerindeyse bilet oluşturun.
Sahipliği açıkça belirleyin. Kim nöbetçi olacak (hafta bu kişi), onaylama ne anlama geliyor (ör. 10 dakika içinde) ve ilk aksiyon nedir karar verin. Küçük bir ekip AppMaster üzerinde bir iç uygulama çalıştırıyorsa, ilk adım şunlar olabilir: son dağıtımları kontrol et, API hatalarına bak, gerekirse geri al veya yeniden dağıt.
Her gerçek uyarıdan sonra küçük bir takip yapın: nedeni düzeltin ya da uyarıyı sayıyı azaltacak şekilde ayarlayın ama gerçek kullanıcı etkisini yakalamaya devam etsin.
Uyarı yorgunluğu genellikle iyi niyetle başlar. Küçük bir ekip “birkaç” uyarı ekler, sonra her hafta bir tane daha ekler. Kısa sürede insanlar bildirimlere güvenmeyi bırakır ve gerçek kesintiler gözden kaçar.
Büyük bir tuzak her sıçrama için uyarı vermektir. İç araçlar sıklıkla yoğun trafik yaşar (maaş ödeme süreçleri, ay sonu raporları). Bir uyarı 2 dakikalık bir dalgalanmayla tetikleniyorsa ekip onu görmezden gelmeyi öğrenir. Uyarıları ham metrik gürültüsüne değil, kullanıcı etkisine bağlayın.
Başka bir tuzak “daha fazla metrik = daha güvenli” düşüncesidir. Çoğu zaman daha fazla sayıda page anlamına gelir. Kullanıcıların gerçekten hissettiği küçük bir sinyal setine bağlı kalın: giriş hataları, sayfa çok yavaş yükleniyor, ana işler bitmiyor.
En fazla gürültü yaratan hatalar:
Panolar hâlâ önemlidir, ama bir uyarı tetiklendikten sonra teşhis etmeye yardımcı olmalı, uyarının yerine geçmemelidir.
Henüz temiz ölçümleriniz yoksa, varmış gibi davranmayın. Önce temel enstrümantasyonu ekleyin (başarı oranı, p95 gecikme ve “kullanıcı görevi tamamlayabiliyor mu” kontrolü), sonra bir veya iki haftalık gerçek veriye göre eşikleri belirleyin.
Uyarıları etkinleştirmeden önce kısa bir ön kontrol yapın. Çoğu uyarı yorgunluğu, bu temel adımlardan birinin atlanmasından kaynaklanır ve sonra baskı altında düzeltmeye çalışılır.
Küçük bir ekip için pratik kontrol listesi:
Sonra, uyarının gerçekten üzerine gidilebileceğinden emin olun. Kimsenin mevcut olmadığı bir saatte tetiklenen bir uyarı, insanların onu görmezden gelmeyi öğrenmesine neden olur.
İlk page öncesi operasyon detaylarını kararlaştırın:
Aracı oluşturuyor veya değiştiriyorsanız (AppMaster dahil), kontrol listesini tekrar çalıştırın. Yeniden üretilen kod ve yeni akışlar gecikme ve hata desenlerini değiştirebilir; uyarılarınız buna ayak uydurmalıdır.
18 kişilik bir ops ekibi, sipariş durumunu kontrol etmek, başarısız bildirimleri yeniden göndermek ve iadeleri onaylamak için bütün gün dahili bir panoyu kullanıyor. Eğer kapalı veya yavaşsa işler hızlıca durur.
İki SLO seçerler:
Şimdi küçük bir ekibin idare edebileceği üç uyarı eklerler:
Önemli olan gelecek haftada ne olduğudur. Hata bütçesi uyarısı iki kez tetiklenirse, ekip net bir karar verir: yeni bir özelliği ertele ve en büyük gecikme nedenini düzeltmek için iki gün harca (ör. indekslenmemiş bir tablo taraması). AppMaster ile inşa ettiyseler, veri modelini ayarlayıp yeniden üretebilir ve temiz kodu yeniden dağıtarak hızlı yamalar yerine kalıcı düzeltme yapabilirler.
SLO'lar ancak gerçek işle bağlantılı kaldıkça yardımcı olur. İşin püf noktası onları yeni bir program gibi değil, küçük bir alışkanlık gibi ele almaktır.
Küçük bir ekibe uyan bir ritim kullanın ve bunu mevcut bir toplantıya bağlayın. Haftalık kısa bir göz atma sürüklenmeyi yakalar, aylık ayarlama gerçek veriye sahip olduğunuzda yeterlidir.
Dayanıklı bir hafif süreç:
Geliştirmeleri küçük ve görünür tutun. Eğer “her Pazartesi sabahı sayfa yavaş” üç kez ortaya çıkarsa, somut bir değişiklik yapın (bir raporu cacheleyin, bir indeks ekleyin, ağır işi daha geç bir saate planlayın) ve SLI'yı gelecek hafta izleyin.
SLO'ları hayır demek için kullanın, nazik ve net şekilde. Düşük değere sahip bir özellik isteği gelirse, mevcut hata bütçesine işaret edin ve sorun: “Bu değişiklik kaydetme veya onay akışımızı riske atar mı?” Eğer bütçeyi zaten harcıyorsanız, güvenilirlik önceliklidir. Bu engellemek değil, önceliklendirmedir.
Dokümantasyonu minimal tutun: araç başına bir sayfa. Ana kullanıcı eylemlerini, SLO sayıları, onlara bağlı birkaç uyarıyı ve sahibi ekleyin. Araç AppMaster'da inşa edildiyse, log/metriklerin nerede görüleceğini ve kimlerin dağıtım yapabileceğini ekleyin, sonra durun.
Güvenilirliği gerçek kılmanın en kolay yolu ilk kurulumun en küçüğünü tutmaktır. Gerçek kırıldığında acı veren bir iç aracı seçin (nöbet devirleri, sipariş onayları, iadeler, stok düzenlemeleri) ve insanların her gün yaptığı birkaç eylem etrafında hedefler koyun.
Bir çoğu ekiplerin kopyalayabileceği en küçük uygulanabilir kurulum:
Bu stabil hale gelince yavaşça genişletin: ayda bir araç veya bir eylem daha ekleyin. Bir uyarının sahibini isimlendiremiyorsanız, onu henüz oluşturmayın.
Eğer iç araçları inşa ediyor veya yeniden inşa ediyorsanız, AppMaster bakım tarafını sürdürülebilir kılmayı kolaylaştırabilir. Veri modellerini ve iş mantığını görsel olarak güncelleyip temiz kodu yeniden üreterek SLO'ların aracın bugün ne yaptığıyla uyumlu kalmasına yardımcı olur.
Bir iç araç oluşturup ilk günden itibaren temel SLO'lar eklemeyi deneyin. Daha net beklentiler, daha az sürpriz ve küçük ekibinizin yetişebileceği uyarılar elde edersiniz.
Eğer sadece küçük bir ekip kullanıyorsa gerçekten SLO'lara ihtiyaç var mı?SLO'lar “oldukça kararlı” ifadesini ölçülebilir bir hedefe çevirerek güvenilirlik tartışmalarını bitirir. 20 kullanıcı olsa bile bir kesinti siparişleri durdurabilir, desteği yavaşlatabilir veya onayları engelleyebilir; bu yüzden küçük araçların bile büyük etkisi olabilir.
Bir yönetici paneli veya ops panosu için önce neyi ölçmeliyiz?İnsanların her gün yaptığı ve başarısız olduğunda işi durduran birkaç kullanıcı eylemini seçin. Başlangıç için yaygın olanlar: giriş, ana panonun güncel verilerle yüklenmesi, arama/filtreleme ve bir oluştur/güncelle formunun başarılı şekilde gönderilmesi.
SLI, SLO ve SLA arasındaki fark nedir?SLI ölçtüğünüz metriktir (örneğin başarı oranı veya p95 gecikme). SLO o metrik için hedeftir (örneğin 30 gün içinde %99.5 başarı). SLA ise sonuçları olabilecek resmi bir taahhüttür; çoğu iç araç için gerekli değildir.
Küçük bir ekip için gerçekçi bir çalışma süresi SLO'su nedir?Çoğu iç araç için iyi bir ilk çalışma süresi SLO'su aylık %99.5'tir; çünkü sürekli kahramanlık gerektirmeden ulaşılabilir. Araç iş saatlerinde gerçekten kritikse, gerçek verileri gördükten sonra sıkılaştırabilirsiniz.
Çalışma süresi yüzdelerini insanların anlayacağı şekilde dakikalara nasıl çeviririz?Çalışma süresi yüzdesini dakikalara çevirin ki herkes takasları anlasın. 30 günlük bir ayda %99.5 yaklaşık 216 dakika kesintiye izin verir; %99.9 ise yaklaşık 43 dakika verir — bu genellikle daha fazla paging ve daha çok güvenilirlik çalışması anlamına gelir.
Gürültü yaratmadan gecikme SLO'ları nasıl belirlenir?Ortalama yerine p95 gibi bir yüzde kullanın; ortalamalar kullanıcıların hatırladığı yavaş anları gizler. Hedefi gerçek bir eyleme bağlayın (ör. “iş saatlerinde p95 pano yüklenmesi 2s altında”) ve ekibi huzursuz etmeyecek bir eşiği seçin.
Büyük bir izleme sistemi kurmadan hangileri ölçülmesi en kolay SLI'lerdir?Zaten sahip olduğunuz sunucu metrikleri ve loglarla başlayın: erişilebilirlik (erişilebiliyor ve yanıt veriyor mu), kritik eylemlerin başarı oranı ve bir veya iki kritik uç nokta için p95 gecikme. En önemli akışlar için sentetik kontroller yalnızca tutarlı ölçüm gerektiğinde ekleyin.
Bir iç araç için kaç uyarı kurmalıyız?Bir araç için küçük ve kullanıcı etkisine bağlı uyarı setine öncelik verin ve yalnızca sürdürülen problemlerde page atın. Faydalı bir ayrım: “araç etkili şekilde bozuk” için acil page ve “yavaş bozulma” için iş saatlerinde işleme konulacak bilet.
İç araçlarda uyarı yorgunluğuna ne sebep olur ve nasıl önleriz?Çoğu alarm yorgunluğu, her ani dalgalanma için paging yapılmasından veya CPU gibi semptomlara dayalı uyarılardan gelir. Uyarıları az tutun, her birine bir sahip atayın ve gerçek bir uyarı sonrası ya nedeni düzeltin ya da uyarıyı daha az ama etkili olacak şekilde ayarlayın.
AppMaster ile iç araçlar oluşturuyorsak SLO'ları nasıl uygularız?Önce uygulamanızdaki ana eylemleri seçin, sonra bu eylemler için erişilebilirlik, başarı oranı ve p95 gecikmeyi tutarlı bir doğruluk kaynağından ölçün. AppMaster ile inşa ediyorsanız, hedefleri kullanıcıların yaptığı işlere odaklayın (giriş, kaydetme, arama) ve büyük değişikliklerden sonra ölçümleri ve uyarıları güncelleyin.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
