SLO nedir? Tek kişilik projeler için pratik bir rehber

SLO nedir? Servisinizin belirli bir zaman aralığında ne sıklıkla çalışması gerektiğini ölçülebilir bir sayıyla ifade eden hedeftir. "İstekların %99.9'u 30 gün boyunca başarılı olur" cümlesi bir SLO'dur. "Site iyi görünüyor" gibi bir hissi kontrol edebileceğiniz bir sayıya çevirir ve yeni özellik göndermeyi bırakıp önce sorunları düzeltmeniz gereken anı size gösterir.

Bunun için bir platform ekibine ihtiyacınız yok. Tek bir API ve bir Postgres veritabanı olan tek kişilik bir geliştirici, bir öğleden sonrada işe yarar bir SLO yazabilir. Aşağıda terimin ne anlama geldiğini, sayıyı nasıl seçeceğinizi ve işlerin nerede ters gittiğini anlatıyorum.

Gece 2'de uygulamanın bozuk olup olmadığını kimse bilmiyordu

Haftada 400 kullanıcısı olan bir yan projeyi düşünün. Bir gece ödeme endpoint'i yaklaşık 20 dakika boyunca 500 hatası dönmeye başlıyor. Kimse tweet atmıyor, kimse e-posta yazmıyor. Bunu üç gün sonra tek bir destek mesajından öğreniyorsunuz.

Bu kötü müydü? Bir hedefiniz yoksa cevap veremezsiniz. Hedefiniz varsa verebilirsiniz: SLO'nuz ayda yaklaşık 43 dakika hataya izin veriyorsa ve siz 20 dakika harcadıysanız, tek bir kötü gecede izninizin neredeyse yarısını kullanmışsınız demektir. SLO'nun tüm amacı budur. Bir hissi bir bütçeyle değiştirir.

SLI, SLO ve SLA arasındaki fark

İnsanlar SLI, SLO ve SLA'yı sürekli birbirine karıştırıyor, o yüzden kısa özeti vereyim.

Bir SLI (hizmet seviyesi göstergesi) bir ölçümdür. "Son 30 günde 5xx dışında bir durum koduyla dönen HTTP isteklerinin oranı" bir SLI'dır. İyi olayların toplam olaylara oranıdır.

Bir SLO (hizmet seviyesi hedefi) o ölçüm için konan hedeftir. "Bu oran en az %99.9 seviyesinde kalmalı" cümlesi SLO'dur. Bu iç bir hedeftir. Siz belirlersiniz, değiştirebilirsiniz ve kimse sizi bunun için dava etmez.

Bir SLA (hizmet seviyesi anlaşması) genellikle iade veya kredi gibi sonuçları olan bir sözleşmedir. Çoğu yan projenin SLA'sı yoktur ve bu sorun değil. SLA olmadan da SLO işletebilirsiniz. Uzun versiyonu isterseniz standart referans Google SRE workbook'un SLO uygulama bölümü.

Sıra önemli: önce SLI'yı seçin, sonra SLO'yu, ve SLA'yı yalnızca bir ödeme yapan müşteri bunu yazılı olarak isterse düşünün.

Hata bütçesi: çalışma şeklinizi değiştiren kısım

%99.9'luk bir SLO, olayların %0.1'inin başarısız olabileceği anlamına gelir. Bu izin hata bütçenizdir ve fikrin asıl faydalı yarısı budur.

30 günlük bir ayda %99.9 kullanılabilirlik, yaklaşık 43 dakika izin verilen kesinti süresi bırakır. Hesap şöyle: 30 gün çarpı 24 saat çarpı 60 dakika, yani 43.200 dakika, çarpı 0.001. %99 hedefi yaklaşık 7.2 saat verir. %99.99 hedefi ise yaklaşık 4.3 dakika.

Son iki sayı, küçük projelerin neden yüksek hedef koymaması gerektiğini açıklıyor. Ayda dört dakika demek, kötü bir deploy ve geri alma işleminin bile hedefi bozması demek. Pratikte insanları yanıltan şey şu: hedefi ne kadar yükseğe koyarsanız, zamanınızın o sayıyı savunmaya gitme payı o kadar artar ve ürünü geliştirmeye o kadar az kalır.

Bütçe ayrıca bir sonraki işin ne olacağına dair bir kural verir. Bütçe büyük ölçüde duruyorsa riskli özelliği gönderin. Bütçe harcandıysa önce sorunlu şeyi düzeltin. Toplantıya gerek yok, panoda sadece bir sayı var.

