Site reliability engineering nedir? Yan proje rehberi

Site reliability engineering nedir? Kısaca, operasyon işini bir yazılım problemi gibi ele almaktır: ölçülebilir bir güvenilirlik hedefi koyarsınız, bu hedefi ne sıklıkla kaçırdığınızı takip edersiniz ve bu sayı yeni özellik mi yayınlayacağınıza yoksa hataları mı düzelteceğinize karar verir. Terimi Google ortaya attı, ama fikir her ölçekte işe yarıyor. Tek uygulaması ve birkaç kullanıcısı olan bir geliştirici için bu, önceden ne kadar kesintiyi kabul edeceğinize karar vermek demek.

Sorun şu ki: çoğu yan projede böyle bir sayı yok. Biri e-posta atana kadar "çalışıyor" sanılırlar. Bu rehber SRE'yi sade bir dille anlatıyor, sonra tek bir kişinin hafta sonu kurabileceği bir boyuta indiriyor.

Peki site reliability engineering aslında ne?

Kısa tanım Google'ın SRE kitabından geliyor: SRE, bir yazılım mühendisinden bir operasyon ekibi tasarlamasını istediğinizde ortaya çıkan şeydir. İnsanların sunucuları elle yeniden başlatması yerine bunu yapan kodu yazarsınız ve sonuçları ölçersiniz.

Üç fikir bu işin büyük kısmını taşıyor. Güvenilirlik bir hissiyat değil, hedefi olan bir özelliktir. Tekrarlayan elle iş (kitap buna "toil" diyor) otomatikleştirilmesi gereken bir hatadır. Arıza da beklenen bir şeydir, bu yüzden suçlu aramak yerine ondan nasıl öğreneceğinizi planlarsınız.

DevOps ile SRE çok örtüşür. Pratik fark şu: DevOps kodu birlikte yayınlayıp çalıştırma kültürüdür, SRE ise bu tartışmayı sayılarla yapmanızı sağlayan somut araçlar verir. Sayıları kullanmak için bir tarafı seçmeniz gerekmez.

SLI, SLO, SLA: üç kısaltma, her biri tek bir fikir

SLI (service level indicator) ölçtüğünüz şeydir. Bir web uygulaması için genelde başarılı isteklerin oranı ya da 300 ms altında yanıt veren isteklerin oranıdır. Bir ya da iki tane seçin, on iki tane değil.

SLO (service level objective) bu ölçüm üzerine koyduğunuz hedeftir, örneğin "30 gün boyunca isteklerin %99.9'u başarılı olsun". Bu içeridedir, kendinize verdiğiniz bir söz gibidir.

SLA (service level agreement) ise bir müşteriyle yapılan sözleşmedir ve genelde hedef tutturulamazsa geri ödemeyle birlikte gelir. Uptime için kimse size para ödemiyorsa henüz bir SLA'nız yok. Fiyatlandırma sayfanızın metnine yanlışlıkla bir tane yazmamalısınız.

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

Hata bütçesi basitçe 100% eksi SLO'dur. 30 günlük %99.9'luk bir hedef, yaklaşık 43 dakikalık izin verilen arıza bırakır. Riskli yayınlar, geçişler ve deneyler için harcayabileceğiniz bütçe budur.

Asıl değerli olan, buna bağlı kural. Bütçe varken yayın yaparsınız. Bütçe bittiğinde özellik yayınlamayı durdurur, bütçe yenilenene kadar güvenilirliğe odaklanırsınız. Kitabın risk bölümü bunu, "hızlı ilerle" ile "bir şeyi bozma" arasındaki tartışmayı pazarlık yerine ortak bir sayıyla çözmenin yolu olarak anlatır.

Bir noktayı tekrarlamakta fayda var: %100 neredeyse hiçbir zaman doğru hedef değildir. Sorunlu mobil ağlardaki kullanıcılar %99.99 ile %99.9'u ayırt edemez ve her ek "dokuz" bir öncekinden çok daha pahalıya gelir. Mükemmel bir hedef değil, ama işe yarayan bir hedef.

Somut bir örnek: ayda iki büyük yayın yapıyorsunuz ve bir yayın 15 dakikalık bir kesintiye yol açtı. Bu durumda aylık bütçenin üçte birini tek bir değişiklik yemiş olur. Bir sonraki hafta yeni özellik beklemek yerine yayın sıklığını düşürmek ya da yayın öncesi kontrolleri sıkılaştırmak, bu sayının söylediği doğru karardır.

Somut bir iş akışı için, SLO uygulaması üzerine SRE çalışma kitabı en pratik bölüm ve kısa.

Bir SRE mühendisi gün boyunca gerçekte ne yapar?

