SRE kültürü ve mühendislik ilkeleri

1) SRE kültürü nedir

SRE kültürü, güvenilirliği yönetilebilir kılan bir dizi değer ve uygulamadır: SLO hedefleri - hata bütçesi - bilinçli değişim riskleri - hızlı stabilizasyon - olaylar üzerine eğitim.
Anahtar paradigma: hız ≠ güvenilirliğin düşmanı. Serbest bırakma hızı, riskler ölçüldüğünde ve otomatikleştirildiğinde mümkündür.

• Kullanıcı merkezli: Güvenilirliği kullanıcının gördüğü gibi gösterir (SLI/SLO).
• Otomasyon-ilk - herhangi bir tekrarlanabilir eylem - komut dosyası/politika/denetleyici.
• Suçsuz: Hatalar sistemiktir, nedenleri araştırırız, insanları değil.
• Veri odaklı: metriklere ve hata bütçelerine dayalı çözümler.
• Basitlik: basit, test edilebilir mekanizmalar> "sihirli" çözümler.

2) SRE Mühendislik Felsefesi

1. SLO/SLI ve hata bütçesi önceliklerin ve uyarmanın temelidir.
2. Olay - stabilizasyon - RCA - önce semptomlar, sonra nedenler.
3. El emeğinin azaltılması (toil), SRE zamanının %50 ≤ hedefidir, zamanla daha düşüktür.
4. Üretim hazırlığı - dış trafikten önce "üretim hazırlığı" gereklidir.
5. Basitlik ve izolasyon - daha az ilişki, daha fazla patlama yarıçapı kısıtlaması.
6. Varsayılan gözlemlenebilirlik - metrikler/günlükler/izler, SLO widget'ları, sentetikler.
7. Değişiklikler yönetilir - aşamalı teslimat, kanarya hesaplamaları, otomatik geri alma.
8. Tasarım gereği güvenlik - sırlar, erişim, denetim, minimum ayrıcalıklar.
9. Çalışma döngüleri - tatbikatlar, kaos oyunları, post-mortemler, retrospektifler.
10. FinOps farkındalığı - "dokuzların fiyatı", hizmet maliyeti, etkili SLO'lar.

3) Ritüeller ve süreçler

3. 1 Üretim Hazırlık İncelemesi (PRR)

• SLI/SLO, gösterge paneli ve uyarılar (hızlı/yavaş yanma).
• Health-endpoints'/healthz ','/readyz','/startupz '.
• Runbook/olayların playbook, sahibi/on-call, eskalasyon zinciri.
• Yedeklemeler/DR planı, kaynak limitleri, bütçe hesaplamaları.
• Hata tolerans testleri (özellik bayrakları, geri alma komut dosyaları).

3. 2 Haftalık SLO Brifingi

Hizmet hata bütçesinin durumu.
Haftalık olaylar, CAPA gelişmeleri.
Serbest bırakma riski: izin verilen/depozito ile sınırlı olduğunda (bütçe).

3. 3 Ücretsiz postmortem

Gerçekler ve zaman çizelgesi, yardımcı olan/engelleyen kullanıcı etkisi.
Sistemik nedenler (süreçler/araçlar), "suçlu'değil.
Sahipleri ve son tarihleri olan belirli CAPA'lar, şirket içinde tanıtım.

3. 4 Kaos ve Dreal Oyunları

Planlı hata enjeksiyonu (ağ, veritabanı, önbellek, düğümler) + hedef SLO.
"Oyun günü": stabilizasyon süresi, MTTR ölçümü, playbook ayarı.

4) Uyarı ve gürültü

• Yalnızca belirtiler konusunda uyarın: bozuk SLO veya kullanıcı yolu.
• Çoklu pencere, çoklu yanma: hızlı ve yavaş kanallar.
• Quorum/anti-flapping: 'for' gecikmeler, bakım sırasında bastırma.
• "CPU> %80'ile aşağı - bu tür sinyaller bir çağrı cihazına değil, gösterge panolarına.