Bu, tartışmaların da seyrini değiştirir. "Bence bu güvenli" demek yerine "bütçede hâlâ hata payı var" diyebilirsiniz. Tek kişi olsanız bile bu alışkanlık, geçen haftanın sezgisini bugünkü kararınızdan ayırmanıza yardım eder. Karar, bir his değil, bir rakam üzerinden verilir.

Ölçülebilir bir SLI ve gerçekçi bir sayı seçmek

Önce kullanıcının "bozuk" dediği şeyin ne olduğunu düşünün. Bir web uygulaması için bu genellikle iki soruya iner: istek başarılı oldu mu, ve yeterince hızlı mıydı?

Çoğu yan proje için iki SLI değerin %90'ını karşılar:

• Kullanılabilirlik: iyi isteklerin toplam isteklere oranı. İyi derken 5xx olmayan bir yanıt kastediliyor.

• Gecikme: belirli bir eşiğin altında yanıt verilen isteklerin payı, örneğin isteklerin %95'inin 500 ms altında yanıt alması.

Gecikmenin ortalama olarak değil, eşiğin altındaki isteklerin payı olarak yazıldığına dikkat edin. Ortalamalar yavaş kuyruğu gizler ve kullanıcıların vazgeçtiği yer tam orasıdır. Burada yüzdelik düşünmek önemli: 300 ms'lik bir ortalamanın altında 4 saniyelik bir p99 saklanabilir.

Ölçümü sistemin kenarında, kullanıcıya mümkün olduğunca yakın yapın. Aynı VPC içinden /healthz adresine ping atan bir sağlık kontrolü, sürecin ayakta olduğunu söyler, kullanıcıların giriş yapıp yapamadığını söylemez. Yalnızca bir ölçüm yapabiliyorsanız, dışarıdan gerçek bir kullanıcı yolunu, örneğin girişi veya ödemeyi, test edin.

Yeni bir proje için dürüst cevap %99 veya %99.5'tir. Son 30 günlük verinize bakın, gerçekte ne sunduğunuzu hesaplayın, SLO'yu bunun biraz altına koyun ve kullanıcılar şikayet ederse sonra sıkılaştırın.

Tek kişilik bir proje için kaba bir rehber:

• Gelir getirmeyen hobi aracı: %99 yeterli. Ayda yaklaşık 7 saatlik başarısızlık çoğu kullanıcı için görünmez.

• Birkaç düzine müşterisi olan ücretli SaaS: ürünün zamana ne kadar duyarlı olduğuna bağlı olarak %99.5 ile %99.9 arası.

• Müşterilerin iş saatlerinde bağımlı olduğu her şey: %99.9, ve söz vermeden önce geri alma yolunuzu test edin.

Bu üç satırı yazarken kendinize tek bir soru sorun: Bu kullanıcı için kötü bir gün nasıl görünürdü? Cevap genellikle bir endpoint'in hata döndürmesi ya da bir sayfanın saniyeler sürmesidir. Bu cevabı bir SLI'ye çevirin ve ölçümü o gün başlatın. Gerisi, o ölçümün üzerine kurulan küçük bir düzendir.

Denenmiş, optimal olmayan ama yine de yapmaya değer bir şey: her ay %100 tutturduğunuz bir SLO, çok düşük konmuş bir sayıdır. Her ay kaçırdığınız bir SLO ise kimsenin güvenmediği bir sayıdır. Ara sıra kaçırmayı hedefleyin, çünkü bütçe asıl işini o zaman yapar.

Her SLO'yu üç ayda bir gözden geçirin, ya da hedefi ciddi biçimde kaçırdığınız veya bütçeyi hiç kullanmadığınız her ayın ardından. Üst üste iki ay kaçırmak, ya sistemin gerçek bir işe ihtiyacı olduğunu ya da hedefin o aşama için iddialı olduğunu gösterir. İkisi de işe yarar bilgidir.

Uptime izlemenin üstüne SLO nasıl eklenir

Aralarında örtüşme olsa da SLO, uptime izlemeyle aynı şey değil. Bir ping izleyici, belirli bir dakikada sitenin yanıt verip vermediğini söyler. Bir SLO ise bir ay boyunca gerçek kullanıcı isteklerinin yüzde kaçının başarılı olduğunu ve bunun bir sonraki kararınız için ne anlama geldiğini söyler.

İki hafta düşünün: ping izleyici her dakika yeşil görünüyor, ama tek bir yavaş veritabanı sorgusu, oturum açmış kullanıcıların %3'ü için pano sayfasının zaman aşımına uğramasına neden oluyor. İzleyici her şeyin yolunda olduğunu söyler. SLI ise gecikme hedefinizi kaçırdığınızı gösterir. Pazartesi günü ne yapacağınızı değiştirecek olan yalnızca biridir.

Ping izleyiciyi yine de tutun. Ucuzdur ve tam kesintileri hızlıca yakalar. Sadece onu "çalışıyor" tanımının kendisi değil, bir girdi olarak görün.

Bir SLO'yu kurduktan sonraki ilk ay, sayılardan çok alışkanlık kazanmak içindir. Haftada bir paneli açın ve üç rakamı okuyun: mevcut SLI, kalan bütçe ve yanma hızı. Bu küçük rutin, tek başına çalışan bir geliştirici için haftalık bir toplantının yerini tutar ve bütçenin ne zaman konuşulması gerektiğini size hatırlatır.

Bir sağlayıcıya ihtiyacınız yok. SLO'yu repo'nuzda, SLO.md adlı bir dosyaya yazabilirsiniz:

service: checkout-api
window: 30d
slis:
  availability:
    good: http_status < 500
    total: /healthz hariç tüm istekler
  latency:
    good: response_time < 500ms
    total: /healthz hariç tüm istekler
objectives:
  availability: 99.5%
  latency: 95%
if_budget_burned:
  - acil olmayan özellikleri dondur
  - en büyük hata kaynağını önce düzelt

Stack'iniz zaten istek sayılarını dışa aktarıyorsa, kullanılabilirlik SLI'si Prometheus tarzı sözdiziminde tek satırdır:

sum(rate(http_requests_total{status!~"5.."}[30d]))
  / sum(rate(http_requests_total[30d]))

Bu oran, hedefinizle karşılaştırıldığında tüm SLO panonuzun ta kendisidir. Geri kalan her şey cilalamadır. Üç panel yeterli: mevcut SLI, kalan bütçe ve bir yanma hızı çizgisi.

Her gecikmede değil, yanma hızında uyarı almak

En yaygın hata neredeyse herkesin yaptığı şey: hata oranı bir eşiği geçtiğinde uyarı almak. 90 saniyelik bir sıçrama yüzünden gece 3'te uyandırılırsınız ve bu sıçrama, ayın bütçesinin yalnızca %0.2'sine mal olmuştur.

Yanma hızı bunu düzeltir. Bütçeyi, pencere sonunda tam sıfıra ulaştıracak tempoyla karşılaştırarak ne kadar hızlı tükettiğinizi sorar. Yanma hızı 1, ayı bütçe bitmeden ve sürpriz olmadan bitireceğiniz anlamına gelir. Yanma hızı 10 ise bütçenin üç gün içinde biteceği anlamına gelir.

Tek kişi için sağlam bir kurulum iki uyarıdır. Hızlı olan, bir saat boyunca 10'un üzerindeki yanma hızı gibi bir durumda sizi uyandırır. Yavaş olan, bir gün boyunca yaklaşık 2'lik bir yanma hızında sabah için bir kayıt açar. Mantığı için Google SRE kitabının hizmet seviyesi hedefleri bölümüne bakabilirsiniz; çok pencereli versiyonu ise yukarıda bağlanan workbook'ta.

Uyarı sayısı da az olmalı. Her gün birkaç kez telefonunuza düşen bir uyarı, bir süre sonra dikkate alınmaz hale gelir ve asıl gerçek uyarı o gürültünün içinde kaybolur. Yanma hızına dayalı uyarılar, bu gürültüyü azaltmanın en pratik yoludur, çünkü yalnızca bütçenin gerçekten tehlikeye girdiği anlarda çalar.

Ekibin tamamı sizseniz hangi aracı seçmelisiniz

Bir ay boyunca bir elektronik tablo ve bir cron işiyle SLO çalıştırabilirsiniz; neyi önemsediğinizi öğrenirken bu yeterli. Sayılar önem kazandığında bir araç hak kazanır. Özellik listesi kadar yığınınız da karar verir, bu yüzden üç seçeneğe bakın.

Grafana, Prometheus metriklerini zaten dışa aktaranlar için varsayılan seçenektir. Ücretsiz katmanı yan proje için cömerttir ve SLO özelliği zaten sahip olduğunuz veri üzerinde çalışır. Henüz bir metrik hattınız yoksa ve bir tane kurma isteğiniz yoksa atlayın.

