Site reliability engineering nedir? Temel kavramlar

Peki site reliability engineering nedir? Üretim sistemlerini manuel operasyon yerine yazılım mühendisliğiyle işletme pratiğidir. Bir SRE ekibi sayısal bir güvenilirlik hedefi koyar, sistemi bu hedefe göre ölçer ve servisi ayakta tutan tekrarlayan işleri otomatiğe bağlar. Gecenin üçünde her ay aynı disk uyarısı yüzünden telefonunuz çalıyorsa, SRE'nin ortadan kaldırmak için var olduğu sorun tam olarak budur.

Google bu terimi 2003 civarında kullanmaya başladı. Bugün fikir Google'ın çok ötesinde, 20 kişilik girişimlerden bankalara kadar birçok yerde uygulanıyor. Aralarındaki fark ölçek; temel mekanik aynı kalıyor.

Bir site reliability engineer gerçekte ne yapar?

Google'ın SRE ekibini kuran Ben Treynor Sloss, Google SRE kitabının giriş bölümünde bunu şöyle özetliyor: SRE, bir yazılım mühendisinden bir operasyon ekibi tasarlamasını istediğinizde ortaya çıkan şeydir. İş, kodla yapılan operasyon işidir.

Normal bir haftada dört iş vardır. Bir servisin neyi "çalışıyor" sayacağını tanımlarsınız. Sorunu gösterecek izlemeyi kurarsınız. Bir şey bozulduğunda müdahale edersiniz. Ve bir sonraki kişinin aynı şey yüzünden çağrılmaması için düzeltmeyi yazarsınız.

İki örnek bunu somutlaştırır. Her perşembe elle yayın yapan bir ekip, otomatik geri almayı içeren bir pipeline kurar. Bir sızıntılı servisi her gece yeniden başlatan ekip ise sızıntının kendisini bulur. İkisi de tekrarlayan bir angarya işini tek seferlik bir projeye çevirir; asıl amaç budur.

Dördüncü kısmı çoğu ekip atlar. Yalnızca olaylara müdahale eden bir SRE, unvanı değişmiş bir operasyon mühendisidir. Rolü farklı kılan mühendislik yarısıdır.

SRE, DevOps'tan nasıl ayrılır?

DevOps bir kültürdür: geliştiriciler ve operasyon ekipleri neyin nasıl yayınlanıp çalıştırıldığı konusunda ortak sorumluluk alır. Ekipler arasındaki duvarın bir sorun olduğunu söyler. Ancak ne kadar kesintinin kabul edilebilir olduğunu ya da ne zaman yayını durdurmanız gerektiğini söylemez.

SRE ise sayıları getirir: servis seviyesi hedefleri (SLO), hata bütçeleri ve manuel işe bir üst sınır. Google'ın kendi çerçevesine göre SRE, DevOps fikirlerini uygulamanın somut bir yoludur.

"Hangisi daha iyi?" tartışmasını bırakın. 8 kişilik bir ekibiniz varsa ikisinden de ödünç alırsınız. Asıl soru, ekibinizin belirli bir servisin ne kadar güvenilir olması gerektiğini tek cümleyle yanıtlayıp yanıtlayamadığıdır.

SLI, SLO ve SLA nedir, neden önemlidirler?

SRE'de üç kısaltma çoğu işi taşır ve insanlar bunları sürekli karıştırır.

• SLI (servis seviyesi göstergesi): Bir ölçüm. Örneğin, HTTP isteklerinin 300 ms altında 5xx dışı bir yanıt dönen payı.

• SLO (servis seviyesi hedefi): Bu ölçüm için hedef. Örneğin, kayan 28 günlük pencerede isteklerin %99.9'unun başarılı olması.

• SLA (servis seviyesi anlaşması): Hedef tutturulamadığında sonuç doğuran sözleşme, genellikle geri ödeme. SLA'nız SLO'nuzdan daha gevşek olmalı.

Bunun önemi şu: "Site hızlı ve güvenilir olmalı" cümlesi test edilemez. "Ödeme isteklerinin %99.9'u 500 ms altında başarılı olmalı" gibi bir hedef ise test edilebilir ve tartışmaları bitirmenin bir yolunu verir.

Servis başına iki üç SLI ile başlayın. Daha fazlası olursa kimse hatırlamaz.

Her SLI için ölçüm kaynağını da yazın. Bir SLI'ı hesaplamak için hangi log, metrik ya da sentetik kontrolün kullanılacağı belli değilse, o SLI henüz bir hedef değil, bir dileğtir. Kaynağı belirlemek genellikle hedefi belirlemekten daha çok zaman alır ve bu zamanı harcamak değer katar.

