Site Reliability Engineering (SRE) ve DevOps
Site Reliability Engineering (SRE)
Öncelikle bir “Site Reliability Engineering” (Site Güvenilirliği Mühendisliği) tanımı yaparsak, yazılım ürünlerinin tüm teknolojik kısımlarından sorumlu olan kişidir diyebiliriz. Wikipedia’da ise şöyle bir tanım mevcut: Yazılım mühendisliğinin belirli kısımlarının alınıp bunların altyapı ve operasyon problemlerini çözmek için kullanılmasıdır. Ana fikir, ölçeklenebilir ve yüksek güvenlikli yazılım sistemleri oluşturmaktır. IT Operasyonları ile Yazılımın kesiştiği noktada bulunur.
-Sre, yazılım mühendisliği deneyimini, sistem uzmanlığı (administration) ve ağ oluşturma (networking) yetkinlikleri ile birleştirmeye çalışır.
-Sre’ler kendilerini, ürünlerin performans ve güvenilirliğini arttırmaya adarlar.
-Sre, Google mühendislik departmanından “Benjamin Treynor”ın oluşturduğu bir kavramdır.
-Sre’de 3 önemli kısım göze çarpmaktadır:
Beceri grubu (skill set), Rol dağılımı ve Güvenilirliğin ölçülmesi.
Beceri Grubu: Sre’ler yazılım becerisi kadar sistem yönetimi ve ağ deneyimi konularında bilgi sahibidir.
Rol Dağılımı: Zamanın yarısı geleneksel operasyon görevlerine ayrılmıştır. (incident response vb gibi göreve hazır (on-call) durumlar) Diğer yarısı ise programlamaya, performansa, güvenilirliği arttırmaya ve otomasyona ayrılır.
Güvenilirliğin Ölçülmesi: Sre’ler anahtar olan bazı güvenilirlik metriklerini belirler ve ölçerler. Bunlar arasında servis seviyesindeki bazı görevler, anlaşmalar ve göstergeler bulunur.
Bu işlemler, Geliştirme takımı, IT Operasyonu ve Sre arasında bir koordinasyonu gerektirir. Yazılımcılar kodu yazar ve onu deploy etmeleri için IT operasyon departmanına gönderirler. Bu arada Sre’ler kodu düzenleyebilir, performansı arttırabilir ve hataları azaltabilirler. Son olarak IT operasyonu ise kodu deploy eder, sistem bakımını sağlar, plansız kesintiler ve olaylara karşılık verirler.
Sre:
-Sistemi 7/24 ayakta tutmayı.
-Olgulara çabuk tepki verip kolay ve ucuz bir şekilde çözmeyi.
-Yazılım geliştirme deneyimi olan mühendisleri işe almayı.
-Hizmet güvenilirliği konusunda sorumluluk almayı.
-Ürünlerin bir güvenilirlik standartına sahip olmasını.
-Takımlar ve projeler arası hareket edebilen bir yapıda olmayı.
gerektirir.
Riski Benimsemek
Hataların gerçekleşmesi olasıdır. Riskleri tamamen elimine etmek yerine riski benimseyip belirli bir süre aksamaların yaşanabileceğini kabul edebiliriz. (makul ölçüde ve tolere edilebilir şekilde)
Kırılma Noktalarını Elimine Etmek
Belirli arıza noktalarını (single point failure) elimine etmeye çalışabiliriz.
Kabullenebilir Verim Düşüşü
Kodu, servis hatalarını belirleyebilecek ve servise çabuk adapte olacak şekilde yazabiliriz. Bu şekilde kritik hizmetleri ayakta tutabiliriz.
DevOps Vs SRE
Genelleme yaparsak geliştiriciler kodu yazar ve operasyona devrederler. Operasyonla ilgili konuları ve süreçleri anlamazlar veya önemsemezler. (Burada olaya biraz yüzeysel bakıyoruz kızmayın :) Daha sık olarak özelliklerin yayınlanmasını isterler. IT ise operasyonla ilgilenir ancak onlarda gerçek anlamda ürünün ne olduğunu anlamaz ne yaptığıyla ilgilenmezler. Onlar daha az canlıya alıp kesintileri azaltmak isterler. SRE açısından bakarsak bu iki uç bir araya gelmeli ve bir köprü gibi davranarak hem ölçümler yapılmalı, riskler azaltılmalı hem de güvenilirlik arttırılarak daha sık yayın (release) yapılmalıdır.
DevOps farkına gelirsek DevOps, sorunları “geliştiricilerin” çözmesi için belirler. SRE’ler ise Production’daki sorunları bulur ve onu “kendileri” çözerler. DevOps production’a dokunmaz. SRE ise deploy etme ve değişiklikler yapma konusunda daha rahattır. DevOps genellikle geliştirme ile birlikte kalır. SRE ise geliştirme ve production takımları arasında hareket edebilir. DevOps ürünleri prod’a daha çabuk getirmeyi amaçlarken SRE, Production çevresini yönetir.
DevOps’un → Geliştirme → Test → Deploy → Prod’a giden bir yolu olduğunu düşünebiliriz.
SRE ise → Geliştirme ←> Test ←> Deploy ←> Prod kısımları arasında hareket edebilir.
SRE, iş birliği sağlar, izlemeyi konfigüre eder, otomasyon yazar ve güvenilirliği arttırmaya çalışır.
Takımlar Arası SRE Organizasyonu
Bir mühendis Sre görevlerine odaklanmalı, diğer mühendisler ise Sre
‘yi desteklemelidir. Takımlar oluşturabilir ve ya geliştirme takımlarıyla beraber çalışabilirler ya da onlar için güvenilirlik standartları oluşturabilirler. (Bu durum yazılım geliştirme, izleme, otomasyon, IT Operasyonları, sistem administration, sistem mühendisliği vb gibi departmanların hepsi için geçerli)
Takımın odağını oluşturmak önemlidir. Çünkü her şey Sre’nin odağına girebilir. Burada kademeli bir destek sistemi oluşturulabilir. Azdan çoğa doğru: 1-Özel destekler, 2-Proje bazlı yarı zamanlı destek, 3-Tam destek ve hazır görevler olarak bir şema oluşturabiliriz.
Servis Seviyesindeki Görevler (SLOs)
SLO’ları ayarlama, görevleri tanımlama ve ölçme olanağı sağlar.
Suçlamalardan Kaçınmak ve Analiz
Suçlamadan kaçınmak, mühendislerin açık bir şekilde sorunun nerede olduğunu belirlemesine olanak sağlar ve aynı problemin tekrar etmesine engel olur.
Olay Yönetimi (Incident Management)
Sre’ler tüm olayları takip eder ve daha yüksek bir güvenilirlik için onların gelişimini izler.
Tanımlar
Otomasyon: Otomasyon, insan müdehalesi gerektirmeden tekrar eden süreçlerin bir yazılım ile yönetilmesidir.
Araçlar (Tooling): Belirli bir hedefe ulaşmak için metodlar, süreçler ve yazılımlar oluşturmak demektir.
Ürün: Müşteri/Kullanıcı için kullanım talimatıyla yayınlanan yazılım.
Servis: Müşteri/Kullanıcı için belirli çıkarımlar yapan yazılım.
Deployment: Bir ürünü aktive etme süreci.
Acil Kurtarma: Sistemi beklenmedik olaylardan geri kazanma planı.
Benchmark: Karşılaştırma yapılabilen bir referans noktası.
Metrikler: Yapılan ölçümlerin sonuçları.
İzleme: Anormal durumlar için ürünün izlenmesi.
MTBF (Mean Time Between Failures): Arızalar arasındaki ortalama süre.
MTTR (Mean Time To Repair): Arızadan sonra bir servisi ya da ürünü onarana kadar geçen zaman.
Failure: Bir ürünün başarısız olması ya da hata vermesi.
Outage: Hataların bir arızaya yol açması ve bir servise ulaşamama durumu.
Postmortem: Arıza sonrası yapılan analiz ile olayın tartışılması, kök nedenin bulunması ve bir daha gerçekleşmemesi için yapılan planı içerir.
Risk: Bir ürünün hata verme/arızalanma olasılığının derecesi.
Reliability: Ürün ya da servislerin erişilebilir halde kalabilme derecesi.
Overloading: Çok fazla iş almak/yüklemek anlamında. Yorgunluğa yol açar.
Toil: Yorgunluk anlamında, sürekli çalışmaktan doğan tükenme durumu.
SLI-Servis Seviyesi Göstergesi (Service Level Indicator)
Biri ürün ya da hizmetin ölçülme parametreleridir.
SLO-Servis Seviyesi Görevi (Service Level Objective)
Ürünün kabul edilebilir kesinti zamanını tanımlar.
SLA-Servis Seviyesi Anlaşması (Service Level Agreement)
Ürünün erişilebilirlik seviyesi hakkında Müşteri/Kullanıcı ile yapılan anlaşmadır.
SLI, SLO’yu etkiler ve SLA’yı belirler.
Güvenilirlik → SLI → SLO → SLA
SLI-Servis Seviyesi Göstergesi
-Nümerik bir değerdir. (% gibi)
-SLI; gecikme, erişilebilirlik, üretilen iş, hata oranı vb gibi metrikleri ölçer.
-Metrikler belirli zaman aralıklarında toplanır.(ör: bir yıl)
-SLO’ların temelini oluşturular.
SLO-Servis Seviyesi Görevi
-Güvenilirlik hedeflerini gösterir.
-Ürün sahibi (Product Owners-Stake Holders) ile anlaşılan görevler.
-Metrikler belirli zaman aralıklarında toplanır.(ör: bir yıl)
-SLA’ların temelini oluşturular.
SLA-Servis Seviyesi Anlaşması
-Kabul edilebilir erişilebilirlik seviyesini gösterir. (ürün sahibi ya da müşteri açısından)
-SLO’lardan daha rahat olmalıdır. SLA devreye girmeden önce hata için bir boşluk oluşturmalıdır.
-Metrikler belirli zaman aralıklarında toplanır.(ör: bir yıl)
-SLA’lar belirli gereksinimler karşılanamadığında müşteriye garanti edilen erişilebilirlik durumunu gösterir. Resmi belge ve kontratlardır.
Güvenilirliği Ölçmek ve Riski Kabullenmek
DevOps’un Beş Ayağı:
-Hataları normal olarak kabul etmek
-Değişiklikleri aşamalı olarak uygulamak
-Her şeyi ölçmek
-Araçların ve Otomasyonun gücünden yararlanmak
-Organizasyonel siloları azaltmak
Güvenilirliği nasıl ölçebiliriz? : SLI’ler ile.
Neyi ölçeriz? : Herşeyi!
Nasıl ölçeriz? :
Uptime: Sistemin erişilebilir olma oranı.
Request Success Rate: Başarılı taleplerin başarısızlara olan oranı.
Latency: Gecikme ya da bekleme zamanı oranı.
Utilization: Değerlendirilen kaynak miktarı.
Hangi aralıklarla ölçeriz? : Günlük-Aylık-Yıllık
SLO’lara nasıl ulaşırız? : Olay yönetim süreci ile ve suçlamadan analiz ile
%99 iyi bir başarı oranı iken bu oranı %99.9, %99.99, %99.999 şeklinde arttırmaya çalışırız. %99.999 harika bir başarıdır!
Yedekli Sistem (Redundant Systems): Plansız kesinti olaylarından önce yedek alındığından emin olun. Tek hata noktalarını elimine etmeye çalışın.
Maliyeti düşünün.
Site Reliability Yaklaşımları
-DevOps
-Suçlama Olmayan Bir Kültür
-Olay Yönetimi: SRE’yi ürün ile ilgili uyarır.
-Olay Gözden Geçirmesi: Kök nedenleri bulmak açısından SRE’ye yardım eder.
-Problem Yönetimi: Sorunlar ile ilgili çözümlere olanak sağlar.
-Değişim Yönetimi: SRE’lere sisteme ya da deployment’a yapılan değişimleri takip etme olanağı sağlar.
-Otomasyon: İnsan hatasını önler, işlemeyi hızlandırır.
-İzleme: SRE’yi sorunlar ile ilgili uyarır. (ya da optimizasyon olanaklarıyla ile ilgili)
Yazılım Geliştirme Araçları: Ürünün gelişimini takip etme olanağı yanında hata ayıklama (bug tracking) ve ürün logları (backlogs) hakkında izleme sağlar.
Kaynak:
Kitap:
Sre Türkiye Twitter hesabı:
Sre Türkiye YouTube Kanalı:
