Küçük ekipler için hata bütçeleri: gerçekçi SLO'lar ve ritüeller

Neden küçük ekiplerin erken dönemde hata bütçesine ihtiyacı var

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.

SLO, SLI ve hata bütçesini sadece anlatmak

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.

Koruyacağınız şeyi seçin: kullanıcıların fark ettiği birkaç yolculuk

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:

• Kayıt: kullanıcı formu gönderir ve X saniye içinde uygulamada karşılanır, herhangi bir hata görmez.
• Checkout: ödeme tamamlanır, onay ekranı gösterilir ve kullanıcı iki kez ücretlendirilmez.
• Yayınla / Job çalıştır / API çağrısı: eylem tamamlanır ve kullanıcı beklenen sonucu görür.

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.

Erken ürün için gerçekçi SLO'lar belirleyin

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.

• Yeni kullanıcılar kayıt oluyor: 7 günlük rolling pencerede kayıt denemelerinin %98.5'i başarılı.
• Ödeme yapan kullanıcılar checkout: 30 günlük rolling pencerede ödemelerin %99.0'ı başarılı.
• Aktif kullanıcılar ana sayfayı yüklüyor: 7 günlük rolling pencerede sayfa yüklemelerinin %99.0'ı başarılı.

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.

Hangi olayların önemli olduğuna karar verin ve hangi olayları görmezden gelin

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ış).

Bir yapışkan nota sığacak ciddiyet ölçeği

Ölçeği küçük tutun ve her seferinde kullanın.

• Sev1: Birçok kullanıcı temel bir yolculuktan engelleniyor veya veri riske girdi. Her şeyi bırakın.
• Sev2: Bazı kullanıcılar engelleniyor veya bir temel yolculuk güvenilmez. Bugün düzeltin ya da bir sonraki iş gününe planlayın.
• Sev3: Küçük bozulma veya dahili rahatsızlık. Kaydedin ve devam edin.

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.

Hafif sinyallerle bütçe tüketimini takip edin

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.

Haftalık güvenilirlik ritüeli: 20 dakika, aynı zaman, aynı not

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:

• Bütçe bakışı: her SLO için kalan bütçe ve en büyük tüketen sebep
• Yeni incident'ler: her biri bir satır (ne oldu, ne zaman, kullanıcı etkisi)
• Takipler: tamamlayacağınız 1–3 eylemi seçin
• Taahhütler: bir sahip ve bitiş tarihi atayın, sonra zamanında bitirin

Takipler ve taahhütler arasında haftalık yayın kuralınızı belirleyin ve sıkıcı tutun:

• Normal: planlandığı gibi gönderin.
• İtemkinli: gönderin, ama etkilenen alanda riskli değişikliklerden kaçının.
• Dondurma: en büyük sorun çözülene kadar o alandaki değişiklikleri durdurun.

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.

Bütçeyi drama olmadan yol haritası kararlarına çevirin

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:

• Eğer bütçe sağlamsa, göndermeye devam edin ve zaten bildiğiniz en kötü güvenilirlik sorununu düzeltin.
• Bütçe hızlı tükeniyorsa, önemsiz özellik çalışmalarını durdurun ve ana hata modunu azaltmaya odaklanın.
• Bütçe tükendiyse, dengedeki pozisyona dönene kadar güvenilirlik işi yol haritası olur.

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.

Küçük ekiplerin düştüğü yaygın tuzaklar

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:

• Her bileşen yerine ana kullanıcı yolculuğu başına bir SLO ile başlayın.
• Çoğu hafta karşılayabileceğiniz bir SLO belirleyin, sonra sıkılaştırın.
• Sadece kullanıcı etkisine göre sayfa atın.
• Basit bir incident tanımı kullanıp her seferinde aynı şekilde uygulayın.
• Postmortem'leri “buna ne izin verdi” üzerine yapın, “kim yaptı” üzerine değil.

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 dakikada çalıştırabileceğiniz hızlı kontrol listesi

10 dakikalık bir zamanlayıcı koyun, ortak bir doküman açın ve bu beş soruyu cevaplayın:

• Kırılmaması gereken 1–3 kullanıcı yolculuğu hangisi?
• Her yolculuk için bir SLO cümlesi ve zaman penceresi yazabiliyor musunuz?
• Bir olayı ne sayacağımız ve kimin 24 saat içinde kaydedeceği konusunda anlaşabildiniz mi?
• Son 7 güne baktınız mı ve etkiye göre (sıkıntı değil) 1–3 takip seçtiniz mi?
• Bütçe düşükse basit bir yayın kuralınız (release rule) var mı?

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.

Örnek: küçük iki kişilik startup'ın tek bir özellik için hata bütçesi kullanması

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:

• Journey SLO: Proje oluşturma 3 saniyenin altında tamamlanır, haftalık %99 başarı.
• Incident tanımı: Başarı oranı 10+ dakika boyunca %97'nin altına düşerse veya p95 gecikme 15+ dakika boyunca 5 saniyenin üstüne çıkarsa, bu bir incident'tir ve kısa bir not yazarlar.

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.

Sonraki adımlar: küçük başlayın ve döngüyü sıkı tutun

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.