Kurumsal sistemlerde outage’ın önemli bir kısmı “kodu deploy ettik ve bozuldu” değil, “konfigürasyonu değiştirdik ve bozuldu” sınıfındadır. Çünkü konfigürasyon çoğu zaman:
- Sahiplenilmez (owner belirsiz)
- Versiyonlanmaz (ne zaman ne değişti bilinmez)
- Test edilmez (prod’de denenir)
- Geri alınamaz (rollback yok)
Bu yazı, konfigürasyonu “dosya” değil kontrol düzlemi olarak ele alan bir governance yaklaşımı sunar.
1) Konfigürasyonun üç sınıfı
İlk adım: her şeyi aynı sepete koymamak.
- Secrets (parola, token, private key)
- Parametre (timeout, threshold, endpoint, quota)
- Feature flag (davranış aç/kapat, degrade, canary)
Bu üç sınıfın saklama, erişim ve audit ihtiyacı farklıdır.
2) Parametre store: neden, ne zaman?
Parametre store/konfigürasyon servisi şu problemleri çözer:
- Değişiklikleri merkezi yönetmek
- Audit log üretmek (kim, neyi, ne zaman değiştirdi)
- Ortam bazlı ayrım (dev/stage/prod)
- Rollback (önceki versiyona dön)
Ancak şunu unutma: “store” tek başına çözüm değildir. Asıl değer, etrafındaki süreçtir.
3) Feature flag disiplini: kill-switch bir ürün özelliğidir
Feature flag’ler iki sebeple hayat kurtarır:
- Riskli özelliği kontrollü açarsın (canary)
- Sorunda hızlı kapatırsın (kill-switch)
Ama kötü yönetilirse “flag çöplüğü” olur.
Pratik flag kuralları:
- Her flag’in owner’ı olmalı
- Her flag’in TTL’i olmalı (geçici flag otomatik kapanmalı/temizlenmeli)
- Flag değişikliği audit edilmeli
- Flag değerleri “insan gözüyle” anlaşılır olmalı (magic number değil)
4) Şema ve doğrulama: yanlış config’i prod’e sokma
Config değişikliğinin en pahalı kısmı, yanlış değerlerin sessizce yayılmasıdır.
Minimum doğrulama seti:
- Şema (JSON schema / zod vb.)
- Aralık kontrolü (timeout 0 olamaz gibi)
- “Dangerous value” denylist (ör.
0.0.0.0/0gibi) - Değişiklik öncesi smoke test (config apply sonrası)
5) Onay akışı ve blast radius: “küçük değişiklik” miti
Konfigürasyon değişikliği için iki soru:
- Blast radius nedir? (kaç servis, kaç kullanıcı, kaç region)
- Geri dönüş ne kadar hızlı? (tek tık mı, deploy mu?)
Operasyonel yaklaşım:
- Prod değişiklikleri “iki kişi” kuralı ile onaylanır (en azından kritik parametrelerde)
- Canary: önce küçük bir user segmentinde uygula
- Geri dönüş: önceki versiyona dönüş otomatik olmalı
6) Observability: config değişikliğini “event” olarak yayınla
Config değiştiğinde şunları otomatik üret:
- Deploy event benzeri bir “config event”
- Versiyon/etkin değer seti (değerleri değil, versiyon id’yi)
- Dashboard üzerinde “config değişti” işareti
Bu sayede incident sırasında “bu latency artışı config ile mi geldi?” sorusunu saniyeler içinde cevaplayabilirsin.
Konfigürasyon governance; aslında bir “hız freni” değil, doğru tasarlanırsa hızlandırıcıdır: daha kontrollü değişiklik, daha hızlı rollback, daha az incident. Feature flag ve parametre store’u; şema, audit ve süreçle birlikte kurduğunuzda gerçek değer üretir.