• Uygulanabilir oranı %80 ≥.
• Medyan süre-ack ≤ 5 dakika (P1).
• Çağrı cihazı yorgunluğunun azaltılması: Mühendis başına haftada ≤ 1 gece sayfası.

5) Değişim yönetimi

Aşamalı teslimat: Kanarya - %10 - %25 - %50 - %100.
SLO sinyallerinde otomatik geri alma (hatalar/gecikme).
Global geri alma yerine özellik bayrakları ve kill-switch.
Riske göre politika değişikliği: hızlı şerit для düşük riskli; CAB - sadece yüksek riskli.

yaml steps:
- setWeight: 10
- analysis: { template: "slo-check" } # fail ⇒ rollback
- setWeight: 25
- analysis: { template: "slo-check" }

6) Zahmetlerin azaltılması (rutin el emeği)

Çalışma kaynaklarına örnekler: manuel deploi, yeniden başlatır, "erişim ver" biletleri, sıra temizleme.

• Tekrarlanabilir görev envanteri - otomasyon/self servis.
• KPI: % çalışma süresi, "otomatik adımlar/olay", "self servise dakikalar".
• Platform servis kataloğu (ad alanları, DB, kuyruklar, gösterge panoları, uyarılar).

7) Gözlemlenebilirlik ve SLO-ilk tasarım

Altın Sinyaller (gecikme, trafik, hatalar, doygunluk).
Her takımda SLO kartları: gol, pencere, bütçe, yanık uyarıları.
Drilldown: metriklerden günlüklere/izlere; Varsayılan günlüklerde 'trace _ id'.
Sentetikler: blackbox + başsız komut dosyaları (giriş/para yatırma/ödeme).

8) Kapasite yönetimi ve sürdürülebilirlik

Kapasite planlaması: Hedef RPS/rekabet gücü, AZ/bölgeye göre stok.
Bölme/dökülme: havuzları izole etme, önce ikincil işlevlerde başarısız olma.
Geri basınç ve kuyruklar: gecikme kontrolü, DLQ, uyarlanabilir rekabet gücü.
Yük devretme ve DR: RPO/RTO, düzenli DR matkaplar.

9) Güvenilirliğin bir parçası olarak güvenlik

Sırlar: gizli yönetici, JIT erişimleri, denetim.
Çevre üzerinde WAF/DDoS-guard, müşteri/kiracı sınırları.
Olaylarda PII minimizasyonu, DSAR/Legal Hold.
Tedarik zinciri güvenliği: eserlerin imzası, temel görüntü politikası.

10) Çağrı sağlığı

"Single" olmadan rotasyonlar, dinlenme pencerelerini temizleyin.
Gece uyanma eşiği sadece SLO P1/P2.
Psikohigien: Uyku eksikliği operasyonel bir risk olarak kaydedilir.
Metrikler: sayfalar/hafta, gece sayfaları/mühendis, kurtarma süresi.

11) SRE Olgunluk Metrikleri

SLO kapsamı: SLO/uyarılarla kritik yolların oranı %90 ≥.
Hata bütçesi yönetimi: donma kuralları vardır ve uygulanır.
Toil: Zamanın ≤ %30-40'ı, düşüş eğilimi.
MTTD/MTTR: Üç aylık dinamiklerde medyanlar.
Otomatik azaltma oranı: Otomatik eylemle olayların %'si.
PRR geçiş oranı: Üretim hazırlığını geçen sürümlerin yüzdesi.
Postmortem SLA: SEV-1 - 48 saat ≤ postmortem.

12) Dokümantasyon ve bilgi

• Runbooks/playbooks (üst komut dosyaları: 5xx spike, DB lag, Kafka lag, NodeNotReady, TLS).
• SLO kartları ve gösterge panoları.
• PRR kontrol listeleri ve sürüm şablonları.
• Platform servis kataloğu ve OLAs/SLAs.
• Eğitim materyalleri: SRE 101, Kaos 101, Çağrı üzerine 101.

