Küçük ekipler için hata bütçelerini öğrenin: erken ürünler için gerçekçi SLO'lar koyun, hangi olayların önemli olduğunu belirleyin ve basit bir haftalık güvenilirlik ritüeli yürütün.
Küçük ekipler hızlı gönderir çünkü zorunludur. Risk genellikle tek dramatik bir kesinti değildir. Daha ziyade aynı küçük hata sürekli tekrar eder: takılgan bir kayıt formu, bazen başarısız olan bir checkout, ara sıra bir ekranı bozan bir deploy. Her biri saatleri çalar, güveni azaltır ve sürümleri bir şansa dönüştürür.
Hata bütçeleri, küçük ekiplerin hızla ilerlerken "güvenilirlik kendiliğinden olur" numarası yapmamasını sağlayan basit bir yöntemdir.
SLO (service level objective) kullanıcı deneyimiyle ilgili sayısal ve zamana bağlı açık bir vaattir. Örnek: “Başarılı checkout'lar son 7 günde en az %99.5 olmalı.” Hata bütçesi ise bu vaad içindeki izin verilen “kötü” miktarıdır. Eğer SLO'nuz %99.5 ise haftalık bütçeniz %0.5 başarısız checkout'tır.
Bu mükemmellik ya da şov yapmakla ilgili değildir. Ağır süreç, bitmeyen toplantılar veya kimsenin güncellemediği bir tablo değildir. "Yeterince iyi"nin ne demek olduğunu kararlaştırmanın, sapmayı fark etmenin ve bir sonraki adımı sakince belirlemenin bir yoludur.
Küçük başlayın: en önemli yolculuklara bağlı 1–3 kullanıcı odaklı SLO seçin, zaten sahip olduğunuz sinyallerle ölçün (hatalar, gecikme, başarısız ödemeler) ve bütçe tüketimine bakıp bir takip eylemi seçtiğiniz kısa bir haftalık gözden geçirme yapın. Alışkanlık, araçtan daha önemlidir.
Güvenilirliği bir diyet planı gibi düşünün. Mükemmel günlere ihtiyacınız yok. Bir hedefe, bunu ölçme biçimine ve gerçek hayat için bir toleransa ihtiyacınız var.
SLI (service level indicator) izlediğiniz sayıdır; örneğin “başarılı isteklerin yüzdesi” veya “p95 sayfa yüklenme süresi 2 saniyenin altında”. SLO, o sayı için konulan hedeftir: “isteklerin %99.9'u başarılı olmalı.” Hata bütçesi ise SLO'dan ne kadar sapabileceğinizdir.
Örnek: SLO'nuz %99.9 kullanılabilirlikse, bütçeniz %0.1 kesinti olur. Bir haftada (10.080 dakika) %0.1 yaklaşık 10 dakikadır. Bu, 10 dakikayı tüketmeye çalışmanız gerektiği anlamına gelmez. Bunun yerine, tükettiğinizde hız, deney ve özellik geliştirme karşılığında bilinçli bir takas yaptığınız anlamına gelir.
Değer şuradadır: güvenilirliği raporlama egzersizi yerine karar aracına çevirir. Eğer bütçenizin çoğunu Çarşamba'ya kadar harcadıysanız, riskli değişiklikleri durdurur ve bozulanları düzeltirsiniz. Eğer neredeyse hiç harcamıyorsanız, daha emin biçimde gönderebilirsiniz.
Her şey aynı SLO'yu gerektirmez. Kamuya açık müşteri uygulaması %99.9 isteyebilir. Dahili bir yönetim aracı genellikle daha gevşek olabilir çünkü daha az kişi fark eder ve etkisi daha küçüktür.
Her şeyi ölçerek başlamayın. Kullanıcının ürününüzün çalışıp çalışmadığına karar verdiği anları korumaya başlayın.
En fazla güven taşıyan 1–3 kullanıcı yolculuğu seçin. Bu yolculuklar sağlam ise, çoğu diğer sorun daha küçük hissedilir. İyi adaylar ilk dokunuş (kayıt veya giriş), para anı (checkout veya yükseltme) ve temel eylemdir (yayınlama, oluşturma, gönderme, yükleme veya kritik bir API çağrısı).
"Başarı"nın ne demek olduğunu sade şekilde yazın. Kullanıcılar geliştirici değilse "200 OK" gibi teknik ifadelerden kaçının.
Uyarlayabileceğiniz birkaç örnek:
Değişiklik hızınıza uygun bir ölçüm penceresi seçin. Günlük gönderim yapıyorsanız hızlı geri bildirim için 7 günlük pencere işe yarar. Yayınlar daha seyrekse veya veriniz gürültülü ise 28 günlük pencere daha sakin olur.
Erken ürünlerin kısıtları vardır: trafik düşük olabilir (kötü bir deploy sayıları çarpıtır), akışlar hızla değişir ve telemetri genellikle incedir. Bu sorun değil. Basit sayımlarla başlayın (denemeler vs başarılar). Yolculuk kendini değiştirmeyi bıraktıktan sonra tanımları sıkılaştırın.
Bugün gönderdiğiniz şeyle başlayın, olmayacak hayallerle değil. Bir veya iki hafta boyunca her ana yolculuk için bir temel çekin: ne kadar sık başarılı, ne kadar sık başarısız. Gerçek trafik kullanın eğer varsa. Yoksa kendi testlerinizi, destek taleplerini ve logları kullanın. "Normal"ün kaba bir resmini çıkartıyorsunuz.
İlk SLO'nuz, çoğu hafta ulaşabileceğiniz bir şey olmalı ve hâlâ göndermeyi sağlamalıdır. Eğer mevcut başarı oranınız %98.5 ise, %99.9 koyup ümit etmek yerine %98 veya %98.5 koyun, sonra ileride sıkılaştırın.
Gecikme cazip olabilir ama erken dönemde dikkat dağıtabilir. Birçok ekip önce başarı oranı SLO'sundan daha çok fayda görür (isteklerin hatasız tamamlanması). Kullanıcılar bunu açıkça hissedene ve veriler yeterince stabil olana kadar gecikmeyi sonradan ekleyin.
Yardımcı bir format: her yolculuk için bir satır: kim, ne, hedef ve zaman penceresi.
Faturalama ve kimlik doğrulama gibi para ve güven anları için pencereyi daha uzun tutun. Günlük akışlar için daha kısa tutun. SLO'yu kolayca karşılayınca biraz yükseltin ve devam edin.
Küçük ekipler her aksama için alarm çalındığında çok fazla güvenilirlik zamanı kaybeder. Amaç basit: kullanıcı tarafından görülen acı bütçeyi tüketir; kalan her şey normal iş olarak ele alınır.
Küçük bir olay seti yeterlidir: tam kesinti, kısmi kesinti (bir ana akış bozulur), bozulmuş performans (çalışıyor ama yavaş), kötü deploy (sürüm hataya neden olur) ve veri problemleri (yanlış, eksik, çoğaltılmış).
Ölçeği küçük tutun ve her seferinde kullanın.
Bütçeye neyin sayılacağına karar verin. Kullanıcı tarafından görülen hataları harcama olarak ele alın: bozuk kayıt veya checkout, kullanıcıların hissettiği timeout'lar, yolculukları durduran 5xx artışları. İletilmiş planlı bakım, eğer iletişim kurulduysa ve uygulama o pencerede beklendiği gibi davrandıysa sayılmamalıdır.
Çoğu tartışmayı bitiren bir kural: gerçek bir dış kullanıcı korunmuş bir yolculuğu tamamlayamıyor olsaydı, bu bütçeye yazılır. Aksi halde yazılmaz.
Bu kural sıradan gri alanları da kapsar: üçüncü taraf kesintisi yalnızca kullanıcı yolculuğunuzu bozuyorsa sayılır, düşük trafikli saatler kullanıcı etkileniyorsa sayılır, ve sadece dahili tester'lar ürünün ana kullanımı değilse sayılmaz.
Amaç mükemmel ölçüm değil. Ortak, tekrarlanabilir bir sinyal: güvenilirlik pahalı hale geldiğinde sizi uyarır.
Her SLO için bir doğruluk kaynağı seçin ve ona bağlı kalın: bir monitoring panosu, uygulama logları, tek bir sentetik kontrol, veya "başarılı checkout'lar" gibi tek bir metric. Ölçüm yöntemini daha sonra değiştirirseniz, tarihi yazın ve bunu bir sıfırlama gibi kabul edin ki elmalarla armutlar karşılaştırılmasın.
Alarmlar bütçe tüketimini yansıtmalı, her aksama için değil. Kısa bir sıçrama can sıkıcı olabilir ama aylık bütçeyi az değerde etkiliyorsa kimseyi uyandırmamalıdır. Basit bir desen işe yarar: “hızlı tüketim” için alarm (aylık bütçeyi bir günde harcayacak gibi) ve “yavaş tüketim” için daha yumuşak bir alarm (bir haftada harcayacak gibi).
Küçük bir güvenilirlik kaydı tutun ki hafızaya güvenmeyin. Her olay için bir satır yeter: tarih ve süre, kullanıcı etkisi, muhtemel sebep, ne değiştirdiniz ve takip sahibi ile bitiş tarihi.
Örnek: iki kişilik bir ekip mobil uygulama için yeni bir API gönderir. SLO'ları “%99.5 başarılı istek”dir, tek bir sayaçtan ölçülür. Kötü bir deploy başarıyı %97'ye düşürür 20 dakika boyunca. Hızlı-tüketim alarmı tetiklenir, rollback yapılır ve takip "deploy öncesi canary kontrolü ekle" olur.
Büyük bir sürece ihtiyacınız yok. Görünürlüğü yüksek tutan, şehir vakitlerini çalmayan küçük bir alışkanlığa ihtiyacınız var. 20 dakikalık bir check-in aynı soruya indirger: güvenilirliği planladığımızdan daha hızlı mı harcıyoruz?
Her hafta aynı takvim slotunu kullanın. Üzerine eklediğiniz tek bir ortak not tutun (yeniden yazmayın). Tutarlılık detaydan daha iyidir.
Sığ bir ajanda:
Takipler ve taahhütler arasında haftalık yayın kuralınızı belirleyin ve sıkıcı tutun:
Eğer kayıt akışınız iki kısa kesinti yaşadı ve bütçesinin çoğunu yaktıysa, sadece kayıtla ilgili değişiklikleri dondurup başka işleri göndermeye devam edebilirsiniz.
Bir hata bütçesi, gelecek hafta ne yapacağınızı değiştirmiyorsa önemsizdir. Amaç mükemmel çalışma değil: bir sonraki hafta özellik mi gönderiyoruz yoksa güvenilirlik borcunu mu kapatıyoruz sorusuna netlik kazandırmaktır.
Açıkça söyleyebileceğiniz bir politika:
Bu ceza değil. Bu, kullanıcıların daha sonra bunun bedelini ödememesi için açık bir takastır.
Yavaşladığınızda, "stabiliteyi artır" gibi belirsiz görevlerden kaçının. Bir sonraki sonucu değiştirecek somut değişiklikler seçin: bekleme süreleri (timeouts), giriş doğrulama, rate limit'ler ekleyin; hatayı yakalayacak bir testi geliştirin; rollback'i kolaylaştırın; en çok hataya neden olan kaynağı düzeltin; veya kullanıcı yolculuğuna bağlı bir alarm ekleyin.
Raporlamayı suçlamadan ayrı tutun. Hatalı olsa bile hızlı olay raporlarını ödüllendirin. Tek kötü olay raporu, gecikmiş ve kimsenin neyin değiştiğini hatırlamadığı rapordur.
Sık tuzaklardan biri ilk günden itibaren altın kaplama bir SLO belirlemek (ör. %99.99 güzel gelir) ve gerçeğin çarpmasıyla bunu sessizce görmezden gelmektir. Başlangıç SLO'nuz mevcut insan ve araçlarla ulaşılabilir olmalı, aksi halde arka plan gürültüsü olur.
Başka bir hata yanlış şeyi ölçmektir. Ekipler beş servis ve bir veritabanı grafiğine bakarken kullanıcıların gerçekten hissettiği yolculuğu (kayıt, checkout, kaydet) kaçırır. Kullanıcının bakış açısıyla SLO'yu bir cümlede açıklayamıyorsanız, muhtemelen çok içseldir.
Alarm yorgunluğu üretimi düzeltme yeteneği olan tek kişiyi tüketir. Her küçük dalgalanma birini çağırırsa, çağrılar "normal" olur ve gerçek yangınlar kaçırılır. Kullanıcı etkisine göre sayfa açın. Diğer her şeyi günlük kontrole yönlendirin.
Daha sessiz bir katil tutarsız sayımdır. Bir hafta iki dakikalık yavaşlamayı olay sayarsınız, başka hafta saymazsınız. Sonra bütçe tartışma konusu olur, sinyal değil. Kuralları bir kere yazıp tutarlı uygulayın.
Yardımcı gardrail'ler:
Eğer bir deploy login'i 3 dakika bozduysa, her seferinde sayın; hızlı düzeltilse bile. Tutarlılık bütçeyi işe yarar kılan şeydir.
10 dakikalık bir zamanlayıcı koyun, ortak bir doküman açın ve bu beş soruyu cevaplayın:
Henüz ölçemiyorsanız, hızlı görebileceğiniz bir vekil ile başlayın: başarısız ödemeler, 500 hataları veya "checkout" etiketli destek talepleri. İzleme iyiye gittiğinde vekilleri değiştirin.
Örnek: iki kişilik ekip bu hafta üç tane “şifre sıfırlanamıyor” mesajı gördü. Eğer parola sıfırlama korunan bir yolculuksa, bu bir olaydır. Bir kısa not yazarlar (ne oldu, kaç kullanıcı, ne yaptılar) ve bir takip seçerler: reset başarısızlıkları için alarm ekle veya retry ekle.
Maya ve Jon iki kişilik bir startup yönetiyor ve her Cuma gönderiyorlar. Hızlı ilerliyorlar ama ilk ödeyen kullanıcıları tek bir şeye önem veriyor: bir proje oluşturup birini davet edebiliyorlar mı, kırılmadan?
Geçen hafta bir gerçek kesinti yaşadılar: kötü bir migration sonrası “Proje oluştur” 22 dakika boyunca başarısız oldu. Ayrıca 8–12 saniye arasında dönen üç “yavaş ama çalışıyor” dönemleri vardı. Kullanıcılar şikayet etti, ama ekip yavaşlığın "aşağı" sayılıp sayılmayacağı konusunda tartıştı.
Bir yolculuk seçip ölçülebilir yaptılar:
Pazartesi 20 dakikalık ritüeli çalıştırdılar. Aynı zaman, aynı doküman. Dört soruyu cevapladılar: ne oldu, ne kadar bütçe yandı, ne tekrarlandı ve tekrarını engelleyecek tek değişiklik ne olur.
Takas bariz hale geldi: kesinti + yavaş dönemler haftalık bütçenin çoğunu yaktı. Bu yüzden gelecek haftaki “büyük özellik” yerine “DB index ekle, migration'ları daha güvenli yap, create-project hatalarında alarm ekle” oldu.
Sonuç mükemmel güvenilirlik değil. Tekrarlayan problemlerin azalması, net evet/hayır kararları ve neyin “yeterince kötü” olduğunu önceden kararlaştırdıkları için daha az gece müdahalesi.
Bir kullanıcı yolculuğu seçin ve ona basit bir güvenilirlik vaadi koyun. Hata bütçeleri sıkıcı ve tekrarlanabilir olduğunda en iyi sonucu verir, mükemmel olmalarında değil.
Bir SLO ve bir haftalık ritüelle başlayın. Bir aydan sonra hâlâ kolay geliyorsa ikinci SLO'yu ekleyin. Ağır geliyorsa küçültün.
Hesaplamayı basit tutun (haftalık veya aylık). Hedefi bulunduğunuz seviyeye göre gerçekçi tutun. Bir sayfalık bir güvenilirlik notu yazın: SLO ve nasıl ölçtüğünüz, neyin incident sayıldığı, bu hafta kim sorumlu, check-in zamanı ve bütçe çok hızlı tükenirse varsayılan olarak ne yapacağınız.
Koder.ai (koder.ai) gibi bir platform üzerinde inşa ediyorsanız, hızlı iterasyonu güvenlik alışkanlıklarıyla eşleştirmeye yardımcı olabilir—özellikle snapshot'lar ve rollback—böylece “son iyi duruma geri dön” normal, pratik bir hareket olarak kalır.
Döngüyü sıkı tutun: bir SLO, bir not, bir kısa haftalık check-in. Amaç olayları yok etmek değil. Erken fark etmek, sakin karar vermek ve kullanıcıların gerçekten hissettiği birkaç şeyi korumaktır.
Bir SLO, belirli bir zaman penceresinde ölçülen kullanıcı deneyimiyle ilgili bir güvence veya vaat anlamına gelir (örneğin 7 veya 30 gün).
Örnek: “Son 7 gündeki checkout'ların %99.5'i başarılı.”
Bir hata bütçesi, SLO'nuz içindeki izin verilen “kötü” kısmın miktarıdır.
Eğer SLO'nuz %99.5 başarı ise, o pencerede %0.5 başarısızlık bütçeniz vardır. Bütçeyi çok hızlı tüketirseniz, riskli değişiklikleri yavaşlatır ve sebepleri düzeltirsiniz.
Önce 1–3 yolculuk koruyun—kullanıcının hemen fark edeceği noktalar:
Bunlar güvenilir olursa, diğer sorunlar genellikle daha küçük hissedilir ve daha kolay önceliklenir.
Haftalar içinde tutturabileceğiniz bir başlangıç tabanı seçin.
Bugün %98.5'teyseniz, %98–98.5 ile başlamak, %99.9 gibi altın kaplamalı bir hedef koyup sonra görmezden gelmekten daha faydalıdır.
Basit sayımlar kullanın: denemeler vs başarılar.
İyi başlangıç kaynakları:
Mükemmel gözlemlenebilirliği beklemeyin; güvenilir bir vekil ile başlayın ve tutarlı kalın.
Eğer harici bir kullanıcı fark eder ve korunmuş bir yolculuğu tamamlayamazsa, bunu sayın.
Bütçe hesabına giren örnekler:
Sadece dahili rahatsızlıkları saymayın, eğer dahili kullanım ana kullanım değilse.
Basit bir kural: bütçe tüketimi üzerine sayfa atın, her küçük dalgalanma için değil.
İki faydalı alarm türü:
Bu, alarm yorgunluğunu azaltır ve dikkat gerektiren sorunlara odaklanır.
20 dakikada tutulacak, aynı zaman ve aynı doküman:
Haftalık bir yayın modu belirleyin: Normal, İtemkinli, veya .
Kolayca söylenebilen bir politika kullanın:
Amaç suçlamadan ziyade sakin bir takastır.
Birkaç pratik güvenlik önlemi işe yarar:
Koder.ai gibi bir platform üzerinde inşa ediyorsanız, “son iyi duruma geri dön” hareketini rutin hale getirin ve tekrar eden rollback'leri test veya deploy kontrollerine yatırım sinyali olarak görün.
