Birçok ekipte iki uç var:
- “Sürekli release yapalım” (risk büyür)
- “Bir incident oldu, 2 hafta freeze” (hız ölür)
Benim pratikte en iyi sonuç aldığım yaklaşım üçüncü yol: Hata bütçesini (error budget) gerçek bir kontrol sinyaline dönüştürmek. Yani yayın hızını “hissiyata” göre değil; SLO burn’e göre yönetmek.
Hata bütçesi neyi çözer?
SLO tanımı yaptığında, sistemin “kabul edilebilir hata” payını da tanımlarsın. Bu pay tüketiliyorsa:
- yayın hızını düşürmek mantıklıdır (risk/etki artmıştır)
- iyileştirme işini öne almak mantıklıdır (operasyon borcu büyümüştür)
Asıl amaç; “release yapmayalım” değil, doğru anda doğru yayını yapmak.
Release gate’i “bir metrik” değil, bir karar modeli olarak kur
Benim modelimde gate 3 sinyalle çalışır:
- Kısa vadeli burn: Son 1–2 saat (ani bozulma var mı?)
- Orta vadeli burn: Son 6–24 saat (trend kötü mü?)
- Incident durumu: Aktif Sev1/Sev2 var mı? (komuta modu açık mı?)
Bu üçü ile “yayın” için 3 karar üretirsin:
- Go: normal yayın
- Go (guarded): canary + daha yavaş rollout + hızlı rollback
- No‑Go: sadece acil güvenlik/iş sürekliliği düzeltmesi
Eşikler: sahada işe yarayan örnek
Örnek bir servis için:
- SLO: %99.9 başarı (aylık)
- Hata bütçesi: ~43 dakika/ay
Benim sık kullandığım burn mantığı:
- 2 saatlik pencerede burn rate > 2 → Go (guarded)
- 6 saatlik pencerede burn rate > 3 → No‑Go
- 24 saatlik pencerede burn rate > 1.5 → Go (guarded)
Burada rakamlar “evrensel doğru” değil; önemli olan:
- kısa vadede hızlı bozulmayı yakalamak
- orta vadede trendi yakalamak
- kararın rollout stratejisine bağlanması
Gate’in çıktısı: rollout stratejisini otomatikleştir
Gate sadece “build fail” demek zorunda değil. Ben çoğu ekipte şu yolu öneriyorum:
- Gate sonucu release parametresi üretir
- “guarded” modda: canary yüzdesi düşer, adım aralığı artar, otomatik rollback daha agresif olur
- “no‑go” modda: sadece “break‑glass” label’lı PR’lar geçer
Örnek bir CI/CD kontrolü (temsili):
name: release-gate
on:
workflow_call:
outputs:
mode:
description: gate result
value: ${{ jobs.gate.outputs.mode }}
jobs:
gate:
runs-on: ubuntu-latest
outputs:
mode: ${{ steps.out.outputs.mode }}
steps:
- name: Decide gate mode
id: out
run: |
# pseudo: fetch burn rates from your metrics API
echo "mode=guarded" >> "$GITHUB_OUTPUT"Bu yaklaşımda “guarded” mod, yayını tamamen durdurmadan riski düşürür.
Operasyon tarafı: gate’in sahibi kim?
Gate’in en kritik parçası sahiplik.
- “SRE onaylıyor” dediğinde, SRE’nin gerçek kapasitesi ve yetkisi var mı?
- “Ürün ekibi karar verir” dediğinde, incident refleksi ve ölçüm okuryazarlığı var mı?
Benim pratikte işe yarayan dağılım:
- SLO tanımı + gate politikasını platform/operasyon liderliği yönetir
- “No‑Go” kararında incident commander söz sahibidir
- “Go (guarded)” yayınını servis sahibi yapar ama rollout guardrail’leri platform sağlar
Gate’in kör noktaları (ve çözüm)
1) Batch job’lar SLO’yu bozuyor
Çözüm: SLO’yu “user journey” ile ölç; batch’i ayrı SLO’ya ayır.
2) Dış bağımlılık (vendor) yakıyor
Çözüm: “dependency SLO” tanımla, gate kararında ayrı sinyal olarak ekle.
3) Gate çok gürültülü (false positive)
Çözüm: burn hesaplarını farklı pencerelerde dengele, incident durumu ile çapraz doğrula.
Sonuç
Hata bütçesi ile release gate tasarlamak; “release hızını düşürmek” değil, hızı duruma göre ayarlamak demektir. Doğru sinyaller, doğru eşikler ve rollout stratejisine bağlı otomasyonla; hem güvenliği hem de teslim hızını aynı sistemde tutabilirsin.