Başlıca SRE ilkeleri ve uygulamaları: verimli döngüler
Bir anlamda "yaptığınız şey sizsiniz" olduğu gerçekten doğruysa, bu modülün kalbine geldik demektir. Bu ünitede, genellikle SRE uygulamasının temeli olarak kabul edilen iki uygulamaya göz atacağız. Her ikisi de "verimli döngüler" oluşturmanın önemli olduğu ilkesinden kaynaklanır. Bu bağlamdaki verimli döngüler, bir kuruluşta geri bildirim döngüleri oluşturarak kuruluşun sürekli olarak daha iyi duruma gelebilmesine yardımcı olan uygulamalardır. Tam olarak bu iki uygulamayla ilgili tüm izleme modüllerimiz var, bu nedenle yalnızca burada her birine genel bir bakışla yüzey kayması yapacağız.
Verimli döngü 1: SLI'lar ve SLO'lar
Bu modülün önceki bölümlerinde "uygun güvenilirlik düzeyine" doğru çalışma konusundaki noktamızı vurgulayacağız. Bu bölüm, bu kavramın tam olarak karşılandığı yerdir.
Üretime getirmeyi planladığınız yeni bir hizmetiniz olduğunu varsayalım (inşa edilmiş olan veya hala planlama sürecinde olan bir hizmet). Bu sürecin bir parçası olarak, istenen güvenilirlik hakkında bazı kararlar almak önemlidir. Kodun tamamını kendiniz yazmıyorsanız, bu kararlar, bunu yapan geliştiricilerle işbirliği içinde alınır (ve bu nokta çok önemlidir).
İlk olarak, hizmetin sistem durumunun göstergesi olarak ne kullanmalıyız (Hizmet Düzeyi Göstergesi veya SLI) vermemiz gerekir? Bu soruyu sormanın bir diğer yolu da "Ne zaman iyi çalıştığını nasıl anlıyabilirsiniz?". SLI'yi izlemenin birçok yolu vardır ve bazılarını daha sonra ayrıntılı olarak inceleyeceğiz. Ancak bu göstergeler genellikle şunlardır:
- Başarı ve başarısızlık ölçüleri karşılaştırması. Hizmet belirli bir süre için bir işlemi başarıyla tamamlıyor mu?
- Zamanlama ölçüleri. Belirli bir zaman eşiği içinde bir yanıt döndürd mü?
- Aktarım hızı ölçüleri. Belirli miktarda veriyi işledik mi?
Ya da tüm bu ölçülerin bir bileşimi.
Basit bir örnek vermek gerekirse, hizmetimiz için bir SLI'nın hizmetin ne sıklıkta başarı döndürdüğü olabilir. Bu bir HTTP 200 koduyla gösterilir (500 veya başka herhangi bir kod yerine).
Artık hizmetin nasıl olduğunu gösteren net bir göstergemiz olduğuna göre. Ondan ne tür bir güvenilirlik beklediğimiz veya istediğimize karar vermek istiyoruz. Örneğin, bir günlük bir süre boyunca hizmetten %20 hata oranı görmeyi bekliyor musunuz? Burada yuvarlak ve büyük sayılar kullanıyoruz çünkü başlangıçta bunları gerekçelendirmek kolaydır. Sonraki modüllerde, bunun gibi deyimlerin karmaşıklığını ve duyarlığını artıracağız ("bu hata oranını hangi kullanıcılar görüyor? Bazılarını mı? çoğu mu?" gibi). Hizmetin geliştiricisiyle birlikte çalışarak oluşturulan bu beklendi bir Hizmet Düzeyi Hedefidir (SLO).
SLO'nun doğru ölçülebilen ve izleme sisteminizde gösterilebilen bir şey olması gerekir. Hizmetin güvenilirliği için hedef, iyi anlaşılmış bir hedef olması amaçlanmıştır. Yeterince iyi olan sayı nedir? “Tamam, son bir iki haftadır hizmetin iyi çalıştığını düşünüyorum, ama söylemesi zor tabii” gibi bir yaklaşım buna uymaz. Hizmet SLO'sunu karşılıyor veya karşılamıyordur, verilerin net olması gerekir. SLO'sunu karşılamıyorsa (özellikle de belirli bir süredir bu durum tekrarlanıyorsa), o zaman bir şeyler yanlıştır ve düzeltilmesi gerekir.
Hata bütçeleri
Bir hizmet SLO'suna uymazsa kuruluşun eyleme geçebileceğini anlayabiliriz. Ancak SRE, SLO'nun karşılandığı veya aşıldığı durumlar için bu kavramın tamamını bir adım ileri götürür. Bazı kuruluşlar SLO'ları kullanarak "hata bütçeleri" olarak adlandırdıkları şeyi oluştururlar.
Bu fikri ortaya koymak için, daha önce üzerinde durduğunuz örnek hizmeti ve onun %80 başarı SLO'sunu kullanalım (bunu "zamanın %80'inde çalışır durumda olması" olarak düşünün). %80 çalışma süresi SLO'suyla, hizmetimizin zamanın %80'inde çalıştır durumda olması gerektiğini beyan ettik. Peki kalan %20 ne olacak? Kalan %20'lik sürede hizmetimizin kapanmasını gerçekten "önemsemiyoruz" çünkü bu fazladan %20'nin bizim için hizmet hedefi olarak önemli olmadığına karar vermiştik.
Söz konusu süre boyunca ne olduğunu önemsemiyorsak, bu hizmetle ne yapabiliriz? Kesinlikle yapabileceğimiz bir şey, çalışan hizmeti yükselterek, belki bazı özellikler ekleyen yeni bir sürüm çıkararak hizmete müdahale etmektir. Bu yeni sürüm çalışıyorsa ve kapalı kalma süresini uzatmıyorsa, nefis olur. Bu yeni sürüm hizmetin daha az kararlı olmasını sağlarsa ve hata ayıklanırken %10 daha fazla hata döndürürse, yine de sorun olmaz. İzin verilen güvenilmezlik için belirlediğimiz bütçeyi aşmış değiliz.
Hata bütçesi, hizmetin potansiyel mükemmel güvenilirliği ile istenen güvenilirliği arasındaki farktır (%100 - %80 = %20). Bu durumda, hata bütçesi bize %20 güvensizliğe %20 oranında bir fon sağlar ve burada "hala belirli olduğu için çalışır durumda olup olmaması umrunda değildir". Bu %20'lik zamanı istediğimiz şekilde (belki de daha fazla sürümle) diğer bütçeler gibi tükenene kadar harcayabiliriz.
Hata bütçeleri bazı kuruluşlar tarafından, SLO'nuzu karşılayamadığınız daha az huzurlu bir durum için de kullanılabilir. Bu durumda, "eyleme geçmekten" biraz daha sıkı bir şey yapmayı seçebilirsiniz. Diyelim ki hizmetimizde bazı sorunlar vardı ve daha önce seçtiğimiz SLI tarafından gösterildiği gibi zamanın yalnızca %60'ında çalışıyordu. Hedefimize (SLO) ulaşamadık. Hizmetimiz hata bütçesinin tümünü kullandı. Kuruluş planlanan bir sürümü geri çekebilir çünkü bu noktada sisteme müdahale etmenin güvenilirlik durumunu daha da olumsuz etkileme olasılığının yüksek olduğunu bilir. Hata bütçeleri genellikle belirli bir süre için hesaplanır; bir ay, çeyrek, vb. Sıralı olarak hizmet güvenilirliğinin artırılması durumunda bütçe geri döner.
Bu geçitli sürümler sırasında kuruluş, bazı mühendislik kaynaklarını özellik geliştirmeden güvenilirlik çalışmalarına kadar uzaklaştırmayı seçebilir. Hizmetin SLO'sunu dağıtmasına neden olan sorunların kaynağını ortaya çıkarma ve iyileştirmeye yardımcı olmak amacıyla.
Hata bütçelerinden söz ederken "bazı kuruluşlar" dememizin nedeni, özellikle de sürümleri durdurmak için kullanıldığında, bunun hayata geçirilme şeklinin belirli bir kurumsal içeriden satın alma gerektirmesidir. Bir yayın kararıyla karşı karşıya kalındığında, hizmetin bugüne kadarki güvenilirliği yeterli değilse kuruluşun yayını geri almaya istekli olması gerekir. Bu karar, tüm kuruluşların vermek istediği bir karar değildir. Bu karar, tükenmiş bir hata bütçesine tek olası yanıt değildir, ancak en çok konuşulan karardır.
Ayrı bir modülde SLI'ler, SLO'lar ve hata bütçeleri hakkında çok daha ayrıntılı bir şekilde konuşacağız. Ancak bu uygulamaların verimli döngü yönünü vurgulamak faydalı olabilir. Teoride, bir kuruluşun bir hizmetin güvenilirliğini tanımlaması, iletişim kurması ve üzerinde işlem yapması için bir yol sağlar. Bunu herkesin daha iyi güvenilirlik için çalışmasını sağlayan bir şekilde yaparken. Bu geri bildirim döngüsü son derece önemli olabilir.
Verimli döngü 2: suçlama yapılmayan otopsiler
Postmortem (önemli, genellikle istenmeyen bir olayın geçmişe dönük analizi) fikri, site güvenilirliği mühendisliğine bile özgü değildir. Operasyonlar dünyasında bile seyrek görülen bir işlem sayılmaz. Ayırt edici olmaya yaklaşabilecek tek nokta SRE’nin bu otopsileri “suçlama yapılmadan” gerçekleştirme yönündeki ısrarı olabilir. Belirli kişilerin eylemlerine değil, olayı yaratan sürecin veya teknolojinin başarısızlığına odaklanmaları gerekir. “Yürürlüğe koyduğumuz süreç X kişisinin başarısızlığa yol açan işlemi yapmasına nasıl izin verdi? O kişiye hangi bilgiler sağlanmadı veya hatta o sırada yanlış sonuca varmasına yol açan belirgin neden neydi? Böyle yıkıcı bir hata yaşanmaması için hangi korumaların yerinde olması gerekirdi?" Bu sorular, suçsuz bir otopside sorulan sorulardır.
Bu soruların mahiyeti ve yönü çok önemlidir. Bu sistemlerin veya süreçlerin iyi niyetle kullanılması kesintiye neden olan bireyleri cezalandırmanın yollarını değil, sistemleri veya süreçleri iyileştirmenin yollarını arıyoruz. “İnsanları işten çıkararak güvenilir olamazsınız” sözünü unutmamak önemlidir. Deneyimlerimize göre, bir üretim olayı olduğunda (birkaç istisna dışında) bir kişiyi kovan bir kuruluş bu olaylardan ders çıkarmaz. Bunun yerine, tek bir bireyle kalırlar, köşede sallarlar, herhangi bir değişiklik yapmaktan korkarlar.
Ama kuruluşta iyi işleyen bir otopsi süreci verimli bir döngü oluşturur. Kuruluşun kesintilerden ders çıkararak sistemlerini sürekli geliştirmesine olanak tanır (uygun analiz ve izleme işlemleri yapılır).
Kuruluş tarafından öğrenme ve geliştirme fırsatları olarak benimsenen hata ve hatalarla bu ilişki, site güvenilirliği mühendisliğinin temel ilkesidir. Bir diğer ilke de, bu fırsatları kullanmak ve kuruluşu daha yüksek güvenilirliğe yönlendirmek için verimli döngülerin oluşturulmasıdır.
Şimdi bir sonraki ünitemizde SRE'nin insan tarafını temel alan diğer ilke ve uygulamaları inceleyelim.