New Relic, ayda 100 GB veri alımına kadar ücretsiz bir katmana ve platforma yerleşik SLO araçlarına sahiptir. Az yapılandırmayla agent tabanlı kurulum istiyorsanız uygundur. Dezavantajı, ücretsiz kotayı aştığınızda maliyetlerin daha az öngörülebilir olmasıdır.

Datadog en eksiksiz ve en pahalı seçenektir. Altyapı, APM ve loglar ayrı ayrı faturalandırılır. Etrafınızda bir ekip büyüyorsa değer katar. Başkası ödemiyorsa tek kişilik bir proje için atlayın.

Hangi seçeneği tercih ederseniz edin, ilk gün on beş SLO tanımlama dürtüsüne direnin. Kullanıcıya dönük her servis için bir kullanılabilirlik SLO'su ve bir gecikme SLO'su, öğrenmek için yeterlidir.

Araç seçimi, bir sonraki adımın yerini almamalı. Bir paneli ne kadar güzel kurarsanız kurun, bütçe bittiğinde ne yapacağınızı önceden yazmadıysanız, pano size sadece bir süs olur. Önce kuralı yazın, sonra aracı bağlayın.

Gerçek rakamlarla bir ay ve sık yapılan üç hata

Diyelim ki 30 günde %99.5 kullanılabilirlik hedefiniz var ve ayda yaklaşık 600.000 istek sunuyorsunuz. Bu hedef %0.5 başarısızlığa izin verir, yani bütçe bitmeden önce 3.000 başarısız istek.

9. günde kötü bir migration 25 dakika boyunca 500 döndürüyor ve 1.100 başarısız isteğe mal oluyor. Tek bir akşamda bütçenin yaklaşık %37'sini kullanmış oluyorsunuz. 17. günde bir üçüncü taraf API zaman aşımına uğruyor ve 900 daha yakıyor. Şu an kalan 13 günle birlikte yaklaşık %67 harcanmış durumdasınız.

Tam bu an bütçenin hakkını verdiği andır. Paniklemenize gerek yok, ama 20. günde planladığınız riskli refactor'u da göndermemelisiniz. O üçüncü taraf çağrısına bir timeout ve bir fallback ekler, atladığınız migration kontrolünü yazar ve refactor'u bir sonraki aya taşırsınız.

Ders, hataların kötü olduğu değil. Hatalar beklenir ve zaten fiyatlandırılmıştır. Sayının size verdiği şey, "şu anda bu riski almayı göze alabilir miyiz?" sorusuna sakin ve ortak bir cevaptır; odada tek kişi siz olsanız bile.

Bu ayın sonunda bütçenin ne kadarının kaldığını ve bir sonraki ay için neyi değiştireceğinizi yazın. Kayıt tek satır bile olsa, bir sonraki kararınızı aynı varsayımlarla vermeyeceksiniz. Bu kayıt, yalnızca tek kişilik projeler için değil, büyüyen her ekip için de aynı işi görür.

Bir SLO'yu işe yaramaz kılan üç hata var:

Kullanıcının hissettiğini değil, kolay ölçülebileni ölçmek. CPU kullanımı bir SLI değildir. Kullanıcılar CPU'nun %40'ta olmasını umursamaz. Sayfanın yüklenmesini umursarlar.

Hedefi hırstan koymak. "Beş dokuz istiyoruz" ciddi görünür ama veritabanınız küçük bir VM üzerinde tek bir instance ise hiçbir anlam ifade etmez. SLO'yu gözlenen gerçeklikten koyun, sonra sistemi iyileştirin, sonra sayıyı sıkılaştırın.

Bütçeyi hiç kullanmamak. Her ayı bütçenin %98'i kalmış halde bitiriyorsanız, ya çok yavaş gönderiyorsunuzdur ya da hedef çok gevşektir. Kullanılmayan bütçe, boşa giden risk alma kapasitesidir.

Bir SLO'nun altına ilk olarak neyi koyardınız? Kırıldığında kullanıcıların fark edeceği tek bir endpoint seçin. SLI'yı sade bir dille yazın, hedefi geçen ay teslim ettiğinizin 0.5 puan altına koyun ve 30 gün sonra tekrar kontrol edin. Bu konuda sıkı bir pratik istiyorsanız, kendi uygulamalarınız için küçük bir uptime ve gecikme panosu iyi bir hafta sonu işidir. Şu an hangi servisinize en az güveniyorsunuz?