Büyük bir şirkette bir SRE zamanını nöbet (on-call), olay müdahalesi, kapasite planlaması ve otomasyon işleri arasında böler. Google'ın kitabı, operasyonel yükü bir mühendisin zamanının yaklaşık yarısıyla sınırlamayı öneriyor ki geri kalanı mühendislik işine gitsin. Bu sınır bir lüks değil, bir tasarım kısıtıdır.

Tekrarlayan iş şöyle görünür:

• SLO'ları ürün ekipleriyle belirlemek ve her küçük dalgalanmada değil, bütçe tüketim hızında uyarı kurmak

• Nöbet rotasyonlarını yürütmek ve gece 3'teki çağrının bir kontrol listesi olması için runbook yazmak

• Olay müdahalesine liderlik etmek, sonra suçlamasız (blameless) bir postmortem yazmak

• Birkaç kereden fazla elle yapılan her işi otomatikleştirmek

• Üretime çıkmadan önce yayınları güvenilirlik riskleri açısından gözden geçirmek

Özellik bayrakları bu zihniyetin iyi bir örneği. Kötü bir yayını yeniden deploy etmeden saniyeler içinde kapatmanızı sağlar ve bu da bütçenizi korur. Bunun için barındırılan bir araca mı ihtiyacınız var, yoksa bir ortam değişkeni işinizi görür mü, bu kaç bayrağınız olduğuna bağlı. İlk birkaç bayrağa kadar ortam değişkeni yeterli olabilir.

Tek başına çalışıyorsanız SRE'ye ihtiyacınız var mı?

Bunu yapmak için üç neden, yapmamak için bir neden var.

Yapmak için nedenler şunlar: kendi projeniz er ya da geç sizi uyandıracak; yazılı bir hedef gereksiz mühendislikten sizi alıkoyar; ve birisi sizi işe alıp almayacağına ya da size güvenip güvenmeyeceğine karar verirken "bir SLO ile üretimi yönetiyorum" cümlesi iyi görünür. Yapmamak için neden ise şu: henüz hiç kullanıcınız yoksa, sahip olmadığınız bir sorun için pratik yapıyorsunuz demektir. Önce yapın, birisi projenize güvenmeye başlayınca ölçün.

Bu yüzden tam donanımı kurmayın. Hobi bir uygulama için ücretli bir çağrı servisi tutmayın, ciddi görünmek için Kubernetes kurmayın, 10 sayfalık bir olay şablonu yazmayın. Yalnızca on gerçek kullanıcınız varsa bile yapmaya değer: bir sağlık kontrolü, bir SLO ve bir şey bozulduğunda bakacağınız bir yer.

Yan proje için bir akşamlık SRE kurulumu

İşte 10 000 kullanıcıya kadar da iyi dayanan minimum kurulum. Bir akşam sürer. Denendi. Optimal değil. Yine de yapıyoruz, çünkü sıkıcıdır ve sıkıcı olan dayanır.

İlk olarak tek bir SLI seçin: 5xx dışında bir şey dönen HTTP isteklerinin oranı. İkinci olarak SLO'yu 30 günde %99.5 olarak belirleyin; bu yaklaşık 3.6 saatlik bütçe demek. Gevşek başlayın, sonra sıkılaştırın. Üçüncü olarak gerçek bir sağlık uç noktasına vuran harici bir uptime kontrolü ekleyin.

Sağlık uç noktası yalnızca sürecin ayakta olduğunu değil, gerçekten bozulan şeyleri kontrol etmelidir:

// GET /healthz
app.get("/healthz", async (req, res) => {
  try {
    await db.query("select 1");          // veritabanına erişilebiliyor mu
    await cache.ping();                  // önbelleğe erişilebiliyor mu
    res.status(200).json({ ok: true });
  } catch (err) {
    res.status(503).json({ ok: false });
  }
});

Dördüncü olarak uyarıları göreceğiniz bir yere gönderin: gelen kutusu yerine telefona push bildirimi. Beşinci olarak postmortems.md adında düz bir metin dosyası tutun ve her kesintiden sonra dört satır ekleyin: ne oldu, neden oldu, ne kadar sürdü, neyi değiştireceksiniz. Bu dosya, sahip olacağınız en az takdir edilen güvenilirlik aracıdır.

Kurulumdan sonra ilk bir ay boyunca hiçbir şeyi değiştirmeyin. Uyarıların ne sıklıkla geldiğini, sağlık kontrolünün gerçekten düştüğü anları ve SLO'nun hangi günlerde zorlandığını not edin. Bir aylık veriden sonra hedefi ya gevşetin ya da sıkılaştırın. Veri olmadan hedef değiştirmek, tahmin etmekten farksızdır ve kurulumun yararını sıfırlar.

Yapay zekâ araçları nerede yardımcı olur, nerede olmaz