13) Anti-desenler

Kahraman kültürü: Sistem düzeltmeleri yerine "kurtarıcılar".
Gürültülü uyarı: Çağrı cihazındaki CPU/sürücüler, yüzlerce gereksiz sinyal.
"DevOps bir adam": lekelenmiş sorumluluk, sahibi yok.
SLO eksikliği:'her şeyi yeşil tutun "- öncelikli kaos.
Gecikmiş ölüm sonrası ve "cadı avı".
Kanaryalar olmadan küresel geri dönüşler.
Config/repo sırlar; faaliyet denetimi yok.
Eyleme geçirilebilir sinyaller olmadan "güzel grafikler'olarak gözlemlenebilirlik.

14) Eser desenleri

14. 1 SRE-Charter (parça)

yaml mission: "Make reliability manageable and economical"
tenets:
- "User - SLI/SLO Center"
- "Automation-first, minimizing toil"
- "Blameless & learning"
governance:
error_budget:
freeze_threshold: 0. 8 # 80% of the budget burned ⇒ release frieze review_cadence: "weekly"
oncall:
paging_policy: "SLO-only, P1/P2 at night"
health_metrics: ["pages_per_week", "night_pages_per_engineer"]

14. 2 Mini-PRR kontrol listesi

• SLI/SLO ve yazma uyarıları yapılandırılmıştır
• Sağlık-uç noktaları ve sentetikler
• Runbook/playbook + sahibi/on-call
• Geri alma/özellik bayrakları/kanarya
• gecikme/hatalar/trafik/doygunluk panoları
• Sınırlar/kotalar/korkuluk güvenliği
• DR planı ve yedeklemeleri test edildi

15) Aşama ile uygulama (4 sprint)

Sprint 1 - Temel

Kritik kullanıcı yollarını ve SLI'ları tanımlayın.
SLO formüle edin ve yanık uyarıları çalıştırın.
PRR ve minimum oyun kitaplarını girin.

Sprint 2 - Değişim Yönetimi

Kanarya hesaplamaları, SLO tarafından otomatik geri alma.
Self servis işlemler, servis kataloğu.
Zahmetli envanter ve otomasyon planı.

Sprint 3 - Eğitim Döngüleri

Ölüm sonrası ritüel, kaos oyunları takvimi.
Panolar SLO + olayları, hata bütçesini bildirme.

Sprint 4 - Optimizasyon ve Ölçek

SLO portföyü, FinOps "9 başına maliyet".
DR disiplininin uygulanması, güvenlik denetimi.
KPI nöbetçi, tükenmişlik önleme.

16) Mini-SSS

SRE ='her şeyi düzelt "?
Hayır. SRE güvenilirlik sistemini yönetir: SLO, uyarı, süreçler, otomasyon ve eğitim.

Bir işletmeyi güvenilirliğe yatırım yapmaya nasıl ikna edebilirim?
ROI'yi göster: Daha düşük MTTR, daha yüksek dönüşüm, daha az SLA kredisi, hizmet maliyetinin altında, istikrarlı sürümler.

Ayrı SRE komutlarına ihtiyacım var mı?
Hibrit model: Kritik ürünlerde platform + gömülü-SRE'de stratejik SRE.

Toplam

SRE kültürü bir pozisyon değil, riskle çalışmanın bir yoludur: SLO - hata bütçesi - yönetilen değişiklik - otomasyon - eğitim. İlkeleri düzeltin, ritüelleri başlatın (PRR, post-mortemler, kaos oyunları), zahmetli ateş edin, "varsayılan olarak" gözlemlenebilirlik oluşturun ve çağrıya dikkat edin. Bu şekilde sürdürülebilir geliştirme hızı, öngörülebilir sürümler ve güvenilir, ekonomik bir platform elde edersiniz.