Kullanıcının hissedebileceği SLI'lar seçin. CPU kullanımı bir sebeptir, belirti değil. Başarısız ödemeler, yavaş sayfa yüklemeleri ve eski veriler ise müşterinin fark ettiği şeylerdir. Bir SLI'ın kullanıcıya bir şey ifade edip etmediğini sormanın basit bir yolu, o metrik yükseldiğinde bir destek talebinin gelip gelmediğine bakmaktır.

Hata bütçesi (error budget) nasıl çalışır?

Hata bütçesi, SLO'nuzun izin verdiği güvenilirsizlik payıdır. Basitçe 1 eksi SLO'dur. %99.9'luk bir erişilebilirlik hedefi %0.1 bırakır; bu da 30 günlük bir ayda yaklaşık 43 dakikalık kesintiye denk gelir.

Aritmetiğin tamamı bu fikir olduğu için, küçük bir hesabı kod olarak yazalım:

slo = 0.999
pencere_dakika = 30 * 24 * 60          # 43200
butce = (1 - slo) * pencere_dakika     # 43.2 dakika
harcanan = 31                          # şimdiye kadarki kötü servis dakikası
print(f"{butce - harcanan:.1f} dakika kaldı")  # 12.2 dakika kaldı

Bütçe kaldığı sürece ekip hızlı yayın yapar. Bittiğinde özellik yayınları durur ve iş güvenilirliğe kayar. SRE Workbook'taki hata bütçesi politikası örneği, bir ekibin bu kuralı nasıl yazılı hale getirdiğini gösteriyor.

Amaç ceza değil. Geliştiricilerin yayın yapmak istediği, operasyon ekibinin ise istikrar istediği eski kavgayı, iki tarafın da okuyabildiği ortak bir sayıyla değiştirir. Ancak liderlik, duraklatmaya önceden uymayı kabul ederse işe yarar. Her çeyrek üzerine yazılan bir bütçe politikası sadece süs olur.

Neden %50 toil kuralı var?

Toil, servisle birlikte büyüyen, geride kalıcı bir şey bırakmayan manuel ve tekrarlayan iştir. Takılmış bir işçiyi elle yeniden başlatmak toil'dir. Onu otomatik yeniden başlatan sağlık kontrolünü yazmak ise mühendisliktir.

Google'ın SRE organizasyonu, toil'i ortadan kaldırma bölümünde anlatıldığı gibi, her mühendisin zamanının %50'sinin altında toil tutmayı hedefler. Kalan zaman, gelecekteki toil'i azaltan ya da özellik ekleyen projelere gider. Gerekçe açık: Kimse durdurmazsa toil, herkesin zamanının %100'ünü dolduracak kadar genişler.

Ekibe sorabileceğiniz basit bir soru da var: Geçen hafta en çok zamanınızı alan üç iş neydi ve bunların kaçı bir daha olmayacak şekilde kapatılabilirdi? Bu soru genellikle en büyük toil kaynağını bir günde ortaya çıkarır.

%50'yi hedef değil, üst sınır olarak görün. Olgun bir servis üzerinde sağlıklı bir ekip bunun çok altında çalışır. Bir çeyrek boyunca bunun üstündeyseniz SRE yapmıyorsunuz, bir operasyon kuyruğu işletiyorsunuz demektir.

Başlamanın basit bir yolu var: İki hafta boyunca her bileti ve her çağrıyı toil ya da proje olarak etiketleyin. Sonra toil'i saate göre sıralayın. İlk üç madde otomasyon listenizdir.

Suçlamasız (blameless) olay sonrası incelemeler neyi değiştirir?

Bir şey bozulduğunda olay sonrası inceleme, kimin hata yaptığını değil, sistemin bir insanın bu hatayı yapmasına nasıl izin verdiğini sorar. Suçlama insanlara bilgiyi saklamayı öğretir. Suçlamasız inceleme ise yazmayı öğretir.

İyi bir olay sonrası raporu kısa olur ve dört bölümden oluşur: zaman çizelgesi, katkıda bulunan nedenler, neyin iyi gittiği ve sahipleri ile tarihleriyle eylem maddeleri. Sahipsiz eylem maddeleri birer dileğe dönüşür.

Pratikte bu, bir incelemenin "kim yaptı?" sorusuyla değil, "bu adımı atmak neden mantıklı görünmüştü?" sorusuyla açılması demektir. Cevap çoğu zaman eksik bir uyarının ya da belirsiz bir runbook'un olduğunu gösterir ve düzeltme de tam orada bulunur.

Değerin çoğu takipten gelir. Açık eylem maddelerini ayda bir gözden geçirin. Aynı neden altı ayda iki kez çıkarsa, belge ne derse desin ilk olay sonrası raporu başarısız olmuştur.

Bir SRE ekibinin önce hangi araçlara ihtiyacı var?

Çok fazla değil. Önce sinyallerle başlayın, sonra çağrı nöbeti ve otomasyonu ekleyin.

1. Metrikler ve panolar. SLI'larınızı hesaplamaya yetecek kadar. Grafana ve Prometheus yaygın bir açık kaynak ikilisi; Datadog ve New Relic ise barındırılan yol.

2. SLO'ya bağlı uyarılar. Tek bir sunucu sıçradığında değil, hata bütçesi hızla eridiğinde uyarın. Daha az çağrı, daha iyi çağrı.

3. Özellik bayrakları ve kademeli yayın. Kabaca, kesintilerin çoğu bir değişiklikten sonra gelir; bu yüzden en ucuz güvenilirlik kazancı değişiklikleri geri alınabilir yapmaktır. LaunchDarkly ve Statsig bunu kapsar.

4. Her uyarı için yazılı bir runbook. Bir uyarının runbook'u yoksa ya bir tane yazın ya da uyarıyı silin.

Araç seçimi genellikle ekibin mevcut yığınına bağlıdır. Zaten Prometheus kullanan bir ekip için yeni bir ajan kurmak yerine mevcut metriklerden SLI hesaplamak çoğu zaman daha hızlıdır. Kurumsal bir platforma geçmeden önce, hangi SLI'ları gerçekten izlediğinizi ve bu izlemenin bir haftada kaç uyarı ürettiğini not edin.

Önce satın alın ya da inşa edin, bu sırayla. SLO'su olmadan bir araç satın alıp başlayan ekipler, belirsiz bir amaç için güzel panolarla kalır.

Tanımadığınız kodu okumak SRE'nin neresinde?

İş ilanlarına kimsenin koymadığı kısım bu. Bir olay sırasında SRE çoğu zaman yazmadığı bir servisi, aylardır açmadığı bir depoda anlamak zorunda kalır. Soru nadiren soyut olur. "Bu yeniden deneme döngüsü nerede ve zaman aşımında ne yapıyor?" gibi somut bir sorudur.

Bunu zaten yaptınız: grep, blame, sonra dosyaya en son dokunan kişiye mesaj. 80K satırlık bir depoda bu işe yarar. Altı ekibin sahip olduğu on iki serviste ise bir olayın ilk 20 dakikasını yer ve o dakikalar bütçeden düşer.

İşte burada, reponuz hakkındaki soruları yanıtlayan bir kod arama aracı değerini kazanır. Örneğin bir servisin zaman aşımlarını nerede ayarladığını ve hangi çağıranların buna bağlı olduğunu sorabilirsiniz. Araç olayı çözmez. Harekete geçmeden önce okumaya harcanan süreyi kısaltır ve bu süre ölçülebilir.

Ekibiniz için SRE fazla mı, nasıl başlanır?

Tek bir servisiniz, birkaç mühendisiniz ve ara sıra kötü bir saate katlanan kullanıcılarınız varsa ayrı bir SRE ekibine gerek yok. İhtiyacınız olan şey bir SLO, makul bir uyarı ve çağrı nöbetini üstlenen birinin olması.

Şu üçünden biri doğru olduğunda düşünmeye başlayın: kesintiler gerçek gelir kaybettiriyor, çağrı nöbeti insanları tüketiyor ya da geliştiriciler ad hoc operasyon talepleri yüzünden yavaşlıyor. Birçok şirket bir ya da iki mühendisi yarı zamanlı SRE yaparak başlıyor ve sonucu izliyor.

Bu kararı verirken işe yarayan bir kontrol listesi de var: Son üç ayda kaç kez gece çağrısı geldi, bunların kaçı aynı nedenden kaynaklandı ve kaç yayın geri alınmak zorunda kaldı? Bu üç sayı, SRE'nin hangi kısmına ihtiyacınız olduğunu genellikle açıkça gösterir.

Sık yapılan bir hata, operasyon ekibini işleyişini değiştirmeden "SRE" olarak yeniden adlandırmaktır. Ekip hâlâ biletlere, elle yapılan yayınlara sahipse ve hata bütçesi yoksa değişen tek şey unvandır.

Gelecek hafta nasıl başlanır

Bir yeniden yapılandırmaya ihtiyacınız yok. Kullanıcıya dönük, en çok canınızı yakan servisi seçin ve beş şey yapın.

1. Bu servis için bir SLI ve bir SLO yazın. Sade tutun.

2. Hata bütçesini hesaplayın ve tüm ekibin gördüğü bir panoya koyun.

3. İki hafta boyunca toil'i izleyin ve otomatikleştirmek için en üstteki işi seçin.

4. Bir sonraki olayınız için sahipli eylem maddeleriyle suçlamasız bir olay sonrası incelemesi yapın.

5. Bütçe sıfıra indiğinde ne olacağını yazılı olarak kabul edin.

Bir ay sonra ekip yayın yapıp yapmama konusunda daha az, sayıların ne dediği konusunda daha çok tartışıyorsa iş yürüyor demektir. Hata bütçesi hiç kıpırdamıyorsa SLO çok gevşektir; sıkılaştırın.