Asistanlar operasyonun sıkıcı tarafında iyidir: sağlık kontrolünü yazmak, bir uptime monitörü için Terraform, bir runbook taslağı ya da 5xx oranını çıkarmak için log ayrıştıran bir betik. SLO'nuza karar vermekte ise kötüdür, çünkü bu kullanıcılarınızın neye tahammül edeceğine dair bir ürün kararıdır.

Bir olay sırasında dikkatli olun. Bir asistan makul görünen bir düzeltme önerebilir ve siz onu gece 2'de, okumadan üretime uygulayabilirsiniz. Stack trace'i açıklamak ya da olay sonrası postmortem taslağı için kullanın; geri alma (rollback) kararını uyanık bir insanda tutun.

Kod kalitesi kapıları da bu resmin parçası. Birçok kesinti, inceleme sırasında zararsız görünen bir değişikliğe kadar izlenir. CI'daki statik analiz tek başına güvenilirlik sağlamaz, ama bütçenize mal olmadan önce bir sınıf aptalca hatayı eler.

Kimsenin okuyacağı bir postmortem nasıl yazılır?

Kısa ve suçlamasız tutun. Suçlamasız, kimsenin sorumlu olmadığı anlamına gelmez. Hatanın hangi sistem tarafından mümkün kılındığını sorarsınız, kimin yaptığını değil. Tek başına bir ekipteyseniz bu sanıldığından önemlidir, çünkü insan kendini kötü hissedip yazmayı atlamak ister.

Dört başlık yeterli: ne oldu, neden oldu, kullanıcılar ne kadar etkilendi ve neler değişecek. Son başlık, gerçekten yapacağınız ve bir tarihi olan bir eylemi adlandırmalı. "Daha dikkatli olalım" bir eylem değildir. "Bir sonraki yayından önce geçişler için staging kontrolü ekle" bir eylemdir.

Bir yıl içinde bu dosya, zayıf noktalarınızın bir haritasına dönüşür. Aynı sebepten üç kesinti yaşandığında kural basit: aynı sebep ikinci kez çıkıyorsa otomatikleştirin. Sertifika yenileme izlemesini eklemek bir akşam sürdü ve bir daha tekrarlanmadı.

Bu dosyayı kimseyle paylaşmanız gerekmiyor. Ama üç ay sonra kendi yazdığınızı okuyup "bunu neden yapmadım?" diye sormak, çoğu zaman en değerli dersi verir. Ekibiniz yoksa, postmortem sizin için hem hafıza hem de hakem işi görür.

Her küçük dalgalanmada değil, yakma hızında uyarın

Yeni başlayanların sık yaptığı hata, tek bir istek başarısız olduğunda kendinize alarm vermektir. Bir hafta içinde kanalı susturursunuz. Daha iyi sinyal yakma hızıdır (burn rate): hata bütçesini, pencere sonunda bütçeyi tam tüketecek hıza kıyasla ne kadar hızlı harcadığınız.

Yan proje için işi kaba tutun. Son 10 dakikadaki hata oranı %5'in üzerindeyse push bildirimi, haftalık oran SLO'yu kaçırma yoluna girerse e-posta özeti gönderin. Bu size iki seviye verir: şimdi uyan ya da pazartesi bak. Daha karmaşık bir şey, kullanıcılar birinci seviyedeki sorunu fark etmeye başlayana kadar beklesin.

Yapmayı seven bir geliştirici için SRE iyi bir kariyer mi?

Bu, neyden keyif aldığınıza bağlı. SRE rolleri, UI yayınlamaktan çok sistemleri, arıza modlarını ve otomasyonu sevenlere uygun. Nöbet çağrısını sessizleştirmekten keyif alıyorsanız hoşunuza gider. Yeni özelliğinizi kullanıcıların tıklayıp görmesini istiyorsanız muhtemelen gitmez.

Bu yola genelde backend ya da altyapı işiyle girilir: bir servisin deploy'larını ve uyarılarını üstlenmeye başlarsınız, sonra güvenilirliğini de üstlenirsiniz. Taşınabilir beceriler: Linux temelleri, ağ, bir bulut sağlayıcısı, bir izleme yığını ve her şeyi yazıya dökme alışkanlığı. Yan projeler bunların hepsini kazanmak için uygun bir yer, çünkü tüm ekip sizsiniz.

Sıradaki ne inşa edilmeli?

Zaten çalıştırdığınız bir şeyi seçin, ücretsiz katmandaki bir uygulama bile olur. SLI'sini, SLO'sunu ve bütçe bittiğinde tam olarak yapacağınız eylemi yazın. Neyi durduracağınızı söyleyemiyorsanız o sayı sadece süs olur. Projelerinizden hangisinin, bir kullanıcı söylemeden önce kapalı olduğunu fark edeceğinizi düşünüyorsunuz?